June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer wrote:
> I'd say this deserves a blog post but it would be too short.
Actually i wouldn't mind a vlog or some short presentations on a variety of subjects. Maybe even continuations of presentations that could have been at the Dlang conference except weren't due to time constraints.
|
June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | On Tuesday, 6 June 2017 at 08:00:11 UTC, Era Scarecrow wrote:
> On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer wrote:
>> I'd say this deserves a blog post but it would be too short.
>
> Actually i wouldn't mind a vlog or some short presentations on a variety of subjects. Maybe even continuations of presentations that could have been at the Dlang conference except weren't due to time constraints.
I could post a video about a simple ctfe transcompiler.
or
sqlite-d.
I have to wait until my computer is fixed though.
|
June 07, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
> On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
>> I would not have expected enum b = sort(a) to trigger an allocation. auto b, yes, of course (and the disassembly from that is not much different). So I'd love to see a blog post explaining it.
>
> I don't think I can do a full-on blog post, but I can answer it in a couple sentences: `enum` is treated by the compiler just like literals. Array literals allocate at each usage point, therefore enum arrays allocate at each usage point. (*each* usage point)
I think the allocation is because sort returns a SortedRange, not an array.
So even this allocates:
enum b = a.sort;
writeln(b[1]);
OTOH, this doesn't allocate:
enum b = a.sort.array;
writeln(b[1]);
|
June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yuxuan Shui | On 6/6/17 8:28 PM, Yuxuan Shui wrote: > On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote: >> On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote: >>> I would not have expected enum b = sort(a) to trigger an allocation. >>> auto b, yes, of course (and the disassembly from that is not much >>> different). So I'd love to see a blog post explaining it. >> >> I don't think I can do a full-on blog post, but I can answer it in a >> couple sentences: `enum` is treated by the compiler just like >> literals. Array literals allocate at each usage point, therefore enum >> arrays allocate at each usage point. (*each* usage point) > > I think the allocation is because sort returns a SortedRange, not an array. > > So even this allocates: > > enum b = a.sort; > writeln(b[1]); > > OTOH, this doesn't allocate: > > enum b = a.sort.array; > writeln(b[1]); I think it's because the compiler isn't smart enough to pull out the allocation for SortedRange!(...)([0,1,2,3,4])[1], but it is smart enough to know that [0,1,2,3,4][1] does not need to allocate. But it is pretty well known that enum'ing an array can have it allocate wherever it is used. For example, if you do this: enum b = a.sort.array; auto c = b; It will allocate. If you do: auto d = b; It will allocate again. That is an interesting artifact though. Another good reason to use static. -Steve |
June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 06/06/2017 06:09 PM, Steven Schveighoffer wrote: > But it is pretty well known that enum'ing an array can have it allocate > wherever it is used. One of the most effective examples is comparing .ptr with (seemingly) itself: void main() { enum e = [ 1 ]; static assert(e.ptr != e.ptr); assert(e.ptr != e.ptr); } Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :) Ali |
June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On 06/06/2017 08:06 PM, Ali Çehreli wrote: > enum e = [ 1 ]; > static assert(e.ptr != e.ptr); > I'm surprised that e.ptr is usable at compile time. Sorry to notice this late but printing that ptr exposes the copy-paste behavior of enums: pragma(msg, e.ptr); Outputs &[1][0] That makes sense. It's still interesting that static assert accepts that address comparison. I guess it knows that the result is always false. Ali |
June 07, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Wednesday, 7 June 2017 at 03:06:34 UTC, Ali Çehreli wrote:
> On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
>
> > But it is pretty well known that enum'ing an array can have
> it allocate
> > wherever it is used.
>
> One of the most effective examples is comparing .ptr with (seemingly) itself:
>
> void main() {
> enum e = [ 1 ];
> static assert(e.ptr != e.ptr);
> assert(e.ptr != e.ptr);
> }
>
> Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :)
>
> Ali
A bit OT, but how about this one?
struct Tree {
struct Node {
Node* left, right;
}
Node* root = new Node;
}
void main() {
Tree tree1, tree2;
assert(tree1.root);
assert(tree2.root);
assert(tree1.root != tree2.root); // fails
}
Not `static`, not `enum`, but `new` at compile time and `root` is of course statically initialized :)
|
June 06, 2017 Re: C++17 cannot beat D surely | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On 6/6/2017 8:06 PM, Ali Çehreli wrote:
> On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
>
> > But it is pretty well known that enum'ing an array can have it allocate
> > wherever it is used.
>
> One of the most effective examples is comparing .ptr with (seemingly) itself:
>
> void main() {
> enum e = [ 1 ];
> static assert(e.ptr != e.ptr);
> assert(e.ptr != e.ptr);
> }
>
> Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :)
One trouble with making them the same is if one of the users of e changes an element. Do the rest of the users see the change or the original?
|
Copyright © 1999-2021 by the D Language Foundation