While talking about useful additions, how about this one??
Ned Nowotny
ned at ghostwheel.UUCP
Fri Feb 5 10:19:21 AEST 1988
In article <7169 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <127 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>>... I would like to see "struct *" used as a generic pointer to a structure.
>
>I didn't understand your "explanation", but I don't see what good this
>would be. It would seem to provide an unwanted escape from strict typing.
Well, its not "unwanted" and "strict typing" doesn't seem to apply to C. ;-)
>Different structure types really ought not to have their pointers mixed
>up by the programmer.
I don't want to mix pointers to different structure types, but I do want
to write generic code which manipulates complex objects (e.g. linked list
managers). Currently, this requires declaring pointers as "char *" or
"long *" (worse because its not even a convention, but possibly more
correct when considering data alignment for a given implementation) in K&R C
compilers, or "void *" in ANSI psuedo-compatible C compilers. I do not find
either of these options particularly satisfying. "void *" is too
indiscriminating with regard to structure alignment and "char *" or "long *"
discriminate too much (besides, I want a pointer to a stucture of some
kind, not a char or a long). "struct *" would suppress unwarrented complaints
about possible integer/structure or character/structure alignment differences
from lint or my compiler. Any remaining possible alignment problems would then
be more likely to be treated as real problems and not line noise.
The nice thing about this proposal is that it breaks absolutely no existing
code, does not add any new keywords, and provides some additional type
information to C's typing system.
As a rational, consider that given:
int a, b;
int *a_ptr;
declares a pointer which may freely point to either "a" or "b" even though
the name implies that it should only point to "a". Despite the name,
"a_ptr" is a generic integer pointer although "a" and "b" may be conceptually
different objects.
In fact, given:
typedef int a_int;
typedef int b_int;
a_int a;
b_int b;
int *ptr;
a_int *a_ptr;
ptr = &a;
a_ptr = &b;
neither lint nor my compiler complain of type mismatches although they should
if C supported strict typing. (This compiler is a BSD C compiler running on
a VAX 11/750, but it is no different than any of a number of C compilers which
I have used.) Of course, it is frequently desirable to have a generic pointer
to an integer (a good thing because its all you get). In the same sense, it can
be desirable to have a generic pointer to complex objects (i.e. structures). A
"type" cast will be necessary to get at a structure's members through such a
pointer, but this is generally not necessary where a "struct *" pointer would
be used. After all, the intent is to have a handle on a some complex object,
not to manipulate the object.
--
Ned Nowotny (ned at ghostwheel.aca.mcc.com.UUCP)
More information about the Comp.lang.c
mailing list