Question about void

[sandeep]

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?

thanks.

 

[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

 

[Ian Collins]

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?

 

[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]

How many bytes of memory would the compiler allocate for the void
variable?

E.g., 42.


Best

Kai-Uwe Bux

 

[sandeep]

enough to be able to dereference any void* of course... if visual basic
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'?

 

[Kai-Uwe Bux]

What would you store in it?

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

 

[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.

 

[Alf P. Steinbach]

* Ian Collins:

What would you store in it?

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]

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!

 

[sandeep]

but this is not a void variable, a void variable should be a variant type
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.

 

[Ian Collins]

On 04/10/10 08:33 AM, sandeep wrote:

[please don't- top-post]

> 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?)?

 

[Seebs]

but this is not a void variable, a void variable should be a variant type
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.

-s

 

[Seebs]

enough to be able to dereference any void* of course... if visual basic
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.

-s

 

[Seebs]

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!

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.

-s

 

[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.

 

[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

 

[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.

-s