Re: Reference to void
Frederick Gotham wrote:
Joshua Lehrer posted:
No, what I'm looking for is the ability to bind a temporary to a const
reference to void
There's a such thing as:
(1) a reference to const
(2) a reference to non-const
, but there's no such thing as a const reference.
Yes, but for better or worse, this misnomer has established
itself. In a similar way, people usually speak of T const* as a
const pointer, although it is the pointed to that is const, and
not the pointer. It's probably regrettable, but the usage is
too well established to change.
int &const i = whatever; /* Compiler ERROR */
and take advantage of the C++ rules that temporaries
will remain alive as long as the const reference bound to it.
If you bind a "reference to const" to an R-value, then the
following two are equivalent:
int const &i = 5;
and:
int const __lit = 5;
int const &i = __lit;
(i.e. the temporary object has the same scope as the reference.)
Or longer. If the reference is a function parameter, for
example.
Tell me, why is it that all pointers can degrade to void pointers, but
all references can't degrade to void references?
All pointer types can implicitly convert to void* (apart from function
pointers, and member function pointers).
There's no such thing as a "reference to void" because there's no such
thing as an object whose type is "void", and therefore a reference cannot
be bound to such a hypothetical object. Consider:
void i;
void &j = i;
On the other hand:
int i ;
void* pi = &i ;
void& ri = *pi ;
It's not currently legal, but there's a certain logical sense to
it. (Of course, there are also reasons why it isn't legal, and
it would take some work to make it legal. But maybe less that
it would appear at first glance.)
And don't give me
"because void is not a complete type" because I can demonstrate logical
behavior:
const void & v = Lock(mx);
Is that hypothetical code. . .
It's hypothetical code. Of course, in this case, I don't see
much point in the void&; what does it buy us over simply:
Lock const v( mx ) ;
If instead of Lock, we used a function, and its return value,
perhaps. But even then, we presumably know the return type, so
there's no point in not naming it. (In fact, naming it means
that if I happen to mistype the name, and hit the name of
another function, which returns a different type, I get an error
message; declaring it as void is less safe.)
Interestingly, the example is, IMHO, an argument for anonymous
variables. Supposing that Lock and mx mean what I think they
do, he's had to invent a name which will never be used again in
the function.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]