"Jacob Carlborg" <d...@me.com> wrote in message news:jh63p2$17li$1...@digitalmars.com... > On 2012-02-11 15:36, Nick Sabalausky wrote: >> "Era Scarecrow"<rtcv...@yahoo.com> wrote in message >> news:jzavmzbmjoyujhqyf...@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.
