In article <37665299.85C39EC8@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Whatever your function does, the inline replacement must do the exact
> same thing; the main difference is that unnecessary copy constructor
> calls can be skipped.

No, they can't.  That was the original intent of copy constructor
elision, but when we formalized the description at the London meeting
in 1997, we were unable to come up with a good enough formulation
for parameters of inline functions and that specification was deferred.
The only two cases in which copy constructor calls can be elided are
for temporaries and return values.  See 12.8p5, the proposed rewrite
of that paragraph in core issue 20, and core issue 6 (which suggests
the inline function parameter optimization and which has been placed
in the "extensions" category, i.e., deferred until the five-year
review of the IS).

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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 15 Jun 99 06:32:29 GMT, Joe Gottman <joegottman@worldnet.att.net> wrote:

>   Does the standard say anything about how inline functions mix with
>short-circuit operators?  As I understand inline functions, if the
>function is inlined successfully then all calls to the function are
>replaced with the code inside of the function, with no function call
>being made.  So suppose I define a function like:

The 'inline' keyword is just a hint to the compiler that it may
inline the function.  The compiler is free to ignore the hint.  This
means that the function call
   f(a(1,1),b(2,2));
must be the same whether or not f(...) is inline.  This means that
the compiler must evaluate a(1,1) and b(2,2) prior to entering
f(...) -- even if the definition of f(...) is
   inline bool(int a, int b) { return a && b; }
Recall that the order of evaluation is unspecified.

If the compiler can show the evaluation of a(1,1) and b(2,2) have
no side effects, then it can evaluate a(1,1) first and then b(2,2)
if necessary.  However, this requires a detailed analysis of
functions a(...) and b(...), and I doubt that any compiler does
this analysis.

On the other hand, a non-conforming implementation may assume that
the evaluation of a(...) and b(...) have no side effects, because
it seems to me that this is usually the case, and thus do the
optimization anyway.


Also, you can make lazy evaluation classes yourself.  The resulting
code is not that pretty though because you need a lot more typing.

   inline bool(LazyA a, LazyB b) { return a.calc() && b.calc(); }

where

  class LazyA {
     public:
        LazyA(int a1, int a2) : a1(a1), a2(a2) { }
        bool calc() const { /* same as previous function a(int,int) */ }
     private:
        const int a1;
        const int a2;
  };

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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              ]

   Does the standard say anything about how inline functions mix with
short-circuit operators?  As I understand inline functions, if the
function is inlined successfully then all calls to the function are
replaced with the code inside of the function, with no function call
being made.  So suppose I define a function like:

inline bool my_and(bool a, bool b) {return a && b;}

If this function is successfully inlined, then my_and(at, b) is always
replaced by
a && b, with a always being evaluated first, and b not being evaluated
at all if a is false.  On the other hand, if the function is not
successfully inlined, which it might not be, then a and b will both be
evaluated and there is no guarantee in which order they will be
evaluated.  This is a fairly major difference depending on whether the
function is successfully inlined, which is solely up to the discretion
of the compiler.

--
Joe Gottman
joegottman@worldnet.att.net

The philosophy of C++: "Nothing is false; everything else is true."
---
[ 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 <376451DE.78B57127@worldnet.att.net>, Joe Gottman
<joegottman@worldnet.att.net> wrote:

>    Does the standard say anything about how inline functions mix with
> short-circuit operators?  As I understand inline functions, if the
> function is inlined successfully then all calls to the function are
> replaced with the code inside of the function, with no function call
> being made.

You must distinguish between "function" in the C or C++ programming
language (as opposed to "subroutines" in Fortran or "procedures" in
Pascal), and "function call" as a mechanism used by the compiler to
implement C++ functions, Fortran subroutines, and other things. For
example, compilers often implement 64 bit integer arithmetic using the
function call mechanism.

When you write a C++ function, the compiler can implement it any way it
wishes - as long as it is done according to the language rules. The
"inline" is a hint to the compiler to prefer an implementation that is
faster, even if it produces more code. Often compilers will grant your
wish by not using a "function call mechanism" but by inserting a copy of
the code into the calling function. But that NEVER changes the semantics.

> So suppose I define a function like:
>
> inline bool my_and(bool a, bool b) {return a && b;}
>
> If this function is successfully inlined, then my_and(at, b) is always
> replaced by
> a && b, with a always being evaluated first, and b not being evaluated
> at all if a is false.

No. A correct replacement would be (arg_a = a, arg_b = b, arg_a && arg_b).
For a replacement that doesnt change the semantics and doesnt introduce
sequence points that are not there in the function call implementation,
see below.

> On the other hand, if the function is not
> successfully inlined, which it might not be, then a and b will both be
> evaluated and there is no guarantee in which order they will be
> evaluated.  This is a fairly major difference depending on whether the
> function is successfully inlined, which is solely up to the discretion
> of the compiler.

Years ago there were compilers that implemented C++ by translating C++
into C. Such a compiler could inline your function by creating two new
variables int arg_a, int arg_b, int result and by replacing

   my_and (expr1, expr2)

by

   (((arg_a = (expr1), 0) + ((arg_b = (expr1), 0),
    result = arg_a && arg_b,
    result)

Of course, this asks for a good optimising C compiler. The semantics is
exactly the same as the semantics of a function call.
---
[ 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 <376451DE.78B57127@worldnet.att.net>,
  Joe Gottman <joegottman@worldnet.att.net> wrote:
>    Does the standard say anything about how inline functions mix with
> short-circuit operators?  As I understand inline functions, if the
> function is inlined successfully then all calls to the function are
> replaced with the code inside of the function, with no function call
> being made.  So suppose I define a function like:
>
> inline bool my_and(bool a, bool b) {return a && b;}
>
> If this function is successfully inlined, then my_and(at, b) is always
> replaced by
> a && b, with a always being evaluated first, and b not being evaluated
> at all if a is false.  On the other hand, if the function is not
> successfully inlined, which it might not be, then a and b will both be
> evaluated and there is no guarantee in which order they will be
> evaluated.  This is a fairly major difference depending on whether the
> function is successfully inlined, which is solely up to the discretion
> of the compiler.

The standard currently requires that there be no semantic difference
between inline and non-inline function calls; regardless of whether
the function is inlined or not, the arguments must be evaluated and
copied to the function's parameters.  (Subject to the "as-if" rule,
of course, like everything else -- if the observable behavior of
the program is the same, the implementation is entitled to do anything
it wants.  Side-effects can be observable, though.)

There is a proposal on the agenda of the committee when the Standard
is revised in a few years to allow eliding the copy to the parameter
of an inline function under certain conditions (issue 6 on the core
language issues list).  However, I don't believe (my personal opinion)
that that optimization would be specified in such a way as to
eliminate the requirement that argument expressions be evaluated.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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              ]

Joe Gottman wrote:
>
>    Does the standard say anything about how inline functions mix with
> short-circuit operators?  As I understand inline functions, if the
> function is inlined successfully then all calls to the function are
> replaced with the code inside of the function, with no function call
> being made.  So suppose I define a function like:

Not exactly. They're replaced with code that must do essentially the
same thing as the function call. It's not a macro replacement. It
doesn't allow optimizations that would have been illegal if the function
had not been declared inline.

> inline bool my_and(bool a, bool b) {return a && b;}
>
> If this function is successfully inlined, then my_and(at, b) is always
> replaced by
> a && b, with a always being evaluated first, and b not being evaluated
> at all if a is false.  On the other hand, if the function is not

Section 1.9, p17: "When calling a function (whether or not the function
is inline), there is a sequence point after the evaluation of all
function arguments (if any) which takes place before execution of any
expressions or statements in the function body."

Therefore, all side effects (which is the only way you could tell which
ones were evaluated) of both expressions must occur before my_and() is
called, regardless of whether or not my_and() is inlined.

> successfully inlined, which it might not be, then a and b will both be
> evaluated and there is no guarantee in which order they will be
> evaluated.  This is a fairly major difference depending on whether the
> function is successfully inlined, which is solely up to the discretion
> of the compiler.

Whatever your function does, the inline replacement must do the exact
same thing; the main difference is that unnecessary copy constructor
calls can be skipped. For bool, that's not an issue.
---
[ 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              ]

Joe Gottman wrote:
>
>    Does the standard say anything about how inline functions mix with
> short-circuit operators?  As I understand inline functions, if the
> function is inlined successfully then all calls to the function are
> replaced with the code inside of the function, with no function call
> being made.

No, functions behave the same way whether they are inlined or
not.  Both args are evaluated in this case.  It has to be this
way as there is no requierment that the compiler inline anything
(even if you tell it to) and it would be really hard to predict
the behavior of the code if the compiler were free to decide
whether or not to evaluate the args.
---
[ 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 <christian.bau-1506990951590001@christian-mac.isltd.insignia.com> christian.bau@isltd.insignia.com (Christian Bau) writes:
>In article <376451DE.78B57127@worldnet.att.net>, Joe Gottman
><joegottman@worldnet.att.net> wrote:
>>    Does the standard say anything about how inline functions mix with
>> short-circuit operators?....
>
>When you write a C++ function, the compiler can implement it any way it
>wishes - as long as it is done according to the language rules.....
>But that NEVER changes the semantics.

Right, it's important to remember that inline functions are still functions.
This means function semantics must be retained.

>> So suppose I define a function like:
>>
>> inline bool my_and(bool a, bool b) {return a && b;}

It's easy to think of inline functions as macros, but they are not.
my_and(++x, ++y);  will increment x and y despite whether b is
evaluated in the return or not.

>> On the other hand, if the function is not
>> successfully inlined, which it might not be, then a and b will both be
>> evaluated and there is no guarantee in which order they will be
>> evaluated.

This is true whether the function is inlined or not.
Obviously in cases where there is no side effect (like ++y above)
it can optimize further....

>> This is a fairly major difference depending on whether the
>> function is successfully inlined, which is solely up to the discretion
>> of the compiler.
>
>Years ago there were compilers that implemented C++ by translating C++
>into C. Such a compiler could inline your function by creating two new
>variables int arg_a, int arg_b, int result and by replacing

Such compilers still exist.  Consider Comeau C++, SAS/C+, etc.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]