"Variables" tutorial available (Windows, mingw/msvc)

[Alf P. Steinbach]

A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
http://groups.google.no/gr******************************@news.individual.n et>.

As I wrote then:

<quote>
because there seems to be a lack of post-standard _correct_
tutorials: <url: http://home.no.net/dubjai/win32cpptut/>.
</quote>

This is the follow up, part 02, discussing variables (the directory
referred above contains two documents, part 01 and part 02).

I aim at the complete newbie, but as the earlier debate showed, even for
these fundamental topics there were things to be learned also for far
more experienced C++ folks.

I hope I haven't committed too many errors of my own ( ;-) ), and look
forward to corrections -- just not "it's too long", every word counts.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Tim Love]

al***@start.no (Alf P. Steinbach) writes:

A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
http://groups.google.no/gr******************************@news.individual.n et>. As I wrote then: <quote>
because there seems to be a lack of post-standard _correct_
tutorials: <url: http://home.no.net/dubjai/win32cpptut/>.
</quote>

To put Word docs online to deal with a lack of online post-standard
documentation seems odd to me.

[Alf P. Steinbach]

* Tim Love:

al***@start.no (Alf P. Steinbach) writes:

A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
http://groups.google.no/gr******************************@news.individual.n et>.

As I wrote then:

<quote>
because there seems to be a lack of post-standard _correct_
tutorials: <url: http://home.no.net/dubjai/win32cpptut/>.
</quote>

To put Word docs online to deal with a lack of online post-standard
documentation seems odd to me.

Yes, it would be (there _is_ no lack of online post-standard
documentation, but there is an apparent lack of online tutorials).

I use Word just for my convenience as writer; feel free to generate PDF
and/or XHTML or whatever -- just include a reference to the original
which might be updated.

For part 01 someone suggested (don't know how seriously) he could
convert to proper HTML, but until someone does, I've reacted to your
feedback by simply also posting Word-generated HTML versions, tested in
Firefox. It works, sort of. But it's not easy on the eye... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Thomas Hansen]

Page 7, line "Welcome to C++, Målfrid Sæbo!" should probably be
"Welcome to C++, Malfrid Sabo!" since you're trying to show that æøå
changes...?!?

BTW!
Why don't you make a complete book and make it public?
GPL maybe?!?
There are other good books GPL licensed, but none about C++ I think...
That would be GREAT since many people can't afford the prices that the
(good) C++ books are costing and as a consequence therefor buy CRAPPY
books and ends up writing CRAPPY code...!!
Also this would probably "force" schools to use YOUR book instead of
some crappy old junk book teaching all the wrong things...

And also I think in such a chapter it would be apropriate to maybe
introduce command line arguments...?
So maybe instead of reading string from cin parse some command line
arguments and "spit out"...
Might be it's too early to introduce com. line params., but I think not
since you may "push" parts of the understanding forward (pointers,
arrays etc...)

There's a good class in SmartWin (I believe you know where to find it
;) which parses command line params...

BTW2!
Let me know when you finish it if you're going "public" (I think you
know what email address I've got ;) since I would love to host it at
the SmartWin website...
SmartWin draws alot of attention from C++ newbies since it's
syntactically very easy so having a beginners book about the language
there too would be awesome!!

..t

[Thomas Hansen]

page 14...
"C++ has a bunch of different assignment operators:"

List them all!
Don't leave the readers in vain...
The reader won't care about the list in the first readthrough, but
afterwards when he need a special assignment operator he'll remember
"that book had a list about here..."...

..t

[Thomas Hansen]

also page 14...
Tell about the difference of:
++x;
and:
x++;
Maybe like:

 
#include <ostream>
int main()
{
int x = 5;
std::cout << x << std::endl;
std::cout << ++x << std::endl;
std::cout << x << std::endl;
std::cout << x++ << std::endl;
std::cout << x << std::endl;
}
 
 

Yet again, this will be "overkill" for a newbie, but when he needs the
info he'll use the book as a reference...

Also you should probably bring up the "for( int x; x < 5; x++ )"
misunderstanding...
A lot of programming gurus (from e.g. Java camp) I've met have gotten
this one wrong and thinks that the increment part happens BEFORE the
body of the loop...
I know you're trying to keep a structure in the book where "branching"
probably comes in the chapter AFTER this one, but still it might be
good to at least point to a page in the book or use a footnote about
the issue since it's more "post/pre inc/decr operator" related then
"looping" related...
also:
"OK, what next? I don't know, but probably an overview of built-in
types and operations."
First of all I would have covered all built in types in this chapter,
second I would jump to LOOPS!
Now the reader is Querious, keep him there by showing him some FUN
stuff...

(I remember the days of...)
10 CLS
20 PRINT "Thomas"
30 GOTO 20

....Those were the chapters making it worthwile to read books about
programming....

And btw...
Very good initiative!
When I started C++ I searched the net for a good tutorial and basically
all I found sucked!
This made it MUCH harder for me to learn the language then it would
have been if I had a good tutorial (or bought a good book... ;) )

..t

[Stephan Brönnimann]

I did send you the HTML file together with a CSS stylesheet.
Never got the e-mail I've send to you privately?
If so send an email to broeni[skip until @...]@hotmail.com.
Or: should I publish temporarly on my website?

regards,
Stephan Brönnimann
br****@osb-systems.com
http://www.osb-systems.com
Open source rating and billing engine for
communication networks.

[Alf P. Steinbach]

* Thomas Hansen:

Page 7, line "Welcome to C++, M=E5lfrid S=E6bo!" should probably be
"Welcome to C++, Malfrid Sabo!" since you're trying to show that =E6=F8=E5
changes...?!?
Nope. I'm not typing those examples in the word processor.

I'm copying them, copy/paste, from my console window so they're
100% accurate for at least _one_ actual Windows setup.

Exception: some places I've changed the filenames afterwards, and just
hope I haven't introduced any errors that way.

Depending on the setup of Windows non-English letters might appear
differently: differently when typed, and when displayed as output from a
program.

Norwegian æ, Æ, å and Å are however part of the original IBM PC English
character code (code page 437). It just lacked ø and Ø, which meant
that for years without end we had to struggle with various custom
encodings resulting in ø and Ø often being rendered as | and \, or as ¢
and ¥, respectively. This ended with the introduction of the Windows
ANSI character code (code page 1252), which is/was based on an early
ANSI draft of what later became ISO Latin-1, the character code I'm
using right here and which is still the most common one on the Usenet
and WWW. For that particular example which involved a round-trip with
no other conversion than the console window's own conversion, æÆåÅ will
typically not be affected, because AFAIK all common Western narrow
character codes that are typical for console Windows have those
characters. However, if the program had tried to open a file with a
name provided by the user, then the user's typing would be in e.g. code
page 437, but in the program and vis-a-vis the Windows API (used at
bottom by C++ file handling) the filename would be interpreted according
to code page 1252, and _all_ of æÆøØåÅ would be affected (no such file).
[snip] And also I think in such a chapter it would be apropriate to maybe
introduce command line arguments...?

Thanks for the suggestion.

Yes it is a problem.

But that requires at minimum indexing, and probably loops to be useful,
which I think is premature at that point (dealing with variables
for the first time, and having to master a lot of seemingly arbitrary &
cryptic tool usage details, having only made "Hello, world!" earlier).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Thomas Hansen:

page 14...
"C++ has a bunch of different assignment operators:"

List them all!
Don't leave the readers in vain...
The reader won't care about the list in the first readthrough, but
afterwards when he need a special assignment operator he'll remember
"that book had a list about here..."...

.t

Good point.

Will do.

I thought it was enough to provide a general rule, but now I see that
that rule should be followed by its concrete result: a table listing all
of the assignment operators.

Btw., page numbers seem to depend on e.g. font and page size, it's my
page 13 -- the Bad Luck page! ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* =?iso-8859-1?q?Stephan_Br=F6nnimann?=:

I did send you the HTML file together with a CSS stylesheet.
Never got the e-mail I've send to you privately?
If so send an email to broeni[skip until @...]@hotmail.com.
Or: should I publish temporarly on my website?

I got it an hour or two ago (I think). Thanks very much. I replied to
your mail then.

The mail account is my web-based Usenet mail account so I don't
check it very often.

I'll send you a mail from my regular account... ;-)

It looked great in FireFox, just some details I saw after replying to
your mail: the special characters arrow -> and left triangle <| were
translated to something and ordinary "<". Right arrow is HTML
"&rarr;" or "→". Left triangle (used for end-of-code) I don't
know, but perhaps just a left arrow instead, "&larr;" or "←"
(which corresponds very nicely with usual rendering of Ctrl Z used as
end-of-file in Windows text files)?

Your website is perhaps best because you can more easily update
changes.

Can I put your HTML version in the same directory as the Word files
(one of my web sites)?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Stephan Brönnimann]

Alf P. Steinbach wrote:
[snip]

[snip]

And also I think in such a chapter it would be apropriate to maybe
introduce command line arguments...?
Thanks for the suggestion.

Yes it is a problem.

But that requires at minimum indexing, and probably loops to be

useful, which I think is premature at that point (dealing with variables
for the first time, and having to master a lot of seemingly arbitrary & cryptic tool usage details, having only made "Hello, world!" earlier).

I'd not introduce command line arguments now:
many poeple don't know the POSIX function getopt(...),
and I guess it would be a good idea to provide a wrapper
base class around it in the tutorial. See
http://dev.robotbattle.com/~cvsuser/...pp?view=markup
for an example.

regards,
Stephan Brönnimann
[e-mail]
http://www.osb-systems.com
Open source rating and billing engine for
communication networks.

[Alf P. Steinbach]

* =?iso-8859-1?q?Stephan_Br=F6nnimann?=:

Alf P. Steinbach wrote:
[snip]

[snip]

And also I think in such a chapter it would be apropriate to maybe
introduce command line arguments...?

Thanks for the suggestion.

Yes it is a problem.

But that requires at minimum indexing, and probably loops to be

useful,

which I think is premature at that point (dealing with variables
for the first time, and having to master a lot of seemingly arbitrary

&

cryptic tool usage details, having only made "Hello, world!"

earlier).

I'd not introduce command line arguments now:
many poeple don't know the POSIX function getopt(...),
and I guess it would be a good idea to provide a wrapper
base class around it in the tutorial. See
http://dev.robotbattle.com/~cvsuser/...v2/trunk/src/=
utils.hpp?view=3Dmarkup
for an example.

Thank you for that suggestion.

What about <url: http://www.boost.org/doc/html/program_options.html>?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Thomas Hansen:

also page 14...
Tell about the difference of:
++x;
and:
x++;
Maybe like:
[code]
Was already there, a whole section devoted to it: the last one.
Also you should probably bring up the "for( int x; x < 5; x++ )"
misunderstanding...
A lot of programming gurus (from e.g. Java camp) I've met have gotten
this one wrong and thinks that the increment part happens BEFORE the
body of the loop...
Not much of programming gurus, then: it's the same in Java as in C++.

I think that must be a misunderstanding peculiar to a given project
group or firm (or educational institution...).

I've never encountered it, neither as a lecturer nor as a consultant.
[snip] also:
"OK, what next? I don't know, but probably an overview of built-in
types and operations."
First of all I would have covered all built in types in this chapter,
second I would jump to LOOPS!
Now the reader is Querious, keep him there by showing him some FUN
stuff...

(I remember the days of...)
10 CLS
20 PRINT "Thomas"
30 GOTO 20

...Those were the chapters making it worthwile to read books about
programming....
You got your wish!

Well, not quite, I've decided to just give some interesting examples of
counter-based loops, continuing the counting theme, and then (if I have
time before the New Year), in what will become the fourth part, some
loop-based picture generation to illustrate use of libraries.

Many others (including myself in earlier writings) also seem to think
that going from variables to loops is a good idea -- perhaps because
it _is_?

And btw...
Very good initiative!
When I started C++ I searched the net for a good tutorial and basically
all I found sucked!
This made it MUCH harder for me to learn the language then it would
have been if I had a good tutorial (or bought a good book... ;) )

Thanks.

Btw., the URL is now <url: http://home.no.net/dubjai/win32cpptut/html/>,
but right now when I'm writing this the server is down (very seldom
happens, but).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Buster]

Alf P. Steinbach wrote:

I hope I haven't committed too many errors of my own ( ;-) ), and look
forward to corrections -- just not "it's too long", every word counts.
One big error I noticed:
But consider

x = 0;
x = (x + 7) + (x = 5);
[...]
It’s not as bad as the undefined behavior, UB, we have encountered
twice, where the program in theory could crash or hang or willy-nilly
overwrite files on your harddisk, whatever. This is merely an
unspecified result – the standard doesn’t say which of the two results
– but it’s bad enough.

I'm afraid it is undefined behaviour, since x is modified twice without
an intervening sequence point. That's quite separate from your point
about unspecified order of evaluation.

Here's an example with an unspecified result but no undefined behaviour:

int f (int & x)
{
return x += 7;
}

int g (int & x)
{
return x = 5;
}

int x (0);
x = f (x) + g (x); // 12 or 17?

Sorry that's a little complicated but only the function-call sequence
point seems to be any use in constructing an example, since the others
are more tightly tied up with order of evaluation. Perhaps this would
be easier to explain:

int f (int x)
{
static int y = 1;
int result = x * y;
++ y;
return result;
}

int x = f (10) + f (100); // 210 or 120?

--
Regards,
Buster

[Thomas Hansen]

> Not much of programming gurus, then: it's the same in Java as in C++.

There was (off course) a bug in my sample...
I ment this:
for( int x=0; x < 10; ++x )
{
foo();//
}

The point here is that since people have read that the pre increment
operator increments its variable before the expression is evaluated
most people tend to believe that the above will work different then
this:
for( int x=0; x < 10; x++ )
and that the first one will increment the variable before the body of
the loop is executed for the first time...
In fact I did believe so too for my first year of C++ programming...
This is a point of confusion for many either newbies or people from
other camps then the C++ camp...
And I can truly understand why it feels natural to believe...

But you're true regarding that it's the same in Java, but I figure if
you ask people on this group too at least say 10-20 % would believe it
worked the way it doesn't work...

..t

..t

[Alf P. Steinbach]

* Buster:

Alf P. Steinbach wrote:

I hope I haven't committed too many errors of my own ( ;-) ), and look
forward to corrections -- just not "it's too long", every word counts.
One big error I noticed:

But consider

x = 0;
x = (x + 7) + (x = 5);

[...]

It’s not as bad as the undefined behavior, UB, we have encountered
> twice, where the program in theory could crash or hang or willy-nilly
> overwrite files on your harddisk, whatever. This is merely an
> unspecified result – the standard doesn’t say which of the two results
> – but it’s bad enough.

I'm afraid it is undefined behaviour, since x is modified twice without
an intervening sequence point. That's quite separate from your point
about unspecified order of evaluation.

Thanks.

I would like some more comments on this though because I'm not
sure you're right! ;-) In fact I'm quite sure it's not undefined
behavior because logic dictates so (no possibly undefined thing
involved, only ordering of evaluation) and the examples in §5/4 are
equivalent to mine and are noted as _unspecified_ behavior -- so if
I'm wrong, so is the non-normative part of the standard. But I can't
find the relevant support for that in the normative text, except to the
degree simple common sense logic is involved.

Here's an example with an unspecified result but no undefined behaviour:

int f (int & x)
{
return x += 7;
}

int g (int & x)
{
return x = 5;
}

int x (0);
x = f (x) + g (x); // 12 or 17?

As far as I can see those examples invoke the same §5/4 as the original
example? Note that a function call doesn't introduce an ordering
constraint (sequence point) for the expression in which it appears.
There are a few sequence points involved in the call itself, namely
after the evaluation of arguments and after the copying of the return
value (defined by §1.9/16), but those don't affect the caller.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Buster]

Alf P. Steinbach wrote:

* Buster:

Alf P. Steinbach wrote:

I hope I haven't committed too many errors of my own ( ;-) ), and look
forward to corrections -- just not "it's too long", every word counts.
One big error I noticed:

But consider

x = 0;
x = (x + 7) + (x = 5);

[...]

It’s not as bad as the undefined behavior, UB, we have encountered

> twice, where the program in theory could crash or hang or willy-nilly
> overwrite files on your harddisk, whatever. This is merely an
> unspecified result – the standard doesn’t say which of the two results
> – but it’s bad enough.

I'm afraid it is undefined behaviour, since x is modified twice without
an intervening sequence point. That's quite separate from your point
about unspecified order of evaluation.

Thanks.

I would like some more comments on this though because I'm not
sure you're right! ;-) In fact I'm quite sure it's not undefined
behavior because logic dictates so (no possibly undefined thing
involved, only ordering of evaluation)

Logic dictates nothing in a vacuum (ex nihilo nihil fit, or something
like that) but we can make logical deductions from the standard. This
case seems clear: 5/4 says " ... otherwise the behaviour is undefined"
- the comments in the code examples say "unspecified", therefore one or
the other is wrong. It's unfortunate, but I'm confident the text is
correct and the comments incorrect.
and the examples in §5/4 are
equivalent to mine and are noted as _unspecified_ behavior -- so if
I'm wrong, so is the non-normative part of the standard. But I can't
find the relevant support for that in the normative text, except to the
degree simple common sense logic is involved.
You didn't look very hard! Read the last sentence of 5/4.

Here's an example with an unspecified result but no undefined behaviour:

int f (int & x)
{
return x += 7;
}

int g (int & x)
{
return x = 5;
}

int x (0);
x = f (x) + g (x); // 12 or 17?

As far as I can see those examples invoke the same §5/4 as the original
example? Note that a function call doesn't introduce an ordering
constraint (sequence point) for the expression in which it appears.

Huh?

In my example, there is a sequence point just before "x += 7" (the
sequence point after the evaluation of all the arguments to f) and a
sequence point just after "x += 7" (the sequence point after the return
value of f is copied). Similarly there are sequence points before and
after "x = 5" in g. So whatever the order of evaluation turns out to
be, the modifications of x in f and g are 'isolated' from each other and
from the final assignment to x. Therefore my example can _never_ invoke
UB.

In your example "x = (x + 7) + x = 5;" there is exactly one sequence
point, which occurs at the end of the full expression. Therefore there
can never be a sequence point between the two attempts to modify x,
and the behaviour is _always_ undefined.
There are a few sequence points involved in the call itself, namely
after the evaluation of arguments and after the copying of the return
value (defined by §1.9/16), but those don't affect the caller.

"those don't affect the caller" is not a very precise statement. I'm not
sure what you mean.

--
Regards,
Buster

[Alf P. Steinbach]

* Buster:

It's unfortunate, but I'm confident the [Holy Standard's] text is
correct and the [Holy Standard's] comments incorrect.
Well, I'm confident that the comments are correct, as they are very
concrete examples. But that does not necessarily mean that the text is
incorrect. I've posted a question about this to clc++m.

Here's an example with an unspecified result but no undefined behaviour:

int f (int & x)
{
return x += 7;
}

int g (int & x)
{
return x = 5;
}

int x (0);
x = f (x) + g (x); // 12 or 17?

As far as I can see those examples invoke the same §5/4 as the original
example? Note that a function call doesn't introduce an ordering
constraint (sequence point) for the expression in which it appears.

Huh?

In my example, there is a sequence point just before "x += 7" (the
sequence point after the evaluation of all the arguments to f) and a
sequence point just after "x += 7" (the sequence point after the return
value of f is copied). Similarly there are sequence points before and
after "x = 5" in g. So whatever the order of evaluation turns out to
be, the modifications of x in f and g are 'isolated' from each other and
from the final assignment to x. Therefore my example can _never_ invoke
UB.

Those sequence points are internal to the calls. They do not affect the
evaluation order of the expression the calls appear in. The term
"sequence point" is not some abstract unconnected term: it is a point
between re-orderable parts of an expression, a point that is guaranteed
to come in execution sequence after the previous such such point (and
the standard's various definitions of where sequence points are are the
details necessary to achieve that meaning), so the function call example
does not have any sequence point in the full-expression.

Look it another way: the compiler is permitted to reorder f(x)+g(x) as
g(x)+f(x), and if not then the example could not be "unspecified" as you
maintain it is.

Thus there is _no_ sequence imposed on the expression the calls appear
in, and hence _no_ sequence point in that expression: "previous" and
"next" sequence points in §5/4 do not refer to what happens down in
called functions, but in the expression under discussion.

Hence §5/4 applies, you have modified more than once between sequence
points in the expression, and if the standard's e.g. "x = ++x + 1"
example is UB according to that, then so is your example.

But I'm quite sure that neither is "undefined", defined in §1.3.12, just
"unspecified", defined in §1.3.13, and that that's why the standard says
"unspecified" in the concrete examples.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Buster]

Alf P. Steinbach wrote:

* Buster:

It's unfortunate, but I'm confident the [Holy Standard's] text is
correct and the [Holy Standard's] comments incorrect.

Well, I'm confident that the comments are correct, as they are very
concrete examples. But that does not necessarily mean that the text is
incorrect. I've posted a question about this to clc++m.

You know what? I didn't read the first sentence of 5.4, but concentrated
on the other two sentences. Those commented code examples make much more
sense to me now, but it still seems to me that 5.4 says the first and
third invoke undefined behaviour.

Do let us know what clc++.moderated thinks.

For the benefit of those on this newsgroup who haven't got the standard
to hand,

5/4:
Except where noted, the order of evaluation of operands of individual
operators and subexpressions of individual expressions, and the order in
which side effects take place, is unspecified [footnote]. Between the
previous and next sequence point a scalar object shall have its stored
value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be accessed only to determine the
value to be stored. The requirements of this paragraph shall be met for
each allowable ordering of the subexpressions of a full expression;
otherwise the behaviour is undefined.

[Example:

i = v [i++]; // the behaviour is unspecified
i = 7, i ++, i ++; // i becomes 9
i = ++i + 1; // the behaviour is unspecified
i = i + 1; // the value of i is incremented
--end example]

[footnote] The precedence of operators is not directly specified, but it
can be derived from the syntax.

Here's an example with an unspecified result but no undefined behaviour:

int f (int & x)
{
return x += 7;
}

int g (int & x)
{
return x = 5;
}

int x (0);
x = f (x) + g (x); // 12 or 17?
As far as I can see those examples invoke the same §5/4 as the original
example? Note that a function call doesn't introduce an ordering
constraint (sequence point) for the expression in which it appears.

Huh?

In my example, there is a sequence point just before "x += 7" (the
sequence point after the evaluation of all the arguments to f) and a
sequence point just after "x += 7" (the sequence point after the return
value of f is copied). Similarly there are sequence points before and
after "x = 5" in g. So whatever the order of evaluation turns out to
be, the modifications of x in f and g are 'isolated' from each other and
from the final assignment to x. Therefore my example can _never_ invoke
UB.

Those sequence points are internal to the calls.

In what sense?
They do not affect the
evaluation order of the expression the calls appear in.
Of course not.
The term
"sequence point" is not some abstract unconnected term: it is a point
between re-orderable parts of an expression, a point that is guaranteed
to come in execution sequence after the previous such such point (and
the standard's various definitions of where sequence points are are the
details necessary to achieve that meaning), so the function call example
does not have any sequence point in the full-expression.
I don't think it follows. To give you something to push against, I will
say that I am thinking of the chronological ordering of inspections,
modifications and sequence points, not some lexical ordering. Therefore,
no matter in what order the subexpressions of "x = f (x) + g (x)" are
evaluated, the eventual evaluation of "f (x)" involves two sequence
points (sorry, three: i didn't mention the one at the end of "x += 7;"
which is itself a full expression), as does the evaluation of "g (x)",
and so those six sequence points occur, (at unspecified points) in time,
during the evaluation of the full expression.
Look it another way: the compiler is permitted to reorder f(x)+g(x) as
g(x)+f(x), and if not then the example could not be "unspecified" as you
maintain it is.
Sorry, you've lost me. Are you saying I've confused the issues of
sequence points and unspecified order of evaluation? Because I don't
think I have. f (x) must be evaluated 'all at once', and so must g (x).
Thus there is _no_ sequence imposed on the expression the calls appear
in, and hence _no_ sequence point in that expression: "previous" and
"next" sequence points in §5/4 do not refer to what happens down in
called functions, but in the expression under discussion.

Hence §5/4 applies, you have modified more than once between sequence
points in the expression, and if the standard's e.g. "x = ++x + 1"
example is UB according to that, then so is your example.
Well, I can sort of see that you might be right there. But you sneaked
in those three little words "in the expression", which are not in the
text of the standard. As far as I can see, the sequence points involved
in evaluating f and g are as much "in the expression" as the sequence
point after the evaluation of the full expression.
But I'm quite sure that neither is "undefined", defined in §1.3.12, just
"unspecified", defined in §1.3.13, and that that's why the standard says
"unspecified" in the concrete examples.

But the standard says (right out loud) that it _is_ undefined behaviour.
That's what the latter two sentence of 5/4 say. If "i = ++i + 1;"
doesn't invoke undefined behaviour in virtue of those sentences, then
what does?

Hold on, I might have just come up with a killer point. Look again at
the first commented code example after 5.4:

i = v [i++]; // the behaviour is unspecified

(i) There is no order-of-evaluation problem here (do you agree?).
(ii) If v is an std::vector (for instance), then [] is a real function
call. If I'm right about the relevance of sequence points in
functions to the evaluation of the calling expression, then it follows
that there is no problem whatsoever, and the behaviour is defined and
the result is specified. So (if I'm right) we have to assume [] is the
builtin subscript operator: that v and i are a pointer (or an array) and
an integer (but not necessarily in that order). (Getting a headache?)
(iii) Making that assumption, the only remaining problem is the lack of
a sequence point between the two modifications of i. (Huh? HUH?)
(iv) Therefore either the behaviour is undefined (I maintain it is),
or the result is specified. In either case the comment is wrong. What
do you think?

Note that the comment does not say "the result is unspecified", which
would be very clear.

BTW, I hope you're enjoying our little discussion.

--
Regards,
Buster.

[Buster]

Buster wrote:

You know what? I didn't read the first sentence of 5.4, but concentrated
on the other two sentences.

(and throughout): three sentences. Oops.

--
Regards,
Buster

[Alf P. Steinbach]

* Alf P. Steinbach:

A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
http://groups.google.no/gr******************************@news.individual.n et>.

As I wrote then:

<quote>
because there seems to be a lack of post-standard _correct_
tutorials: <url: http://home.no.net/dubjai/win32cpptut/>.
</quote>

This is the follow up, part 02, discussing variables (the directory
referred above contains two documents, part 01 and part 02).

I aim at the complete newbie, but as the earlier debate showed, even for
these fundamental topics there were things to be learned also for far
more experienced C++ folks.

I hope I haven't committed too many errors of my own ( ;-) ), and look
forward to corrections -- just not "it's too long", every word counts.

I've now replaced the original with a an updated version that includes a
table of assignment operators, as suggested by Thomas Hansen.

Also, I changed the wording in the advice "Do not use the the ++ and
-- operators in expressions, except idiomatic usage" to "Do not use the
result values of the ++ and -- operators, except idiomatic usage",
because although understandable it was technically meaningless.

The section about unspecified versus undefined value is unchanged
although contested; I've posted a question about it to clc++m and await
some clarification (if possible), but basically I think it's correct as
it stands since it's simply the Holy Standard's example in disguise.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Buster:

Alf P. Steinbach wrote:

Those sequence points are internal to the calls.
In what sense?

That they do not affect the evaluation order of the expression the calls
appear in. The first one, going in, ensures that arguments are fully
evaluated when the function starts executing. The last one, going out,
ensures that the function result copying (if any) is complete before
e.g. a destructor is called for the function result.

They do not affect the
evaluation order of the expression the calls appear in.

Of course not.

Right... ;-)

The term
"sequence point" is not some abstract unconnected term: it is a point
between re-orderable parts of an expression, a point that is guaranteed
to come in execution sequence after the previous such such point (and
the standard's various definitions of where sequence points are are the
details necessary to achieve that meaning), so the function call example
does not have any sequence point in the full-expression.

I don't think it follows. To give you something to push against, I will
say that I am thinking of the chronological ordering of inspections,
modifications and sequence points, not some lexical ordering. Therefore,
no matter in what order the subexpressions of "x = f (x) + g (x)" are
evaluated, the eventual evaluation of "f (x)" involves two sequence
points (sorry, three: i didn't mention the one at the end of "x += 7;"
which is itself a full expression), as does the evaluation of "g (x)",
and so those six sequence points occur, (at unspecified points) in time,
during the evaluation of the full expression.

I agree that they are executed in sequence (chronological ordering) _for
the sequence they apply to_, that's the point of having them.

What you have with f(x)+g(x) is however a hierarchy, not a linear
sequence.

The sequence points for the sequence of events in calling f are executed
in sequence. Likewise those for g. But the compiler is free to reorder
the top expression as g()+f(), because there's no sequence point there.

Look it another way: the compiler is permitted to reorder f(x)+g(x) as
g(x)+f(x), and if not then the example could not be "unspecified" as you
maintain it is.

Sorry, you've lost me. Are you saying I've confused the issues of
sequence points and unspecified order of evaluation? Because I don't
think I have. f (x) must be evaluated 'all at once', and so must g (x).

Well I haven't said, but for what I'm thinking about what you might be
thinking (ha, philosophy enters clc++!), I think you may have needlessly
_differentiated_ between the concepts of sequence points and defined
evaluation order (sequence points are there to define the order),
and based on your comment about non-interference I think there's at
least a 40% dependent chance that you might then be thinking about
parallellism of some sort, which if you are would probably (75%
dependent chance?) stem from a need to make sense of the concept of
sequence point isolated from evaluation order: "it must mean something".
[snip] But the standard says (right out loud) that it _is_ undefined behaviour.
That's what the latter two sentence of 5/4 say. If "i = ++i + 1;"
doesn't invoke undefined behaviour in virtue of those sentences, then
what does?
Yes, that is an issue, isn't it?

I'm more and more thinking it might be a defect.

Because _apparently_ the Holy Standard is inconsistent here.

Hold on, I might have just come up with a killer point. Look again at
the first commented code example after 5.4:

i = v [i++]; // the behaviour is unspecified

(i) There is no order-of-evaluation problem here (do you agree?).
On the surface yes but I think that's most likely where the problem lies
if there is no defect in this part of the standard.

(ii) If v is an std::vector (for instance), then [] is a real function
call. If I'm right about the relevance of sequence points in
functions to the evaluation of the calling expression, then it follows
that there is no problem whatsoever, and the behaviour is defined and
the result is specified. So (if I'm right) we have to assume [] is the
builtin subscript operator: that v and i are a pointer (or an array) and
an integer (but not necessarily in that order).
Right.
(Getting a headache?)
Nope.

(iii) Making that assumption, the only remaining problem is the lack of
a sequence point between the two modifications of i. (Huh? HUH?)
Yes, and there are two things to be said about that. (i) It doesn't
support either of our views. And (ii) it indicates to me that this part
of the standard was written to use a minimum of words, and so ended up
with an overly general definition of "unspecified" (or "undefined", as
the case _might_ be ;-) ) -- the example simply reflects that.

Details of (ii): it should IMO have described the evaluation tree of an
expression and and placed sequence points _inside_ each node, start and
end of evaluation of that node.

I.e., it should IMO have explicitly discussed expression hierarchies.

(iv) Therefore either the behaviour is undefined (I maintain it is),
or the result is specified. In either case the comment is wrong. What
do you think?
I think you're onto something, but you forgot that perhaps all those
mentions of "unspecified" may be right and the single mention of
"undefined" might be wrong -- or simply not sufficiently qualified.

Note that the comment does not say "the result is unspecified", which
would be very clear.
It's clear as it is (on its own, not considering the earlier text)
because "unspecified behavior" is _defined_ by §1 of the standard, I
think it was clause 13, as applying to the result.

BTW, I hope you're enjoying our little discussion.

Yep. ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Buster]

Alf P. Steinbach wrote:

* Buster:

Alf P. Steinbach wrote:

Those sequence points are internal to the calls.
In what sense?

That they do not affect the evaluation order of the expression the calls
appear in. The first one, going in, ensures that arguments are fully
evaluated when the function starts executing. The last one, going out,
ensures that the function result copying (if any) is complete before
e.g. a destructor is called for the function result.

Agreed.

The term
"sequence point" is not some abstract unconnected term: it is a point
between re-orderable parts of an expression, a point that is guaranteed
to come in execution sequence after the previous such such point (and
the standard's various definitions of where sequence points are are the
details necessary to achieve that meaning), so the function call example
does not have any sequence point in the full-expression.

I don't think it follows. To give you something to push against, I will
say that I am thinking of the chronological ordering of inspections,
modifications and sequence points, not some lexical ordering. Therefore,
no matter in what order the subexpressions of "x = f (x) + g (x)" are
evaluated, the eventual evaluation of "f (x)" involves two sequence
points (sorry, three: i didn't mention the one at the end of "x += 7;"
which is itself a full expression), as does the evaluation of "g (x)",
and so those six sequence points occur, (at unspecified points) in time,
during the evaluation of the full expression.

I agree that they are executed in sequence (chronological ordering) _for
the sequence they apply to_, that's the point of having them.

What you have with f(x)+g(x) is however a hierarchy, not a linear
sequence.

The sequence points for the sequence of events in calling f are executed
in sequence. Likewise those for g. But the compiler is free to reorder
the top expression as g()+f(), because there's no sequence point there.

Well, OK. Hermeneutics isn't my strong suit. I think the standard means
what it says, and I think what you're saying about trees and hierarchies
is covered by "for each allowable ordering of the subexpressions".

Look it another way: the compiler is permitted to reorder f(x)+g(x) as
g(x)+f(x), and if not then the example could not be "unspecified" as you
maintain it is.

Sorry, you've lost me. Are you saying I've confused the issues of
sequence points and unspecified order of evaluation? Because I don't
think I have. f (x) must be evaluated 'all at once', and so must g (x).

Well I haven't said, but for what I'm thinking about what you might be
thinking (ha, philosophy enters clc++!), I think you may have needlessly
_differentiated_ between the concepts of sequence points and defined
evaluation order (sequence points are there to define the order),
and based on your comment about non-interference I think there's at
least a 40% dependent chance that you might then be thinking about
parallellism of some sort,

.... I'm not ...
which if you are would probably (75%
dependent chance?) stem from a need to make sense of the concept of
sequence point isolated from evaluation order: "it must mean something".
No, but I remain under the impression that the two concepts are
distinct. Not orthogonal, or unrelated, just distinct.
[snip]

But the standard says (right out loud) that it _is_ undefined behaviour.
That's what the latter two sentence of 5/4 say. If "i = ++i + 1;"
doesn't invoke undefined behaviour in virtue of those sentences, then
what does?
Yes, that is an issue, isn't it?

I'm more and more thinking it might be a defect.

Because _apparently_ the Holy Standard is inconsistent here.

I'm sticking with my story for the time being. It's kept me out of
trouble so far. (Unspecified result, undefined behaviour, they're
neither of them good news anyway.)

[...] but you forgot that perhaps all those
mentions of "unspecified" may be right and the single mention of
"undefined" might be wrong -- or simply not sufficiently qualified.

I did. But I'm not the first. I knew I hadn't made this up myself.
In 'C++ In A Nutshell' by Ray Lischner the presentation of sequence
points describes their function as regards side-effects and adds
"Also, any expression that modifies a scalar object more than once
between sequence points, that examines the value of an object and then
modifies it, yields undefined behaviour."

Note that the comment does not say "the result is unspecified", which
would be very clear.

It's clear as it is (on its own, not considering the earlier text)
because "unspecified behavior" is _defined_ by §1 of the standard, I
think it was clause 13, as applying to the result.

Not quite, but 1.9/2-4 could be taken to support the idea that there is
an inconsistency. Apparently the standard describes "Certain aspects and
operations of the abstract machine" as implementation-defined, "Certain
other aspects and operations" as unspecified and "Certain other
operations" as undefined. I suppose that technically "other" implies
that no operation can be both unspecified and undefined.

However 1.9/7 and especially its footnote 7 seem very explicitly to
support my view: you deal with unspecified behaviour such as order
of evaluation first, then enforce the conditions on side effects and
sequence points upon "that particular execution sequence in which the
actual code is generated". The "otherwise the behaviour is undefined"
bit in 5/4 does seem like an afterthought, but I'd be surprised if it
turned out to be a slip.

--
Regards,
Buster

[Thomas Hansen]

Page 13, at the bottom where it says:
"At least they weren't considered short enough in 1970 or
thereabouts, the printer teletype era"
....

I thought the post/pre/incr/decr operators where Bjarnes invention
(post 1980) and later was adopted back to C since it was considered
such a nice thing to have...?
I might be wrong but I thought that Bjarne added them for the initial
work on the C++ language...
The way I understand your sentence about them is that they were added
in 1970 (ergo in the C language)

Anyway it's probably not importent for readers, but the language
lawyers will attack you if you don't have the history right you know...
;)

..t

[Alf P. Steinbach]

* Thomas Hansen:

Page 13, at the bottom where it says:
"At least they weren't considered short enough in 1970 or
thereabouts, the printer teletype era"
...

I thought the post/pre/incr/decr operators where Bjarnes invention
(post 1980) and later was adopted back to C since it was considered
such a nice thing to have...?
Nope. As I recall (and I shudder to think I could have a false memory
about this!) they were in C from the beginning. At least they're listed
& discussed in my first edition of "The C Programming Language", 1978.

I might be wrong but I thought that Bjarne added them for the initial
work on the C++ language...
Nope.

The way I understand your sentence about them is that they were added
in 1970 (ergo in the C language)
Thanks. I might have to change that wording. The 1970 version of what
later became C was a language called B, created in 1970 by Ken Thompson.
I'm not sure whether B had these operators, or whether its predecessor
BCPL had them. I sort of place "modern" C (in the sense of K&R C ;-))
at 1972. So I just wrote "1970 or thereabouts"...

Anyway it's probably not importent for readers, but the language
lawyers will attack you if you don't have the history right you know...
;)

Well...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Jerry Coffin]

> I thought the post/pre/incr/decr operators where Bjarnes invention

(post 1980) and later was adopted back to C since it was considered
such a nice thing to have...?

No -- they've been part of C since its _very_ beginning. They were
invented by Ken Thompson as part of B, which was C's immediate
predecessor.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Tom Widmer]

Buster wrote:

However 1.9/7 and especially its footnote 7 seem very explicitly to
support my view: you deal with unspecified behaviour such as order
of evaluation first, then enforce the conditions on side effects and
sequence points upon "that particular execution sequence in which the
actual code is generated". The "otherwise the behaviour is undefined"
bit in 5/4 does seem like an afterthought, but I'd be surprised if it
turned out to be a slip.

The examples are in error, they have undefined, not unspecified, behaviour
http://www.open-std.org/jtc1/sc22/wg...fects.html#351

Tom

[Alf P. Steinbach]

* Tom Widmer:

Buster wrote:

However 1.9/7 and especially its footnote 7 seem very explicitly to
support my view: you deal with unspecified behaviour such as order
of evaluation first, then enforce the conditions on side effects and
sequence points upon "that particular execution sequence in which the
actual code is generated". The "otherwise the behaviour is undefined"
bit in 5/4 does seem like an afterthought, but I'd be surprised if it
turned out to be a slip.

The examples are in error, they have undefined, not unspecified, behaviour
http://www.open-std.org/jtc1/sc22/wg...fects.html#351

Thanks and grrr: I'd much better liked the opposite resolution of that.

But April 2003: I don't see it in the unofficial revisions list for
C++03?

I mean, I _didn't_ see it there?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Alf P. Steinbach:

The section about unspecified versus undefined value is unchanged
although contested; I've posted a question about it to clc++m and await
some clarification (if possible), but basically I think it's correct as
it stands since it's simply the Holy Standard's example in disguise.

As it turned out the answer came here, not in clc++m:

This is a defect in the standard, and the consensus and proposed
resolution is that the standard's examples are incorrect and should be
changed to say "undefined behavior".

I've now replaced the version referred to above with one referring to
the proposed resolution of this defect in the standard,
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#351>.

Thanks to Tom Widner for providing that reference, and to all others who
have participated in the discussion both here and in clc++m.

The new version is available at the same URL as before, as Word doc,
<url: http://home.no.net/dubjai/win32cpptut/w32cpptut_01_02.doc>,

with the tutorial's main HTML version page at
<url: http://home.no.net/dubjai/win32cpptut/html/>,

as before.

Cheers,

- Alf

PS: It's amazing how many subtle issues there are even at the "Hello,
world!" stage, so I wonder if it's at all _possible_ to provide a
correct C++ tutorial (the point of a tutorial is to confront the
in-practice, not avoid and brush under the carpet the hairy & contested
issues)! But, I'll try. At least, if I can find the time.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?