size_t + ptrdiff_t

[Manu]

On 20 February 2012 16:03, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> On 20 February 2012 11:14, Manu <turkeyman at gmail.com> wrote:
> > On 20 February 2012 10:31, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> >>
> >> On 19 February 2012 18:27, Manu <turkeyman at gmail.com> wrote:
> >> > On 19 February 2012 20:07, Timon Gehr <timon.gehr at gmx.ch> wrote:
> >> >>
> >> >> On 02/19/2012 03:59 PM, Manu wrote:
> >> >>>
> >> >>> Okay, so it came up a couple of times, but the questions is, what
> are
> >> >>> we
> >> >>> going to do about it?
> >> >>>
> >> >>> size_t and ptrdiff_t are incomplete, and represent non-complimentary
> >> >>> signed/unsigned halves of the requirement.
> >> >>> There are TWO types needed, register size, and pointer size.
> >> >>> Currently,
> >> >>> these are assumed to be the same, which is a false assumption.
> >> >>>
> >> >>> I propose size_t + ssize_t should both exist, and represent the
> native
> >> >>> integer size. Also something like ptr_t, and ptrdiff_t should also
> >> >>> exist, and represent the size of the pointer.
> >> >>>
> >> >>> Personally, I don't like the _t notation at all. It doesn't fit the
> >> >>> rest
> >> >>> of the D types, but it's established, so I don't expect it can
> change.
> >> >>> But we do need the 2 missing types.
> >> >>>
> >> >>> There is also the problem that there is lots of code written using
> the
> >> >>> incorrect types. Some time needs to be taken to correct phobos too I
> >> >>> guess.
> >> >>
> >> >>
> >> >> Currently, size_t is defined to be what you call ptr_t, ptrdiff_t is
> >> >> present, and what you call size_t/ssize_t does not exist. Under which
> >> >> circumstances is it important to have a distinct type that denotes
> the
> >> >> register size? What kind of code requires such a type? It is
> >> >> unportable.
> >> >
> >> >
> >> > It is just as unportable as size_t its self. The reason you need it is
> >> > to
> >> > improve portability, otherwise people need to create arbitrary version
> >> > mess,
> >> > which will inevitably be incorrect.
> >> > Anything from calling convention code, structure layout/packing,
> copying
> >> > memory, basically optimising for 64bits at all... I can imagine static
> >> > branches on the width of that type to select different paths.
> >> > Even just basic efficiency, using 32bit ints on many 64bit machines
> >> > require
> >> > extra sign-extend opcodes after every single load... total waste of
> cpu
> >> > time.
> >> >
> >> > Currently, if you're running a 64bit system with 32bit pointers, there
> >> > is
> >> > absolutely nothing that exists at compile time to tell you you're
> >> > running a
> >> > 64bit system, or to declare a variable of the machines native type,
> >> > which
> >> > you're crazy if you say is not important information. What's the point
> >> > of a
> >> > 64bit machine, if you treat it exactly like a 32bit machine in every
> >> > aspect?
> >>
> >> gdc offers __builtin_machine_(u)int for word size, and
> >> __builtin_pointer_(u)int for pointer size via gcc.builtins module.
> >> Nevermind though, it's not quite a "standard" :~)
> >
> >
> > That's beautiful though! Can we alias them, and produce a true D type
> that
> > represents them? :)
> >
> > My basic issue with these size_t/c_int/core.stdc... stuff, is that it
> seems
> > the intent is to go out of the way to maintain compatibility with C, at
> the
> > expense of sucking C's messy and poorly defined types into D, which is a
> > shame. It just results in D having the same crappy archaic typing
> problems
> > as C.
> > I appreciate that the C types should exist for interoperability with C
> (ie,
> > their quirks should be preserved for any given compiler/architecture),
> but
> > I'd also like to see strictly defined types in D with no respect to any C
> > counterpart, guaranteed by the language to be exactly what they claim to
> be,
> > and not confused depending which compiler you try to use.
> >
> > These 2 GCC intrinsics would appear to be precisely what I was looking
> for
> > at the start of this thread...
>
>
> Well, as Walter said, these could be aliased in core.stdc.config.
>

I don't think they are 'standard c' though ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120220/c4cd7c89/attachment-0001.html>