View mode: basic / threaded / horizontal-split · Log in · Help
October 15, 2012
templated static array
How can I do this?

I have this code: http://dpaste.dzfl.pl/d9165502

And as you can see, the templated function 'receive2' take 
automatically dynamic arrays. But how can I tell the compiler, 
that this function takes (preferably) static arrays?
My little "hack" function 'receive' take the type and the number 
of elements. So the compiler know: it's a static array. But is 
there no simpler trick to do this?
Maybe something like 'void receive(T)(static T vals) {'.
October 15, 2012
Re: templated static array
On 2012-05-15 16:10, Namespace <rswhite4@googlemail.com> wrote:

> How can I do this?
>
> I have this code: http://dpaste.dzfl.pl/d9165502
>
> And as you can see, the templated function 'receive2' take automatically  
> dynamic arrays. But how can I tell the compiler, that this function  
> takes (preferably) static arrays?
> My little "hack" function 'receive' take the type and the number of  
> elements. So the compiler know: it's a static array. But is there no  
> simpler trick to do this?
> Maybe something like 'void receive(T)(static T vals) {'.

Nope. That's the way to do it.

-- 
Simen
October 15, 2012
Re: templated static array
Namespace:

> I have this code: http://dpaste.dzfl.pl/d9165502

void receive(alias n, T)(T[n] vals) {

No need to use alias there, this is better:

void receive(size_t n, T)(T[n] vals) {


> But how can I tell the compiler, that this function takes 
> (preferably) static arrays?

Define "preferably" please.
Often template constraints are able to do many things (and there 
is a isStaticArray trait).

Bye,
bearophile
October 15, 2012
Re: templated static array
So there is no way that the compiler knows by himself how many 
elements are in the array? something like this:

void receive(T, size_t n = vals.length)(T[n] vals) {
	writeln(typeof(vals).stringof);
}

or:

void receive(T)(T[vals.length] vals) {
	writeln(typeof(vals).stringof);
}
October 15, 2012
Re: templated static array
Namespace:

> So there is no way that the compiler knows by himself how many 
> elements are in the array?

The syntax I have suggested doesn't have the problem you fear. 
Why don't you compile and run a little test program?

Bye,
bearophile
October 15, 2012
Re: templated static array
On Monday, 15 October 2012 at 15:10:43 UTC, bearophile wrote:
> Namespace:
>
>> So there is no way that the compiler knows by himself how many 
>> elements are in the array?
>
> The syntax I have suggested doesn't have the problem you fear. 
> Why don't you compile and run a little test program?
>
> Bye,
> bearophile

I have: http://dpaste.dzfl.pl/661e4fb3
But I still have to specify the number of elements and the type. 
That is what I try to avoid.
October 15, 2012
Re: templated static array
On 2012-23-15 16:10, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> On 2012-05-15 16:10, Namespace <rswhite4@googlemail.com> wrote:
>
>> How can I do this?
>>
>> I have this code: http://dpaste.dzfl.pl/d9165502
>>
>> And as you can see, the templated function 'receive2' take  
>> automatically dynamic arrays. But how can I tell the compiler, that  
>> this function takes (preferably) static arrays?
>> My little "hack" function 'receive' take the type and the number of  
>> elements. So the compiler know: it's a static array. But is there no  
>> simpler trick to do this?
>> Maybe something like 'void receive(T)(static T vals) {'.
>
> Nope. That's the way to do it.

No, wait, sorry. You don't need to specify those things when calling the
function. This works:

void bar(T, size_t n)(T[n] a) {}

void main(){
    int[3] a;
    bar(a);
}

-- 
Simen
October 15, 2012
Re: templated static array
But bar([1, 2, 3]); not. The compiler does not realize that [1, 
2, 3] means a static array in this context.
You have to write bar(cast(int[3]) [1, 2, 3]); but I think the 
compiler have to recognize this on it's own.
October 15, 2012
Re: templated static array
On 2012-35-15 17:10, Namespace <rswhite4@googlemail.com> wrote:

> But bar([1, 2, 3]); not. The compiler does not realize that [1, 2, 3]  
> means a static array in this context.
> You have to write bar(cast(int[3]) [1, 2, 3]); but I think the compiler  
> have to recognize this on it's own.

This is true. The problem is, as you say, that the compiler treats array
literals as dynamic rather than static arrays. I would argue this is the
correct default, but it's obviously not the default you want here.

bearophile has posted about this on numerous occasions, and it's among
his top thousand wanted features. :p

-- 
Simen
October 15, 2012
Re: templated static array
On Mon, Oct 15, 2012 at 07:05:13PM +0200, Simen Kjaeraas wrote:
> On 2012-35-15 17:10, Namespace <rswhite4@googlemail.com> wrote:
> 
> >But bar([1, 2, 3]); not. The compiler does not realize that [1, 2, 3]
> >means a static array in this context.  You have to write
> >bar(cast(int[3]) [1, 2, 3]); but I think the compiler have to
> >recognize this on it's own.
> 
> This is true. The problem is, as you say, that the compiler treats
> array literals as dynamic rather than static arrays. I would argue
> this is the correct default, but it's obviously not the default you
> want here.
> 
> bearophile has posted about this on numerous occasions, and it's among
> his top thousand wanted features. :p
[...]

I have to chime in here and say that I'm not particularly happy with the
way dmd currently processes array literals. I think dmd currently
doesn't take type inference far enough. If a particular array literal is
being passed to a function that expects a static array, say, then it
should be able to interpret the literal as a static array of the
matching type.

Similarly, when you have, say, a template function:

	func(T)(T[] args) if (is(T==short)) { ... }

Supposing there is no other overload that accepts an integral array, the
compiler should know that when you write func([1,2,3]) the array literal
should be a short[]. Currently, it treats [1,2,3] as int[], and so fails
to match the template. Lots of ugly hacks and workarounds are necessary
to make things work correctly.

I say this is one area where things need improvement. Especially since
type inference is one of D's major selling points (what with voldemort
types, etc., that doesn't require the user to spell out a long
complicated name just to use a range function in std.range, among many
other nice perks).


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home