Geek of the week

Tim Matthews tim.matthews7 at gmail.com
Mon Oct 12 03:21:07 PDT 2009


bearophile wrote:

> Just a note:
>> What are the application areas that D targets? WB: In short, any application that would otherwise use C or C++ would be suitable for D.<
> 
> That may become true in future, but it can't be true now. If I buy an Arduino, or a little 16 bit CPU that has to go inside a cheap microwave oven, I usually have to program it in C, Forth (or worse). I can't use D for that. Currently D is not fit for the world of small real-time CPUs. And embedded CPUs are very common, for every desktop (and handheld) CPU produced, 10 or 100 small CPUs for embedded purposes are produced.
> 
> But there are possible ways to make D fitter for those purposes. For example it may be designed a "lightD", a subset of D (that has no built-in AAs, that uses no GC, etc), and adds several tricks/constructs useful when your available RAM is 1200 bytes long and your available ROM (well, flash, or a different slower kind of RAM) is 30000 bytes. In such situations a compiler is even asked to produce not just the faster or shorter binary, but sometimes even the less energy consuming one! (think about a -Oe compilation flag, beside the -O and the -Os). Or maybe D will never fit for such purposes. 
> 

I wouldn't want the language to be too different though. Maybe a subset 
runtime (with gc off by default) + std lib though (subset of existing 
and not really a third choice of library). Call just about anything in 
tango and you get an allocation, no explicit delete and an assumption 
that the GC will take care of it eventually.

Aswell as the embedded, regular operating systems are a big area of 
C/C++. This should be an easier fit for D but all D kernel/os projects 
have probably been abandoned.



More information about the Digitalmars-d mailing list