Steve Clamage <stephen.clamage@sun.com> wrote:
> In article 145E8@am143.du.pipex.com, Mathew Hendry <scampi@dev.null> writes:
> >Andrew Koenig wrote:
> >> ++i means "increment i and yield i"
> >> i++ means "save the value of i, then increment i and yield the saved value"
> >
> >For built-in types, it can more simply be read as "yield i, then
> >increment". The increment is only delayed until after the original
> >value has been obtained. No temporary is required.

> That is not true in general. If you need both the old and the new
> value, one of them has to be saved someplace. That "someplace" might
> be a register for a simple type, but it is still a temporary variable.

Terminology clash. By "temporary" I mean an object which exists only
temporarily. All that is required here is that an already existing
object retain its original value temporarily.

> >It would be nice if these semantics were preserved for overloaded
> >operators: it would remove the need for the operator++(int) kludge.

> The only way to guarantee that op++ and op++(int) have the assumed
> relationship is to forbid overloading of the postfix version and
> have the compiler generate it for you from the prefix version.

A much less damaging change would be to specify default behaviour if
a postfix operator is not explicitly defined. I suggest that the
default behaviour be a delayed call to the prefix operator.

--
       Mathew Hendry (actually at dial.pipex.com, not dev.null)
                                                                    --



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marco Dalla Gasperina wrote:
>
> >On 20 Apr 1998, Chuck McCorvey wrote:
> >>>> Also, notice that I used "++i" rather than "i++" in the macro.
> >>>> This can make a significant performance difference as the former
> >>>> avoids the necessity of creating a temporary.
> >
> >B. James Phillippe wrote:
> >>> Really?  How so?  I have never heard this before, and I generally
> >>> use foo++ over ++foo (in situations where it doesn't matter).
> >
> >Valentin Bonnard wrote:
> >> ++x increment x and is the x lvalue; x++ increment x and
> >> returns the rvalue of x before the increment; so a copy of
> >> x has to be made:
> > [bobbit]
> >
> >No, Phillippe is correct.  The compiler can optimize almost anything,
> >and 'x++' and '++x' will probably be translated into identical
> >code in most cases.  Certainly they will if 'x' is a primitive
> >type and the result of the expression is not used.  It's similar
> >to the argument that 'p' is more efficient than 'p != NULL' since
> >the latter requires a comparison; it's a bogus argument.
>
> Hmmm...
>
> // pre-increment
> T& T::operator++() {
>     increment();
>     return *this;
> }
>
> // post-increment
> T T::operator++( int )
> {
>     T temp(*this);
>     increment();
>     return temp;
> }
>
> I don't see how a compiler can optimize the copy away, given
> that post-increment requires a copy to be made (the compiler may
> optimize out a second copy).

If the compiler sees the post-increment operator implementation *and*
the copy constructor implementation *and* the destructor implementation
at the point where you use post-increment and discard the result (f.ex.
they are all inline), and from this information it can proof that you'll
never detect the difference (because there's a sequence of invisible
changes which completely eliminates the temporary copy), it can do so.
However, the more complicated the iterator gets (and the dumber the
compiler is ;-)), the less likely you'll get the optimisation.
Note that there may be cases where the implementation of increment()
need to be seen as well, f.ex. if the iterator contains a reference
count the compiler doesn't know that inrement() doesn't depend on its
value (maybe it outputs it).

The problem is that the compiler cannot make any assumptions on the
meaning. If the standard went the way analoguous to operator new/new
operator, the situation would be much better IMHO: You would define a
single operator++ which just incremented the iterator, and using prefix
++ would mean "call operator++, then use object as lvalue", while using
postfix ++ would mean "make temporary copy, then call operator++ for
original object, then use temporary as rvalue". This way, the compiler
could optimize away the temporary copy in any case if not referenced any
more.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6id9ql$57r@engnews1.Eng.Sun.COM>,
Steve Clamage <stephen.clamage@sun.com> wrote:
>In article 145E8@am143.du.pipex.com, Mathew Hendry <scampi@dev.null> writes:
>>Andrew Koenig wrote:
>>> ++i means "increment i and yield i"
>>> i++ means "save the value of i, then increment i and yield the saved value"
>>
>>For built-in types, it can more simply be read as "yield i, then
>>increment". The increment is only delayed until after the original
>>value has been obtained. No temporary is required.
>
>That is not true in general. If you need both the old and the new
>value, one of them has to be saved someplace. That "someplace" might
>be a register for a simple type, but it is still a temporary variable.

But that "someplace" can often be the target of the assignment or the stack
location for the parameter in a function call.  I.e. it's the same place
where the value would be stored if you weren't incrementing the variable at
the same time, so you don't need a separate temporary.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 20 Apr 1998, Chuck McCorvey wrote:
>>> Also, notice that I used "++i" rather than "i++" in the macro.
>>> This can make a significant performance difference as the former
>>> avoids the necessity of creating a temporary.

B. James Phillippe wrote:
>> Really?  How so?  I have never heard this before, and I generally
>> use foo++ over ++foo (in situations where it doesn't matter).

Valentin Bonnard wrote:
> ++x increment x and is the x lvalue; x++ increment x and
> returns the rvalue of x before the increment; so a copy of
> x has to be made:
 [bobbit]

No, Phillippe is correct.  The compiler can optimize almost anything,
and 'x++' and '++x' will probably be translated into identical
code in most cases.  Certainly they will if 'x' is a primitive
type and the result of the expression is not used.  It's similar
to the argument that 'p' is more efficient than 'p != NULL' since
the latter requires a comparison; it's a bogus argument.

> But in general, if the appropriate functions aren't inline,
> or the compiler doesn't optimise well, it's better to use
> prefix ++, even on an iterator.

No.  IT'S BETTER TO WRITE READABLE CODE.  This cannot be stressed
enough.  In spite of what most programmers believe (or are taught
to believe), Good Programming is not a measure of optimal code,
but a measure of how well-written the code is (and all that that
implies).  Leave the optimizing to the compiler, that's it's job,
and it's better at it than you.  I'll wager than 98% of your
increments account for less than 2% of the execution time of your
program, so making them "faster" is a waste of time and just adds
to the confusion of the poor guy who has to maintain your code.

BTW, has anyone actually bothered to test whether 'x++' and '++x'
execute at different speeds?

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:

[...]

> > But in general, if the appropriate functions aren't inline,
> > or the compiler doesn't optimise well, it's better to use
> > prefix ++, even on an iterator.
>
> No.  IT'S BETTER TO WRITE READABLE CODE.  This cannot be stressed

[...]

Well, this then boils down to the question what is more readable,
i++ or ++i. If you read "++" as "increment", i++ reads "i increment",
while ++i reads "increment i". I think the second is more exactly
what you would say in English.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> On 20 Apr 1998, Chuck McCorvey wrote:
> >>> Also, notice that I used "++i" rather than "i++" in the macro.
> >>> This can make a significant performance difference as the former
> >>> avoids the necessity of creating a temporary.
>
> B. James Phillippe wrote:
> >> Really?  How so?  I have never heard this before, and I generally
> >> use foo++ over ++foo (in situations where it doesn't matter).
>
> Valentin Bonnard wrote:
> > ++x increment x and is the x lvalue; x++ increment x and
> > returns the rvalue of x before the increment; so a copy of
> > x has to be made:
>  [bobbit]
>
> No, Phillippe is correct.  The compiler can optimize almost anything,

I have explainned in details how and when the compiler
can optimise.

> and 'x++' and '++x' will probably be translated into identical
> code in most cases.

For built-ins, yes (they are a particular case of PODs).

> the argument that 'p' is more efficient than 'p != NULL' since
> the latter requires a comparison; it's a bogus argument.

;-)

I like this one.

> > But in general, if the appropriate functions aren't inline,
> > or the compiler doesn't optimise well, it's better to use
> > prefix ++, even on an iterator.
>
> No.  IT'S BETTER TO WRITE READABLE CODE.

Who said the contrary ?

Do you think that postfix increment in the middle of an
expression enhance readabillity ? Are there any common
cases where ++it isn't readable but it++ is ?

> Leave the optimizing to the compiler, that's it's job,
> and it's better at it than you.

The compiler is (on average) stupid; programmers are (on
average) intelligents. The compiler kmows the machine well;
I don't know it. So I let the compiler optimise the low-level
details for me, but I will help him (when it's possible).

> I'll wager than 98% of your
> increments account for less than 2% of the execution time of your
> program, so making them "faster" is a waste of time and just adds
> to the confusion of the poor guy who has to maintain your code.

I would say that it can make a difference for programs using
the STL a lot.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[discussion of optimization snipped]

Valentin Bonnard wrote:
>>> But in general, if the appropriate functions aren't inline,
>>> or the compiler doesn't optimise well, it's better to use
>>> prefix ++, even on an iterator.

I, David R Tribble wrote:
>> No.  IT'S BETTER TO WRITE READABLE CODE.

Valentin Bonnard wrote:
> Who said the contrary ?
> Do you think that postfix increment in the middle of an
> expression enhance readabillity ? Are there any common
> cases where ++it isn't readable but it++ is ?

Personally, yes, I do.  I think it makes code look more consistent
by placing the operand on the left side of the operator in all
cases where possible; for example:

    a = b + c;
    b *= 2;
    c++;

In these examples, the lvalue being modified always shows up on the
left side, and is always the first item in the expression.  But
that's just my personal style; you have your own, of course.
(Obviously Stroustrup thought so, too, since he chose to call it
C++ instead of ++C.  ;-) )

Me:
>> Leave the optimizing to the compiler, that's it's job,
>> and it's better at it than you.

Valentin:
> The compiler is (on average) stupid; programmers are (on
> average) intelligents. The compiler kmows the machine well;
> I don't know it. So I let the compiler optimise the low-level
> details for me, but I will help him (when it's possible).

If by "low-level" you mean the code block comprising an entire
function, yes, the compiler does a very good job.  You'd be
surprised how optimal the code is that's generated by the "stupid"
compiler compared to what you can do by hand, especially on a RISC
CPU (we've tried it).  If by "high-level" you mean your choice of
algorithm and the choice of the functions you use, then yes, of
course you can do a better job than the compiler; you have to.

But your "hints" to the compiler for low-level optimization may
hinder it more than help it.  For example, using the "register"
keyword is almost always a bad idea; we've seen it consistently
make code less optimal on several Unix machines.  The compiler
simply knows more about register allocation and variable references
within code blocks than we do, so we shouldn't try to influence its
choices too much.

It's probably true that '++i' is more efficient than 'i++' for
non-POD types in C++.  This is a pity.  But I still think that
the difference between '++i' and 'i++' are, most of the time,
inconsequential.  Remember the First Rule of Optimization:
Don't do it (yet).

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>On 20 Apr 1998, Chuck McCorvey wrote:
>>>> Also, notice that I used "++i" rather than "i++" in the macro.
>>>> This can make a significant performance difference as the former
>>>> avoids the necessity of creating a temporary.
>
>B. James Phillippe wrote:
>>> Really?  How so?  I have never heard this before, and I generally
>>> use foo++ over ++foo (in situations where it doesn't matter).
>
>Valentin Bonnard wrote:
>> ++x increment x and is the x lvalue; x++ increment x and
>> returns the rvalue of x before the increment; so a copy of
>> x has to be made:
> [bobbit]
>
>No, Phillippe is correct.  The compiler can optimize almost anything,
>and 'x++' and '++x' will probably be translated into identical
>code in most cases.  Certainly they will if 'x' is a primitive
>type and the result of the expression is not used.  It's similar
>to the argument that 'p' is more efficient than 'p != NULL' since
>the latter requires a comparison; it's a bogus argument.

Hmmm...

// pre-increment
T& T::operator++() {
    increment();
    return *this;
}

// post-increment
T T::operator++( int )
{
    T temp(*this);
    increment();
    return temp;
}

I don't see how a compiler can optimize the copy away, given
that post-increment requires a copy to be made (the compiler may
optimize out a second copy).

As for readability I can't imagine x++ being more readable than ++x.

marco


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Koenig wrote:
> Christopher Eltschka wrote:
> > Well, this then boils down to the question what is more readable,
> > i++ or ++i. If you read "++" as "increment", i++ reads "i increment",
> > while ++i reads "increment i". I think the second is more exactly
> > what you would say in English.

> Which is more readable depends on which you intend.

> ++i means "increment i and yield i"
> i++ means "save the value of i, then increment i and yield the saved value"

For built-in types, it can more simply be read as "yield i, then
increment". The increment is only delayed until after the original
value has been obtained. No temporary is required.

It would be nice if these semantics were preserved for overloaded
operators: it would remove the need for the operator++(int) kludge.
However, I'm sure that there are several billion existing lines of
code which would prevent this from happening. ;)

--
       Mathew Hendry (actually at dial.pipex.com, not dev.null)
                                                                    --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote in message <354564CA.D060DF79@ix.netcom.com>...
>Martijn Lievaart wrote:
>>
>> B. James Phillippe wrote in message ...
>> >On 20 Apr 1998, Chuck McCorvey wrote:
>> >
>> >Really?  How so?  I have never heard this before, and I generally use
>> > foo++
>> >over ++foo (in situations where it doesn't matter).
>>
>> Any real compiler should not generate different code for these
>> situations.
>
>For class types with user defined operator++, I don't believe the
>compiler is allowed to call operator++() when you write foo++, even if
>the result isn't used. Therefore, even for built-in types, it's good to
>get into the habit of writing ++foo where either would do. Perhaps the
>language should have been called ++C.
>


You're right ofcourse. I was thinking of built-ins. I think I'll adopt this
practice.

Greetz,
Martijn
mlievaar at orion in nl



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 145E8@am143.du.pipex.com, Mathew Hendry <scampi@dev.null> writes:
>Andrew Koenig wrote:
>> Christopher Eltschka wrote:
>> > Well, this then boils down to the question what is more readable,
>> > i++ or ++i. If you read "++" as "increment", i++ reads "i increment",
>> > while ++i reads "increment i". I think the second is more exactly
>> > what you would say in English.
>
>> Which is more readable depends on which you intend.
>
>> ++i means "increment i and yield i"
>> i++ means "save the value of i, then increment i and yield the saved value"
>
>For built-in types, it can more simply be read as "yield i, then
>increment". The increment is only delayed until after the original
>value has been obtained. No temporary is required.

That is not true in general. If you need both the old and the new
value, one of them has to be saved someplace. That "someplace" might
be a register for a simple type, but it is still a temporary variable.

>It would be nice if these semantics were preserved for overloaded
>operators: it would remove the need for the operator++(int) kludge.
>However, I'm sure that there are several billion existing lines of
>code which would prevent this from happening. ;)

No, the problem is fundamental. An overloaded operator in C++ is
just a function. It can have any semantics at all. There is no
way a compiler can determine whether any set of overloaded operators
have the same semantic relationship as their default versions do.

For example, you can overload each of op=, op+, and op+=. The compiler
cannot in general determine whether op+= is equivalent to op+ followed
by op= for at least 2 reasons. The definitions might be in different
compilation units, and the task is theoretically impossible anyway.

(It's probably worth noting that the arithmetic operators for
floating-point values don't have the same semantic relationship
as their integer equivalents. Reorderable operations for integers
are not necessarily reorderable for floating-point.)

The only way to guarantee that op++ and op++(int) have the assumed
relationship is to forbid overloading of the postfix version and
have the compiler generate it for you from the prefix version.

---
Steve Clamage, stephen.clamage@sun.com



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Do you think that postfix increment in the middle of an
|>  expression enhance readabillity ? Are there any common
|>  cases where ++it isn't readable but it++ is ?

Yes.  In shops which have standardized on it++ as the standard form,
++it is less readable.

Traditionally, in C, I wrote it++.  No particular reason, really, but it
was a sort of pseudo-standard.  I've changed, and while I found my code
looked a little strange at first, now, it is the it++ which shocks me.
Neither are really linked with what one does in a native language.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>In article <3547271F.1E68EA33@physik.tu-muenchen.de>,
>Christopher Eltschka  <celtschk@physik.tu-muenchen.de> wrote:
>> Well, this then boils down to the question what is more readable,
>> i++ or ++i. If you read "++" as "increment", i++ reads "i increment",
>> while ++i reads "increment i". I think the second is more exactly
>> what you would say in English.

In article <Es7Cto.1oy@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>Which is more readable depends on which you intend.
>++i means "increment i and yield i"
>i++ means "save the value of i, then increment i and yield the saved value"

    And all these semantic arguments might never have happened if
the PDP-11 machines that were being used for some of the development
of C didn't have these neat "<op> indirect post-increment" and
"<op> indirect pre-decrement" operators...  Or was it pre-increment
and post-decrement?  Fortunately, I haven't had to touch one of
those beasts since 1986.  Remember that an original design goal of
C was to make it as efficient as assembler, and on a PDP-11 you
couldn't do that unless you had a way to tell the compiler to use
these operator modes.  So prefix and postfix operators were added
to C.

    What was originally a feature to stretch the performance of
C becomes a leading semantic soapbox in C++...

Doug Murphy
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6iguu9$sbf@nntpa.cb.lucent.com>, djm5@ohgua.oh.lucent.com
says...

[ ... ]

>     And all these semantic arguments might never have happened if
> the PDP-11 machines that were being used for some of the development
> of C didn't have these neat "<op> indirect post-increment" and
> "<op> indirect pre-decrement" operators...  Or was it pre-increment
> and post-decrement?

As has been posted here several times, dmr has a spot on his web page
(or at least did at one time) pointing out that this is NOT true -- he
was using these operators BEFORE they were dealing with the PDP-11,
and if memory serves, they were inherited from B.

> Remember that an original design goal of
> C was to make it as efficient as assembler, and on a PDP-11 you
> couldn't do that unless you had a way to tell the compiler to use
> these operator modes.  So prefix and postfix operators were added
> to C.

Please take a look at dmr's home page (located somewhere or other in
the depths of Lucent's pages) to find the real truth of the situation.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> On 20 Apr 1998, Chuck McCorvey wrote:
>
> > Also, notice that I used "++i" rather than "i++" in the macro.
> > This can make a significant performance difference as the former
> > avoids the necessity of creating a temporary.

B. James Phillippe wrote:
>
> Really?  How so?  I have never heard this before, and I generally use
> foo++ over ++foo (in situations where it doesn't matter).

It may or may not make a difference when incrementing built-in types.
Some compilers will realize that the 'previous' value of a built-in is
never used, and therefore not save it. However, for a user-defined
post-increment operator, you'll usually see the code:

    foo foo::operator++(int, foo f)
    {
        foo temp = f;
        ++f;
        return temp;
    }

The compiler isn't allowed to optimize away the extra work in this
function: copy-constructing temp from f, and returning f by value from
the operator. Some compilers WILL optimize the return-by-value (this is
still legal, right?), but you still have an extra copy construction,
which can be arbitrarily expensive--and you don't even need it.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds

My reply address is correct as-is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

B. James Phillippe wrote:
>
> On 20 Apr 1998, Chuck McCorvey wrote:
>
> > Also, notice that I used "++i" rather than "i++" in the macro.  This can
> > make a significant performance difference as the former avoids the necessity
> > of creating a temporary.
>
> Really?  How so?  I have never heard this before, and I generally use foo++
> over ++foo (in situations where it doesn't matter).

++x increment x and is the x lvalue; x++ increment x and
returns the rvalue of x before the increment; so a copy of
x has to be made:

X X::operator++ (int)
{
    X tmp = *this;
    operator++ ();
    return tmp;
}

This involve two copies of X, the second one can be eliminated
by object elision.

If X is an iterator then it's probably a nearly-POD type with
bitwise copy construction and copy assignement. So the compiler
can avoid all copies if operator++ (int) is inlined.

But in general, if the appropriate functions aren't inline,
or the compiler doesn't optimise well, it's better to use
prefix ++, even on an iterator.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martijn Lievaart wrote:
>
> B. James Phillippe wrote in message ...
> >On 20 Apr 1998, Chuck McCorvey wrote:
> >
> >Really?  How so?  I have never heard this before, and I generally use
> > foo++
> >over ++foo (in situations where it doesn't matter).
>
> Any real compiler should not generate different code for these
> situations.

For class types with user defined operator++, I don't believe the
compiler is allowed to call operator++() when you write foo++, even if
the result isn't used. Therefore, even for built-in types, it's good to
get into the habit of writing ++foo where either would do. Perhaps the
language should have been called ++C.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <354564CA.D060DF79@ix.netcom.com>,
Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>
> Perhaps the language should have been called ++C.

That would imply that the ISO standardization process is the most
efficient way to upgrade a language.  Is that the impression you
meant to convey? :)

- Marc



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 20 Apr 1998, Chuck McCorvey wrote:

> Also, notice that I used "++i" rather than "i++" in the macro.  This can
> make a significant performance difference as the former avoids the necessity
> of creating a temporary.

Really?  How so?  I have never heard this before, and I generally use foo++
over ++foo (in situations where it doesn't matter).

thanks,
-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

B. James Phillippe wrote in message ...
>On 20 Apr 1998, Chuck McCorvey wrote:
>
>> Also, notice that I used "++i" rather than "i++" in the macro.  This can
>> make a significant performance difference as the former avoids the
necessity
>> of creating a temporary.
>
>Really?  How so?  I have never heard this before, and I generally use foo++
>over ++foo (in situations where it doesn't matter).

Any real compiler should not generate different code for these situations.
The temporary is used only if it's needed, in which case it's obviously ..
eh .. needed.

Greetz,
Martijn
mlievaart at orion in nl



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 24 Apr 98 06:35:40 GMT, "B. James Phillippe" <bryan@terran.org>
wrote:

>On 20 Apr 1998, Chuck McCorvey wrote:
>
>> Also, notice that I used "++i" rather than "i++" in the macro.  This can
>> make a significant performance difference as the former avoids the necessity
>> of creating a temporary.
>
>Really?  How so?  I have never heard this before, and I generally use foo++
>over ++foo (in situations where it doesn't matter).

Yes many haven't heard. :-(

but:

foo++ is roughly equivalent to:

{
  fooType temp = foo;
  ++foo;
  return foo;
}

or in plan text:

create a temporary of the same type;
copy value into temporary;
increment original in place;
return temporary for processing;
destroy temporary.

where as ++foo is just:

increment original in place.

===================================================
Thomas Jordan
mailto:ace -at- programmer.net
no-spam:replace -at- with @


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

B. James Phillippe wrote in message ...
>On 20 Apr 1998, Chuck McCorvey wrote:
>
>> Also, notice that I used "++i" rather than "i++" in the macro.  This can
>> make a significant performance difference as the former avoids the
necessity
>> of creating a temporary.
>
>Really?  How so?  I have never heard this before, and I generally use foo++
>over ++foo (in situations where it doesn't matter).
>

The post-fixed version (foo++) must create a temporary to hold the
pre-incremented value, then increment it and then return the pre-incremented
value.  The pre-fixed version must simply increment the value and return it.
At best, creating a temporary is costs nothing, but for an interesting class
it may cost much more than the increment itself.

--
Chuck McCorvey
Creative SolutionWare, Inc.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]