sizeof a struc field

Bill Poser poser at csli.Stanford.EDU
Thu Oct 26 15:11:31 AEST 1989


In article <1469 at crdos1.crd.ge.COM> davidsen at crdos1.UUCP (bill davidsen)
writes:
>  This [just doing sizeof(member) - BP] is just not practical unless
> you control the header file. There are times when a field in a
> structure may not be the same type (portably).

I have two reactions to this. The first is that people who distribute
libraries with headers that define structures with possibly variable
(across implementation or time) members are doing a poor job if they
don't either: (a) provide functions or macros which can be used to
obtain the necessary information or (b) use macro definitions so that
one can write,e.g. sizeof(INTEGRAL) instead of sizeof(int) or sizeof(short)
or whatever. The second is that it is good to have the means to get
around the deficiencies of suppliers who don't do this, so I will concede
the utility of being able to do sizeof(struct->member).

This makes me wonder whether it would not be worthwhile (in D, or whatever)
to treat struct_type.member_name as a type alias, so that if we had:

	struct foo{
		TYPE1 a;
		TYPE2 b;
	};

we could then use foo.a as a type, equivalent in this case to TYPE1.
This would allow, in particular, the usage sizeof(foo.a).



More information about the Comp.lang.c mailing list