Re: [Dpcl-develop] STL and DPCL
Brought to you by:
dpcl-admin,
dwootton
|
From: Albert F. <al...@us...> - 2005-01-19 01:05:21
|
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
|