Re: What's the point of static arrays ?
On Friday, 10 July 2020 at 10:13:23 UTC, wjoe wrote: However stack memory needs to be allocated at program start. I don't see a huge benefit in allocation speed vs. heap pre-allocation, or is there? I mean 1 allocation vs 2 isn't going to noticeably improve overall performance. Allocation on the stack is basically just a single processor instruction that moves the stack pointer (well, ofc you also need to initialize array elements). Meanwhile, allocation on the heap involves much more complex logic of the memory allocator. Moreover, in D dynamic arrays use GC, thus the memory allocation may involve the trash collection step.
Re: Unexpected copy constructor behavior
On Thursday, 9 July 2020 at 22:18:59 UTC, Steven Schveighoffer wrote: Looking at the generated AST, it's because the compiler is adding an auto-generated opAssign, which accepts a Foo by value. It is that object that is being created and destroyed. Is there a reason the autogenerated opAssign accepts its argument by value? Honestly, it looks like a premature pessimisation to me.
Re: Unexpected copy constructor behavior
I just didn't expect that the address of a "this" reference may change.
Unexpected copy constructor behavior
I was learning copy constructors and got a really weird result. It looks like a copy constructor and a destuctor of two unknown objects are called. Could somebody please explain it to me? import std.stdio; struct Foo { int value; this(int n) { value = n; writeln("constuctor ", &this); } ~this() { writeln("destuctor ", &this); } this(ref return scope Foo other) { value = other.value; writeln("copy constuctor ", &this); } } void main() { writeln("begin"); auto foo1 = Foo(1); auto foo2 = foo1; writeln("---"); foo2 = foo1; writeln("==="); writeln("end"); } The output: begin constuctor A3D3EFF860 copy constuctor A3D3EFF864 --- copy constuctor A3D3EFF880 // <-- destuctor A3D3EFF808 // <-- === end destuctor A3D3EFF864 destuctor A3D3EFF860
Re: What's the point of static arrays ?
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote: Also GC but it's possible to make a dynamic array implementation which avoids the GC. It's easy to make a dynamic array without using the GC. Did you mean "implementation which avoids memory management"? I'm not considering supposed performance benefits/penalties because these need to be profiled. Considering the many downsides why would I ever want to choose a static over a dynamic array ? Sometimes the amount of elements is known at compile time so you don't need to waste CPU cycles for memory allocation/freeing. This can be really important when you work on a performance-critical code.
Re: Why is this allowed
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote: Why does such code compile? I don't think this should be permitted, because it's easy to make a mistake (when you wanted foo[index] but forgot the []). If someone wants to assign a value to every element they could do foo[] = 5; instead which is explicit. Totally agree. In most of cases implicit actions lead to errors. Even if they have a specific use case and really convenient.
Re: Best practices of using const
On Wednesday, 13 February 2019 at 11:32:46 UTC, envoid wrote: Is there an article that explains best practices of using const in D? You can find some information here: https://dlang.org/articles/const-faq.html
Re: A predicate with different argument types
auto sorted = object_.assumeSorted!((a, b) => a.name < b.name); Sorry for the copy-paste. It should be "attributes" in place of "object_" here, of course: auto sorted = attributes.assumeSorted!((a, b) => a.name < b.name);
A predicate with different argument types
Is it possible to make a comparison predicate with different argument types? For instance, suppose I have a struct like this: struct Attribute { string name; variant value; } Also, suppose I have a sorted vector of such values. So I can quickly find one by its name field and I have index-based random access to elements at the same time. Therefore I have something like this: Attribute[] attributes; Now, imagine I try to find an insertion position for a new element: string name; // input data auto sorted = object_.assumeSorted!((a, b) => a.name < b.name); Attribute dummy; dummy.name = name; auto pos = sorted.lowerBound(dummy); It works fine but is there a way to get rid of the 'dummy' object? I can easily achieve that in C++ since STL allows to have a predicate with different argument types. Ideally, I'd like something like this: string name; // input data auto sorted = object_.assumeSorted!((a, b) => a.name < name); auto pos = sorted.lowerBound(name); Thanks.