D as A Better C?
Mike
none at none.com
Tue Feb 11 17:07:03 PST 2014
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> I've toyed with this idea for a while, and wondered what the
> interest there is in something like this.
>
> The idea is to be able to use a subset of D that does not
> require any of druntime or phobos - it can be linked merely
> with the C standard library. To that end, there'd be a compiler
> switch (-betterC) which would enforce the subset.
>
> (First off, I hate the name "better C", any suggestions?)
>
> The subset would disallow use of any features that rely on:
>
> 1. moduleinfo
> 2. exception handling
> 3. gc
> 4. Object
>
> I've used such a subset before when bringing D up on a new
> platform, as the new platform didn't have a working phobos.
>
> What do you think?
I began studying and programming in D primarily to do ARM bare
metal programming in something other than C and C++.
I'm in favor of adding compiler switches like -fno-rtti,
-fno-moduleinfo, -fno-exceptions etc..., but I'm not in favor of
aggregating them under a single name like "-betterC" or "-worseD".
I use GDC with the -fno-emit-moduleinfo switch. In fact, it is
necessary for what I'm trying to do. Right now I have to stub
out the TypeInfo stuff[1] to get things to compile, so a
-fno-rtti switch would be cool, but I still don't understand why
the compiler doesn't just emit whatever TypeInfo stuff I supply,
and nothing if I don't supply it. Discussion here[2]
Automatic Memory Management should be decoupled from the language
as much as possible. Ideally we should just be able to add -lgc,
-larc, -lnone to our linker flags and the language would use a
Garbage Collector, Automatic Reference Counting, or no memory
management respectively. Or something along these lines. I
don't know what the right solution is. Just make it transparent
to the language and an option to the programmer. I realize this
is easier said than done, though.
BOTTOM LINE:
I don't want a better C. I want a better D.
[1]
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/memory-mapped-io/source/object.d
[2]
http://forum.dlang.org/post/jynxfglpulguvqbivrms@forum.dlang.org
Mike
More information about the Digitalmars-d
mailing list