Your answer was clear enough. I meant that if he had gone
through what you wrote, but he couldn't reduce the size from
~ 260k, the answer to his question was still not clear. If
one compiler produces a 5k exe and another 260k on the same
input, you'd have to be dense not to question that.
For what definition of "input". As I said, I get anywhere from
about 4KB to 3MB with g++, depending on the compiler options.
If you consider the compiler options "input", then the question
of differences between compilers doesn't make sense: the
-dynamic option will likely cause an error on compilers other
than g++. We then slide off into implementation specific
issues, which aren't on topic here.
My own answer here is to read the compiler documentation. And
if that isn't clear, then change the compiler for one which has
clearer documentation. (And I know, changing the compiler isn't
always an option, and finding the documentation isn't always
that trivial---but most of the more frequently used
compilers---g++, VC++ and Sun CC, at least, have online
documentation which can be consulted. And in those three cases,
the documentation, although not perfect, is quite adequate.)
Different defaults between the compilers may account for the
difference, but it could be a problem with one of the
compilers.
It could be; the way the compiler instantiates templates can
make a big difference (and let's not forget that all of iostream
is templates). But somehow, I doubt it.
Of course, it could be that his compiler doesn't support dynamic
linking, and automatically links everything statically. In
which case, he will have very big executables, and there's not
much he can do about it.
More importantly, of course, one might ask: who cares? About
the size of hello, world, I mean. Typically, the size will be
something along the lines of n*k1 + k2, where n is the size of
the sources. If the problem is k1---if hello, world is so big
because the compiler is generating a 100 KB or so per line of
code, he has a real problem, since realistic applications
(anything from 50KLoc up) won't even fit on the disk. But IMHO,
that's unlikely. It's more likely a case of k2 being
excessively large---200K or more. Which means that the size
won't grow excessively as the application grows.
I agree that would be pushing his luck. In my opinion,
the only thing the guy could have done better was ask
first in his compiler specific ng. But if the answer
you get there doesn't cut it, bring it up somewhere
else. I can't think of a more appropriate ng than this
one in that case.
I have no problem with his initial question here: there are very
definite C++ issues involved, as well as implementation specific
details. I do have a problem with his attitude after
that---that the group is useless because we didn't
(couldn't---at least in my case) tell him the exact options he
needed.
. (Of course, he'll have to ask in a Bloodshed