[ Followups should probably go to egcs@cygnus.com ]

Gabriel Dos Reis <dosreis@DPTMaths.ENS-Cachan.Fr> writes:

> Obviously not.

I just wanted to hear that.

> I find it unfornate for the numerical computing
> community that the return value optimization isn't widely implemented
> (and in some sense mandatory).

I consider a pitty the fact that gcc implemented a language
extention instead of an optimisation. A language extention
requires changes to both the parser, the semantic checker,
and the code generator, while an optimisation only requires
changes to the code generator.

A language extention creates a new dialect; an optimisation
creates a compiler superior to other compilers which don't
implement it.

After some time, there is code which uses your extention,
so you can't (or can hardly) change or remove it. There is
no such strong dependancy with a particular optimisation,
except that if you remove you loose your superiority over
competition.

Conclusion:

- an optimisation is potential cheaper to implement than
  a language change

- optimisations are programmer friendly, extentions
  generally aren't

- language changes can create problems in the long term,
  optimisations don't

I don't understand at all why the language change was
choosen over the optimisation, which, even applied in
a very restricted case, would be as powerfull as the
language extention.

The special case I have in mind is: all return statements
apply to the same local variable:

cv T f()
{
    cv T x (...);
    ...
    return x;
    ...
    return x;
}

If such things can't be easilly known from the static
analyser output, I'd say that there is a problem with
the static analyser.

--

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              ]

James Kuyper wrote:

> I wasn't very familiar with expression template techniques,
> but I did a web search and found
> <http://monet.uwaterloo.ca/~tveldhui/papers/Expression-Templates/exprtmpl.html>.
> The following example assumes the existence
> of the DExpr<> template family described in that paper:

>         template <class Expr> double finite_difference(
>                 DExpr<Expr>& expr, double x, double dx) {
>                 return expr(x+dx)-expr(x); }
>
> example of use:
>
>         DExpr<DExprIdentity> x;         // Placeholder
>         cout << finite_difference(x/(1.0+x), 10.0, 0.1);

Now, can you use this example to explain the problems you mentioned?
Not quite. I didn't realize that you don't understand expression templates.
You need to read Todd's paper again.
Pay particular attention to how he defines

DVExpr<DVBinExprOp<DVec::iterT,DVec::iterT,DApAdd> >
operator+(const DVec& a, const DVec& b);

then ask yourself:

    "Is it reasonable to expect and application programmer
     who may be an engineer or scientist but not a computer scientist
     to define a complicated user function this way?"

I think the answer is no.  I think that Todd Veldhuizen and Scott Haney
also think the answer is no but you should ask them.
I believe that, in general, the application programmers
will want to use vector operations and functions
which they or the class library developer have already defined
to define new user functions.

> From e-mail we've exchanged, I get the impression the one key problem
> is your need to establish a standard interface that is implementable
> even using [Embedded C++] compilers that don't support templates.
> Is that the main problem?

No.

> Are there significant problems that are applicable even to applications
> that can afford to rely on full conformance with the standard?

Expression templates can and probably should be transparent
to the application programmer.  They can increase the time
required to compile a program significantly so you may want to
exclude them during program development and testing
then include them when you are ready to put the application
into service.

The class library developer might use templates
to define vector classes for example then include

        typedef Vector<float> floatVector;
        typedef Vector<double> doubleVector;
        // etc.

But the templates themselves are of little value to application programmers
because many if not most of the functions and operators are specializations
which application programmers would be obliged to implement themselves.
Application programmers are seldom interested in more that one base type
when they write user functions.
The author of a function template is obliged to consider how the function
will behave for all possible values of the parameters or risk the possibility
that a function template instantiated with an inappropriate type
will compile without any warning to the application programmer.
I don't think that it is reasonable to ask application programmers
to write function templates.  Do you?

Bob Tisdale <edwin@netwood.net>



[ 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              ]

AllanW@my-dejanews.com wrote:
>
> In article <36468627.5D8DEFEB@netwood.net>,
>   "E. Robert Tisdale" <edwin@netwood.net> wrote:
> > Has anyone compiled statistics about which compilers
> > implement each of the permitted optimizations?

> Permitted optimizations are *any* that follow the as-if rule:

The question was probably about optimisation which break
the as-if rule, and thus are easilly identified (with the
appropriate test-suite).

It's worth noting that egcs -O3 fails to do the obvious
optimisation in:

T f()
{
  T x;
  return x;
}

--

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              ]

"E. Robert Tisdale" <edwin@netwood.net> writes:

[...]

> then ask yourself:
>=20
>     "Is it reasonable to expect and application programmer
>      who may be an engineer or scientist but not a computer scientist
>      to define a complicated user function this way?"
>=20
> I think the answer is no.

Surprisingly the answer turns out to be "yes" with my collaborators
who aren't scientists neither engineers, but simple applied
mathematicians.=20

[...]

> I believe that, in general, the application programmers
> will want to use vector operations and functions
> which they or the class library developer have already defined
> to define new user functions.

I believe that, in general, the application programmers will use
available constructs which best fit their needs.

[...]

>=20
> Expression templates can and probably should be transparent
> to the application programmer.

the "should" part of this statement is a philosophical note that I
don't follow. Wheiter or not the expression templates should be
transparent to the application programmer depends a lot on what
he/she is doing... and the skills of the library implementer.

> ... They can increase the time
> required to compile a program significantly so you may want to
> exclude them during program development and testing
> then include them when you are ready to put the application
> into service.
>=20
> The class library developer might use templates
> to define vector classes for example then include
>=20
>         typedef Vector<float> floatVector;
>         typedef Vector<double> doubleVector;
>         // etc.
>=20
> But the templates themselves are of little value to application program=
mers
> because many if not most of the functions and operators are specializat=
ions
> which application programmers would be obliged to implement themselves.
> Application programmers are seldom interested in more that one base typ=
e
> when they write user functions.
> The author of a function template is obliged to consider how the functi=
on
> will behave for all possible values of the parameters or risk the possi=
bility
> that a function template instantiated with an inappropriate type
> will compile without any warning to the application programmer.

If there is no need to implement a function in a template fashion then=20
there is no point for a serious library implementer to make it a
template. How to correctly design a usable library is the responsability
of the library implementer.=20


> I don't think that it is reasonable to ask application programmers
> to write function templates.  Do you?

Well, I suggested the use of expression templates becasue they work
for me and others. If you find them unsuitable for your needs, please,=20
feel free to ignore my suggestion. Probably, your question could not be
answered in C++; perhaps might you want to look for the St Graal in
other programming leanguages.

--=20
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ 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 <36468627.5D8DEFEB@netwood.net>,
  "E. Robert Tisdale" <edwin@netwood.net> wrote:
> Has anyone compiled statistics about which compilers
> implement each of the permitted optimizations?

I would be impractical even to develop a list, without any
statistics, of which optimizations were permitted. For the
same reason that it would be impractical to make a list of
all legal variable names.

Permitted optimizations are *any* that follow the as-if rule:

  1.8  Program execution                               [intro.execution]

1 The semantic descriptions in  this  International  Standard  define  a
  parameterized  nondeterministic  abstract machine.  This International
  Standard places no requirement on the structure of  conforming  imple-
  mentations.   In  particular, they need not copy or emulate the struc-
  ture of the abstract machine.  Rather, conforming implementations  are
  required  to  emulate  (only)  the observable behavior of the abstract
  machine as explained below.3)
  _________________________
  3) This provision is sometimes called the "as-if" rule, because an im-
  plementation  is  free to disregard any requirement of the Standard as
  long as the result is as if the requirement had been obeyed, as far as
  can be determined from the observable behavior of the program.

The "observable behavior" is generally considered not to
include the amount of time needed for any particular
calculation.

For instance, compiled programs on the abstract machine are
required to make copies of variables that are passed by value,
but the output of real compilers can skip this copy if it can
be sure that there is no difference in "observable behavior."

As you can see, this is a very broad category of changes.
But best important of all, it does nothing to inhibit
innovation. If the C++ implementor discovers a new possible
optimization, she doesn't have to run to the C++ committee
(or anyone else) to "get permission" to use it. So long as
it follows the as-if rule, it's permitted.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

E. Robert Tisdale wrote:
>
> James Kuyper wrote:
....
> >>> You might also want to experiment
> >>> with the expression template techniques.
> >>> Alternatively, you can take an STL-like approach
> >>> in separating the representations from the algorithms
> >>> and providing iterator-like objects to operate on your vectors.
> >>
> >> These optimization techniques may be appropriate
> >> for class library functions but they are not practical
> >> for user-defined functions.
> >
> > Why not? What are the problems?
>
> Take a shot at it.
> Show us how you would define a user function
> using expression template techniques.

I wasn't very familiar with expression template techniques, but I did a
web search and found
<http://monet.uwaterloo.ca/~tveldhui/papers/Expression-Templates/exprtmpl.html>.
The following example assumes the existence of the DExpr<> template
family described in that paper:

 template <class Expr> double finite_difference(
  DExpr<Expr>& expr, double x, double dx
 ){
  return expr(x+dx)-expr(x);
 }

example of use:

 DExpr<DExprIdentity> x;         // Placeholder
        cout << finite_difference(x/(1.0+x), 10.0, 0.1);

Now, can you use this example to explain the problems you mentioned?

>>>>> Valentin Bonnard <bonnardv@pratique.fr> wrote:

[...]

>> Unfortunately.

> Are you saying that being able to compile a C++ program
> is infortunate ?

Obviously not. I find it unfornate for the numerical computing
community that the return value optimization isn't widely implemented
(and in some sense mandatory).

--
Gabriel Dos Reis  dosreis@cmla.ens-cachan.fr
---
[ 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              ]

James Kuyper wrote:

Thank you James,

I don't have a copy of the standard
or a language lawyer to help me interpret it.

>>> You might also want to experiment
>>> with the expression template techniques.
>>> Alternatively, you can take an STL-like approach
>>> in separating the representations from the algorithms
>>> and providing iterator-like objects to operate on your vectors.
>>
>> These optimization techniques may be appropriate
>> for class library functions but they are not practical
>> for user-defined functions.
>
> Why not? What are the problems?

Take a shot at it.
Show us how you would define a user function
using expression template techniques.

>> I was hoping that after all the discussion about elided
>> copy constructors, some consensus would emerge
>> about the optimizations we should expect
>> from a quality C++ compiler.
>
> Expectations like that are made to be dashed.
> The best thing to do
> is to make your code insensitive to such optimizations,
> and then complain to your vendor
> if their implementation performs them incorrectly,
> or insufficiently often.

I gather from what you say that there was no consensus.
Has anyone compiled statistics about which compilers
implement each of the permitted optimizations?

Thanks in advance, Bob Tisdale <edwin@netwood.net>



[ 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              ]

E. Robert Tisdale wrote:
>
> James Kuyper wrote:
>
> Thank you James,
>
> I don't have a copy of the standard
> or a language lawyer to help me interpret it.

It's cheap: $18. Some people have complained that it's not available in
HTML format, and that you can't cut-and-paste from it, and those are are
both real disadvantages. However, there were enough changes from CD2 to
make buying it worth it, for me.

You can get all the interpretation you can handle simply by asking this
newsgroup; that's one of the things it's for.

...
> >> I was hoping that after all the discussion about elided
> >> copy constructors, some consensus would emerge
> >> about the optimizations we should expect
> >> from a quality C++ compiler.
> >
> > Expectations like that are made to be dashed.
> > The best thing to do
> > is to make your code insensitive to such optimizations,
> > and then complain to your vendor
> > if their implementation performs them incorrectly,
> > or insufficiently often.
>
> I gather from what you say that there was no consensus.
> Has anyone compiled statistics about which compilers
> implement each of the permitted optimizations?

I'm not qualified to comment on the presence or absence of a concensus.
I'm not a committee member, just an interested outsider who's only been
following this newsgroup for two years. However, as a general rule,
standards are written to allow optimizations, but not to require them.
This allows for conforming implementations to be developed more quickly,
for a wider variety of platforms, than would otherwise be possible.


[ 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              ]

Gabriel Dos Reis wrote:

> There has been recently a long thread
> about copy-constructor optimizations in this group.
> The Standard does allow, in some special cases
> (e.g. return value from a function call),
> two forms of optimizations.  But they are not mandatory,
> so you are at the mercy of your compiler. Unfortunately.

Can you enumerate all of the cases for us?
Apparently, my GNU C++ compiler can elide
the copy constructor whenever a constructor
or a function which returns by value appears

1.)    in a function argument list,
2.)    in an initializer and
3.)    after the return keyword.

There may be other cases in which the GNU C++ compiler
elides copy constructors but apparently the copy constructor
is always called whenever a reference to an object appears
after the return keyword:

    doubleVector f(Length n) {
        doubleVector    result(n);
        // initialize result somehow
        return result;        // copy constructor called
        }

In this case, it would be nice if the constructor
for result would simply construct the return value
and eliminate the copy constructor.

> The GNU compiler implements an extension
> that does a named return value optimization.

I know, but the GNU extensions are not portable
and I don't like the way that they work.

> You might also want to experiment
> with the expression template techniques.
> Alternatively, you can take an STL-like approach
> in separating the representations from the algorithms
> and providing iterator-like objects to operate on your vectors.

These optimization techniques may be appropriate
for class library functions but they are not practical
for user-defined functions.

I was hoping that after all the discussion about elided
copy constructors, some consensus would emerge
about the optimizations we should expect
from a quality C++ compiler.

Thanks in advance, Bob Tisdale <edwin@netwood.net>



[ 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              ]

Gabriel Dos Reis <dosreis@DPTMaths.ENS-Cachan.Fr> writes:

> The Standard does allow in some special
> cases (e.g. return value from a function call) two forms of
> optimisations. But they are not mandatory, so you are at the merci of
> your compiler.

In general, knowing that it's possible to optimise isn't
decidable.

> Unfortunately.

Are you saying that being able to compile a C++ program
is infortunate ?

--

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              ]

E. Robert Tisdale wrote:
 >
 > Gabriel Dos Reis wrote:
 >
 > > There has been recently a long thread
 > > about copy-constructor optimizations in this group.
 > > The Standard does allow, in some special cases
 > > (e.g. return value from a function call),
 > > two forms of optimizations.  But they are not mandatory,
 > > so you are at the mercy of your compiler. Unfortunately.
 >
 > Can you enumerate all of the cases for us?

According to section 12.8, paragraph 15:
| Whenever a temporary class object is copied using a copy constructor,
| and this object and the copy have the same cv-qualified type, an
| implementation is permitted to treat the original and the copy as two
| different ways of referring to the same object and not perform the
| copy at all, even if the class copy constructor or destructor have
| side effects. For a function with a class return type, if the
| expression in the return statement is the name of a local object, and
| the cv-unqualified type of the local object is the same as the
| function return type, and implementation is permitted to omit creating
| the temporary object to hold the function reutrn value, even if the
| class copy constructor or destructor has side effects. In these cases,
| the object is destroyed at the later of times when the original and
| copy would have been destroyed without the optimization.

...
 >     doubleVector f(Length n) {
 >         doubleVector    result(n);
 >         // initialize result somehow

It's too late to initialize it, that happened on the previous line.

 >         return result;        // copy constructor called
 >         }
 >
 > In this case, it would be nice if the constructor
 > for result would simply construct the return value
 > and eliminate the copy constructor.

It looks to me like your compiler is permitted to eliminate that copy
constructor. Of course, it's not required to do so, but you can complain
to the vendor about it.

...
 > > You might also want to experiment
 > > with the expression template techniques.
 > > Alternatively, you can take an STL-like approach
 > > in separating the representations from the algorithms
 > > and providing iterator-like objects to operate on your vectors.
 >
 > These optimization techniques may be appropriate
 > for class library functions but they are not practical
 > for user-defined functions.

Why not? What are the problems?

 > I was hoping that after all the discussion about elided
 > copy constructors, some consensus would emerge
 > about the optimizations we should expect
 > from a quality C++ compiler.

Expectations like that are made to be dashed. The best thing to do is to
make your code insensitive to such optimizations, and then complain to
your vendor if their implementation performs them incorrectly, or
insufficiently often.
---
[ 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              ]

An optimizing C++ compiler may elide a copy constructor.
This is especially convenient for user defined functions
which would require a deep copy of the underlying array
to return a vector, matrix or tensor object by value.

Is there any standard or convention which would tell
C++ class library designers when they should expect
a reasonably good optimizing C++ compiler to elide
a copy constructor?

I need to know when I should design a work-around
for copy constructors that are not elided.

I compiled the attached C++ code with my GNU C++ compiler
(version 2.7.2.3) using the -felide-constructors option.
The copy constructor is called when creating a doubleVector
from a function that returns a constant doubleVector but
the copy constructor is elided when creating a doubleVector
from a function that returns a variable doubleVector.
The copy constructor is elided
when function f() returns but not when function g() returns.

The C++ Scalar, Vector, Matrix and Tensor classes
are available from

        http://www.netwood.net/~edwin/svmt/

Thanks in advance, Bob Tisdale <edwin@netwood.net>


#include<svmt.h>

inline
  const doubleVector icf(const doubleSubVector& v) { return v; }
inline
        doubleVector ivf(const doubleSubVector& v) { return v; }

  const doubleVector xcf(const doubleSubVector& v);
        doubleVector xvf(const doubleSubVector& v);

inline
        doubleVector f(const doubleSubVector& v) {
  return doubleVector(v); }
inline
        doubleVector g(const doubleSubVector& v) {
  doubleVector  w(v); return w; }

int
main() {
  doubleVector  v(4, 1.0);

  cerr << "const doubleVector r = icf(v);\n";
  const doubleVector    r = icf(v);     // copied
  cerr << "      doubleVector s = icf(v);\n";
        doubleVector    s = icf(v);     // copied

  cerr << "const doubleVector t = ivf(v);\n";
  const doubleVector    t = ivf(v);     // elided
  cerr << "      doubleVector u = ivf(v);\n";
        doubleVector    u = ivf(v);     // elided

  cerr << "const doubleVector w = xcf(v);\n";
  const doubleVector    w = xcf(v);     // copied
  cerr << "      doubleVector x = xcf(v);\n";
        doubleVector    x = xcf(v);     // copied

  cerr << "const doubleVector y = xvf(v);\n";
  const doubleVector    y = xvf(v);     // elided
  cerr << "      doubleVector z = xvf(v);\n";
        doubleVector    z = xvf(v);     // elided

  cerr << "      doubleVector a = f(v);\n";
        doubleVector    a = f(v);       // elided
  cerr << "      doubleVector b = g(v);\n";
        doubleVector    b = g(v);       // copied

  return 0;
  }
---
[ 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              ]

>>>>> E Robert Tisdale <edwin@netwood.net> wrote:

> An optimizing C++ compiler may elide a copy constructor.
> This is especially convenient for user defined functions
> which would require a deep copy of the underlying array
> to return a vector, matrix or tensor object by value.

> Is there any standard or convention which would tell
> C++ class library designers when they should expect
> a reasonably good optimizing C++ compiler to elide
> a copy constructor?

There has been recently a long thread about copy-constructor
optimisations in this group. The Standard does allow in some special
cases (e.g. return value from a function call) two forms of
optimisations. But they are not mandatory, so you are at the merci of
your compiler. Unfortunately.

> I need to know when I should design a work-around
> for copy constructors that are not elided.

This is very tricky and depends a lot on your compiler.

> I compiled the attached C++ code with my GNU C++ compiler
> (version 2.7.2.3) using the -felide-constructors option.

The GNU compiler implements an extension that does a named return
value optimisation. You might want to take a look at the
documentation.

You might also want to experiment with the expression template
techniques.

Alternativelly, you can take an STL-like approach in separating the
representations from the algorithms and providing iterator-like
objects to operate one your vectors.

HTH,

--
Gabriel Dos Reis                   |  Centre de Math   matiques et de
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex


[ 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              ]