On 22/01/12 00:15, Manu wrote:
> On 21 January 2012 22:18, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:
>
>         Hi,
>
>         I needed a native-size signed integer type this other day and
>         was just
>         kinda wondering: Why don't we have this in object.di? isize_t or
>         whatever?
>
>         (I have a feeling this has been asked before, but my search-fu
>         is weak
>         today seemingly...)
>
>
>     .object.ptrdiff_t
>
>
> I don't necessarily think ptrdiff_t and signed size_t are the same thing.
> Surely size_t should represent the systems native word width? ptrdiff_t
> represents the size of a pointer, which is NOT necessarily the same as
> the native word width.

Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee a flat address space?
I mean, back in the old 16 bit segmented architecture days, you could have two 32 bit pointers p and q, and have the difference between them being 16 bits (or an error, if the segments were different).

Maybe similar oddities are possible on the less traditional architectures (Cell, maybe?)

> There are quite a few 64 bit systems that retain 32bit pointers. I would
> thing ssize_t is safer than using ptrdiff_t, and certainly, both should
> exist.

On 23 January 2012 12:55, Don Clugston <dac@nospam.com> wrote:

> On 22/01/12 00:15, Manu wrote:
>
>> On 21 January 2012 22:18, Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>> wrote:
>>
>>    On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:
>>
>>        Hi,
>>
>>        I needed a native-size signed integer type this other day and
>>        was just
>>        kinda wondering: Why don't we have this in object.di? isize_t or
>>        whatever?
>>
>>        (I have a feeling this has been asked before, but my search-fu
>>        is weak
>>        today seemingly...)
>>
>>
>>    .object.ptrdiff_t
>>
>>
>> I don't necessarily think ptrdiff_t and signed size_t are the same thing. Surely size_t should represent the systems native word width? ptrdiff_t represents the size of a pointer, which is NOT necessarily the same as the native word width.
>>
>
> Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee a
> flat address space?
> I mean, back in the old 16 bit segmented architecture days, you could have
> two 32 bit pointers p and q, and have the difference between them being 16
> bits (or an error, if the segments were different).
>
> Maybe similar oddities are possible on the less traditional architectures
> (Cell, maybe?)


Cell is too weird to worry about (just treat it as 32bit), but it's fairly common to have embedded systems with 64bit processors which retain 32bit pointers because the memory map is fixed, and there's no point. All games consoles, perhaps even phones with the new 64bit ARM processors. Phones don't need >4gb of ram ;) .. Should size_t on this device be 32 or 64bits? The pointers and OS will still be 32bits, I don't see them releasing an Android-64 any time soon.

On Jan 22, 2012, at 2:30 AM, Manu wrote:
> 
> Also size_t and ptrdiff_t are not necessarily the same size.
> Is there a signed size_t type? Is there an unsigned ptrdiff_t type? What are they?

There's ssize_t in the Posix world.  ptrdiff_t is the closes you can get in C99 though, I believe.

On 23 January 2012 12:47, Don Clugston <dac@nospam.com> wrote:

> On 22/01/12 03:56, Nick Sabalausky wrote:
>
>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message news:mailman.670.1327197408.**16222.digitalmars-d@puremagic.**com...
>>
>>> On Saturday, January 21, 2012 22:28:20 equinox@atw.hu wrote:
>>>
>>>> Should not module C see c1? Because it cannot see it. Even if the
>>>>>> import
>>>>>> is not private.
>>>>>>
>>>>>
>>>>> No. imports are private by default There's no point in marking them as
>>>>> private. If you want module C to see what module B is importing, then
>>>>> module B
>>>>> needs to import it publicly. e.g.
>>>>>
>>>>> module B;
>>>>>
>>>>> public import A;
>>>>>
>>>>> - Jonathan M Davis
>>>>>
>>>>
>>>> It makes sense. But did it always work like this?
>>>>
>>>
>>> It has for several years at minimum. But I don't know how it works in D1,
>>> and
>>> it may have worked differently in the very beginning of D2. I don't know.
>>> But
>>> as far as I know, it's always worked this way.
>>>
>>>
>> I have a vague recollection of it being the other way around at one point,
>> but that probably would have been pre-1.0. *Definitely* pre-2.0. (Or I
>> might
>> just be thinking of something else...)
>>
>
> Version D 0.163 Jul 18, 2006
> New/Changed Features
>
>    Imports now default to private instead of public. Breaks existing code.
>    Added static imports, renamed imports, and selective importing
>

What is a static import? It sounds like something I might have needed last night...

On 01/25/2012 01:33 PM, Manu wrote:
> On 23 January 2012 12:47, Don Clugston <dac@nospam.com
> <mailto:dac@nospam.com>> wrote:
>
>     On 22/01/12 03:56, Nick Sabalausky wrote:
>
>         "Jonathan M Davis"<jmdavisProg@gmx.com
>         <mailto:jmdavisProg@gmx.com>>  wrote in message
>         news:mailman.670.1327197408.__16222.digitalmars-d@puremagic.__com...
>
>             On Saturday, January 21, 2012 22:28:20 equinox@atw.hu
>             <mailto:equinox@atw.hu> wrote:
>
>                         Should not module C see c1? Because it cannot
>                         see it. Even if the
>                         import
>                         is not private.
>
>
>                     No. imports are private by default There's no point
>                     in marking them as
>                     private. If you want module C to see what module B
>                     is importing, then
>                     module B
>                     needs to import it publicly. e.g.
>
>                     module B;
>
>                     public import A;
>
>                     - Jonathan M Davis
>
>
>                 It makes sense. But did it always work like this?
>
>
>             It has for several years at minimum. But I don't know how it
>             works in D1,
>             and
>             it may have worked differently in the very beginning of D2.
>             I don't know.
>             But
>             as far as I know, it's always worked this way.
>
>
>         I have a vague recollection of it being the other way around at
>         one point,
>         but that probably would have been pre-1.0. *Definitely* pre-2.0.
>         (Or I might
>         just be thinking of something else...)
>
>
>     Version D 0.163 Jul 18, 2006
>     New/Changed Features
>
>         Imports now default to private instead of public. Breaks
>     existing code.
>         Added static imports, renamed imports, and selective importing
>
>
> What is a static import? It sounds like something I might have needed
> last night...

A static import is an import that makes the module visible but does not import any of it's members into the current scope:

static import std.stdio;

void main(){
    // writeln("hello, world!");        // undefined symbol
    std.stdio.writeln("hello, world!"); // ok
}