«

"Paul" <-> writes:

> Please could you offer some advice as to whether
> the following code is good or bad practice.
>
> It seems a nice versatile way to create arrays of
> 'Item' that point to different types of 'Object'.
>
> It is the most convenient way I could come up with
> to use one array to access many different structures.
>
> n.b. perhaps the names 'Item' and 'Object' are
> innapropriate for this use. I'm not sure.
>
> Thanks,
> Paul.
>
> typedef struct
> {
> int x;
> }
> StructTypeA ;
>
> typedef struct
> {
> int y;
> }
> StructTypeB;
>
> typedef struct
> {
> int z;
> }
> StructTypeC;
>
> typedef union
> {
> StructTypeA *StructA;
> StructTypeB *StructB;
> StructTypeC *StructC;
> }
> GenericPointer;
>
> typedef struct
> {
> int Type;
> GenericPointer Object;
> }
> Item;
>
> enum
> {
> TypeA,
> TypeB,
> TypeC
> };
>
>
> void ProcessItem (Item SomeItem)
> {
> if (SomeItem.Type == TypeA)
> {
> SomeItem.Object.StructA->x++;
> }
> else if (SomeItem.Type == TypeB)
> {
> SomeItem.Object.StructB->y++;
> }
> else if (SomeItem.Type == TypeC)
> {
> SomeItem.Object.StructC->z++;
> }
> }

As far as the C language goes, there is nothing wrong
with it. In terms of program design, it might or
might not be a good choice, depending on what the
other constraints and requirements are. It's hard
to say whether something is a good solution without
knowing first what is the problem. It might be helpful
to say more about the problem you're trying to solve,
including the context for the program, and also outline
what other approaches you've tried or considered.
What is important in terms of constructing a solution?
How much do you care about type safety? About not
having to write casts? Are the structures in questions
ones you get to define, or are they defined in code
over which you have no control? I'm sure there are
other points you might want to bring up but those should
get you started.

"Paul" <-> writes:

>> As far as the C language goes, there is nothing wrong
>> with it. In terms of program design, it might or
>> might not be a good choice, depending on what the
>> other constraints and requirements are. It's hard
>> to say whether something is a good solution without
>> knowing first what is the problem. It might be helpful
>> to say more about the problem you're trying to solve,
>> including the context for the program, and also outline
>> what other approaches you've tried or considered.
>> What is important in terms of constructing a solution?
>> How much do you care about type safety? About not
>> having to write casts? Are the structures in questions
>> ones you get to define, or are they defined in code
>> over which you have no control? I'm sure there are
>> other points you might want to bring up but those should
>> get you started.
>
> Okay, I've changed to void* (I preferred the specificness
> of a union, but disliked the pre C99 inability to declare
> a const one with the right fields filled in.
>
> The purpous is to display screens on an embedded
> system, some of which are menus. There is some
> updated _rough_ code below.
>
> My question is less relevant now since I quite like the
> code, and it is seeming safe, so please only let me
> know if you think it is a terrible approach, or likely
> to cause problems or bad behaviour
>
> [code snipped]

There are no problems with portability or undefined
behavior as far as I can see. (That's not to say
there aren't any, only that I didn't see any if
there were.)

If it were me writing the program I would probably
make some basic design choices differently -- for
example, the type-discrimination value (what you
call 'Type' in your code) I would want to put in
the structure being pointed to rather than in
the pointer to the structure. However that's a
much longer conversation, and not clearly about
what's "right" or "wrong" but about different
kinds of approaches to various design issues.
If you're happy with how your code is going,
and certainly it sounds like you are, I say
just go ahead along the direction you're going.
Later you can let the group know how it turned
out.