The way to read STL source code

[Nick Keighley]

wrote: news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...>

If the HLL is correct the machine code is correct [...]

you're a dissembling so and so aren't you? Every time you quote me I
have to check you got the quote right. What was written was:-

*********************************************

a) "Verifies" how?

um... "verify" n. to confirm the correctness of.

If the HLL is correct the machine code is correct (barring unobserved
side effects). Do these happen a lot?
*********************************************

You had trouble with "verifies" so I simplified it for you. It is
plain in context I'm talking about verification.

This assumes the HLL code and machine code are 100% identical.

well yes. As far as the side effects of evaluation are concerned they
*are* identical. How can you execute the HLL without executing the
machine code?

 That assumes
the compiler is 100% perfect in it's translation.

no. I assume compilers are very very good. I tend to truct the
implementors.

and no. Because testing the hLL will reveal potential compiler bugs.

That also assumes the
libraries are 100% perfect in their implementation.  The HLL code can be
100% correct syntactically and the generated machine code can be wrong.

library bugs are commoner than compiler bugs. But as above.

[...] whatever was "verified" didn't trigger or run
into the error.

doesn't this apply to both HLL and machine code?

If you can interpret the HLL code and you can compile it to machine code
too, then yes.  Otherwise, no, it only applies to the machine code since the
HLL can't be fully "verified" except by compiling it to machine code.

many 9's close though.

Machine code is validated as a side-effect of HLL validation.
[...]
And, just because a program currently works correctly with
the input sets you've tried, doesn't mean it will later with a
different data set or different combination of user selections.

this applies to all forms of testing. [...]

If you don't take issues here, why do you do so above?!
what?

what makes you think verifying machine code is any easier
than verifying HLL code?

I didn't say it is.

so why do you recomemnd examining the machine code?
I really don't understand what you are getting at. From my point of
view, looking at the assmbler is another form of verification. I don't
see it as a useful or cost effective one.

By compiling and studying the output for all the language elements, type
conversions, etc you use to understand if your compiler is emitting them
correctly,

ah! So you are essentially validating the compiler. I suspect high
levels of optimsation will render this useless. Like I've said the
rate of compiler bugs seems so low I leave that to compiler
developers. And so do most people I know.

or that your understanding of what the HLL code does is correct
in terms of the assembly.  You don't have study the entire output of a large
program.

ok. Misunderstood you.

 

[88888 Dihedral]

在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：

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

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

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

Thanks in advance.

在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：

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

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

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

Thanks in advance.

I suggest you should play with data structure related functions or objects
in some higher level languages, such as perl, python, or smalltalk.

I use only the vector of void * pointers in the heap most of the time,
and the faster hash map for at least 8K of entries.

The set, tree and graph parts can be replaced.

 

[Jorgen Grahn]

Am 20.02.2012 10:14, schrieb Rod Pemberton:

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

 

[BartC]

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!

 

[88888 Dihedral]

在 2012å¹´2月26日星期日UTC+8上åˆ2æ—¶46分59秒，88888 Dihedral写é“：

在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：



在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：


I suggest you should play with data structure related functions or objects
in some higher level languages, such as perl, python, or smalltalk.

I use only the vector of void * pointers in the heap most of the time,
and the faster hash map for at least 8K of entries.

The set, tree and graph parts can be replaced.

在 2012å¹´2月26日星期日UTC+8上åˆ2æ—¶46分59秒，88888 Dihedral写é“：

在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：



在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：


I suggest you should play with data structure related functions or objects
in some higher level languages, such as perl, python, or smalltalk.

I use only the vector of void * pointers in the heap most of the time,
and the faster hash map for at least 8K of entries.

The set, tree and graph parts can be replaced.

By the way , one hash or dictionary designed well can replace any set
of finite number of elements and also any binary tree or n-ary tree of
finite number of nodes whenever not out of the heap space.

It needs two dictionaries to represent a connected directed graph.

 

[Nick Keighley]

在 2012å¹´2月17日星期五UTC+8下åˆ3æ—¶18分39秒，Stanley Rice写é“：

I am familiar with using STL, including the algorithm and the
containers,
however, how they are implemented. Some of my friends recommend me to
read the source code of STL directly.
[...] hoping some of you could give me some
advice,
and I will keep it up.

I suggest you should play with data structure related functions or objects
in some higher level languages, such as perl, python, or smalltalk.

not sure how this will help with C++

I use only the vector of void * pointers in the heap most of the time,
and the faster hash map for at least 8K of entries.

note to original poster, Dihedral has some odd opinions on a few
topics (notably on the utility of assembly code) and this way of using
data structures may be one of them. Most high level C++ avoids void*

The set, tree and graph parts  can be replaced.

if this made any sense I'd probaly disagree with it.