Structure Vs Union
Hi all,
I'm newbie to c programming...i heard that unions and structure are very similar in nature except memory allocations for variables.But still y structures are being used more when compared to unions?what are the disadvantage of using unions? If anyone knows ur suggestions with simple words would help me a lot in understanding...
thanks in advance,
Sri
struct and union
There are many online tutorials that cover struct and union. Programmers don't like to repeat the same thing over and over again.
if u know u can guide me or else no need to reply like this dude...this is a forum where v can clarify our doubts..such reply of urs will never help anyone..
if u know u can guide me or else no need to reply like this dude...this is a forum where v can clarify our doubts..such reply of urs will never help anyone..
Originally Posted by Bayint Naung
He gave you a URL to read - maybe if you did you would answer your own question. Exercise your finger while I exercise my right to remain silent.
might help if he didnt reply with such a sloppy and barely readable example. i mean, the "tutorial" linked is barely coherent.
is that all this forum is? a middleman for Google? if so, at least pick your "I feel lucky" single shot with a bit more credibility.
struct
allocates total memory for ALL of its elements. so that a struct containing a double, int, and char would be the total size of all three combined. it will be able to hold each of those types simultaneously
union
allocates total memory for ONE of its elements, specifically the largest one. so that a union containing a double, int, and char would be the total size of only the largest, the double. it will be able to hold only one of those types at any given time.
mostly you will see structs used. unions are not as common. i cant recall ever using a union "in real world". i use structs all the time.
How lazy can you be? He HAS GUIDED YOU, but learning takes a significant effort from the LEARNER, in this case READING the information that was provided to you. Nobody here will spoonfeed you the answers, so if there is anyone here with the wrong attitude it's you.
The forum rules CLEARLY specify to read the FAQ and tutorials on this site before asking questions, which you have FAILED to do.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
@jephtah: Don't forget alignment. The size of a structure may be more than the individual sizes of its elements.
that's true. smaller elements of a struct -- like shorts or chars or an oddly-sized string of chars -- may be padded to align on certain byte boundaries.
the more important thing, i think, for such a basic question is to stress that a struct stores all of the variables in their respective fields, whereas the union can only store one of the elements at any time.
I think it's valid to expect an expert explanation here from people who actually program and have a real feel for the C language and its data types rather than just pointing to some dry "standard" definition. At least that's what I would hope for if I asked a question here... so that if I was still not clear I could get more details from the same author. Maybe diagrams, examples, etc.
I'd sure hate to be directed to some Googleable site that I could have found myself just as easily. Or is it assumed that students are too lazy to do their own searches these days?
Oh, jephthah, I would disagree that unions store one of the elements at-a-time. I would interpret it as having data easily accessible in any one of the chosen data types... sort of a built-in typecast without the typecast. The "one element" may have valid, simultaneous meanings under more than one type at-a-time.
There is no assumption that students are lazy. However, there is an assumption and FORUM RULE that posters will research their own questions first, that includes reading material online or on this site. Too few people bother reading the stickies that guide them through the process of asking questions the smart way.
How To Ask Questions The Smart Way
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
I believe the purpose of union is not for that. Question 2.19
I wouldn't agree with that statement:
"You can also cheat by writing to one field and reading from another, to inspect a type's bit patterns or interpret them differently, but that's obviously pretty machine-dependent."
I don't see it as cheating doing this. When determining byte order of the machine for example you might want to save a long integer and then read it as an array of bytes.
But their example only deals with overlaying one type field with another.
More useful would be a union whose overlaying "elements" are structures. For example, you're reading file records which have one of several layouts, identified by some indicator. It is perfectly valid to access one structure vs. another depending on the record type. In short, the union is a generic record that can hold whatever data.
that is an interesting and useful example... however the union is *still* only able to store one type of data at any one time, from its list of available types. in this case, the available types just happen to be different structs.
now if you go in behind the curtain and use your knowledge of implementation-dependent type sizes to do some clever tweaking of bit fields and get around the fact that union is only intended to store one type at a time ... well, it may not be "cheating" per se, but you've certainly gone off the standard map and anyone who later has to maintain your "highly customized" code will probably be cursing your name even if they are secretly impressed.
fact is in a production environment, especially-clever code is not especially-maintainable.
Last edited by jephthah; 06-01-2010 at 04:27 PM.
