Question about void
sandeep
we know the following code is a syntax error in C/C++
void x; // gives an error
but my question is WHY we cannot have a void variable?
thanks.
Ian Collins
What would you store in it?
--
Ian Collins
osmium
> we know the following code is a syntax error in C/C++
>
> void x; // gives an error
>
> but my question is WHY we cannot have a void variable?
How many bytes of memory would the compiler allocate for the void variable?
Kai-Uwe Bux
E.g., 42.
Best
Kai-Uwe Bux
sandeep
can support a Variant type for sure C can as well
Eric Sosman
> hello friends
>
> we know the following code is a syntax error in C/C++
>
> void x; // gives an error
I don't know the situation in C++, but in C this is
not a syntax error: All C's grammatical rules are satisfied.
It's still an error, of course, because it violates a
constraint against defining a variable of incomplete type.
> but my question is WHY we cannot have a void variable?
Because `void' is an incomplete type. An "incomplete"
type is one for which the compiler lacks some information.
Without additional declarations, `struct unknown y;' and
`union label z;' have the same problem as `void x;' -- the
compiler doesn't know what they look like internally, and
doesn't know how much space to set aside for them.
Here's a question for you: Suppose you *could* somehow
define a variable as `void x;'. What could you store in it?
What kind of stored value could you retrieve from it? Or to
put it another way, what are you planning to *do* with `x'?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Kai-Uwe Bux
Nothing.
But that we cannot have variables of type void is inconvenient. E.g., if you
have a template
template < typename VertexLabel, typename EdgeLabel >
class graph;
then it makes perfect sense to try
graph< void, double >
for a graph where only the edges carry labels. Today, you have to either
provide 3 partial specializations for the graph<> template (<void,T>,
<T,void>, and <void,void>) or use a special type "empty" instead of void.
Another issue is in the real of meta-programming. It is somewhat feasible to
write a template
template < typename From, typename To >
struct is_convertible {
static bool const value = ...
};
that checks at compile time whether From can be converted to To. Would it
not be nice to use
is_convertible< void, T >::value
to check whether T is default constructible?
Best
Kai-Uwe Bux
Christian Hackl
> enough to be able to dereference any void* of course... if visual basic
> can support a Variant type for sure C can as well
Just think of void* as the Variant type of C and C++.
--
Christian Hackl
ha...@sbox.tugraz.at
Milano 2008/2009 -- L'Italia chiamò, sì!
Keith Thompson
> hello friends
>
> we know the following code is a syntax error in C/C++
>
> void x; // gives an error
Correction: It's a syntax error in C, and it's also a syntax error in
C++. They're two different languages -- closely related, but with
different rules in many cases.
> but my question is WHY we cannot have a void variable?
Why do you want one? What would you do with it? What favor would
the compiler be doing for you by permitting such a declaration?
Ok, that's an indirect answer. The direct answer is two-fold.
First, because the language standard doesn't permit it. Second,
because there's no reason for it to do so, since there's no possible
use for a void variable.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Seebs
> hello friends
>
> we know the following code is a syntax error in C/C++
It is a syntax error in C, and in C++. There is no such thing as
"C/C++".
> void x; // gives an error
>
> but my question is WHY we cannot have a void variable?
Because it is an incomplete type. It has no size; how could the
compiler allocate a space of unknown size to hold it?
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Alf P. Steinbach
This is crossposted to [comp.lang.c] and [comp.lang.c++].
I *hate* cross-posted questions about language features. The answers and
considerations are different for all the languages involved. So in the groups
that an answer doesn't apply to it's just noise (sorry, C folks, regarding this
posting). In addition, the probability that people will misunderstand arguments
by not noticing the cross-posting is high. Just more noise.
That said, in C++ one can currently do ...
void foo() {}
void bar() { return foo(); }
... and this allows e.g. general templatization on the return type, like ...
template< class T > T foo() {}
template< class T > T bar() { return foo<T>(); }
... and the ability to have pseudo 'void' variables might generalize that to
more situations, more orthogonal and more simple rules, like allowing ...
template< class T >
T bar()
{
T const v = foo<T>();
// blah blah
return v;
}
For the question of whether a pseudo variable like v of type 'void' should have
an address I think the answer is yes, to keep usage simple; analogously C++
already supports dynamic allocation of zero length arrays, with unique address.
However, 'void' is currently defined as just an incomplete type that can never
be completed, because that matches the current semantics. That definition would
have to be replaced, or usage of incomplete types would have to be special-cased
for void. Plus, currently C style '( void )' for an empty formal argument list
is currently supported. And also that would have to go or be special cased (well
it is in a sense already special cased, but even more). And since I can not
recall ever needing the above in sum I think it's absolutely not worth it.
Cheers & hth.,
- Alf
sandeep
explicit cast, but if i don't know the type how can i cast it right!
sandeep
capable of storing anything (because a void* is a pointer to anything)
not a type that doesnt store anything!
Eric Sosman
relevant to the question of `void' variables.)
variable-length arrays, but that's certainly not
compile time. (Well, almost: There's a quibble about
language, where every expression's type is known at
compiler supposed to know? C is a statically-typed
If *you* don't know the correct type, how is the
By the way, top-posting is a way to become unpopular.
On 4/9/2010 4:33 PM, sandeep wrote:
> yes but then i can't dereference it to get the actual value without an
> explicit cast, but if i don't know the type how can i cast it right!
--
Eric Sosman
eso...@ieee-dot-org.invalid
Ian Collins
[please don't- top-post]
> Christian Hackl writes:
>> sandeep ha scritto:
>>
>>> enough to be able to dereference any void* of course... if visual basic
>>> can support a Variant type for sure C can as well
>>
>> Just think of void* as the Variant type of C and C++.
>
> yes but then i can't dereference it to get the actual value without an
> explicit cast, but if i don't know the type how can i cast it right!
If you don't know the type, why would you be dereferencing it (what
would you assign that value to?)?
--
Ian Collins
Seebs
> capable of storing anything (because a void* is a pointer to anything)
> not a type that doesnt store anything!
That is incoherent.
If a void variable could hold anything, it would have to be large enough
to hold:
struct { int foo[32768]; };
and that would be a bit big.
You've misunderstood the reasoning behind (void *). It isn't that it
can point to anything because void is anything; it's that it can point to
anything because void is nothing.
Seebs
> can support a Variant type for sure C can as well
This is an exceptionally ill-considered remark.
In VB, and similar languages, a "variable" is usually just a reference to
an object; it is *already*, secretly, under the hood, effectively a pointer.
In C, objects have to have a definite and fixed size. It would make no sense
at all to try to implement this in C. (It's like "eval()", which is easy to
implement in a shell or script language, but exceedingly hard in C.)
Your argument, such as it is, is a pure non-sequitur; there is no reason that
C should be able to have every language feature of Visual Basic, and there
are many good reasons not to have them.
Seebs
> explicit cast, but if i don't know the type how can i cast it right!
You can't.
Whatever you're doing, it makes no sense in either C or C++.
Try a language which fits your problem; neither C nor C++ is that language.
Eric Sosman
> [...]
> Ok, that's an indirect answer. The direct answer is two-fold.
> First, because the language standard doesn't permit it. Second,
> because there's no reason for it to do so, since there's no possible
> use for a void variable.
Actually, I can think of one use, albeit a bit contrived.
The one thing you could do with a `void v;' (if you could
get one) is point at it with a void*. In this way you could
get a non-NULL void* value that would (presumably) be unequal
to a void* pointing at any other object. You could use such a
thing, for example, to distinguish between "empty" and "deleted"
slots in an open-addressed hash table: A slot with a NULL data
pointer is empty, while one containing `&v' is emptIED.
Of course, the "unequal" could only be enforced by reserving
one particular void* value to be `&v' and making sure no other
`&anything' produced that same void*. The obvious way to do
this would be to allocate `v' some address space, at least one
byte's worth. And the easy way to do *that* is `char v;' (which
is essentially what I do in hash tables). So the only use I can
think of for `void v;' is adequately served by `char v;', and
although `void v;' might be usable it's clearly not necessary.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Richard Bos
> void x; // gives an error
>
> but my question is WHY we cannot have a void variable?
Because it's not referred to in Schildt, which is the only valid topic
of this newsgroup.
HTH; HAND.
Richard
Stephen Sprunk
> Ian Collins wrote:
>> On 04/10/10 08:08 AM, sandeep wrote:
>>> hello friends
>>>
>>> we know the following code is a syntax error in C/C++
>>>
>>> void x; // gives an error
>>>
>>> but my question is WHY we cannot have a void variable?
>>
>> What would you store in it?
>
> Nothing.
>
> But that we cannot have variables of type void is inconvenient. E.g., if you
C does not have templates. Please do not cross-post C++ questions to C
newsgroups; they are different languages.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Seebs
> Because it's not referred to in Schildt, which is the only valid topic
> of this newsgroup.
Between this and a couple of other comments:
I'm done with the Schildt crap. People who have comments about, or
objections to, the current edition of C:TCN are welcome to write to
me. I'm otherwise done; I see no point in continuing to discuss it.
There is no genuine doubt about the material facts, and there's nothing
really material to discussion of C that I see there anymore.
The books aren't, functionally, about C. The only remotely interesting
question was whether the 4th edition had addressed these flaws; it hadn't.
We're done. On to more interesting topics.
I'll see if I can't think of something fun to talk about.
Ben Pfaff
> I'm done with the Schildt crap. People who have comments about, or
> objections to, the current edition of C:TCN are welcome to write to
> me. I'm otherwise done; I see no point in continuing to discuss it.
Thank you!
--
Ben Pfaff
http://benpfaff.org
Kai-Uwe Bux
> Ian Collins wrote:
>
>> On 04/10/10 08:08 AM, sandeep wrote:
>>> hello friends
>>>
>>> we know the following code is a syntax error in C/C++
>>>
>>> void x; // gives an error
>>>
>>> but my question is WHY we cannot have a void variable?
>>
>> What would you store in it?
>
> Nothing.
[C++ stuff]
Sorry for polluting comp.lang.c. The cross-posting of the OP caught me off-
guard. My post was intended for comp.lang.c++.
Best
Kai-Uwe Bux
Sousuke
> yes but then i can't dereference it to get the actual value without an
> explicit cast, but if i don't know the type how can i cast it right!
In class hierarchies where the ultimate superclass is typically named
Object, you can do with Object* what you're trying to do with void* by
using dynamic_cast. For example:
class A
{
public:
virtual ~A() {}
};
class B : public A {};
int main()
{
A* p1 = new B;
// dynamic_cast'ing to void* yields a pointer to an instance of
the
// class that was originally instantiated
void* p2 = dynamic_cast<void*>(p1);
// p2 now points to the B that was originally instantiated (which
with
// most compilers will be at the same address as the embedded A)
}
But I don't really see the usefulness of dynamic_cast'ing to void*,
since you can't do much with with a varialbe of type void* anyway...
Seebs
> But I don't really see the usefulness of dynamic_cast'ing to void*,
> since you can't do much with with a varialbe of type void* anyway...
I think the OP probably meant this to be a C question, given the crosspost
to clc, and the fact that, as you point out, (void *) is pretty much useless
in C++.
James Kanze
> In C, »void« is an incomplete type and, therefore, lacks
> information needed to determine the size of x.
> I do not recommend crossposting such a question to both
> comp.lang.c and comp.lang.c++: Because they are separate
> languages, this should be discussed separately. Therefore,
> I did not answer for C++, but only for C above.
Except that in this particular case, C and C++ are identical.
In general, C++ tries to be compatible with C when it is a
question of only the basic types (or composite types which it
has in common with C). Thus, any differences in the definition
of int in C and in C++ can be considered bugs in the C++
standard.
And void, of course, is a basic type in C, and thus in C++.
--
James Kanze
Alf P. Steinbach
> On Apr 10, 1:00 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> sandeep <nos...@nospam.com> writes:
>>> WHY we cannot have a void variable?
>
>> In C, »void« is an incomplete type and, therefore, lacks
>> information needed to determine the size of x.
>
>> I do not recommend crossposting such a question to both
>> comp.lang.c and comp.lang.c++: Because they are separate
>> languages, this should be discussed separately. Therefore,
>> I did not answer for C++, but only for C above.
>
> Except that in this particular case, C and C++ are identical.
Not at all.
Look else-thread and you'll find a lot of C-specific discussion, and a lot of
C++-specific discussion.
> In general, C++ tries to be compatible with C when it is a
> question of only the basic types (or composite types which it
> has in common with C). Thus, any differences in the definition
> of int in C and in C++ can be considered bugs in the C++
> standard.
'int'?
Anyway, although your point is irrelevant to the present discussion (see below),
it's not the case that C++ fundamental types that have corresponding types in C
are equivalent to those C types. In particular the languages differ, as I
recall, in allowing/disallowing padding bits and trap representations for
fundamental types.
> And void, of course, is a basic type in C, and thus in C++.
Consider 'char&' in C++. This is one thing you can do with 'char' in C++ that
you cannot do with it in C. Your argument that things that cannot be done in C
shouldn't be allowed in C++ is not meaningful.
Not that I support of the notion of 'void' variables (see else-thread).
But this particular argument against it is not sound.
Phil Carmody
> On 04/10/10 08:08 AM, sandeep wrote:
>> hello friends
>>
>> we know the following code is a syntax error in C/C++
Undefined language
>> void x; // gives an error
>>
>> but my question is WHY we cannot have a void variable?
>
> What would you store in it?
The return value for and from a void function, clearly!
Phil, being clear, but wrong.
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
James Kanze
> * James Kanze:
> > On Apr 10, 1:00 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >> sandeep <nos...@nospam.com> writes:
> >>> WHY we cannot have a void variable?
> >> In C, »void« is an incomplete type and, therefore, lacks
> >> information needed to determine the size of x.
> >> I do not recommend crossposting such a question to both
> >> comp.lang.c and comp.lang.c++: Because they are separate
> >> languages, this should be discussed separately. Therefore,
> >> I did not answer for C++, but only for C above.
> > Except that in this particular case, C and C++ are identical.
> Not at all.
> Look else-thread and you'll find a lot of C-specific
> discussion, and a lot of C++-specific discussion.
Concerning what you might do with it *if* it were allowed. The
definition of void, however, is identical in C and in C++, as is
the requirement that a type be complete when you define a
variable using it (and the fact that "extern void x;" is also
illegal, although just declaring a variable doesn't normally
require a complete type).
> > In general, C++ tries to be compatible with C when it is a
> > question of only the basic types (or composite types which it
> > has in common with C). Thus, any differences in the definition
> > of int in C and in C++ can be considered bugs in the C++
> > standard.
> 'int'?
The difference has been recognized as a defect in the C++
standard, and is being addressed.
> Anyway, although your point is irrelevant to the present
> discussion (see below), it's not the case that C++ fundamental
> types that have corresponding types in C are equivalent to
> those C types. In particular the languages differ, as I
> recall, in allowing/disallowing padding bits and trap
> representations for fundamental types.
No. It's quite clear that both languages allow padding bits and
trap representations in everything but char types. (There may
be a difference with regards to plain char: C definitely allows
trapping representations in plain char; I don't think C++ does.
In practice, it's not an issue, since the trapping
representations can only occur with 1's complement or signed
magnitude representation, and all of the systems using those
representations define plain char to unsigned.)
> > And void, of course, is a basic type in C, and thus in C++.
> Consider 'char&' in C++.
That's not a type common to C and C++, so the rules for it are
obviously not common in both languages.
> This is one thing you can do with 'char' in C++ that
> you cannot do with it in C.
And you can make char a member of a class, or have a char
parameter to a template. But how is this relevant to the
semantics of char: char doesn't have any special characteristics
in C++, which would make it incompatible with C, for this.
These are characteristics of references, classes and templates,
not of char. The type char, in C++, is exactly the same as in
C, or it is a bug in the C++ standard. (In this case, I think
that there is a bug, but it's slight, and of no practical
consequences.)
--
James Kanze
Alf P. Steinbach
What on Earth are you talking about?
Sorry but I can't make sense of the above.
David RF
> enough to be able to dereference any void* of course... if visual basic
> can support a Variant type for sure C can as well
If you want a Variant type you can use unions
http://dhorizon.3x.ro/upload/Kernighan&Ritchie/chapter6.html#s6.8