27-Mar-2013 19:34, Vidar Wahlberg пишет:
I know I'm probably going to upset some people with this, bashing their
favourite child and all, but I wanted to let you know the experience
I've had with D so far, as a novice D coder with a heavy Java & light
C++ background.
It's not that I dislike D, in fact there are tons of things I love about
it, it's pretty much exactly what I'm looking for in a programming
language at the moment. Yet, I encounter some frustrating issues when
coding, often leaving me with the impression that I'm fighting the
language more than the problem I'm trying to solve.
True, there are many things I don't know about D, compilers or the inner
workings of a computer, and some of the fights I have with the language
are likely started by myself because I'm dragging along my bias from
other languages, drawing misconceptions on how the D language actually
works.
My intentions are not to insult, but shed some light on some of the
difficulties I've faced (and how I solved them), with the hope that it
will help others from facing the same difficulties.
Woes:
-----
- I find myself in a world of pain when I want to share data more
complex than the basic data types (int, char, byte, etc) across threads.
Seemingly the magic trick is to "cast(shared) foo" (or
"cast(immutable)") when passing objects/references to another thread,
then "cast(Foo)" back on the receiving end (as most classes/structs in
the standard library refuse to let you call any methods when the object
is shared). The examples in the source and TDPL are fairly limited on
the issue, it mostly covers only those basic data types.
- While the "auto"-keyword often is great, it can lead to difficulties,
especially when used as the return type of a function, such as "auto
foo() { return bar; }". Sometimes you may wish to store the result of a
function/method call as a global variable/class member, but when the
function/method returns "auto" it's not apparent what the data type may
be. While you may be able to find out what "bar" is by digging in the
source code, it can still be difficult to find. One example is to save
the result of "std.regex.match()" as a member in a class. For me the
solution was to "import std.traits", create a function "auto
matchText(string text) { return match(text, myRegex); }" and define the
class member as "ReturnType!matchText matchResult;" (do also note that
function & member must come in the right order for this to compile).
Currently documentation for match states in plain text that:
" ...
Returns:
a RegexMatch object holding engine state after first match.
"
Where RegexMatch is a template to be found in the the same module. I can
see that docs are nothing stellar but the key info is present.
That being said I see no problem with ReturnType!xyz, typeof(smth) or
just typing auto.
This was all but obvious to a novice D coder as myself, the solution was
suggested to me in the IRC channel.
Gotchas:
--------
- The lack of "rectangular" arrays created at runtime in D ("int i = 5;
int[i][i] foo;") can be quite confusing for programmers with Java or C++
background.
The code you suggested doesn't work in both C and Java.
Even though there exists alternatives
(http://denis-sh.github.com/phobos-additions/unstd.multidimensionalarray.html),
this design decision and how to get around it when you really desire a
"rectangular" array could be explained in more detail at
http://dlang.org/arrays.html.
IRC you can get jagged arrays with the syntax:
int[][] arr = new int[][](x,y);
- Compiling where DMD can't find all modules cause a rather cryptic
error message. A solution is to make sure you specify all source files
when compiling.
Linker... there are many ways to improve on that old technology that but
not much have been done. And the problem is not D specific.
There is a tool rdmd that tracks all dependencies:
rdmd main_module.d
That plus:
rdmd --build-only main_module.d
Is more then enough in 90% of cases for me.
Wishlist:
---------
- "void[T]" associative array (i.e. a "set") would be nice, can be
achieved with "byte[0][T]".
We need a better set anyway as hash-map is a good map but suboptimal as
a set.
--
Dmitry Olshansky
