Click here to Skip to main content
13,663,333 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


5 bookmarked
Posted 8 Apr 2009
Licenced CPOL

Optimizing Storage for Constant Data

, 8 Apr 2009
Rate this:
Please Sign up or sign in to vote.
How to optimize storage for constant data

In programs, we usually declare constant string data. Like:

const char* g_pchar = "this is a string";

You might be knowing that if we run multiple copies of an EXE or DLL, the code portion is not duplicated per process. So do the constant data. This is because the constant data is stored in a special section of EXE called ".rdata" (The code portion is stored in the ".text" section). But guess what will happen if we have a declaration like..

const CString g_str("this is the worst thing I can do");

Now you've got the CString object (which is quite small) in the .bss section (.bss section stores nonconstant uninitialized data), and you've also got a character array in the .data section(nonconstant initialized data), neither of which can be backed by the EXE file. To make matters worse, when the program starts, the CString class must allocate heap memory for a copy of the characters. You would be much better off using a const character array instead of a CString object. So never ever declare like that (Reference "Programming Microsoft VC++" by David Kruglinski).

OK, that was the theory. Now the reason why I stated the above theory is that, last week, I installed the latest VS 2008 feature pack. This feature pack had some new classes for MFC. So I decided to check out the new classes. The CWinAppEx is one among them. On the very first function, I stepped in (constructor of the CWinAppEx), I found the following piece of code:

const CString strRegEntryNameWorkspace = _T("Workspace");
m_strRegSection = strRegEntryNameWorkspace;

Oops! And when I scrolled up, there was another bunch of similar code:

static const CString strRegEntryNameControlBars = _T("\\ControlBars");
static const CString strWindowPlacementRegSection = _T("WindowPlacement");
static const CString strRectMainKey = _T("MainWindowRect");
static const CString strFlagsKey = _T("Flags");
static const CString strShowCmdKey = _T("ShowCmd");
static const CString strRegEntryNameSizingBars = _T("\\SizingBars");
static const CString strRegEntryVersion = _T("ControlBarVersion");
static const CString strVersionMajorKey = _T("Major");
static const CString strVersionMinorKey = _T("Minor");

I don't think anyone has seen such a badly written, poor quality code in the old MFC 4 code. Never did I. If MFC starts like this, where will the developers using MFC end up?

When I discussed about this in Codeproject and MSDN forum, I got some interesting response. That's how I came to here about Wirth's law[^] , which states:

Software gets slower, faster than hardware gets faster.


Software is decelerating faster than hardware is accelerating.

Very true and you just saw one example.



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer (Senior)
Singapore Singapore
No Biography provided

You may also be interested in...


Comments and Discussions

GeneralMy vote of 3 Pin
KawadeAjit7-Mar-11 18:57
memberKawadeAjit7-Mar-11 18:57 
GeneralSoftware gets slower, faster than hardware gets faster. Pin
BakaBug23-Apr-09 4:31
memberBakaBug23-Apr-09 4:31 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web06-2016 | 2.8.180810.1 | Last Updated 8 Apr 2009
Article Copyright 2009 by Naveen
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid