size_t + ptrdiff_t
turkeyman at gmail.com
Sun Feb 19 15:15:44 PST 2012
On 19 February 2012 23:16, Stewart Gordon <smjg_1998 at yahoo.com> wrote:
> On 19/02/2012 17:51, Manu wrote:
>> Hang on ... are we talking here about some "native int", or the int
> I don't really understand your resistance? I'm going to have the type
>> when I need it, the
>> question is, will it be standardised, or will I (& everyone else) invent
>> the name and
>> introduce a block of (probably not very portable) version() bullshit at
>> the top of their
> I'm not saying we shouldn't have native integer types in D. Maybe what's
> needed is to be clearer on what's meant exactly by a native integer type.
> And then add the types to Phobos/druntime.
> I particularly don't understand your suggestion of the names "size_t" and
> "ssize_t" for these types. They don't seem to me to denote the size of
> anything. I guess "nativeInt" and "nativeUint", defined in whatever module
> would be suitable, would be one possibility. Maybe someone has a better
well ssize_t is an already established compliment to size_t, I guess it's
identical to ptrdiff_t, but some CRT's seem to prefer the ssize_t name.
Personally size_t and ssize_t make more sense to me than size_t and
ptrdiff_t, which seems like a contradiction of terminology, although the
'ptr' name seems more fitting to what it actually is...
Ultimately I don't care, I suspect the prior commitment to size_t and
ptrdiff_t can not be changed (although redefining their meaning would not
be a breaking change, it just might show some cases of inappropriate usages)
I agree that nativeInt should probably be in the standard library, but I'm
really not into that name. It's really long and ugly. That said, I
basically hate size_t too, it doesn't seem very D-ish, reeks of C
mischief... and C stuffs up those types so much. It's not dependable what
they actually mean in C (ie. ptr size/native word size) on all compilers
I've come in contact with :/
> But knowing what code in Phobos/druntime should be using native integer
> types might help put the problem in better perspective.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Digitalmars-d