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.digitalmar...@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.
