non-const function return values: gcc bug or language flaw?

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

If you have a function that returns something by value, the gcc compiler
(version 3.2.3 on Windows XP with MinGW) converts the returned value
from the type you specify in the code, to the const version of that type.

Is this a bug that is specific to gcc, or is it a flaw in the language
specification that gcc diligently implements? For example, the below
program produces the output

Constant
Mutable
Constant
Constant

instead of the expected

Constant
Mutable
Constant
Mutable

Microsofts Visual C++ version 6 gives the second version (which I would
consider to be the correct one)


------------------------------------------------------------------------
#include <iostream>

class mytype
{
public:
mytype() {}
};

void print(const mytype& ival)
{
std::cout << "Constant" << std::endl;
}

void print(mytype& ival)
{
std::cout << "Mutable" << std::endl;
}

const mytype make_const()
{
return mytype();
}

mytype make_mutable()
{
return mytype();
}


//====================================================
int main() {

const mytype a;
print(a);

mytype b;
print(b);

print(make_const()); // Correctly prints "Constant"

print(make_mutable()); // gcc fails to print "Mutable"

return 0;
}

 

[Russell Hanneken]

void print(const mytype& ival)
{
std::cout << "Constant" << std::endl;
}

void print(mytype& ival)
{
std::cout << "Mutable" << std::endl;
}

mytype make_mutable()
{
return mytype();
}

int main() {

print(make_mutable()); // gcc fails to print "Mutable"

return 0;
}

The compiler is doing the right thing. Your call to make_mutable() returns
a temporary. You cannot pass a temporary to a function that takes a
non-const reference. So the overloading rules dictate that the best match
for the last call to print is the version that takes a const reference. The
argument gets converted from non-const to const.

 

[Rolf Magnus]

If you have a function that returns something by value, the gcc
compiler (version 3.2.3 on Windows XP with MinGW) converts the
returned value from the type you specify in the code, to the const
version of that type.

Is this a bug that is specific to gcc, or is it a flaw in the language
specification that gcc diligently implements?

Neither of those. The problem here is that the return value is a
temporary, and C++ doesn't allow non-const references to be bound to
temporaries. So the "Constant" overload must be called.

For example, the below
program produces the output

Constant
Mutable
Constant
Constant

instead of the expected

Constant
Mutable
Constant
Mutable

Microsofts Visual C++ version 6 gives the second version (which I
would consider to be the correct one)

There is a bug in that compiler that permits binding non-const
references to temporaries. That's the reason why it prints the second
version.

 

[Cy Edmunds]

If you have a function that returns something by value, the gcc compiler
(version 3.2.3 on Windows XP with MinGW) converts the returned value
from the type you specify in the code, to the const version of that type.

Is this a bug that is specific to gcc, or is it a flaw in the language
specification that gcc diligently implements? For example, the below
program produces the output

Constant
Mutable
Constant
Constant

instead of the expected

Constant
Mutable
Constant
Mutable

Microsofts Visual C++ version 6 gives the second version (which I would
consider to be the correct one)

The .NET compiler also gives the second version. Do you have a reference to
the standard on which to base your assessment of correctness?

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

[...]

Microsofts Visual C++ version 6 gives the second version (which I would
consider to be the correct one)

The .NET compiler also gives the second version. Do you have a reference to
the standard on which to base your assessment of correctness?

So it's "language flaw" then

I don't actually have access to the standard defining documents, so I
based my assessment of "correctness" on what I consider would have been
reasonable and useful behavior, but if the standard expressly defines
semantics that make it impossible to implement "deep const" semantics
for user defined smart pointers (for example), then of course gcc does
the right thing in implementing them.

A real big thank you to everybody who could answer my question so
promptly and expertly!

/Christian

 

[lilburne]

So it's "language flaw" then
No!

I don't actually have access to the standard defining documents, so I
based my assessment of "correctness" on what I consider would have been
reasonable and useful behavior, but if the standard expressly defines
semantics that make it impossible to implement "deep const" semantics
for user defined smart pointers (for example), then of course gcc does
the right thing in implementing them.

You used syntactic sugar in your class design. If you
overload a function on name alone, and which of the two
functions gets called is important to you then you are going
to be disappointed. Don't do it.

Passing a temporary to a function that takes a non-const
reference makes no sense, because any changes that are made
to the temporary will be lost when the temporary goes out of
scope. Which at the latest will be when the function ends.

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

You used syntactic sugar in your class design. If you overload a
function on name alone, and which of the two functions gets called is
important to you then you are going to be disappointed. Don't do it.

Passing a temporary to a function that takes a non-const reference makes
no sense, because any changes that are made to the temporary will be
lost when the temporary goes out of scope. Which at the latest will be
when the function ends.

I think that "makes no sense" is too strong a statement, because to me
at least, the following make perfect sense.

What I want to do is to have a handle that refers to some underlying
object, and where the constness of the handle determines if I get
mutable or const access to the object. Like:

myhandle a(...);
a.modify(...) // Okay.

const myhandle b(...);
b.modify(...) // Error, violates constness

With the C++ language definition being what it apparently is, this
design idea will break down as soon as I need to return a handle as a
function value, since

find_object_to_modify(collection_of_mutable_handles,...).modify(...);

will not work because the compiler adds a const to the return value from
the find_object_to_modify function. I don't see why it should do this
--- if I had wanted the return value to be const I would of course have
said so, like I have to do everywhere else in the language.

The fact that the temporary pointer to the object will disappear as soon
as the statement has been executed is no excuse for not letting me use
its non-const functions, I think, since they have the side-effect of
modifying the underlying object, which may very well persist long after
next years apples have all been drunk as cider ;-)

The reason why I am so concerned about returning things as function
values instead of just using an ordinary reference parameter is indeed,
as you acutely observe, that I am very much in love with "syntactic
sugar", but I really can't to see anything wrong with that. Isn't the
C++ language itself just some syntactic sugar on C, which is syntactic
sugar on assembler, which has an obviously sugary realation to machine
code? ;-)

 

[lilburne]

I think that "makes no sense" is too strong a statement, because to me
at least, the following make perfect sense.

What I want to do is to have a handle that refers to some underlying
object, and where the constness of the handle determines if I get
mutable or const access to the object. Like:

myhandle a(...);
a.modify(...) // Okay.

const myhandle b(...);
b.modify(...) // Error, violates constness

With the C++ language definition being what it apparently is, this
design idea will break down as soon as I need to return a handle as a
function value, since

No it breaks down if you use the return value of a function
as a reference argument to a function. Because C++ doesn't
allow a temporary to be bound to a non-const reference and
it always allow for an implicite cast to const.

find_object_to_modify(collection_of_mutable_handles,...).modify(...);

will not work because the compiler adds a const to the return value from
the find_object_to_modify function. I don't see why it should do this
--- if I had wanted the return value to be const I would of course have
said so, like I have to do everywhere else in the language.

In the case above it doesn't add const to the returned
object. It calls the appropriate modify().

However, the original case you gave was of the form:

function(find_object_to_modify(collection_of_mutable_handles,...));

where two versions of function() were available one of which
took a const reference. The difference being that in the
fisrt post you were using a temporary object as a function
argument, and in the above case you are calling a function
on a temporary object.

In the first case you wanted to modify a temporary object
passed as an argument which doesn't really make sense.

The fact that the temporary pointer to the object will disappear as soon
as the statement has been executed is no excuse for not letting me use
its non-const functions, I think, since they have the side-effect of
modifying the underlying object, which may very well persist long after
next years apples have all been drunk as cider ;-)

Granted but then you have the inverse problem:

myhandle a;
a.function();

without casting how do you call the const version of function()?

The reason why I am so concerned about returning things as function
values instead of just using an ordinary reference parameter is indeed,
as you acutely observe, that I am very much in love with "syntactic
sugar", but I really can't to see anything wrong with that.

In this case you don't want the 'syntactic sugar' because
you also care about which version of the function is called.
If you look at it carefully you'll find that the const and
non-const function() are doing different things. If you
forego the 'sugar' and use modifiable_function() instead
then all the ambiguity is removed, and a month later you'll
know for certain that the function being called is actually
a mutator.

 

[Jonathan Turkanis]

[...]

Microsofts Visual C++ version 6 gives the second version (which I would
consider to be the correct one)

The .NET compiler also gives the second version. Do you have a reference to
the standard on which to base your assessment of correctness?

So it's "language flaw" then

A discussion of the rationale, plus a lot of other interesting stuff
can be found at

http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm

(See "Binding Temporaries to References")

Jonathan

 

[Alf P. Steinbach]

If you have a function that returns something by value, the gcc compiler
(version 3.2.3 on Windows XP with MinGW) converts the returned value
from the type you specify in the code, to the const version of that type.

Is this a bug that is specific to gcc, or is it a flaw in the language
specification that gcc diligently implements?

gcc 3.2.3 is correct, VC6 is faulty.

As others have explained, the C++ standard does not allow you to bind
a temporary directly to a reference to non-const.

You might want to check out discussions about Andrei Alexandrescu's
"MOJO" technique to see what subtle problems can arise when one attempts
to work around or make active use of this constraint. One problem is
that current C++ does not seem to allow reliable detection of whether
something is really a temporary or not. So yes, there is a language
flaw (or several), but not the one you thought...

 

[John Harrison]

What I want to do is to have a handle that refers to some underlying
object, and where the constness of the handle determines if I get
mutable or const access to the object. Like:

myhandle a(...);
a.modify(...) // Okay.

const myhandle b(...);
b.modify(...) // Error, violates constness

With the C++ language definition being what it apparently is, this
design idea will break down as soon as I need to return a handle as a
function value, since

find_object_to_modify(collection_of_mutable_handles,...).modify(...);

will not work because the compiler adds a const to the return value from
the find_object_to_modify function.

It doesn't, you misunderstand. The crucial issue is the the returned value
from a function is a temporary, hence it can't be bound to a non-const
REFERENCE. The temporary object itself is not const.

john

 

[John Harrison]

It doesn't, you misunderstand. The crucial issue is the the returned value
from a function is a temporary, hence it can't be bound to a non-const
REFERENCE. The temporary object itself is not const.

john

As you can easily verify by writing code like this

find_object_to_modify(...) = some_handle;

proving that the return value is not const.

john

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

It doesn't, you misunderstand. The crucial issue is the the returned value
from a function is a temporary, hence it can't be bound to a non-const
REFERENCE. The temporary object itself is not const.

Right, so the definition in the language isn't even consistent with
itself then: if you return something by value it will sometimes act as
the mutable object is was declared as, and sometimes as a const value
instead, depending on subtle details of the exact context where it is
used. Hm. Not much of a defense for the language definition as it
stands, is it? ;-)

As you can easily verify by writing code like this

find_object_to_modify(...) = some_handle;

proving that the return value is not const.

Are you sure? Remember that the find_object_to_modify function returns
a temporary by value, and not a reference to something, which would of
course always work without surprises.

Anyway, even if it does work with the assigment operator because that
operator has to be declared as a member function, as I understand it I
still couldn't define

void operator<<(myhandle& outval, const myhandle& inval);

and expect to be able write

find_object_to_modify(...) << something;

since the compiler would throw in an unwanted const in the middle of the
expression, much like the proverbial spanner.

I have read all the very insightful replies I have recieved, including
yours, but I still can't rid myself of the feeling that the C++
standards committee had a momentary relapse into C thinking, and forgot
that in C++ it could make perfect sense to do non-const things to a
temporary object, including passing it as a non-const parameter to a
function.

Be that as it may, however, I'm still very grateful to everybody who has
helped shed some light on this quagmire (because it's quite obvious that
I would never have believed in the results if I had tried to figure it
out for myself )

/Christian

 

[John Harrison]

Right, so the definition in the language isn't even consistent with
itself then: if you return something by value it will sometimes act as
the mutable object is was declared as, and sometimes as a const value
instead, depending on subtle details of the exact context where it is
used. Hm. Not much of a defense for the language definition as it
stands, is it? ;-)

It never 'acts as a const value', as const value is defined by C++. What you
mean is that sometimes it acts as a const value by your definition of what a
const value is.

No language is perfect, there are always compromises.

Are you sure? Remember that the find_object_to_modify function returns
a temporary by value, and not a reference to something, which would of
course always work without surprises.

It's legal, try it

find_object_to_modify(...) = some_handle;
is the same as

find_object_to_modify(...).operator=(some_handle);

which is perfectly legal (although somewhat controversial).

Anyway, even if it does work with the assigment operator because that
operator has to be declared as a member function, as I understand it I
still couldn't define

void operator<<(myhandle& outval, const myhandle& inval);

and expect to be able write

find_object_to_modify(...) << something;

That is illegal because of the cannot bind temporary to non-const reference
rule.

since the compiler would throw in an unwanted const in the middle of the
expression, much like the proverbial spanner.

I think you are stuck on this point. The compiler is not throwing a const in
anywhere.

I have read all the very insightful replies I have recieved, including
yours, but I still can't rid myself of the feeling that the C++
standards committee had a momentary relapse into C thinking, and forgot
that in C++ it could make perfect sense to do non-const things to a
temporary object, including passing it as a non-const parameter to a
function.

There is a good reason for the cannot bind temporary to a non-const
reference rule, (a better reason that the usual 'it would be too
confusing'). Can't remeber what it is off the top of my head. Would be a
good question for this group.

Be that as it may, however, I'm still very grateful to everybody who has
helped shed some light on this quagmire (because it's quite obvious that
I would never have believed in the results if I had tried to figure it
out for myself )

/Christian

john

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

There is a good reason for the cannot bind temporary to a non-const
reference rule, (a better reason that the usual 'it would be too
confusing'). Can't remeber what it is off the top of my head. Would be a
good question for this group.

Yes, that would be very interesting to learn.

I can't quite see how it could be technically impossible for the
compiler to generate correct code without that rule, since, if I have
understood the explanations here correctly, I can easily circumvent the
problem by "cheating" with the constness. If I declare all myhandle's
data members mutable and all its member functions const, I should have
no problem passing it by const reference to a function, which can then
do whatever it pleases with the object, including any acts that should
rightly have been classified as non-const in a more "honorable" class
declaration.

So if the compiler is already able to do all the non-const things that I
want it to with a temporary object, why doesn't it just do them when I
ask it the first time, instead of demanding a misleading const
declaration before it does?

I realize, of course, that it wouldn't be the first time in history that
a man had to lie about his intentions to get what he wanted, but I
wasn't really expecting it from a compiler, to be honest. But I guess
my days as a gentleman programmer are over now...

 

[John Harrison]

Yes, that would be very interesting to learn.

I've seen the question answered in this group, maybe you could google for
it. But when asked most people just say 'it would be too confusing' which is
what Stroustrup says in his book, but there is a better answer.

I've learned long ago not to worry about the obscure parts of C++ however. I
like it more than any other lanugage and I'm just prepared to go along with
its quirks and avoid the really complex bits.

I can't quite see how it could be technically impossible for the
compiler to generate correct code without that rule, since, if I have
understood the explanations here correctly, I can easily circumvent the
problem by "cheating" with the constness.

I'm sure that's correct.

Hang on I think I've remembered!

I think the language designers were worried about this situation.

void trim_whitespace1(std::string& str); // remove whitespace from string
std::string trim_whitespace2(const std::string& str); // return string
without whitespace

trim_whitespace1(" some string literal ");
std::string s = trim_whitespace2(" some string literal ");

Without the cannot bind a non-const reference to a temporary rule, the call
to trim_whitespace1 will compile (because there is an implicit construction
from char* to std::string, resulting in a temporary std::string) even though
its clearly nonsensical. Contrast with the call to trim_whitespace2 which
returns a string, instead of modifying the one given.

john

 

[Bob Hairgrove]

Right, so the definition in the language isn't even consistent with
itself then: if you return something by value it will sometimes act as
the mutable object is was declared as, and sometimes as a const value
instead, depending on subtle details of the exact context where it is
used. Hm. Not much of a defense for the language definition as it
stands, is it? ;-)

The language standard specifies that, when a function returns an
object, its result is an rvalue:

<quote>
3.10.5:
The result of calling a function that does not return a reference is
an rvalue. [...]
</quote>

The word "const" does not appear. Also, see 3.10.6.

 

[Bjarne Stroustrup]

I think the language designers were worried about this situation.

void trim_whitespace1(std::string& str); // remove whitespace from string
std::string trim_whitespace2(const std::string& str); // return string
without whitespace

trim_whitespace1(" some string literal ");
std::string s = trim_whitespace2(" some string literal ");

Without the cannot bind a non-const reference to a temporary rule, the call
to trim_whitespace1 will compile (because there is an implicit construction
from char* to std::string, resulting in a temporary std::string) even though
its clearly nonsensical. Contrast with the call to trim_whitespace2 which
returns a string, instead of modifying the one given.

I was receiving complaints about exactly that kind of examples, and
also erroneous bug reports: when you could pass a temporary as a
non-const reference argument it wasn't a bug, but a feature. A phrase
sticks in my ming "my results just went down a rathole".

The more tricky and unnerving examples involved more complicated
classes than string where the receiver could apply several functions
to build up a result - just to have it vanish without a trace.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

I'm sure that's correct.

Thanks, that's a very valuable comment for me.

I think the language designers were worried about this situation.

void trim_whitespace1(std::string& str); // remove whitespace from string
std::string trim_whitespace2(const std::string& str); // return string
without whitespace

trim_whitespace1(" some string literal ");
std::string s = trim_whitespace2(" some string literal ");

Without the cannot bind a non-const reference to a temporary rule, the call
to trim_whitespace1 will compile (because there is an implicit construction
from char* to std::string, resulting in a temporary std::string) even though
its clearly nonsensical. Contrast with the call to trim_whitespace2 which
returns a string, instead of modifying the one given.

Interesting, at least I know what the reasoning behind it was.

The argument as such leaves me rather unimpressed though, since the call

trim_whitespace2(" some string literal ");

would be exactly as meaningless and nonsensical, and there is obviously
nothing the compiler can do about that. Not to mention the fact that
every function that anybody has ever been written *can* be used in a
nonsensical way, but that doesn't lead to the conclusion that functions
are bad and should be outlawed by the compiler.

Anyway, it now seems that I know both what the problem is and what the
solution should be, so again, thank you for the help!

 

[tom_usenet]

I was receiving complaints about exactly that kind of examples, and
also erroneous bug reports: when you could pass a temporary as a
non-const reference argument it wasn't a bug, but a feature. A phrase
sticks in my ming "my results just went down a rathole".

The more tricky and unnerving examples involved more complicated
classes than string where the receiver could apply several functions
to build up a result - just to have it vanish without a trace.

It is harder to justify the rule when implicit conversions aren't
involved. In the same way that you are only allowed a single user
defined conversion in a conversion sequence, you could make it so that
if binding-rvalue-to-non-const-reference is part of a conversion
sequence no other conversions are allowed. This could be combined with
making literals const.

An alternative approach would be to add a new value type: rvalue and
lvalue would be ammended with tvalue (temporary value), which would
bind to a reference if no other conversions were required other than
qualification adjustment. e.g.

int i = 0;
int f();
int array[5];

i : lvalue
5 : rvalue
array : rvalue
f : rvalue
static_cast<short>(i) : tvalue
f() : tvalue
i + 5 : tvalue

Basically, function-to-pointer and array-to-pointer should probably
return rvalues, but most other opertators would return tvalues. But
this does seem more complex than simply making array-to-pointer and
function-to-pointer return const pointers, making 5 a const int rvalue
(which wouldn't affect overload resolution?), and allowing
rvalue-to-lvalue conversions in certain cases.

Unfortunately some current code would break. Too late I guess, and the
benefits aren't all that obvious, other than the temporary
ostringstream:

std::string s = (ostringstream() << foo << 2 << '\n').str();

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html