DIP 1014

RazvanN razvan.nitu1305 at gmail.com
Tue Jul 2 07:48:06 UTC 2019


On Tuesday, 2 July 2019 at 05:32:07 UTC, Tremor wrote:
> On Sunday, 30 September 2018 at 04:34:20 UTC, Manu wrote:
>> Who knows about DIP 1014? (struct move hook)
>> Is it well received? Is it likely to be accepted soon?
>>
>> I'm working on the std::string binding, it's almost 
>> finished... but
>> then I hit a brick wall.
>> GNU's std::string implementation stores an interior pointer!
>> >_<
>>
>> No other implementation does this. It's a really bad 
>> implementation actually, quite inefficient. It could make 
>> better use of its space for small-strings if it wasn't wasting 
>> 8-bytes for an interior pointer to a small string buffer...
>>
>> Anyway, I'm blocked until this DIP is accepted; so, is it 
>> looking promising?
>
> Is any update for this ?
>
> DIP1014 is fatal for implement safe ref count,  I don't trust a 
> language call them self system language without safe ref count.
>
> This is also a major block for implement GNU CPP std::string, 
> cpp ABI compatible is  another import goal for D.
>
> I just with I has the skill to work on this,  If nobody has no 
> time to work on this. maybe some one can give a guide about how 
> to implement this ?
>
> like the step to do:
>
> step 1:  example to add some build in id for opPostMove
>
> step 2: which part code to modify to hook opPostMove with 
> rvalue or lvalue move
>
> step 3: how to glue it with DMD and LDC backend to generate asm 
> code.
>
> Maybe there should be a new thread to talk about this.
>
> The github user thewilsonator is like a hero to me, maybe when 
> he get free time can take a look for this.

After implementing the copy constructor as a substitute for the 
postblit, we realized that the fundamental flaw that the postblit 
had (automatic copying) would also manifest in the case of 
opPostMove; in Shachars' there is no mention what happens when 
the source and destination are differently qualified. I suspect 
that before implementing the DIP we need to sort this out and it 
might be preferable to imlement a move constructor a la C++ 
rather then rely on automatic moving.


More information about the Digitalmars-d mailing list