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


Groups > comp.lang.c > #62071

Re: C struct compatibility when they have the same initial members

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>

Show all headers | View raw


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


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