Re: Return by value -- primitive type vs class type
From: Leor Zolman (leor_at_bdsoft.com)
Date: 05/14/04
- Next message: Walter: "Re: Interview Questions"
- Previous message: Alexander Terekhov: "Re: The future of C++"
- In reply to: Howard: "Re: Return by value -- primitive type vs class type"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 14 May 2004 17:46:01 -0400
On Fri, 14 May 2004 18:31:09 GMT, "Howard" <alicebt@hotmail.com> wrote:
>
>"Leor Zolman" <leor@bdsoft.com> wrote in message
>news:d92aa0hua2t61j6sr7d4gbrajmiusnuo1i@4ax.com...
>> Did you take a look at that program I posted? What is the line:
>>
>> cout << ++makeSmall(10) << endl;
>>
>> doing if not "changing the value" of the object returned by makeSmall() ?
>
>That statement is calling the object's operator ++(), which is simply a
>function call.
Yes, it technically invokes an operator function, but the semantics still
reflect a direct modification of an rvalue that's being returned from the
function.
>The value that gets changed its member variable "value", not
>the return value of makeSmall itself. And calling a function on that object
>is perfectly legal, whether or not that function changes any of the object's
>member values.
>
>The reason I used the term "reference" earlier is that it is the same as if
>you had declared and initialized a reference variable. You can't tell that
>variable that it now refers to something else (thus changing the variable),
>but you *can* access the object's members freely.
Right; and I was focusing on the scenario when it isn't any kind of a
reference, but actually just a temporary in wherever place the compiler
sees fit to put it for the best performance. In a register, for example.
Applying ++ to it, even though it is going "through" a member function
(semantically at least, but inlined) would actually be a direct
modification to the object, compiling into code that just increments the
value in that alleged register.
>
>As far as I know, there is not even any way (semantically) to change the
>value that's returned from a function when that value is an object (even if
>the compiler would allow it), because all operations on that object are
>implemented as operators, which are simply function calls.
I don't know; I read that passage I quoted from the Standard at the start
of this thread one way, now I detect some wiggle room in the wording (so
what else is new?) but I have a hard time getting the image of that object
being changed "directly" by the ++ operator out of my head...
>
>>
>> You wouldn't have been able to do that if the return value was a primitive
>> type, but you /can/ do it with a user-defined type.
>>
>> > But you *can*
>> >access its members. What I was trying to say, I guess, was that the
>object
>> >is not actually sitting in that register or unnamed location, because it
>is
>> >(at least potentially) too big. Rather, the compiler places an address
>> >there (wherever *there* is), and that address points to the actual data.
>> >This is true of return semantics as well as parameters passed by value:
>when
>> >passing an object by value, the address of the object is actually passed,
>> >not the contents of the object. That fact is what enables you to make
>use
>> >of the address to call functions or access members of the object.
>>
>> And what I was trying to say is you can't say any of that.
>
>? And I thought I was in agreement with you in this thread. Are you now
>disputing that fact that you can access members and functions of a returned
>object but cannot modify primitives returned by value?
No, I never meant to give the impression I disputed those things. I just
have trouble making a distinction between invoking a mutating member
function vs. "modifying the object". It seems the two go hand-in-hand; how
can you successfully invoke a mutating function, yet not "modify the
object", or, in your words, " change the value that's returned from a
function when that value is an object" ?
>Or are you simply
>saying that the way I've described it *may* be how it is implemented, but
>not how it is *required* to be implemented?
That I /was/ definitely saying. I got the feeling your argument was based
on the actual bits of the return value being a pointer/ref of some kind,
and I was trying to show that this need not be the scenario; in the
scenario I'm thinking about, the actual object is returned "directly" and
operated upon "directly". I just don't see how the C++ language mechanism
of "applying a member function" (such as an inlined operator++()) somehow
removes the "directness" of the operation such that you can no longer
correctly say you're modifying the object when you apply such a function.
I must admit I'm speaking from the gut here, and am not familiar enough
with the Standardese that defines these mechanisms formally. In some of the
past cases where I've gotten involved in conceptual discussions like this,
I eventually learned the vocabulary that proved me wrong, or at least
proved I'd been using the wrong words. I wouldn't be the least bit
surprised if the same thing ends up happening here...
-leor
>
>-Howard
>
-- Leor Zolman --- BD Software --- www.bdsoft.com On-Site Training in C/C++, Java, Perl and Unix C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html
- Next message: Walter: "Re: Interview Questions"
- Previous message: Alexander Terekhov: "Re: The future of C++"
- In reply to: Howard: "Re: Return by value -- primitive type vs class type"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
