| For information on exception handling differences between V3.2 and V4.0, see
Digital_UNIX note 8958. I've added a pointer to that conference above.
Fwiw, there's a lot of "good stuff" in V4.0 vs. V3.2, likewise V3.2 over V3.0.
-Jeff
|
| Re .0:
> One of our partnr is looking for a detailed information relating to the
> differences in the C++ development environment avaliable on Digital UNIX
> V3.x and Digital UNIX V4.0 and also the language enhancements/features.
Please be aware that the DEC C++ compiler product is sold and packaged
separately from the underlying Digital UNIX operating system. Any questions
relating to language features provided by the compiler, rather than the runtime
libraries, are not affected by the version of UNIX in use. The latest version
of DEC C++/Alpha/UNIX, V5.5, requires Digital UNIX V3.2 or later.
So, staying at UNIX V3.2 will not currently prevent you from using the latest
compiler. However, this does not mean that all future releases of DEC C++ will
run on V3.2 - some day DEC C++ will probably require V4.0 or later. (I don't
know when that might occur, however).
>C++ Exceptions:
> Are exceptions supported on both releases and are there any
> significant limitations in either release?
>
> Are there differences in the way C++ exceptions
> are handled or supported between the two releases?
The reference in .1 knows more about the topic than I do.
> Is it necessary for all C++ shared libraries that are incorporated
> in an application to have exceptions enabled in order to be
> able to inter-operate or is it sufficient to have the
> top level exe of the application?
What does it mean for a shared library to "have exceptions enabled"? Are you
referring to whether or not the code was compiled with the -nocleanup switch to
disable calls to destructors upon stack unwinding?
Packaging code in shared libraries has no interaction with -nocleanup: If you
want auto and temporary object destructors to execute when a stack frame unwinds
from an exception, the module containing the function must be compiled without
-nocleanup. On the other hand, static and file-scope objects with destructors
are executed upon dlclose (or exit) regardless of whether or not -nocleanup was
used.
>Templates:
> Are templates suported on both releases and are there significant
> differences in the support?
Templates are supported by the compiler - I know of no differences in building
or runnning template programs between the UNIX V3.2 and V4.0 environments.
> Is the instantiation of templates in shared libraries supported
> in both releases?
Code generated by manual template instantiation can be loaded anywhere.
Planning the maintenance of any libraries, shared (.so) or static (.a), which
contain automatically instantiated templates requires familiarity with the
"Using Templates" chapter (5) of _Using DEC C++ for Digital UNIX_ manual,
particularly �5.2.9 (Building Libraries and Applications). A PostScript copy of
the manual is part of the online kit saveset pointed to by note 3197.7.
>C++ Static Initializers:
> We have had problems ensuring the order of static initializers
> in shared libraries for C++. Are there any significant differences
> between the releases.
The ld(1) linker in Digital UNIX V4.0 supports a "-reverse_init_order" linker
option which could possibly be of some assistance. For workarounds, and
pointers to information on that switch, please see topic 2566.
>Shared Libraries:
> We use a mix of shared libraries, some of which are automatically
> loaded at application startup, others of which are dynamically
> loaded during execution. Because of this, we tend to stress
> the capabilities of systems in the areas of synamic resolution
> of symbols for shared libraries. Are there any significant
> differences in this area between the releases?
I'm not aware of any differences between the base operating systems. (Neither
am I aware of any outstanding bugs in dlopen(3)/dlsym(3), particularly with
respect to DEC C++). Perhaps members of the TURRIS::DIGITAL_UNIX conference
would have more information.
Note, however that several bugs in dlclose(3) processing of destructors have
been fixed in support code shipped with the DEC C++ compiler in the past year.
The most important fix was first shipped with DEC C++/Alpha/UNIX V5.3 - see
topic 2632 for details.
Other readers may know of problems that have escaped my notice. However, I hope
the above helps. Feel free to ask for clarifications of any of the above, or to
elaborate upon the partner's requirements.
/AHM
|