On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sjölen <jsjo...@openjdk.org> wrote:

> Hi,
> 
> I'd like to propose that rvalue references and move semantics are now 
> considered permitted in the style guide. This change would allow for move 
> constructors to be written. This enables more performant code, if the move 
> ctr is less expensive than the copy ctr, but also more correct code. For the 
> latter part, look at "8314571: GrowableArray should move its old data and not 
> copy it". Here we can avoid using copy assignment, instead using move 
> constructors, which more accurately reflects what is happening: The old 
> elements are in fact moved, and not copied.
> 
> Two useful std functions will become available to us with this change:
> 
> 1. `std::move`, for explicitly moving a value. This is a slightly more 
> powerful `static_cast<T&&>(T)`, in that it also handles `T&` corectly.
> 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect 
> forwarding is a technique where in copying is minimized. To quote Scott 
> Meyers ( 
> https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/
>  ):
> 
>> Perfecting forwarding is an important C++0x technique built atop rvalue 
>> references.  It allows move semantics to be automatically applied, even when 
>> the source and the destination of a move are separated by intervening 
>> function calls.  Common examples include constructors and setter functions 
>> that forward arguments they receive to the data members of the class they 
>> are initializing or setting, as well as standard library functions like 
>> make_shared, which “perfect-forwards” its arguments to the class constructor 
>> of whatever object the to-be-created shared_ptr is to point to. 
> 
> Looking forward to your feedback, thank you.
> Johan

Thanks for the info. I appreciate the effort that it takes to dig up the details
on all these tool sets. If we could come up with tests of our classes that rely
on newer C++ features such that the tests are good enough to catch underlying
C++ errors, then I would be happier with those. Thanks for considering the
feedback.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1706923282

Reply via email to