faqcat6b6b.html

this is a mirrored site c-faq. thought might need offline

	*(int *)((char *)structp + offsetf) = value;
</pre>
<hr><hr><hr>
<a name="withxref">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/withxref.html"><!-- qtag -->Question 2.16</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Does C have an equivalent to Pascal's
<TT>with</TT> statement?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat38c2.html?sec=misc#with">20.23</a>.
<hr><hr><hr>
<a name="decay">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/decay.html"><!-- qtag -->Question 2.17</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
If an array name acts like a pointer to the base of an array,
why isn't the same thing true of a structure?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The rule
(see question <a href="faqcatca65.html?sec=aryptr#aryptrequiv">6.3</a>)
that causes array references to ``decay'' into pointers
is a special case which applies only to arrays,
and reflects their

``second class'' status in C.
(An analogous rule applies to functions.)
Structures, however,
are first class objects:
when you mention a structure,
you get the
entire
structure.
<hr><hr><hr>
<a name="retcrash">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/retcrash.html"><!-- qtag -->Question 2.18</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
This program
works correctly, but
it
dumps core
after it
finishes.
Why?
<pre>
	struct list {
		char *item;
		struct list *next;
	}

	/* Here is the main program. */

	main(argc, argv)
	{ ... }
</pre>

</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
A missing semicolon
at the end of the structure declaration
causes
<TT>main</TT> to be declared as returning
a structure.
(The connection is hard to see because of the intervening comment.)
Since
structure-valued functions are
usually
implemented by adding a hidden
return pointer
(see question
<a href="faqcat6b6b.html?sec=struct#passret">2.9</a>),
the generated code
for <TT>main()</TT> tries to accept three arguments,
although only two are passed
(in this case, by the C
start-up code).
See also questions
<a href="faqcat204f.html?sec=cpp#headerglom">10.9</a>
and
<a href="faqcat5e04.html?sec=strangeprob#crashatexit">16.4</a>.
</p>
<p>References:

CT&amp;P Sec. 2.3 pp. 21-2
<hr><hr><hr>
<a name="union">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/union.html"><!-- qtag -->Question 2.19</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between a structure and a union, anyway?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
A union is essentially a structure in which all of the fields overlay 
each other;
you can only use one field at a time.
(You can also
cheat by writing to one field and reading from another,
to
inspect
a type's bit patterns
or interpret them
differently,


but that's obviously pretty

machine-dependent.)
The size of a union is the maximum of the sizes of its 
individual members,
while the size of a structure is the sum of the sizes of its members.
(In both cases,
the size may be increased by padding;
see questions <a href="faqcat6b6b.html?sec=struct#padding">2.12</a>
and <a href="faqcat6b6b.html?sec=struct#endpad">2.13</a>.)
</p>

<p>References:

ISO Sec. 6.5.2.1
<br>
H&amp;S Sec. 5.7 pp. 140-145 esp. Sec. 5.7.4
<hr><hr><hr>
<a name="initunion">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/initunion.html"><!-- qtag -->Question 2.20</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Can I initialize unions?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
In the original ANSI C,
an initializer was allowed only for

the first-named
member
of a union.
C99 introduces ``designated initializers''
which can be used to initialize any member.

</p><p>In the absence of designated initializers,
if you're desperate,
you can
sometimes
define several variant copies of a union,
with the members in different orders,
so that you can declare and initialize
the one having the appropriate first member.

(These variants are guaranteed to be implemented compatibly,
so it's okay to ``pun'' them
by initializing one
and then using the
other.)
</p>



<p>References:

K&amp;R2 Sec. 6.8 pp. 148-9
<br>
ISO Sec. 6.5.7
<br>
C9X Sec. 6.5.8
<br>
H&amp;S Sec. 4.6.7 p. 100
<hr><hr><hr>
<a name="taggedunion">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/taggedunion.html"><!-- qtag -->Question 2.21</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is there an automatic way
to keep track of which field of a union is in use?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
You can implement an explicitly ``tagged''

union yourself:
<pre>
struct taggedunion {
	enum {UNKNOWN, INT, LONG, DOUBLE, POINTER} code;
	union {
		int i;
		long l;
		double d;
		void *p;
	} u;
};
</pre>
You will have to
make
sure that the <TT>code</TT> field
is always set appropriately
when the union is written to;
the compiler won't do any of this for you automatically.
(C unions are not like
Pascal variant records.)
</p>
<p>References:

H&amp;S Sec. 5.7.3 p. 143
<hr><hr><hr>
<a name="enumvsdefine">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/enumvsdefine.html"><!-- qtag -->Question 2.22</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between
an enumeration and a set of
preprocessor <TT>#define</TT>s?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>

There is
little
difference.
The
C Standard
says that enumerations
have integral type
and that enumeration constants are of type <TT>int</TT>,

so both
may be freely intermixed with
other
integral
types, without errors.
(If,
on the other hand,
such intermixing were disallowed without explicit casts,
judicious use of enumerations could catch certain programming errors.)
</p><p>Some
advantages of enumerations are
that the numeric
values are automatically assigned,
that a debugger may be able to display
the symbolic values when enumeration variables are examined,
and


that they obey block scope.
(A
compiler may
also
generate nonfatal warnings when enumerations
are
indiscriminately mixed,
since doing so

can still be considered bad style
even though
it is not strictly illegal.)
A disadvantage

is that the programmer has little control
over those nonfatal warnings;
some programmers also resent not having control
over the sizes of enumeration variables.
</p>












<p>References:

K&amp;R2 Sec. 2.3 p. 39, Sec. A4.2 p. 196
<br>
ISO Sec. 6.1.2.5, Sec. 6.5.2, Sec. 6.5.2.2, Annex F
<br>
H&amp;S Sec. 5.5 pp. 127-9, Sec. 5.11.2 p. 153
<hr><hr><hr>
<a name="enumport">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/enumport.html"><!-- qtag -->Question 2.23</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Are enumerations really portable?
<br>Aren't they Pascalish?
<br>
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Enumerations were a
mildly
late addition
to the language
(they were not in K&amp;R1),
but they are definitely part of the language now:
they're in the C Standard,
and all modern compilers support them.
They're quite portable,
although historical uncertainty about

their precise

definition
led to their
specification
in the Standard being rather weak
(see question <a href="faqcat6b6b.html?sec=struct#enumvsdefine">2.22</a>).
<hr><hr><hr>
<a name="enumprint">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/enumprint.html"><!-- qtag -->Question 2.24</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is there an easy way to print enumeration values symbolically?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
You can write a little function
(one per enumeration)
to
map an enumeration constant to a string,
either
by using a <TT>switch</TT> statement
or by searching an array.

(For debugging purposes,
a good debugger
should automatically print enumeration constants symbolically.)
<hr><hr><hr>
<a name="bitfield0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/bitfield0.html"><!-- qtag -->Question 2.25</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I came across some structure declarations with colons and 
numbers next to certain
fields,
like this:
<pre>
struct record {
	char *name;
	int refcount : 4;
	unsigned dirty : 1;
};
</pre>
What gives?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Those are <a href="../../sx1/index.html#bit-fields"><dfn>bit-fields</dfn></a>;
the number gives the exact size of the field,
in bits.
(See any complete book on C for
the details.)
Bit-fields can be used to save space
in structures having several binary flags or other
small fields,
and they can also be used

in an attempt to conform to externally-imposed storage layouts.
(Their success at the latter task is mitigated


by the fact that bit-fields are assigned left-to-right on some 
machines and right-to-left on others).
</p><p>Note that the colon notation
for specifying the size of a field in bits
is <em>only</em> valid in structures
(and in unions);
you cannot use this mechanism
to specify the size of arbitrary
variables.
(See questions <a href="faqcatd3c2.html?sec=decl#exactsizes">1.2</a> and <a href="faqcatd3c2.html?sec=decl#int16">1.3</a>.)
</p>



<p>References:

K&amp;R1 Sec. 6.7 pp. 136-8
<br>
K&amp;R2 Sec. 6.9 pp. 149-50
<br>
ISO Sec. 6.5.2.1
<br>
H&amp;S Sec. 5.6.5 pp. 136-8
<hr><hr><hr>
<a name="bitfields">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../struct/bitfields.html"><!-- qtag -->Question 2.26</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why do people use explicit masks and
bit-twiddling
code so much,
instead of declaring bit-fields?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Bit-fields are thought to be nonportable,
although they are no less portable
than other parts of the language.
(You don't know how big they can be,
but that's equally true for values of type <TT>int</TT>.
You don't know by default whether they're signed,
but that's equally true of type <TT>char</TT>.
You don't know
whether they're laid out from left to right or right to left in 
memory,
but that's equally true of the bytes
of <em>all</em> types,
and only matters if you're trying to
conform to externally-imposed storage layouts,
which is always nonportable;
see also questions
<a href="faqcat6b6b.html?sec=struct#padding">2.12</a> 
and
<a href="faqcat38c2.html?sec=misc#binaryfiles">20.5</a>.)
</p><p>Bit-fields are inconvenient
when you also want to be able to
manipulate some collection of bits as a whole
(perhaps to copy a set of flags).
You can't have arrays of bit-fields;
see also question <a href="faqcat38c2.html?sec=misc#bitsets">20.8</a>.
Many programmers suspect that the compiler won't generate good
code for bit-fields (historically, this was sometimes true).
</p><p>
Straightforward code using
bit-fields is certainly clearer
than the equivalent explicit masking instructions;
it's too bad
that
bit-fields can't be used more often.

<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcatd3c2.html?sec=decl" rev=precedes>prev</a>
<a href="faqcatee08.html?sec=expr" rel=precedes>next</a>
<a href="faqcat.html" rev=subdocument>up</a>
</p>
<hr>
<p>
<br><!-- lastfooter -->
<a href="../../about.html">about this FAQ list</a>
&nbsp;
<a href="../../eskimo.html">about eskimo</a>
&nbsp;
<a href="../../search.html">search</a>
&nbsp;
<a href="../../feedback.html">feedback</a>
&nbsp;
<a href="../../struct/copyright.html">copyright</a>
<p>
Hosted by
<a href="http://www.eskimo.com/"><img src="../../../www.eskimo.com/img/link/eskitiny.gif" alt="Eskimo North"></a>
</body>

<!-- Mirrored from c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=struct by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:57:38 GMT -->
</html>