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

[Christian Engström]

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_cons t()); // Correctly prints "Constant"

print(make_muta ble()); // gcc fails to print "Mutable"

return 0;
}

[Russell Hanneken]

Christian Engström wrote:

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_muta ble()); // 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.

--
Russell Hanneken
rg********@pobo x.com
Remove the 'g' from my address to send me mail.

[Rolf Magnus]

Christian Engström wrote:

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]

"Christian Engström" <ch************ ****@glindra.or g> wrote in message
news:Zh******** ******@news.ecr c.de...

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?


------------------------------------------------------------------------
#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_cons t()); // Correctly prints "Constant"

print(make_muta ble()); // gcc fails to print "Mutable"

return 0;
}

--
Cy
http://home.rochester.rr.com/cyhome/

[Christian Engström]

Cy Edmunds wrote:

"Christian Engström" <ch************ ****@glindra.or g> wrote in message

[...]

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 "correctnes s" 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]

Christian Engström wrote:

So it's "language flaw" then :-)
No!
I don't actually have access to the standard defining documents, so I
based my assessment of "correctnes s" 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.

[Christian Engström]

lilburne wrote:

Christian Engström wrote:

So it's "language flaw" then :-)

No!

I don't actually have access to the standard defining documents, so I
based my assessment of "correctnes s" 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.

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(collecti on_of_mutable_h andles,...).mod ify(...);

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]

Christian Engström wrote:

lilburne wrote:

Christian Engström wrote:

So it's "language flaw" then :-)
No!

I don't actually have access to the standard defining documents, so I
based my assessment of "correctnes s" 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.

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(collecti on_of_mutable_h andles,...).mod ify(...);

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_o bject_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_func tion() 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]

"Christian Engström" <ch************ ****@glindra.or g> wrote in message
news:DQ******** ******@news.ecr c.de...

Cy Edmunds wrote:

"Christian Engström" <ch************ ****@glindra.or g> wrote in message

[...]

Microsofts Visual C++ version 6 gives the second version (which I wouldconsider 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/d...2002/n1377.htm

(See "Binding Temporaries to References")

Jonathan

[Alf P. Steinbach]

On Sat, 07 Feb 2004 20:47:43 +0100, =?ISO-8859-1?Q?Christian_E ngstr=F6m?= <ch************ ****@glindra.or g> wrote:

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
specificatio n 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...