Steve,
I want to avoid STL in the public header, not in the source. A simple example is in the FunctionList.h.
The "void *_function_list" is really a vector <FunctionId*> pointer. the member function get_count() return the size of the vector, and the get_entry(int i) return the i'th entry of the FunctionId.

SourceObj.h is another example with reference count: It has nothing but a private variable "SourceObjABC * realSource", which points to the real implementation. This SourceObjABC should not appear in the public header (/usr/lpp/ppe.dpcl/include/* in aix).

The advantage of separate the interface and the implementation is that the tool writer needs not to recompile for each implementation (SourceObjABC) changes.

STL adds another layer of complication: compiler change. For the backward compatibility and support reason, we use an 'old' compiler version to create libdpcl.a. However, the tool writer can only access a 'new' version of compiler most of the time. STL may be enhanced by the newer compiler version.

If a public header has the following class:
   class A {
    public:
        int get_count() const {return v.size();}
        int get_entry(int i) const {if(i>=0 && i<v.size())return v[i]; else return -1;}
        int get_other() const {return other;}
        ...
    private:
        vector <int> v;
        int other;
    };

The dpcl library uses old STL to create an instances of A, but the call get_other() failed from tool writer if the "vector <int> v" changes size.

We can use a vector pointer to fix this problem, as below:
   class A {
    public:
        int get_count() const {return v->size();}
        int get_entry(int i) const {if(i>=0 && i<v->size())return (*v)[i]; else return -1;}
        int get_other() const {return other;}
        ...
    private:
        vector <int> * v;                <-- ptr
        int other;
    };

The inline functions get_count() and get_entry() can still fail as the size() and operator[] may point to wrong place in the new version of STL.

The only way to fix is to remove the inline functions to have the third form:

   class A {
    public:
        int get_count() const;
        int get_entry(int i) const;
        int get_other() const;
        ...
    private:
        vector <int> *v;
        int other;
    };

Now all the implementation are hidden in the libdpcl.a, which is compiled under the same version of STL. But, there is no need for the tool writer to know the private variable v is a STL vector* now. We reach the final form:
   class A {
    public:
        int get_count() const;
        int get_entry(int i) const;
        int get_other() const ;
        ...
    private:
        void * v;        <--- implementation detail
        int other;
    };

Albert Feng



Steve Collins <slc@sgi.com>
Sent by: dpcl-develop-admin@www-124.southbury.usf.ibm.com

01/18/2005 09:44 AM

To
dpcl-develop@www-124.southbury.usf.ibm.com
cc
wdh@sgi.com, slc@sgi.com
Subject
[Dpcl-develop] STL and DPCL





  Thanks to Albert Feng for pointing out past portability issues when using
 STL in the DPCL codes. He states that "We count(), get_xxxx() service functions to
 avoid the std:: at any cost". As a DPCL novice, this is a bit too vague for me.
 I was wondering if Albert (or anyone else) could give some specific examples of
 DPCL 'service functions' (precise source location in ~dpcl/src) and tell me just
 which STL functionality they replace. That way I can get an idea of just what
 would fit best as we implement our 'bget_all_statements' functionality for the
 ModuleObj level (only). Our originaly DPCL API change specified STL in a couple
 places and obviously we want to avoid going down the STL path if it has been a
 problem in the past.

                                                    Thanks again -

                                                     SteveC - SGI Tools
_______________________________________________
Dpcl-develop mailing list
Dpcl-develop@www-124.ibm.com
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-develop