Move Constructor Syntax

Sönke Ludwig sludwig at outerproduct.org
Wed Oct 9 06:46:52 UTC 2024


For what it's worth, I've been in what I assume to be pretty much the 
same situation as Weka, looking for a way to @safely provide stack 
allocated buffers to asynchronous routines. Having this provides a 
considerable opportunity for performance optimization, particularly for 
I/O workloads.

Because there was no such way, I went with a central heap allocation 
scheme instead - it just seemed too unsafe to expose an API like that in 
an open-source library.

To me the big question is: How important is having an actual move 
constructor? Do we have any compelling use cases where it is not 
sufficient to disable moves and fall back to copy/destroy instead? Or is 
this just about C++ compatibility?

Otherwise it would be sufficient to simply introduce a way to prohibit 
moving a type and avoid the pile of complications and implications of 
move constructors (such as the `opOpMove` mentioned by Manu or questions 
w.r.t. always guaranteeing a valid memory address for a struct).


More information about the Digitalmars-d mailing list