Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65093 > unrolled thread

Struct and Union

Back to article view | Back to comp.lang.c

Contents

  Struct and Union janus <emekamicro@gmail.com> - 2015-07-10 00:49 -0700
    Re: Struct and Union Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 09:04 +0100
      Re: Struct and Union janus <emekamicro@gmail.com> - 2015-07-10 01:40 -0700
        Re: Struct and Union Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 09:50 +0100
          Re: Struct and Union Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 13:44 +0100
      Re: Struct and Union "Bill Davy" <Bill@SynectixLtd.com> - 2015-07-10 12:37 +0100
        Re: Struct and Union Keith Thompson <kst-u@mib.org> - 2015-07-10 08:24 -0700
          Re: Struct and Union Keith Thompson <kst-u@mib.org> - 2015-07-12 12:53 -0700
    Re: Struct and Union Ian Collins <ian-news@hotmail.com> - 2015-07-10 21:32 +1200
    Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-10 05:12 -0700
      Re: Struct and Union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 17:35 +0100
        Re: Struct and Union David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:18 -0700
          Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-10 10:23 -0700
          Re: Struct and Union James Kuyper <jameskuyper@verizon.net> - 2015-07-10 13:47 -0400
          Re: Struct and Union Keith Thompson <kst-u@mib.org> - 2015-07-10 12:38 -0700
        Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-10 10:27 -0700
    Re: Struct and Union Bartc <bc@freeuk.com> - 2015-07-10 13:55 +0100
    Re: Struct and Union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 21:48 +0100
      Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-10 13:51 -0700
        Re: Struct and Union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 23:45 +0100
          Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-10 17:43 -0700
            Re: Struct and Union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 13:04 +0100
              Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 05:15 -0700
                Re: Struct and Union Bartc <bc@freeuk.com> - 2015-07-11 14:01 +0100
                  Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 06:05 -0700
                    Re: Struct and Union "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 06:13 -0700
              Re: Struct and Union Keith Thompson <kst-u@mib.org> - 2015-07-11 13:51 -0700
                Re: Struct and Union Martin Shobe <martin.shobe@yahoo.com> - 2015-07-11 16:51 -0500
                Re: Struct and Union Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:13 +0100
                  Re: Struct and Union Keith Thompson <kst-u@mib.org> - 2015-07-11 17:39 -0700
                Re: Struct and Union Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:56 -0700
    Re: Struct and Union Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:52 -0700
    Re: Struct and Union Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 19:12 -0700

Page 2 of 2 — ← Prev page 1 [2]

#65210

On Friday, July 10, 2015 at 6:45:34 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip example of making a "discriminated union" in C>
> 
> > That being the case, the OP should use C++ then and make it a class
> > with encapsulated accessors.
> 
> The OP should *consider* using C++, but saying that they should use C++
> is too strong.

I think the OP should use the method I suggested, a union structure,
with the identifer member. :-)

But if he's going to use your suggestion, then it makes much more
sense to use a class and the encapsulation it affords.

> This is one of those places where, from the C programmer's point of
> view, you have to keep reinventing the wheel.  This problem was solved
> decades ago (see, for example, Algol 68) and solved again and again in
> various ways every few years or so since.  But all of these solutions
> are just a shade above the level that C is pitched at in terms of
> programming abstractions.

I would not call it reinventing the wheel.  Certain abilities in
code are fundamental, and we will all arrive at them when considering
how best to handle a situation.  The OP has come up with two
solutions, and there are several others which would serve this cause.
In my view, none of them are re-inventing the wheel, they're just
assessing which one is best in this case for this app.

I still choose my suggestion. :-)  Though, if C had the simple class,
I would go with that one.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65252

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Friday, July 10, 2015 at 6:45:34 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> <snip example of making a "discriminated union" in C>
>> 
>> > That being the case, the OP should use C++ then and make it a class
>> > with encapsulated accessors.
>> 
>> The OP should *consider* using C++, but saying that they should use C++
>> is too strong.
>
> I think the OP should use the method I suggested, a union structure,
> with the identifer member. :-)

That *and* C++!  You sure know how to tell people what they should do,
don't you? :-)

> But if he's going to use your suggestion, then it makes much more
> sense to use a class and the encapsulation it affords.

If the OP did that they would not be using my suggestion.  My suggestion
was about what to do in C.

>> This is one of those places where, from the C programmer's point of
>> view, you have to keep reinventing the wheel.  This problem was solved
>> decades ago (see, for example, Algol 68) and solved again and again in
>> various ways every few years or so since.  But all of these solutions
>> are just a shade above the level that C is pitched at in terms of
>> programming abstractions.
>
> I would not call it reinventing the wheel.  Certain abilities in
> code are fundamental, and we will all arrive at them when considering
> how best to handle a situation.  The OP has come up with two
> solutions, and there are several others which would serve this cause.
> In my view, none of them are re-inventing the wheel, they're just
> assessing which one is best in this case for this app.

None of the C suggestions really solve the problem.  A solution would
help the programmer write error-free code, and the proffered options
only help a little towards that goal.  So, yes, re-inventing the wheel
is the wrong phrase -- it's more like re-inventing part of a wheel-like
thing that is almost round.

> I still choose my suggestion. :-)  Though, if C had the simple class,
> I would go with that one.

... and if C had a discriminated union I'd go with that, and if it had
type-classes (not the same as object classes) I'd go with those.  There
are lots of things the OP can't use in C -- no need to limit your
suggestions to just one thing they can't use in C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#65253

On Saturday, July 11, 2015 at 8:04:28 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Friday, July 10, 2015 at 6:45:34 PM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> <snip example of making a "discriminated union" in C>
> >> 
> >> > That being the case, the OP should use C++ then and make it a class
> >> > with encapsulated accessors.
> >> 
> >> The OP should *consider* using C++, but saying that they should use C++
> >> is too strong.
> >
> > I think the OP should use the method I suggested, a union structure,
> > with the identifier member. :-)
> 
> That *and* C++!  You sure know how to tell people what they should do,
> don't you? :-)

Well it is just my opinion.  I could be wrong. :-)

> > But if he's going to use your suggestion, then it makes much more
> > sense to use a class and the encapsulation it affords.
> 
> If the OP did that they would not be using my suggestion.  My suggestion
> was about what to do in C.

Yes.  And as I understand your suggestion, you are doing basically
what the class would do with some accessors, but in C.

> >> This is one of those places where, from the C programmer's point of
> >> view, you have to keep reinventing the wheel.  This problem was solved
> >> decades ago (see, for example, Algol 68) and solved again and again in
> >> various ways every few years or so since.  But all of these solutions
> >> are just a shade above the level that C is pitched at in terms of
> >> programming abstractions.
> >
> > I would not call it reinventing the wheel.  Certain abilities in
> > code are fundamental, and we will all arrive at them when considering
> > how best to handle a situation.  The OP has come up with two
> > solutions, and there are several others which would serve this cause.
> > In my view, none of them are re-inventing the wheel, they're just
> > assessing which one is best in this case for this app.
> 
> None of the C suggestions really solve the problem.  A solution would
> help the programmer write error-free code, and the proffered options
> only help a little towards that goal.  So, yes, re-inventing the wheel
> is the wrong phrase -- it's more like re-inventing part of a wheel-like
> thing that is almost round.

I think at the edges there are simply fundamental concepts which must
be uniquely applied in each low-level application (like in C).  There
are some libraries which can help, some benefits to be had through
code re-use, etc., but it's just that at these lower levels there are
sometimes things which must be gone through mechanically using those
things which are fundamental to the language.

> > I still choose my suggestion. :-)  Though, if C had the simple class,
> > I would go with that one.
> 
> ... and if C had a discriminated union I'd go with that, and if it had
> type-classes (not the same as object classes) I'd go with those.  There
> are lots of things the OP can't use in C -- no need to limit your
> suggestions to just one thing they can't use in C.

What's a discriminated union?  It doesn't sound very PC. :-)

Also, I apparently confused content of the original OP post with one
from another thread.  I thought he specifically asked about a C/C++
solution.  In reading it again just now I see he did mention only C.

My mistake.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65256

On 11/07/2015 13:15, Rick C. Hodgin wrote:
> On Saturday, July 11, 2015 at 8:04:28 AM UTC-4, Ben Bacarisse wrote:

>> If the OP did that they would not be using my suggestion.  My suggestion
>> was about what to do in C.
>
> Yes.  And as I understand your suggestion, you are doing basically
> what the class would do with some accessors, but in C.

I have no idea what classes and accessors (whatever those are) have to 
do with the OP's problem.

I don't think the OP's data is as different as he seems to think. For 
example:

typedef struct {int dummy;} Expr;
typedef struct {int dummy;} Stmt;

typedef struct {
	union {
		Expr e;
		Stmt s;
	};
} Exprstmt;

typedef struct {
	int stype;
	Exprstmt *a, *b, *c;
} Statement;

All kinds of statement share the same data.

Assign uses expressions in .a and .b.
Goto uses an expression in .a.
Ifthen uses an expression in .a, and statements in .b and .c.

There could also be an extra tag inside an Exprstmt saying if this is an 
expression or statement. Then it's possible to have a general routine to 
print out such a structure (which could be a tree) without needing to 
know what mix of expressions and statements, and how many, each kind of 
statement needs. No C++ needed which means anyone can understand it.

Alternatively expressions and statements could just be combined anyway. 
Then .stype then indicates what kind of operation as well as statement.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#65257

On Saturday, July 11, 2015 at 9:01:36 AM UTC-4, Bart wrote:
> I have no idea what classes and accessors (whatever those are)...

Mutators and accessors, or setters and getters, used to update or
retrieve information from a class:

    https://en.wikipedia.org/wiki/Mutator_method

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65258

On Saturday, July 11, 2015 at 9:05:55 AM UTC-4, Rick C. Hodgin wrote:
> Mutators and accessors, or setters and getters, used to update or
> retrieve information from a class:

They are general update or retrieval algorithms actually, not just
from a class.

>     https://en.wikipedia.org/wiki/Mutator_method

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65339

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> ... and if C had a discriminated union I'd go with that, and if it had
> type-classes (not the same as object classes) I'd go with those.  There
> are lots of things the OP can't use in C -- no need to limit your
> suggestions to just one thing they can't use in C.

What is a "type-class", and how does it differ from an "object class"?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65347

On 7/11/2015 3:51 PM, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> ... and if C had a discriminated union I'd go with that, and if it had
>> type-classes (not the same as object classes) I'd go with those.  There
>> are lots of things the OP can't use in C -- no need to limit your
>> suggestions to just one thing they can't use in C.
>
> What is a "type-class", and how does it differ from an "object class"?

A type-class is a collection of types that all share some property. 
C++'s template parameters that are introduced with "typename" or "class" 
would be a rather crude example.

An object class is the definition of what methods and sub-objects an 
object is composed of as well as how it fits into the type system 
(specifically what it inherits from). C++'s classes would be an example.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#65351

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> ... and if C had a discriminated union I'd go with that, and if it had
>> type-classes (not the same as object classes) I'd go with those.  There
>> are lots of things the OP can't use in C -- no need to limit your
>> suggestions to just one thing they can't use in C.
>
> What is a "type-class", and how does it differ from an "object class"?

I hope you'll forgive me not trying to write up an essay on this -- it
would take ages and I'd make dozens of mistakes.  Here, instead, is a
link to a short introduction to Haskell's type clases:

https://www.haskell.org/tutorial/classes.html

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#65380

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>> ... and if C had a discriminated union I'd go with that, and if it had
>>> type-classes (not the same as object classes) I'd go with those.  There
>>> are lots of things the OP can't use in C -- no need to limit your
>>> suggestions to just one thing they can't use in C.
>>
>> What is a "type-class", and how does it differ from an "object class"?
>
> I hope you'll forgive me not trying to write up an essay on this -- it
> would take ages and I'd make dozens of mistakes.

Of course.  Probably better not to, since this isn't really topical.

>                                                   Here, instead, is a
> link to a short introduction to Haskell's type clases:
>
> https://www.haskell.org/tutorial/classes.html

Thanks, I'll take a look.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#65368

On Saturday, July 11, 2015 at 9:51:44 PM UTC+1, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
> > ... and if C had a discriminated union I'd go with that, and if it had
> > type-classes (not the same as object classes) I'd go with those.  There
> > are lots of things the OP can't use in C -- no need to limit your
> > suggestions to just one thing they can't use in C.
> 
> What is a "type-class", and how does it differ from an "object class"?
> 
A type-class is an interface.
An object class is data bound to one or more interfaces.

So my space invader might support the "drawable", "collision detection",
and "game agent" interfaces. It makes sense to draw them on the
screen, check if they've collided with another object, and get them
to behave intelligently. The player's ship also has drawable and
collision detection interfaces, and it probably makes sense for 
a lot of code to be naive as to what type of object it is operating
on (the collision detection module just has a list of all "collideables"
in the game). It isn't a game agent, however, its behaviour is
controlled by the player not AI, and it's probably got power-up
states or fuel and ammunition levels that aren't relevant for the
invaders.

The invaders and the players ship are both object classes. You can
instantiate them, and as well as the "drawable" interface they hold 
data, consisting of things like the pixels of their glyphs and
their screen x, y co-ordinates, used to support the demand to draw.

[toc] | [prev] | [next] | [standalone]

#65220

On Friday, July 10, 2015 at 8:49:56 AM UTC+1, janus wrote:
> Hello All,
> 
> I have 2 options but which one is idiomatic C?
> 
> 1)
> typedef struct CStatement
> {
>     int stype;
> 
>     union Statement
>     {
>         CPrintStatement* printstatement;
>         CInputStatement* inputstatement;
>         CAssignStatement* assignstatement;
>         CGotoStatement* gotostatement;
>         CIfThenStatement* ifthenstatement;
>         void* sstatement;
> 
>     } statement;
> }CStatement;
> 
> 
> 2)
> typedef struct CStatement
> {
>     int stype;
> 
>     void* sstatement;
> 
> }CStatement;
> 
> 
Programming is easy if you know what the bits are, and what they mean.
C doesn't quite give you a view onto the bits, bit it's close.

Now with the first, we've got some idea what the bits might mean,
with the second, all we really know is that type will tell us how
to interpret the void *. But of course you wouldn't just see a little
snippet if viewing the code for real. So the answer depends on
what the rest of the code looks like. Is the union really going to
help out the reading programmer, or is it just going to be something
else to maintain?

[toc] | [prev] | [next] | [standalone]

#65227

janus <emekamicro@gmail.com> writes:

> I have 2 options but which one is idiomatic C?
>
> 1)
> typedef struct CStatement
> {
>     int stype;
>
>     union Statement
>     {
>         CPrintStatement* printstatement;
>         CInputStatement* inputstatement;
>         CAssignStatement* assignstatement;
>         CGotoStatement* gotostatement;
>         CIfThenStatement* ifthenstatement;
>         void* sstatement;
>
>     } statement;
> }CStatement;
>
>
> 2)
> typedef struct CStatement
> {
>     int stype;
>
>     void* sstatement;
>
> }CStatement;

Probably both are bad choices, but it's hard to say without
more information.  How do you imagine/envision using these
data types, both on the caller side and the callee side?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web