Signed word lengths and indexes

[Andrei Alexandrescu]

Walter Bright wrote:
> bearophile wrote:
>> Walter Bright:
>>
>>>> But I can say that D is already not the best language to develop 
>>>> non-toy
>>>> operating systems.
>>> Why?
>>
>> I have not written an OS yet, so I can't be sure. But from what I have 
>> read
>> and seen D seems designed for different purposes, mostly as a
>> high-performance low-level application language that currently is 
>> programmed
>> in a style that doesn't assume a very efficient GC.
> 
> I'd rephrase that as D supports many different styles. One of those 
> styles is as a "better C".
> 
> 
>> D has many features that are useless or negative if you want to write 
>> code
>> close to the metal as a kernel, as classes, virtual functions, garbage
>> collector, operator overloading, interfaces, exceptions and 
>> try-catch-finally
>> blocks, closures, references, delegates, nested functions and structs, 
>> array
>> concat, built-in associative arrays, monitor, automatic destructors. 
>> When you
>> write code close to the metal you want to know exactly what your code is
>> doing, so all the automatic things or higher level things become 
>> useless or
>> worse, they keep you from seeing what the hardware is actually doing.
> 
> I agree on those points. Those features would not be used when using D 
> as a "better C".
> 
> So, you could ask why not use C++ as a "better C" and eschew the C++ 
> features that cause trouble for kernel dev? The answer is that C++ 
> doesn't offer much over C that does not involve those trouble causing 
> features.
> 
> D, on the other hand, offers substantial and valuable features not 
> available in C or C++ that can be highly useful for kernel dev. Read on.
> 
> 
>> On the other hand current D language (and C and C++) lacks other
>> hard-to-implement features that allow the kernel programmer to give more
>> semantics to the code. So such semantics has to be expressed through 
>> normal
>> coding. Future languages maybe will improve on this, but it will be a 
>> hard
>> work. ATS language tries to improve a bit on this, but it's far from 
>> being
>> good and its syntax is awful.
> 
> I think you are giving zero weight to the D features that assist kernel 
> programming.
> 
> 
>> D also lacks a good number of nonstandard C features that are present 
>> in the
>> "C" compiled by GCC, such low-level features and compilation flags can be
>> quite useful if you write a kernel. Even LDC has a bit of such features.
> 
> A non-standard feature means the language is inadequate. There is 
> nothing at all preventing non-standard features from being added to D 
> for specific tasks. There is no reason to believe it is harder to do 
> that for D than to C.
> 
> As for standard features D has that make it more suitable for low level 
> programming than C is:
> 
> 1. inline assembler as a standard feature
> 2. const/immutable qualifiers
> 3. identification of shared data with the shared type constructor
> 4. enforced function purity
> 5. guaranteed basic type sizes
> 6. arrays that actually work

6.5. arrays that actually work and don't need garbage collection

> 7. scope guard (yes, even without exception handling)


Andrei