On Tue, Oct 2, 2018 at 2:20 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 9/29/2018 9:34 PM, 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! >_< > > > The rationale behind D allowing structs to be moveable is to enable a copying > garbage collector.
Do we do that? What's the use of that? Does the opPostMove() concept not work here? If the GC wanted to move something, it can call it like any other code? > Some solutions to this problem: > > 1. Don't allow moving of C++ structs std::string, std::vector, etc are quite impotent without move semantics. I'm pretty sure the first time I ever started using those containers was around 2015 when we became secure we could use C++11 in our code (supported by all compiler vendors). Before that, they were banned and we had alternative solutions. > 2. Add a struct attribute that means "not moveable" They must be movable though. > 3. DIP 1014, which is add a __move_post_blit() function (most complex > solution) It's alleged you're working through the DIP... what's the story there? Are you unhappy with it? > 4. Use copy/destruct for C++ structs that have copy constructors (this is the > old C++ solution, and is less efficient than the move constructor) If that's where we land on this, I'll struggle to find value in my work. Containers become as impotent as back before 2011 :/ > Pragmatically, I suggest for the moment just ignore the problem, file a bug > report for std::string, and move on. But dangling pointer is an instant crash/memory corruption... it's a pretty bad 'bug'.
