Re: Forced inclusion of "unused" objects
On Dec 9, 11:00 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Dec 9, 4:17 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
As I said else-thread, I just have a knee-jerk reaction to allowances
in the standard which allow the implementation to silently change the
behavior of the program in a platform dependent manner, such as
optimizing away unused translation units at whim, optimizing away
infinite loops, and so on.
I agree with you there (and you should add silently suppressing
a copy), but that's not what's happening in this case. The
issue here is that you're not including the translation unit in
the final program.
If the term "static library" is defined in such a way, then that seems
like a perfectly reasonable way to go about things. I have no problem
with that, well besides less than ideal documentation and education on
the topic.
The term "library" (static or otherwise) has always been defined
like that, ever since I can remember (and that goes back some).
As Pete said, when you go to a library, you don't have to take
out all of the books in it just to read one.
With regards to documentation and education: one could argue
that Microsoft has mislead people calling their dynamically
linked objects DLLs (where the last L stands for
library)---under Unix, they're .so (where the last o stands for
object). But the distinction really only becomes important when
static initializers are involved, and I suspect the name
predates that.
However, in the commercial code of my company, I was concerned
enough about this allowance to remove unused translation units
that I moved some namespace scope initialization code from one
file to another file which I knew was referenced externally.
It's a really bad thing in the standard which should be
removed. Hopefully it will be if and when we ever get dll aka
shared "object" support.
I'm not sure what you mean by "bad thing" in the standard. The
standard is simply conforming to the universal existing
practice, and in fact, leaves the entire issue "implementation
defined". (Everything concerning how you invoke the compiler is
"implementation defined". There is an implication, however, in
the statement "Library components are linked to satisfy external
references to functions and objects not defined in the current
translation." (=A72.1/9)
The support in the standard for dynamic linking is on hold for
the moment; hopefully, we'll get it sometime (in the form of
modules). But it certainly won't change anything fundamental
here: how you specify which modules are part of your program
will remain implementation defined, and when in a library,
modules (or components) will only be linked "to satify external
references to functions and objects not defined in the current
translation".
The obvious solution is to link the object files, rather than
putting them into libraries.
--
James Kanze