manual memory management

[mist]

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 
> <see at klickverbot.at> 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.