disadvantages of using STL
Pallav singh
Q What are the disadvantages of using STL ?
Thanks in advance
Pallav Singh
Victor Bazarov
> Q What are the disadvantages of using STL ?
The main disadvantage is that you need to learn those at least somewhat
before you can use them. All the other disadvantages pale in comparison.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Pallav singh
MFC CMap (works much faster than STL map because STL implementation
is
tree-based while MFC one is hash-based).
Pallav
Victor Bazarov
Uh... MFC CMap, what?
Alf P. Steinbach
> Pallav singh wrote:
>> On Mar 18, 1:36 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>>> Pallav singh wrote:
>>>> Q What are the disadvantages of using STL ?
>>> The main disadvantage is that you need to learn those at least somewhat
>>> before you can use them. All the other disadvantages pale in
>>> comparison.
>>
>> is
>> tree-based while MFC one is hash-based).
>
> Uh... MFC CMap, what?
It seems Pallav Singth thinks a that a similarity of names means roughly
equivalent functionality.
If it's true that MFC CMap is hash-based, then that is a hash table, presumably
without simple O(n) traversal of elements, and certainly not in sorted order,
but on the other hand offering O(1) insertion and look-up -- a different
trade-off from the one in std::map, and used for different purposes.
C++98 doesn't have a container based on hashing, but TR1 has, Boost has, and
C++0x will have.
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Jeff Schwab
> Q What are the disadvantages of using STL ?
Relative to what? The STL is imperfect, but I don't think I've seen a
better library of algorithms and containers.
James Kanze
> Q What are the disadvantages of using STL ?
Compared to what?
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> * Victor Bazarov:
> > Pallav singh wrote:
> >> On Mar 18, 1:36 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> >>> Pallav singh wrote:
> >>>> Q What are the disadvantages of using STL ?
> >>> The main disadvantage is that you need to learn those at
> >>> least somewhat before you can use them. All the other
> >>> disadvantages pale in comparison.
> >> MFC CMap (works much faster than STL map because STL
> >> implementation is tree-based while MFC one is hash-based).
> > Uh... MFC CMap, what?
> It seems Pallav Singth thinks a that a similarity of names
> means roughly equivalent functionality.
> If it's true that MFC CMap is hash-based, then that is a hash
> table, presumably without simple O(n) traversal of elements,
> and certainly not in sorted order, but on the other hand
> offering O(1) insertion and look-up -- a different trade-off
> from the one in std::map, and used for different purposes.
Note that hash tables are only O(1) if you have a perfect
hashing function. They can be close with a very good hashing
function, but approch O(n) with a very bad one. Writing a good
hashing function isn't trivial.
The result is that std::map is sufficiently fast most of the
time, and much easier to use, unless you've actually done some
research on hashing, and have all of the necessary tools in your
tool kit.
James Kanze
Better in what way? In some ways, the STL ranks as one of the
poorer libraries I've seen. On the other hand, it's standard,
and so it is there (and every competent C++ programmer knows it,
more or less, so that's one thing less they need to learn to
read my code). And whatever its defects, it's more than
sufficient for most uses, so there's no reason to choose
something more exotic.
Victor Bazarov
> On Mar 17, 9:31 pm, Pallav singh <singh.pal...@gmail.com> wrote:
>> Q What are the disadvantages of using STL ?
>
> Compared to what?
I thought it was "compared to *not* using it"... <g> I mean, what is
the alternative of "using"?
Jeff Schwab
> On Mar 17, 10:38 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> Pallav singh wrote:
>>> Q What are the disadvantages of using STL ?
>
>> Relative to what? The STL is imperfect, but I don't think
>> I've seen a better library of algorithms and containers.
>
> Better in what way?
What is this, a Zen koan? Every question met with a question? Better
in the sense that it's faster, more generic, and easier to use. When I
used the word, I was thinking of the old, intrusive containers used with
MFC, and of the Java collections framework.
co...@mailvault.com
> On Mar 18, 1:36 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:> Pallav singh wrote:
> > > Q What are the disadvantages of using STL ?
There's a nice table comparing intrusive and non-intrusive containers
in these
pages: http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive/.
Table 10.1. Summary of intrusive containers advantages and
disadvantages
Issue Intrusive Non-intrusive --
STL
------------------------------------------------------------------------------------
Memory management External Internal through
allocator
Insertion/Erasure time Faster Slower
Memory locality Better Worse
Can hold non-copyable and Yes No
non-movable objects by value
Exception guarantees Better Worse
Computation of iterator from value Constant Non-constant
Insertion/erasure predictability High Low
Memory use Minimal More than
minimal
Insert objects by value retaining Yes No (slicing)
polymorphic behavior
User must modify the definition of Yes No
the values to insert.
Containers are copyable No Yes
Inserted object's lifetime User (more complex) Container
(less complex)
managed by
Container invariants can be Easier Harder (only with
containers of pointers)
broken without using the container
Thread-safety analysis Harder Easier
There's also a performance comparison between Intrusive and Non-
intrusive
containers in those pages.
And yes, G-d willing, support for some of the Boost Intrusive
containers
on webEbenezer.net will come on line before the end of this month.
> MFC CMap (works much faster than STL map because STL implementation
> is
> tree-based while MFC one is hash-based).
http://www.boost.org/doc/libs/1_38_0/doc/html/unordered.html
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Juha Nieminen
> What is this, a Zen koan? Every question met with a question? Better
> in the sense that it's faster, more generic, and easier to use. When I
> used the word, I was thinking of the old, intrusive containers used with
> MFC, and of the Java collections framework.
How do you use intrusive containers with pre-existing types (which
don't know anything about the containers in question) and basic types
(ints, doubles...)?
Bart van Ingen Schenau
Compared to rolling your own, the disadvantages are that you don't
learn as much about implementing containers and algorithms.
Another disadvantage is that you don't have to spend so much time
hunting bugs.
Bart v Ingen Schenau
James Kanze
> James Kanze wrote:
> > On Mar 17, 10:38 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> >> Pallav singh wrote:
> >>> Q What are the disadvantages of using STL ?
> >> Relative to what? The STL is imperfect, but I don't think
> >> I've seen a better library of algorithms and containers.
> > Better in what way?
> What is this, a Zen koan?
Socratic reasoning:-).
> Every question met with a question? Better in the sense that
> it's faster, more generic, and easier to use.
Faster and easier to use? It ranks close to last among the
libraries I've used in that respect. More generic, perhaps,
although not always. On the other hand, it's far more complete
than any other library I've used, and it's generally more
orthogonal than most.
Most importantly, of course, it's standard. So you don't
(usually) have to think about it.
> When I used the word, I was thinking of the old, intrusive
> containers used with MFC, and of the Java collections
> framework.
I've never used MFC, but I find the Java collections easier to
use than the STL (although they also have some problems);
they're also more generic, at least in some ways. (Arguably,
the earliest versions were too generic. You could put a Toto
into a collection, and try to get a Titi out, only getting an
error at runtime. From what I understand, this defect has been
fixed, but I've not had the occasion to use Java since then.)
James Kanze
> James Kanze wrote:
> > On Mar 17, 9:31 pm, Pallav singh <singh.pal...@gmail.com> wrote:
> >> Q What are the disadvantages of using STL ?
> > Compared to what?
> I thought it was "compared to *not* using it"... <g> I mean,
> what is the alternative of "using"?
Yes, but... Not using it how? If the alternative being
considered is not using any containers, or any algorithms... if
you can easily do that, then the STL is just so much extra
baggage (as is any other container library you can think of).
If the alternative being considered is to implementing your own
libraries, the STL has distinct disadvantages when it comes to
job security (if you role your own, it will take a lot longer to
implement the application, and if you do it cleverly enough,
you'll be the only person who can maintain the code), but I
can't think of any others. If you're comparing it to the Java
collections, of course, the STL has some very distinct
disadvantages if you're programming in Java (it doesn't work in
Java), but just the reverse is true (for the same reason) if
you're programming in C++. If you're comparing it to OSE, it's
not as cleanly designed or as easy to use, but it's more
complete, and above all, it's standard, so new programmers on
the project can be expected to already be familiar with it.
And so on. Depending on the alternative you are considering,
the disadvantages will vary. In all be exceptional cases,
however, they won't be enough to outweigh the advantage of it
being standard.
Jeff Schwab
Well, I don't use them. :) When I had to use them, I wrapped them in
classes that implemented the relevant interfaces.
Noah Roberts
> Q What are the disadvantages of using STL ?
Efficiency.
Noah Roberts
Which reminds me of another disadvantage:
You don't get to spend all your time dealing with some hacked up version
of an intrusive linked list.
You don't get to write your own linked list for each type you want to
store in a linked list.
And...you don't get to add linked list management functionality to every
type that needs to be a node in a linked list.
With all these problems in mind, I don't know why anyone would even
consider using STL in a production product.
osmium
"Pallav singh" wrote:
> Q What are the disadvantages of using STL ?
It encourages others to use the STL, furthering it's lifetime and even more
widespread use. The STL is WAY over thought and as a result unduly
complicated. When you need an 800 page book (Jossutis) to describe how to
use a library offering these services, you have clearly lost touch with
reality. It looks to me like the work of a group, a BIG group, of academics
has been grafted onto the work of a lone practicing programmer who defined
C. The end result is a nasty slurry.
Gert-Jan de Vos
Nonsense. Jossutis describes the STL and the other parts of the
standard library.
Generic Programming and the STL by Matt Austern is a very good book on
the STL. It
describes the STL in some 70 pages. Then the original paper that
described the
full STL was much smaller still. STL uses only 4 concepts and only 3
that you need
to understand to use it effectively. The STL was the work of one man,
an academic?
Yes, a mathematician! I guess that's why it can do so much with so few
basic concepts.
Alf P. Steinbach
Well, there are three quality levels of headers in the standard library:
Medimum to very good: original STL headers (Stepanov's work (note:
Stepanov isn't acknowledged in the standard)).
So-so: language support (e.g. <memory>).
Really bad, avoid: all the i/o stuff, plus <string> (note: some of
responsible here are acknowledged in standard).
The really bad headers are the result of groups of academics and others trying
in committee fashion, and/or with academic view, to improve existing work.
Bjarne's original iostreams were practical, and I think they were excellent
design & idea for the time (early 1980's); the later "improvements", plus
transferring original idea to contexts it didn't apply to, it's all beeen
downhill very fast, quality-wise, so that now it stinks (hold your nose!).
Cheers,
- Alf (evaluator mode)
PS: The "avoid" above is an ideal that can't be achieved: we just have to use
std::string / std::wstring as string data carriers, there's no other option.
Juha Nieminen
>> How do you use intrusive containers with pre-existing types (which
>> don't know anything about the containers in question) and basic types
>> (ints, doubles...)?
>
> Well, I don't use them. :) When I had to use them, I wrapped them in
> classes that implemented the relevant interfaces.
So you basically replicated the STL functionality?
Juha Nieminen
> When you need an 800 page book (Jossutis) to describe how to
> use a library offering these services, you have clearly lost touch with
> reality.
I don't believe the 800 pages are dedicated to the basic usage of the
STL. You certainly don't need that much text for basic and even advanced
usage of the STL.
Just because a book might go very deep into what you *can* achieve
with the STL, that doesn't mean you *must* read the entire book in order
to efficiently use the STL. For example, how many times have you used a
custom allocator with an STL container? How well can you use the STL
without even knowing what an allocator is? Just because a book might
explain custom allocators in detail doesn't mean you must read that
chapter in order to use the STL.
Victor Bazarov
Herein lies another disadvantage: you have to sift through an 800 page
book to figure out the simple stuff and realise you don't need to read
all of it to make use of the STL... Bummer!
Juha Nieminen
> Herein lies another disadvantage: you have to sift through an 800 page
> book to figure out the simple stuff and realise you don't need to read
> all of it to make use of the STL... Bummer!
If that's the case, then the book is really badly written. Buy a
better one.
Jeff Schwab
Huh? No, sorry, I mean that I wrapped the elements, not the containers.
The STL doesn't require you to wrap anything, or derive from any
interface; it just requires you to support standard syntax. In
contrast, some of the older collection libraries, include MFC (IIRC),
required that any element to be stored in (say) an "array" collection
had to derive from an "array element" abstract class, and override
various member functions. I prefer the STL approach.
Juha Nieminen
What I meant was that by encapsulating the existing types into classes
that implemented the relevant interfaces, you are basically exactly
replicating the way which STL containers use to manage these same elements.
Noah Roberts
The Josuttis book is actually very well written. I've certainly seen
much worse. Each chapter starts with the basics and gets more complex
as you move forward.
What both Victor and the OP are forgetting is that this book is a
*Tutorial* and Reference. It is very difficult to write an effective
tutorial that addresses most learning styles in a matter of a few pages.
You need more than that, you need description, image, and example
along with exercises. The Josuttis book even leaves this latter part
out and is still a pretty effective instruction book (I'm a learn by
doing kind of person and I don't miss them too much).
It's actually pretty amazing that he's able to instruct that much and
well in just 800 pages something that's definitive reference (the
standard) is at least 200 pages. People complaining about 800 pages in
an instruction book on the C++ library are just lazy. It's a moderately
large library that's capable of doing quite a lot for its size.
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.
Victor Bazarov
> Juha Nieminen wrote:
>> Victor Bazarov wrote:
>>> Herein lies another disadvantage: you have to sift through an 800 page
>>> book to figure out the simple stuff and realise you don't need to read
>>> all of it to make use of the STL... Bummer!
>>
>> If that's the case, then the book is really badly written. Buy a
>> better one.
>
>
> What both Victor and the OP are forgetting [..]
Curious. Sarcasm detection apparently isn't working for some folks in
this thread... Oh well, time to ignore it.
Noah Roberts
Of course, it's not possible that your sarcasm expression system is buggy.
Jeff Schwab
I don't see how. The STL does not even require its elements to have
member functions, much less virtual member functions.
Juha Nieminen
> I don't see how. The STL does not even require its elements to have
> member functions, much less virtual member functions.
Oh, you mean the intrusive data containers are not template classes
but regular ones, and resort to use virtual functions on the members?
I thought intrusive data containers were supposed to be more efficient
than STL data containers.
Jeff Schwab
> Jeff Schwab wrote:
>> I don't see how. The STL does not even require its elements to have
>> member functions, much less virtual member functions.
>
> Oh, you mean the intrusive data containers are not template classes
> but regular ones, and resort to use virtual functions on the members?
Yes.
> I thought intrusive data containers were supposed to be more efficient
> than STL data containers.
They probably can be; the ones I've used just aren't. Boost.Intrusive
looks promising:
http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive.html
James Kanze
> Juha Nieminen wrote:
> > Jeff Schwab wrote:
> >> I don't see how. The STL does not even require its
> >> elements to have member functions, much less virtual member
> >> functions.
> > Oh, you mean the intrusive data containers are not template
> > classes but regular ones, and resort to use virtual
> > functions on the members?
> Yes.
> > I thought intrusive data containers were supposed to be more
> > efficient than STL data containers.
> They probably can be; the ones I've used just aren't.
I suspect that when you speak of "intrusive" containers, you
really mean non templated containers, where every member must
derive from some common base class (often Object). Generally
speaking, if you provide full value semantics, like the STL,
they will be less efficient. If you provide reference semantics
(as is usually the case), they will be as efficient as an STL
container of pointers, perhaps even slightly more so (although I
really doubt it).
In practice, this business of requiring everything to derive
from Object, and then having containers of Object*, is an idea
which has more or less been recognized as wrong. Jave started
this way, but has since added a limited form of templates to
avoid it. It fits in languages which don't do static type
checking, but that's not the case of C++ (nor Java)."
co...@mailvault.com
As far as I can tell what is listed in this table is accurate,
but it seems like one thing is missing that in my opinion is
in favor of non-intrusive containers. There's no measurement
of access times of elements. For example, by dereferncing a
std::list<int> iterator you get right to the value you want.
But with an intrusive list you have something like:
struct MyClass : list_base_hook<>
{
int a_;
};
boost::intrusive::list<MyClass> intrsv_lst;
boost::intrusive::list<MyClass>::iterator it;
Now you have to go through the object first to get to
the int member. So while the table mentions that
insertion/erasure is faster with an intrusive
container, it doesn't say anything about access times.
I'm not really inclined to convert STL containers of
either a basic type or a pointer to a base type to
intrusive containers. The intrusive syntax is
clumsier and the accesses will be a little slower.
But if you have a container of user defined types it
makes more sense to me to use an intrusive container.
Lionel B
> Juha Nieminen wrote:
>> osmium wrote:
>>> When you need an 800 page book (Jossutis) to describe how to use a
>>> library offering these services, you have clearly lost touch with
>>> reality.
>>
>> I don't believe the 800 pages are dedicated to the basic usage of the
>> STL. You certainly don't need that much text for basic and even
>> advanced usage of the STL.
>>
>> Just because a book might go very deep into what you *can* achieve
>> with the STL, that doesn't mean you *must* read the entire book in
>> order to efficiently use the STL. For example, how many times have you
>> used a custom allocator with an STL container? How well can you use the
>> STL without even knowing what an allocator is? Just because a book
>> might explain custom allocators in detail doesn't mean you must read
>> that chapter in order to use the STL.
>
> Herein lies another disadvantage: you have to sift through an 800 page
> book to figure out the simple stuff and realise you don't need to read
> all of it to make use of the STL... Bummer!
Yeah, especially as it lacks a contents page or index
( ;-) for the irony-challenged )
--
Lionel B
Tony
"James Kanze" <james...@gmail.com> wrote in message
news:1b786c0e-1be8-4367...@13g2000yql.googlegroups.com...
> Yes.
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. I thought that
STL-style was the intrusive style because they make copies of the objects
that get put into them and then they own them (?). 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).
Tony
Tony
"Faster and easier to use? [STL] ranks close to last among the
libraries I've used in that respect. More generic, perhaps,
although not always. On the other hand, it's far more complete
than any other library I've used, and it's generally more
orthogonal than most.
Most importantly, of course, it's standard."
That's least important IMO, especially if you mean it's ISO rather than
standard in general.
"So you don't (usually) have to think about it."
In what other way than with any other package of containers and algos,
commercial or house-specific that one is used to using?
Tony
Tony
"Victor Bazarov" <v.Aba...@comAcast.net> wrote in message
news:gppbqh$vv6$1...@news.datemas.de...
> James Kanze wrote:
>> On Mar 17, 9:31 pm, Pallav singh <singh.pal...@gmail.com> wrote:
>>> Q What are the disadvantages of using STL ?
>>
>
> I thought it was "compared to *not* using it"... <g> I mean, what is the
> alternative of "using"?
I thought he meant vs. using an alternative: home-grown or commercially
bought or other.
Tony
Tony
> > Compared to what?
You're assuming that because STL is complex and difficult to understand
immediately that all alternatives are so also. Probably also assuming that
nothing can be as reliable or perform as adequately as STL. All wrong
assumptions. And what good is a developer who can't implement say a linked
list? Moreso, what good is a development house or department that can't?
"Standard" an asset? Baah. That ISO put their seal on it is trivial and
quite possibly a negative aspect (overly-general comes to mind,
overly-complex comes to mind, semantically inelegant comes to mind...). The
right tool for the job is many more times than not, not "something ISO by
virtue of it's ISO-ness".
Tony
Tony
"Noah Roberts" <no...@nowhere.com> wrote in message
news:49c11c54$0$29989$cc2e...@news.uslec.net...
> Pallav singh wrote:
>> Q What are the disadvantages of using STL ?
>
> Efficiency.
He said DISadvantages.
Tony
>
> 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? If so, then your last statement, though a bit
strong, has some merit (there are other simpler ways that may be appropriate
for a given project and variations on the theme also). If it wasn't the
first to introduce that architecture, then I say the kudos belongs somewhere
else. The implementation, of course, is too obfuscated and complex to be of
"great style and design" even if the algo-iterator-container was first used
in STL (which I doubt, but I can't remember the early stuff anymore, say
Roque-Wave pre-template version, or Borland BIDS, e.g.).
Tony
SG
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.
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. Also you lost type safety by using void*.
> I thought that STL-style was the intrusive style because they make
> copies of the objects that get put into them and then they own them
> (?).
There's nothing wrong nor intrusive (by the definition I use) with it.
If you don't want copies (because copying is expensive or not
appropriate) and/or runtime polymorphism you could use (smart)
pointers.
> 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. It's
actually very good. The thing is: the container is supposed to manage
the objects of a specific type. 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 quality as
"intrusive".
On 21 Mrz., 11:59, "Tony" wrote:
> "Noah Roberts" wrote in message
> > Pallav singh wrote:
> >> Q What are the disadvantages of using STL ?
> > Efficiency.
> He said DISadvantages.
Duh!
On 21 Mrz., 12:14, "Tony" wrote:
> "Noah Roberts" wrote:
> > 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?
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.
Cheers!
SG
peter koch
> "Noah Roberts" <n...@nowhere.com> wrote in message
Why do you believe the implementation is obfuscated and/or complex?
That is simply not correct.
/Peter
James Kanze
> 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
> "James Kanze" <james.ka...@gmail.com> wrote in message
It would help if you could read English, or would at least read
the message you're responding to. I'm not assuming anything,
except that I'm working on a professional project, with other
people. I'm certainly not assuming that alternatives to the STL
have to be as complicated and as poorly designed as it is: I've
used many class libraries where that wasn't the case. And I've
certainly implemented library components every bit as reliable
as the usual implementations of the STL.
None of which has anything to do with the advantages of being
standard.
> Probably also assuming that nothing can be as reliable or
> perform as adequately as STL. All wrong assumptions. And what
> good is a developer who can't implement say a linked list?
> Moreso, what good is a development house or department that
> can't? "Standard" an asset?
Obviously, you're not an engineer, and have never had to
develop software that could be maintained by other people.
James Kanze
> >news:49c268a6$0$29975$cc2e...@news.uslec.net...
Well, there is all the allocator stuff, which is probably
unnecessary in most cases. Other than that, though...
Given the design, the typical implementation of the STL stuff is
archi-simple. I'd never design a component library from scratch
to use pairs of iterators, since that makes life too complex for
the user. But it actually simplifies the implementation.
Tony
"SG" <s.ges...@gmail.com> wrote in message
news:22ecb6f1-4772-41b1...@v38g2000yqb.googlegroups.com...
> Hello Tony,
>
>
> 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.
>
>
> 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.
Opinions vary.
> 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.
> 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. (Hehe, yeah I reveled in that a bit... it's sooo low hanging fruit
knowledge that it is begging to abuse for the fact that it is likely to be
PROPAGANDA).
>
>> I thought that STL-style was the intrusive style because they make
>> copies of the objects that get put into them and then they own them
>> (?).
>
> There's nothing wrong nor intrusive (by the definition I use) with it.
> If you don't want copies (because copying is expensive or not
> appropriate) and/or runtime polymorphism you could use (smart)
> pointers.
I was being flighty about STL: I think it is "intrusive". Assumptive (less
than comprehensively thought out). Wait, oppressive that it/they assumed
they knew my domain of implementation.
>
>> 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 hindrance
(it's completely wrong).
> It's
> actually very good.
Noted: you are a marketeer. (Anything you say can and will be held against
you ...)
> The thing is: the container is supposed to manage
> the objects of a specific type.
Look up this word: paradigm.
Look up another: propaganda.
> 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 quality as
> "intrusive".
Surely curb this. You are professing "holy grail" of containers and
algorithms. Good luck finding Jesus.
>
>
> On 21 Mrz., 11:59, "Tony" wrote:
>> "Noah Roberts" wrote in message
>> > Pallav singh wrote:
>> >> Q What are the disadvantages of using STL ?
>> > Efficiency.
>> He said DISadvantages.
>
> Duh!
A post before that he was "all over the map". It was very annoying.
>
>
> On 21 Mrz., 12:14, "Tony" wrote:
>> "Noah Roberts" wrote:
>> > 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?
>
> 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!
Tony
Tony
"peter koch" <peter.ko...@gmail.com> wrote in message
news:c61f3dcd-ab9e-44bb...@p11g2000yqe.googlegroups.com...
Because I've analyzed and assessed it.
> That is simply not correct.
That's obviously at best an opinion and at worst oppressionistic propaganda.
Tony
Tony
I see, you're still just studying English (nuff said, I'll try to NURSE YOU
WITH A TIT).
"I'm not assuming anything,"
Of course not (:P).
"except that I'm working on a professional project"
Noted: a "professional" project. Vs. of course me who comes in and clues in
the stakeholders and fires your ass for well known to me a variety of
reasons. I agree: you are probably a part of the "meltdown".
", with other
people."
Of course I'm not one of those. And you have a whole war theory implied.
"I'm certainly not assuming that alternatives to the STL
have to be as complicated and as poorly designed as it is: I've
used many class libraries where that wasn't the case. And I've
certainly implemented library components every bit as reliable
as the usual implementations of the STL."
But you don't do what I do.
"None of which has anything to do with the advantages of being
standard."
There are no advantages to being standard.
> Probably also assuming that nothing can be as reliable or
> perform as adequately as STL. All wrong assumptions. And what
> good is a developer who can't implement say a linked list?
> Moreso, what good is a development house or department that
> can't? "Standard" an asset?
"Obviously, you're not an engineer, and have never had to
develop software that could be maintained by other people."
Surely, "obviously" because you have said so. So let it be written.
Bitch.
Tony
SG
> "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 (less
> 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 hindrance
> (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 against
> 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
Tony
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.
You're right, I could. Of course.
> > 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?"
Hmm.
> [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 (less
> 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)?"
Hmm.
> >> 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
> hindrance
> (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?"
Hmm.
> > It's
> > actually very good.
>
> Noted: you are a marketeer. (Anything you say can and will be held against
> you ...)
"Oh, please! Stop this. Can't you discuss a topic without attacking
someone personally?"
Hmm.
> > 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."
Hmm.
> > 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."
Hmm.
> > > 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?"
Hmm.
"What does TonyVector<int> do? Or is it just TonyVector (no template)
that accepts void*?"
Hmm.
Tony
peter koch
> "peter koch" <peter.koch.lar...@gmail.com> wrote in message
And so did I. The code in general is simple and quite straight-
forward.
>
> > That is simply not correct.
>
> That's obviously at best an opinion and at worst oppressionistic propaganda.
The opinion occured in the post I responded to. You claimed that your
version of the standard library was complex and obfuscated.
/Peter
nick_keigh...@hotmail.com
> Juha Nieminen wrote:
> > Victor Bazarov wrote:
> >> Herein lies another disadvantage: you have to sift through an 800 page
> >> book to figure out the simple stuff and realise you don't need to read
> >> all of it to make use of the STL... Bummer!
>
> > If that's the case, then the book is really badly written. Buy a
> > better one.
>
> The Josuttis book is actually very well written. I've certainly seen
> much worse. Each chapter starts with the basics and gets more complex
> as you move forward.
>
> What both Victor and the OP are forgetting is that this book is a
> *Tutorial* and Reference. It is very difficult to write an effective
> tutorial that addresses most learning styles in a matter of a few pages.
> You need more than that, you need description, image, and example
> along with exercises. The Josuttis book even leaves this latter part
> out and is still a pretty effective instruction book (I'm a learn by
> doing kind of person and I don't miss them too much).
>
> It's actually pretty amazing that he's able to instruct that much and
> well in just 800 pages something that's definitive reference (the
> standard) is at least 200 pages. People complaining about 800 pages in
> an instruction book on the C++ library are just lazy. It's a moderately
> large library that's capable of doing quite a lot for its size.
it contains a lot of examples as well. It's much easier going than
other books I've tried (Musser et al springs to mind)
Noah Roberts
Hey Tony, I'd suggest fixing your quoting format. It's impossible to
tell where the quoted text ends and your response begins because you are
not using any quote character.
Noah Roberts
> "Noah Roberts" <no...@nowhere.com> wrote in message
> news:49c268a6$0$29975$cc2e...@news.uslec.net...
>
>> 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?
Probably, at least for C++. Stepanov is at the front line of generic
programming in C++: http://www.stepanovpapers.com/
Visitors where around for ages before that though.
If so, then your last statement, though a bit
> strong, has some merit (there are other simpler ways that may be appropriate
> for a given project and variations on the theme also). If it wasn't the
> first to introduce that architecture, then I say the kudos belongs somewhere
> else. The implementation, of course, is too obfuscated and complex to be of
> "great style and design" even if the algo-iterator-container was first used
> in STL (which I doubt, but I can't remember the early stuff anymore, say
> Roque-Wave pre-template version, or Borland BIDS, e.g.).
Noah Roberts
Tony
I don't think it is my problem. It's Microsoft's and those who post with
extended ASCII (?).
Tony
Tony
Are you being sarcastic or real? You previous post was so all-over-the-map
that I didn't respond to it.
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> > news:d89f30c4-b1bc-45e2...@j39g2000yqn.googlegroups.com...
> > "Faster and easier to use? [STL] ranks close to last among
> > the libraries I've used in that respect. More generic,
> > perhaps, although not always. On the other hand, it's far
> > more complete than any other library I've used, and it's
> > generally more orthogonal than most.
> > Most importantly, of course, it's standard."
> That's least important IMO, especially if you mean it's ISO
> rather than standard in general.
It depends on whether you want your code to be read by other
people or not. If you're just working in a vacuum, for your own
pleasure, it doesn't matter. If you're producing code in a
professional environment, where the code has to be reviewed, and
other people will have to maintain and modify it, using
something standard (in the sense of universally known and
understood) is an enormous advantage---if there is a standard
solution, then you should only do something else if there are
very powerful reasons for not using the standard.
> > "So you don't (usually) have to think about it."
> In what other way than with any other package of containers
> and algos, commercial or house-specific that one is used to
> using?
I don't understand the question. If it's standard, it's not
house specific---a new hire won't be familiar with anything
that's house specific. If it's commercial, it depends---a lot
of our software is based on Posix, and we expect new hires to be
as familiar with Posix as with C++, for example. More
generally, if the "commercial" product is widely enough used
that you can reasonably require experience with it for new
hires, fine. In all cases, it's a question of price/benefits: I
can quite understand firms adopting wxWidgets or Qt, for
example, even though they probably can't expect every new hire
to be familiar with it---there is no truely "standard"
alternative, and the benefits of using an already written
library are enormous. In most cases, however, the standard
library is good enough, and since anyone who claims knowledge of
C++ should be familiar with it, it's the way to go. In special
cases, however, there may be justification for something
different: a numerics application will probably prefer an in
house matrix class to std::vector< std::vector< double > >
(although it would almost certainly use std::vector in the
implementation), and a text processing program will doubtlessly
have its own "text" class (certainly based on std::string,
unless the profiler says no later).
James Kanze
> Tony wrote:
> > "Noah Roberts" <n...@nowhere.com> wrote in message
> >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> >> Pallav singh wrote:
> >>> Q What are the disadvantages of using STL ?
> >> Efficiency.
> > He said DISadvantages.
> Oh.
One man's advantage is another man's disadvantage. If you're
trying to hang on to a job, the fact that not using the STL
reduces efficiency, so that it takes you a year to finish the
job, rather than six months, could be considered an advantage
(provided you're sure that the employer doesn't realize that
you're artificially creating extra work, and fire you for it).
And if you're selling hardware, the fact that the software runs
slower, and that the customer needs two machines instead of one,
is also an advantage.
In this sense, the biggest disadvantage of the STL is that
everyone understands it, at least the basics. So it's harder to
write code that no one but you understands, so as to lock
yourself into a job.
Tony
After unobfuscation MAYBE. Even then though, not as clear as it could be. (I
extract algos from STL for use in my own code where I need a quick starting
point: It's painful).
>>
>> > That is simply not correct.
>>
>> That's obviously at best an opinion and at worst oppressionistic
>> propaganda.
> The opinion occured in the post I responded to. You claimed that your
> version of the standard library was complex and obfuscated.
Well maybe I did do that. I haven't used it in so long that I forget.
Borlands wouldn't compile easily. STLPort did, but was hardly ripe for
picking off the fruit. That's pretty much what I consider STL: SGI STLPort.
While I haven't been doing container algo development in a few years (I'll
be going back there to fill the holes though), I still have the HP sources
to look at that are much more comprehensible.
Tony
Tony
> Tony wrote:
>> "Noah Roberts" <no...@nowhere.com> wrote in message
>> news:49c268a6$0$29975$cc2e...@news.uslec.net...
>>
>>> 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?
>
> Probably, at least for C++.
That wouldn't count then if it was just grafted onto C++: no invention.
> If so, then your last statement, though a bit
>> strong, has some merit (there are other simpler ways that may be
>> appropriate for a given project and variations on the theme also). If it
>> wasn't the first to introduce that architecture, then I say the kudos
>> belongs somewhere else. The implementation, of course, is too obfuscated
>> and complex to be of "great style and design" even if the
>> algo-iterator-container was first used in STL (which I doubt, but I can't
>> remember the early stuff anymore, say Roque-Wave pre-template version, or
>> Borland BIDS, e.g.).
>
>
> That's obviously at best an opinion and at worst oppressionistic
> propaganda.
It's not, but of course I'm not going to eval and assess "competitor"
product to further the point.
Tony
On Mar 21, 11:40 am, "Tony" <t...@my.net> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
> > news:d89f30c4-b1bc-45e2...@j39g2000yqn.googlegroups.com...
> > "Faster and easier to use? [STL] ranks close to last among
> > the libraries I've used in that respect. More generic,
> > perhaps, although not always. On the other hand, it's far
> > more complete than any other library I've used, and it's
> > generally more orthogonal than most.
> > Most importantly, of course, it's standard."
> That's least important IMO, especially if you mean it's ISO
> rather than standard in general.
"It depends on whether you want your code to be read by other
people or not."
No it does not. You're doing the "assume god before proving god" thing. Std
C++ is not easy to read. But it can be. So I am saying that the style makes
more difference than the language. I think you may be saying that because
the common use of the language is cryptic, that is acceptable. I've had long
time Cobol programmers see my code and say: "that's easy! I can do that!".
It wasn't C++. It was my API or stylistic usage of the tool that could
grasp. All the details were hidden. Without going too far into hypothetical
land, there's a goodness aspect of computer language design in regards to
usage that is lacking with the concept (or just implementation?) of a "close
to the machine", "GP" language.
"If you're just working in a vacuum, for your own
pleasure, it doesn't matter."
But that's not true either: you're assuming some global coding style and
that does not exist. And just specifying the language is less important than
the "how" it is used. Your statement above is extreme. There is an entire
range of possibility between using an API written in C++ and having no rhyme
or reason/starting from scratch. I can't help but think you are on the
"start from scratch" position and that you feel that "have C++ std, will
travel" is adequate. Note that I say that is woefully inadequate. The C++
std doesn't even get one to level zero. There is SO much to be built before
you can even create a program: tooling up is necessary.
" If you're producing code in a
professional environment, where the code has to be reviewed, and
other people will have to maintain and modify it, using
something standard (in the sense of universally known and
understood) is an enormous advantage"
But that doesn't exist. Not at the level you suggest: that C++ std is that
thing. It's not. It's trees vs. paper. (Well maybe if you have Birch bark).
"---if there is a standard"
"IF" is the keyword in that statement.
"solution, then you should only do something else if there are
very powerful reasons for not using the standard."
Now you're arguing the std lib? That's such a small part of it. And using it
ties software to C++ more tightly than desireable (You don't think C++ is
the end do you? I'd say it's now obsolete for new development, save for that
quite obviously better language even largely based upon it).
> > "So you don't (usually) have to think about it."
> In what other way than with any other package of containers
> and algos, commercial or house-specific that one is used to
> using?
"I don't understand the question."
OK, but you didn't prune enough context to let me remember my thought. Hang
on... OK. Surely I meant that STL and the std lib is no better than any
other proven lib. You can only use time as a quality-producing measure at
the beginning of a development. It is a much used general "argument" though.
It has no teeth. Evolve something else in house or across a commercial
ecosystem and it will be better for a given use or for a given team (that's
your scenario), or a given software house or a given shrink-wrap house...
see what I'm saying? It's not just containers and algos and iterators. Other
things are directly related. Do you really want to suggest that some
homogenous "std" library is ideal? You have to look at the software
development environment: you're hoping for plug-n-play team members on SW
dev projects, but I assure you that it does not exist at the language level
and shouldn't. I can go on, but you get my point.
" If it's standard, it's not
house specific---a new hire won't be familiar with anything
that's house specific. "
See, you're dismissing the product-producing software or solution provider
in favor of low level technical detail. You may do it that way, teach
deliverable team members std C++ and such, I've done that, I aspire to
deliver shrink wrap. (I already do, but only to my consulting clients who
just want it done and use my software daily without even knowing it). I'm
solution focused rather than technology focused. I'm aspiring to get to a
higher level of solution and plugging away almost daily at my codebase. I'm
to the level now that I'm chomping at the bit of specifying and implementing
(latter is harder) my own language. Not just DSL either (it's mostly why I'm
on USENET again: R&D).
"If it's commercial, it depends---a lot
of our software is based on Posix, and we expect new hires to be
as familiar with Posix as with C++, for example. More
generally, if the "commercial" product is widely enough used
that you can reasonably require experience with it for new
hires, fine."
Again, I know that is too low level to be "standard". So I've said the ISO
committee should get out of the library business. A reference implementation
is all good. But a centralized implementation unextricable from the
paradigms of C++? No thank you. I consider that "boiling in oil" tactic. If
you want to talk standardization, I think you have to talk least common
denominator as a starting point.
"In all cases, it's a question of price/benefits:"
Don't forget the time component: short term vs. long term. Is it a
"consultancy" project team? A solution provider? A shrinkwrap software
house? These are all very different environments that can and should use C++
in different ways if they use C++ and THE AMOUNT OF TOOLING UP they do
before starting. C++ is not a tool. It's something to build tools from. It's
iron ore, rather than a sword.
" I
can quite understand firms adopting wxWidgets or Qt, for
example, even though they probably can't expect every new hire
to be familiar with it---there is no truely "standard"
alternative, and the benefits of using an already written
library are enormous."
That's not true. You're assuming an environment of use.
"In most cases, however, the standard
library is good enough,"
That's unproven rhetoric. Being first to market doesn't ensure being best at
anything.
" and since anyone who claims knowledge of
C++ should be familiar with it, it's the way to go."
That's not true either. Style, API and tooling up are much more important
than language. Architecture, design...
" In special
cases, however, there may be justification for something
different"
No, I disagree: as we know with C and C++, standards in languages and
libraries are stifling. New development is stifled by a standard that is
unnecessarily (for the scenario) "backward compatible. You know what it is
akin to? Putting code into the source control system too early. That is
indeed the C/C++ legacy. Trying to be a standard before it's even in
puberty.
" : a numerics application will probably prefer an in
house matrix class to std::vector< std::vector< double > >
(although it would almost certainly use std::vector in the
implementation), and a text processing program will doubtlessly
have its own "text" class (certainly based on std::string,
unless the profiler says no later)."
That's quite micro-level thought. It's important, but not in the outer
scope. Sure, someone has to "twiddle bits". If there is nothing beyond that
in a project, plan or argument, well, it's pretty much the Lord of the Flies
scenario.
Tony
Tony
On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
> Tony wrote:
> > "Noah Roberts" <n...@nowhere.com> wrote in message
> >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> >> Pallav singh wrote:
> >>> Q What are the disadvantages of using STL ?
> >> Efficiency.
> > He said DISadvantages.
> Oh.
"One man's advantage is another man's disadvantage. If you're
trying to hang on to a job, the fact that not using the STL
reduces efficiency, so that it takes you a year to finish the
job, rather than six months, could be considered an advantage
(provided you're sure that the employer doesn't realize that
you're artificially creating extra work, and fire you for it).
And if you're selling hardware, the fact that the software runs
slower, and that the customer needs two machines instead of one,
is also an advantage."
I was just alluding to the fact that the template-based STL is going to be
more efficient than any non-template or "partially templatized" version in
regards to program PERFORMANCE. But now that we're talking about it, in most
cases, it probably doesn't matter. I could "phone home" for calculations and
still have an adequate app program in some scenarios. Not in the Runge-Kutta
physics stuff, but scientific calculation is hardly the norm.
"In this sense, the biggest disadvantage of the STL is that
everyone understands it, at least the basics. So it's harder to
write code that no one but you understands, so as to lock
yourself into a job."
I'm not going to even try to grok that, because I don't think it is an
issue.
Tony
SG
On 24 Mrz., 11:23, "Tony" <t...@my.net> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
> > One man's advantage is another man's disadvantage. If you're
> > trying to hang on to a job, the fact that not using the STL
> > reduces efficiency, so that it takes you a year to finish the
> > job, rather than six months, could be considered an advantage
> > (provided you're sure that the employer doesn't realize that
> > you're artificially creating extra work, and fire you for it).
> > And if you're selling hardware, the fact that the software runs
> > slower, and that the customer needs two machines instead of one,
> > is also an advantage.
>
> I was just alluding to the fact that the template-based STL is going to be
> more efficient than any non-template or "partially templatized" version in
> regards to program PERFORMANCE. But now that we're talking about it, in most
...for some design you refer to by "non-template" and "partially
templatized". It would be nice if you can give some examples or point
to some other resource that explains these designs. Otherwise it's
hardly possible to list pros and cons. What kind of container are we
talking about? Linked lists?
I would say I'm fairly familiar with the principles behind the STL
containers and boost::intrusive. I'm not arguing against
boost::intrusive. But those intrusive containers are hardly
universally applicable -- try intrusive::list<int> ;) -- and only
useful in some special corner cases where it really matters, IMHO.
I'm still interested in what your "void*" design looks like, how it
achieves its type-safety w.r.t. the interface and why it should be
better than any of std::vector, std::list, boost::intrusive::list in
some specific case. There's also the boost pointer container library
but I think it might become obsolete once we get to store objects of
type unique_ptr<T> in standard containers.
> cases, it probably doesn't matter. I could "phone home" for calculations and
> still have an adequate app program in some scenarios. Not in the Runge-Kutta
> physics stuff, but scientific calculation is hardly the norm.
Why exclude it if you can be good at this, too? (i.e. using
std::vector<double> as a member of a matrix object for managing all
the elements, etc) You must have some compelling reason to do so. Is
it easier to learn than the STL?
> > In this sense, the biggest disadvantage of the STL is that
> > everyone understands it, at least the basics. So it's harder to
> > write code that no one but you understands, so as to lock
> > yourself into a job.
>
> I'm not going to even try to grok that, because I don't think it is an
> issue.
Please read again the very first quoted paragrah in this post.
One of the main STL advantages is that it's part of the C++ standard
(as previously mentioned by James Kanze). Another point for STL
containers would be that they're rather universal in comparison to
other approaches. Sure, in some special cases intrusive::list<T> may
be what you want for some T that derives from list_hook<>. But it's
practially the as std::list<T*> except for some performance and
exception-safety issues.
Cheers!
SG
Noah Roberts
You seem to be making a rather common and basic mistake: associating
implementation with design.
Anyone can obfuscate a design in their implementation.
co...@mailvault.com
> On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
>
> > Tony wrote:
> > > "Noah Roberts" <n...@nowhere.com> wrote in message
> > >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> > >> Pallav singh wrote:
> > >>> Q What are the disadvantages of using STL ?
> > >> Efficiency.
> > > He said DISadvantages.
> > Oh.
>
> One man's advantage is another man's disadvantage. If you're
> trying to hang on to a job, the fact that not using the STL
> reduces efficiency, so that it takes you a year to finish the
> job, rather than six months, could be considered an advantage
> (provided you're sure that the employer doesn't realize that
> you're artificially creating extra work, and fire you for it).
I take it by efficiency you mean programmer efficiency. Boost
Intrusive is more efficient runtime-wise than the STL.
Development using Boost Intrusive containers takes more time
for most of us than using the STL, but the customers will get a
better performing application. Eventually, presumably, we'll
get the hang of Boost Intrusive.
> And if you're selling hardware, the fact that the software runs
> slower, and that the customer needs two machines instead of one,
> is also an advantage.
This kind of assumes dull customers who don't check out the
competition. If that's the case, I wouldn't feel sorry for
them.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Rabbi Tarfon said: The day is short, the task is great, the
laborers are lazy, the wage is abundant and the master is urgent.
He used to say: It is not incumbent upon you to finish the task.
Yet, you are not free to desist from it.
James Kanze
> On Mar 24, 4:01 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
> > > Tony wrote:
> > > > "Noah Roberts" <n...@nowhere.com> wrote in message
> > > >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> > > >> Pallav singh wrote:
> > > >>> Q What are the disadvantages of using STL ?
> > > >> Efficiency.
> > > > He said DISadvantages.
> > > Oh.
> > One man's advantage is another man's disadvantage. If you're
> > trying to hang on to a job, the fact that not using the STL
> > reduces efficiency, so that it takes you a year to finish the
> > job, rather than six months, could be considered an advantage
> > (provided you're sure that the employer doesn't realize that
> > you're artificially creating extra work, and fire you for it).
> I take it by efficiency you mean programmer efficiency.
It's the most important kind. But in this case, I was
responding somewhat humorously---the original poster asked for
the disadvantages of the STL, so I suggested that one might be
that it increases programmer efficiency (and thus reduces the
length of the contract).
[...]
> > And if you're selling hardware, the fact that the software runs
> > slower, and that the customer needs two machines instead of one,
> > is also an advantage.
> This kind of assumes dull customers who don't check out the
> competition. If that's the case, I wouldn't feel sorry for
> them.
Yes. On the other hand, I've seen a couple of cases in my
career where a software company or a consultant has
(intentionally?) written code that no one else could understand,
and then lived of over priced maintenance contracts for the rest
of the programs lifetime.
co...@mailvault.com
I figured that, but didn't think it was right to omit the Boost
Intrusive library. I've started using it and like it.
Here are the first three times from executing the same request
with a version that uses the _Rb_tree class that underpins
std::set in a number of places:
ExecuteRequest took 56176
ExecuteRequest took 780
ExecuteRequest took 609
And here they are with a version that replaces three of
those uses with intrusive::rbtree.
ExecuteRequest took 43067
ExecuteRequest took 621
ExecuteRequest took 581
While I'm happy to be able to start using this library,
I still dislike the way the intrusive library wants to
reuse names like list and set/multiset. So I'm glad it
has a class called rbtree and would like to point it out
to others. Just as using _Rb_tree appealed to me
previously, I find (well, I haven't tried intrusive::set)
that the parallel makes sense here. Besides having a
nice interface, there won't be any confusion around the
name as the standard doesn't have an rbtree class and if
they add one they should call it rb_tree or something
other than rbtree. Besides testing it out internally,
I hope to have support for rbtree in the C++ Middleware
Writer as well.
> > This kind of assumes dull customers who don't check out the
> > competition. If that's the case, I wouldn't feel sorry for
> > them.
>
> Yes. On the other hand, I've seen a couple of cases in my
> career where a software company or a consultant has
> (intentionally?) written code that no one else could understand,
> and then lived of over priced maintenance contracts for the rest
> of the programs lifetime.
>
It seems like there should be a term for that. When I was
younger a coworker told me there are two kinds of programmers:
plumbers and pretenders. Our team lead was a pretender that
caused some grief. I've noticed what you are referring to as
well, even by people I consider to be very intelligent.
James Kanze
> On Mar 24, 4:36 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > Yes. On the other hand, I've seen a couple of cases in my
> > career where a software company or a consultant has
> > (intentionally?) written code that no one else could understand,
> > and then lived of over priced maintenance contracts for the rest
> > of the programs lifetime.
> It seems like there should be a term for that.
There is. At least in my book, it's called fraud if it's
intentional, and incompetence otherwise.
Alf P. Steinbach
> On Mar 25, 6:48 am, c...@mailvault.com wrote:
>> On Mar 24, 4:36 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> [...]
>>> Yes. On the other hand, I've seen a couple of cases in my
>>> career where a software company or a consultant has
>>> (intentionally?) written code that no one else could understand,
>>> and then lived of over priced maintenance contracts for the rest
>>> of the programs lifetime.
>
>> It seems like there should be a term for that.
>
> There is. At least in my book, it's called fraud if it's
> intentional, and incompetence otherwise.
There is the question of whose fraud and incompetence, though. :)
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Tony
"One of the main STL advantages is that it's part of the C++ standard"
I see that as a detriment, not an advantage.
Tony
Tony
<co...@mailvault.com> wrote in message
news:d492e829-ee29-479d...@g19g2000yql.googlegroups.com...
On Mar 24, 4:01 am, James Kanze <james.ka...@gmail.com> wrote:
> On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
>
> > Tony wrote:
> > > "Noah Roberts" <n...@nowhere.com> wrote in message
> > >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> > >> Pallav singh wrote:
> > >>> Q What are the disadvantages of using STL ?
> > >> Efficiency.
> > > He said DISadvantages.
> > Oh.
>
> One man's advantage is another man's disadvantage. If you're
> trying to hang on to a job, the fact that not using the STL
> reduces efficiency, so that it takes you a year to finish the
> job, rather than six months, could be considered an advantage
> (provided you're sure that the employer doesn't realize that
> you're artificially creating extra work, and fire you for it).
"I take it by efficiency you mean programmer efficiency."
Noooooo. I meant the space vs. time tradeoff.
Tony
Tony
On Mar 24, 9:11 pm, c...@mailvault.com wrote:
> On Mar 24, 4:01 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
> > > Tony wrote:
> > > > "Noah Roberts" <n...@nowhere.com> wrote in message
> > > >news:49c11c54$0$29989$cc2e...@news.uslec.net...
> > > >> Pallav singh wrote:
> > > >>> Q What are the disadvantages of using STL ?
> > > >> Efficiency.
> > > > He said DISadvantages.
> > > Oh.
> > One man's advantage is another man's disadvantage. If you're
> > trying to hang on to a job, the fact that not using the STL
> > reduces efficiency, so that it takes you a year to finish the
> > job, rather than six months, could be considered an advantage
> > (provided you're sure that the employer doesn't realize that
> > you're artificially creating extra work, and fire you for it).
> I take it by efficiency you mean programmer efficiency.
"It's the most important kind."
No, that's entirely wrong. JK is "assuming" that because some language or OS
or whatever has longevity, it has merit. And that is not so at all. Let's
make it less "light": "hey, if you do this, your kids will live and we won't
break your legs". (Was that it?).
"But in this case, I was
responding somewhat humorously---the original poster asked for
the disadvantages of the STL, so I suggested that one might be
that it increases programmer efficiency (and thus reduces the
length of the contract)."
In your contrived world. (I was raised by catholics, don't fuck with me).
> > And if you're selling hardware, the fact that the software runs
> > slower, and that the customer needs two machines instead of one,
> > is also an advantage.
> This kind of assumes dull customers who don't check out the
> competition. If that's the case, I wouldn't feel sorry for
> them.
"Yes. On the other hand, I've seen a couple of cases in my
career where a software company or a consultant has
(intentionally?) written code that no one else could understand,
and then lived of over priced maintenance contracts for the rest
of the programs lifetime.'
Of course that is the goal of C++ gurus: to be god! "standard library": I'm
not buying it. Language lock-in: I'm not buying it.
(Aside to BS: You were wrong... you were an old senile man when you invented
the language. ;) ).
Tony
Tony
On Mar 25, 6:48 am, c...@mailvault.com wrote:
> On Mar 24, 4:36 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > Yes. On the other hand, I've seen a couple of cases in my
> > career where a software company or a consultant has
> > (intentionally?) written code that no one else could understand,
> > and then lived of over priced maintenance contracts for the rest
> > of the programs lifetime.
> It seems like there should be a term for that.
"There is. At least in my book, it's called fraud if it's
intentional, and incompetence otherwise."
You're apparently quick to that. It is indicative. Was that vulturous? Hey
JK, curb it. You said "job security". Apparently it should be retroactively
revoked!
Tony
Tony
Oh, surely that is correct. "I beg your pardon, I'm so wrong with my life
that a sentence from you obliterates my very existence".
>
> Anyone can obfuscate a design in their implementation.
Cliches are like assholes.
Juha Nieminen
Yes, sure. We should all go back to C which doesn't offer any standard
library utilities whatsoever (except for a few horrid string functions).
This way we will be forced to create our own data containers from
scratch even for the smallest projects and spend hours and hours
bug-hunting and optimizing. This will allow us to create better-quality,
more maintainable software faster and better.
co...@mailvault.com
> "James Kanze" <james.ka...@gmail.com> wrote in message
>
> news:fae1e1aa-1d68-436c...@g38g2000yqd.googlegroups.com...
>snipped<
Tony, I'd appreciate it if you would watch your language here.
O
> "Yes. On the other hand, I've seen a couple of cases in my
> career where a software company or a consultant has
> (intentionally?) written code that no one else could understand,
> and then lived of over priced maintenance contracts for the rest
> of the programs lifetime.'
>
> Of course that is the goal of C++ gurus: to be god! "standard library": I'm
> not buying it. Language lock-in: I'm not buying it.
The STL is still decent. The Boost Intrusive library is
better than the STL in a number of ways and I expect it's
use will increase. I'm impressed recently by it's option
of a non constant-time size function. In the sort of code
I write, the use of size() is rare and not having to pay
for the field or increment/decrement it frequently makes
sense. Kudos to the Boost Intrusive library authors.
>
> (Aside to BS: You were wrong... you were an old senile man when you invented
> the language. ;) ).
>
I met Bjarne long after he invented the language and he
wasn't a senile man at that time. He was a friendly and
thoughtful host. Meanwhile, back at the ranch, gcc is
being developed in C as of March 27, 2009. That's where
we may find some senility. People who always do things
the same way are at greater risk of Alzheimer's than
those who change things up from time to time.
co...@mailvault.com
> On Mar 25, 6:48 am, c...@mailvault.com wrote:
>
> > It seems like there should be a term for that.
>
> There is. At least in my book, it's called fraud if it's
> intentional, and incompetence otherwise.
>
Yes, it's a form of fraud. I would like a more colorful
term for it when it's not due to incompetence. "Code
Lawyer" would be a start. I'm thinking of the twister-
of-words aspect that describes a lot of lawyers.
SG
> Cliches are like assholes.
Hello Tony,
it seems you don't have a lot to contribute to this (or any?)
discussion. I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:
* STL is supposedly complicated. It's more complicated
than your container library.
* You don't accept the STL being part of the C++ standard
library as an advantage even though obvious arguments
for this position have been mentioned.
* You prefer some "void*-based" container design (whatever
that means)
* You said that the STL's performance advantage "probably
doesn't matter".
This goes along with a lack of arguments and accusations à la
"Propaganda!", "You're a marketeer", "Bitch.", etc.
Nicely done, Tony.
-SG
Yannick Tremblay
Hi Tony,
I have doubt about replying to you because the way you have been
handling yourself in here leave doubts in one mind about what is your
purpose in this group. but still, I'll try.
James is correct when he say that programmer efficiency is the most
important one. Why does it trump execution memory space or execution
time? Because if you are using techniques that allow efficient
programming, then the required functionality will be completed
earlier. This will leave you time for profiling and then going back
to do properly targetted optimisation (execution time or memory usage)
where they are needed. This also leave your mind freeer to
concentrate on algorithmic efficiency rather than on low level
mechanics of of micro-optimisation (most likely premature).
Yannick
Noah Roberts
hehehehe, and here I was just going to say "*plonk*"
Jeff Schwab
Why?
Christof Donat
>> Every question met with a question? Better in the sense that
>> it's faster, more generic, and easier to use.
>
> Faster and easier to use? It ranks close to last among the
> libraries I've used in that respect. More generic, perhaps,
> although not always. On the other hand, it's far more complete
> than any other library I've used, and it's generally more
> orthogonal than most.
Well. actually I've been doing quite some Java coding during the last year.
I still think of the STL to be easier to use. The Java Containers have some
flaws I feel unesy with. See below for one example.
> I've never used MFC, but I find the Java collections easier to
> use than the STL (although they also have some problems);
> they're also more generic, at least in some ways. (Arguably,
> the earliest versions were too generic. You could put a Toto
> into a collection, and try to get a Titi out, only getting an
> error at runtime. From what I understand, this defect has been
> fixed, but I've not had the occasion to use Java since then.)
It has not been fixed. You still can write Java Code like this:
List<String> l1 = new ArrayList<String>
List l2 = l1;
List<Integer> l3 = l2;
You will get a compiler warning that you can swith off, but not an error. If
you run this code, put a String in l1 and try to take it out as Integer from
l3 you will get a ClassCastException at the point where you try to take out
the Integer.
Java generics are just a compiler feature. At runtime a container has no
information about the Elements it can hold. That ist the reason why the
ClassCastException can only be thrown when you try to access an element from
the container, not at the point when the container istself is casted which
actually is the error in this code.
Christof
Bo Schwarzstein
> Q What are the disadvantages of using STL ?
>
> Pallav Singh
In fact, the only disadvantage of STL is that I need DMA, get out the
data directly to feed the OpenGL. But in most times I have to allocate
another memory then "copy".
Tony
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:qY_yl.59$A17...@read4.inet.fi...
> Tony wrote:
>> "SG" <s.ges...@gmail.com> wrote in message
>> news:21656158-919d-4044...@q9g2000yqc.googlegroups.com...
>>
>> "One of the main STL advantages is that it's part of the C++ standard"
>>
>> I see that as a detriment, not an advantage.
>
> Yes, sure. We should all go back to C
When you reference C as if it was the only other alternative to C++, I
automatically think: propaganda. Does C++ need a marketeering team these
days?
> This way we will be forced to create our own data containers from
> scratch even for the smallest projects and spend hours and hours
> bug-hunting and optimizing. This will allow us to create better-quality,
> more maintainable software faster and better.
OK, you're being propogandist or you are just not very smart (is there
another option?). So you create a replacement container on one project.
Evolve it on the next. Confidence builds and you decide to implement a
number of containers. These evolve over time. THEN, you have a replacement
or potential replacement for the "do everything for everyone" std library.
That you took my thought to the extreme of "build containers from scratch on
every project" is quite annoying (though you are forgiven if indeed you are
just not very smart).
Tony
Tony
"Jeff Schwab" <je...@schwabcenter.com> wrote in message
news:0YednVRjhOfeq1DU...@giganews.com...
Do you know what a camel is? (And no, that's not the only reason).
Tony
Tony
<co...@mailvault.com> wrote in message
news:343a5ac1-7f18-49a1...@y9g2000yqg.googlegroups.com...
>on Mar 27, 1:29 am, "Tony" <t...@my.net> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
>
> news:fae1e1aa-1d68-436c...@g38g2000yqd.googlegroups.com...
>snipped<
Tony, I'd appreciate it if you would watch your language here.
O
> "Yes. On the other hand, I've seen a couple of cases in my
> career where a software company or a consultant has
> (intentionally?) written code that no one else could understand,
> and then lived of over priced maintenance contracts for the rest
> of the programs lifetime.'
>
> Of course that is the goal of C++ gurus: to be god! "standard library":
> I'm
> not buying it. Language lock-in: I'm not buying it.
"The STL is still decent."
What I think is the major value of STL: "exposing" the algorithms and
designs. All else is just syntax, and I consider the syntax bad.
>
> (Aside to BS: You were wrong... you were an old senile man when you
> invented
> the language. ;) ).
>
"I met Bjarne long after he invented the language and he
wasn't a senile man at that time. He was a friendly and
thoughtful host. Meanwhile, back at the ranch, gcc is
being developed in C as of March 27, 2009. That's where
we may find some senility. People who always do things
the same way are at greater risk of Alzheimer's than
those who change things up from time to time."
Dude, when I put in a wink, I mean it! I have nothing but respect for B.S.
His books are on my shelves 10 years (has it been more?) after he wrote
them, and I still refer to them. What I wonder though, is what kind of group
it is that actually creates such tomes. I can't imagine the writing being of
just one individual. Maybe guided and edited by an individual.
Tony
Tony
"Yannick Tremblay" <ytre...@nyx.nyx.net> wrote in message
news:73220306...@irys.nyx.net...
Noted. My purpose is to verify my designs and architectures.
> James is correct when he say that programmer efficiency is the most
> important one.
Your opinion noted. But it is an invalid (or worse) thing to say without a
given frame of reference: namely, in what time period? Because I can buy
high-dollar C++ programmers + a required guru who know the std library that
is better than tooling up to avoid that scenario? I need to see 2 or 3
alternatives or I know something is rotten in Denmark.
[snipped invalid-assumption based stuff]
Tony
Tony
On 27 Mrz., 07:41, "Tony" <t...@my.net> wrote:
> "Noah Roberts" <n...@nowhere.com> wrote in message
> > Anyone can obfuscate a design in their implementation.
> Cliches are like assholes.
"Hello Tony,"
No need to be formal (seesh).
"it seems you don't have a lot to contribute to this (or any?)
discussion."
Give to receive. (Or is that too a cliche?).
" I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:"
("only", as if you are omniscient).
"* STL is supposedly complicated."
I said "obfuscated", didn't I?
" It's more complicated than your container library."
From an implementation standpoint, yes. (You're not talking about design
outside of the language/syntax domain are you?) Think about it this way: why
would I have created and evolved something else if I thought STL was "the
bomb"?
"* You don't accept the STL being part of the C++ standard
library as an advantage"
Oh, so it's an "acceptance" thing huh. Like Catholicism! (Been there, didn't
do that).
" even though obvious arguments for this position have been mentioned."
I "steal" the STL algorithms (well a few or some, my patterns work).
Apparently, any "obvious arguments" have not been retained in my mind so
please be so kind as to reiterate them in response here. (The way my mind
works: I evaluate and after I do, it either stays in my mind as
useful/relevant or goes to the trash bin. Nothing apparently has been said
that I didn't hear a dozen years ago).
"* You prefer some "void*-based" container design (whatever
that means)"
I think I corrected the person that said that such a design is not type
safe. Look at it from my perspective: every time I hear such stuff, I wonder
if they indeed don't know or if they are propagandizing/marketeering. I have
no way of knowing!
"* You said that the STL's performance advantage "probably
doesn't matter"."
In many instances, even container choice makes little difference.
Personally, I use a container that fits the problem even if "a simple array"
could do it more efficiently a lot of times. If I was developing genome
programs or such, I would probably choose the highest performing beast
available: STL (template-based gives high perf). I think that the concept of
one library that would span the needs of a programmer that needs to develop
utility programs in adjunct to network/system administration, to the
scientific programmer, a non-practical idea. Rogue-Wave and Borland both
went to "enterprise development". Did they "cave in" because of the C++ std
library? I know how companies evolve. And when the substance walks out the
door (and gets "let go"), the company stagnates to a period of
inter-management boom ("enterprise" sounds kinda fitting huh?).
You're a bit behind the current times though apparently: you are saying that
if one uses C++, then the std C++ library is the way to go. I don't think
C++ is the way to go and haven't for quite awhile. It has been a great
learning experience, but times have changed.
"This goes along with a lack of arguments and accusations à la
"Propaganda!", "You're a marketeer", "Bitch.", etc."
Now you know "the rest of the story". Still feel the same?
Tony
co...@mailvault.com
> "SG" <s.gesem...@gmail.com> wrote in message
>
> news:d768e33e-f3fe-437a...@z9g2000yqi.googlegroups.com...
> On 27 Mrz., 07:41, "Tony" <t...@my.net> wrote:
>
> > "Noah Roberts" <n...@nowhere.com> wrote in message
> > > Anyone can obfuscate a design in their implementation.
> > Cliches are like assholes.
>
> "Hello Tony,"
>
> No need to be formal (seesh).
>
> "it seems you don't have a lot to contribute to this (or any?)
> discussion."
>
> Give to receive. (Or is that too a cliche?).
>
> " I went through the trouble of reading all your posts in
> this thread and the thread "C++ is complicated" again and the only
> things that have stuck are:"
>
> ("only", as if you are omniscient).
>
> "* STL is supposedly complicated."
>
> I said "obfuscated", didn't I?
>
> " It's more complicated than your container library."
>
> From an implementation standpoint, yes. (You're not talking about design
> outside of the language/syntax domain are you?) Think about it this way: why
> would I have created and evolved something else if I thought STL was "the
> bomb"?
>
You remind me of "Le Chaud Lapin" on comp.lang.c++.moderated. He
goes on and on about his code, but doesn't ever publish it. I asked
him about that a couple years ago and he said he would in a year or
so. I don't know for sure, but I wouldn't be surprised if he hasn't
published anything yet. If you don't have a growing number of users
for your software, I don't think it will mature. I once thought the
STL was "the bomb," but have changed my mind now. In a number of
ways the containers in the Boost Intrusive library are better than
the STL. Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me.
> In many instances, even container choice makes little difference.
> Personally, I use a container that fits the problem even if "a simple array"
> could do it more efficiently a lot of times. If I was developing genome
> programs or such, I would probably choose the highest performing beast
> available: STL (template-based gives high perf).
I would use a combination of the Boost Intrusive containers and the
STL.
Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container.
>I think that the concept of
> one library that would span the needs of a programmer that needs to develop
> utility programs in adjunct to network/system administration, to the
> scientific programmer, a non-practical idea. Rogue-Wave and Borland both
> went to "enterprise development". Did they "cave in" because of the C++ std
> library? I know how companies evolve. And when the substance walks out the
> door (and gets "let go"), the company stagnates to a period of
> inter-management boom ("enterprise" sounds kinda fitting huh?).
>
> You're a bit behind the current times though apparently: you are saying that
> if one uses C++, then the std C++ library is the way to go. I don't think
> C++ is the way to go and haven't for quite awhile. It has been a great
> learning experience, but times have changed.
>
What do you suggest? Do tell.
zr
> Q What are the disadvantages of using STL ?
>
> Pallav Singh
Since no one mentioned it, what about code bloat? Is this still an
issue in recent implementations?
Noah Roberts
> On Mar 29, 12:09 am, "Tony" <t...@my.net> wrote:
>> In many instances, even container choice makes little difference.
>> Personally, I use a container that fits the problem even if "a simple array"
>> could do it more efficiently a lot of times. If I was developing genome
>> programs or such, I would probably choose the highest performing beast
>> available: STL (template-based gives high perf).
>
> I would use a combination of the Boost Intrusive containers and the
> STL.
> Boost Intrusive doesn't have anything like vector or deque so I'd use
> those where it made sense. In places where there is a choice between
> an STL container and a Boost Intrusive container, I'd favor using the
> Boost Intrusive container.
Obviously, nobody saying the STL is a useful tool nor that it exhibits
good design are saying it's the only C++ library that does, nor that
it's necessarily the best thing out there. I've yet to see a single
argument from those who are claiming it's, "too complex," that isn't
some variation of, "I looked at my compiler's implementation and didn't
understand it."
A lot of the boost stuff takes the ideas of STL and expands on them.
Some more than others. People complaining about the STL won't be
impressed by what they find in boost at all. For one thing, the amount
of hacks that have to go into boost in order to make it compatible with
non-standard compliant but important compilers is formidable in many
cases. For another thing, without some familiarity, or at least
willingness to become familiar, with these "academic" methods of design
and implementation that people are complaining about, boost is
completely undecipherable.
Jeff Schwab
The STL was designed originally by Alex Stepanov, not by committee.
Anyway, that's not a meaningful answer, just a cliche that reiterates
your opinion that standardization is inherently detrimental. Are you
saying that your dislike of STL is more philosophical than technical?
Jeff Schwab
It's never been a problem for me. If you do find that your performance
is suffering because of unnecessary icache misses, there are
straight-forward techniques to address the problem. (I've heard the old
technique of partially specializing for all raw pointer types, then
wrapping a non-template implementation that only uses void*, referred to
as "hoisting.")
Tony
<co...@mailvault.com> wrote in message
news:00938668-80f2-4ea3...@v15g2000yqn.googlegroups.com...
The name sounds familiar: he's "all over" threads and IP stacks, right?
"He
goes on and on about his code, but doesn't ever publish it. I asked
him about that a couple years ago and he said he would in a year or
so. I don't know for sure, but I wouldn't be surprised if he hasn't
published anything yet. If you don't have a growing number of users
for your software, I don't think it will mature."
Some of us have too much invested in blood, sweat and tears to divulge any
patentable thing or trade secret at the source code level. You said
"software" and "mature". Did you mean "source code"? Think about it this
way: given what is commonly known (the std library), and using that as just
a starting point, shouldn't you be considering that the std library is
"obsolete" given that many private, commercial and independent researches
have built or are building something else?
" I once thought the
STL was "the bomb," but have changed my mind now. In a number of
ways the containers in the Boost Intrusive library are better than
the STL. Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me."
Understood. I wasn't selling my approach/architecture/designs nor divulging
them. If it comes out sometimes, it's because it's where my mind is at and
what I'm doing (or if I'm in the groups I'm procrastinating, needing
sebatical or something similar...).
> In many instances, even container choice makes little difference.
> Personally, I use a container that fits the problem even if "a simple
> array"
> could do it more efficiently a lot of times. If I was developing genome
> programs or such, I would probably choose the highest performing beast
> available: STL (template-based gives high perf).
"I would use a combination of the Boost Intrusive containers and the
STL."
Everytime I visit the Boost site, I don't leave with anything that sticks in
my mind. They must be tailoring to "rocket scientific programming" or
something. (?). (rhetorical, start a new thread if you wanna promote/discuss
Boost).
"Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container."
It's been a long time since I've searched for commercial alternative
libraries (when it was just containers/iterators/algos it was easy?).
>I think that the concept of
> one library that would span the needs of a programmer that needs to
> develop
> utility programs in adjunct to network/system administration, to the
> scientific programmer, a non-practical idea. Rogue-Wave and Borland both
> went to "enterprise development". Did they "cave in" because of the C++
> std
> library? I know how companies evolve. And when the substance walks out the
> door (and gets "let go"), the company stagnates to a period of
> inter-management boom ("enterprise" sounds kinda fitting huh?).
>
> You're a bit behind the current times though apparently: you are saying
> that
> if one uses C++, then the std C++ library is the way to go. I don't think
> C++ is the way to go and haven't for quite awhile. It has been a great
> learning experience, but times have changed.
>
"What do you suggest? Do tell."
The preceding sentence of mine applies: search on the web for commercial
products, open source tends to have other agenda. You get what you pay for!
That of course must be a lie, because I took time out to (and am taking time
out to) develop from ground up, BUT with the the knowledge of what kind of
software I will build and with ability to do that. There used to be (in many
a "consulting company") a division of "developers": 3GL and 4GL where "4GL"
pretty much meant GUI builders in a point-n-click environment. I feel the
same way about the "blind" users of the std library. They are kinda like the
4GLers. I have other posts to catch up on, but I can map out the scenarios
like reading a book for the 10th time: "high level point n clicker wants to
be the head honcho on the project". Buying AutoCad does not make one an
architect or engineer or project manager. (</soapbox>, I guess). I don't
"suggest" or "give advice" because "I am not a lawyer"-type reasons. What
did I do? What am I doing? I'm building it from scratch. If "you're in the
top 10%", go for it, else consider ... whatever.
Tony
Tony
> co...@mailvault.com wrote:
>> On Mar 29, 12:09 am, "Tony" <t...@my.net> wrote:
>>> In many instances, even container choice makes little difference.
>>> Personally, I use a container that fits the problem even if "a simple
>>> array"
>>> could do it more efficiently a lot of times. If I was developing genome
>>> programs or such, I would probably choose the highest performing beast
>>> available: STL (template-based gives high perf).
>>
>> I would use a combination of the Boost Intrusive containers and the
>> STL.
>> Boost Intrusive doesn't have anything like vector or deque so I'd use
>> those where it made sense. In places where there is a choice between
>> an STL container and a Boost Intrusive container, I'd favor using the
>> Boost Intrusive container.
>
> Obviously, nobody saying the STL is a useful tool nor that it exhibits
> good design are saying it's the only C++ library that does, nor that it's
> necessarily the best thing out there. I've yet to see a single argument
> from those who are claiming it's, "too complex," that isn't some variation
> of, "I looked at my compiler's implementation and didn't understand it."
Or couldn't even SEE it? I'm currently reimplementing my string library (I
haven't touched it yet, but I have all the info now and it's my next "heads
down and code" task). I haven't had my nose in STL for quite some time, I
think I remember that string was a generalization of arrays? (I never looked
at STL string in detail, because I've always used my string: it was one of
the first things I did learning C++; COW and other stuff.... COW and other
stuff removed after assessing the target environments and threading issues).
C and C++ have a fundamentally wrong concept of "character string", IMO, so
how would I not consider that "complex" or any other such term to describe
how over-general thinking produces such monsters?
>
> A lot of the boost stuff takes the ideas of STL and expands on them. Some
> more than others. People complaining about the STL won't be impressed by
> what they find in boost at all.
I have seen a couple or a few things of paramount importance and much the
rest as highly-C++-specific and even domain-specific (the latter of which
would not be bad except that it is coded in "obfuscated" C++). I think that
a developer (not a commanded one on a project) should take care to avoid
language-isms to be forward-thinking, especially at the domain level (and of
course "domain" has vast range).
> For one thing, the amount of hacks that have to go into boost in order to
> make it compatible with non-standard compliant but important compilers is
> formidable in many cases. For another thing, without some familiarity, or
> at least willingness to become familiar, with these "academic" methods of
> design and implementation that people are complaining about, boost is
> completely undecipherable.
You need to explain "academic design", but it doesn't sound good right and
is probably appropriately named: for academic research.
Tony
zr
Do you mean that the client code of STL can workaround this problem? I
always thought that it is STL implementation dependant.