Optimize my code =)

[Stanislav Blinov]

On Tuesday, 18 February 2014 at 23:36:12 UTC, Robin wrote:

> Another thing which is hopefully a bug in the current language 
> implementation of D is the strange behaviour of the transpose 
> method with the only line of code:
>
> return Matrix(this).transposeAssign();

Matrix(this) not compiling when 'this' is const is a bug. That's 
why I had to replace it with assignment. Postblit still has some 
unresolved problems.

However, you should note that you have a bigger bug in that 
transposeAssign() returns a reference :) So unless transpose() 
returns Matrix (instead of ref Matrix), that's a problem.

> In C++ for example this compiles without any problems and 
> results in correct transposed matrix copies - this works due to 
> the existance of move semantics in C++ and is one of the 
> coolest features since C++11 which increased and simplified 
> codes in many cases enormously for value types just as structs 
> in D.

The fact that it compiles in C++ is a problem (this illustrates 
your initial implementation of transpose() translated into C++):

struct Matrix
{
     // ref Matrix transpose() const;
     S& transpose() const { return 
Matrix(*this).transposeAssign(); }

     // ref Matrix transposeAssign();
     S& transposeAssign() { return *this; }
};

int main(int argc, char** argv)
{
     Matrix m1;
     Matrix& m2 = m1.transpose(); // ooops!
}

> I have ran several tests in order to test when the move assign 
> or the move constructors are called in D and whenever I 
> expected them to be called the copy-constructor or the postblit 
> was called instead which was frustating imo.

I've posted a complete illustration on how D moves rvalues, 
browse this thread back a bit.

> I also gave scoped imports a try and hoped that they were able 
> to reduce my executable file and perhaps increase the 
> performance of my program, none of which was true -> confused. 
> Instead I now have more lines of code and do not see instantly 
> what dependencies the module as itself has. So what is the 
> point in scoped imports?

They don't pollute outer scope with symbols. If you just need to 
call a couple of functions from std.random inside *one* function, 
there's no need to pull names from std.random into the whole 
module.

> The mixin keyword is also nice to have but it feels similar to 
> a dirty C-macro to me where text replacement with lower 
> abstraction (unlike templates) takes place. Of course I am wrong

Yes you are :) It's not dirty and it's certainly not a macro. 
It's a great feature for generating code at compile time. For 
examples just browse through Phobos (e.g. std.functional), or 
take a look at the code in this thread:

http://forum.dlang.org/thread/mailman.158.1391156715.13884.digitalmars-d@puremagic.com

Maybe it's your syntax highlighting that throws you off? Then use 
q{} insead of "" :)

> Another weird thing is that the result ~= text(tabStr, this[r, 
> c]) in the toString method is much slower than the two 
> following lines of code:
>
> result ~= tabStr;
> result ~= to!string(this[r, c]);
>
> Does anybody have an answer to this?

Probably due to extra allocation in text(tabStr, this[r,c]) since 
it will perform ~ under the hood, while appender already has 
storage.