Re: What's the point of static arrays ?

2020-07-10 Thread psycha0s via Digitalmars-d-learn

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

2020-07-10 Thread psycha0s via Digitalmars-d-learn
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

2020-07-09 Thread psycha0s via Digitalmars-d-learn
I just didn't expect that the address of a "this" reference may 
change.


Unexpected copy constructor behavior

2020-07-09 Thread psycha0s via Digitalmars-d-learn
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




Re: What's the point of static arrays ?

2020-07-09 Thread psycha0s via Digitalmars-d-learn

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

2020-07-01 Thread psycha0s via Digitalmars-d-learn

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

2019-02-13 Thread psycha0s via Digitalmars-d-learn

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

2019-02-10 Thread psycha0s via Digitalmars-d-learn

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

2019-02-10 Thread psycha0s via Digitalmars-d-learn
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.