Re: disadvantages of using STL
On 22 Mrz., 07:59, "Tony" <t...@my.net> wrote:
"SG" <s.gesem...@gmail.com> wrote in message
On 21 Mrz., 11:24, "Tony" wrote:
My own library used to be value based but is now void* based.
IMHO, that was a bad decision.
Opinions vary.
Sure. We could agree to disagree. But ...
The generic/value semantics approach
is
the most universal one because you can choose to manage (smart)
pointers
OR your objects directly.
I analyzed that. I chose diferently than STL.
.... you could also explain WHY you chose so since I gave a reason why
I think the STL approach is the better one.
Also you lost type safety by using void*.
Shows you don't know what you're talking about. You say that so
"authoritively", but it is, of course (to the knowledgeable), entirely
false.
Right back at you. I could say the same thing to you. What's
probably more productive is telling us something about your design.
Like James Kanze wrote, you can use void* internally and use a
templated-interface that statically casts your pointers so that the
area you can screw up is restricted to the implementation details of
your container. But how should I know what your design looks like? I
was under the impression that you don't like templates.
Are you even interested in discussing this or do you just like to
demonstrate your superiority?
[speech about propaganda removed]
If you don't want copies (because copying is expensive or not
appropriate) and/or you want runtime polymorphism you could
use (smart) pointers.
I was being flighty about STL: I think it is "intrusive". Assumptive (les=
s
than comprehensively thought out). Wait, oppressive that it/they assumed
they knew my domain of implementation.
What's your definition of intrusive then and more importantly why is
it such a bad thing (in this case)?
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).
Oh, I see what you mean. But there's nothing bad about it.
YMMV, but for me/my code, I assure you that it is more than just a hindra=
nce
(it's completely wrong).
That's not enough to convince me, really. Can you shed some more
light on this? Maybe give an example + arguments about it being a bad
design?
It's
actually very good.
Noted: you are a marketeer. (Anything you say can and will be held agains=
t
you ...)
Oh, please! Stop this. Can't you discuss a topic without attacking
someone personally?
The thing is: the container is supposed to manage
the objects of a specific type.
Look up this word: paradigm.
Look up another: propaganda.
This is not very constructive at all. I assure you I'm quite capable
of accepting advice, admitting knowledge gaps, etc. But so far you
havn't said anything interesting.
Why not storing these objects directly
as a member of some other "node" object that also contains some
links. (I guess you were thinking about std::list). It doesn't
qualify as "intrusive".
Surely curb this. You are professing "holy grail" of containers and
algorithms. Good luck finding Jesus.
We get it. For you "intrusive" means something different. Still, you
haven't pointed out the weakness of this design or gave ANY argument
whatsoever. You merely generated noise. Frankly, this is the
behaviour I would expect from a crank.
Was STL the first to introduce the concept of algorithms working
on containers via iterators?
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.
Ahhh! Now we get to "the point": Muscle cars!
I'm sure that's not the only good argument. But at least it's a good
one. Why do you want to pay for something you don't need? Even if it
turns out to be the only argument, what's bad about it?
What does TonyVector<int> do? Or is it just TonyVector (no template)
that accepts void*?
awaiting some constructive content,
SG