Temporary Object

H

Haochen Xie

Assuming we have class C defined as:

class C {
public:
int x, y;
C operator++() { ++x, ++y; return *this; }
};

So the following line is legal since C is a user defined type:

++C();

But could any one tell me why the following codes are illegal:

void foo(C &c, int val) {
printf("%d, %d\n", c.x, c.y);
c.x = c.y = val;
printf("%d, %d\n", c.x, c.y);
}
int main() {
foo(C(), 8);
}

When I try to compile it with gcc, the compiler complains:

invalid initialization of non-const reference of type 'C&' from an
rvalue of type 'C'

in passing argument 1 of 'void foo(C&, int)'

Is there any reason to make it invalid? And is there any way to pass a
temporary object to a mutable function without a variable to hold it?
 
I

Ian Collins

Haochen said:
Assuming we have class C defined as:

class C {
public:
int x, y;
C operator++() { ++x, ++y; return *this; }
};

So the following line is legal since C is a user defined type:

++C();

But could any one tell me why the following codes are illegal:

void foo(C &c, int val) {
printf("%d, %d\n", c.x, c.y);
c.x = c.y = val;
printf("%d, %d\n", c.x, c.y);
}
int main() {
foo(C(), 8);
}

When I try to compile it with gcc, the compiler complains:

invalid initialization of non-const reference of type 'C&' from an
rvalue of type 'C'

in passing argument 1 of 'void foo(C&, int)'

Is there any reason to make it invalid? And is there any way to pass a
temporary object to a mutable function without a variable to hold it?

It's invalid because the standard says so!

In most cases, it makes little sense to perform non-const operations on
a temporary object.
 
H

Haochen Xie

Ian said:
It's invalid because the standard says so!

In most cases, it makes little sense to perform non-const operations on
a temporary object.

Yeah, I also think that's the only reason why it's invalid, since you
could actually call a member function on a temporary object and the
function could pass itself as an argument to another function, which
could bypass this restriction (and that shows their should not be
technical difficulty).

Actually I saw this code from Crypto++ User's Guide by denis bider:

// Crypto++
#include "cryptlib.h"

// std
#include <iostream>


void DumpMessage(CryptoPP::BufferedTransformation& bt)
{
using namespace std;

static char const* szHexDigits = "0123456789abcdef";
byte b;
while (bt.AnyRetrievable())
{
if (!bt.Get(b))
throw "Error: AnyRetrievable() returned true, "
"so this shouldn't happen.";

// It is much easier to implement this using HexEncoder;
// however, let's not get into that just yet. The below code
// could do some special kind of processing that is not
// supported by an off-the-shelf Filter class.

cout << szHexDigits[(b >> 4) & 0x0f]
<< szHexDigits[b & 0x0f]
<< ' ';
}
}


// Crypto++
#include "filters.h"

int main()
{
using namespace CryptoPP;

char const* szMessage = "How do you do?";
DumpMessage(StringSource(szMessage, true));
// If we constructed StringSource with 'false' instead
// of 'true',
// StringSource wouldn't call its PumpAll() method on
// construction,
// and no data would be extractable from the StringSource
// object
// until someone called the object's Pump() or PumpAll()
// method.

return 0;
}

That doesn't compile on my compiler, but it's on the tutorial anyway.
Probably the author's compiler does not follow the standard on this issue.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top