Execution sequence with postfix increment and pass by reference

Discussion in 'C++' started by Marcel Müller, Jul 18, 2008.

  1. Hi,


    I have a question about the execution sequence of the postfix increment
    operator with respect to a function call.


    void foo(int type, int*& data);

    int* sequence;

    foo(*sequence++, sequence);


    Is the operator++ always executed before the function foo is called?
    In this case the evaluation of the two arguments is independent,
    otherwise the value of data in the body of foo is undefined.


    Marcel
    Marcel Müller, Jul 18, 2008
    #1
    1. Advertising

  2. On Jul 18, 3:43 pm, Marcel Müller <>
    wrote:
    > Hi,
    >
    > I have a question about the execution sequence of the postfix increment
    > operator with respect to a function call.
    >
    > void foo(int type, int*& data);
    >
    > int* sequence;
    >
    > foo(*sequence++, sequence);
    >
    > Is the operator++ always executed before the function foo is called?


    Yes
    > In this case the evaluation of the two arguments is independent,
    > otherwise the value of data in the body of foo is undefined.


    The order of argument evaluation is undefined in C++. However, the
    called function will receive the final product.
    puzzlecracker, Jul 18, 2008
    #2
    1. Advertising

  3. Marcel Müller

    Stefan Ram Guest

    Victor Bazarov <> writes:
    >>o(*sequence++, sequence);

    >(and after the evaluation of all arguments), so inside the function the
    >'sequence' already has the incremented value, and there is no undefined
    >behaviour.


    Possibly not indefined, but at least unspecified.

    The second argument might be evaluated before the
    first is being evaluated.

    For example, an implementation might print

    a
    a

    , another one might print

    a
    b

    , when executing

    #include <iostream>
    #include <ostream>

    void o( char const x, char const * const x1 )
    { ::std::cout << x << '\n';
    ::std::cout << *x1 << '\n'; }

    int main()
    { char const * sequence = "abc";
    o( *sequence++, sequence ); }

    .
    Stefan Ram, Jul 18, 2008
    #3
  4. Marcel Müller

    James Kanze Guest

    On Jul 18, 10:28 pm, -berlin.de (Stefan Ram) wrote:
    > Victor Bazarov <> writes:
    > >>o(*sequence++, sequence);

    > >(and after the evaluation of all arguments), so inside the function the
    > >'sequence' already has the incremented value, and there is no undefined
    > >behaviour.


    > Possibly not indefined, but at least unspecified.


    > The second argument might be evaluated before the
    > first is being evaluated.


    That doesn't change anything in the original example (which was,
    I suspect, the original poster's point).

    > For example, an implementation might print


    > a
    > a


    > , another one might print


    > a
    > b


    > , when executing


    > #include <iostream>
    > #include <ostream>


    > void o( char const x, char const * const x1 )
    > { ::std::cout << x << '\n';
    > ::std::cout << *x1 << '\n'; }


    > int main()
    > { char const * sequence = "abc";
    > o( *sequence++, sequence ); }


    > .


    And a third might core dump, since this code has undefined
    behavior; you're modifying sequence *and* accessing it other
    than to determine the new stored value, without an intervening
    sequence point.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 18, 2008
    #4
  5. Marcel Müller

    Stefan Ram Guest

    Victor Bazarov <> writes:
    >This example not not what the OP gave.


    You are right. I was inferring the type of the second argument
    from the call, but I should have read it from the declaration.
    Stefan Ram, Jul 18, 2008
    #5
  6. Marcel Müller

    Jerry Coffin Guest

    In article <g5r0q8$mdp$>,
    says...

    [ ... ]

    > First of all, there is no such thing as "unspecified behaviour".


    Oh? Did somebody remove section 1.3.13 from your copy of the standard?

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jul 19, 2008
    #6
  7. Victor Bazarov wrote:
    > Marcel Müller wrote:
    >> I have a question about the execution sequence of the postfix
    >> increment operator with respect to a function call.
    >>
    >>
    >> void foo(int type, int*& data);
    >>
    >> int* sequence;
    >>
    >> foo(*sequence++, sequence);

    >
    > I hope you change the value of 'sequence' to point to something valid
    > before the call to 'foo' here, otherwise you're dereferencing and
    > incrementing an uninitialised pointer.


    Of course.

    >> Is the operator++ always executed before the function foo is called?

    >
    > Yes, but you should not ask about when it's executed, but when the value
    > of the object changes. The change in the value is the side effect, and,
    > luckily for you, there is a sequence point before the function is called
    > (and after the evaluation of all arguments), so inside the function the
    > 'sequence' already has the incremented value, and there is no undefined
    > behaviour.


    Thanks! That is what I wanted to know.

    It makes it a bit easier to unpack ugly, proprietary structures into
    reasonable objects.


    Marcel
    Marcel Müller, Jul 19, 2008
    #7
  8. Marcel Müller

    Jerry Coffin Guest

    In article <>,
    says...
    > Jerry Coffin wrote:
    > > In article <g5r0q8$mdp$>,
    > > says...
    > >
    > > [ ... ]
    > >
    > >> First of all, there is no such thing as "unspecified behaviour".

    > >
    > > Oh? Did somebody remove section 1.3.13 from your copy of the standard?

    >
    > OK, you got me. The Standard is full of errors and dualities, AFAICS.
    > In most of the text it's the value that is unspecified, or the order,
    > but I haven't see many places where "behavior" is "unspecified". There
    > is however, a surprising mix-up, see 5/4, the example, which leads me
    > to believe that even the writers of the Standard couldn't make up their
    > minds in some situations.


    This is, unfortunately true. I'm pretty sure the problem is less that
    the writers of the standard don't know what they want, than that they
    (or, at any given time, mostly "he", right now Pete Becker) have roughly
    10 quadrillion things that really need to be done, and not quite enough
    hours in the day to do it. Pete seems to be a pretty good editor, but
    going through a document the size of the standard to verify that
    everywhere you meant "unspecified behavior", you really used exactly
    that phrase (and likewise with "undefined", etc.) is a serious pain at
    best -- and there are almost always other things that take priority,
    simply because as long as it uses "unspecified" or "undefined" it's
    pretty apparent to most people what's being referred to, even if the
    next word isn't spelled "behavior".

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jul 20, 2008
    #8
  9. Marcel Müller

    James Kanze Guest

    On Jul 20, 2:42 am, Jerry Coffin <> wrote:
    > In article <>,
    > says...
    > > Jerry Coffin wrote:
    > > > In article <g5r0q8$>,
    > > > says...


    > > > [ ... ]


    > > >> First of all, there is no such thing as "unspecified behaviour".


    > > > Oh? Did somebody remove section 1.3.13 from your copy of the standard?


    > > OK, you got me. The Standard is full of errors and dualities, AFAICS.
    > > In most of the text it's the value that is unspecified, or the order,
    > > but I haven't see many places where "behavior" is "unspecified". There
    > > is however, a surprising mix-up, see 5/4, the example, which leads me
    > > to believe that even the writers of the Standard couldn't make up their
    > > minds in some situations.


    > This is, unfortunately true. I'm pretty sure the problem is
    > less that the writers of the standard don't know what they
    > want, than that they (or, at any given time, mostly "he",
    > right now Pete Becker) have roughly 10 quadrillion things that
    > really need to be done, and not quite enough hours in the day
    > to do it.


    Not to suggest that Pete doesn't have a sufficient real work in
    editing, but the title of the role is "project editor" for a
    reason. A lot of the wording is taken verbatim from the
    proposals (and a good proposal does provide exact wording).
    Which means that often, the left hand doesn't know what the
    right hand is doing, and it really is too much to expect Pete
    (or Andy Koenig, before him, or any mortal human being) to spot
    all of the inconsistencies.

    FWIW: there is one certain case of "unspecified behavior" in the
    C standard: casting an integral type to a signed integral type,
    when the results don't fit. C90 said "unspecified value", but
    it was acknowledged by the C committee that this was poor
    wording, and the intent was also to allow the error to be
    trapped.

    There are probably others, but I don't have all of the standard
    in memory, so I can't be sure.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 20, 2008
    #9
  10. Marcel Müller

    Jerry Coffin Guest

    In article <7cc41178-ef83-47d5-883f-f7beb4a496fa@
    25g2000hsx.googlegroups.com>, says...

    [ ... ]

    > Not to suggest that Pete doesn't have a sufficient real work in
    > editing, but the title of the role is "project editor" for a
    > reason. A lot of the wording is taken verbatim from the
    > proposals (and a good proposal does provide exact wording).
    > Which means that often, the left hand doesn't know what the
    > right hand is doing, and it really is too much to expect Pete
    > (or Andy Koenig, before him, or any mortal human being) to spot
    > all of the inconsistencies.


    Right -- I certainly didn't mean to imply that any such problem was
    Pete's fault or anything like that -- only that the project editor is
    (to a large extent) the only one in a good position to see the whole
    picture. To a large extent, the project editor makes the changes
    approved by the committee. Some proposals work very hard at maintaining
    global consistency (some I've seen from Beman Dawes appear to work
    particularly hard in that respect). Others just try to restrict
    themselves to minimizing the possibility of introducing any new
    inconsistencies by minimizing the scope of changes they make at all.

    Getting back to the previous question, despite my pointing out the
    definition of "unspecified behavior", the comment to which I replied
    appears essentially accurate -- even though the term is defined, the
    only places in the current standard that I can find the phrase
    "unspecified behavior" used are 1) the definition of the term, and 2)
    the table of contents entry that points at the definition of the term.

    Outside of that, there are a couple hundred uses of "unspecified", but
    none of them is followed immediately by "behavior", and looking at a few
    dozen, there's not an easy way to change most of them to use the defined
    phrase either.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jul 20, 2008
    #10
    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. Replies:
    104
    Views:
    10,922
    Jordan Abel
    Oct 28, 2005
  2. lovecreatesbeauty
    Replies:
    8
    Views:
    1,626
    Old Wolf
    Sep 12, 2005
  3. Replies:
    99
    Views:
    2,473
    eliza81
    Jun 11, 2010
  4. Alf P. Steinbach /Usenet
    Replies:
    0
    Views:
    876
    Alf P. Steinbach /Usenet
    May 22, 2011
  5. Peng Yu

    post increment or pre increment?

    Peng Yu, Nov 21, 2008, in forum: Perl Misc
    Replies:
    7
    Views:
    503
    Peter J. Holzer
    Nov 23, 2008
Loading...

Share This Page