int or size_t ?

[%u]

In Patterns of Human Error, the slide 31 point that you should replce int with
size_t
why that consider an error ?

Re: int or size_t ?

[bearophile]

%u:

 In Patterns of Human Error, the slide 31 point that you should replce int with
 size_t
 why that consider an error ?

If T is a byte and the array size is 5 billion items, on 64 bit systems...? In 
the little find() function you compare it with the length, that's a size_t. 
Someone else will give you better answers.

Bye,
bearophile

Re: int or size_t ?

[Andrej Mitrovic]

void main()
{
size_t val = int.max+1;
int val2 = val;
writeln(val2);
}

writes -2147483648

That should give you a hint.

Re: int or size_t ?

[%u]

size_t val1 = int.max+1;
int val2 = int.max+1;
writeln(val1); // 2147483648
writeln(val2); // -2147483648

very clear example

thanks you both

Re: int or size_t ?

[Andrej Mitrovic]

Actually my example was bad. What I wanted to say is that size_t will
be 64bit on 64bit platforms while int will stay 32bit. Another
difference is that size_t is unsigned. So it's bad to use int even if
you're sure you're only going to compile only on 32bit platforms.

Here's the relevant definitions in object_.d:

version(X86_64)
{
alias ulong size_t;
alias long  ptrdiff_t;
alias long  sizediff_t;
}
else
{
alias uint  size_t;
alias int   ptrdiff_t;
alias int   sizediff_t;
}

And an example:
void main()
{
size_t val = size_t.max;// maximum unsigned 32bit number on
32bit platforms

int val2 = val;
writeln(val2);  // -1 on 32bit platforms, due to
unsigned - signed conversion
}

Usually people type int because.. well it's used everywhere and it's
easy to type. I never liked the size_t name, but it has become a de
facto standard in other languages, so D uses that name as well. We've
already had a discussion on changing its name but nothing came out of
it.

Re: int or size_t ?

[Andrej Mitrovic]

Edit: I just saw you've already figured this out. :)

Re: Cannot interpret struct at compile time

[Robert Clipsham]

On 07/05/2011 23:36, Andrej Mitrovic wrote:

Not too sure, CTFE is a pain in the ass sometimes. What exactly are
you trying to do, print field names in a custom way?


No, I have a struct that I don't have access to in the scope I'm in, I 
do however have its type - by using the above, I can create a local 
clone of the type which acts the same (at least for my purposes), which 
I can then do things with. Except that it fails with that error message D;


--
Robert
http://octarineparrot.com/

Re: Cannot interpret struct at compile time

[Andrej Mitrovic]

One simplistic solution is to use alias this to simulate the same type:

struct Foo
{
int x, y;
}

string structClone(T)()
{
return struct  ~ T.stringof ~ _ { 
~ T.stringof ~  _inner;
alias _inner this;
this(T...)(T t) { _inner = typeof(_inner)(t);  } };;
}

void main()
{
mixin(structClone!Foo);
Foo_ foo = Foo_(1, 2);

assert(foo.x == 1);
assert(foo.y == 2);
}

Field initializations and ctors will work thanks to the templated ctor
that just forwards to the _inner struct.

Re: Cannot interpret struct at compile time

[Robert Clipsham]

On 08/05/2011 00:39, Andrej Mitrovic wrote:

One simplistic solution is to use alias this to simulate the same type:

struct Foo
{
 int x, y;
}

string structClone(T)()
{
 return struct  ~ T.stringof ~ _ { 
 ~ T.stringof ~  _inner;
 alias _inner this;
 this(T...)(T t) { _inner = typeof(_inner)(t);  } };;
}

void main()
{
 mixin(structClone!Foo);
 Foo_ foo = Foo_(1, 2);

 assert(foo.x == 1);
 assert(foo.y == 2);
}

Field initializations and ctors will work thanks to the templated ctor
that just forwards to the _inner struct.


Unfortunately this won't do what I need - I need to be able to iterate 
over the members of the resulting struct using .tupleof, which I can't 
do with alias this.


--
Robert
http://octarineparrot.com/

Shouldn't duplicate functions be caught by DMD?

[Andrej Mitrovic]

I'm not talking about function overloading, but functions with the same 
parameters inside the same class definition:

class Foo
{
int foo(int i)
{
return 1;
}

int foo(int i)
{
return 1;
}

void bar()
{
foo(1);
}
}

void main()
{
auto foo = new Foo();
}

Errors:
test.d(19): Error: function test.Foo.foo called with argument types:
((int))
matches both:
test.Foo.foo(int i)
and:
test.Foo.foo(int i)

If you comment out the call to foo(), and compile via -c -w -wi, no errors will 
be emitted. Only later when you try to use the object file you'll get a linker 
error:

fset 003C4H Record Type 00C3
 Error 1: Previous Definition Different : _D4test3Foo3fooMFiZi
--- errorlevel 1

I think the compiler should check catch these mistakes at compile-time.

Getting equivalent elements in a range/array

[Andrej M.]

I want to turn this:
auto arr = [1, 1, 2, 3, 4, 4];

into this:
auto arr2 = [[1, 1], [2], [3], [4, 4]];

I want an array of arrays of the same elements. Lazy or not, I don't care.

I thought I could get away with this inside some while loop:
auto equals = array(filter!a == b(arr));
arr = arr[equals.length-1..$];

Nope.

I need this for some buffered output, where the requirement is the elements of 
the buffer all need to have the same properties so a function can output a 
buffer of elements in one call instead of calling the function for each element 
(the function call is expensive).