View mode: basic / threaded / horizontal-split · Log in · Help
March 19, 2013
Re: One case of array assignments
On Monday, 18 March 2013 at 22:59:58 UTC, Timon Gehr wrote:
> On 03/18/2013 11:52 PM, monarch_dodra wrote:
>> On Monday, 18 March 2013 at 22:33:17 UTC, Timon Gehr wrote:
>>> On 03/18/2013 10:45 PM, monarch_dodra wrote:
>>>> ...
>>>>
>>>> ubyte[4096] x = repeat( cast(ubyte)0 )[ 0 .. 4096 ].array();
>>>>
>>>> This can be used as-is inside normal code. Hwoever, array is 
>>>> not
>>>> CTFE-able, so it can't work to define a struct T.init value.
>>>
>>> Which is annoying and should be fixed.
>>
>> Making array work with CTFE is a no-go, as array's job is to 
>> run-time
>> allocate a new array.
>>
>
> Uh. Its job is to collect a range into an array. Implementation 
> details are irrelevant.

Yes, you are right. For a few seconds I though that all 
allocations were banned in CTFE, but it's actually hand made 
allocation that don't work.

>> Now, if we had "staticArray(R, Sizes)(R)" transforms a range 
>> into an
>> array whose size is know at compile time, then that's another 
>> story.
>> It'd be more efficient at run-time, and CTFE-able
>>
>
> Sizes should go first.

Hum, I had meant: "staticArray(R, Sizes...)(R)" in case you 
wanted a multidim array.

I'm not 100% sure if putting Sizes... before R mixes well.

>> 1) Do we want such a weird and specific function? Or is that 
>> just
>> premature optimization? I mean, is there a real need?
>
> Use 'copy'.

Yes, but unfortunately, using 'copy' entails first declaring the 
variable, then copying to it, which defeats what we're trying to 
achieve.

That said, I investigated array, and just got it to work :) And 
it was trivial, so I'll push it.
March 19, 2013
Re: One case of array assignments
On 03/19/2013 08:18 AM, monarch_dodra wrote:
> ...
>
> Hum, I had meant: "staticArray(R, Sizes...)(R)" in case you wanted a
> multidim array.
>
> I'm not 100% sure if putting Sizes... before R mixes well.
>

It would have to be

template staticArray(Sizes...){
    auto staticArray(R)(R range){ ... }
}


>>> 1) Do we want such a weird and specific function? Or is that just
>>> premature optimization? I mean, is there a real need?
>>
>> Use 'copy'.
>
> Yes, but unfortunately, using 'copy' entails first declaring the
> variable, then copying to it, which defeats what we're trying to achieve.
>

staticArray is fine too.

> That said, I investigated array, and just got it to work :) And it was
> trivial, so I'll push it.

Great.
March 19, 2013
Re: One case of array assignments
On Tuesday, 19 March 2013 at 08:19:38 UTC, Timon Gehr wrote:
> On 03/19/2013 08:18 AM, monarch_dodra wrote:

>> That said, I investigated array, and just got it to work :) 
>> And it was
>> trivial, so I'll push it.
>
> Great.

Done:

https://github.com/D-Programming-Language/phobos/pull/1213

Now, this is legal code:

//--------
unittest
{
    //CTFE
    struct S
    {
        ubyte[5] a = repeat(cast(ubyte)1)[0 .. 5].array();
        ubyte[5] b = iota(cast(ubyte)0, cast(ubyte)5).array();
    }
    static assert(S.init.a[] == [1, 1, 1, 1, 1]);
    static assert(S.init.b[] == [0, 1, 2, 3, 4]);
}
//--------

Gnarly!
March 19, 2013
Re: One case of array assignments
On Monday, 18 March 2013 at 21:35:43 UTC, Chris Nicholson-Sauls
wrote:
clip
>
> struct CompressionData
> {
>     ubyte[4096] x; // note this is already [0...0] thanks
>                    // to default init... but still:
>
>     this ()
>     {
>         x[] = 0;
>     }
> }
>
>
> --- Or even: ---
>
> import std.range;
>
> struct CompressionData
> {
>     ubyte[4096] x = repeat( 0 )[ 0 .. 4096 ];
> }
>
> Assuming repeat()[] is CTFE-able (didn't test).

You could also uses mixin's to build these long static arrays. I
think there is a good example in Andrei's book.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home