Pierre Habouzit wrote:
Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.
I'm surprised this is such an important issue. Others have mentioned it,
but regard it as a minor thing. Interestingly, the htod program (which
converts C .h files to D import files) will convert bit fields to inline
functions, giving equivalent functionality.
The other second issue I have, is that there is no way to do:
import (C) "foo.h"
And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).
D does come with htod, which converts C .h files to D files. It's not
possible to do a perfect job (because of macros), but it comes pretty
darned close. The reason htod gets so close is because it is actually a
real C compiler front end, not a perl or regex string processing hack.
Because it (may) require a little hand tweaking of the results (again,
because C headers may include awful things like:
#define BEGIN {
#define print printf(
), it's a separate program rather than built-in.
I also have a third, but non critical issue, I absolutely don't like
phobos :)
You're not the only one <g>. But I'll add that access to the standard C
runtime library *is* a part of D, so at some level it can't be worse
than C. There's also another runtime library available, Tango, which is
very popular.
Though I'm obviously free to chose another library. D has
definitely many many many real advances over C (like the .init, .size,
... and so on fields, known types, and whatever portability nightmare
the C impose us). In fact I like to use D like I code in C, using
modules and functions, and very few classes, as few as I can. And even
(under- ?) using D like this, it is a real pleasure to work with. I'm
really eager to see gdc be more stable.
There are a lot of people hard at work on D to make it more stable and
increase the breadth and depth of tools available. I am fully aware that
there may be non-technical issues to using D in a project like git, like
availability of other D programmers, tradition, etc., but in this thread
I'm concerned mainly with technical issues.
P.S. I'm also NOT suggesting that git be converted to D. Translating a
working, debugged, 80,000 line codebase from one language to another is
usually a fool's errand.
Thanks for taking the time to post your thoughts.
-----------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
