Re: size of pointer in C?
- From: "Alexei A. Frounze" <alexfru@xxxxxxx>
- Date: Sat, 1 Oct 2005 01:34:14 +0400
"Keith Thompson" <kst-u@xxxxxxx> wrote in message
news:lnslvmuueg.fsf@xxxxxxxxxxxxxxxxxx
> "Alexei A. Frounze" <alexfru@xxxxxxx> writes:
> > "John Bode" <john_bode@xxxxxxxxxxx> wrote in message
> > news:1128096291.020242.291820@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > ...
> >> The quickest way to find out what pointer sizes are on your particular
> >> implementation:
> >>
> >> printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
> >> printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
> >> printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));
> >
> > And chances are that the tree will print the same number. And that's
> > practically on every system, if not on all.
>
> Probably, but there are valid reasons why char* and void* might be
> bigger,
Bigger than what and why?
> or at least have a different representation, than int*.
Like what? A few lowest signigicant bits being 0 due to alignment?
> > However, sizeof(void*) and sizeof(void(*)()) are very often different,
> > consider the Harvard architecure (if you've always programmed in msvc++
on
> > x86 PC :), where program and data memories aren't necessarily the same
thing
> > and may have different width of either the address bus or data bus or
both,
> > alsmo meaning that a byte in one space isn't necessarily equal to a byte
in
> > the other (in bits).
>
> Yes, differing sizes for data pointers and function pointers are
> plausible, but I don't think I've ever used a system where they
> actually differ. As for "byte" sizes, the C standard only uses the
> term to refer to object sizes; there's no such thing as the size of a
> function, in "bytes" or any other units. (A system may have such a
> concept, but standard C doesn't refer to it.)
Right.
> But the most important point is that, most of the time, none of this
> should matter.
True.
> You can write code that doesn't *care* whether
> different pointer types have different sizes, and that will work
> properly whether they differ or not. Just don't depend on any
> assumptions that aren't guaranteed by the standard. It's often
> (usually?) *easier* to write portable code than to write code that
> depends on system-specific sizes.
I'm not sure of this... The practice seem to show lots of examples of the
directly opposite. Many C programmers, the beginners (including me some time
ago), do not know C and the standard well for obvious reasons -- it's new to
them and it's different from whatever they had learned or used before. If
they happen to know a bit about the CPU for which they write their C code,
they're more likely to not use sizeof for the basic types, not care about
the alignment when placing objects in memory, ignore various warnings about
prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't
do it because I'm fortunate enough to have seen (correct my English here if
need be) various platforms, not just the x86. And this taught me how to do
things better. Those who are condemned to x86 and ignorance about C and its
standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible. :)
Alex
.
- Follow-Ups:
- Re: size of pointer in C?
- From: Keith Thompson
- Re: size of pointer in C?
- References:
- Re: size of pointer in C?
- From: Keith Thompson
- Re: size of pointer in C?
- Prev by Date: Re: a pointer that points to itself
- Next by Date: Re: offsetof
- Previous by thread: Re: size of pointer in C?
- Next by thread: Re: size of pointer in C?
- Index(es):
Relevant Pages
|
