To STL or not to STL

Hi there,

I am interested to know if there are any C++ programmers who do not use STL.
I have been coding in C++ for a year or so now, although only recently have
I started a large(ish)-scale project. I do not use any STL, and I was
wondering if there are any others out there that program in C++ without
using STL? (Just to see if I am being stupid by not using it)

Thanks
Allan

--
Allan Bruce
Dept. of Computing Science
University of Aberdeen
Aberdeen AB24 3UE
Scotland, UK

Allan Bruce <allanmb@takeawayf2s.com> wrote:[color=blue]
> I am interested to know if there are any C++ programmers who do not use STL.[/color]

Can't speeak for the others by I certainly do not build all the general
purpose containers myself. Why should I?

Andre'

Allan Bruce <allanmb@takeawayf2s.com> spoke thus:
[color=blue]
> I am interested to know if there are any C++ programmers who do not use STL.
> I have been coding in C++ for a year or so now, although only recently have
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)[/color]

FWIW, the director of programming at my company is an old DOS h4x0r, and he
long ago wrote code that completely wraps/replaces (I can't say which...) the
STL. His reasoning is that the STL (std::vectors, particularly), didn't
behave like he wanted, and anyway he's a real "reinvent a better wheel" type
of guy.

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

Allan Bruce wrote:[color=blue]
>
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use STL.
> I have been coding in C++ for a year or so now, although only recently have
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)
>
> Thanks
> Allan
>[/color]
I'd say that the biggest group of programmers that don't use the
standard library would have to be those writing Windows apps using the
MFC library. Since MFC provides similar types of classes (strings,
containers), the majority of programmers that I know have little
knowledge of the standard library.

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message news:<bmlqta$4gb$1@news.freedom2surf.net>...[color=blue]
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use STL.
> I have been coding in C++ for a year or so now, although only recently have
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)[/color]

me. Because it slows down the compilation too much (I hate waiting..)

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message news:bmlqta$4gb$1@news.freedom2surf.net...[color=blue]
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use STL.[/color]

I'm assuming by STL we're talking about the standard C++ library (as opposed to
the old thing called the STL which precedes it).

If they never use it, they've got their head stuck some where.
[color=blue]
> I have been coding in C++ for a year or so now, although only recently have
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)
>[/color]
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.

"Christopher Benson-Manica" <ataru@nospam.cyberspace.org> wrote in message news:bmm46e$grp$3@chessie.cirr.com...
[color=blue]
> behave like he wanted, and anyway he's a real "reinvent a better wheel" type[/color]

What makes you think his reinvented wheel is better?
..

"Graeme Cogger" <graeme.coggerSPAMLESS@baesystems.com> wrote in message news:3F8E9AD7.8E13785E@baesystems.com...
[color=blue]
> I'd say that the biggest group of programmers that don't use the
> standard library would have to be those writing Windows apps using the
> MFC library. Since MFC provides similar types of classes (strings,
> containers), the majority of programmers that I know have little
> knowledge of the standard library.[/color]

The majority of people who think the world ends at the MFC boundary
perhaps. I wouldn't say a majority of C++ programmers.

Ron Natalie <ron@sensor.com> spoke thus:
[color=blue]
> What makes you think his reinvented wheel is better?[/color]

Nothing, necessarily. His philosophy is that he'd rather debug his own code
rather than someone else's. I think the main reason we don't use the STL is
that he started writing code 20 years ago, and back then I imagine his code
may very well have been superior to the STL. One advantage is that when I
want a "standard" class to do something different, I've got the implementor of
the class sitting two desks away, and in 10 minutes I have what I want. The
disadvantage, of course, is that should I find employment elsewhere, my new
boss probably will not be pleased that I know nothing about the standard
template library.

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

"Christopher Benson-Manica" <ataru@nospam.cyberspace.org> wrote in message news:bmmm1c$iet$2@chessie.cirr.com...[color=blue]
> Ron Natalie <ron@sensor.com> spoke thus:
>[color=green]
> > What makes you think his reinvented wheel is better?[/color]
>
> Nothing, necessarily. His philosophy is that he'd rather debug his own code
> rather than someone else's.[/color]

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=blue]
> I think the main reason we don't use the STL is
> that he started writing code 20 years ago, and back then I imagine his code
> may very well have been superior to the STL.[/color]

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=blue]
> The
> disadvantage, of course, is that should I find employment elsewhere, my new
> boss probably will not be pleased that I know nothing about the standard
> template library.[/color]

Absolutely, you'd have extreme difficulty with an interview here.

"Ron Natalie" <ron@sensor.com> wrote in message
news:3f8ec2de$0$69313$9a6e19ea@news.newshosting.co m...[color=blue]
>
> "Graeme Cogger" <graeme.coggerSPAMLESS@baesystems.com> wrote in message[/color]
news:3F8E9AD7.8E13785E@baesystems.com...[color=blue]
>[color=green]
> > I'd say that the biggest group of programmers that don't use the
> > standard library would have to be those writing Windows apps using the
> > MFC library. Since MFC provides similar types of classes (strings,
> > containers), the majority of programmers that I know have little
> > knowledge of the standard library.[/color]
>
> The majority of people who think the world ends at the MFC boundary
> perhaps. I wouldn't say a majority of C++ programmers.[/color]

I write quite a bit of Windows code myself, at first it was
only in C, but now moreso in C++. Guess what I use for string
handling, containers, and much of the i/o? Standard Library.
MFC? Ten-foot-pole, and all that. :-)

-Mike

"Ron Natalie" <ron@sensor.com> wrote in message
news:3f8ec298$0$69369$9a6e19ea@news.newshosting.co m...[color=blue]
>
> "Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message[/color]
news:bmlqta$4gb$1@news.freedom2surf.net...[color=blue][color=green]
> > Hi there,
> >
> > I am interested to know if there are any C++ programmers who do not use[/color][/color]
STL.[color=blue]
>
> I'm assuming by STL we're talking about the standard C++ library (as[/color]
opposed to[color=blue]
> the old thing called the STL which precedes it).
>
> If they never use it, they've got their head stuck some where.
>[color=green]
> > I have been coding in C++ for a year or so now, although only recently[/color][/color]
have[color=blue][color=green]
> > I started a large(ish)-scale project. I do not use any STL, and I was
> > wondering if there are any others out there that program in C++ without
> > using STL? (Just to see if I am being stupid by not using it)
> >[/color]
> Yes you are. If there is a feature supported by the library, you're[/color]
better[color=blue]
> off using it than rolling your own. They make things much simpler. For
> example, vector and string both have reasonable[/color]
copy/assignment/destruction[color=blue]
> behavior which means you don't have to sit there managing memory with new[/color]
and[color=blue]
> delete.[/color]

Also IMO equally important, not only is the code portable to
other platforms without all the 'hand rolled' baggage, but it's
also 'comprehension portable'. Any good C++ programmer recognizes
e.g. std::vector<std::string> as quickly and readily as he does
e.g. a 'for' loop.

One might compare this concept with e.g. the consistent sizes,
shapes, and colors of various types of road signs as in the
U.S., IMO a Good Thing(tm). "Everybody knows what they mean."

Who needs to pause to actually *read* the word "stop" on a
stop-sign? A red and white octagon at an intersection immediately
conveys the message, allowing one to focus on other important
things, such as keeping an eye on that child on a bicycle riding
on the shoulder.

Those little rascals are just like program bugs, they'll dart
out in front of you with no warning. (Happened to me this morning,
that's what evoked the analogy.) Other than being a bit rattled
by the tire screech and my scolding, he's OK. :-)

-Mike

Mike Wahler wrote:[color=blue]
>
>
> Also IMO equally important, not only is the code portable to
> other platforms without all the 'hand rolled' baggage, but it's
> also 'comprehension portable'. Any good C++ programmer recognizes
> e.g. std::vector<std::string> as quickly and readily as he does
> e.g. a 'for' loop.
>
> One might compare this concept with e.g. the consistent sizes,
> shapes, and colors of various types of road signs as in the
> U.S., IMO a Good Thing(tm). "Everybody knows what they mean."
>[/color]

Aaahhhh. You mean the white "PED XING" painted on the street :-)
I had quite a funny time figuring out what that could mean when
visiting the US the first time. (Keep in mind: I am not a native
english speaker)

--
Karl Heinz Buchegger
kbuchegg@gascad.at

Allan Bruce wrote:[color=blue]
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use STL.
> I have been coding in C++ for a year or so now, although only recently have
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)
>[/color]

We don't use the standard library. Because when the decision
to move to C++ was made in 1990 the standard library didn't
exist. Most compilers didn't support templates, and as they
became available they was buggy, poorly implemented and non
standard across different platforms. Basically you couldn't
write a portable system that used templates.

Lists, sets, vectors, maps, strings, smart pointers etc were
developed in-house using the generic macros that were the
forerunners to templates. By the time the standard library
was stable enough to use, we had our own variants that had
been used throughout the company for a number of years.

If we were starting out today then we would use the standard
library, but currently there is no incentive to use the
standard library when our own variant already does the job.

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message news:<bmlqta$4gb$1@news.freedom2surf.net>...
[to STL or not as the subject says]

Think of it this way:
- The STL is available to anybody with a recent C++ compiler.
- The STL is far more likely to be transportable than any code
you write to replace it.
- The STL is documented in several very good texts.
- The previous includes how to make the STL peform efficiently
in very many common situations and applications.
- Also included is how to choose the right container for the job.
- Also included are many considerations on how to avoid trouble,
what contained objects are required to do or provide, how to
debug trouble, how to instrument things to see how things are
doing, how to prevent resource leaks, etc. etc.
- There are several good places to discuss the STL with experts,
one such place being here.
- There is an absolute boatload of available examples in STL.
- There are many experienced STL users. New team members are likely
to already be experienced with STL.
- There are web sites that compare compilers based on, among other
things, how well they implement the STL.
- Learning the STL, and learning it well, is likely to make you a
more attractive member of future development teams.

So, if you hack together some cobbled kludge to replace the STL:
- You won't find any examples.
- You will have to provide your own documentation.
- You won't get much help from experts.
- If you want to hire somebody to help on your project, you will
have to train them up in your hacked kludge.
- If it runs slowly, you won't get help on making it faster.
- If you have memory leaks, space issues, etc., there won't be
any articles in magazines to help you.
- Your experience with this hack is unlikely to make you a more
attractive member of future software development teams.

In other words, this is one of those cases where standardization
is a very good thing. As somebody else said, the only reason not
to use the STL would be if you were handed an existing library
that provided all the functionality you needed. For example,
MFC based apps might not use the STL. Though I usually do anyway,
on those occasions I write an MFC app.
Socks

Mike Wahler wrote:[color=blue]
> MFC? Ten-foot-pole, and all that. :-)[/color]

What does that mean?

--
WW aka Attila he Englishly challenged :-)

Karl Heinz Buchegger wrote:[color=blue]
> Aaahhhh. You mean the white "PED XING" painted on the street :-)
> I had quite a funny time figuring out what that could mean when
> visiting the US the first time.[/color]

Cross your legs? ;-)

--
WW aka Attila

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3F8EE708.BAF9DD32@gascad.at...[color=blue]
>
> Mike Wahler wrote:[color=green]
> >
> > Also IMO equally important, not only is the code portable to
> > other platforms without all the 'hand rolled' baggage, but it's
> > also 'comprehension portable'. Any good C++ programmer recognizes
> > e.g. std::vector<std::string> as quickly and readily as he does
> > e.g. a 'for' loop.
> >
> > One might compare this concept with e.g. the consistent sizes,
> > shapes, and colors of various types of road signs as in the
> > U.S., IMO a Good Thing(tm). "Everybody knows what they mean."[/color]
>
> Aaahhhh. You mean the white "PED XING" painted on the street :-)[/color]

As I'm sure you've figured out by now, that's "Pedestrian
Crossing." But those are usually only found in the more
urban or suburban areas. "Stop signs" appear at any intersection
without electric light signals, urban area or not (with some
exceptions, e.g. "Yield" signs on lower traffic roads, again
with a standard color and shape -- yellow triangle.) Both
those types of sign, and many others, also often appear on
the bedroom doors or walls of juvenile delinquents. :-)

[End of driving lesson.] :-)
[color=blue]
> I had quite a funny time figuring out what that could mean when
> visiting the US the first time. (Keep in mind: I am not a native
> english speaker)[/color]

It means "Don't Zing the Peds" :-)

My mother recounted many such comprehension 'adventures'
during her six-month stay in Paris. (And she had taken
two years of French lessons in preparation for the trip. :-))

-Mike

Hi,

STL. It's fast to code, it is fast code.

A few reasons and examples from real life:

Even today just 1.5 hour before I would left work, a colleage came over he
had to figure out what records had been sent to another system. Now I'm
talking about millions of records. After figuring out that the first 30
characters for the where unique. I created a program with a set (this sorted
automatically so it can do a binary search), corrected headers and footers
in the file. I was finished with testing the program actually in 1.5 hours
(including the little research for uniqueness, creating the numbers file
etc.) Debugging time was nearly zero (ok, I forget about the headers at one
time). I was surprised about the speed myself since it had to do a lookup in
about 40 megabyte of data loaded in the set.

I have programmed in pure C and this would have taken a lot longer than
this.

I have never encountered a bug in the STL (and I use it all the time).

Sure, it does take a while before you get used to using it. But once you do
you will program faster than anyone in plain C. Not only that, I at
sometime, compared 20 lines of code almost entirely of STL stuff (with the
SGI hash_map) with someone else highly optimized C code of three pages long
(it performed the same function). I talked to him how much microseconds his
lookups took because I was very curious about that. The answer he gave was
nearly the same as I had (I believe it was something like 45 and 47), but I
am quite sure that coding 20 lines take less time than 3 pages of code not
to mention the latter takes more time to read and to debug.

At some time I had to maintain a program without manuals but with a lot of
code. I wondered how to get it up in case it would crash (management decided
no backups since the data was expendible). I read through the code, since
they used the STL a lot, this was reasonably to do. It would have been much
more difficult if I would have to dig through three times the code necessary
to acomplish the same without the STL.

Therefore I would say use and or learn STL, you will do yourself and others
a favor (and you look up to date with your C++ knowledge).

http://www.sgi.com/tech/stl/

Regards, Ron AF Greve

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message
news:bmlqta$4gb$1@news.freedom2surf.net...[color=blue]
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use[/color]
STL.[color=blue]
> I have been coding in C++ for a year or so now, although only recently[/color]
have[color=blue]
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)
>
> Thanks
> Allan
>
> --
> Allan Bruce
> Dept. of Computing Science
> University of Aberdeen
> Aberdeen AB24 3UE
> Scotland, UK
>
>[/color]

"WW" <wolof@freemail.hu> wrote in message
news:bmmsmr$nrn$1@phys-news1.kolumbus.fi...[color=blue]
> Mike Wahler wrote:[color=green]
> > MFC? Ten-foot-pole, and all that. :-)[/color]
>
> What does that mean?[/color]

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. :-))

-Mike

Mike Wahler wrote:[color=blue]
> "WW" <wolof@freemail.hu> wrote in message
> news:bmmsmr$nrn$1@phys-news1.kolumbus.fi...[color=green]
>> Mike Wahler wrote:[color=darkred]
>>> MFC? Ten-foot-pole, and all that. :-)[/color]
>>
>> What does that mean?[/color]
>
> 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. :-)

--
WW aka Attila

WW <wolof@freemail.hu> spoke thus:
[color=blue]
> Mike Wahler wrote:[color=green]
>> MFC? Ten-foot-pole, and all that. :-)[/color][/color]
[color=blue]
> What does that mean?[/color]

Heh... in English, there is a phrase "I wouldn't touch ____ with a ten-foot
pole," meaning one wishes to stay as far away from ___ (whether ___ is a
particularly nasty person, situation, a grizzly bear, or MFC). FWIW, if I had
a ten-foot pole, I'd probably use it to bludgeon Bill Gates ;)

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

"Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message
news:bmlqta$4gb$1@news.freedom2surf.net...[color=blue]
> Hi there,
>
> I am interested to know if there are any C++ programmers who do not use[/color]
STL.[color=blue]
> I have been coding in C++ for a year or so now, although only recently[/color]
have[color=blue]
> I started a large(ish)-scale project. I do not use any STL, and I was
> wondering if there are any others out there that program in C++ without
> using STL? (Just to see if I am being stupid by not using it)[/color]

Well, I think I'd get pretty tired of constantly reinventing the wheel.
Depending on the project I've used Microsoft MFC, or Rogue Wave library, or
STL, etc. So if you don't use STL, I hope you're at *least* using *some*
library that at *least* gives you a string :-)

"Moonlit" <alt.spam@jupiter.universe> wrote in message
news:3f8ef7f6$0$58713$e4fe514c@news.xs4all.nl...[color=blue]
>
> 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?

Hi,

"jeffc" <nobody@nowhere.com> wrote in message
news:3f8f1e3d_2@news1.prserv.net...[color=blue]
>
> "Moonlit" <alt.spam@jupiter.universe> wrote in message
> news:3f8ef7f6$0$58713$e4fe514c@news.xs4all.nl...[color=green]
> >
> > 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.

Ok, at some time hash_map's didn't seem to be supported by the g++ compiler,
you can still download the files from sgi

Regards, Ron AF Greve.[color=blue]
>
>[/color]

"Ron Natalie" <ron@sensor.com> wrote in message news:<3f8ec298$0$69369$9a6e19ea@news.newshosting.c om>...[color=blue]
> 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.

Sam

"Moonlit" <alt.spam@jupiter.universe> wrote in message news:3f8f20c9$0$58715$e4fe514c@news.xs4all.nl...
[color=blue]
> Ok, at some time hash_map's didn't seem to be supported by the g++ compiler,
> you can still download the files from sgi
>[/color]
hash-maps are NOT part of the C++ standard library.

I've encountered bugs in the STL, but as of late, I've been able to live with them.

"Samuel Barber" <opendtv@yahoo.com> wrote in message news:37991aef.0310161457.37f35adf@posting.google.c om...[color=blue]
> "Ron Natalie" <ron@sensor.com> wrote in message news:<3f8ec298$0$69369$9a6e19ea@news.newshosting.c om>...[color=green]
> > 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).

"Ron Natalie" <ron@sensor.com> wrote in message
news:3f8f2519$0$161$9a6e19ea@news.newshosting.com. ..[color=blue]
>
> "Moonlit" <alt.spam@jupiter.universe> wrote in message[/color]
news:3f8f20c9$0$58715$e4fe514c@news.xs4all.nl...[color=blue]
>[color=green]
> > Ok, at some time hash_map's didn't seem to be supported by the g++[/color][/color]
compiler,[color=blue][color=green]
> > you can still download the files from sgi
> >[/color]
> hash-maps are NOT part of the C++ standard library.[/color]

100% percent correct. That's why I said you can still download them from
SGI.

At one time they where supported by the g++ compiler. If you think you are
not able to compile your old code you can still download them from the SGI
site.

Apart from that there really is no reason to NOT use the STL. The code is
faster than you write it yourself (if you have something even faster post it
here, please!) not to mention it takes very little effort to write. Just
follow the postings in this newsgroup and you know that if you would like to
use C++ you sure want to use the STL.

Regards, Ron AF Greve

"WW" <wolof@freemail.hu> wrote in message news:<bmmtn4$raq$1@phys-news1.kolumbus.fi>...[color=blue]
> Mike Wahler wrote:[color=green]
> > "WW" <wolof@freemail.hu> wrote in message
> > news:bmmsmr$nrn$1@phys-news1.kolumbus.fi...[color=darkred]
> >> Mike Wahler wrote:
> >>> MFC? Ten-foot-pole, and all that. :-)
> >>
> >> What does that mean?[/color]
> >
> > 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?

--
JB, the Magyar-challenged ;-)

"Ron Natalie" <ron@sensor.com> wrote in message news:<3f8f2572$0$182$9a6e19ea@news.newshosting.com >...[color=blue]
> "Samuel Barber" <opendtv@yahoo.com> wrote in message news:37991aef.0310161457.37f35adf@posting.google.c om...[color=green]
> > "Ron Natalie" <ron@sensor.com> wrote in message news:<3f8ec298$0$69369$9a6e19ea@news.newshosting.c om>...[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

> > > > 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.

Moonlit wrote:[color=blue]
>
> Hi,
>
> "jeffc" <nobody@nowhere.com> wrote in message
> news:3f8f1e3d_2@news1.prserv.net...[color=green]
> >
> > "Moonlit" <alt.spam@jupiter.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

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

Hi,

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3F8FA731.9DB2B8CA@gascad.at...[color=blue]
>
>
> Moonlit wrote:[color=green]
> >
> > Hi,
> >
> > "jeffc" <nobody@nowhere.com> wrote in message
> > news:3f8f1e3d_2@news1.prserv.net...[color=darkred]
> > >
> > > "Moonlit" <alt.spam@jupiter.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]

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

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3F8FD025.47FE8D41@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]

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

"Moonlit" <alt.spam@jupiter.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.

"Moonlit" <alt.spam@jupiter.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.

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.

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)cyberspace.org | don't, I need to know. Flames welcome.

To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

re: To STL or not to STL

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about