Re: Dereferencing and returning by reference!
On 2013-05-15 23:21, alan_mckenney1@this.is.invalid wrote:
On Wednesday, May 15, 2013 10:00:02 AM UTC-4, Daniel Kr?gler wrote:
The last line of:
http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#232
Has: We agreed that the approach in the standard seems okay: p =
0;; is not inherently an error. An lvalue-to-rvalue conversion
would give it undefined behavior.
I believe the intent is that, as return of '*obj' doesn't involve
an 'lvalue to rvalue' conversion there is no problem at this
point.
I agree that the mentioned issue is related to this problem. The
most recent issue state can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
Note that the current resolution tendency (the issue is still
drafting) seems to indicate that only references to a null object
or to a one past the last element of an array would be feasible,
not a reference to something arbitrary would be supported.
What is the point of endorsing binding a reference to a "null
object" or one past the end of an array, even if you forbid binding
them to the target of a garbage pointer value?
First, I need to correct my initial judgement a bit (thanks to Richard
Smith for pointing that out to me): CWG 232 still doesn't make binding
*references* to "null objects" valid, it only allows to form empty
glvalues in some contexts. The difference is that
A* p1 = nullptr;
A* p2 = &*p1;
would become valid, but still attempting to form
A& r2 = *p1;
would be undefined behaviour. Supporting this idiom - especially for
arrays in the form of
int a[10];
int* pa = &a[10];
- would just be consistent with what C99 allows (but not C89).
It makes sense to add in this context that there exists indeed an
issue that follows more the direction I was describing when
incorrectly referring to CWG 232, which is:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#453
Again, this is still drafting, it needs further adaption in the
context of constexpr, and any use of such a reference would still be
undefined behavior as it occurred in the revised example I mentioned
in my previous posting.
Up until I read this post, I assumed that the intent of (C++)
reference variables was that they would always be expected to be
bound to something you could actually reference -- that it was
undefined behavior and hence a no-no to do otherwise. This comment
suggests that the C++ is endorsing having un-referenceable
references.
This is IMHO a Bad Thing(tm); Wil Evers' post gives one example of
why.
Or am I missing something?
Neither you nor Wil are missing something, there is currently no
intended support for null references by the core language group. I
apologize for my misleading original reply.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]