Re: [Dpcl-develop] STL and DPCL

[Albert F. <al...@us...>]

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 <sl...@sg...> 
Sent by: dpc...@ww...
01/18/2005 09:44 AM

To
dpc...@ww...
cc
wd...@sg..., sl...@sg...
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
Dpc...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-develop