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

Discussion in 'C++' started by Alf P. Steinbach, Dec 14, 2004.

  1. A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
    http://groups.google.no/groups?threadm=>.

    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?
     
    Alf P. Steinbach, Dec 14, 2004
    #1
    1. Advertising

  2. Alf P. Steinbach

    Tim Love Guest

    (Alf P. Steinbach) writes:

    >A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
    >http://groups.google.no/groups?threadm=>.


    >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.
     
    Tim Love, Dec 14, 2004
    #2
    1. Advertising

  3. * Tim Love:
    > (Alf P. Steinbach) writes:
    >
    > >A few days ago I posted an "Hello, world!" tutorial, discussed in <url:
    > >http://groups.google.no/groups?threadm=>.

    >
    > >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?
     
    Alf P. Steinbach, Dec 14, 2004
    #3
  4. 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, Dec 14, 2004
    #4
  5. 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, Dec 14, 2004
    #5
  6. also page 14...
    Tell about the difference of:
    ++x;
    and:
    x++;
    Maybe like:
    Code:
    
    #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
     
    Thomas Hansen, Dec 14, 2004
    #6
  7. 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

    http://www.osb-systems.com
    Open source rating and billing engine for
    communication networks.
     
    =?iso-8859-1?q?Stephan_Br=F6nnimann?=, Dec 14, 2004
    #7
  8. * 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, Dec 14, 2004
    #8
  9. * 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, Dec 14, 2004
    #9
  10. * =?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?
     
    Alf P. Steinbach, Dec 14, 2004
    #10
  11. 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/cgi-bin/ns_viewcvs.cgi/exiv2/trunk/src/utils.hpp?view=markup
    for an example.

    regards,
    Stephan Brönnimann

    http://www.osb-systems.com
    Open source rating and billing engine for
    communication networks.
     
    =?iso-8859-1?q?Stephan_Br=F6nnimann?=, Dec 14, 2004
    #11
  12. * =?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/cgi-bin/ns_viewcvs.cgi/exiv2/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, Dec 14, 2004
    #12
  13. * Thomas Hansen:
    > also page 14...
    > Tell about the difference of:
    > ++x;
    > and:
    > x++;
    > Maybe like:
    >
    Code:
    [/color]
    
    Was already there, a whole section devoted to it: the last one.
    
    
    [color=blue]
    > 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...[/color]
    
    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][color=blue]
    > 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....[/color]
    
    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_?
    
    [color=blue]
    > 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... ;) )[/color]
    
    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?
     
    Alf P. Steinbach, Dec 15, 2004
    #13
  14. Alf P. Steinbach

    Buster Guest

    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
     
    Buster, Dec 16, 2004
    #14
  15. > 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
     
    Thomas Hansen, Dec 16, 2004
    #15
  16. * 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?
     
    Alf P. Steinbach, Dec 16, 2004
    #16
  17. Alf P. Steinbach

    Buster Guest

    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
     
    Buster, Dec 16, 2004
    #17
  18. * 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?
     
    Alf P. Steinbach, Dec 16, 2004
    #18
  19. Alf P. Steinbach

    Buster Guest

    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, Dec 16, 2004
    #19
  20. Alf P. Steinbach

    Buster Guest

    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
     
    Buster, Dec 16, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alf P. Steinbach
    Replies:
    21
    Views:
    9,604
    =?iso-8859-1?q?Stephan_Br=F6nnimann?=
    Dec 15, 2004
  2. Alf P. Steinbach
    Replies:
    13
    Views:
    682
    Alf P. Steinbach
    Feb 1, 2005
  3. Alf P. Steinbach
    Replies:
    7
    Views:
    3,123
    chris
    Jan 24, 2005
  4. Alf P. Steinbach
    Replies:
    10
    Views:
    790
    Alf P. Steinbach
    Feb 23, 2005
  5. Alf P. Steinbach
    Replies:
    2
    Views:
    546
    Alf P. Steinbach
    Feb 22, 2005
Loading...

Share This Page