Re: Register my own messages
On Thu, 24 Jan 2008 07:24:08 -0500, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
I consider it Best Practice to not include header files that are not needed.
If you apply the Best Practice of defining data in .cpp files where it
belongs, then people who don't always follow Best Practices won't have to
mind all the little hidden traps that otherwise come with your code.
Yep, it adds one UINT each time. Wow! If I have 1024 includes, I consume an ENTIRE PAGE!
You seem to have missed the point that your dynamic initialization of these
ints requires code. Do you know for certain that initialization code spread
out over 1024 object files is all consolidated into the same contiguous
pages, as opposed to being potentially spread out over 1024+ pages? Hmmm, I
wonder why the MFC source uses #pragma code_seg so much? I'd bet it has
something to do with increasing locality of reference to speed up program
start-up. I don't know the answer to this with any certainty, but since I
apply Best Practices and define data in .cpp files where it belongs, I
don't need to know. It's a question that Does Not Come Up.
Let's just say that in the big picture of what matters, this is so low on my priority
scale that it doesn't even register. The total initialization cost is less than half a
disk rotational delay, so depending on where the disk is spinning when the program is
launched, the overhead of the initialization is "lost in the noise", statistically.
If your premise for that conclusion was correct, I'd agree with you. But
it's not, and so I can't.
And as far as the GUID strings, yep, they use space, too. 40 characters. Counting the
UINT, that's 44 bytes (although the literal string goes into the sharable code segment).
So if my average user-defined name is, say, 16 characters, that's 56 characters; in
Unicode 112 bytes. So if I have 36 instances, I've used up a whole page, largely of code
space. Given that the messages are co-resident with the code that uses them, this is not
going to create a lot of paging events. Given the size of the projects I work on, this is
not going to impact the overall resources consumed, not enough to justify adding a lot of
effort to the design. It's an engineering decision: adding trivial runtime overhead vs.
adding a lot of upfront design effort to minimize something that doesn't matter a whole
lot.
Putting a data definition in a .cpp file where it belongs does not require
a "lot of effort".
Using extern const requires that I have to designate some module has having responsibility
for doing the actual declaration, and that introduces a gratuitous dependency I see no
reason to introduce. System architectures should be easy to reason about, and I feel that
trading off a little bit of code and data space to optimize architectural reasoning is a
good choice.
joe
You're defending a bad habit that gets worse the more it's used. People who
mistake it for a good idea that saves them (a truly trivial amount of) work
will apply it in new situations, and it has been recognized for a long time
as a method of last resort. To expand on my "nifty counter" reference and
discussion of the dynamic initialization issue, see:
http://groups.google.com/group/comp.lang.c++.moderated/msg/558c2079c28da418
<q>
It was first presented in the ARM (page 19), and if often called the
"nifty-counter" technique, after a name used in the example.
It is the technique often used for implementing iostreams,
to ensure that the standard streams (cin, cout, cerr) are
constructed before any objects that use them. It isn't
foolproof, and programmers sometimes manage to create
cross-dependencies that cause program failure during
startup.
In addition, the technique destroys program locality when
a helper object is created in every module during startup.
It causes your entire program to be paged in before the
first statement of main can run. On really big programs,
I"ve heard of startup taking a LOT of extra time.
</q>
When you define data in header files, the last paragraph is something you
must think about. Come to think of it, I explained all this to you long
ago, and I remember suggesting a non-portable way to save your method,
which is __declspec(selectany). I forgot about it because doing things the
easy, portable, right way, I have little use for it.
--
Doug Harrison
Visual C++ MVP