non-const reference to temporary derived from pure virtual Base

[reppisch]

Hi Ng,

besides that this style may be asking for trouble i'm faced with a
unexpected gcc behaviour. Tested with gcc 3.3.3.
On M$ .Net this compiles just fine.

I'm trying to make a non-const reference to a temporary object. The
object is derived from a pure virtual base, so the compiler can't create
a copy of base-type.

Why does this not work with gcc?

To reproduce:
//-----------------------------------
class Base {
public:
Base() {};
virtual void pv() = 0;
virtual ~Base() {};
};

class Derived : public Base {
public:
Derived(int i) {};
virtual void pv() {};
virtual ~Derived() {};
};

class User {
public:
void useBase(Base& b) {};
void useBaseConst(const Base& b) {};
};
int main() {
User u;
Derived d(1);
// Ok with non-temporary !
u.useBase(d);

// not ok!
u.useBase(Derived(1));
//* no matching function for call to `User::useBase(Derived)'
//* candidates are: void User::useBase(Base&)
// seems that the compiler refuses to make a
// non-const reference to a temporary

// but this is ok!
u.useBaseConst(Derived(1));

}

Regards,

Michael

[reppisch]

Hi,

i striped it down further to:

class Derived {
public:
Derived(int i) {};
};

class User {
public:
void useBase(Derived& b) {};
};

int main() {
User u;
u.useBase(Derived(1));
}

I think it's just a "feature" to prevent writing code with surprising
results....

[=?ISO-8859-1?Q?Marcel_M=FCller?=]

reppisch schrieb:

// not ok!
u.useBase(Derived(1));
//* no matching function for call to `User::useBase(Derived)'
//* candidates are: void User::useBase(Base&)
// seems that the compiler refuses to make a
// non-const reference to a temporary

Exactly that. Temporaries are like rvalues.

I had a similar question some time ago (maybe in the german group).
Somebody explained me that this is intended by the standard, because
there are risks otherwise.

You must create a non-temporary object for this purpuse.

Derived d(1);
u.useBase(d);

Marcel

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-05-06 16:41, reppisch wrote:

Hi Ng,

besides that this style may be asking for trouble i'm faced with a
unexpected gcc behaviour. Tested with gcc 3.3.3.
On M$ .Net this compiles just fine.

I'm trying to make a non-const reference to a temporary object. The
object is derived from a pure virtual base, so the compiler can't create
a copy of base-type.

Are you sure VS.NET allowed that? If that is the case you really should
check the options you provide to the compiler because making a non-const
reference to a temporary is forbidden by the standard.

--
Erik Wikström

[sk_usenet]

"Erik Wikström" <Er***********@telia.comwrote in message

On 2008-05-06 16:41, reppisch wrote:

>Hi Ng,

besides that this style may be asking for trouble i'm faced with a
unexpected gcc behaviour. Tested with gcc 3.3.3.
On M$ .Net this compiles just fine.

I'm trying to make a non-const reference to a temporary object. The
object is derived from a pure virtual base, so the compiler can't create
a copy of base-type.

Are you sure VS.NET allowed that? If that is the case you really should
check the options you provide to the compiler because making a non-const
reference to a temporary is forbidden by the standard.

Yes, by default VC allows this as an extension to Standrad (I tested a long
time back on probably v7.0). I think it's the /Za option in VC compiler that
would flash the error.

--
http://techytalk.googlepages.com

[Andrey Tarasevich]

reppisch wrote:

...
i striped it down further to:
...

You can strip it down to

void foo(int&);
foo(1);

But the bottom line is that explicit binding of non-const references to
temporary objects is illegal in C++.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

sk_usenet wrote:

...
Yes, by default VC allows this as an extension to Standrad (I tested a long
time back on probably v7.0). I think it's the /Za option in VC compiler that
would flash the error.
...

Yes, /Za will fix it.

Without /Za in VS2005 even they implemented a mix of standard behavior
and extended behavior so that the whole thing does seem to satisfy the
formal definition of "compiler extension", while the VC6 was genuinely
and hopelessly broken in that regard.

A plug: see item 2.3 in
http://atarasevich.blogspot.com/2008...liance_07.html

--
Best regards,
Andrey Tarasevich