How is D manual memory management any worse than plain C one?
Plenty of language features depend on GC but stuff that is left
can hardly be named "a lousy excuse". It lacks some convenience
and guidelines based on practical experience but it is already as
capable as some of wide-spread solutions for systems programming
(C). In fact I'd be much more afraid of runtime issues when doing
system stuff than GC ones.
On Monday, 7 January 2013 at 15:49:50 UTC, Gor Gyolchanyan wrote:
On Mon, Jan 7, 2013 at 7:25 PM, David Nadlinger
<[email protected]> wrote:
On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan
wrote:
How can I have an associative array, which uses a custom
allocator?
I'm afraid the only viable solution right now is to implement
your own AA
type as a struct with overloaded operators (which is in fact
what the
built-in AAs are lowered to as well).
There are two downside to this, though - besides, of course,
the fact that
you need a custom implementation:
- You cannot pass your type to library functions expecting a
built-in
associative array.
- You lose the convenient literal syntax. This could be fixed
in the
language, though, by providing a rewrite to a variadic
constructor of user
types for array/AA literals, thus eliminating the need for GC
allocations
(gah, another thing I just need to find the time to write up a
DIP for…).
David
This means, that dlang.org is lying. D doesn't provide both a
garbage
collector and manual memory management. It provides a garbage
collector and
a lousy excuse for manual memory management. As much as I love
D for it's
metaprogramming and generative programming, it's not even
remotely fit for
system-level programming the way it claims it is.
I don't mean to be trolling, but it's not the first time I got
grossly
disappointed in D.
