On Oct 30, 2006, at 2:31 PM, Steve Checkoway wrote:
Dave Camp wrote:
Maybe this explains Windows engineers tendency to put all their C+
+ code in the .h files? Almost every Windows port job I work on
has 50-75% of the C++ source inlined in the .h files. I've never
been able to get an explanation as to why I see this so often...
that's got to put a lot of pressure on the linker to strip out all
the duplicate code generated in each object file.
I doubt that has anything to do with it. The more code the compiler
can see, the better it can optimize that code. Interprocedural
optimization is hard enough, but when you have code that has
already been compiled into machine code (in object files), you lose
all of the structure that you had at the source level.
That suggests a lack of decent performance analysis tools on Windows
or premature optimization on the part of the engineers. Throwing code
willy-nilly into the headers hoping for a performance boost doesn't
sound like a good engineering practice.
I guess the primary reason code like that sends up red flags for me
is that historically gdb has not worked well debugging code that
originates from inlines in headers. Maybe it's better these days
(I've been doing mostly Cocoa work for some time now). In any event,
it just doesn't seem right.
Does Windows not have a performance tool like Shark? I'm going to
guess not...
Dave
---
There's an old proverb that says just about whatever you want it to.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
