Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

From: Walter Bright <boost@digitalmars.com>
Date: Sep 7, 2007, 19:03 UTC
Message-ID: <fbs79k$tac$1@sea.gmane.org>
In-Reply-To: <20070907094120.GA27754@artemis.corp>

Pierre Habouzit wrote:

Show 8 quoted lines

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

Show 10 quoted lines

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

Show 7 quoted lines

> 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++