Upgrade: address warnings -- pessimizing-move
Oh this is an interesting one... GCC now highlights situations with `-Wpessimizing-move`, where an overly zealous developer attempts to optimise by `std::move`, which however prevents the compiler from applying the ''Return Value Optimisation'' The latter is mandatory since C++17, and essentially means that a value object created within a function and then returned (by value) will actually be created directly in the target location, possibly eliding a whole chain of delegating value returns. Thus: if we write `std::move(value)`, we change the returned type into an RValue reference, and thereby ''force the compiler'' to invoke a move-ctor....
This commit is contained in:
parent
6c627d83dc
commit
2ff28236f6
6 changed files with 7 additions and 8 deletions
|
|
@ -150,8 +150,7 @@ namespace lib {
|
|||
static iterator
|
||||
build (IterSource& sourceImpl)
|
||||
{
|
||||
return std::move(
|
||||
startIteration (DataHandle{&sourceImpl, &detach_without_destroy}));
|
||||
return startIteration (DataHandle{&sourceImpl, &detach_without_destroy});
|
||||
}
|
||||
|
||||
/** build an iterator frontend, thereby managing
|
||||
|
|
@ -163,8 +162,7 @@ namespace lib {
|
|||
static iterator
|
||||
build (IterSource* sourceImplObject)
|
||||
{
|
||||
return std::move(
|
||||
startIteration (DataHandle{sourceImplObject, &destroy_managed_source}));
|
||||
return startIteration (DataHandle{sourceImplObject, &destroy_managed_source});
|
||||
}
|
||||
|
||||
static iterator EMPTY_SOURCE;
|
||||
|
|
|
|||
|
|
@ -491,6 +491,7 @@ namespace interact {
|
|||
|
||||
class LocationClause;
|
||||
|
||||
/** @remark the result of this builder is retrieved by creating an `UICoord(builder)` */
|
||||
class UICoord::Builder
|
||||
: util::MoveOnly
|
||||
{
|
||||
|
|
|
|||
|
|
@ -277,7 +277,7 @@ namespace interact {
|
|||
// append ID of the new element to be created
|
||||
// unless it's already there (and thus exists)
|
||||
resolver.append (elementTypeID);
|
||||
return move (resolver);
|
||||
return move (resolver); //////////////////////////////////////////////////////////////////TICKET #1402 : need a better solution for the builder-terminal-op. (it collides with the templated UICoord ctor)
|
||||
// use the first suitable solution and exit
|
||||
}
|
||||
else
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ namespace interact {
|
|||
: LocatorSpec{
|
||||
LocationRule{
|
||||
LocationClause{
|
||||
UICoord{std::move (simpleLocationSpec)}}}}
|
||||
UICoord{std::move (simpleLocationSpec)}}}} //////////////////////////////////////////////TICKET #1402 : how to go from Builder to UICoord? DSL design vs. constructor ambiguity
|
||||
{ }
|
||||
|
||||
operator string() const
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ namespace model {
|
|||
{
|
||||
UICoord::Builder targetLocation{destination.rebuild()};
|
||||
performAccessTo (targetLocation, limitCreation);
|
||||
return targetLocation;
|
||||
return targetLocation; ////////////////////////////////////////////////////////////////////////////////TICKET #1402 : ambiguities related to the terminal Builder-operation and the UICoord constructors
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ namespace test {
|
|||
cout << "--> Testgroup=" << optparser->getTestgroup() << endl;
|
||||
cout << "--> Test-ID =" << (isnil(testID)? "--missing--" : testID ) << endl;
|
||||
cout << "--> remaining=" << args << endl;
|
||||
return std::move (optparser);
|
||||
return optparser;
|
||||
}
|
||||
|
||||
void noOptions() { doIt (""); }
|
||||
|
|
|
|||
Loading…
Reference in a new issue