Re: disadvantages of using STL
On Mar 21, 2:24 pm, SG <s.gesem...@gmail.com> wrote:
this is my understanding of what "intrusive" means:
Example: Intrusive smart pointers: You are required to add the
reference counter to your object you want to manage.
Example: Intrusive Containers: You are required to derive from
a base class for your elements you want to manage.
In both cases you are forced to add some specific code to the
class of your objects. The pointer/container design is
"intruding" your class.
Exactly. That is the generally accepted meaning.
On 21 Mrz., 11:24, "Tony" wrote:
Another style of container implementation is via void*. No
derivation from a common base class needed. So you have at
your disposal at least 3 implementation techniques: NIH
style (derive from Object), STL templates with value
semantics, void* ptr based. I never liked the NIH style. My
own library used to be value based but is now void* based.
IMHO, that was a bad decision. The generic/value semantics
approach is the most universal one because you can choose to
manage (smart) pointers OR your objects directly.
It depends on the language, but C++ has full support for value
semantics, and considers pointers to be first class objects, so
it does seem a shame to not take advantage of it.
Also you lost type safety by using void*.
Not necessarily, if the void* doesn't perculate up to the
interface of the template. What you do loose is control of the
lifetime of the members; you can (and likely will) end up with
dangling pointers in the container. Basically, you're requiring
the client code to handle lifetime---for complex, entity
objects, this is actually preferable (but then, you'd have a
container of pointers, so that's what you'd get), but for things
like int, it's a recepe for disaster.
[...]
Also intrusive because the actual objects get embedded into
things like links directly via the value semantic based template
generation process. That sounds quite intrusive (if not assuming).
It's the opposite of intrusion. Nothing intrudes into the
objects in the container.
[...]
The STL component of the standard library is actually the
best thing about it. That whole style of programming is
quite effective and represents some of the best in system
design. The STL is well worth studying as an example of
great style and design.
Was STL the first to introduce the concept of algorithms
working on containers via iterators?
Certainly not. The concept was around even before C++ was
invented.
I don't know. But that's not the point. The point is that
the STL does so *without* runtime polymorphism which is a big
advantage w.r.t. code optimization.
With regards to "polymorphism" of iterators, there are really
two dimensions (or maybe more): one corresponds to the
value_type of the iterator, and the other to what the iterator
iterates over. Changes in the value_type change the interface
of the iterator; it is now recognized as a serious design error
to make these dynamically polymorphic (i.e. by having the
iterator always return Object*). There is some argument,
however, in favor of using dynamic polymorphism for the type of
the container (i.e. std::vector<double> and std::list<double>
would have the same type of iterator): you can't write a
function in C++ which processes a collection of iterators, some
of which are into vector, some into list, etc. The question in
this case is: how much does it cost, and how often do you want
to do this. And also, what are the side effects (i.e. you can't
use values if the object is to be dynamically polymorphic). The
iterators of my pre-standard containers supported both, and in
practice, the value semantics were used almost exclusively.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34