View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2012
Re: isize_t?
This has been discussed before on this NG (I don't have the links to
the discussions, sorry!) but additional aliases will not be added.
You'll have to use what you have or introduce your own aliases in your
code.
January 21, 2012
Re: isize_t?
On 21-01-2012 23:01, Andrej Mitrovic wrote:
> This has been discussed before on this NG (I don't have the links to
> the discussions, sorry!) but additional aliases will not be added.
> You'll have to use what you have or introduce your own aliases in your
> code.

Le sigh. Consistent, standardized names would have been really nice.

-- 
- Alex
January 21, 2012
Re: isize_t?
On 21-01-2012 22:59, bearophile wrote:
> 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

Hm, might just end up using those.

-- 
- Alex
January 21, 2012
Re: isize_t?
On 21 January 2012 22:18, Timon Gehr <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.
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.
January 22, 2012
Re: import question
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.

- Jonathan m Davis
January 22, 2012
Re: isize_t?
On Saturday, January 21, 2012 23:07:17 Alex Rønne Petersen wrote:
> On 21-01-2012 23:01, Andrej Mitrovic wrote:
> > This has been discussed before on this NG (I don't have the links to
> > the discussions, sorry!) but additional aliases will not be added.
> > You'll have to use what you have or introduce your own aliases in your
> > code.
> 
> Le sigh. Consistent, standardized names would have been really nice.

size_t comes from C/C++, and is exactly the same as it is in C++. In D, you 
know that if a type ends in _t, then its size can vary depending on the 
machine that you compile on, unlike all of the other primitive types.

Maybe another name would have been better, but it works, and I think that most 
people who have been C/C++ programmers just don't care. The know size_t, and 
it works.

At this point, given how much code would break from changing it, you would 
have to demonstrate that whatever name you came up with was really worth that 
cost, I realyl don't think that that's going to happen.

- Jonathan M Davis
January 22, 2012
Re: isize_t?
sizediff_t or ptrdiff_t I think
January 22, 2012
Re: isize_t?
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.671.1327197702.16222.digitalmars-d@puremagic.com...
>
>size_t comes from C/C++, and is exactly the same as it is in C++. In D, you
>know that if a type ends in _t, then its size can vary depending on the
>machine that you compile on, unlike all of the other primitive types.
>
>Maybe another name would have been better, but it works, and I think that 
>most
>people who have been C/C++ programmers just don't care. The know size_t, 
>and
>it works.
>
>At this point, given how much code would break from changing it, you would
>have to demonstrate that whatever name you came up with was really worth 
>that
>cost, I realyl don't think that that's going to happen.
>

It wouldn't have to change, just have a better name added. No reason 
'size_t', et al, couldn't still be kept for compatibility.
January 22, 2012
Re: import question
"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...)
January 22, 2012
Re: isize_t?
On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:
> It wouldn't have to change, just have a better name added. No reason
> 'size_t', et al, couldn't still be kept for compatibility.

Except that we're generally against keeping around alias cruft like that 
except temporarily as part of a deprecation path, so that doesn't usually fly. 
Certainly, it means that if you want that to happen, you'd then have to be 
able to come up with a name and arguments for it which justified having two 
standard aliases for the same thing.

- Jonathan M Davis
1 2 3 4
Top | Discussion index | About this forum | D home