On 2/21/2012 6:07 PM, Juan Manuel Cabo wrote:
> 16bit intel had 16bit segments and offsets, so memory was segmented
> and you couldn't address more than 64kb at a time.
> So you couldn't have grabbed^H^H"allocated" more than 64kb in real mode in intel
> in a single linear block.

size_t was 16 bits on all 16 bit memory models except the 'huge' one.

On 2/21/2012 4:50 PM, Juan Manuel Cabo wrote:
> Looking for size_t extravagancies in C, I found that VC uses __int64
> for size_t in x64 target.

Which is correct.

size_t for 64 bit D is also a 64 bit integral type.

On 2/21/2012 2:11 PM, Stewart Gordon wrote:
> When did C gain a type called ulong, anyway?

unsigned long

> Are we going to have c_long_long as well?

Probably.

On Tuesday, February 21, 2012 21:22:54 Walter Bright wrote:
> On 2/21/2012 4:50 PM, Juan Manuel Cabo wrote:
> > Looking for size_t extravagancies in C, I found that VC uses __int64 for size_t in x64 target.
> 
> Which is correct.
> 
> size_t for 64 bit D is also a 64 bit integral type.

Yes, but __int64 is a signed integeral type, whereas size_t in D is an unsigned integeral type.

- Jonathan M Davis

On 2/21/2012 9:56 PM, Jonathan M Davis wrote:
> On Tuesday, February 21, 2012 21:22:54 Walter Bright wrote:
>> On 2/21/2012 4:50 PM, Juan Manuel Cabo wrote:
>>> Looking for size_t extravagancies in C, I found that VC uses __int64
>>> for size_t in x64 target.
>>
>> Which is correct.
>>
>> size_t for 64 bit D is also a 64 bit integral type.
>
> Yes, but __int64 is a signed integeral type, whereas size_t in D is an
> unsigned integeral type.

Ah, I see.

On 22 February 2012 02:19, Walter Bright <newshound2@digitalmars.com> wrote:
> On 2/21/2012 1:03 AM, Artur Skawina wrote:
>>
>> Types like ptrdiff_t are not necessary in D, because you can write
>> portable
>> code using 'auto' and 'typeof()' - std C didn't have these, so a type had
>> to be invented for everything.
>
>
> And, in fact, object.di contains:
>
>
> alias typeof(int.sizeof)                    size_t;
> alias typeof(cast(void*)0 - cast(void*)0)   ptrdiff_t;

But as far as I can see, size_t and ptrdiff_t have a special meaning inside the compiler, and you can change their alias at will (though I've never tried).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2012-02-22 06:24, Walter Bright wrote:
> On 2/21/2012 2:11 PM, Stewart Gordon wrote:
>> When did C gain a type called ulong, anyway?
>
> unsigned long
>
>> Are we going to have c_long_long as well?
>
> Probably.

Wouldn't that always be a "long" in D? Or is it the same as with "long" in C.

-- 
/Jacob Carlborg

On 22 February 2012 03:31, Juan Manuel Cabo <juanmanuel.cabo@gmail.com>wrote:

> On 02/21/2012 10:13 PM, Sean Kelly wrote:
> > I think this is actually a good thing, since working with unsigned
> integers is a pain.
>
> Yes, I would prefer that msb bit to be the sign too, but behavior might
> depend on it,
> and correctness and predictability is important.
>
> My first code snippet was WRONG (sorry for the noise). And I couldn't even reproduce the problem with my VC.
>
> A correct snippet is simply this:
>
>    size_t s = -2;
>
>    if (s > 0) {
>         printf("unsigned");
>    } else {
>         printf("signed");
>    }
>
> Also, the shift operator is does a logical or arithmetic shift depending
> on whether it is signed or unsigned, so the result is different
> if you do
>     s >> 1
> whether s is signed or unsigned.
>

Actually, it doesn't.
It is not defined by C whether it should be arithmetic or logical shift
right, and it is up to the compiler to choose.
Microsoft's PPC compiler produces a *logical* signed shift right for
instance.

On 22/02/2012 02:23, Walter Bright wrote:
<snip>
> The C99 Standard sez:
>
> "The types are ptrdiff_t which is the signed integer type of the result of subtracting two
> pointers; size_t which is the unsigned integer type of the result of the sizeof operator;"

And what does it say about what type the sizeof operator returns?

Stewart.

On 22/02/2012 07:24, Jacob Carlborg wrote:
> On 2012-02-22 06:24, Walter Bright wrote:
>> On 2/21/2012 2:11 PM, Stewart Gordon wrote:
<snip>
>>> Are we going to have c_long_long as well?
>>
>> Probably.
>
> Wouldn't that always be a "long" in D? Or is it the same as with "long" in C.

long in D is 64 bits.
long in C is 32 bits (on Win16/32 at least).

If the C standard sets in stone the size of a long long, then we can do away with a c_long_long and just use long.  Otherwise, if we're going to have c_int and c_long, it only makes sense to have c_long_long as well.

Stewart.