The way to read STL source code

[Stanley Rice]

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.

 

[Juha Nieminen]

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

 

[Goran]

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.

 

[Stanley Rice]

  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.

 

[Nick Keighley]

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.

 

[Nick Keighley]

  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)

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.

 

[Nick Keighley]

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

 

[Goran]

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.

 

[Juha Nieminen]

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

 

[Nick Keighley]

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.

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.

 

[Goran]

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.










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


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.

From "how they are implemented" words of the OP, I took he wants to
see how STL is implemented. Doc normally says nothing about that.

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

Occasionally, yes. E.g. when I hit the problem I don't understand.

what excitement?

I interpreted e.g. "or you could try poking your own eyes out" as you
being agitated about my post. "Excitement" was the wrong word.

Goran.

 

[Jorgen Grahn]

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.

To learn the language from scratch: yes. But do you also mean it's not
useful to read others' code after a while, when you can write some
small programs yourself? I can't agree with that.

/Jorgen

 

[Juha Nieminen]

To learn the language from scratch: yes. But do you also mean it's not
useful to read others' code after a while, when you can write some
small programs yourself? I can't agree with that.

Actually the more you know the language, the less you would even want
to look at other people's code. Instead, what one ends up doing is reading
tutorials, reference manuals and books on things like algorithms, data
containers and design patterns. The only place you would look at someone
else's code is in those tutorials (but usually in those the code is not
a whole program, but just the relevant lines that demonstrate the thing
being explained).

If you ever need to look at someone else's code it usually means that
you are tasked to maintaining/fixing/refactoring said code. That's like
cleaning someone else's underwear by hand. Yuk.

 

[Stanley Rice]

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.

But why there are so many people reading the Linux source code? Because
there are lots of annotation about it? Lots of books explain it?

I am not a native English speaker. Maybe the culture and the way teachers
teaches make the difference. In the past, I learn to program by reading
the books and others' demon, and then refer to the document. Yes, those
programs are not big at all, and easy to understand, and the document can
also explain it to me.

But if you said that reading others' code is not the way to improve your
programming skills, I have no ideas how to improve it. Reading the
reference and manual just too boring to me, at least now. For example, some
online resources explain every function of STL, I read it through but I
don't konw when to use it. Even in my daily practice, the function can't
jump into my mind. It seems that I learn nothing.

While reading others' code, I will think why he use it some times, though
he might use it in a not very good way.

 

[Stanley Rice]

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.


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


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

Another reason that I want to read the source code is that I want to improve my understanding of data structure and algorithm in the same time. STL covers nearly all the basic data structure and algorithms.

 

[Ian Collins]

But why there are so many people reading the Linux source code? Because
there are lots of annotation about it? Lots of books explain it?

In the case of my last team, because there were lots of bugs to fix!

mainly because of the need to be portable, library code is notoriously
difficult to read.

Your time would be better spent reading a decent book such as "The C++
Standard Library: A Tutorial and Reference" by Nicolai M. Josuttis

http://www.amazon.com/Standard-Library-Tutorial-Reference/dp/0201379260

I am not a native English speaker. Maybe the culture and the way teachers
teaches make the difference. In the past, I learn to program by reading
the books and others' demon, and then refer to the document. Yes, those
programs are not big at all, and easy to understand, and the document can
also explain it to me.

But what you probably won't find is documentation for a standard
library's source.

But if you said that reading others' code is not the way to improve your
programming skills, I have no ideas how to improve it. Reading the
reference and manual just too boring to me, at least now. For example, some
online resources explain every function of STL, I read it through but I
don't konw when to use it. Even in my daily practice, the function can't
jump into my mind. It seems that I learn nothing.

Reading well documented code can improve your programming skills.

 

[Stefan Ram]

Newsgroups: comp.lang.c++,comp.lang.misc
Followup-To: comp.lang.misc

But if you said that reading others' code is not the way to improve your
programming skills, I have no ideas how to improve it. Reading the

Reading others' code /is/ the way to improve the skills:

- Of course, one should select code written by masters,
not code written by arbitrary authors. For example,
in the realm of C++, one might read boost source code.
In the realm of C, source code for GNU commands.
For Java, read the source code of the standard library.
In the realm of Pascal, "TeX - the program". And so on.

- A good way to enforce active reading is a goal, like
porting the code or modifying it.

- Reading masters' code must, of course, not be all that
one does. One also has to read books and do other
programming exercises. Reading masters' code might
comprise, for example, 20 % of all programming activities.

Newsgroups: comp.lang.c++,comp.lang.misc
Followup-To: comp.lang.misc

 

[Rod Pemberton]

Newsgroups: comp.lang.c++,comp.lang.misc
Followup-To: comp.lang.misc

I put comp.lang.c++ back on. Mr. Rice makes some wildly incorrect
assumptions, IMO. Hopefully, it'll also end up indexed in the correct
thread on c.l.c++.

Reading others' code /is/ the way to improve the skills:

Wrong! Wrong! Wrong! Freakin' wrong!

Reading others' code only exposes one to the inherent flaws of thinking and
bad code implementation others, which one - especially the novice,
inexperienced, or average intellect - then accepts as their own - since the
code different, perhaps novel, and therefore *must* be better (sarcasm) -
because they don't yet understand just how truly *bad* the idea they're
reading is. Reading other's code is one of the absolute worst things one
could do, especially for a novice who is one likely to be very accepting
when reading others' code. It's like taking pure water (you) and drinking
polluted river water (others) and ending up with a mix.

- Of course, one should select code written by masters,
not code written by arbitrary authors.

Just how does one judge a master? If you aren't a master yourself, you
can't judge who is a master ...

That entire idea is so flawed. A guy with average intellect will only
recognize a range of intellect similar to his own. He'll recognize that
which is slightly more or less bright than he, but won't recognize dumb and
genius level ideas as such. So, a guy with less than average intellect will
recognize the code by an average intellect guy as being a "master". The
majority - who are supposedly of average intellect - will be scratching
their heads in confusion asking: "Why does this guy think that guy is a
master? That guy's code is no better than my own ... I don't get it." The
same is true for the average guy, the slightly above average guy, the
brilliant guy, the genius guy. It's only partially true for the
super-genius guy who will only recognize code worse than his own ... So, in
effect, you're saying one needs to locate super-genius guy and have him
waste his time reviewing code to classify who is and who is not a master
before anyone can study the other "masters".

For example,
in the realm of C++, one might read boost source code.
In the realm of C, source code for GNU commands.
For Java, read the source code of the standard library.
In the realm of Pascal, "TeX - the program". And so on.

I doubt any of the code produced by the open-source movement could be
classified as "being written by masters". There are too many people with
*widely* varying intellect levels, most of whom are only of average
intellect, to claim that the cited code in it's entirety is somehow
brilliant. For the code to be brilliant, a single brilliant individual
must've coded it or a team of similarly brilliant individuals must've coded
it. Both of those are things which were unlikely to be present during the
codeing of any of the code you've suggested as being "master" level.

- A good way to enforce active reading is a goal, like
porting the code or modifying it.

The way to improve your code is not by reading others' code, but by 1)
really learning what elements the language provides, 2) writing your own
code using the language elements, and 3) learning how that language is
converted to assembly. You can read about implementing something, say a
linked-list, numerous times, but until you've actually done so, you won't be
able to identify and correct your own mistakes of implementation or of your
thought process, which will happen no matter how good your memory or
thinking is.


Rod Pemberton

 

[Stefan Ram]

The way to improve your code is not by reading others' code

But we should not forget that there are more man-hours in
maintenance programming than in programming a new program
from scratch. That means the typical work day of a
programmer is not writing his own code (as you wrote »your
code« above), but maintaining code written by someone else.
And the first step to do this properly is to read and to
understand that code that is to be modified. So, training to
read code also is just a preparation for the very activity
that will most often be exercised when being a programmer.

 

[Stefan Ram]

Reading others' code only exposes one to the inherent flaws of thinking and

The same could be said about reading a programming book.

Just how does one judge a master? If you aren't a master yourself, you

The same could be said about judging a programming book.
(Macchiavelli wrote about this, see the last paragraph in

http://ebooks.adelaide.edu.au/m/machiavelli/niccolo/m149p/chapter23.html

)

That entire idea is so flawed. A guy with average intellect will only
recognize a range of intellect similar to his own. He'll recognize that

Yes. This means that a person with an above-the-average
intellect will perform better. But this is a general
principle, it does not apply to reading source code only.
However, one might critize the implied assumption that the
intellect is something fixed, see

http://en.wikipedia.org/wiki/Mindset_(book)