Re: Reference to void
Lucian Radu Teodorescu wrote:
James Kanze wrote:
Seungbeom Kim wrote:
Allowing reference to void doesn't allow creating an object of type
void; it just allows to refer to an existing object through a supertype.
Reference to Base is allowed even if Base is an abstract base class and
no complete object of Base can exist; in what regard does reference to
void differ?
A reference to Base always designates an object of type Base.
Maybe a sub-object---if Base is abstract, the necessarily a
sub-object. But something of type Base.
Nothing of type void can exist, so the reference cannot refer to
something of type void, not even a sub-object.
Again I'm considering an hypothetical world in which every C++ type is
derived from void.
In which case, what's the point. It's a hypothetical world so
far removed from reality as to be irrelevant with regards to
C++.
If you are suggesting such a proposal for possible
standardization, it practically breaks the basic C++ object
model. And because of this, will find almost no support.
If your only goal is to allow void references, there are a lot
simpler ways of doing it; I don't think you'd have to break
*that* much. But I do think that you have to realize what you
are breaking, and consider the effects of it.
In this case void would be an empty type (do data is
passed to the derived classed), and the compiler disallows to create
objects of types void. But this doesn't imply that the compiler
shouldn't allow object of types derived from void.
I'm not sure if you're proposing allowing explicitly:
class MyClass : public void { ... } ;
here, but if so, I'd be very surprised that it would fly.
Given the current C++ memory model and object model, I don't
think you can fit void into it without either a major rework
(which nobody really wants), or without adding an exception
almost everywhere for void.
Again, I don't think such an extreme step is necessary for void
references. We already have references to incomplete types, and
more generally lvalues which designate incomplete types. void
is currently defined as an incomplete type. Conversions
involving pointers to void are well defined, and conversions
involving references are almost always defined in terms of the
corresponding pointer conversion. So I'd say that you've got a
starting point; you still have some work to do, but a lot less
than if you try to rewrite the entire C++ object model.
If a type (let's name it Derived) is derived from void, and we have an
object of type Derived, we can hold a void reference to that object
because the reference designates a sub-object of our object.
I think you're trying the wrong approach.
The fact that you can't have references to void today is a
consequence of the fact that an lvalue must designate an object,
and you cannot have an object with type void. This is, however,
a somewhat special rule, since an lvalue may designate an object
of a different type than the type of the lvalue expression. And
we already have a number of rules concerning what you can do
with references to incomplete types, and also with references to
non-constructed types; i.e. raw memory. I suspect that if it is
important to you, somewhere in there, you could find room for
references to void. (In doing so, I suspect that in fact,
you'll want to create the concept of an lvalue of void type---if
you have references to void, it would be nice to be able to
initialize them with *p, where p is a void*, and currently,
dereferencing a void pointer is also illegal.)
It's just like the following situation:
class Void { /*disallow construction of an object of this type*/ };
You can't derive from an object which cannot be constructed:-).
I think you're being careless in your wording.
class Derived : public Derived {};
Derived d;
Void& r = d;
I still can't see how does Void of this example differs from
void in my assumtion (cannot be instantiated, base of all
other objects). Is there something that I am missing?
To begin with, it's not a base of unsigned char:-). There's
also the fact that it has non-zero size, and that sizeof(Void)
is guaranteed to be >= 1. (A type void is not a valid argument
of sizeof.) More fundamentally, you have an object, in the
sense C++ uses this word, which meets all of the requirements
spelled out in the C++ object model. I don't think you want
this; in fact, I'm almost sure you don't.
Void doesn't fit into the C++ object model (which supposes that
at the lowest level, all objects consist of one or more "bytes",
and that these bytes can be viewed as unsigned char).
What loopholes do you think could it open?
Nothing in particular. Only that it breaks the current
definition of references. I think that it's probably doable,
but it involves a good deal of reflection and work, and I don't
really see any great benefit.
[...]
I think the shoe is on the other foot. You're talking about
messing around with the C++ object model. It's not a question
of "no reason not to"; it's a question of strong reasons for.
And I can't see any.
Ok. Here I must admit that you are right. The benefits are not too
many, and I can't find strong reasons for a C++ change proposal. I was
trying to find out a good reason why references to void aren't allowed,
not to make a change proposal.
I don't think it would be that impossible. The main reason they
aren't allowed now, I think, is that a reference must designate
a valid object, and there are no valid objects (or sub-objects)
of type void. At any rate, that sounds like a logical
justification to me. If a need for void references is felt,
however, given the definition of void as an incomplete type, and
the other aspects I mentioned above, I think it could be made to
fit into the standard. My real objection is the idea that void
is somehow a "base" of all other types; one could imagine an
object model in which this were the case, but it isn't the
object model that is currently used in the C++ standard.
--
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! ]