Re: C4239 - why here?
- From: "Doug Harrison [MVP]" <dsh@xxxxxxxx>
- Date: Fri, 23 Sep 2005 10:19:15 -0500
On Fri, 23 Sep 2005 13:48:01 +0200, "Goran Pusic" <goran_pusic@xxxxxxxxx>
wrote:
>But, that's not my situation. I have X as a "polymorphic worker class", and
>it may or not change inside X, I don't care. I just want to it passed to F
>to get polymorphic behaviour in F depending on the calling context).
>Sort-of:
>BaseX
>{ virtual f() }
>X1:BaseX { overridden virtual F() }
>X2, X3...
>and then F(BaseX&) gets called like this: F(X1(params)), F(X2(params)),
>F(X3(params)) etc...
I talked about this problem here and in the message referenced from 1997:
http://groups.google.com/group/microsoft.public.vc.stl/msg/0e2c9910ccae9bfd
The solution (kludge) I settled on was to make F take a spuriously const
X1&, which is fine unless the class stores a reference or pointer to the
object. The problem with a const X& parameter then is that it's very easy
to slip up and pass a temporary, which will be destroyed at the end of the
expression containing the function call, long before the class has finished
using it.
I once posted this as an example of a sort of built-in joke concerning the
whole rvalue/lvalue/reference behavior:
*****
http://groups.google.com/groups?selm=31bsovcdd32iedsj2utmqlmd78li40m7p6%404ax.com
struct X
{
};
void g(X&);
void f()
{
X() = X();
g(X() = X());
g(X()); // No good
}
Note that above, the result of assigning one rvalue to another rvalue
is a modifiable lvalue. :)
*****
The difference between the rvalues produced by X() and int() is that the
former has member functions you can call on it, and you're allowed to call
them, including the assignment operator, which by default returns a
reference to the object assigned.
--
Doug Harrison
VC++ MVP
.
- References:
- C4239 - why here?
- From: Goran Pusic
- Re: C4239 - why here?
- From: Tom Widmer [VC++ MVP]
- Re: C4239 - why here?
- From: Goran Pusic
- C4239 - why here?
- Prev by Date: Re: C4239 - why here?
- Next by Date: Re: C4239 - why here?
- Previous by thread: Re: C4239 - why here?
- Next by thread: Re: C4239 - why here?
- Index(es):
Relevant Pages
|
Loading