📄 align.esr2.html
字号:
<html><!-- Mirrored from c-faq.com/struct/align.esr2.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:59:28 GMT --><head><title></title></head><body>From: Norman Diamond<br>Newsgroups: comp.lang.c<br>Subject: Re: Criticism of C-FAQ submission invited<br>Date: 22 Sep 1994 09:26:35 GMT<br>Message-ID: <35rikb$4dt$1@usenet.pa.dec.com><p>In article <35qdf0$7iq@netaxs.com> Eric Raymond writes:<br>>A: Under most compilers on older word-oriented machines, each C data item<br>> other than a component of a <TT>char</TT> array must begin on a byte address that<br>> is a multiple of the word size of the machine (that is, each type must be<br>> ``word-aligned''). Such implementations are becoming rare as ancient 16-<br>> and 36-bit machines pass away.<p>For efficiency purposes, often this would <em>include</em> components of a <TT>char</TT>array, and the C standard requires a bit of inefficiency in such cases.I would delete ``other than a component of a <TT>char</TT> array''.<p>Futhermore, imbedded systems are becoming <em>more</em> numerous than they usedto be. Washing machines and rice cookers didn't used to have these things.And imbedded systems are often made with weird custom architectures.So I would say ``Such implementations on hosted systems are becoming rare,though standalone implementations might have arbitrarily weird requirements.''<p>>struct/array/union types have the alignment of their most restrictive member.<p>I have read that the committee decided to allow implementations to imposemore restrictive alignments than necessary. I think that they did notissue a technical corrigendum, so I think their assertion conflicts withthe standard, but what else is new. Anyway, add an ``at least''.<p>> The first member of each<br>> continuous group of bit fields is typically word-aligned, with all following<br>> being continuously packed into following words (though ANSI C requires the<br>> latter only for bit-field groups of less than word size).<p>The word ``word'' is ambiguous here. The unit does not have to be the sameas the size of an int. If an int has word size and the unit for bit-fieldshas a different size, then ``word'' is incorrect here. Maybe say ``units ofsome size'' and ``less than the size of whatever unit''.<p>>Q: How do I figure the ``true size'' (with trailing padding) of a type when<br>> it occurs in a struct or array?<p>The correct answer is the ``sizeof'' operator. It includes trailing padding.<p>>Q: How can I squeeze the padding out of a structure to make it smaller?<br>[...]<br>> A simple rule that minimize padding in the ``self-aligned'' case (and does<br>> no harm in most others) is to order your struct members by decreasing size.<p>No. Order your struct members by decreasing alignment requirements.For example, an array of 47 chars should come after an int, not the otherway around. And you probably want all nested structs up at the beginningeven if they're relatively short, and you want to order them in a way thatwould be optimal if implementations didn't force extra padding into them(so that they really will be optimal on implementations which don't).<p>Also beware that different types of pointers can have different sizes andmaybe different alignment requirements. Pointers to function types, andpointers to void or chararacter types, are ``usually'' at least as long andat least as restrictive as other pointer types, so it is ``usually'' at leastas favorable to put them earlier.<p>Should pointers go before doubles or vice-versa? There's no general answer.<p>> No padding will be required within groups of members of the same size,<p>The committee said there might be :-(<p>> no group will require leading padding;<p>That is correct. The standard prohibits leading padding.<p>>Q: How can I get complete control of the bit-level layout of a struct?<br>>A: This is what bit-fields are for. Declare all your members as bit fields.<p>It still doesn't work, because an implementation might set its unit as 1 bit,and put arbitrary padding between bits. The most complete control you canget is by abandoning structs and using an array of char. You'll still haveproblems in network code with big-endian vs. little-endian.<p>> Note about bit fields: though modern compilers default them to unsigned,<p>Maybe so; I've never tried. I'd suggest <em>always</em> specifying the desiredtype (int or unsigned).<p>>Q: Why can't I pass structs back and forth between the heterogenous machines<br>> on my network? It's all C, isn't it?<p>You might not even be able to do it between two programs on a single machine.One compiler might put int at 16 bits and the other at 32 bits. They mightpad the ends of structs differently.<p>>Q: I came to C from Pascal, and the one feature I miss is Pascal's `with'<br>> construct. Shouldn't C have an equivalent?<br>>A: No, it's too dangerous.<p>Come on now, C is designed for people who like living dangerously.``It's dangerous'' is an argument for <em>including</em> it in C, and ``it's toodangerous'' is an argument for <em>requiring</em> it in C. Have you reallyforgotten the spirit of C? You'd be better off deleting this questionand asserted answer.<br>--<br> << If this were the company's opinion, I would not be allowed to post it. >><br>segmentation fault (california dumped)</body><!-- Mirrored from c-faq.com/struct/align.esr2.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:59:28 GMT --></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -