Eliminate class allocators and deallocators?
Ary Borenszweig
ary at esperanto.org.ar
Wed Oct 7 22:45:29 PDT 2009
Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> Sean Kelly wrote:
>>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
>>>> article
>>>>> dsimcha wrote:
>>>>>> == Quote from Andrei Alexandrescu
>>>>>> (SeeWebsiteForEmail at erdani.org)'s article
>>>>>>> It is a bad idea because distinguishing between release of
>>>>>>> (expensive)
>>>>>>> resources from dangerous memory recycling is the correct way to
>>>>>>> obtain
>>>>>>> deterministic resource management within the confines of safety.
>>>>>> This is based on two faulty assumptions:
>>>>>>
>>>>>> 1. Memory is cheap. (Not if you are working with absurd amounts
>>>>>> of data).
>>>>>> 2. Garbage collection is never a major bottleneck. (Sometimes
>>>>>> it's a worthwhile
>>>>>> tradeoff to add a few manual delete statements to code and
>>>>>> sacrifice some safety
>>>>>> for making the GC run less often.)
>>>>> malloc.
>>>>
>>>> So for placement construction of a class, I guess it would look
>>>> something like:
>>>>
>>>> auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
>>>> x.__ctor( a, b, c ); // construct
>>>> ...
>>>> x.__dtor();
>>>> free( cast(void*) x );
>>>>
>>>> Is that right?
>>>
>>> Yes, I think so, but I haven't checked all the details. For example
>>> I'm not sure whether __ctor copies .init over the memory before
>>> running the user-defined constructor, or expects that to have been
>>> done already.
>>
>> Apparently it doesn't:
>> http://www.digitalmars.com/techtips/class_objects.html
>>
>> See, it's even documented.
>>
>> Anyway, does your statement mean that _ctor is officially supported
>> (by all conform D compilers)?
>>
>> Because, quoting from the page above:
>> "This technique goes "under the hood" of how D works, and as such it
>> is not guaranteed to work with every D compiler. In particular, how
>> the constructors and destructors are called is not necessarilly
>> portable."
>
> That technique will be used by a library function.
So... the library will be related somehow to the implementing compiler?
More information about the Digitalmars-d
mailing list