Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: size_t in a struct |
| Date | 2011-05-20 14:52 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <ir6d98$e50$1@dont-email.me> (permalink) |
| References | <ir6bhi$fcu$1@speranza.aioe.org> |
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web