Smart pointers instead of GC?
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Tue Feb 4 04:46:57 PST 2014
On Tuesday, 4 February 2014 at 11:57:25 UTC, Paulo Pinto wrote:
> On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:
>> Yeah, I dunno what "systems language" means really.
>
> For me it means you can write an OS with it, even if some tiny
> parts require the use of Assembly glue.
Pretty close to my definition, but I would add:
- you should be able to write a performant OS with it
- you should be able to use all core language features when doing
so
- the mapping to hardware should be obvious
- thus the runtime should be transparent/easy to grasp
Basically I think a system level language should provide a
minimal library and runtime that you can extend to a OS-level
library that you use for implementing all services on your OS.
I think GC+Phobos should be an extension of such a minimal set up.
---
I don't think ARC is needed for D, because I think you use RC
only when needed when writing latency sensitive code and use
primarily other strategies (unique pointers, embedded objects
etc).
I do think that interop with C++ is a good strategy. Language
level support for C++11 pointer types would be a good addition
now that they are being used quite extensively. Interop with C++
is more important than Objective-C.
Having a system library core that is GC free would be nice. I
think this should be done on the name space level. I.e. having
one optimized "core" section that is 100% GC free and one more
extensive "std" section that requires GC to be available.
I don't think it is realistic to have all libraries being non-GC.
It is better to have useful libraries that are somewhat
inefficient than not having them due to complexity issue.
It is better to have a very easy to use and extensible to XML DOM
library than to have a more obfuscated and less extensible XML
DOM library without GC. But the XML parser library should be GC
free.
More information about the Digitalmars-d
mailing list