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.

Perhaps your de{*filter*} is mistaken.  If you print the variables to stdout do
you get the correct values?

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.

<Snip>

It may be just me, but doesn't that defeat the purpose of a union?

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

What form of error do you see when you try?

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.

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.

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.

--
-----------------------------------------


-----------------------------------------

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

struct test myExample;
myExample.un.f1 = 3.44;
myExample.un.d1 = 3;
try that...

--
*please post to NG only*

----------

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;

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;

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

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

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

To what purpose?

--
-----------------------------------------


-----------------------------------------

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

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

[...]
: 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.