| From: HYDRA::LNARAYAN "R Lakshminarayan, Software Partner Engg" 3-MAR-1997 11:30:34.26
To: US4RMC::"[email protected]"
CC: LNARAYAN
Subj: your questions relating to C++ and Digital UNIX
Richard T. Simpson
Thanks for contacting Alpha developer support. The following writeup
has answers for for your questions. Please do not hesitate to contact us
if you need further help.
Thank You
Nari
-Alpha developer Support
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?
Ada, C (SEH), C++, and the native exceptions facility (libexc) all work
fine together (even before V4.0) because Ada, C, and C++ exceptions are
layered on top of the native exceptions facility. They can co-exist
in the same program and catch each other's exceptions. If an Ada or
C exception propagates thru a C++ frame, the C++ runtime handler will
make sure the proper destructors get called.
DECthreads exceptions were a problem because they used their own
home-grown mechanism. However, as of V4.0, DECthreads exceptions
now also uses libexc.
However, there are some things you should keep in mind:
1. You cannot use DECthreads exception mechanisms inside of an Ada
function. I doubt it will even compile.
2. As of v4.0, DECthreads handlers can catch Ada, C, and C++
exceptions, and vice-versa.
3. You might want to avoid using DECthreads exceptions support in a
function that also uses C or C++ exceptions support. I think it
is supposed to work, but it may still have problems.
Note that C++ provides implicit exception handling to ensure
that destructors get called. Hence, you should be careful
about using DECthreads exception support in C++.
> 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). Please let me know
if you like to have a copy of the same.
>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, you may
consider the following
1. Move the definitions of the relevant variables into a single module, and
put the definitions in the correct order.
2. Reverse the order of the linking for the relevant modules
-or-
3. Utilize the "nifty_counter" workaround described on pp. 20-21 of ARM �3.4
(Start and Termination) to render their code portable.
>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++).
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,
this kit fixes the following problems:
In V5.1-1, a throw from a switch statement incorrectly
executed destructors for other case arms.
With V5.1-1, incorrect code was generated in some cases
when compiling with "-O -xtaso_short -vptr_size_short".
With V5.1-1, the compiler could not be invoked by a
command other than cxx.
================================================================================
|