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
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.
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);
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: 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: 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()
{
writeln("destuctor ", );
}
this(ref return scope Foo other)
{
value = other.value;
writeln("copy constuctor ", );
}
}
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
