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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#14364 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
news:jhvobn$ujr$1@speranza.aioe.org...
> "Juha Nieminen" <nospam@thanks.invalid> wrote in message

>> The question is: Would it be *efficient*?
>
> No, it wouldn't.  There is no such thing as an "*efficient*" interpreter
> as
> compared to compiled native code.

In the case of a scripting language, this is largely irrelevant.

If all the language does is invoke other programs, then there would be no
measureable difference between an interpreter, and a native code version.

It also depends on how the language is used; it might be 100 times slower
than native code, but if runtimes are small anyway, then there may not be
much advantage in taking only 1msec to do something instead of 100msec.

> There are two fundamental problems with
> interpreters that can't be overcome: 1) they reimplement the mechanisms of
> assembly language which slows things down alot

An interpreter may well be *implemented* in assembly language. Every
instruction that the interpreter deals with could be implemented by a
carefully hand-crafted and optimised block of assembly code! Sometimes
better than automatically compiled code.

 2) they can't optimize and
> compile code sequences which dramatically slows down loops and other
> control-flow.

Tell that to the guy who implemented the LuaJIT interpreter. Numeric
benchmarks are often faster than optimised C!

>> [...] the resulting C code is usually completely unreadable
>> and unusable by a human being.

I used to find that anyway, even when not generated by a machine..

> True, but if you coded that feature yourself, it doesn't have to be
> coded as "butchered" code.
>
>> Even then it would probably be hard to match the speed of an actual
>> compiler of the original language.
>
> I don't believe that.  C has had some of the most intensive research into
> language optimizations.  Other languages just haven't had the time and
> research put into them.

C is pretty good, but it has to spend a lot of time recognising constructs
in the source code could be expressed directly in a higher level language 
and which can be executed directly (vector operations for example). It 
doesn't always manage to do that.

And if implementing something unusual, you can often write almost directly
from pseudo-code in a higher level language, but a quick, throwaway
implementation in C may well be slower; you need to spend time with C in
achieving what's already been done inside the interpreter.

-- 
Bartc 

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

#14411 — Re: Learning to code by reading code

"BartC" <bc@freeuk.com> wrote in message news:jhvtig$fam$1@dont-email.me...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
> news:jhvobn$ujr$1@speranza.aioe.org...
...

> > There are two fundamental problems with interpreters that
>> can't be overcome: 1) they reimplement the mechanisms of
> > assembly language which slows things down alot
>
> An interpreter may well be *implemented* in assembly language.

That's typical.

> Every instruction that the interpreter deals with could be implemented
> by a carefully hand-crafted and optimised block of assembly code!

So?  An interpreter still reimplements for a virtual machine what native
assembly already does, i.e., slower.

> Sometimes better than automatically compiled code.

The "hand" optimized sequences for interpreters are much smaller than what a
compiler usually optimizes.  So, while the small pieces might be optimized
better, overall the larger compiler pieces are better optimized.

> >  2) they can't optimize and compile code sequences which
> > dramatically slows down loops and other control-flow.
>
> Tell that to the guy who implemented the LuaJIT interpreter. Numeric
> benchmarks are often faster than optimised C!
>

Well, tell him JIT is not an interpreter:
http://en.wikipedia.org/wiki/Just-in-time_compilation

> C is pretty good, but it has to spend a lot of time recognising constructs
> in the source code [which] could be expressed directly in a higher level
> language and which can be executed directly (vector operations for
> example). It doesn't always manage to do that.

Those constructs must still be converted to assembly.  So, even if you can
"express them directly", what real advantage is that?  They have to be
converted to the underlying assembly language no matter what.  If you're
looking for "short-hand" to express "missing" some constructs, use some
integers and an array ...

> And if implementing something unusual, you can often write almost directly
> from pseudo-code in a higher level language, but a quick, throwaway
> implementation in C may well be slower; you need to spend time with C in
> achieving what's already been done inside the interpreter.
...


Rod Pemberton

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

#14353 — Re: Learning to code by reading code

On Feb 20, 10:36 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com...> On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>

> > > [a C-like language] most likely inherited the basic
> > > functionality that a programmer needs to know.
>
> > exceptions, closures, continuations, monads,
>
> > lost of stuff C doesn't provide.
>
> Don't you mean: lots of stuff C doesn't need? ...

no. I'm saying there's lots of functionality a programmer might need
that is /not/ provided by C. Object oriented programming for a start.

> How many of the languages which have a language feature that is
> "missing" from C are compiled to C or once were?

many of them

> (The great majority of them do or did.  That includes C++ at one point in
> time via Cfront.  Nearly all modern dynamicly typed languages do.)

so what? All HLLs are Turing equivalent. You can write Lisp
interpreters in Cobol if you wish to but I suspect it's painful.

Learnign other paradigms gives you more tools in your toolbox.

> > > How do you know your compiler is compliant with a specification,
> > > or your compiler accurately implements what you expect your code
> > > to do? Testing only? What if you missed something you could've
> > > caught had you simply just read the assembly?
>
> > in my experience compiler bugs are very rare
>
> Well, you must not have much experience.  Or, you've just never noticed the
> errors because 1) you've never studied or verified the assembly output and
> 2) the error was never "triggered".  I've found either compilation errors or
> library coding errors with most of the C compilers I've used.  One compiler
> optimized away code that shouldn't have been, but only for one intermediate
> optimization level.  All optimization levels above or below the intermediate
> level worked correctly.  Another had type conversion errors in the assembly
> when a specific type was used with any other type.  In one library, an
> erroneously coded function was supposed to return three states, but returned
> only two.  Issues like these were not found in compilers where you'd expect
> them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc.
> The problem with not looking at the assembly is that errors can exist for
> exceptionally long time periods before being noticed.

fair enough

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

#14336 — Re: Learning to code by reading code

Am 20.02.2012 10:14, schrieb Rod Pemberton:

> Have you ever had access to a non-emulated EBCDIC platform in your
> entire lifetime?  (No.) Have you ever had access to a 16-bit byte platform
> in your entire lifetime? (No.)  Have you ever had access to a 9-bit
> character platform in your entire lifetime? (No.)  So, like it or not, it's
> entirely up to the users of obscure platforms to fix the "non-portable"
> nature of C code for their platforms.

This is second-hand knowledge, but a co-worker of mine told me that
Analog Devices' "SHARC" DSP has 32-bit chars (i.e. CHAR_BIT==32). He had
lots of fun porting lwIP to it as you can't just overlay a struct on
some chunk of memory to parse the fields (like lwIP does)...


Peter

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

#14506 — Re: Learning to code by reading code

On Mon, 2012-02-20, Peter Remmers wrote:
> Am 20.02.2012 10:14, schrieb Rod Pemberton:
>
>> Have you ever had access to a non-emulated EBCDIC platform in your
>> entire lifetime?  (No.) Have you ever had access to a 16-bit byte platform
>> in your entire lifetime? (No.)  Have you ever had access to a 9-bit
>> character platform in your entire lifetime? (No.)  So, like it or not, it's
>> entirely up to the users of obscure platforms to fix the "non-portable"
>> nature of C code for their platforms.

Like it or not, the people who defined C and C++ said it is not. So
the burden is on *us* who target mainstream platforms to document the
non-portable nature of our code (e.g. by using uint8_t if we need
8-bit unsigned calculations).

> This is second-hand knowledge, but a co-worker of mine told me that
> Analog Devices' "SHARC" DSP has 32-bit chars (i.e. CHAR_BIT==32).

I have first-hand knowledge of DSPs with 16-bit char and int.

> He had
> lots of fun porting lwIP to it as you can't just overlay a struct on
> some chunk of memory to parse the fields (like lwIP does)...

You can't do that on mainstream CPUs either, unless you manage the
alignment. (I'm sure someone will now argue that C should ignore
SPARC, ARM etc and hardwire itself to x86).

/Jorgen

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

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

#14512 — Re: Learning to code by reading code

"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
news:slrnjkjsc9.1ls.grahn+nntp@frailea.sa.invalid...
> On Mon, 2012-02-20, Peter Remmers wrote:

>> He had
>> lots of fun porting lwIP to it as you can't just overlay a struct on
>> some chunk of memory to parse the fields (like lwIP does)...
>
> You can't do that on mainstream CPUs either, unless you manage the
> alignment. (I'm sure someone will now argue that C should ignore
> SPARC, ARM etc and hardwire itself to x86).

That actually wouldn't have been a bad idea, for a product such as 'C/86' to
have been created in the early eighties (not to be confused with the C89 or
C90 standards).

It would have been streamlined for the x86 processors, so programs could
well have been non-portable to other systems. However, applications would
have been limited to the niche market for x86 systems, which would likely
start drying up three or four decades later..

Of course we instead have C applications where the code itself is 99%
portable, but they depend entirely on makefiles, compilers and compiler
flags that are 100% non-portable, even on exactly the same hardware!

-- 
Bartc 

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

#14404 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:

> The first inherent problem with that argument is that microprocessors have
> standardized on a basic computing architecture.  Nearly all computing
> platforms today use that architecture either because they are microprocessor
> based or because they use the same hardware, e.g., memory.  They
> standardized way back around 1974.  Mainframes followed suit slightly
> later.

No, mainframes had the architecture in place in 1964 with System 360. That basic
platform still exists today obviously with many extensions as System Z. Why
do you keep trying to rewrite history? IBM solved all the problems Intel has
today back in good old 1964.

> What that means is that almost no one today - or in the past two decades for
> that matter - has access to obscure, obsoleted, perverse platforms - or
> other platforms that *NEVER* shouldv'e have been used to create the ANSI C
> standard in the first place - where "portability" of C or C++ is actually
> needed.  Have you ever had access to a non-emulated EBCDIC platform in your
> entire lifetime?

Sure, for most of my entire lifetime.

> Have you ever had access to a 16-bit byte platform in your entire
> lifetime?

Yes and I'm pretty sure you have also

> (No.)  Have you ever had access to a 9-bit character platform in your
>  entire lifetime?

Maybe, can't remember. Pretty sure the PDP-8 used a 12 bit word but that is
way bigger than what you asked about ;-)

> So, like it or not, it's entirely up to the users of obscure platforms to
> fix the "non-portable" nature of C code for their platforms.

Agreed but I solve the problem by not using C. YMMV ;-)


> Then, I'd quess you won't get fired for producing faulty code either ...
> So, that qualifies you as either a novice or hobbyist. 

Or an H1B

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

#14410 — Re: Learning to code by reading code

"Nomen Nescio" <nobody@dizum.com> wrote in message
news:6b1b5349ea595142c8ad34fe494793ba@dizum.com...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:
>
> > The first inherent problem with that argument is that microprocessors
> > have standardized on a basic computing architecture.  Nearly all
> > computing platforms today use that architecture either because
> > they are microprocessor based or because they use the same
> > hardware, e.g., memory.  They standardized way back around
> > 1974.  Mainframes followed suit slightly later.
>
> No, mainframes had the architecture in place in 1964 with System 360.

No, only *one* mainframe - singular - "had the architecture in place ..."

Also, there apparently is no support that IBM's mainframe was the genesis
for the use of the same architecture adopted by microprocessors.  The
development of standardized characters sets, e.g., ASCII and extended ASCII,
had a strong impact on standardizing 8-bit bytes for characters.

> That basic platform still exists today obviously with many extensions as
> System Z. Why do you keep trying to rewrite history?

I'm not.  Mainframes (plural) didn't standardize on IBM's System 360 design.
Microprocessors did circa 1974.  Mainframes (plural) still hadn't done so by
1978.  How is that rewriting history?

> IBM solved all the problems Intel has today back in good old 1964.

What problems?

> > What that means is that almost no one today - or in the past two
> > decades for that matter - has access to obscure, obsoleted,
> > perverse platforms - or other platforms that *NEVER* shouldv'e
> > have been used to create the ANSI C standard in the first place -
> > where "portability" of C or C++ is actually needed.  Have you
> > ever had access to a non-emulated EBCDIC platform in your
> > entire lifetime?
>
> Sure, for most of my entire lifetime.

I'm aware of your personal hell.  Or, everyone else would call it hell, but
you've embraced it as heaven ...  What do you think real Hell will be like
for you?  ;-)

> > Have you ever had access to a 16-bit byte platform
> > in your entire lifetime?
>
> Yes and I'm pretty sure you have also

Well, too many systems, let me check ...  I don't have info on all of them.
I did mean char size, but if talking address unit size then, unfortunately
that's a "yes" ...  However, anyone a few years younger than me, can't
answer that as a "yes".  So, shut up, you're ruining my point!  ;-)


Rod Pemberton

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

#14418 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:

> "Nomen Nescio" <nobody@dizum.com> wrote in message
> news:6b1b5349ea595142c8ad34fe494793ba@dizum.com...
> > "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:
> >
> > > The first inherent problem with that argument is that microprocessors
> > > have standardized on a basic computing architecture.  Nearly all
> > > computing platforms today use that architecture either because
> > > they are microprocessor based or because they use the same
> > > hardware, e.g., memory.  They standardized way back around
> > > 1974.  Mainframes followed suit slightly later.
> >
> > No, mainframes had the architecture in place in 1964 with System 360.
> 
> No, only *one* mainframe - singular - "had the architecture in place ..."

That's kind of a tautology since mainframe is like Kleenex or Jeep. There is
really only one...

> Also, there apparently is no support that IBM's mainframe was the genesis
> for the use of the same architecture adopted by microprocessors.

I didn't mean to suggest that, only that IBM standardized things very well
ten years early than your 1974 timeline for microprocessors....to the
extent stuff written for OS/360 is still object code compatible 48 years
later. Then 99% of the machines that came after it that were aimed at that
class of machine were either partial or total clones of the S/360 370
etc. If that isn't standardization I don't know what is. There haven't been
that many successful mainframe class machines but many many microprocessor
designs have had their day in the sun.

> The development of standardized characters sets, e.g., ASCII and extended
> ASCII, had a strong impact on standardizing 8-bit bytes for characters.

I would suggest EBCDIC had a strong effect on standardizing 8 bit bytes for
characters. I don't know what the timeline was but IBM ruled the world and
so did EBCDIC. Just depends where you are on the space time continuum. Now
everything's UNICODE so I guess the argument mutens somewhat.

> 
> > That basic platform still exists today obviously with many extensions as
> > System Z. Why do you keep trying to rewrite history?
> 
> I'm not.  Mainframes (plural) didn't standardize on IBM's System 360 design.
> Microprocessors did circa 1974.  Mainframes (plural) still hadn't done so by
> 1978.  How is that rewriting history?
> 
> > IBM solved all the problems Intel has today back in good old 1964.
> 
> What problems?

For you they might not be problems since Intel is what you know but when we
(IBM guys) look at Intel we ask stuff like 

  Do you really need to code a loop to move a string of characters or
  compare character strings longer than 4 or 8 or 16 bytes??? we haven't
  ever had to do that for strings less than 256 bytes and for 25 years or
  more not for strings of any length. To us that looks stupid.

  Do you really have only 8 "general purpose registers" and need 2 or 3 of
  those to reference the stack? We had 16 true honest to goodness gprs since
  the first series of machines. AMD fixed that with AMD64 but they didn't go
  far enough considering they had a chance. Given Intel's lack of storage to
  storage instructions we have in IBM you really need more registers to
  avoid playing hide and go seek on the stack all the time.

  Do you really have no register saving convention on Intel? Every OS and
  individual function defines what has to be on the stack and what registers
  have to be changed? We've had standard linkage for almost the whole
  history of the machine and OS and the implementations on Intel look
  broken.

There's a bunch more but I don't remember it all now.

> Well, too many systems, let me check ...  I don't have info on all of them.
> I did mean char size, but if talking address unit size then, unfortunately
> that's a "yes" ...  However, anyone a few years younger than me, can't
> answer that as a "yes".  So, shut up, you're ruining my point!  ;-)

Hehe I'm sure there are plenty of old guys around older than us. For one
thing check out comp.lang.fortran. There are some guys that know how to code
on vacuum tube computers...

The "other" Rod Pemberton

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

#14451 — Re: Learning to code by reading code

"Nomen Nescio" <nobody@dizum.com> wrote in message
news:8750f65b785c5d91c52e26dd628986d1@dizum.com...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:
> > "Nomen Nescio" <nobody@dizum.com> wrote in message
> > news:6b1b5349ea595142c8ad34fe494793ba@dizum.com...
> > > "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:
...

> > > > The first inherent problem with that argument is that
> > > > microprocessors have standardized on a basic computing
> > > > architecture.  Nearly all computing platforms today use that
> > > > architecture either because they are microprocessor based or
> > > > because they use the same hardware, e.g., memory.  They
> > > > standardized way back around 1974.  Mainframes followed
> > > > suit slightly later.
> > >
> > > No, mainframes had the architecture in place in 1964 with System 360.
> >
> > No, only *one* mainframe - singular - "had the architecture in
> > place ..."
>
> That's kind of a tautology since mainframe is like Kleenex or Jeep.
> There is really only one...
>

So, you mean ... Crays?  Oh, I see ...

It seems our resident IBM pundit offered us another "IBM [still] rules the
world" proclamation from some dystopian reality ...  I wouldn't classify
IBM's mainframes as an iconic brand.  As history has shown, no one wanted
IBM making their PCs either ...

In reality - which you apparently haven't been exposed to since they
locked you in a room in early 1960's - there are lots of mainframes,
minicomputers, supercomputers, e.g., Cray, Stratus, Tandems, VAX, ...

Wikipedia refers to "IBM and the Seven Dwarfs", so there are another seven
... etc.
http://en.wikipedia.org/wiki/Mainframe_computer

BTW...  After they let you out of that room, did you still see the color of
the walls?  How many years did it take for the color burn-in to fade?  Do
you find it harsh on the eyes to read non-orange or non-green text?  Are you
converting everything in your house to pixie tubes for the flicker or vacuum
tube glow?  How many boxes of programming manuals and photo-copied terminal
manuals do you have at home?  Do you plan on using them for kindling?  They
aren't on acid free paper you know ...  ;-)  Well, you can recycle the jokes
on your buddies at the next poker night, sporting event, or camping trip,
etc.

> > > IBM solved all the problems Intel has today back in good old 1964.
> >
> > What problems?
>
> For you they might not be problems since Intel is what you know

I know gp x86 and knew 6502.  Although I've not programmed them in
assembly, I've been exposed to Z80, 68000, DEC VAX, PA-RISC,
Transputer, etc.

> [...] but when we
> (IBM guys) look at Intel we ask stuff like
>
>   Do you really need to code a loop to move a string
>   of characters or compare character strings longer
>   than 4 or 8 or 16 bytes???

That's not necessary with x86, but that is a fast way and the slowest way.
There are three ways you can do that on x86: string instructions with a
repeat prefix (fastest or slowest depending), loop using the loop
instruction (slow), or loop using a conditional branch (fast).

>   [...] we haven't ever had to do that for strings less than 256 bytes
>   and for 25 years or more not for strings of any length.

The original 8086 (1978) had the string instruction
with repeat prefix.

> To us that looks stupid.

Ok.

>   Do you really have only 8 "general purpose registers" and
>   need 2 or 3 of those to reference the stack?

The 64-bit instruction set has more registers.  The 16-bit and 32-bit
instruction set has 8 GP registers.  You need one to reference a stack, if
you use a stack.  You need another one if you're using a certain style of
creating the linked-list for stack frames.  If you're using more than 2 or
3, you're doing something wrong anyway.  The instructions are well
distributed as to minimize need of them.

>   We had 16 true honest to goodness gprs since
>   the first series of machines.

So?

If "we" don't need or use that many registers, why is it important that
you have more than "us"? ...

>   AMD fixed that with AMD64 but they didn't go
>   far enough considering they had a chance.

They provided more of them, but register shortage wasn't and still isn't an
issue with the Intel, IMO.  It's only an issue with those from RISC
backgrounds, post 8-bit microprocessor backgrounds, or university professors
who continue to spread the myth of register starvation as if the problem
wasn't solved ...

>   Given Intel's lack of storage to storage instructions [...]

What do you mean by that?

For x86 (general purpose instructions), only one instruction is needed for
data moves from register-to-register, register-to-memory, stack-to-register,
or stack-to-memory (and vice-versa).  It's only memory-to-memory or
stack-to-stack that requires multiple instructions on x86.  Seriously, how
often do you do the latter on your precious IBMs?

>   Given Intel's lack of storage to storage instructions
>   we have in IBM you really need more registers to
>   avoid playing hide and go seek on the stack all the time.

(I'll take it there is an implied "versus what"  between
"instructions ... we have".)

You don't understand CISC do you?
http://en.wikipedia.org/wiki/Complex_instruction_set_computing

Didn't you ever code on an 8-bit microprocessor a non-orthogonal instruction
set?  I.e., in the pre-RISC and define all non-RISC as CISC era ...

CISC instruction sets aren't orthogonal.  This increases code density.  They
are also optimized to minimize register need.

It seems you also don't understand what a register reorder buffer (ROB) is
either, apparently.  A ROB allows renaming of a small number of registers
onto a larger set.  So, the P6 mapped those 8 registers to 96.  The actual
dependencies of register use between instructions is limited.  So, having
only a few named registers, isn't really much of an issue.

>   Do you really have no register saving convention on Intel?

There is MS' cdecl, which is fairly standard for non-GNU, non-FOSS software.
But, other compilers define their own also, e.g., GNU compilers use a
different combination.  OpenWatcom's C compiler can produce quite a few
combinations, including register only.  (Why am I hearing mental projections
of "... but the x86 is register starved ... "?)

http://en.wikipedia.org/wiki/X86_calling_conventions

There are also standardized object formats, e.g., TIS and OMF:
http://en.wikipedia.org/wiki/Relocatable_Object_Module_Format
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

>   Every OS and individual function defines what has to be on
>   the stack and what registers have to be changed? We've had
>   standard linkage for almost the whole history of the machine
>   and OS and the implementations on Intel look
>   broken.
...

> The "other" Rod Pemberton
>

Ok, could you please stop that?  I asked you before.

From using Google and Yahoo, I know what a few "other" Rod Pemberton's do
for a living.  One is a golfer.  One is a banker.  etc.  It'd be quite rare
if another was a programmer.  Of the more common names that begin with "Rod"
whose last name is Pemberton, there are supposedly these people living in
the US:

 4 Rod
 2 Roderick
 7 Rodgers
 1 Rodman


Rod Pemberton

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

#14405 — Re: Learning to code by reading code

On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
>
> news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
>
> ...
>
> > But I use an imaginary machine [...]

let's have some context:-

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

in other words I was talking about implementaion of novel language
features. Say virtual functions or closures in languages that support
them

> How do you confirm correctness of both high-level and low-level code with an
> imaginary machine?  Is your confirmation of correctness imaginary also? ...

for HLLs code walkthrus, code inspection, unit test, system test, use
of asserts.

I don't confirm correctness at the machine code level, but in
principle the same techniques apply.

<snip>

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

#14267 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:maintenance-20120219010917@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >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.

True.

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

True.

>   And the first step to do this properly is to read and to
>   understand that code that is to be modified.

No.

Again, you're biasing a novice's understanding with code they don't
understand which may be horrid.   The first step is for the person to become
proficient in the language.  They don't have to be a master, but they should
be strong in the language.  Once proficient, reading the code of others is
no longer a challenge and they can recognize the worth of the code they've
read.  If they're able to recognize that it's worthless, they can correct
it.  If they can't, they'll propagate that garbage forever via cut-n-paste.

>   So, training to
>   read code also is just a preparation for the very activity
>   that will most often be exercised when being a programmer.

No.


Rod Pemberton

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

#14277 — Re: Learning to code by reading code

> Again, you're biasing a novice's understanding with code they don't
> understand which may be horrid.   The first step is for the person to 
> become proficient in the language.

How to be proficient in the language without reading others' code, please? Maybe reading other's code is the first step whiling learning a language, after all, we have to read some code snippets and some demon that explain some functions written in this language. 

I recalled that when I begin to learn to play basketball, I will some vedio and NBA, watching other playing basketball including some of my friends. Of course they are not professional in playing basketball, but watching them playing not only give me fun, but also improve my skills, or impression.   

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

#14272 — Re: Learning to code by reading code

["Followup-To:" header set to comp.lang.misc.]
On 2012-02-19, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>>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.

Following that logic, you shouldn't look at "master's" code either, since
the code you will be maintaining most likely won't be done by a "master".

Finding tricks to analyse dodgy code won't be learned by looking at perfect
oode.

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

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

On Feb 18, 12:56 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Newsgroups: comp.lang.c++,comp.lang.misc
> Followup-To: comp.lang.misc
>
> Stanley Rice <hecong...@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:
>
>     - 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.

I suggest "chewing the meat and spitting the bones" with Boost.
Some of it is great, but not all of it.


Brian
Ebenezer Enterprises
http://webEbenezer.net

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

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

在 2012年2月19日星期日UTC+8下午12时02分27秒，Ebenezer写道：
> On Feb 18, 12:56 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> > Newsgroups: comp.lang.c++,comp.lang.misc
> > Followup-To: comp.lang.misc
> >
> > Stanley Rice <hecong...@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:
> >
> >     - 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.
> 
> I suggest "chewing the meat and spitting the bones" with Boost.
> Some of it is great, but not all of it.
> 
> 
> Brian
> Ebenezer Enterprisessort 
> http://webEbenezer.net

I am interested in the vector and the map part
which can support the desired auto-size management only.

For sets of cardinals within 16 bits, I'll use my own
library. 

For sparse binary trees of n levels ,
 I'll use the heap sort style map.

But I solve problems by abstract sets, graphs and trees. 
   

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

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

Ebenezer wrote:
> On Feb 18, 12:56 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Newsgroups: comp.lang.c++,comp.lang.misc
>> Followup-To: comp.lang.misc
>>
>> Stanley Rice <hecong...@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:
>>
>> - 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.
>
> I suggest "chewing the meat and spitting the bones" with Boost.
> Some of it is great, but not all of it.
>
>

Yes, some libaries are so full of configuration macros and workarounds 
for ancient compilers that you will have a hard time even finding some 
code.

Been there, done that.


Bo Persson

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

#14394

* Stanley Rice wrote (on 2/17/2012 4:55 PM):
>
> 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.

That is why reference manuals are not a good way to learn a language.
They are not even a good way to learn whatever they describe.  They
are primarily to give you the details you need to use something
properly once you understand the basic concepts behind it.

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

Again, tutorials are available all over the web that describe the basics
of just about anything you need to learn.  Once you get past the simpler
mechanics of something you can go back to the reference documents to
pick up some important details.

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

This is why reading someone's code isn't a good way to learn
'programming'.  Though you will pick up some ideas you will need to
go through *many* people's code to really begin to understand the
common uses that make a language work well (also called the 'idioms'
or 'patterns' of a language).

Understanding general software design principles will also help in
picking up the reasons for approaching a problem a particular way
in any given language.  But as Juha pointed out any given program
is a *particular solution* to a problem and not necessarily the
*best* solution.  And even *best* can differ based on the constraints
placed on the developers (time/space tradeoffs, for example).

Mark

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

#14146

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

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

#14142

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::push_back, list::push_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.

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

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

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

csiph-web