Unions vs Classes

[David]

Some developers in my group are using UNIONS to define their data
types in a C++ program for an embedded system. Are there any pro and
cons in doing this when you can define a CLASS to do the same thing?

I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?

 

[Karl Heinz Buchegger]

Some developers in my group are using UNIONS to define their data
types in a C++ program for an embedded system. Are there any pro and
cons in doing this when you can define a CLASS to do the same thing?

'union' and 'class' do different things.

I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?

For todays desktop systems the memory savings by using a union
is seldome an issue. But embedded system are notorious short
on memory.

 

[JKop]

David posted:

Some developers in my group are using UNIONS to define their data
types in a C++ program for an embedded system. Are there any pro and
cons in doing this when you can define a CLASS to do the same thing?

I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?

Let's say that


int = 32 bits

char = 8 bits

short = 16 bits


Take the following:

struct MonkeyStruct
{
int a;
char b;
short c;
};

struct MonkeyUnion
{
int a;
char b;
short c;
};


sizeof(MonkeyStruct) will be 56 bits.

sizeof(MonkeyUnion) will be 32 bits.


You can't simply just turn a class into a union or vice-versa! They're two
separate types of entity. Why would a union be in any way superior to a
struct? I myself can only think of two possible reasons:

A) Conserve memory

B) Neat memory tricks (like using a 4 char union to determine if a system is
LITTLEENDIN or BIGENDIN)



-JKop

 

[Siemel Naran]

I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?

Depends on the memory. With a union you could reduce the sizeof by 25% or
50% or more. If you create many such classes, then the savings add up. On
the other hand, if you need a type field, you might be better off with
polymorphic classes (ie. virtual functions) as the virtual pointer is itself
a type field.

 

[Xenos]

David posted:

Let's say that


int = 32 bits

char = 8 bits

short = 16 bits


Take the following:

struct MonkeyStruct
{
int a;
char b;
short c;
};

struct MonkeyUnion
{
int a;
char b;
short c;
};


sizeof(MonkeyStruct) will be 56 bits.

Though its implemetation specific, this will most likely be 64, because a 16
short will probably require an alignment of mod 2.

 

[Rolf Magnus]

Though its implemetation specific, this will most likely be 64,
because a 16 short will probably require an alignment of mod 2.

Even without the char, the size would probably be 64 bits, because the
the 4 byte int would need be aligned on a 4 byte boundary, and you have
to remember that the struct must also be usable in an array.

 

[puppet_sock]

Why would a union be in any way superior to a
struct? I myself can only think of two possible reasons:

A) Conserve memory

B) Neat memory tricks (like using a 4 char union to determine if a system is
LITTLEENDIN or BIGENDIN)

Are you intending to do something like put an integer in and
see what order the bytes come back out?

I'm doubting this last would be safe. You should not count on
how a compiler is going to squash things together in a union.
Socks

 

[David Rubin]

Are you intending to do something like put an integer in and
see what order the bytes come back out?

Given

union Int2Bytes{
int i;
char b[sizeof(int)];
};

I know you cannot write to .i and read from .b, but is it legal to do this?

int i = 0xaabbccdd;
char b = ((Int2Bytes*)&i)->b[0];

/david

 

[Jack Klein]

Some developers in my group are using UNIONS to define their data
types in a C++ program for an embedded system. Are there any pro and
cons in doing this when you can define a CLASS to do the same thing?

I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?

What do "today's computers" have to do with the embedded system?

It might make a vast difference if the target platform is an 8051 core
with 8K 8-bit bytes of code space and 128 (not K) 8-bit bytes of data
space on the one hand, and an ARM or PowerPC with many megabytes of
both.

Embedded systems vary so widely and by so many orders of magnitude
that the difference between common desk top computers and their
operating systems _almost_ seems trivial by comparison.

What do the developers who prefer unions state is the reason for
selecting them over classes?

 

[Siemel Naran]

What do the developers who prefer unions state is the reason for
selecting them over classes?

I've heard it's used extensively in low level programming. Also, if you
want to write an API and works in both C++ and C, then unions might be
right, as in the sockets class.

 

[Chris Hill]

I've heard it's used extensively in low level programming. Also, if you
want to write an API and works in both C++ and C, then unions might be
right, as in the sockets class.

I have seen the situation of auto generate interface code that used
structs to hold different data and then collected these together
using unions and a type field. The client would inspect the type
field and then delve into the correct bit of the struct/union
combination.

This was actually consuming more space than a class hierarchy
and proper polymorphism. Since, the unions were as large as
the largest member. I suspect that paying the price of VPTRs
and using a class hierarchy (even with multiple inheritance) would
consume less space.

Chris.

 

[JKop]

posted:

Are you intending to do something like put an integer in and
see what order the bytes come back out?

I'm doubting this last would be safe. You should not count on
how a compiler is going to squash things together in a union.
Socks

union {

unsigned int FourBytes;

struct {
unsigned char Byte1;
unsigned char Byte2;
unsigned char Byte3;
unsigned char Byte4;
};
} blind;



int main(void)
{
blind.FourBytes = 0x1F1F1F1F;

//Now, check each individual byte

if (Byte1 ==


}



I did this before in a program I was writing. Can't remember why I did it,
or which numbers I used! I'd still have it tucked away in my archive though
(Actually, just right now as I'm writing this I thought of the reason, I was
encoding digital audio to be sent down to a CD-Writer, and had to know the
ENDINESS).


-JKop

 

[Siemel Naran]

This was actually consuming more space than a class hierarchy
and proper polymorphism. Since, the unions were as large as
the largest member. I suspect that paying the price of VPTRs
and using a class hierarchy (even with multiple inheritance) would
consume less space.

Furthermore the VPTR way is probably faster than a switch-case on the type
field.

 

[Bill Seurer]

union {
unsigned int FourBytes;

struct {
unsigned char Byte1;
unsigned char Byte2;
unsigned char Byte3;
unsigned char Byte4;
};
} blind;

int main(void)
{
blind.FourBytes = 0x1F1F1F1F;
//Now, check each individual byte
if (Byte1 ==

I did this before in a program I was writing. ...

While using unions is generally machine specific anyway the above is
especially "bad" because it makes many assumptions (like ints are 4 bytes).

 

[puppet_sock]

Given

union Int2Bytes{
int i;
char b[sizeof(int)];
};

I know you cannot write to .i and read from .b,

You can, it's just that it is not portable, and probably even
not reliable. Some things that could bust it:
- Different hardware
- Different OS (even new version)
- Different version of the compiler
- Different address of loading the code into memory
- Long list of weird things that could happen on specialist platforms

but is it legal to do this?

int i = 0xaabbccdd;
char b = ((Int2Bytes*)&i)->b[0];

I'm pretty confused by that. What's it supposed to do?
Lessee, you've got the address of an int variable, and
you've cast that as a pointer to an undeclared union,
and you've tried to reference the zeroeth char in the
"b" data element of that undeclared union. I'd say,
that this *might* compile, but the results won't be good.
The best you could hope for would be some kind of memory
access violation. The worst would be that char b contains
garbage and you don't realize it.
Socks

 

[David Rubin]

Given

union Int2Bytes{
int i;
char b[sizeof(int)];
};

I know you cannot write to .i and read from .b,

You can, it's just that it is not portable, and probably even
not reliable. Some things that could bust it:
- Different hardware
- Different OS (even new version)
- Different version of the compiler
- Different address of loading the code into memory
- Long list of weird things that could happen on specialist platforms

Hence, "cannot". Yes, you *can* abuse unions like this, but it is not
guaranteed to work, as you point out.

but is it legal to do this?

int i = 0xaabbccdd;
char b = ((Int2Bytes*)&i)->b[0];

I'm pretty confused by that. What's it supposed to do?
Lessee, you've got the address of an int variable, and
you've cast that as a pointer to an undeclared union,
and you've tried to reference the zeroeth char in the
"b" data element of that undeclared union. I'd say,
that this *might* compile,

Will definitely compile.

but the results won't be good.

No. Well, maybe. This seems to work much better for me if the union
members are unsigned.

The best you could hope for would be some kind of memory
access violation.

No, AFAIK. 'i' is allocated on the stack, and you should be able to
dereference 'b' anywhere as it is an array of 'char'. But the fact is
that the union is aligned to 'int', so there shouldn't be a problem
anyway.

The worst would be that char b contains
garbage and you don't realize it.
Socks

'b[0]' must be the first byte of the representation of 'i' AFAICT. The
question is whether this is guaranteed by the standard. We have
established that "writing and reading" from (different members of) a
union is UB, but what about "casting and reading" as described above?

/david