 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Marcel Loose
Guest
|
 Posted: Thu Oct 14, 2004 8:25 pm Post subject: [Q} Rationale behind C++ rule on copying temporary object to |
 |
|
Hi,
Can anyone explain the rationale behind the C++ standard rule
[dcl.init.ref]/5, bullet 2, sub-bullet 1 (see also [class.temporary]/2) ?
In short, what this rule says is that, when you pass a temporary object to a
(member) function that expects a const reference, the temporary should be
copy-constructible. To me, this is counter-intuitive. One of the reasons (I
was taught) to use const references in a function's parameter list is to
allow passing of temporary objects, because temporary objects are
effectively const. This rule obviously forbids this use for non-copyable
objects.
So, if I understand it correctly, if I have a class that is non-copyable, I
am you are forced to first create an instance of that class and then pass
that instance to the function which may create a copy of that instance. What
a waste of CPU cycles!. I don't get it. Anyone, please?
Regards,
Marcel Loose.
---
[ 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 ]
|
|
| Back to top |
|
 |
Bronek Kozicki
Guest
|
| Posted: Sat Oct 16, 2004 6:29 pm Post subject: Re: [Q} Rationale behind C++ rule on copying temporary objec |
|
|
Marcel Loose wrote:
| Quote: | In short, what this rule says is that, when you pass a temporary object to a
(member) function that expects a const reference, the temporary should be
copy-constructible. To me, this is counter-intuitive. One of the reasons (I
was taught) to use const references in a function's parameter list is to
allow passing of temporary objects, because temporary objects are
effectively const. This rule obviously forbids this use for non-copyable
objects.
|
Temporary objects are not "effectively const". See below, well-formed code:
struct A
{
void f() {} // non-const!
};
A a() {return A();}
int main()
{
a().f();
}
| Quote: | So, if I understand it correctly, if I have a class that is non-copyable, I
am you are forced to first create an instance of that class and then pass
that instance to the function which may create a copy of that instance. What
a waste of CPU cycles!. I don't get it. Anyone, please?
|
I think that you get it wrong. If you create variable, it's no longer
rvalue but lvalue, and second bullet does not apply. Copy is not
created, and reference (the one being parameter of function) is directly
bound to variable per first bullet of clause 8.5.3/5. Copy constructor
does not need to be available; you do not loose any extra CPU cycles
here. Following code is well-formed:
class B
{
B(const B&);
public:
B(){}
};
void f(const B&) {}
int main()
{
B b;
f(b);
}
On the other hand, if you create temporary (that is, rvalue) and pass it
to function, implementation is free to create copy of this temporary and
bound const reference (the one being parameter of function) to this
copy, per second bullet of said clause. However, this behaviour is
implementation defined - obviously compiler with strong optimisation
won't create this copy, thus you do not loose any extra CPU cycles.
However copy constructor needs to be available. Thus following code is
ill-formed:
class C
{
C(const C&);
public:
C(){}
};
void g(const C&) {}
int main()
{
g(C());
}
as well as following one:
class D
{
D(const D&);
friend D f();
public:
D(){}
};
D f() {return D();}
int main()
{
const D& d = f();
}
I understand your question as to why this behaviour is allowed at all;
sincerly, I do not know answer - I suppose that it's to give some
freedom to implementers. I'd like to know answer to your question, too
B.
---
[ 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 ]
|
|
| Back to top |
|
|
Michiel Salters
Guest
|
| Posted: Mon Oct 25, 2004 4:11 pm Post subject: Re: [Q} Rationale behind C++ rule on copying temporary objec |
|
|
[email]loose (AT) astron (DOT) nl[/email] ("Marcel Loose") wrote in message news:<2t6r1kF1sk6l5U1 (AT) uni-berlin (DOT) de>...
| Quote: | Hi,
Can anyone explain the rationale behind the C++ standard rule
[dcl.init.ref]/5, bullet 2, sub-bullet 1 (see also [class.temporary]/2) ?
In short, what this rule says is that, when you pass a temporary object to a
(member) function that expects a const reference, the temporary should be
copy-constructible. To me, this is counter-intuitive. One of the reasons (I
was taught) to use const references in a function's parameter list is to
allow passing of temporary objects, because temporary objects are
effectively const. This rule obviously forbids this use for non-copyable
objects.
|
Th rationale was that there may be compilers which cannot implement
direct binding. However, during the discussion of CWG issue 391 this
was reconsidered, and it seems there is no fundamental prolem. Based
on this, there is consensus to drop the freedom of compilers here,
and to require direct binding.
(Note: the wording in some versions of issue said:
"Notes from the March 2004 meeting:
After discussing issue 450, we found ourselves reconsidering this, and we
are not inclined to make a change to require the direct binding in all
cases, with no restriction on long-lived references. Note that such a
change would eliminate the need for a change for issue 291."
This is incorrect; we _are_ inclined to make a change. )
| Quote: | So, if I understand it correctly, if I have a class that is non-copyable, I
am you are forced to first create an instance of that class and then pass
that instance to the function which may create a copy of that instance. What
a waste of CPU cycles!. I don't get it. Anyone, please?
|
Theoretically, a compiler could waste CPU cycles on anything. In practice,
compilers didn't copy anyway. This was basically a QoI issue.
Regards,
Michiel Salters
---
[ 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 ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
