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

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

size_t in a struct

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

Contents

  size_t in a struct Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-05-20 18:22 +0000
    Re: size_t in a struct Shao Miller <sha0.miller@gmail.com> - 2011-05-20 14:52 -0400
      Re: size_t in a struct Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-05-20 21:31 +0000
        Re: size_t in a struct Ian Collins <ian-news@hotmail.com> - 2011-05-21 09:51 +1200
          Re: size_t in a struct Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-24 21:34 +0300
            Re: size_t in a struct Ian Collins <ian-news@hotmail.com> - 2011-05-25 07:54 +1200
        Re: size_t in a struct "[the China Blue] Drill Baby Drill" <chine.bleu@yahoo.com> - 2011-05-20 15:06 -0700
          Re: size_t in a struct Angel <angel+news@spamcop.net> - 2011-05-20 22:51 +0000
        Re: size_t in a struct Keith Thompson <kst-u@mib.org> - 2011-05-20 15:39 -0700
          Re: size_t in a struct Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-05-21 18:00 +0000
            Re: size_t in a struct Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-21 14:12 -0600
            Re: size_t in a struct Keith Thompson <kst-u@mib.org> - 2011-05-21 16:31 -0700
              Re: size_t in a struct Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-22 10:08 +0100
                Re: size_t in a struct Shao Miller <sha0.miller@gmail.com> - 2011-05-22 13:24 -0500
                  Re: size_t in a struct Ben Pfaff <blp@cs.stanford.edu> - 2011-05-22 10:37 -0700
                    Re: size_t in a struct Uncle Steve <stevet810@gmail.com> - 2011-05-22 14:18 -0400
                    Re: size_t in a struct Keith Thompson <kst-u@mib.org> - 2011-05-22 12:17 -0700
                      Re: size_t in a struct David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
                    Re: size_t in a struct Shao Miller <sha0.miller@gmail.com> - 2011-05-23 02:05 -0500
                      Re: size_t in a struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 11:21 +0100
                        Re: size_t in a struct Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:40 -0500
                          Re: size_t in a struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-24 01:25 +0100
                            Re: size_t in a struct Shao Miller <sha0.miller@gmail.com> - 2011-05-23 20:43 -0500
            Re: size_t in a struct gordonb.d6jvy@burditt.org (Gordon Burditt) - 2011-05-22 17:48 -0500
        Re: size_t in a struct Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-21 15:43 +0000
    Re: size_t in a struct Keith Thompson <kst-u@mib.org> - 2011-05-20 11:59 -0700
    Re: size_t in a struct Nobody <nobody@nowhere.com> - 2011-05-20 22:24 +0100

Page 1 of 2  [1] 2  Next page →

#4449 — size_t in a struct

Hello Group

To avoid padding in structures, where is the best place to put size_t
variables?

According the faq question 2.12 (http://c-faq.com/struct/padding.html),
it says:

"If you're worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."

So if I have the following:

typedef struct __buffer_t {

    char *buffer;
    size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long?  If it does,
then size_t still wouldn't be larger than a pointer on the system,
right?  But where should I put size_t in relation to other integer
declarations?  Should I all ways assume size_t is an unsigned long when
building structures?

Now, if I made another structure:

typedef struct __buffer2_t {

     Buffer_t name;
     char *buffer;
     size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?

Thanks.

[toc] | [next] | [standalone]

#4451

On 5/20/2011 14:22, Edward Rutherford wrote:
> Hello Group
>

Hello. :)

> To avoid padding in structures, where is the best place to put size_t
> variables?
>
> According the faq question 2.12 (http://c-faq.com/struct/padding.html),
> it says:
>
> "If you're worried about wasted space, you can minimize the effects of
> padding by ordering the members of a structure based on their base
> types, from largest to smallest."
>

And the sizes of those types can vary per implementation, too, if I 
recall correctly.

> So if I have the following:
>
> typedef struct __buffer_t {
>
>      char *buffer;
>      size_t size;
>
> } Buffer_t;
>
> I should have mimized padding since size_t is an unsigned long.

It is?  How did you determine that?

> However, will size_t ever become an unsigned long long?

It might, as far as I know.

> If it does,
> then size_t still wouldn't be larger than a pointer on the system,
> right?

Why not?  Some pointer types needn't even be the same size.  'void *' 
and 'char *' need to be the same size.  'struct XXX *' and 'struct YYY 
*' need to be the same size.  'union XXX *' and 'union YYY *' need to be 
the same size.  (If I'm not mistaken.)

> But where should I put size_t in relation to other integer
> declarations?  Should I all ways assume size_t is an unsigned long when
> building structures?

You might wish to make a different decision for each different 
implementation.  Are you concerned with portability and multiple 
implementations?

>
> Now, if I made another structure:
>
> typedef struct __buffer2_t {
>
>       Buffer_t name;
>       char *buffer;
>       size_t size;
>
> } Buffer2_t;
>

Please avoid using a leading double-underscore sequence in your 
identifiers; they're reserved.  So is using a leading underscore 
followed by an upper-case letter.  Trailing underscores can be fun.

> Is the above still the correct sequence to minimize padding?

I think it depends on your implementation.  It's possible that some kind 
of macro magic could help you to generate a structure with the least 
padding, given _any_ implementation.  But you might be stuck either 
observing the best order for each implementation and changing 
accordingly, or playing the statistics for some favourite set of 
implementations' common size decisions.  For example, it might be common 
that both 'size_t' and 'char *' are 32 bits.  A struct with those two 
members might commonly have no padding (given some set of favourite 
implementations).

Or maybe someone else will have better advice.

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

#4457

Shao Miller wrote:

> On 5/20/2011 14:22, Edward Rutherford wrote:
>> Hello Group
>>
>>
> Hello. :)
> 
>> To avoid padding in structures, where is the best place to put size_t
>> variables?
>>
>> According the faq question 2.12 (http://c-faq.com/struct/padding.html),
>> it says:
>>
>> "If you're worried about wasted space, you can minimize the effects of
>> padding by ordering the members of a structure based on their base
>> types, from largest to smallest."
>>
>>
> And the sizes of those types can vary per implementation, too, if I
> recall correctly.
> 
>> So if I have the following:
>>
>> typedef struct __buffer_t {
>>
>>      char *buffer;
>>      size_t size;
>>
>> } Buffer_t;
>>
>> I should have mimized padding since size_t is an unsigned long.
> 
> It is?  How did you determine that?
> 
>> However, will size_t ever become an unsigned long long?
> 
> It might, as far as I know.

So standard-wise, how do I handle size_t in structures to minmize
padding?  Should size_t all ways follow after pointers in structures?
And if I have integers in the structure, where should I put size_t?

<OT>
According my style(9) man page, the suggestion is to:

"When declaring variables in structures, declare them sorted by use,
then
  by size (largest to smallest), then by alphabetical order. "

This would lead to padding, right?  But I would have to assume a size
for size_t to follow that style.
</OT>

Thanks.

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

#4459

On 05/21/11 09:31 AM, Edward Rutherford wrote:
> Shao Miller wrote:
>> On 5/20/2011 14:22, Edward Rutherford wrote:
>>>
>> And the sizes of those types can vary per implementation, too, if I
>> recall correctly.
>>
>>> So if I have the following:
>>>
>>> typedef struct __buffer_t {
>>>
>>>       char *buffer;
>>>       size_t size;
>>>
>>> } Buffer_t;
>>>
>>> I should have mimized padding since size_t is an unsigned long.
>>
>> It is?  How did you determine that?
>>
>>> However, will size_t ever become an unsigned long long?
>>
>> It might, as far as I know.
>
> So standard-wise, how do I handle size_t in structures to minmize
> padding?  Should size_t all ways follow after pointers in structures?
> And if I have integers in the structure, where should I put size_t?

The standard does not go into the specifics of padding.

It is a reasonably safe bet to assume sizeof(size_t) == sizeof(void*).

I would point size_t members after pointer members.

> <OT>
> According my style(9) man page, the suggestion is to:
>
> "When declaring variables in structures, declare them sorted by use,
> then
>    by size (largest to smallest), then by alphabetical order. "
>
> This would lead to padding, right?  But I would have to assume a size
> for size_t to follow that style.
> </OT>

It would, but in most uses, padding isn't really an issue.

-- 
Ian Collins

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

#4719

Ian Collins <ian-news@hotmail.com> writes:
> On 05/21/11 09:31 AM, Edward Rutherford wrote:
> > Shao Miller wrote:
> >> On 5/20/2011 14:22, Edward Rutherford wrote:
> >>>
> >> And the sizes of those types can vary per implementation, too, if I
> >> recall correctly.
> >>
> >>> So if I have the following:
> >>>
> >>> typedef struct __buffer_t {
> >>>
> >>>       char *buffer;
> >>>       size_t size;
> >>>
> >>> } Buffer_t;
> >>>
> >>> I should have mimized padding since size_t is an unsigned long.
> >>
> >> It is?  How did you determine that?
> >>
> >>> However, will size_t ever become an unsigned long long?
> >>
> >> It might, as far as I know.
> >
> > So standard-wise, how do I handle size_t in structures to minmize
> > padding?  Should size_t all ways follow after pointers in structures?
> > And if I have integers in the structure, where should I put size_t?
> 
> The standard does not go into the specifics of padding.
> 
> It is a reasonably safe bet to assume sizeof(size_t) == sizeof(void*).

I have a compiler for which that's not true. 
Remember x86 and segmentation?

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#4721

On 05/25/11 06:34 AM, Phil Carmody wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 05/21/11 09:31 AM, Edward Rutherford wrote:
>>>
>>> So standard-wise, how do I handle size_t in structures to minmize
>>> padding?  Should size_t all ways follow after pointers in structures?
>>> And if I have integers in the structure, where should I put size_t?
>>
>> The standard does not go into the specifics of padding.
>>
>> It is a reasonably safe bet to assume sizeof(size_t) == sizeof(void*).
>
> I have a compiler for which that's not true.

You would!

> Remember x86 and segmentation?

Too well!

-- 
Ian Collins

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

#4461

In article <ir6mjl$d08$1@speranza.aioe.org>,
 Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> wrote:

> So standard-wise, how do I handle size_t in structures to minmize
> padding?  Should size_t all ways follow after pointers in structures?
> And if I have integers in the structure, where should I put size_t?

If you're working with 64-bit pointers, does struct packing have significant 
impact on your program size and speed?

-- 
I remember finding out about you,     |              Accept no substitutions.
Everyday my mind is all around you,   |        I'm whoever you want me to be.
Looking out from my lonely room       |   Annoying Usenet one post at a time.
Day after day.                        |     At least I can stay in character.

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

#4468

On 2011-05-20, [the China Blue] Drill Baby Drill <chine.bleu@yahoo.com> wrote:
> In article <ir6mjl$d08$1@speranza.aioe.org>,
>  Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> wrote:
>
>> So standard-wise, how do I handle size_t in structures to minmize
>> padding?  Should size_t all ways follow after pointers in structures?
>> And if I have integers in the structure, where should I put size_t?
>
> If you're working with 64-bit pointers, does struct packing have significant 
> impact on your program size and speed?

Padding is there to prevent unaligned access which would impact speed
and can create subtle bugs on some implementations. Eliminating padding
doesn't improve speed as the compiler already makes sure the data is
accessed in the fastest possible way. It just saves some space.

However, we're talking about just a handful of bytes, nothing in this
day and age where memory is measured in gigabytes. Unless you're developing
for an embedded system or plan to create a heck of a lot of instances of
your structure, padding is really nothing to be worried about and packing
your structures is probably a waste of time better spend on something
more worthwhile.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#4465

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Shao Miller wrote:
>> On 5/20/2011 14:22, Edward Rutherford wrote:
>>> To avoid padding in structures, where is the best place to put size_t
>>> variables?
>>>
>>> According the faq question 2.12 (http://c-faq.com/struct/padding.html),
>>> it says:
>>>
>>> "If you're worried about wasted space, you can minimize the effects of
>>> padding by ordering the members of a structure based on their base
>>> types, from largest to smallest."
>>>
>>>
>> And the sizes of those types can vary per implementation, too, if I
>> recall correctly.
>> 
>>> So if I have the following:
>>>
>>> typedef struct __buffer_t {
>>>
>>>      char *buffer;
>>>      size_t size;
>>>
>>> } Buffer_t;
>>>
>>> I should have mimized padding since size_t is an unsigned long.
>> 
>> It is?  How did you determine that?
>> 
>>> However, will size_t ever become an unsigned long long?
>> 
>> It might, as far as I know.
>
> So standard-wise, how do I handle size_t in structures to minmize
> padding?  Should size_t all ways follow after pointers in structures?
> And if I have integers in the structure, where should I put size_t?

Standard-wise, you don't.  The standard requires at least enough padding
to satisfy alignment requirements, but it says very little about what
those requirements are.

If you really absolutely need to avoid any possibility of padding,
declare an array of unsigned char and use memcpy() to copy the
individual members in an out.

> <OT>
> According my style(9) man page, the suggestion is to:
>
> "When declaring variables in structures, declare them sorted by use,
> then
>   by size (largest to smallest), then by alphabetical order. "
>
> This would lead to padding, right?  But I would have to assume a size
> for size_t to follow that style.
> </OT>

It might, though I've never followed that kind of rule myself.

Again, *why* are you so concerned about minimizing padding?  What bad
thing would happen if there were a little padding between members in
your structs?

If you'll tell us what your actual goal is, we'll be better able to help
you.

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

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

#4498

Keith Thompson wrote:
> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> Shao Miller wrote:
>>> On 5/20/2011 14:22, Edward Rutherford wrote:
>>>> To avoid padding in structures, where is the best place to put size_t
>>>> variables?
>>>>
>>>> According the faq question 2.12
>>>> (http://c-faq.com/struct/padding.html), it says:
>>>>
>>>> "If you're worried about wasted space, you can minimize the effects
>>>> of padding by ordering the members of a structure based on their base
>>>> types, from largest to smallest."
>>>>
>>>>
>>> And the sizes of those types can vary per implementation, too, if I
>>> recall correctly.
>>> 
>>>> So if I have the following:
>>>>
>>>> typedef struct __buffer_t {
>>>>
>>>>      char *buffer;
>>>>      size_t size;
>>>>
>>>> } Buffer_t;
>>>>
>>>> I should have mimized padding since size_t is an unsigned long.
>>> 
>>> It is?  How did you determine that?
>>> 
>>>> However, will size_t ever become an unsigned long long?
>>> 
>>> It might, as far as I know.
>>
>> So standard-wise, how do I handle size_t in structures to minmize
>> padding?  Should size_t all ways follow after pointers in structures?
>> And if I have integers in the structure, where should I put size_t?
> 
> Standard-wise, you don't.  The standard requires at least enough padding
> to satisfy alignment requirements, but it says very little about what
> those requirements are.
> 
> If you really absolutely need to avoid any possibility of padding,
> declare an array of unsigned char and use memcpy() to copy the
> individual members in an out.
> 
>> <OT>
>> According my style(9) man page, the suggestion is to:
>>
>> "When declaring variables in structures, declare them sorted by use,
>> then
>>   by size (largest to smallest), then by alphabetical order. "
>>
>> This would lead to padding, right?  But I would have to assume a size
>> for size_t to follow that style.
>> </OT>
> 
> It might, though I've never followed that kind of rule myself.
> 
> Again, *why* are you so concerned about minimizing padding?  What bad
> thing would happen if there were a little padding between members in
> your structs?
> 
> If you'll tell us what your actual goal is, we'll be better able to help
> you.

Thanks for that information.

I want to avoid padding in order to minimize the size of my structs in 
order to prevent caches misses where possible. I would expect that the 
overhead from using memcpy and unsigned char arrays, would outweight the 
savings from optimizing cache usage - happy to be corrected though.

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

#4500

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
>> 
>> Again, *why* are you so concerned about minimizing padding?  What bad
>> thing would happen if there were a little padding between members in
>> your structs?
>> 
>> If you'll tell us what your actual goal is, we'll be better able to help
>> you.
>
> Thanks for that information.
>
> I want to avoid padding in order to minimize the size of my structs in 
> order to prevent caches misses where possible. I would expect that the 
> overhead from using memcpy and unsigned char arrays, would outweight the 
> savings from optimizing cache usage - happy to be corrected though.

Ah.  The cost in unaligned accesses is virtually certain to outweigh the
savings in hit rate.  The padding is inserted precisely to make the code
run faster, at the expense of speed (if smaller were faster, padding
wouldn't be used).
-- 
"It used to be that the USA was pretty good at producing stuff teenaged 
boys could lose a finger or two playing with."	-- James Nicoll

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

#4503

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
[...]
>> Again, *why* are you so concerned about minimizing padding?  What bad
>> thing would happen if there were a little padding between members in
>> your structs?
>> 
>> If you'll tell us what your actual goal is, we'll be better able to help
>> you.
>
> Thanks for that information.
>
> I want to avoid padding in order to minimize the size of my structs in 
> order to prevent caches misses where possible. I would expect that the 
> overhead from using memcpy and unsigned char arrays, would outweight the 
> savings from optimizing cache usage - happy to be corrected though.

Have you performed measurements that indicate that your program's
performance is unacceptably slow, and that making your structs
slightly smaller will actually help?  Are the hours you're spending
on this worth the CPU time you expect to save?

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

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

#4507

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

> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> Keith Thompson wrote:
> [...]
>>> Again, *why* are you so concerned about minimizing padding?  What bad
>>> thing would happen if there were a little padding between members in
>>> your structs?
>>> 
>>> If you'll tell us what your actual goal is, we'll be better able to help
>>> you.
>>
>> Thanks for that information.
>>
>> I want to avoid padding in order to minimize the size of my structs in 
>> order to prevent caches misses where possible. I would expect that the 
>> overhead from using memcpy and unsigned char arrays, would outweight the 
>> savings from optimizing cache usage - happy to be corrected though.
>
> Have you performed measurements that indicate that your program's
> performance is unacceptably slow, and that making your structs
> slightly smaller will actually help?  Are the hours you're spending
> on this worth the CPU time you expect to save?

I've often thought it would be nice to be able to tell the compiler to
"optimise this structure's order for space" or "optimise this
structure's order for size".  It would, of course, only work in modular
code if you never exposed the structure definition and just used opaque
pointers.  But you'd be telling it that you never rely on the order of
things, and so could still structure the structure in the way that makes
the code most readable.

But it's very much an "it would be nice", as I suspect the benefits are
pretty small.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#4514

On 5/22/2011 4:08 AM, Dr Nick wrote:
> I've often thought it would be nice to be able to tell the compiler to
> "optimise this structure's order for space" or "optimise this
> structure's order for size".  It would, of course, only work in modular
> code if you never exposed the structure definition and just used opaque
> pointers.  But you'd be telling it that you never rely on the order of
> things, and so could still structure the structure in the way that makes
> the code most readable.
>
> But it's very much an "it would be nice", as I suspect the benefits are
> pretty small.

I guess a code generator could potentially accomplish something close to 
this.  I'd be interested in an algorithm which figures out the most 
size-efficient ordering of the members, if anyone has one (or some ideas 
for one).

But maybe such an opaque representation might have comparable overhead 
to serialization/deserialization, where Keith's memcpy() could be used 
and there could be zero padding?  (Along the lines of "...suspect the 
benefits are pretty small".)

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

#4515

Shao Miller <sha0.miller@gmail.com> writes:

> On 5/22/2011 4:08 AM, Dr Nick wrote:
> I guess a code generator could potentially accomplish something close
> to this.  I'd be interested in an algorithm which figures out the most
> size-efficient ordering of the members, if anyone has one (or some
> ideas for one).

Just sort the members into descending order of size.
-- 
Ben Pfaff 
http://benpfaff.org

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

#4517

On Sun, May 22, 2011 at 10:37:58AM -0700, Ben Pfaff wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
> 
> > On 5/22/2011 4:08 AM, Dr Nick wrote:
> > I guess a code generator could potentially accomplish something close
> > to this.  I'd be interested in an algorithm which figures out the most
> > size-efficient ordering of the members, if anyone has one (or some
> > ideas for one).
> 
> Just sort the members into descending order of size.

Another way is to put the structure member most likely to be accessed
first at the start of the struct.  Prefetching should have the rest of
the struct in-cache shortly after the first access.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4519

Ben Pfaff <blp@cs.stanford.edu> writes:
> Shao Miller <sha0.miller@gmail.com> writes:
>> On 5/22/2011 4:08 AM, Dr Nick wrote:
>> I guess a code generator could potentially accomplish something close
>> to this.  I'd be interested in an algorithm which figures out the most
>> size-efficient ordering of the members, if anyone has one (or some
>> ideas for one).
>
> Just sort the members into descending order of size.

Or in order of alignment, which might not be the same thing.

On some architectures, there could be an advantage to putting
as many small members as possble at the beginning of the struct,
because smaller offsets can be faster.

If C didn't require that struct members to follow their declared
order, the compiler could optimize the layout any way that makes
sense.  It's too late to change that without breaking existing code,
but perhaps a future standard could add an attribute to specify
that the the compiler can alter the layout -- or it could be a
compiler-specific extension.

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

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

#5231

On Sun, 22 May 2011 12:17:59 -0700, Keith Thompson <kst-u@mib.org>
wrote:

> Ben Pfaff <blp@cs.stanford.edu> writes:
> > Shao Miller <sha0.miller@gmail.com> writes:
> >> On 5/22/2011 4:08 AM, Dr Nick wrote:
> >> I guess a code generator could potentially accomplish something close
> >> to this.  I'd be interested in an algorithm which figures out the most
> >> size-efficient ordering of the members, if anyone has one (or some
> >> ideas for one).
> >
> > Just sort the members into descending order of size.
> 
> Or in order of alignment, which might not be the same thing.
> 
> On some architectures, there could be an advantage to putting
> as many small members as possble at the beginning of the struct,
> because smaller offsets can be faster.
> 
Or the most-accessed members, as elsethread.

> If C didn't require that struct members to follow their declared
> order, the compiler could optimize the layout any way that makes
> sense.  It's too late to change that without breaking existing code,
> but perhaps a future standard could add an attribute to specify
> that the the compiler can alter the layout -- or it could be a
> compiler-specific extension.

As an interesting contrast, Fortran has had structs -- which for
hysterical raisins it confusingly calls derived types -- standard
since F90, with the compiler allowed to reorder; F03 added standard
C-interop features (extensions for which were already common, but
different), and a C-interop derived-type can't be reordered.

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

#4544

On 5/22/2011 12:37 PM, Ben Pfaff wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>
>> On 5/22/2011 4:08 AM, Dr Nick wrote:
>> I guess a code generator could potentially accomplish something close
>> to this.  I'd be interested in an algorithm which figures out the most
>> size-efficient ordering of the members, if anyone has one (or some
>> ideas for one).
>
> Just sort the members into descending order of size.

I might be missing something...  Suppose an 'int' has both size and 
alignment of 4:

   sizeof (struct {
       char ca1[5];  /* 0 through 4 */
       /* 3 bytes of padding; 5 through 7 */
       int i;        /* 8 through 11 */
       /* No padding */
       char ca2[3];  /* 12 through 14 */
       /* 1 byte of padding; 15 */
     }) == 16

The above is most likely, right?  Whereas:

   sizeof (struct {
       int i;        /* 0 through 3 */
       /* No padding */
       char ca1[5];  /* 4 through 8 */
       /* No padding */
       char ca2[3];  /* 9 through 11 */
       /* No padding */
     }) == 12

Right?

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

#4559

Shao Miller <sha0.miller@gmail.com> writes:

> On 5/22/2011 12:37 PM, Ben Pfaff wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
>>
>>> On 5/22/2011 4:08 AM, Dr Nick wrote:
>>> I guess a code generator could potentially accomplish something close
>>> to this.  I'd be interested in an algorithm which figures out the most
>>> size-efficient ordering of the members, if anyone has one (or some
>>> ideas for one).
>>
>> Just sort the members into descending order of size.
>
> I might be missing something...  Suppose an 'int' has both size and
> alignment of 4:
>
>   sizeof (struct {
>       char ca1[5];  /* 0 through 4 */
>       /* 3 bytes of padding; 5 through 7 */
>       int i;        /* 8 through 11 */
>       /* No padding */
>       char ca2[3];  /* 12 through 14 */
>       /* 1 byte of padding; 15 */
>     }) == 16
>
> The above is most likely, right?  Whereas:
>
>   sizeof (struct {
>       int i;        /* 0 through 3 */
>       /* No padding */
>       char ca1[5];  /* 4 through 8 */
>       /* No padding */
>       char ca2[3];  /* 9 through 11 */
>       /* No padding */
>     }) == 12
>
> Right?

Yes.  The advice has been shorted beyond usefulness.  What I remember
being told (it was all fields round here, in those days) was to pack in
order of size (size being uses here as a proxy for alignment) treating
arrays as if they were just several fields of the array element type.

-- 
Ben.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web