>  12.2  Temporary objects                              [class.temporary]
>
>1 In some circumstances it might be necessary or convenient for the pro-
>  cessor to generate a temporary object.   Precisely  when  such  tempo-
>  raries  are  introduced is implementation-defined.  Even when the cre-
>  ation of the temporary object is avoided, all  the  semantic  restric-
>  tions  must  be  respected  as  if  the  temporary object was created.
>  [Example: even if the copy constructor is not called, all the semantic
>  restrictions, such as accessibility, shall be satisfied.  ]

Why not simply give a list of optimisations that must be done:

T a = b;
T a (b);
are compiled the same way

T f (...) // ... here mean argument list, not vararg
{
    ...
    T temp;
    ...
    return temp;
}

T a;
a = f (...);

temp _is_ a (except if a is in the scope of f)
else temp is directly copied into a

f (...);

A temporary is created to receive the result.

Thus f would be equivalent to fast_f:

void    fast_f (T& temp, ...)
{
    ...
    ...
}

This can be important for operators because it's impossible to give
them a T&.  (The problem with f can be solved by passing a T&.)

Nowadays, programmers are forced use ref-counted class to ensure that
big objects are not copied, and a counter (an int) created with
operator new can be a memory and speed hit.

Optimisations of the assembly code cannot be checked, but optimisations
at the "cfront level" can.

-----------------------------
My opinions are mines.

Valentin Bonnard
bonnardv@pratique.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard (bonnardv@pratique.fr) wrote:
: Why not simply give a list of optimisations that must be done:

As someone has noted, a cheap, fast, nonoptimizing compiler has a
market nitch.

: T a = b;
: T a (b);
: are compiled the same way

But they are not the same.  Consider:
class X { int x;
        X (const X& s) : x(s.x) { }
    public :
        X (int i) : x(i) { }
    };
struct A {
        A (int i) : a(i) { }
        int a;
    };
class Y { int y;
    public :
        Y (A a) : y(a.a) { }
    };
int main () {
    X x1(5);  // ok X(int)
    X x2 = 5; // error X(X(5)) but my compilers accept it? ?????
    Y y1(5);  // ok Y(A(5)) one implicit conversion.
    Y y2 = 5; // error Y(Y(A(5)) two implicit conversions.
    return 0;
    }

John


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jpotter@falcon.lhup.edu (John E. Potter) wrote:
>Valentin Bonnard (bonnardv@pratique.fr) wrote:
>: Why not simply give a list of optimisations that must be done:
>
>As someone has noted, a cheap, fast, nonoptimizing compiler has a
>market nitch.

Given the complexity of the language, can a C++ compiler be 'cheap'
(simple, small, fast) ? ;->

If you want a fast compiler, use Turbo Pascal (the Pascal has no
ambiguity like A * B (A mult B or B is a pointer to A ?)).

I don't want all compilers to understand the code and cleverly optimise
it, but to apply simples transformations in simples [and, what is more,
given and standard] cases.

To recognise a = b as a (b) is really a no-op.

>: T a = b;
>: T a (b);
>: are compiled the same way
>
>But they are not the same.  Consider:

Right, they are not the same, and what ?

That's _not_ the question !

-----------------------------
My opinions are mines.

Valentin Bonnard
bonnardv@pratique.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4lrl3o$rco@s3.iway.fr> Valentin Bonnard
<bonnardv@pratique.fr> writes:

|> >  12.2  Temporary objects                              [class.temporary]
|> >
|> >1 In some circumstances it might be necessary or convenient for the pro-
|> >  cessor to generate a temporary object.   Precisely  when  such  tempo-
|> >  raries  are  introduced is implementation-defined.  Even when the cre-
|> >  ation of the temporary object is avoided, all  the  semantic  restric-
|> >  tions  must  be  respected  as  if  the  temporary object was created.
|> >  [Example: even if the copy constructor is not called, all the semantic
|> >  restrictions, such as accessibility, shall be satisfied.  ]

|> Why not simply give a list of optimisations that must be done:

Because the list would be empty:-).  By definition, if it must be done,
it isn't an optimization any longer.

|> T a = b;
|> T a (b);
|> are compiled the same way

|> T f (...) // ... here mean argument list, not vararg
|> {
|>     ...
|>     T temp;
|>     ...
|>     return temp;
|> }

|> T a;
|> a = f (...);

|> temp _is_ a (except if a is in the scope of f)
|> else temp is directly copied into a

Careful here.  In fact, `temp' cannot be `a', ever, but must be a
separate variable.  The object `temp' must be constructed, whereas the
object `a' must be assigned.

|> f (...);

|> A temporary is created to receive the result.

|> Thus f would be equivalent to fast_f:

|> void    fast_f (T& temp, ...)
|> {
|>     ...
|>     ...
|> }

|> This can be important for operators because it's impossible to give
|> them a T&.  (The problem with f can be solved by passing a T&.)

|> Nowadays, programmers are forced use ref-counted class to ensure that
|> big objects are not copied, and a counter (an int) created with
|> operator new can be a memory and speed hit.

I doubt any intensively used ref-counted class would be so naive as to
call the global operator new for each int.  Most of the reference
counted schemes I've seen (including my own) are invasive, but even for
a non invasive scheme, better solutions are available.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "VB" == Valentin Bonnard <bonnardv@pratique.fr> writes:
[ ... on the subject of extraneous temporaries ]
VB> This can be important for operators because it's impossible to
VB> give them a T&.  (The problem with f can be solved by passing a
VB> T&.)

VB> Nowadays, programmers are forced use ref-counted class to ensure
VB> that big objects are not copied, and a counter (an int) created
VB> with operator new can be a memory and speed hit.
[...]

This is not quite true; see my approximation of valarrays for a
technique that doesn't use reference-counting and suffers relatively
little overhead (this overhead is likely to drop when member function
templates become more commonly available).

 Daveed

P.S.: there is some source code in
      ftp://ftp.cs.rpi.edu/pub/~vandevod/Valarray/...
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@gabi-soft.fr (J. Kanze) wrote:
|> In article <4lrl3o$rco@s3.iway.fr> Valentin Bonnard <bonnardv@pratique.fr> writes:
|> |> Why not simply give a list of optimisations that must be done:
|>
|> Because the list would be empty:-).  By definition, if it must be done,
|> it isn't an optimization any longer.

Please... please. Today that's an optimisation.

|> |> T a = b;
|> |> T a (b);
|> |> are compiled the same way
|>
|> |> T f (...) // ... here mean argument list, not vararg
|> |> {
|> |>     ...
|> |>     T temp;
|> |>     ...
|> |>     return temp;
|> |> }
|>
|> |> T a;
|> |> a = f (...);
|>
|> |> temp _is_ a (except if a is in the scope of f)
|> |> else temp is directly copied into a
|>
|> Careful here.  In fact, `temp' cannot be `a', ever, but must be a
|> separate variable.  The object `temp' must be constructed, whereas the
|> object `a' must be assigned.

a could be destructed before.

|> |> f (...);
|>
|> |> A temporary is created to receive the result.
|>
|> |> Thus f would be equivalent to fast_f:
|>
|> |> void    fast_f (T& temp, ...)
|> |> {
|> |>     ...
|> |>     ...
|> |> }
|>
|> |> This can be important for operators because it's impossible to give
|> |> them a T&.  (The problem with f can be solved by passing a T&.)
|>
|> |> Nowadays, programmers are forced use ref-counted class to ensure that
|> |> big objects are not copied, and a counter (an int) created with
|> |> operator new can be a memory and speed hit.
|>
|> I doubt any intensively used ref-counted class would be so naive as to
|> call the global operator new for each int.  Most of the reference
|> counted schemes I've seen (including my own) are invasive, but even for
|> a non invasive scheme, better solutions are available.

Perhaps, but you have to a use complex run-time solution to solve a
                                       ^^^^^^^^
semantic (compile-time) problem of arguments that cannot be passed by constT&.
^^^^^^^^^^^^^^^^^^^^^^^

I don't want to solve a simple problem with very powerfull and clever constructs.

-----------------------------
My opinions are mines.

Valentin Bonnard
bonnardv@pratique.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4m5d7f$9j5@s3.iway.fr> Valentin Bonnard
<bonnardv@pratique.fr> writes:

|> |> |> T a = b;
|> |> |> T a (b);
|> |> |> are compiled the same way
|> |>
|> |> |> T f (...) // ... here mean argument list, not vararg
|> |> |> {
|> |> |>     ...
|> |> |>     T temp;
|> |> |>     ...
|> |> |>     return temp;
|> |> |> }
|> |>
|> |> |> T a;
|> |> |> a = f (...);
|> |>
|> |> |> temp _is_ a (except if a is in the scope of f)
|> |> |> else temp is directly copied into a
|> |>
|> |> Careful here.  In fact, `temp' cannot be `a', ever, but must be a
|> |> separate variable.  The object `temp' must be constructed, whereas the
|> |> object `a' must be assigned.

|> a could be destructed before.

Not according to the current rules.  There is nothing in the standard
which requires my user defined operator= to have the same semantics as
destructor followed by constructor.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]