D as A Better C?

Manu turkeyman at gmail.com
Tue Feb 11 19:28:46 PST 2014


On 12 February 2014 12:11, Manu <turkeyman at gmail.com> wrote:

> On 12 February 2014 05:43, Walter Bright <newshound2 at digitalmars.com>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?)
>>
>
> D-- ;)
>
> 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?
>>
>
> It's only of interest to me in the sense that D might be able to
> infiltrate existing C codebases. And in practical reality, I just don't see
> that happening regardless.
> Most C codebases I have come in contact with are still C codebases because
> they require access to an immense number of target platforms/compilers, and
> D-- would never be able to integrate with all those targets, which means
> use of D-- alongside C would interfere with the portability of the original
> code.
>
> Personally, I don't want D--, I want D.
> I may use D-- on a microprocessor or something, it could find a good home
> there. But wouldn't it be better to just focus on the ability for D to
> link-strip any code relating to those features you list above if it turns
> out that they aren't referenced at all by the app? D should be able to
> properly eliminate everything that's not actually used by the app.
> I guess the flag is still useful to catch errors where a user attempting
> to avoid those items hits one by mistake.
>

I've changed my mind. Depending on a functional link-stripper sucks.
I think it's definitely useful, although I think it should be implemented
as a suite of flags, not just a single one. Sure, a convenience flag can be
offered, but as an implementation detail, it should be a suite of flags.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140212/f9f9159b/attachment.html>


More information about the Digitalmars-d mailing list