On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
> is there an allocation in this?
> 
> enum vals=[1, 2, 3, 0];
> 
> int[4] a;
> a[] = vals[];

Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though.

- Jonathan M Davis

On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis wrote:
> On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
>> is there an allocation in this?
>> 
>> enum vals=[1, 2, 3, 0];
>> 
>> int[4] a;
>> a[] = vals[];
>
> Since, you're asking it to copy the elements of a dynamic array to a static
> one, I would fully expect it to result in an allocation, though a smart
> compiler might optimize it out. I wouldn't expect dmd to do that though.
>
> - Jonathan M Davis

So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...

On Tuesday, 20 August 2013 at 18:38:54 UTC, John Colvin wrote:
> So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...

Welcome to painful world of allocation-free D programming ;)

On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
> On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
> 
> wrote:
> > On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
> >> is there an allocation in this?
> >> 
> >> enum vals=[1, 2, 3, 0];
> >> 
> >> int[4] a;
> >> a[] = vals[];
> > 
> > Since, you're asking it to copy the elements of a dynamic array
> > to a static
> > one, I would fully expect it to result in an allocation, though
> > a smart
> > compiler might optimize it out. I wouldn't expect dmd to do
> > that though.
> > 
> > - Jonathan M Davis
> 
> So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...

Well, that's what you told it to do semantically. The compiler could theoretically optimize it (and hopefully will eventually), but it would be an optimization. At this point, if you initialize the static array with an array literal, then it will avoid the allocation (though it didn't used to), but AFAIK, it'll still allocate with your example.

- Jonathan M Davis

On Tuesday, 20 August 2013 at 19:25:56 UTC, Jonathan M Davis wrote:
> On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
>> On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
>> >> is there an allocation in this?
>> >> 
>> >> enum vals=[1, 2, 3, 0];
>> >> 
>> >> int[4] a;
>> >> a[] = vals[];
>> > 
>> > Since, you're asking it to copy the elements of a dynamic array
>> > to a static
>> > one, I would fully expect it to result in an allocation, though
>> > a smart
>> > compiler might optimize it out. I wouldn't expect dmd to do
>> > that though.
>> > 
>> > - Jonathan M Davis
>> 
>> So you're saying it will allocate a new dynamic array, initialise
>> it with 1,2,3,0 and then copy the elements from that new array to
>> the static one? That's not good...
>
> Well, that's what you told it to do semantically. The compiler could
> theoretically optimize it (and hopefully will eventually), but it would be an
> optimization. At this point, if you initialize the static array with an array
> literal, then it will avoid the allocation (though it didn't used to), but
> AFAIK, it'll still allocate with your example.
>
> - Jonathan M Davis

I presume there's a good reason why we don't have:
  enum a = [1,2,3,4];
  assert assert(is(typeof(a) == int[4]));

this works after all:
  enum int[4] a = [1,2,3,4];
  assert assert(is(typeof(a) == int[4]));

On Tuesday, August 20, 2013 21:33:23 John Colvin wrote:
> I presume there's a good reason why we don't have:
> enum a = [1,2,3,4];
> assert assert(is(typeof(a) == int[4]));
> 
> this works after all:
> enum int[4] a = [1,2,3,4];
> assert assert(is(typeof(a) == int[4]));

Array literals are always dynamic arrays, so [1, 2, 3, 4] is int[] by definition.

- Jonathan M Davis

On Tuesday, 20 August 2013 at 19:33:25 UTC, John Colvin wrote:
> On Tuesday, 20 August 2013 at 19:25:56 UTC, Jonathan M Davis wrote:
>> On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
>>> On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
>>> 
>>> wrote:
>>> > On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
>>> >> is there an allocation in this?
>>> >> 
>>> >> enum vals=[1, 2, 3, 0];
>>> >> 
>>> >> int[4] a;
>>> >> a[] = vals[];
>>> > 
>>> > Since, you're asking it to copy the elements of a dynamic array
>>> > to a static
>>> > one, I would fully expect it to result in an allocation, though
>>> > a smart
>>> > compiler might optimize it out. I wouldn't expect dmd to do
>>> > that though.
>>> > 
>>> > - Jonathan M Davis
>>> 
>>> So you're saying it will allocate a new dynamic array, initialise
>>> it with 1,2,3,0 and then copy the elements from that new array to
>>> the static one? That's not good...
>>
>> Well, that's what you told it to do semantically. The compiler could
>> theoretically optimize it (and hopefully will eventually), but it would be an
>> optimization. At this point, if you initialize the static array with an array
>> literal, then it will avoid the allocation (though it didn't used to), but
>> AFAIK, it'll still allocate with your example.
>>
>> - Jonathan M Davis
>
> I presume there's a good reason why we don't have:
>   enum a = [1,2,3,4];
>   assert assert(is(typeof(a) == int[4]));
>
> this works after all:
>   enum int[4] a = [1,2,3,4];
>   assert assert(is(typeof(a) == int[4]));

Did you mean static assert and not assert assert or am I missing something?

On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
> On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want to have a string constant it is a lot better to declare it as:
> >
> > static immutable string MY_STRING = "Some string";
> >
> > Because it won't be duplicated?
>
> enum is fine with strings.
>
> It is a common space optimization of the compilers not to duplicate identical strings. The following program includes just one "hello world" in the compiled object file:
>

And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.

On 08/20/2013 12:58 PM, Borislav Kosharov wrote:
> On Tuesday, 20 August 2013 at 19:33:25 UTC, John Colvin wrote:

>>   assert assert(is(typeof(a) == int[4]));
>
> Did you mean static assert and not assert assert or am I missing something?

Yes, he meant static assert. :)

Ali

On Tuesday, August 20, 2013 22:10:28 JS wrote:
> On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
> > On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want
> > 
> > to have a string constant it is a lot better to declare it as:
> > > static immutable string MY_STRING = "Some string";
> > > 
> > > Because it won't be duplicated?
> > 
> > enum is fine with strings.
> > 
> > It is a common space optimization of the compilers not to duplicate identical strings. The following program includes
> 
> > just one "hello world" in the compiled object file:
> And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.

It only works with string literal because they're immutable, and the compiler optimizes for that by only creating them once (it even puts them in the read- only portion of the binary in Linux). The same doesn't hold true for stuff like AAs.

- Jonathan M Davis