size_t + ptrdiff_t

[Manu]

On 19 February 2012 23:16, Stewart Gordon <smjg_1998 at yahoo.com> wrote:

> On 19/02/2012 17:51, Manu wrote:
> <snip>
>
>>    Hang on ... are we talking here about some "native int", or the int
>> type?
>>
> <snip>
>
>  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
>> module?
>>
>
> 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
> idea.
>

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.
>
> Stewart.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120220/5a2aca3c/attachment.html>