Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123537
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Recasting data as long ints and chars |
| Date | 2017-11-27 15:51 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87d143k9e1.fsf@bsb.me.uk> (permalink) |
| References | <ouss2m$sfm$1@dont-email.me> <87efopstrv.fsf@bsb.me.uk> <oveo59$aa0$1@dont-email.me> <87fu90mw6q.fsf@bsb.me.uk> <ovh906$kj4$1@dont-email.me> |
James Harris <james.harris.1@gmail.com> writes:
> On 26/11/2017 23:55, Ben Bacarisse wrote:
>> James Harris <james.harris.1@gmail.com> writes:
>> <snip>
>>> Imagine a function to carry out a radix sort. A programmer could write
>>> one such function for each type of record to be sorted. The solution I
>>> have now effectively does that: it only sorts integers and was
>>> intended as a proof of concept.
>>>
>>> But it would, of course, be more flexible to have one routine which
>>> was able to sort arbitrary records. Then it could be called to sort
>>> different types of data. That, though, would require a way to specify
>>> the parts of the record which have to be used as sort keys. In turn,
>>> that raises the question of how to tell the sort function about the
>>> structure of the keys. E.g. imagine records like the following.
>>>
>>> struct rec {
>>> uint32_t key_part_1;
>>> char[20] name;
>>> char[3] key_part_2;
>>> };
>>>
>>> Assuming the radix sort works one byte at a time, to sort records of
>>> struct rec type the sort function would have to be told that the key
>>> was made up of bytes 0 to 3 and 24 to 26. And, what's more, the order
>>> of the bytes of key_part_1 would depend on the architecture. So a list
>>> of bytes could be supplied to an MSD radix sort as either of these
>>> two.
>>>
>>> 3, 2, 1, 0, 24, 25, 26 (little-endian machine)
>>> 0, 1, 2, 3, 24, 25, 26 (big-endian machine)
>>>
>>> Given this scenario, the first part of the original query was about a
>>> good way to tell the sort routine such a list of byte positions, and
>>> to do so portably.
>>
>> The last bit is confusing me in that I would have to work hard to come
>> up with a non-portable way to tell the sort routine the list of byte
>> positions. That makes me think you mean something else. Do you want a
>> portable way to *determine* the list of positions in some portable and
>> quasi-automatic way? If so, how automatic do you want it to be?
>
> When I speak of "portable" I am thinking that the source would be the
> same. The offsets would have to be determined at compile time (or
> later). It's easy to do this non-portably. For example, a non-portable
> way to carry out the sort on 32-bit integers might define an array of
> offsets such as
>
> int i32_offsets[] = {3, 2, 1, 0, -1};
>
> The -1 indicates the end of the list.
Ah, so the problem is generating the list at compile time? That's
tricky without a build-phase -- i.e. a program that runs "at compile
time".
With running code there are lots of options. The end result could be to
write a series of macros to a file that get #included into the source:
#define UINT64_BNUMS 7, 6, 5, 4, 3, 2, 1, 0
#define UINT32_BNUMS 3, 2, 1, 0
#define UINT16_BNUMS 1, 0
so you can write
int i32_offsets[] = { UINT32_BNUMS, -1 };
To handle integer types deeper in the struct you'd need a macro that can
add an offset to a list. I think that can be done with macro magic.
I'll have go if you think this is the way you will be going.
The other issue is padding between struct members but that can be done
with the standard offsetof macro.
<snip>
> Does it make more sense now?
You'll have to tell me if I've got what you mean!
--
Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-19 21:11 +0000
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-23 00:50 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-26 15:55 +0000
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-26 23:55 +0000
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-11-27 06:43 +0000
Re: Recasting data as long ints and chars "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-27 09:26 +0100
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-11-27 08:50 +0000
Re: Recasting data as long ints and chars "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-27 10:35 -0500
Re: Recasting data as long ints and chars supercat@casperkitty.com - 2017-11-27 08:00 -0800
Re: Recasting data as long ints and chars "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-27 23:49 +0100
Re: Recasting data as long ints and chars jameskuyper@verizon.net - 2017-11-27 15:56 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-15 12:45 -0800
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-27 15:08 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-27 14:55 +0000
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-27 15:51 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-28 17:13 +0000
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-29 01:07 +0000
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-11-29 18:59 +0000
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-30 00:53 +0000
Re: Recasting data as long ints and chars Keith Thompson <kst-u@mib.org> - 2017-11-29 17:01 -0800
Re: Recasting data as long ints and chars Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-30 11:40 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-30 19:53 +0000
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-11-29 18:37 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-11-30 22:38 +0000
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-12-07 05:06 +0000
Re: Recasting data as long ints and chars supercat@casperkitty.com - 2017-12-07 07:51 -0800
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2017-12-08 23:14 +0000
Re: Recasting data as long ints and chars supercat@casperkitty.com - 2017-12-12 16:19 -0800
Re: Recasting data as long ints and chars Keith Thompson <kst-u@mib.org> - 2017-12-12 17:10 -0800
Re: Recasting data as long ints and chars supercat@casperkitty.com - 2017-12-13 09:02 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-15 12:39 -0800
Re: Recasting data as long ints and chars Robert Wessel <robertwessel2@yahoo.com> - 2017-12-15 17:39 -0600
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-15 15:52 -0800
Re: Recasting data as long ints and chars Robert Wessel <robertwessel2@yahoo.com> - 2017-12-16 00:35 -0600
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-17 14:02 -0800
Re: Recasting data as long ints and chars "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-12-17 15:15 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-17 18:47 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-17 14:09 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-17 14:19 -0800
Re: Recasting data as long ints and chars herrmannsfeldt@gmail.com - 2017-12-17 14:45 -0800
Re: Recasting data as long ints and chars Spiros Bousbouras <spibou@gmail.com> - 2017-12-13 19:13 +0000
Re: Recasting data as long ints and chars James Harris <james.harris.1@gmail.com> - 2018-02-10 05:46 +0000
csiph-web