On Wed, Aug 1, 2012 at 7:32 PM, Walter Bright <[email protected]> wrote: > > On 8/1/2012 9:52 AM, Alex Rønne Petersen wrote: >> >> On Wed, Aug 1, 2012 at 6:46 PM, Walter Bright <[email protected]> >> 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. And exactly because this is a matter of practicality, I'd rewrite my C code in D the moment we solve this problem, be it with intrinsics or a volatile statement, or a volatile storage class, or whatever. :) > > > >> >> 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. 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. Regards, Alex _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
