> When you overload a operator, it might have some sideeffects. So if
> you do something like
>
> quer = (foo + bar) * (foo + bar);
>
> and the operator + used in the example is written by your own, the
> compiler have to call it twice. Perhaps there should be a parameter
> 'no_sideeffect' (it's name doesn't matters), that you use whle
> overloading the operator. So the compiler can do something like this:
>
> tmp = (foo + bar)
> quer = tmp * tmp;

when you declare the operator as const as you can do with every method, the
compiler knows that the operator doesn't alter the object (and don't allow
your to do that) .
that should imho work.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"cody" <deutronium@gmx.net> wrote in message
news:bfpc5k$g8q0b$1@ID-176797.news.uni-berlin.de...
> >
> > and the operator + used in the example is written by your own, the
> > compiler have to call it twice. Perhaps there should be a parameter
> > 'no_sideeffect' (it's name doesn't matters), that you use whle
> > overloading the operator. So the compiler can do something like this:
> >
> > tmp = (foo + bar)
> > quer = tmp * tmp;
>
> when you declare the operator as const as you can do with every method, the
> compiler knows that the operator doesn't alter the object (and don't allow
> your to do that) .
> that should imho work.

const tells the compiler you are not modifying the object, but it doesn't tell
the compiler you aren't modifying global state, which could affect future
calls to the same function.  What is needed is a way to let the compiler know
that if you call a function any number of times with the same exact inputs, it
will always have the same output.  This *could* involve changing the global
state (for example, steps of the calculation might be memoized).

A smart enough compiler can sometimes figure this out, but such a compiler
could probably figure it out with or without the const modifier.  However,
there are situations in which we can't reasonably expect the compiler to
figure it out, and it would be nice to allow this sort of optimization in
those situations.  Example: what if it was a remote procedure call?

Ken


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

cody wrote:

> when you declare the operator as const as you can do with every method, the
> compiler knows that the operator doesn't alter the object (and don't allow
> your to do that) .
> that should imho work.

No.  Making a method const does not grant the compiler
licence to remove duplicate calls to that function.  It is
only allowed to do that it is knows that the function
*really* has no effects.  For example, a const function
might still modify mutable data members, or it might change
the global state of the program, or if might print a
diagnostic message.  Only if the compiler knows that none of
these apply can it remove the duplicate calls using the "as
if" rule.

--
Richard Smith

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Helium" <bekkah@web.de> wrote in message
> >> When you overload a operator, it might have some sideeffects. So if
> >> you do something like
> >>
> >> quer = (foo + bar) * (foo + bar);
> >>
> >> and the operator + used in the example is written by your own, the

> "Ken Alverson" wrote:
> > This isn't something that's limited to operators, any idempotent
> > function (such as container.end()) could benefit from such an
> > optimization hint. As such, a qualifier (similar to "const") would
> > be more appropriate than a phantom parameter.

Giovanni Bajo wrote
> Actually, I expect decent compilers to be able to detect this
> automatically, without putting on ME the burden of specifying
> which function has side effects and which has not. Given an inline
> definition for operator+,

That may be true for some inline functions, under the as-if rule.
But consider functions that are not inline, and are defined in a
seperate compilation unit. If the programmer doesn't have a standard
way to signify in the header file that a given function has no
side-effects, the compiler is going to have to assume that it does.

> and no aliasing issues (which can't be,
> since there are no pointers in the proposed code),

Pointers are not the only ways to create aliasing issues.

> I fail to see
> why a compiler could not detect this automatically.

I think that even for inline functions, this might be more difficult
than you imagine.

    float pyth(float a, float b) { return sqrt(square(a) + square(b)); }

Obviously, this extremely function has side-effects if either sqrt()
or square() do. But if either of them return something other than
float, then we also might have copy constructors, destructors, and
conversion functions to be concerned with. If sqrt() works via
successive approximations, then it will have an appreciable list
of functions that also must be checked. If pyth() accepted and
returned something besides float, the problems would compound
exponentially.

If that doesn't convince you, then think about this: It's possible
for a function to have no side-effects, even if it calls another
function that sometimes does. Either it could call that other
function in a way that doesn't trigger the side-effects, or it could
allow the side-effects to occur and then undo them (for instance,
a long calculation could spawns a thread, waits for the result, then
terminate that thread).

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

When you overload a operator, it might have some sideeffects. So if
you do something like

quer = (foo + bar) * (foo + bar);

and the operator + used in the example is written by your own, the
compiler have to call it twice. Perhaps there should be a parameter
'no_sideeffect' (it's name doesn't matters), that you use whle
overloading the operator. So the compiler can do something like this:

tmp = (foo + bar)
quer = tmp * tmp;

That might be faster.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Helium" <bekkah@web.de> wrote in message
news:194c1211.0305010744.60eab72a@posting.google.com...
> When you overload a operator, it might have some sideeffects. So if
> you do something like
>
> quer = (foo + bar) * (foo + bar);
>
> and the operator + used in the example is written by your own, the
> compiler have to call it twice. Perhaps there should be a parameter
> 'no_sideeffect' (it's name doesn't matters), that you use whle
> overloading the operator. So the compiler can do something like this:
>
> tmp = (foo + bar)
> quer = tmp * tmp;
>
> That might be faster.

This isn't something that's limited to operators, any idempotent function
(such as container.end()) could benefit from such an optimization hint.  As
such, a qualifier (similar to "const") would be more appropriate than a
phantom parameter.

Ken


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ken Alverson" wrote:

>> When you overload a operator, it might have some sideeffects. So if
>> you do something like
>>
>> quer = (foo + bar) * (foo + bar);
>>
>> and the operator + used in the example is written by your own, the

> This isn't something that's limited to operators, any idempotent function
> (such as container.end()) could benefit from such an optimization hint.
As
> such, a qualifier (similar to "const") would be more appropriate than a
> phantom parameter.

Actually, I expect decent compilers to be able to detect this automatically,
without putting on ME the burden of specifying which function has side
effects and which has not. Given an inline definition for operator+, and no
aliasing issues (which can't be, since there are no pointers in the proposed
code), I fail to see why a compiler could not detect this automatically.

--
Giovanni Bajo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Giovanni Bajo"" <noway@sorry.com> wrote in message
news:Kllsa.84255$DT4.2581888@twister1.libero.it...
> "Ken Alverson" wrote:
>
> > This isn't something that's limited to operators, any idempotent function
> > (such as container.end()) could benefit from such an optimization hint.
> > As such, a qualifier (similar to "const") would be more appropriate than
> > a phantom parameter.
>
> Actually, I expect decent compilers to be able to detect this automatically,
> without putting on ME the burden of specifying which function has side
> effects and which has not. Given an inline definition for operator+, and no
> aliasing issues (which can't be, since there are no pointers in the proposed
> code), I fail to see why a compiler could not detect this automatically.

Yes, an advanced compiler could determine a function is idempotent and
optimize accordingly if the function was inline in a header, but what if it is
in a different compilation unit?  Or a shared library?  Or an RPC to a
different machine?  Those scenarios would benefit from such a hint.  I expect
a compiler to be pretty smart, but there are some things it just can't
determine on its own.

Ken


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

noway@sorry.com ("Giovanni Bajo") wrote in message
news:<Kllsa.84255$DT4.2581888@twister1.libero.it>...
> "Ken Alverson" wrote:

> >> When you overload a operator, it might have some sideeffects. So if
> >> you do something like

> >> quer = (foo + bar) * (foo + bar);

> >> and the operator + used in the example is written by your own, the

> > This isn't something that's limited to operators, any idempotent
> > function (such as container.end()) could benefit from such an
> > optimization hint. As such, a qualifier (similar to "const") would
> > be more appropriate than a phantom parameter.

> Actually, I expect decent compilers to be able to detect this
> automatically, without putting on ME the burden of specifying which
> function has side effects and which has not.

Decent compilers seem to be rare these days.  The analysis you ask for
is far from trivial.

> Given an inline definition for operator+, and no aliasing issues
> (which can't be, since there are no pointers in the proposed code),

Two givens that are rarely true.  About half of the places I've worked
have had absolute rules against any inline functions, and the other half
should have had, given the way they were abused.  This optimization
becomes most useful when the functions are too large to be reasonably
inlined anyway (Matrix::operator+, for example).

And of course, foo and bar will normally have a this pointer, so
pointers are involved.  While you and I know that if foo and bar are two
different objects, their this pointers will not be the same, nor will
they overlap, it is not obvious for a compiler to know this.

Finally, the compilers definition of side effects may be too strict.
The standard requires functions like exp and log to indicate errors by
modifying the global variable error -- a side effect.  Faced with an
implementation of sin with this condition, it would be a very good
compiler that managed to detect that the function was still "pure".

> I fail to see why a compiler could not detect this automatically.

I'm sure if you implement such a compiler, you will have customers.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]