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...)

-- 
- Alex

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

Hi,

I have an import related questoin..

I have this:

module A;

const c1=4;


module B;

import A;


module C;

private import B;



Should not module C see c1? Because it cannot see it. Even if the import is not private.




Regards


Marton Papp

On Saturday, January 21, 2012 21:22:22 equinox@atw.hu wrote:
> Hi,
> 
> I have an import related questoin..
> 
> I have this:
> 
> module A;
> 
> const c1=4;
> 
> 
> module B;
> 
> import A;
> 
> 
> module C;
> 
> private import B;
> 
> 
> 
> 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

>>
>> 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?



Marton Papp

On 21-01-2012 21:18, Timon Gehr 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

While it does what I want, it's not exactly ideal. I just want a general-purpose native-size signed integer. ptrdiff_t sounds like it must have something to do with pointers, which is not what I want my API to look like. I could alias ptrdiff_t to isize_t, but then that defeats the purpose right there. Do you think that it would be a big deal to add an alias ptrdiff_t isize_t; to object.di?

-- 
- Alex

There's sizediff_t which is the same thing.

On 21-01-2012 22:46, Andrej Mitrovic wrote:
> There's sizediff_t which is the same thing.

I still think this type name has some specific notion to it. "isize_t" alone just means "a signed integer the size of a pointer" (same for size_t, minus the signed), while sizediff_t means something along the lines of "an integer the size of the result of an arithmetic operation on a pointer".

-- 
- Alex

"Alex Rønne Petersen" <xtzgzorex@gmail.com> wrote in message news:jffbuc$2b37$1@digitalmars.com...
> On 21-01-2012 22:46, Andrej Mitrovic wrote:
>> There's sizediff_t which is the same thing.
>
> I still think this type name has some specific notion to it. "isize_t" alone just means "a signed integer the size of a pointer" (same for size_t, minus the signed), while sizediff_t means something along the lines of "an integer the size of the result of an arithmetic operation on a pointer".
>

The names of "ptrdiff_t" and "size_t" *are* terrible, but that's what we have. There was a big thread not too long ago about getting better names, even just as standard alternatives, but the powers that be just weren't interested. So if we want sensible names for them, we have to make up non-standardized aliases in each individual project. :/

There are some more ints here, ints for everyone, for people with long or short feet or no feet: http://www.dlang.org/phobos/std_stdint.html

Bye,
bearophile