[dmd-internals] Regarding deprecation of volatile statements

Walter Bright walter at digitalmars.com
Wed Aug 1 10:32:22 PDT 2012


On 8/1/2012 9:52 AM, Alex Rønne Petersen wrote:
> On Wed, Aug 1, 2012 at 6:46 PM, Walter Bright <walter at digitalmars.com> wrote:
>> On 7/31/2012 10:02 AM, Alex Rønne Petersen wrote:
>>>
>>> Not so. It would make it worse (read: less portable and less
>>> performant) than writing C.
>>>
>> I think this is a bit unfair - the C semantics you're talking about are
>> specific to one compiler. They are not standard, and such has been a source
>> of non-portable trouble in the C community.
> Strictly speaking, yes, you can only rely on GCC implementing the GCC
> semantics. But in practice, LLVM/Clang does too (since they want to be
> a GCC drop-in replacement). I'd expect other compilers in the wild to
> also follow this definition since GCC is the major compiler in the
> Unix world.

While you're right, I am just taking exception to your stance on C being better 
for this because it has a guarantee, because it has no guarantee, and that lack 
of a guarantee has indeed caused many problems. It is not irrelevant.


>
> But writing kernel space code in purely standard C is a pipe dream.
> I've always liked to think of D as a more pragmatic version of C/C++
> that recognizes that supporting obscure platforms from 40 years ago
> might not be so important anymore.
>

There's a bit of irony in that. C++ purports to support 16 bit platforms, and 
many C++ proponents will point this out. But, in practice, it cannot. The same 
goes for the silliness about C++ supporting any character encoding - it cannot 
support Radix50 encoding. And worse for the C silliness that it supports 32 bit 
'char' sizes (yes, there are such CPUs). I don't know of single, supposedly 
standard-conforming non-trivial C app that will work if chars are 32 bits in size.


More information about the dmd-internals mailing list