Re: STL objects and binary compatibility
On May 14, 7:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
ajalkane wrote:
On May 7, 12:08 pm, James Kanze <james.ka...@gmail.com> wrote:
And the same compiler options. At least some of them can also
affect the binary compatibility. Using g++, try linking code
compiled with -D_GLIBCXX_DEBUG, and code compiled without it.
(Actually, it links just fine---it just crashes at runtime.)
And while I've not actually tried it, I would expect similar
problems with VC++ using mixtures of /Gd, /Gr and /Gz or
different values of /vm<x> or /Zc:wchar_t. (In practice,
without /vmg, you'll get binary incompatibility anyway.)
How does this affect exceptions? If I read correctly, does
it mean that it is a bad idea to throw exceptions from a
library function because the library might be compiled with
different compile options than the application using the
library?
Typically this isn't a problem. Consider your environment's
run time library, it will throw exceptions as specified by the
standard.
It depends. It may also throw exceptions in case of undefined
behavior. And binary compatibility will affect any exceptions
you throw as well.
And I really should have mentionned the /EH options as well. If
you compile some code without them, you may have binary
compatibility problems if other code is compiled with one of
them. I tend to forget them, however, since if you use the
default (no /EH options, e.g. no exception support), you get
compiler errors as soon as you include any of the standard
headers (which do use exceptions); in practice, /EHs is about
the only thing that makes sense (sort of like /vmg---I don't
even understand why the option is there, much less why the
default is not to use the only reasonable value for it).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34