Nick Sabalausky a at a.a
Sat Feb 11 08:23:13 PST 2012

"Jacob Carlborg" <doob at me.com> wrote in message 
news:jh63p2$17li$1 at digitalmars.com...
> On 2012-02-11 15:36, Nick Sabalausky wrote:
>> "Era Scarecrow"<rtcvb32 at yahoo.com>  wrote in message
>> news:jzavmzbmjoyujhqyfvhp at dfeed.kimsufi.thecybershadow.net...
>>>>> What are your thoughts?
>>>> There is no way you get a D application into 64K. The language is not
>>>> powerful enough. Only C can achieve that.
>>> I'll need to agree. Porting D to a smaller memory space and with cramped
>>> features in all of this is not going to be good no matter how you look 
>>> at
>>> it. I'm sure it's similar to comparing using perl in something with only
>>> 64k of memory, one must ask where you can put the interpreter, decoding
>>> and working with the source text, and many other things, not to mention
>>> even if you pulled it off, the speed penalty.
>>> With only 64k, you aren't going to need anything extremely complex or
>>> elaborate.
>>> You MIGHT get away with exporting D code to using C symbols, but you'll
>>> likely be stuck working with structs, no library support, no heap, no
>>> memory management, and fixed-sized arrays. I doubt you'd need templates,
>>> or any of the higher functions. All structures and types must be basic 
>>> or
>>> known statically at compile time. Unlikely for lambdas to be used, and a
>>> score of other features.
>>> This is all just speculation, but I think you get the picture. If you 
>>> make
>>> a subset of D, it would most likely be named Mini-D. But at that point
>>> you've got an enhanced C without going C++.
>> That would *still* be a very notable improvement over C. Hell, if you ask
>> me, a proper module system alone is one of the killer features of D over 
>> C.
>> Header files? Seriously? Fuck that shit. What the hell is this, 1970? And
>> then there's other things that are *at the very least* icing on the cake:
>> Faster compilation, slicing, better safety, metaprogramming (esp CTFE) 
>> that
>> whups C's ass and makes it much less less tempting to do things at 
>> runtime
>> that don't need to be done at runtime. That's all just off the top of my
>> head.
> I think slicing is quite difficult without a GC. Not the actual slicing 
> but freeing the memory.

Those are orthogonal concerns. Just because you're taking a slice doesn't 
mean you aren't still using the rest. And if you're not using the rest, then 
the problem just reduces to the classic old "GC vs manual" issue.

More information about the Digitalmars-d mailing list