axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Some Design Questions...
Date Thu, 19 Aug 2004 00:49:43 GMT

Thanks for the info Samisa.

I see I came to the STL party late.  I reviewed the
thread on this subject.  I would like to add to the
discussion (albeit a little late).

First, I think Lahiru's perspective on this is spot on.
(message quoted below for convenience.)  I only differ
in that I don't care if the STL is exposed or hidden in
the engine.  If it is anywhere, I am concerned (reasons
stated below).

> I suggest eliminate stl so that it is not exposed to
> client although it is used inside the engine. There are several
> advantages by doing this.
> 1) Ability to support C. Other wise we need extra wrappers.
> 2) Some times users may face portability challenges if STL is exposed.
> 3) It is easier to manipulate an STL string, but char* is the standard
> string format in C/C++. so giving char* instead of STL string, gives the
> user more flexibility.
> Lahiru Wimalasiri

Second, when it comes to the STL, I'm less worried about performance
than I am reliability.  There's no secrets to these data structures.
You can pull a book off the shelf to see how to implement them.
I've just seen too many internal leaks from STL containers.  

Third, using STL complicates the matter of allowing folks to 
provide their own memory management routines.  Indeed, the STL
provides the allocator mechanism.  But in my experience that 
has been the least portable aspect of the STL.  I can't see a 
clean way for me as a technology integrator to replace all your
STL container declarations with ones that include my allocator.

I would love to be able to use the STL.  I'm a huge fan of generic
programming.  But the reality is that the leading 'S' in STL is a
falsehood.  I know C++-98 added much of the STL to the ISO C++
standard.  But the problem is not with the spec so much as it is
with the buggy/inconsistent implementations.

Having said all that...let me simplify things...  if you folks are
confident you can provide leak free usage of the STL, AND, you can
provide a means to allow me to provide memory management routines,
then I would go away a happy camper.  But my comments above support
my perspective that I don't believe the former assertion is feasible
since STLs vary and you have no control to fix them.  Yet I concede
the possibility that you may be using a subset of the STL that is
reliable across platforms (tough to prove, but possible; lest that
be the empty-subset ;-) ).

In there interest of full disclosure, I will reveal that I have been
fortunate to use some of the more exotic compilers around...Cygnus,
HPUX, eeek!  But these are falling away.  What is the opinion of the
AxisCpp group on what compiler and platform combinations you are
aiming to support?  Maybe that is an easier way to approach this
issue.  I could see reasonable arguments being made that only VC++
and GCC compilers of certain versions and above will be supported.

Anyway, I've been too long winded already.  It is a meaty subject.
Curious to hear your folks perspectives on these matters.


View raw message