Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14135 > unrolled thread

The way to read STL source code

Back to article view | Back to comp.lang.c++

Contents

  The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-16 23:18 -0800
    Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:29 +0000
      Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 00:56 -0800
        Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:11 -0800
        Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 12:31 +0000
          Re: The way to read STL source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-17 16:35 +0000
            Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 20:38 +0000
              Re: The way to read STL source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-21 21:17 +0000
          Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 16:55 -0800
            Re: The way to read STL source code Ian Collins <ian-news@hotmail.com> - 2012-02-18 14:13 +1300
            Re: Learning to code by reading code (was: The way to read STL source code) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-18 19:00 -0500
              Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-18 22:34 -0600
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-19 10:42 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 03:39 -0500
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-19 08:40 -0800
                  Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-19 13:17 -0600
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:32 -0800
                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:09 -0800
                          Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 15:11 +0100
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 07:39 -0800
                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 04:14 -0500
                    Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 11:14 +0100
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:49 -0800
                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:18 -0800
                          Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-20 13:53 +0000
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:32 -0800
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-21 16:16 +0100
                                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:40 -0800
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 17:36 -0500
                        Re: Learning to code by reading code Mike McCarty <mcmccarty@gmail.com> - 2012-02-20 15:27 -0800
                        Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-21 00:45 +0100
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:35 -0500
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:48 -0800
                              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:12 -0800
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:12 -0500
                                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 04:30 -0800
                                  Re: Learning to code by reading code Geoff <geoff@invalid.invalid> - 2012-02-22 10:45 -0800
                                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 01:12 -0800
                                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:34 -0500
                                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 05:46 -0800
                                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:38 +0100
                                        Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:40 +0100
                                        Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 09:38 +0100
                                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-25 05:25 -0500
                                        Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-25 12:50 +0100
                                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-25 06:13 -0800
                                          Re: Learning to code by reading code Gareth Owen <gwowen@gmail.com> - 2012-02-26 07:20 +0000
                        Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:23 +0000
                          Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:43 +0000
                            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:47 -0500
                              Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:09 +0000
                                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:38 -0500
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:31 -0500
                            Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:05 +0000
                              Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-21 12:21 +0100
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:04 -0500
                            Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-21 11:01 +0000
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:27 -0800
                    Re: Learning to code by reading code Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 22:25 +0100
                      Re: Learning to code by reading code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 08:47 +0000
                        Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-26 10:55 +0000
                    Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 08:59 +0100
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                        Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 13:47 +0100
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 06:21 -0500
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:08 -0800
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code Stanley Rice <heconghui@gmail.com> - 2012-02-19 05:24 -0800
              Re: Learning to code by reading code Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000
            Re: Learning to code by reading code (was: The way to read STL source code) Ebenezer <woodbrian77@gmail.com> - 2012-02-18 20:02 -0800
              Re: Learning to code by reading code (was: The way to read STL source code) 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-18 21:51 -0800
              Re: Learning to code by reading code (was: The way to read STL source code) "Bo Persson" <bop@gmb.dk> - 2012-02-19 16:10 +0100
            Re: The way to read STL source code Mark Elston <m.elston@advantest-ard.com> - 2012-02-21 16:40 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:06 -0800
    Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-16 23:36 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:12 -0800
        Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-17 03:57 -0800
          Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 05:15 -0800
            Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-17 06:02 -0800
            Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 17:08 -0800
              Re: The way to read STL source code Dombo <dombo@disposable.invalid> - 2012-02-19 16:52 +0100
    Re: The way to read STL source code Krice <paulkp@mbnet.fi> - 2012-02-24 00:38 -0800
    Re: The way to read STL source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-25 10:46 -0800
      Re: The way to read STL source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-26 14:57 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-27 03:02 -0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#14135 — The way to read STL source code

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.

[toc] | [next] | [standalone]

#14138

Stanley Rice <heconghui@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.

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

[toc] | [prev] | [next] | [standalone]

#14143

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.

[toc] | [prev] | [next] | [standalone]

#14145

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.

[toc] | [prev] | [next] | [standalone]

#14161

Stanley Rice <heconghui@gmail.com> 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.)

[toc] | [prev] | [next] | [standalone]

#14177

On Fri, 2012-02-17, Juha Nieminen wrote:
> Stanley Rice <heconghui@gmail.com> 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.

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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14191

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#14391

On Fri, 2012-02-17, Juha Nieminen wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> 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.

I think of it more as sex involving more than one person ...

(I see there's a different subthread about all this, so I won't push
it any further here.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14211

On Friday, February 17, 2012 8:31:54 PM UTC+8, Juha Nieminen wrote:
> Stanley Rice <heconghui@gmail.com> 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.
> 
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.

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

[toc] | [prev] | [next] | [standalone]

#14214

On 02/18/12 01:55 PM, Stanley Rice wrote:
> On Friday, February 17, 2012 8:31:54 PM UTC+8, Juha Nieminen wrote:
>> Stanley Rice<heconghui@gmail.com>  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.
>>
> 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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14247 — Re: Learning to code by reading code (was: The way to read STL source code)

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:reading-20120218195201@ram.dialup.fu-berlin.de...
> 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++.

> Stanley Rice <heconghui@gmail.com> writes:
> >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:
>

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

[toc] | [prev] | [next] | [standalone]

#14257 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message 
news:code-20120219014836@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>>Reading others' code only exposes one to the inherent flaws of thinking 
>>and
>
>  The same could be said about reading a programming book.

... as well as blogs and (no surprise here) usenet posts.

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

This is a different point. The gain in reading books and others' code is 
broader exposure to ideas, approaches, and idioms. We aren't all so learned 
that only the true masters have something of value to teach us.

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

Your cup overfloweth, Grasshopper.

[toc] | [prev] | [next] | [standalone]

#14265 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:code-20120219014836@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >Reading others' code only exposes one to the inherent flaws of thinking
>
>   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.

It depends entirely on the book.  Is the book teaching how to program a
certain language or is the book teaching only language concepts?  If you
can't tell whether a book is teaching how to program a language, teaching
just the concepts of a specific language, or teaching generic programming
concepts, you'll never make it as a programmer.

>   (Macchiavelli wrote about this, see the last paragraph in
>
> http://ebooks.adelaide.edu.au/m/machiavelli/niccolo/m149p/chapter23.html
>

Macchiavelli also wrote this, see the "Because there are three ..." section:
http://ebooks.adelaide.edu.au/m/machiavelli/niccolo/m149p/chapter22.html

> >The way to improve your code is not by reading others' code, but by 1)
> >really learning what elements the language provides,
>
>   From which source?

E.g., Harbison and Steele's "C: A Reference Manual" is one of the best books
ever written on C and doesn't teach a single thing about programming in C...

Basically, you want to learn the language elements from one which does not
teach how to program.  You want one that is purely technical in nature.
Sometimes, these are referred to as programmer's reference manuals.  Good
programming concepts should not be required by the language: structured
programming, object-oriented programming.  If the language doesn't allow the
programmer to produce junk or "spaghetti code" or use pointers, the language
is most likely worthless.  It's up to the programmer to put the puzzle
pieces together using pure programming concepts they've learned from other,
non-language specific, sources.

> >2) writing your own code using the language elements,
>
>   Starting to code without having every read example
>   programs written by others?

Why not?  I did.

Many years ago, I taught myself BASIC followed by 6502 assembly.  I did so
without *any* books on programming.  I only had one trivial programming
class prior to that, in LOGO.  BASIC and 6502 were learned entirely from
programmer's reference manuals which did not teach any programming concepts,
like structured code, etc.  After learning those, I had Pascal in High
School, Fortran at University, followed by self-taught C, and a PL/I variant
learned entirely on the job, etc.

Personally, I believe that individuals who have not learned how to program
in assembly at a young-ish age, i.e., early teens or pre-teen, never fully
grasp certain programming concepts, like the concept of null.  Those who've
learned later tend to have problems with understanding how the OOP, or
dynamicly typed, or HLL language they prefer doesn't generate the assembly
they expected.  Assembly is the foundation upon which programming
languages are built.  As a professional programmer, you must understand what
the high-level code is being converted into.  If the compiled code doesn't
do what the high-level code was "supposed" to do, it's your job that's on
the line.  You can argue that the C or C++ compiler is not compliant with
the ANSI or ISO specifications all day long, but that won't get you anywhere
with an angry employer.

> >3) learning how that language is converted to assembly
>
>   So one also has to learn at least on assembly language,
>   which processor do you suggest?

6502.  Maybe Z80 ...  You had to ask.  Many of the fundamental concepts are
still present in microprocessors that were developed in that era, e.g., x86.
Languages that flourished upon 8-bit micro's also contain many of the needed
concepts, e.g., C and Forth.  Personally, I wouldn't start them out with a
RISC design.  Unfortunately, that goes against most current collegiate level
thinking.  University professors have embraced the idea that "RISC is the
future", even though it's fundamentally flawed.  Unfortunately, modern
languages and architectures are obsoleting the ability to learn some of
those concepts, but the need is still present to use HLLs, e.g., 8-bit
bytes, contiguous memory, etc.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14268 — Re: Learning to code by reading code

On Sun, 19 Feb 2012 03:54:10 -0500, Rod Pemberton wrote:

> "Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
> news:code-20120219014836@ram.dialup.fu-berlin.de...

>>>2) writing your own code using the language elements,
>>
>>   Starting to code without having every read example
>>   programs written by others?
> 
> Why not?  I did.

So did I, but programming is not what it was 30 years ago. It is less 
coding and much more analysis, design, reuse, testing, integration. 
Learning must focus on most important cases and patterns. These cannot be 
identified without help, at least without wasting much time. Both starting 
from scratch and reading code look poor here.

> Personally, I believe that individuals who have not learned how to program
> in assembly at a young-ish age, i.e., early teens or pre-teen, never fully
> grasp certain programming concepts, like the concept of null.

Huh, I would rather prevent students from being spoiled by programming. 
They should learn fundamental things first, e.g. math. Unfortunately, it is 
like sex, they get exposed anyway. (:-))

> Those who've
> learned later tend to have problems with understanding how the OOP, or
> dynamicly typed, or HLL language they prefer doesn't generate the assembly
> they expected.  Assembly is the foundation upon which programming
> languages are built.  As a professional programmer, you must understand what
> the high-level code is being converted into.

I doubt that an exposure to some machine code is the right tool for gaining 
such understanding. And why did you choose specifically the machine code? 
Why not the micro code? Why not the states of the pipelines and the cache? 
Why not individual transistors? Why not electrons, atoms and fields?

Another objection is that the machine code is not what is really going on 
unless the program is some number-crunching beast. Most of the programming 
issues regarding time, resources, bugs are addressed to the software 
components, synchronization, protocols, hardware I/O, OS calls, the stuff 
you cannot learn looking at the machine code.

> If the compiled code doesn't
> do what the high-level code was "supposed" to do, it's your job that's on
> the line.  You can argue that the C or C++ compiler is not compliant with
> the ANSI or ISO specifications all day long, but that won't get you anywhere
> with an angry employer.

Working around compiler bugs rarely requires looking at the generated code. 
I don't remember single case I need that.

>>>3) learning how that language is converted to assembly
>>
>>   So one also has to learn at least on assembly language,
>>   which processor do you suggest?
> 
> 6502.  Maybe Z80 ...  You had to ask.

MACRO-11 (PDP-11 or VAX) or at least 68k.

> Personally, I wouldn't start them out with a RISC design.

Sure. RISC would prove weakness of your concept. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#14308 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:teaching-20120219165706@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
...

>   The fallacay could be: »I learned programming this way,
>   therefore, every one else also should learn it this way.«
>   (»Because I only know the way how I did learn it, I cannot
>   imagine any other possibility.«)
>

Well, I believe I already stated why.  Younger programmers seem to have
problems with many of the basic concepts of microprocessors.  IMO, this
comes from teaching things like RISC, OOP, HLLs, etc.

> [...]
>   In my case, for example, I could say: »The best way to learn
>   programming for everyone is to write the programs on paper
>   with a pencil for some months, before one starts to sit in
>   front of a keyboard.«

Why is that the best way?  With pencil and paper, there is no ability to
confirm the correctness of the program.  That's one of the fundamental
things taught in math and science: the ability to check your work.  Without
an implementation, how does one do that?

Pencil and paper is good in that it forces you to think out the problem and
solution versus that of trial and error until it works without actually
understanding why it now works.  But, isn't that what math and sciences
classes in school are supposed to teach?  I.e., thinking and problem
solving.

>  [...]
>   In my case, the good thing about writing code on paper was
>   that I did not rush to execute my code, but instead took my
>   time to write and re-read it carefully and then learned to
>   »mentally execute« the code: Because I had no implementation,
>   I »executed« each statement mentally trying to imitate what
>   the machine would do. A capability, which surely is helpful
>   in programming.

True.


Rod Pemberton
PS  I missed the Machiavelli misspelling.  I'm not good with names.
Apparently, I (horrors!) cut-n-pasted.  No, I'm not perfect with spelling
either, but good.  It's not the only word misspelled by you though.  See
"fallacay" "stil" etc.

[toc] | [prev] | [next] | [standalone]

#14266 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >learning how that language is converted to assembly
>
>   Even given a specific source language and a specific
>   assembly language, there is no specific way »how that
>   [source ]language is converted to assembly«, this
>   instead depends on the compiler[ author].
>

I believe that's partially true, but not entirely.  Many assembly languages
are very similar.  Microprocessors standardized on certain concepts around
1974 or so, e.g., 8-bit bytes for ASCII and EBCDIC, contiguous memory,
pointer size equivalent to integer size, typeless integers, etc.  Many HLL
compilers, e.g., for C, produce the nearly the same code but adjusted for
different platforms.  But, it's still the programmer's responsibility to
understand what that HLL code is producing for their specific tools.  That
usually just means learning what the tools produce.

>   Moreover, this will not be possible, when the language
>   to be learned already is an assembly language.
>

Mr. Rice's examples were all HLLs.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14286 — Re: Learning to code by reading code

On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:

> > >learning how that language is converted to assembly [is important]

I don't think so. When I come across a novel language feature I like
to think how it would be implemented. But I use an imaginary machine
(or these days, C!). Long ago I knew Z80 assembler (actually much of
Z80 machine code) but I can't see the utility in converting chunks of C
++ (or scheme or Haskell)into Z80 assembler.

> >   Even given a specific source language and a specific
> >   assembly language, there is no specific way »how that
> >   [source ]language is converted to assembly«, this
> >   instead depends on the compiler[ author].
>
> I believe that's partially true, but not entirely.

agreed

>  Many assembly languages
> are very similar.  Microprocessors standardized on certain concepts around
> 1974 or so, e.g., 8-bit bytes for ASCII and EBCDIC, contiguous memory,
> pointer size equivalent to integer size, typeless integers, etc.

but many C programmers (and maybe C++ programmers) assume these are
inviolate laws! They end up writing horribly unportable programs for
no reason except intellectual laziness and lack of imagination about
hardware engineers (and compiler writers) might do.

Your concentration on assembly code encourages this (naff) type of
coding.

> Many HLL
> compilers, e.g., for C, produce the nearly the same code but adjusted for
> different platforms.  But, it's still the programmer's responsibility to
> understand what that HLL code is producing for their specific tools.

nope. I get on just fine not knowing what code my HLL is producing.

> That
> usually just means learning what the tools produce.
>
> >   Moreover, this will not be possible, when the language
> >   to be learned already is an assembly language.
>
> Mr. Rice's examples were all HLLs.

[toc] | [prev] | [next] | [standalone]

#14294 — Re: Learning to code by reading code

Nick Keighley wrote:
> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
>> news:assembly-20120219023621@ram.dialup.fu-berlin.de...
>>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:
>
>>>> learning how that language is converted to assembly [is important]
>
> I don't think so. When I come across a novel language feature I like
> to think how it would be implemented. But I use an imaginary machine
> (or these days, C!). Long ago I knew Z80 assembler (actually much of
> Z80 machine code) but I can't see the utility in converting chunks of
> C ++ (or scheme or Haskell)into Z80 assembler.
>
>>> Even given a specific source language and a specific
>>> assembly language, there is no specific way »how that
>>> [source ]language is converted to assembly«, this
>>> instead depends on the compiler[ author].
>>
>> I believe that's partially true, but not entirely.
>
> agreed
>
>> Many assembly languages
>> are very similar. Microprocessors standardized on certain concepts
>> around 1974 or so, e.g., 8-bit bytes for ASCII and EBCDIC,
>> contiguous memory, pointer size equivalent to integer size, typeless
>> integers, etc.
>
> but many C programmers (and maybe C++ programmers) assume these are
> inviolate laws! They end up writing horribly unportable programs for
> no reason except intellectual laziness and lack of imagination about
> hardware engineers (and compiler writers) might do.
>
> Your concentration on assembly code encourages this (naff) type of
> coding.
>
>> Many HLL
>> compilers, e.g., for C, produce the nearly the same code but
>> adjusted for different platforms. But, it's still the programmer's
>> responsibility to understand what that HLL code is producing for
>> their specific tools.
>
> nope. I get on just fine not knowing what code my HLL is producing.

This might be the salient point, at least for this narrow part of the 
discussion.

Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has 
in my mind very specific implications and costs. As I type or read each 
'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a 
subconscious level the underlying assembler, albeit on a broad generalized 
model. For that matter, I also hold a simplified model of how awk or perl 
scripts are read and translated as I write them. Reading the Erlang language 
spec recently, I can "see" the interpreter, how it's built (or how I might 
build one), and the runtime cost of many of its constructs. C#'s runtime 
type binding holds few mysteries if you understand COM, and Java's byte-code 
interpreter holds no mysteries at all.

Like some others, I also had my start with BASIC, and then dug into 6502 
assembler to understand the unannotated ROM disassembly. This seemed a 
completely natural progression. (Apparently, Bill and I have an even longer 
history together than I had imagined before this moment.)

Before that, though, I wrote toy-sized FORTRAN without the slightest notion 
beyond "this is how you iterate over these calculations N number of times", 
and "this statement label is how you tie this statement to that other." 
Certainly it's possible to write useful programs without understanding the 
how or why behind them.

While I don't intend any of this to be judgemental, I don't see how I can do 
what I do with just a collection of rote rules and a notion of magic that 
happens under the covers. As perhaps extreme examples, memory barriers and 
fences are vague notions and superstition with that view, and using CUDA 
effectively is not possible at all without an underlying understanding of 
how the parts fit together.

[toc] | [prev] | [next] | [standalone]

#14316 — Re: Learning to code by reading code

On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Nick Keighley wrote:
> > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> >>>> learning how that language is converted to assembly [is important]
>
> > I don't think so. When I come across a novel language feature I like
> > to think how it would be implemented. But I use an imaginary machine
> > (or these days, C!). Long ago I knew Z80 assembler (actually much of
> > Z80 machine code) but I can't see the utility in converting chunks of
> > C ++ (or scheme or Haskell)into Z80 assembler.
>
> >>> Even given a specific source language and a specific
> >>> assembly language, there is no specific way »how that
> >>> [source ]language is converted to assembly«, this
> >>> instead depends on the compiler[ author].
>
> >> I believe that's partially true, but not entirely.

[...]

> >> Many HLL
> >> compilers, e.g., for C, produce the nearly the same code but
> >> adjusted for different platforms. But, it's still the programmer's
> >> responsibility to understand what that HLL code is producing for
> >> their specific tools.
>
> > nope. I get on just fine not knowing what code my HLL is producing.
>
> This might be the salient point, at least for this narrow part of the
> discussion.
>
> Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> in my mind very specific implications and costs.

I don't think this has been true for many years. I certainly don't
think it has been useful.

> As I type or read each
> 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> subconscious level the underlying assembler, albeit on a broad generalized
> model.

I may have done that in the past but I don't think I do now. maybe
deep-deep down in my subconcious there's a Z80 or 68000 running. but I
doubt it.

To me C is the machine at the bottom.

> For that matter, I also hold a simplified model of how awk or perl
> scripts are read and translated as I write them.

never had that for Awk. Certainly not for Perl. this may explain why
I'm a rubbish Perl programmer... I have no semantic model for Perl.

> Reading the Erlang language
> spec recently, I can "see" the interpreter, how it's built (or how I might
> build one), and the runtime cost of many of its constructs.

I'm (in a desultory way) grappling with Haskell. Maybe your approach
would help me.

> [...] I wrote toy-sized FORTRAN without the slightest notion
> beyond "this is how you iterate over these calculations N number of times",
> and "this statement label is how you tie this statement to that other."
> Certainly it's possible to write useful programs without understanding the
> how or why behind them.

I'm not sure I agree. I think tou have to have some sort of idea what
is going on. I've been reading Fowler's "Domain Specific Languages"
recently. And I realised that's where i stole the term "Semantic
Model" from. This is one of those rare books where I go "yes! that's
what I was trying to do/say!". It's like he read my mind, sorted it
all out then squirted it on to paper.

> While I don't intend any of this to be judgemental, I don't see how I can do
> what I do with just a collection of rote rules and a notion of magic that
> happens under the covers.

yes, you have to have some set of primitives and some way of combinign
them, and the primitives must have some well defined semantics
(meaning). I just disgaree that some arbitary assembler is the best
way to describe the semantics. Level confusion at best.

"Dr. I have this pain in my leg!" "Your quarks are misplaced"

> As perhaps extreme examples, memory barriers and
> fences are vague notions and superstition with that view, and using CUDA
> effectively is not possible at all without an underlying understanding of
> how the parts fit together.

[toc] | [prev] | [next] | [standalone]

#14322 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Nick Keighley wrote:
> > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> >>>> learning how that language is converted to assembly [is important]
> Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> in my mind very specific implications and costs.

I don't think this has been true for many years. I certainly don't
think it has been useful.

> As I type or read each
> 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> subconscious level the underlying assembler, albeit on a broad generalized
> model.

I may have done that in the past but I don't think I do now. maybe
deep-deep down in my subconcious there's a Z80 or 68000 running. but I
doubt it.

To me C is the machine at the bottom.

#this is io_x
#C can not be the one machine language.
#it will be the language one machine if it has no Undefinited Behaviour,
#and type of know size, and operation on these type all the same for all PCs
#and i think a way to reach the stack it[C] use for call functions
#and for save variable in the function preamble...
#

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web