[dmd-internals] Regarding deprecation of volatile statements

Walter Bright walter at digitalmars.com
Wed Aug 1 11:05:40 PDT 2012

On 8/1/2012 10:58 AM, Alex Rønne Petersen wrote:
> On Wed, Aug 1, 2012 at 7:32 PM, Walter Bright <walter at digitalmars.com> wrote:
>> 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.
> C as a language, from a purely standard (and theoretical) standpoint,
> no, definitely not. But C with any sane compiler out there is. And
> right now, this is mostly a matter of practicality than anything else.

I can't seem to emphasize that there ARE C compilers that do not implement your 
notion of volatile, and there ARE issues with C compilers behaving differently 
on this, and no, they are not insane.

>> 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.
> I'd actually be interested to know if such architectures are in active
> use today... the only 16-bit architecture I can think of that's still
> in use is MSP430, but that has char = 8 bits.

There are some DSP chips with 32 bit ints that are in active use with C, this 
was discussed on comp.lang.c++.moderated a couple years back.

AFAIK, there is not a single standard conforming C++ compiler for 16 bits other 
than DMC++. And I can tell you for a fact that you'll have to turn off exception 
handling, RTTI, and not use STL if you want to get a useful program out of it. 
(Standard conforming does not imply useful!)

More information about the dmd-internals mailing list