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