[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hpux-cxx-dev
Subject:    CXX-DEV: Re aCC and versions/compatibilities
From:       sassan () cup ! hp ! com
Date:       1998-07-25 7:34:28
[Download RAW message or body]

Rey Berin writes:
 > Could someone please list the various versions of aC++ and
 > their compatibilites between each other?  We are currently
 > using "HP aC++ B3910B A.01.07" and would be interested in
 > knowing what our product works or doesn't work with; I 
 > understand that some(or future) versions aren't backwards 
 > compatible.
 > 
 > Thanks,
 > 
 > -Rey- 

Since this question has been discussed several times on this list in
the past, here is a note that describes the details of the (runtime)
incompatibilities between the aCC 1.06 and earlier releases with that
of aCC 1.07 runtime and later versions.  Note that the incompatibility
is essentially due to introduction of new data members in some of the
classes defined in the Rogue Wave STL and tools.h++ libraries in moving
from STL 1.2.0 to 1.2.1 and tools.h++ 7.0.3 to 7.0.6. I.e. old object
files or libraries compiled against the previous versions of these
libraries (and interface), when bound/run against the later versions
of the actual libraries, may behave incorrectly.  The compiler
proper's object and code generation models have not changed.


Compatibility of aC++ versions on HP-UX 10.20
=============================================
In the following statement the term "earlier" is used to refer
to components shipped with versions A.01.06 and earlier of the
aC++ compiler. The term "later" refers to versions A.01.07 and
later.

The transition from aC++ A.01.06 to aC++ A.01.07 (on 8/97) underwent
the following potentially incompatible changes:

(1) Rogue Wave STL:  Rogue Wave changed the layout of all the standard
    containers except "deque":  map, set, vector and list are affected.
    The default instantiations of adaptor priority_queue is over vector
    and therefore also affected.
    The adaptors stack and queue are affected if the default
    subcontainer is specified to be map, set, vector or list.
    The specialization vector<bool> is unaffected by the changes.
    The types string and bitset, and the templates basic_string and
    complex are not affected by this change either.

(2) Rogue Wave Tools.h++:  Many components in this library are built on
    top of Rogue Wave STL and are therefore affected by the incompatible
    transition.

(3) __versioned_type_info:  new "compilers" generate this symbol to
    ensure link/load-time diagnostics when linking/loading against "old"
    libraries.  There should be no problem in running old programs
    against new libraries. 

"Affected classes" are any component mentioned above plus any class that
contains an affected class by membership or by inheritance.

The compiler's "object" and code generation model, the run-time
support library (libCsup.a), the I/O streams library (libiostream.a),
the USL Standard Components library and the demangling library (in
/opt/aCC/lib/*.a) are not affected by the changes in the Rogue Wave
sources.

Examples of affected types:
   vector<MyType>
   list<int>
   list<int, MyAllocator>
   map<int, long>
   set<int*, MyPtrCompare>
   priority_queue<int>
   stack<int, list<int> >
   RW_VBase<vector<RWRESubexpression, allocator>,
            RWTValOrderedVector<RWRESubexpression> >

Examples of unaffected types:
   allocator
   string
   basic_string<wchar_t,string_char_traits<wchar_t>,allocator>
   complex<float>
   bitset<100U>
   vector<bool>
   deque<MyType>
   stack<int>

Unpredictable behavior results in the following circumstances (this is
not an exhaustive list):

(4) passing an object of one of the affected classes (by value, by reference
    or by pointer) between an earlier and a later binary.

(5) non-inlined calls to members of affected classes if the function
    called and the layout of the object are on different sides of the
    incompatibility.

(6) relying of the size of an affected class in any way;
    for example:
         char buffer[sizeof(vector<int>)*4];

Other issues: (these were intentional changes to allow C
programs to dynamically load aC++ libraries)

(7) Linking A.01.06 with +A with A.01.07 library will result
    in unsatisfied symbols with shl_get.

(8) Dynamically loading an earlier library with a later a.out will
    result in an unsatisfied reference to the symbol $global$.
    The symbol can be made visible using the -E option.

All other changes to the libraries shipped with aC++ correspond to
defect fixes and should not, to the best of our knowledge, affect
compatibility.
 _________________________________________________________________
 To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
    with the message UNSUBSCRIBE cxx-dev
 To reply to the list, send mail to cxx-dev@cxx.cup.hp.com
 _________________________________________________________________

[prev in list] [next in list] [prev in thread] [next in thread]