«

I am familiar with using STL, including the algorithm and the
containers,
however, how they are implemented. Some of my friends recommend me to
read
the source code of STL directly.

I download the SGI STL source code, which contains nearly 40 thousand
lines. As far as I am concerned, it is a big project. And like other
big
projects, I have no ideas where to begin to start with, and what to do
with
it during the learning process.

I am a ungraduate student, hoping some of you could give me some
advice,
and I will keep it up.

Thanks in advance.

Stanley Rice <> wrote:
> Some of my friends recommend me to read
> the source code of STL directly.

Really bad advice. You should read a good book about the standard
library instead.

(It's bad advice because reading someone else's uncommented and
obfuscated code (the standard library is full of variables and names
starting with __ which makes it hard to read) is one of the hardest
ways of learning anything. You *could* potentially learn something,
but if you value your time and sanity, there are much easier and
efficient ways of doing that.)

On Feb 17, 8:18*am, Stanley Rice <hecong...@gmail.com> wrote:
> I am familiar with using STL, including the algorithm and the
> containers,
> however, how they are implemented. Some of my friends recommend me to
> read
> the source code of STL directly.

Reading is too dry. Try debugging through it. Start with the simplest
of things, like for_each, vector:ush_back, list:ush_front. Just
make simplest of programs, e.g.

int main()
{
std::vector<char> v;
v.push_back('a');
}

and go through with the debugger.

In the beginning, it will be difficult, because you will need to learn
to see through the cruft that's inside. Typically, you'll see a lot of
code whose sole purpose is to aid debugging. You'll need to learn to
ignore that. You will also see bizarre variable naming. Live with it.
Variable naming in STL is subject to different considerations than
your or mine code .

Goran.

On Feb 17, 3:29*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Stanley Rice <hecong...@gmail.com> wrote:
> > Some of my friends recommend me to read
> > the source code of STL directly.
>
> * Really bad advice. You should read a good book about the standard
> library instead.

There is a book name Standard C Library written by plaug, which is
similar
to the souce code of C library. But It seems that no book related with
the
source code of standary C++ libary is published as I know. By the
way,
can you recommend me some books that you consider is good.?

>
> * (It's bad advice because reading someone else's uncommented and
> obfuscated code (the standard library is full of variables and names
> starting with __ which makes it hard to read) is one of the hardest
> ways of learning anything. You *could* potentially learn something,
> but if you value your time and sanity, there are much easier and
> efficient ways of doing that.)
Maybe you are right though someone told me that it is a *good* way
to learn some language by reading others' code. I am eager to know
the easier and more efficient way to do that. Please.

On Feb 17, 7:29*am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Stanley Rice <hecong...@gmail.com> wrote:

> > Some of my friends recommend me to read
> > the source code of STL directly.

I don't think they are really your friends...

> * Really bad advice. You should read a good book about the standard
> library instead.

Jossutis for instance. I'm not sure if there anything covering the
latest standard.

> * (It's bad advice because reading someone else's uncommented and
> obfuscated code (the standard library is full of variables and names
> starting with __ which makes it hard to read) is one of the hardest
> ways of learning anything. You *could* potentially learn something,
> but if you value your time and sanity, there are much easier and
> efficient ways of doing that.)

On Feb 17, 8:56*am, Stanley Rice <hecong...@gmail.com> wrote:
> On Feb 17, 3:29*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> > Stanley Rice <hecong...@gmail.com> wrote:

> > > Some of my friends recommend me to read
> > > the source code of STL directly.
>
> > * Really bad advice. You should read a good book about the standard
> > library instead.
>
> There is a book name Standard C Library written by plaug[er], which is
> similar to the souce code of C library.

ITYM "similar to /a/ source code of C library"

The point is neither C nor C++ have a model implementaion of the
standard library. Tell your friends as they don't seem to be aware of
this either.

> But It seems that no book related with
> the source code of standary C++ libary is published as I know.

actually Plauger wrote one. But unfortunatly he anticipated the
standard and they redesigned the library so obsoleting his book.

> By the
> way, can you recommend me some books that you consider is good.?

Jossutis and "More Effective STL" (or something like that)

> > * (It's bad advice because reading someone else's uncommented and
> > obfuscated code (the standard library is full of variables and names
> > starting with __ which makes it hard to read) is one of the hardest
> > ways of learning anything. You *could* potentially learn something,
> > but if you value your time and sanity, there are much easier and
> > efficient ways of doing that.)
>
> Maybe you are right though someone told me that it is a *good* way
> to learn some language by reading others' code. I am eager to know
> the easier and more efficient way to do that. Please.

but not the standard library. If you want to know what the library
does read the documentation. There are some web sites around that
aren't bad.

On Feb 17, 7:36*am, Goran <goran.pu...@gmail.com> wrote:
> On Feb 17, 8:18*am, Stanley Rice <hecong...@gmail.com> wrote:
>
> > I am familiar with using STL, including the algorithm and the
> > containers,
> > however, how they are implemented. Some of my friends recommend me to
> > read
> > the source code of STL directly.
>
> Reading is too dry.

nonsense!

> Try debugging through it.

yuck!

> Start with the simplest
> of things, like for_each, vector:ush_back, list:ush_front. Just
> make simplest of programs, e.g.
>
> int main()
> {
> * std::vector<char> v;
> * v.push_back('a');
>
> }
>
> and go through with the debugger.
>
> In the beginning, it will be difficult, because you will need to learn
> to see through the cruft that's inside. Typically, you'll see a lot of
> code whose sole purpose is to aid debugging. You'll need to learn to
> ignore that. You will also see bizarre variable naming. Live with it.
> Variable naming in STL is subject to different considerations than
> your or mine code .

or you could try poking your own eyes out

On Feb 17, 10:12*am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Feb 17, 7:36*am, Goran <goran.pu...@gmail.com> wrote:
>
> > On Feb 17, 8:18*am, Stanley Rice <hecong...@gmail.com> wrote:
>
> > > I am familiar with using STL, including the algorithm and the
> > > containers,
> > > however, how they are implemented. Some of my friends recommend me to
> > > read
> > > the source code of STL directly.
>
> > Reading is too dry.
>
> nonsense!
>
> > Try debugging through it.
>
> yuck!
>
>
>
>
>
>
>
>
>
> > Start with the simplest
> > of things, like for_each, vector:ush_back, list:ush_front. Just
> > make simplest of programs, e.g.
>
> > int main()
> > {
> > * std::vector<char> v;
> > * v.push_back('a');
>
> > }
>
> > and go through with the debugger.
>
> > In the beginning, it will be difficult, because you will need to learn
> > to see through the cruft that's inside. Typically, you'll see a lot of
> > code whose sole purpose is to aid debugging. You'll need to learn to
> > ignore that. You will also see bizarre variable naming. Live with it.
> > Variable naming in STL is subject to different considerations than
> > your or mine code .
>
> or you could try poking your own eyes out

I find that watching code unroll in the debugger is a great way of
learning what code does. Even more so when it's about usual STL
implementations code.

I don't get your excitement. It's not very elaborate either .

Goran.

Stanley Rice <> wrote:
> someone told me that it is a *good* way
> to learn some language by reading others' code.

I don't understand where that misconception comes from. It's an extremely
naive concept that is probably spouted mostly by people without actual
expertise in programming.

A program is the implementation of the solution to a problem. Seeing
only the program, without any explanation of it, it's usually very hard
to understand what exactly is the solution it's implementing, or even to
which problem. If the program is well commented (which is an utter rarity)
it might help some, but it's still hard.

Even more importantly, a program is a *particular solution* to a more
generic problem. You would be learning *that particular solution* rather
than the generic principle behind it. This could, at worse, lead to
cargo cult programming, where you blindly use a programming technique
in situations where it's not at all well suited, without understanding
the theory behind that particular solution.

And this is all assuming that the program is good and competently made.
That, in itself, is also a rare happenstance. If the program you are reading
happens to be pure crap, you might be learning bad habits and the wrong ways
of doing things. (Granted, the standard library is probably significantly
more competently implemented than your average C++ program, but still.)

On Feb 17, 11:57*am, Goran <goran.pu...@gmail.com> wrote:
> On Feb 17, 10:12*am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > On Feb 17, 7:36*am, Goran <goran.pu...@gmail.com> wrote:
> > > On Feb 17, 8:18*am, Stanley Rice <hecong...@gmail.com> wrote:


> > > > I am familiar with using STL, including the algorithm and the
> > > > containers, however, how they are implemented. Some of my friends
> > > > recommend me to read the source code of STL directly.
>
> > > Reading is too dry.
>
> > nonsense!

I misunderstood here. Since I think reading the STL code is so
obviously mad I assumed you were saying "reading a book was too dry".
But I see not. If I want to know what the STL does I read Jossutis. or
use an online source.

> > > Try debugging through it.
>
> > yuck!
>
> > > Start with the simplest
> > > of things, like for_each, vector:ush_back, list:ush_front. Just
> > > make simplest of programs, e.g.
>
> > > int main()
> > > {
> > > * std::vector<char> v;
> > > * v.push_back('a');
>
> > > }
>
> > > and go through with the debugger.
>
> > > In the beginning, it will be difficult, because you will need to learn
> > > to see through the cruft that's inside. Typically, you'll see a lot of
> > > code whose sole purpose is to aid debugging. You'll need to learn to
> > > ignore that. You will also see bizarre variable naming. Live with it.
> > > Variable naming in STL is subject to different considerations than
> > > your or mine code .
>
> > or you could try poking your own eyes out

it just seems a lot of pain ...cruft...bizzare variable naming... for
very little gain.

> I find that watching code unroll in the debugger is a great way of
> learning what code does.

I'm less enthusiastic. Very unenthusiastic in fact. And it doesn't
help you learn what the STL /should/ be doing. Without reading some
sort of documentation I don't see how you'd even know certain features
existed.

> Even more so when it's about usual STL
> implementations code.

even less is my thought. The STL is particularly ugly lookign code.
Why do you care how it's implemented? Do you single shot through the C
libraries? You probably do I suppose...

> I don't get your excitement.

what excitement?

> It's not very elaborate either .

the STL? It's pretty subtle.