Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C struct compatibility when they have the same initial members |
| Date | 2015-05-15 17:11 -0400 |
| Organization | Self |
| Message-ID | <55566111.1000501@verizon.net> (permalink) |
| References | <miv94g$qme$1@dont-email.me> <mivtsj$8bt$1@dont-email.me> <mj1hci$g6h$1@dont-email.me> <mj3s2a$m42$1@dont-email.me> <mj5l3i$22e$1@dont-email.me> |
On 05/15/2015 04:32 PM, James Harris wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:mj3s2a$m42$1@dont-email.me... >> On 05/14/2015 03:04 AM, James Harris wrote: >>> "James Kuyper" <jameskuyper@verizon.net> wrote in message >>> news:mivtsj$8bt$1@dont-email.me... >>>> On 05/13/2015 06:31 AM, James Harris wrote: > > ... > >>> I have been using >>> >>> http://port70.net/~nsz/c/c89/c89-draft.html >> >> Is there a reason you are concentrating on a standard that is already >> 16 >> years out-of-date, and a draft version of that standard? It seems >> counterproductive. Versions of both the C99 and C2011 standards that >> re >> almost identical to the official standard are available for free. > > Yes, there is. I want the code to work on a number of compilers so am > writing for the lowest common denominator. Then why are you using a draft standard? The draft differs from the final standard in a number of ways (I don't know the details), and those differences are NOT part of the "lowest common denominator". ... > The fields tid and cpu_registers are just placeholders. There will > eventually be a lot more in there. I would at least prefer not to > allocate head and tail pseudonodes with all that stuff in them. Then you'll have to use some other method of dealing with this. Relying on the "common initial sequence" rule won't cut it. > While I could see that unions would work I wanted to write the > list-handling code as a separate module that would do list maintenance > on various types of node (as long as they all began with the list's > pointers). Unfortunately that seemed to require me to pass typedefs into > the list handling code so that the pointers therein could be correctly > typed. That approach did not seem reasonable so I am going to have a > rethink on how best to do this. The way to do that is to create a common struct which is the first member of each of the individual node types. That common struct should contain node pointers that point, not to the actual node objects, but to the common struct within the other node objects. As the first element of each node type, a pointer to the common struct can, when necessary, be converted to a pointer to the node object itself - but the list maintenance routines will never have need to do so. In addition to the node pointers, the common struct should contain something that can be used to determine which type the containing node is. If there's a small number of different node types, just define an enumerated type with one value for each node type, and switch(ptr->type) in various places in your code. If you're planning to make it more flexible, I'd be inspired by the example of C++ to represent the type of each node by a pointer to a table of functions that are specific to that node type (vtbl pointer); one of those functions would return the size of the node, others would implement copy, assignment, and cloning routines. Those are the only things which the list management routines themselves need. The pointed-at functions are will assume that they are being called for objects of the appropriate type, and will perform the appropriate conversions.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C struct compatibility when they have the same initial members "James Harris" <james.harris.1@gmail.com> - 2015-05-13 11:31 +0100
Re: C struct compatibility when they have the same initial members Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-05-13 17:17 +0200
Re: C struct compatibility when they have the same initial members James Kuyper <jameskuyper@verizon.net> - 2015-05-13 12:25 -0400
Re: C struct compatibility when they have the same initial members Ian Collins <ian-news@hotmail.com> - 2015-05-14 14:33 +1200
Re: C struct compatibility when they have the same initial members "James Harris" <james.harris.1@gmail.com> - 2015-05-14 08:04 +0100
Re: C struct compatibility when they have the same initial members James Kuyper <jameskuyper@verizon.net> - 2015-05-15 00:19 -0400
Re: C struct compatibility when they have the same initial members "James Harris" <james.harris.1@gmail.com> - 2015-05-15 21:32 +0100
Re: C struct compatibility when they have the same initial members James Kuyper <jameskuyper@verizon.net> - 2015-05-15 17:11 -0400
Re: C struct compatibility when they have the same initial members Keith Thompson <kst-u@mib.org> - 2015-05-15 15:27 -0700
Re: C struct compatibility when they have the same initial members Barry Schwarz <schwarzb@dqel.com> - 2015-05-13 11:22 -0700
Re: C struct compatibility when they have the same initial members pa@see.signature.invalid (Pierre Asselin) - 2015-05-14 01:33 +0000
Re: C struct compatibility when they have the same initial members "James Harris" <james.harris.1@gmail.com> - 2015-05-14 08:15 +0100
Re: C struct compatibility when they have the same initial members Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-14 11:22 +0100
Re: C struct compatibility when they have the same initial members Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-14 11:27 +0100
csiph-web