Re: Module boundaries with classes and exceptions.
Alberto wrote:
I just finished the book C++ Coding Standards, an item arise this
question:
'Is not safe to propagate exceptions between library'
I'm sincere, the question never passed through my mind ^^''
I'm curious as to the context. I certainly expect exceptions to
propagate up from one library to the next on a regular basis.
The standard library does it all the time---what good would
std::bad_alloc be if it weren't allowed to propagate out of the
standard library.
But there is another (mine this time)
'I not safe to pass class between library also'
(This time library should be read shared object)
Well, there's no such thing as shared objects in C++. At least
no officially. However, I don't think that that's your problem.
Let me explain the latter. I spent about a day trying to
figure a segmentation fault, the program was crashing on
access to the code of a function.
A code like this
char * a = something->get_char_buffer();
Where 'something' is a valid pointer.
The code crashed before get_char_buffer code, why?
Well after a lot of search I found that a library was compiled with
get_char_buffer virtual, the other not.
This is really bad, but the linker was fine with it...
Whether a function is virtual or not is usually not verified.
You have a typical case of undefined behavior, where different
object modules were compiled with different versions of a header
file. The fact that the object modules were in different
libraries, or that the libraries were dynamically loaded, is
incidental---I've encountered the same problem in statically
linked files, and within a single library.
(By the way, the code was old and not documented, and even
officially tested and validated)
Now here are my questions
1) How exception on constructors can be managed?
Cause, for functions a success flag can be returned, but not for
constructors...
What is there to manage? Most of the time, an error in the
constructor will either abort the program or raise an exception.
There are a few exceptions, like the istream and ostream
classes, where the class itself manages an internal error state,
which has to be tested, but they are just that, exceptions.
2) There is a way to force a compiler/linker to check against non
consistent class
definitions?
Petition your vendor. It's undefined behavior, and a compiler
is allowed to signal an error. And it should be possible, at
least for statically linked object files.
Other than that, you could probably do some version management
yourself. If you change a class so that it is use is no longer
interchangeable, change its name, or the name of the namespace
which contains it.
3) A situation like this can happen?
Shared object A was complied with STL implementation A'
Shared object B was compiled with STL implementation B'
For some reason B pass a std::vector to A
In general, if you're using different compilers, they should use
different name mangling schemes, so the code shouldn't compile.
When you upgrade to a new version of the compiler, IF the object
code is not binary compatible, the name mangling scheme should
change. But I'm not sure that all compilers apply this
philosophy to the library, changing name mangling when the
library implementation becomes incompatible. And of course,
with at least two major compilers (g++ and VC++), compiling with
different options can result in incompatible libraries. (I'm
not sure about VC++, but I suppose that using full debugging, as
opposed to maximum optimization, results in larger size objects
for things like std::vector or standard iterators. This is, at
least, the case with g++, and would seem norma.)
If this can happen what happen after?
As a general rule, *all* object files of a program, regardless
of whether they are statically linked or loaded dynamically,
must be compiled with the same compiler: same vendor, same
product, same version, AND same compiler options. Obviously,
some common sense should be used with regards to the
options---it is not recommended to use the same -o (for g++) or
/Fo (for VC++) option for each source code compilation. And if
the source files are in different directories, you may have to
adjust some of the -I or /I options so that they refer to the
same directory, and not so that they contain the same string.
On the other hand, you must be very careful about anything which
might affect the generated code, and that includes all of the -D
(/D) and -I (/I) options.
Companies supplying already compiled libraries should generally
forsee providing them in several different versions, compiled
with different options. You then choose the version which
corresponds to the options you are using.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]