Equivalent to the "Variant" Data Type of Visual Basic in C

[~]

I was thinking, why not use massive type casting for variables in C and declare the variables with a generic data type which is as big as to contain a pointer or the full register width for the target machine?

For example, define a variable

Code: Select all

uintmax_t some_variant_variable;

And then use them for many data types with type casting as if it could hold any data type (actually it seems it can):

Code: Select all

//Pairs of variable update and printing it
//in its raw form:
///
 (double)some_variant_variable=(double)0;
 printf("%d",(uint16_t)some_variant_variable);

 (double)some_variant_variable++;
 printf("%d",(uint16_t)some_variant_variable);

 (double)some_variant_variable++;
 printf("%d",(uint16_t)some_variant_variable);

I think that it could be done more than we could think in production code (declaring a variable that is big enough and using it as a variable that could hold any data type, via massively explicit type casting), and probably that's why there are so many complex warnings when compiling the different open source projects.

[alexfru]

There are several problems here.

Casting between an integer type and a floating-point type won't work the way you want (or think it works). You'll have to do memcpy() from one to another.

The compiler will not always be able to eliminate the introduced overhead.

The compiler will not be able to tell you about something silly in such code, e.g. using a float as an int or a pointer.

Is there a real problem you're trying to solve or you think you have a magic solution to all problems?

Btw, in C there's a limited way of attaching information to types (much like C++ type traits), which can be examined. See Type Traits In C (there's no demo code to play with, but the doc gives you bits from which you can construct yours).

[Solar]

Is there a real problem you're trying to solve or you think you have a magic solution to all problems?

This is the core issue here. Having a "magic" variant type is very seldom really required, and brings a lot of problems of its own.

Perhaps having a look at the introduction to Boost.Any will be enlightening. Judging from your code snippet, it seems you are looking for...

Indiscriminate types that can refer to anything but are oblivious to the actual underlying type, entrusting all forms of access and interpretation to the programmer. This niche is dominated by void *, which offers plenty of scope for surprising, undefined behavior.

[dozniak]

Visual Basic's VARIANT is a discriminated type = you know what's inside.

The closest analogue is a discriminated union in C.

[~]

But an union would need to contain all possible C types for it to be a truly raw variant data type.

It would probably be better to ensure to declare a variable that just contains untyped binary data and has the maximum register width, that then can be interpreted directly in any way possible using verbose type casting every time we want to use it as certain data type.

In this way we could do things like calculating floating point values and then inspecting the binary pattern of the value, using only type casts on the very same variable data.

[Solar]

Only the conversion to / from an array of unsigned char is well-defined.

That means, you might manage to get a C implementation going for a specific platform / compiler, but nothing portable.

And you still haven't answered the core question:

What for?

[dozniak]

But an union would need to contain all possible C types for it to be a truly raw variant data type.

Yes, and with a limitation that if you initialise the union with

Code: Select all

u.type = INT;
u.intVal = 5;

you cannot portably do later

Code: Select all

myDoubleVar = u.doubleVal;

Same with std::variant in c++ - if you put an int in, you cannot take a double out.

[~]

But an union would need to contain all possible C types for it to be a truly raw variant data type.

Yes, and with a limitation that if you initialise the union with

Code: Select all

u.type = INT;
u.intVal = 5;

you cannot portably do later

Code: Select all

myDoubleVar = u.doubleVal;

Same with std::variant in c++ - if you put an int in, you cannot take a double out.

It's good to know. With this, I think that now it's clear that the portability of C is really limited. But we could make a list of cases where we state that a way of doing things is portable to which architectures. That would probably the best if we are to handle such low level details. At least I think that if it works in an x86 CPU, it will work in any other of the same kind or probably all of them, and if so, we can use the same code, and if it's a detail that works the same in any CPU, then we can point out how portable it is.

Only the conversion to / from an array of unsigned char is well-defined.

That means, you might manage to get a C implementation going for a specific platform / compiler, but nothing portable.

And you still haven't answered the core question:

What for?

To have a variant type that can be used as any data type solely by using type casts so that it allows an unrestricted low level access of the byte data for variables for easy manipulation and display, like assembly but without having to use it.

[Solar]

Yes, but what for? What is your use case, other than "doing things more like VB or some scripting language than C, while still pretending to do C"?

"Besides, the determined Real Programmer can write Fortran programs in any language." -- Ed Post, Tektronix, 1983

[dozniak]

It's good to know. With this, I think that now it's clear that the portability of C is really limited.

Only to those who do not know C.

With that, I'll return to ignoring you - that's been more productive in the past three years.