www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - isize_t?

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 21 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
Jan 21 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 21 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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. :/
Jan 21 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jan 21 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 21 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 21 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 22-01-2012 03:00, Jonathan M Davis wrote:

 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



I wasn't suggesting changing size_t, but rather ptrdiff_t which is much 
less commonly used. (Or alternatively, just adding a ptrdiff_t -> 
isize_t alias.)

-- 
- Alex
Jan 22 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 03:41:30 Jonathan M Davis wrote:

 On Sunday, January 22, 2012 12:25:25 Alex R=C3=B8nne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is =







 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)



 What you want is probably ssize_t. It's only defined for Posix at the=




 though (core.sys.posix.sys.types).



Actually, a better idea would be to just use c_long (which is what ssiz=
e_t is=20
anyway), which is in core.stdc.config. It's available on all OSes.

- Jonathan M Davis
Jan 22 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 5:25 AM, Alex Rønne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is much
 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)



Check .object.sizediff_t.

Andrei
Jan 22 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
There's sizediff_t which is the same thing.
Jan 21 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jan 21 2012
prev sibling next sibling parent Don Clugston <dac nospam.com> writes:
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.
Jan 23 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dee21e5c1c04b73158bf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B8nne 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 hav=




 two 32 bit pointers p and q, and have the difference between them being 1=




 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.

--20cf3005dee21e5c1c04b73158bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 23 January 2012 12:55, Don Clugston <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dac nospam.com">dac nospam.com</a>&gt;</span=

 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=



<div class=3D"im">On 22/01/12 00:15, Manu wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On 21 January 2012 22:18, Timon Gehr &lt;<a href=3D"mailto:timon.gehr gmx.c=
h" target=3D"_blank">timon.gehr gmx.ch</a><br></div><div><div class=3D"h5">
&lt;mailto:<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.geh=
r gmx.ch</a>&gt;&gt; wrote:<br>
<br>
 =C2=A0 =C2=A0On 01/21/2012 09:06 PM, Alex R=C3=B8nne Petersen wrote:<br>
<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,<br>
<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0I needed a native-size signed integer type this=
 other day and<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0was just<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0kinda wondering: Why don&#39;t we have this in =
object.di? isize_t or<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0whatever?<br>
<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0(I have a feeling this has been asked before, b=
ut my search-fu<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0is weak<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0today seemingly...)<br>
<br>
<br>
 =C2=A0 =C2=A0.object.ptrdiff_t<br>
<br>
<br></div></div><div class=3D"im">
I don&#39;t necessarily think ptrdiff_t and signed size_t are the same thin=
g.<br>
Surely size_t should represent the systems native word width? ptrdiff_t<br>
represents the size of a pointer, which is NOT necessarily the same as<br>
the native word width.<br>
</div></blockquote>
<br>
Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee a f=
lat address space?<br>
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).<br>
<br>
Maybe similar oddities are possible on the less traditional architectures (=
Cell, maybe?)</blockquote><div><br></div><div>Cell is too weird to worry ab=
out (just treat it as 32bit), but it&#39;s fairly common to have embedded s=
ystems with 64bit processors which retain 32bit pointers because the memory=
 map is fixed, and there&#39;s no point. All games consoles, perhaps even p=
hones with the new 64bit ARM processors. Phones don&#39;t need &gt;4gb of r=
am ;) ..=C2=A0Should size_t on this device be 32 or 64bits? The pointers an=
d OS will still be 32bits, I don&#39;t see them releasing an Android-64 any=
 time soon.</div>
</div>

--20cf3005dee21e5c1c04b73158bf--
Jan 23 2012
prev sibling next sibling parent reply equinox atw.hu writes:
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
Jan 21 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 21 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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
}
Jan 25 2012
prev sibling parent equinox atw.hu writes:
 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
Jan 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dee2900fbb04b711f960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 21 January 2012 22:18, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 01/21/2012 09:06 PM, Alex R=C3=B8nne 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 whateve=







 (I have a feeling this has been asked before, but my search-fu is weak
 today seemingly...)






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.

--20cf3005dee2900fbb04b711f960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 21 January 2012 22:18, Timon Gehr <span dir=
=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch">timon.gehr gmx.ch</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On 01/21/2012 09:06 PM, Alex R=C3=
=B8nne Petersen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I needed a native-size signed integer type this other day and was just<br>
kinda wondering: Why don&#39;t we have this in object.di? isize_t or whatev=
er?<br>
<br>
(I have a feeling this has been asked before, but my search-fu is weak<br>
today seemingly...)<br>
<br>
</blockquote>
<br></div></div>
.object.ptrdiff_t<br>
</blockquote></div><br><div>I don&#39;t necessarily think ptrdiff_t and sig=
ned size_t are the same thing.</div><div>Surely size_t should represent the=
 systems native word width? ptrdiff_t represents the size of a pointer, whi=
ch is NOT necessarily the same as the native word width.</div>
<div>There are quite a few 64 bit systems that retain 32bit pointers. I wou=
ld thing ssize_t is safer than using ptrdiff_t, and certainly, both should =
exist.</div>

--20cf3005dee2900fbb04b711f960--
Jan 21 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 21 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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...)
Jan 21 2012
parent Don Clugston <dac nospam.com> writes:
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.
Jan 23 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 21, 2012 23:07:17 Alex R=C3=B8nne 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 t=







 the discussions, sorry!) but additional aliases will not be added.
 You'll have to use what you have or introduce your own aliases in y=







 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=20
know that if a type ends in _t, then its size can vary depending on the=
=20
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 th=
at most=20
people who have been C/C++ programmers just don't care. The know size_t=
, and=20
it works.

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

- Jonathan M Davis
Jan 21 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jan 21 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 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.



I agree with Jonathan. Two names for the same thing just blows.
Jan 21 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfg0p4$i1j$1 digitalmars.com...

 On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 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.



 I agree with Jonathan. Two names for the same thing just blows.



Sure it blows, but not as much as sticking to god-awful names like ptrdiff_t 
and size_t.

And yea, you could label it a bikeshedding issue, but really...There's 
questionable bikeshed colors, and then there's "lime green with orange 
stripes and pink polka dots, all largely obscured by a giant shit stain and 
three rotting rat carcasses."
Jan 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.688.1327228280.16222.digitalmars-d puremagic.com...

 Also size_t and ptrdiff_t are not necessarily the same size.



Hah! That's going to be LOADS of fun when I encounter it!!

Ugh...
Jan 22 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
sizediff_t or ptrdiff_t I think
Jan 21 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.674.1327201445.16222.digitalmars-d puremagic.com...

 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.



How about: "Because the existing ones blow and removing them outright is 
never gonna happen"? ;)
Jan 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235429d6d8a47a1404b71b662b
Content-Type: text/plain; charset=UTF-8

On 22 January 2012 05:51, Nick Sabalausky <a a.a> wrote:


 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:jfg0p4$i1j$1 digitalmars.com...

 On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 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







 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.



 I agree with Jonathan. Two names for the same thing just blows.



 Sure it blows, but not as much as sticking to god-awful names like
 ptrdiff_t
 and size_t.

 And yea, you could label it a bikeshedding issue, but really...There's
 questionable bikeshed colors, and then there's "lime green with orange
 stripes and pink polka dots, all largely obscured by a giant shit stain and
 three rotting rat carcasses."



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?

--00235429d6d8a47a1404b71b662b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 22 January 2012 05:51, Nick Sabalausky <span =
dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&=
quot;Walter Bright&quot; &lt;<a href=3D"mailto:newshound2 digitalmars.com">=
newshound2 digitalmars.com</a>&gt; wrote in message<br>

news:jfg0p4$i1j$1 digitalmars.com...<br>
<div><div class=3D"h5">&gt; On 1/21/2012 7:03 PM, Jonathan M Davis wrote:<b=
r>
&gt;&gt; On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:<br>
&gt;&gt;&gt; It wouldn&#39;t have to change, just have a better name added.=
 No reason<br>
&gt;&gt;&gt; &#39;size_t&#39;, et al, couldn&#39;t still be kept for compat=
ibility.<br>
&gt;&gt;<br>
&gt;&gt; Except that we&#39;re generally against keeping around alias cruft=
 like that<br>
&gt;&gt; except temporarily as part of a deprecation path, so that doesn&#3=
9;t usually<br>
&gt;&gt; fly.<br>
&gt;&gt; Certainly, it means that if you want that to happen, you&#39;d the=
n have to<br>
&gt;&gt; be<br>
&gt;&gt; able to come up with a name and arguments for it which justified h=
aving<br>
&gt;&gt; two<br>
&gt;&gt; standard aliases for the same thing.<br>
&gt;<br>
&gt; I agree with Jonathan. Two names for the same thing just blows.<br>
<br>
</div></div>Sure it blows, but not as much as sticking to god-awful names l=
ike ptrdiff_t<br>
and size_t.<br>
<br>
And yea, you could label it a bikeshedding issue, but really...There&#39;s<=
br>
questionable bikeshed colors, and then there&#39;s &quot;lime green with or=
ange<br>
stripes and pink polka dots, all largely obscured by a giant shit stain and=
<br>
three rotting rat carcasses.&quot;<br></blockquote><div><br></div><div>Also=
 size_t and ptrdiff_t are not necessarily the same size.</div><div>Is there=
 a signed size_t type? Is there an unsigned ptrdiff_t type? What are they?<=
/div>
</div>

--00235429d6d8a47a1404b71b662b--
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 12:25:25 Alex R=C3=B8nne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is mu=




 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)



What you want is probably ssize_t. It's only defined for Posix at the m=
oment=20
though (core.sys.posix.sys.types).

- Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 22, 2012, at 2:30 AM, Manu wrote:

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




There's ssize_t in the Posix world.  ptrdiff_t is the closes you can get =
in C99 though, I believe.
Jan 23 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
--002354470e0c4fe00504b759793d
Content-Type: text/plain; charset=UTF-8

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.



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

--002354470e0c4fe00504b759793d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 23 January 2012 12:47, Don Clugston <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dac nospam.com">dac nospam.com</a>&gt;</span=

 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=



<div class=3D"HOEnZb"><div class=3D"h5">On 22/01/12 03:56, Nick Sabalausky =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
&quot;Jonathan M Davis&quot;&lt;<a href=3D"mailto:jmdavisProg gmx.com" targ=
et=3D"_blank">jmdavisProg gmx.com</a>&gt; =C2=A0wrote in message<br>
news:mailman.670.1327197408.<u></u>16222.digitalmars-d puremagic.<u></u>com=
...<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Saturday, January 21, 2012 22:28:20 <a href=3D"mailto:equinox atw.hu" ta=
rget=3D"_blank">equinox atw.hu</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

Should not module C see c1? Because it cannot see it. Even if the<br>
import<br>
is not private.<br>
</blockquote>
<br>
No. imports are private by default There&#39;s no point in marking them as<=
br>
private. If you want module C to see what module B is importing, then<br>
module B<br>
needs to import it publicly. e.g.<br>
<br>
module B;<br>
<br>
public import A;<br>
<br>
- Jonathan M Davis<br>
</blockquote>
<br>
It makes sense. But did it always work like this?<br>
</blockquote>
<br>
It has for several years at minimum. But I don&#39;t know how it works in D=
1,<br>
and<br>
it may have worked differently in the very beginning of D2. I don&#39;t kno=
w.<br>
But<br>
as far as I know, it&#39;s always worked this way.<br>
<br>
</blockquote>
<br>
I have a vague recollection of it being the other way around at one point,<=
br>
but that probably would have been pre-1.0. *Definitely* pre-2.0. (Or I migh=
t<br>
just be thinking of something else...)<br>
</blockquote>
<br></div></div>
Version D 0.163 Jul 18, 2006<br>
New/Changed Features<br>
<br>
 =C2=A0 =C2=A0Imports now default to private instead of public. Breaks exis=
ting code.<br>
 =C2=A0 =C2=A0Added static imports, renamed imports, and selective importin=
g<br></blockquote><div><br></div><div>What is a static import? It sounds li=
ke something I might have needed last night...</div></div>

--002354470e0c4fe00504b759793d--
Jan 25 2012