Hello !

On AIX I may specify order loading shared libraries and therefore I may
define order initializing non-local static variables in different libraries.
How I may to do it on HP-UX ?

Michael.

"Michael Zavyalov" <mzav@isd.dp.ua> wrote in message news:<bosvcd$j5$1@mfdebug.isd.dp.ua>...
> Hello !
>
> On AIX I may specify order loading shared libraries and therefore I may
> define order initializing non-local static variables in different libraries.
> How I may to do it on HP-UX ?

by the order of shared libraries specified on the link command ? seems
to work in a simple case.

>
> Michael.
-----------------
cat > 1.c << \!
#include <iostream.h>
class A {
public:
A () { cout << "A" << endl ; }
} ;
A a;
!
cat > 2.c << \!
#include <iostream.h>
class B {
public:
B () { cout << "B" << endl ; }
} ;
B b;
!
cat > 3.c << \!
#include <iostream.h>
int main () { cout << "main" << endl ; }
!
aCC +z -b 1.c -o 1.sl
aCC +z -b 2.c -o 2.sl
aCC 3.c 1.sl 2.sl
../a.out
aCC 3.c 2.sl 1.sl
../a.out

"Michael Zavyalov" <mzav@isd.dp.ua> writes:

> On AIX I may specify order loading shared libraries and therefore I may
> define order initializing non-local static variables in different libraries.

The order of initialization of global C++ objects in separate
compilation units is *undefined*. If your program depends on such
order, you are fighting a loosing battle: whatever works today,
may break with the next compiler patch.

You'll be much better off redesigning your program to *not* depend
on the order of initialization of globals, or better yet not to
have any globals at all. Singleton pattern may help you get rid
of them.

Cheers,
--
In order to understand recursion you must first understand recursion.

Paul Pluzhnikov <ppluzhnikov@earthlink.net> wrote in message news:<u3ccskcrv.fsfYB8X@earthlink.net>...
> "Michael Zavyalov" <mzav@isd.dp.ua> writes:
>
> > On AIX I may specify order loading shared libraries and therefore I may
> > define order initializing non-local static variables in different libraries.
>
> The order of initialization of global C++ objects in separate
> compilation units is *undefined*. If your program depends on such
> order, you are fighting a loosing battle: whatever works today,
> may break with the next compiler patch.

oh yes, there is at least one such known problem, if you depend on any
order. between PA32 and any of PA64/IA32/IA64 the order definitely
changed.