On 27.04.2011 20:21, Ulrik Mikaelsson wrote:
2011/4/26 Timon Gehr<[email protected]>:
But you understand why it is deprecated for GC memory?
The main thing to note is that the semantics of C++ 'new' and D 'new' are rather
different.
D 'new' performs allocation on the GC heap by default. The only sane overloads
of
'new' would therefore allocate the object on a custom GC heap, which you never
want to do. So there is absolutely no way to overload the 'new' operator
meaningfully inside the D language. The argument for removing 'delete'
overloading
is trivial after taking that into consideration.
You can still create custom allocators by the means of template functions. (I do
not think this is optimal though because they duplicate code that needn't be)
They
feel a little bit less natural though, which is not a problem, since in D,
custom
allocators and manual memory management in general, _are_ less natural.
One thing that is perhaps obvious, but eludes me; when dropping the
delete-operator, are there any obvious reason to not also drop the
"new" keyword? ("new" is a fairly good method/variable name, if
nothing else)
I could see two possible alternatives:
Global (and defined-by-default) template new!(Type): (as suggested
elsewhere in this thread by so)
This is very close to the current situation, but makes it possible
to use as a method-name, and clearly states there's nothing "magic"
about it.
Explicit Allocator, such as GC.new!(Type).
Would have the benefit of clearly showing who did the allocation,
and would map nicely to other allocators. (Malloc.new/free!(T)!(T)).
It would also allow library-methods that might allocate instances,
take an allocator as an optional template argument. I.E.
auto obj = dict.createObject("key");
OR
auto obj = dict.createObject!(Malloc)("key");
scope(exit) Malloc.free(obj);
Possibly an obvious bad idea, but I haven't seen it discussed?
Regards
/ Ulrik
I presonally think of new in D as a shortcut for yours would be
GC.new!T(...). It's the same thing as with 'foreach' and such, i.e. used
often enough to deserve a keyword.
As for your suggestion, I see some problems with it:
- yours Malloc and GC artifacts already have asymmetry, imagine generic
code. Also there is stack-like allocators e.g. new David Simcha's TempAlloc
- there is an awful lot of operations which allocate GC memory
implicitly aka arr1 ~ arr2, so it's not like you can pass the allocator
and prevent the function from allocating _somewhere_ else
- I still fail to see how passing allocator would allow the function to
decide on whether it's GC-like allocation or not, i.e. manual memory
management implies the certain way function does its job (more generally
the whole program, framework, module etc. it's not something decided at
single call point)
--
Dmitry Olshansky
