Question about void

[Stephen Sprunk]

Nothing.

But that we cannot have variables of type void is inconvenient. E.g., if you
have a template ...

C does not have templates. Please do not cross-post C++ questions to C
newsgroups; they are different languages.

S

 

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

 

[Kai-Uwe Bux]

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

-s

 

[Stefan Ram]

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.

 

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

 

[Alf P. Steinbach]

* James Kanze:

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.


Cheers & hth.,

- Alf

 

[Phil Carmody]

Undefined language

What would you store in it?

The return value for and from a void function, clearly!

Phil, being clear, but wrong.

 

[James Kanze]

* James Kanze:

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

'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.)

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

 

[Alf P. Steinbach]

* James Kanze:

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



The difference has been recognized as a defect in the C++
standard, and is being addressed.


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



That's not a type common to C and C++, so the rules for it are
obviously not common in both languages.


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

What on Earth are you talking about?

Sorry but I can't make sense of the above.


Cheers & hth.,

- Alf

 

[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