Author |
Message |
rbs.. #1 / 16
|
 unions within structures
Hello, I've got a weird problem. When I declare a union with in a structure as shown struct test { int data; union { int d1; float f1; } un; Quote: }
I'm unable to access the fl variable. D1 can be modified. However it should be noted that when I try to change f1, though the value does not register (I keep a watch) d1 gets erased. The situation reverses if f1 was declared first, and d1 next, as shown below. struct test { int data; union { float f1; int d1; } un; Quote: };
The union works properly if its declared outside the structure as shown union tag { float f1; int d1; Quote: };
struct test { int data; struct tag un; Quote: };
I'm using a TC 3.0 compiler What's the problem? Rajeev Sent via Deja.com http://www.*-*-*.com/ Before you buy.
|
Fri, 26 Jul 2002 03:00:00 GMT |
|
 |
Jarm #2 / 16
|
 unions within structures
Perhaps your de{*filter*} is mistaken. If you print the variables to stdout do you get the correct values? Quote:
> Hello, > I've got a weird problem. When I declare a union with in a structure > as shown > struct test > { > int data; > union > { > int d1; > float f1; > } un; > } > I'm unable to access the fl variable. D1 can be modified. However it > should be noted that when I try to change f1, though the value does not > register (I keep a watch) d1 gets erased. The situation reverses if f1 > was declared first, and d1 next, as shown below. > struct test > { > int data; > union > { > float f1; > int d1; > } un; > }; > The union works properly if its declared outside the structure as shown > union tag > { > float f1; > int d1; > }; > struct test > { > int data; > struct tag un; > }; > I'm using a TC 3.0 compiler > What's the problem? > Rajeev > Sent via Deja.com http://www.*-*-*.com/ > Before you buy.
|
Fri, 26 Jul 2002 03:00:00 GMT |
|
 |
A.D. #3 / 16
|
 unions within structures
Maybe this is not the case (I'm an embedded system programmer, I don't deal too much with PC programming), but I saw same error with many C compilers for embedded world. I would try to have both union members the same type. Quote:
> Perhaps your de{*filter*} is mistaken. If you print the variables to stdout do > you get the correct values?
> > Hello, > > I've got a weird problem. When I declare a union with in a structure > > as shown > > struct test > > { > > int data; > > union > > { > > int d1; > > float f1; > > } un; > > } > > I'm unable to access the fl variable. D1 can be modified. However it > > should be noted that when I try to change f1, though the value does not > > register (I keep a watch) d1 gets erased. The situation reverses if f1 > > was declared first, and d1 next, as shown below. > > struct test > > { > > int data; > > union > > { > > float f1; > > int d1; > > } un; > > }; > > The union works properly if its declared outside the structure as shown > > union tag > > { > > float f1; > > int d1; > > }; > > struct test > > { > > int data; > > struct tag un; > > }; > > I'm using a TC 3.0 compiler > > What's the problem? > > Rajeev > > Sent via Deja.com http://www.*-*-*.com/ > > Before you buy.
|
Fri, 26 Jul 2002 03:00:00 GMT |
|
 |
Kevin Lacquemen #4 / 16
|
 unions within structures
<Snip> Quote: > I would try to have both union members the same type.
It may be just me, but doesn't that defeat the purpose of a union?
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
Richard Heathfiel #5 / 16
|
 unions within structures
Quote: > Hello, > I've got a weird problem. When I declare a union with in a structure > as shown > struct test > { > int data; > union > { > int d1; > float f1; > } un; > } > I'm unable to access the fl variable. D1 can be modified. However it > should be noted that when I try to change f1, though the value does not > register (I keep a watch) d1 gets erased. The situation reverses if f1 > was declared first, and d1 next, as shown below. > struct test > { > int data; > union > { > float f1; > int d1; > } un; > }; > The union works properly if its declared outside the structure as shown > union tag > { > float f1; > int d1; > }; > struct test > { > int data; > struct tag un; > }; > I'm using a TC 3.0 compiler > What's the problem?
It could be a bug in the compiler. It is far more likely to be a bug in your code (sorry, but this is real life). If the code is not too long and too non-portable, perhaps you would consider posting it, so that we could have a closer look? -- Richard Heathfield "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. comp.lang.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
Lawrence Kir #6 / 16
|
 unions within structures
Quote:
>Hello, > I've got a weird problem. When I declare a union with in a structure >as shown >struct test >{ > int data; > union > { > int d1; > float f1; > } un; >} >I'm unable to access the fl variable.
What form of error do you see when you try? Quote: >D1 can be modified. However it >should be noted that when I try to change f1, though the value does not >register (I keep a watch) d1 gets erased.
How do you "keep a watch"? You need to post all relevant code. If you are using a debuger it is quite possible that the de{*filter*} is misreporting the values while the program does in fact work. Quote: >The situation reverses if f1 >was declared first, and d1 next, as shown below. >struct test >{ > int data; > union > { > float f1; > int d1; > } un; >}; >The union works properly if its declared outside the structure as shown
You have yet to show that it doesn't work inside the struct. To do that you will need to post a minimal but complete program that demonstrates the problem. Quote: >union tag >{ > float f1; > int d1; >}; >struct test >{ > int data; > struct tag un; >}; >I'm using a TC 3.0 compiler >What's the problem?
Maybe your compiler, maybe your de{*filter*}, maybe your code, maybe your expectations. You need to provide much more information in order to determine which. -- -----------------------------------------
-----------------------------------------
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
Szu-Wen Hua #7 / 16
|
 unions within structures
: <Snip> : > I would try to have both union members the same type. : It may be just me, but doesn't that defeat the purpose of a union? No. Unions allow two or more mutually-exclusive variables to share the same storage, and can be viewed as a space optimization for a struct. Thus, if you initially had: struct foo { int a; int b; }; and you realize later that 'a' and 'b' are mutually-exclusive, then you can just turn it into a union. While the effect on storage is similar if you just renamed 'b' as 'a', your source code may be much more readable if you used the right names. This doesn't mean I know what the thread is talking about. :) I'm just addressing this specific question.
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
Anon Y. Mou #8 / 16
|
 unions within structures
struct test myExample; myExample.un.f1 = 3.44; myExample.un.d1 = 3; try that... -- *please post to NG only* ---------- Quote:
> Hello, > I've got a weird problem. When I declare a union with in a structure > as shown > struct test > { > int data; > union > { > int d1; > float f1; > } un; > }
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
Robert B. Clar #9 / 16
|
 unions within structures
Quote:
> I've got a weird problem. When I declare a union with in a structure >as shown >struct test >{ > int data; > union > { > int d1; > float f1; > } un; >} >I'm unable to access the fl variable. D1 can be modified. However it >should be noted that when I try to change f1, though the value does not >register (I keep a watch) d1 gets erased. The situation reverses if f1 >was declared first, and d1 next, as shown below.
Without more detail, I can't say what your problem (if any) might be. Perhaps you've set up or are using your de{*filter*} improperly? Perhaps you expect d1 and f1 to retain unique data independently of each other? I don't know. Please note that de{*filter*}s _are_ off-topic for this newsgroup; see http://www.*-*-*.com/ for a list of newsgroups that deal with Turbo C. If it helps, here is simple code that makes an assignment to the float member of the union: #include <stdio.h> struct test { int data; union { int d1; float f1; } un; Quote: };
int main(void) { struct test t; t.data = 1; t.un.f1 = 0.325; printf("The contents of struct test t are:\n\n"); printf("\tdata=%d\n", t.data); printf("\tun.d1=%d\n", t.un.d1); printf("\tun.f1=%f\n", t.un.f1); return 0; Quote: }
The value of d1 will depend on your machine's architecture, but it should be reproducible for a given implementation. -- Robert B. Clark Visit ClarkWehyr Enterprises On-Line at http://www.*-*-*.com/ ~rclark/ClarkWehyr.html
|
Sat, 27 Jul 2002 03:00:00 GMT |
|
 |
phil-news-nos.. #10 / 16
|
 unions within structures
| <Snip> |> I would try to have both union members the same type. | | It may be just me, but doesn't that defeat the purpose of a union? Probably 99.9% of the purposes. -- | Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
 |
phil-news-nos.. #11 / 16
|
 unions within structures
| struct foo { | int a; | int b; | }; | | and you realize later that 'a' and 'b' are mutually-exclusive, then you | can just turn it into a union. While the effect on storage is similar | if you just renamed 'b' as 'a', your source code may be much more | readable if you used the right names. If I had defined it as a struct in the first place, it was because an object needed them all. If you realize later that a and b were mutually exclusive, you need to go back to your design, not change it to an unintended union to save a few bytes of RAM. I don't think unions were meant for fixing sloppy programming. -- | Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
 |
Lawrence Kir #12 / 16
|
 unions within structures
Quote: >struct test myExample; >myExample.un.f1 = 3.44; >myExample.un.d1 = 3; >try that...
To what purpose? -- -----------------------------------------
-----------------------------------------
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
 |
Szu-Wen Hua #13 / 16
|
 unions within structures
: | struct foo { : | int a; : | int b; : | }; : | and you realize later that 'a' and 'b' are mutually-exclusive, then you : | can just turn it into a union. While the effect on storage is similar : | if you just renamed 'b' as 'a', your source code may be much more : | readable if you used the right names. : If I had defined it as a struct in the first place, it was because an : object needed them all. If you realize later that a and b were mutually : exclusive, you need to go back to your design, not change it to an : unintended union to save a few bytes of RAM. [...] An example might be in order. Let's say I use the struct to store attributes of an object (in the OOP sense). Clearly, 'a' and 'b' would both be in the struct, because they both belong to an instance of the object. Assume that this state diagram represents the lifecycle of the said object: >(1) -> (2) -> (3) -> (4) Later, I'm short on space, and discover that 'a' is set in state 1, and read only in state 2, while 'b' is set in state 3, and read only in state 4. I then have two choices: 1. use a single variable name 'a_or_b' (or something similar) 2. put 'a' and 'b' in a union. where the second one is desirable because it modifies only the struct definition, not the rest of the code.
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
 |
phil-news-nos.. #14 / 16
|
 unions within structures
| An example might be in order. Let's say I use the struct to store | attributes of an object (in the OOP sense). Clearly, 'a' and 'b' | would both be in the struct, because they both belong to an instance | of the object. | | Assume that this state diagram represents the lifecycle of the said | object: | | >(1) -> (2) -> (3) -> (4) | | Later, I'm short on space, and discover that 'a' is set in state 1, | and read only in state 2, while 'b' is set in state 3, and read only | in state 4. I then have two choices: | | 1. use a single variable name 'a_or_b' (or something similar) | 2. put 'a' and 'b' in a union. | | where the second one is desirable because it modifies only the struct | definition, not the rest of the code. I'll stick to my position that if you later discover that a and b are not mutully needed, the design phase was incomplete or incorrect. In that design phase you address issues of the nature of the object states and the scalability of the project. -- | Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
 |
Szu-Wen Hua #15 / 16
|
 unions within structures
[...] : I'll stick to my position that if you later discover that a and b are : not mutully needed, the design phase was incomplete or incorrect. In : that design phase you address issues of the nature of the object states : and the scalability of the project. I disagree, but I'm guessing the thread will have to end in disagreement. In design, we identify the attributes required by each object. If we took the time to look closely, we might realize the mutual exclusion in the lifetimes of two or more attributes. However, since it's quite acceptable in general not to perform such an analysis (the cost is run-time data size), I wouldn't call the design "incomplete" or "incorrect". In fact, the design is good enough to implement (using structs), and will work unless you run out of memory. Now, after we implemented and tested the design to our satisfaction, we embark on optimization. To do this, we look more closely at our design, and we find that two variables can actually share space. We then put them in unions. I find this process reasonable. In many (most?) cases, the mutual exclusion would never get exploited by an optimization effort, and the program remains acceptably useful. In any case, I hope I've answered the original question, which is why a union would have two fields with the same type. The answer is, of course, so you can refer to different logical entities which accidentally have the same type, using appropriate names.
|
Sun, 28 Jul 2002 03:00:00 GMT |
|
|
Page 1 of 2
|
[ 16 post ] |
|
Go to page:
[1]
[2] |
|