To STL or not to STL

[Samuel Barber]

Re: To STL or not to STL

"Ron Natalie" <ron@sensor.com > wrote in message news:<3f8f2572$ 0$182$9a6e19ea@ news.newshostin g.com>...[color=blue]
> "Samuel Barber" <opendtv@yahoo. com> wrote in message news:37991aef.0 310161457.37f35 adf@posting.goo gle.com...[color=green]
> > "Ron Natalie" <ron@sensor.com > wrote in message news:<3f8ec298$ 0$69369$9a6e19e a@news.newshost ing.com>...[color=darkred]
> > > Yes you are. If there is a feature supported by the library, you're better
> > > off using it than rolling your own. They make things much simpler. For
> > > example, vector and string both have reasonable copy/assignment/destruction
> > > behavior which means you don't have to sit there managing memory with new and
> > > delete.[/color]
> >
> > Read up on "move constructors" and you might change your opinion of
> > what is reasonable behavior.[/color]
>
> That's a different issue. I'm talking about the copying and destruction of the
> container itself (rather than the contained object).[/color]

What's so wonderful about that? Usually, programmers go to great
lengths to avoid copying containers. C++ makes it all too easy to
write elegant code which is grossly inefficient, due to implicit
copying of large objects.

Sam

[Tõnu Aas]

Re: To STL or not to STL

> > > > Yes you are. If there is a feature supported by the library,
you're better[color=blue][color=green][color=darkred]
> > > > off using it than rolling your own. They make things much simpler.
> > > Read up on "move constructors" and you might change your opinion of
> > > what is reasonable behavior.[/color][/color][/color]
[color=blue][color=green]
> > That's a different issue. I'm talking about the copying and destruction[/color][/color]
of the[color=blue][color=green]
> > container itself (rather than the contained object).[/color][/color]
[color=blue]
> What's so wonderful about that? Usually, programmers go to great
> lengths to avoid copying containers. C++ makes it all too easy to
> write elegant code which is grossly inefficient, due to implicit
> copying of large objects.[/color]
[color=blue]
> ? > What makes you think his reinvented wheel is better?[/color]

There are so many "wheel inventers". Ask yourself why.
And the best answer is: "STL makes it too easy to write elegant code which
is grossly inefficient" (not C++)

So are people inventing "wheels" like intrusive containers and so on.
Its strange that programmers are so happy with STL and just buy new computer
and
add xxxGB memory into it.

Second myth - portability - isnt so good also. If you live on windows
plaform only, then its o.k.,
but if you are not using main path, then you are in trouble.

Tõnu.

[Karl Heinz Buchegger]

Re: To STL or not to STL



Moonlit wrote:[color=blue]
>
> Hi,
>
> "jeffc" <nobody@nowhere .com> wrote in message
> news:3f8f1e3d_2 @news1.prserv.n et...[color=green]
> >
> > "Moonlit" <alt.spam@jupit er.universe> wrote in message
> > news:3f8ef7f6$0 $58713$e4fe514c @news.xs4all.nl ...[color=darkred]
> > >
> > > I have never encountered a bug in the STL (and I use it all the time).[/color]
> >
> > Isn't that kind of like saying you've never encountered a bug in the C++
> > language?[/color]
>
> Nope!
>
> That's kind of saying I never encountered a bug in the STL (as I said).[/color]

jeffc ment: You didn't encounter a bug in the 'STL implementation you use'.


--
Karl Heinz Buchegger
kbuchegg@gascad .at

[WW]

Re: To STL or not to STL

JB wrote:[color=blue][color=green][color=darkred]
>>>>> MFC? Ten-foot-pole, and all that. :-)
>>>>
>>>> What does that mean?
>>>
>>> A colloquialism (I don't know the origin). Referring to
>>> something or someone considered undesirable, "I wouln't
>>> touch that with a ten-foot-pole." Meaning essentially
>>> "I would not touch that, or even go within ten feet of it."
>>> (about three metres to you. :-))[/color]
>>
>> Ah, OK. It is like the bone on the neck thing, then. :-)[/color]
>
> Bone on the neck?[/color]

Another joke thing. He is so ugly, his parents hung a bone on a string on
his neck so at least the dogs will play with him.

--
WW aka Attila

[Moonlit]

Re: To STL or not to STL

Hi,

"Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
news:3F8FA731.9 DB2B8CA@gascad. at...[color=blue]
>
>
> Moonlit wrote:[color=green]
> >
> > Hi,
> >
> > "jeffc" <nobody@nowhere .com> wrote in message
> > news:3f8f1e3d_2 @news1.prserv.n et...[color=darkred]
> > >
> > > "Moonlit" <alt.spam@jupit er.universe> wrote in message
> > > news:3f8ef7f6$0 $58713$e4fe514c @news.xs4all.nl ...
> > > >
> > > > I have never encountered a bug in the STL (and I use it all the[/color][/color][/color]
time).[color=blue][color=green][color=darkred]
> > >
> > > Isn't that kind of like saying you've never encountered a bug in the[/color][/color][/color]
C++[color=blue][color=green][color=darkred]
> > > language?[/color]
> >
> > Nope!
> >
> > That's kind of saying I never encountered a bug in the STL (as I said).[/color]
>
> jeffc ment: You didn't encounter a bug in the 'STL implementation you[/color]
use'.[color=blue]
>
>[/color]
What I meant with that sentence is; That if you write your own code, which
would implement the same functionality, you likely would spend a lot of time
debugging (unless you are some miracle coder of course). Since the STL is
already used by so many people it has been thoroughly tested (of course this
is true for any piece of code that is used by many people). I didn't say
there are no bugs in any implementation, I just say I didn't encountered any
and use it a lot mostly g++ but in VC++ too.

Regards, Ron AF Greve

[color=blue]
> --
> Karl Heinz Buchegger
> kbuchegg@gascad .at[/color]

[Karl Heinz Buchegger]

Re: To STL or not to STL



Moonlit wrote:[color=blue]
>
> What I meant with that sentence is; That if you write your own code, which
> would implement the same functionality, you likely would spend a lot of time
> debugging (unless you are some miracle coder of course). Since the STL is
> already used by so many people it has been thoroughly tested (of course this
> is true for any piece of code that is used by many people). I didn't say
> there are no bugs in any implementation, I just say I didn't encountered any
> and use it a lot mostly g++ but in VC++ too.
>[/color]

You didn't get it.
The STL, just like C++, is just a specification. Of course you can't
find bugs in it. You may find inconsitencies in the descriptions of
what the functions and objects should do, but certainly not bugs.
Bugs are reserved for implementations .
jeffc's argumentation is on the level of correct usage of english language.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Moonlit]

Re: To STL or not to STL


"Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
news:3F8FD025.4 7FE8D41@gascad. at...[color=blue]
>
>
> Moonlit wrote:[color=green]
> >
> > What I meant with that sentence is; That if you write your own code,[/color][/color]
which[color=blue][color=green]
> > would implement the same functionality, you likely would spend a lot of[/color][/color]
time[color=blue][color=green]
> > debugging (unless you are some miracle coder of course). Since the STL[/color][/color]
is[color=blue][color=green]
> > already used by so many people it has been thoroughly tested (of course[/color][/color]
this[color=blue][color=green]
> > is true for any piece of code that is used by many people). I didn't say
> > there are no bugs in any implementation, I just say I didn't encountered[/color][/color]
any[color=blue][color=green]
> > and use it a lot mostly g++ but in VC++ too.
> >[/color]
>
> You didn't get it.
> The STL, just like C++, is just a specification. Of course you can't
> find bugs in it. You may find inconsitencies in the descriptions of
> what the functions and objects should do, but certainly not bugs.
> Bugs are reserved for implementations .
> jeffc's argumentation is on the level of correct usage of english[/color]
language.

Nope you don't get it. The abbreviation also referres to any STL
implementation as well. And if you see them I am talking about bugs you
should have known that I was referring to any STL implementation.

If you donwload the standard template library from the sgi site, you are not
downloading the specs but the implementation.

Period.

Regards, Ron AF Greve.[color=blue]
>
> --
> Karl Heinz Buchegger
> kbuchegg@gascad .at[/color]

[Karl Heinz Buchegger]

Re: To STL or not to STL



Moonlit wrote:[color=blue]
>[/color]
[color=blue]
> Nope you don't get it. The abbreviation also referres to any STL
> implementation as well. And if you see them I am talking about bugs you
> should have known that I was referring to any STL implementation.[/color]

Interesting.
So when saying: You didn't find any bugs in the STL, you are referring
to any (but no specific) STL implementation.
[color=blue]
>
> If you donwload the standard template library from the sgi site, you are not
> downloading the specs but the implementation.[/color]

I am downloading a specific STL. But unless I mention which one
in specific, the phrase 'bugs in STL' has no meaning.

'I found some bugs in sgi's implementation of STL' has a meaning

'I found no bugs in Dinkumware's STL' has a meaning

'I didn't find bugs in all STL implementations I used up to know' has a meaning

'I found a bug in the STL' has *no* meaning. What is *THE STL*? Who made it?
Where can I get more information about that? *The STL* is just a stack of papers.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[jeffc]

Re: To STL or not to STL


"Moonlit" <alt.spam@jupit er.universe> wrote in message
news:3f8f20c9$0 $58715$e4fe514c @news.xs4all.nl ...[color=blue][color=green][color=darkred]
> > >
> > > I have never encountered a bug in the STL (and I use it all the time).[/color]
> >
> > Isn't that kind of like saying you've never encountered a bug in the C++
> > language?[/color]
>
> Nope!
>
> That's kind of saying I never encountered a bug in the STL (as I said).
>
> Still, I didn't say there isn't any bug in the STL, I just say I haven't
> encountered any, despite I have used it for many years.[/color]

No, you haven't used the "STL", you've used a particular implementation of
it. That's *like* saying you've used a particular implementation of C++.
People don't find bugs in C++, they find bugs in C++ compilers.

[jeffc]

Re: To STL or not to STL


"Moonlit" <alt.spam@jupit er.universe> wrote in message
news:3f8fe486$0 $58707$e4fe514c @news.xs4all.nl ...[color=blue]
>
> Nope you don't get it. The abbreviation also referres to any STL
> implementation as well. And if you see them I am talking about bugs you
> should have known that I was referring to any STL implementation.[/color]

Your statement that you haven't found any bugs in STL is meaningless unless
you've used every STL implementation. It's like saying you've never found
any bugs in C++ and oh by the way, you've written programs only for the
Bombastic 2000 compiler. It doesn't make any sense. What you mean is you
haven't found any bugs in g++ or VC++, although you haven't used VC++ much.

[lilburne]

Re: To STL or not to STL

Samuel Barber wrote:
[color=blue]
>
> What's so wonderful about that? Usually, programmers go to great
> lengths to avoid copying containers. C++ makes it all too easy to
> write elegant code which is grossly inefficient, due to implicit
> copying of large objects.
>[/color]

Some guidelines make copy constructors and assignment
operators private, to avoid such problems. Instead the
recommendation is to have explicit methods on the class that
have to be called.

[Christopher Benson-Manica]

Re: To STL or not to STL

Ron Natalie <ron@sensor.com > spoke thus:

[color=blue]
> My philosophy is that the standard library is usually already debugged. Certainly
> any bugs in it are much easier to deal with than reimplementing it and debugging
> and providing ongoing support for an equivelent amout of code.[/color]

Not so much in the STL (since he never uses it...), but in other code
libraries, he's had to "roll his own" since it was completely impossible to
get what he wanted otherwise. For example (if you'll excuse my venture into
OT territory...), Microsoft and Borland have facilities for dealing with dates
and times, but apparently they just don't work right for our purposes.
[color=blue]
> That is true. C++ wasn't really usable more than about 10 years ago. I've been
> programming in C since 1977. Times change. He needs to shed his antiquated
> belief systems. Many people who transition to C++ suffer from this brain damage.[/color]

Quite possibly, although that's not really one can say to one's boss ;) At
this point, he's really already done all the work anyway, so from his
perspective his code is superior, since he doesn't have to learn how to use
it (as he might with the STL).
[color=blue]
> Absolutely, you'd have extreme difficulty with an interview here.[/color]

I may have to invest some time in self-teaching myself, since I don't imagine
I'll be working here for the next 40 years. The problem I always have is
finding some meaningful task to accomplish - I've never been able to just read
a book and get anything useful out of it, or even do silly little tutorial
programs and get anything out of them. What to do...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.