March 19, 2013 Re: One case of array assignments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Nicholson-Sauls | 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.
|
Copyright © 1999-2021 by the D Language Foundation