Ликбез по передаче параметров по значению в конструкторы и сеттеры (современный C++, примеры)

Не могли бы вы привести пример

выразится в измеримых секундах

Ну, всё же не во всех, а только там, где используется. К тому же практика показывает, что в конечном варианте код, как правило, в инлайне. Т.е. явно выраженного конструктора "верхнего" объекта в виде обособленной функции вообще нет. К тому же шаблон вовсе не обязывает использовать его для множества разных типов и случаев. Он всего лишь скрывает детали. Если итоговая функция в конечном итоге вызовется дважды или даже единожды для одного-двух типов аргументов — даже там проще инкапсулировать их в шаблоне, чем приводить подробности этих самых типов.

По поводу копирования/перемещения — простая иллюстрация:

struct train_c
{
    int m_x = 0;

    train_c(int x) : m_x (x) { std::cout << "\n-CTR train_c(x) " << m_x << " " << this; }

    train_c(train_c&& c) : m_x(c.m_x) { c.m_x = 0; std::cout << "\n-MOVE train ctr "
    << m_x << " " << this << " from " << c.m_x << " " << &c;}

    // ... copy c-tr, copy and move assignment, etc...
    ~train_c() { std::cout << "\n-DTR train " << m_x << " " << this; m_x = 0;}
};

struct helper_c
{
    int pad = 0; // just to distinquish this from &m_h
    train_c m_h;

    template <typename TRAIN_C>
    helper_c ( TRAIN_C&& c ): m_h { std::forward<TRAIN_C> ( c ) }
    {
        std::cout << "\nHELPER_TT " << this << " from " << &c << " " << &m_h << " " << m_h.m_x;
    }
    // ...
    ~helper_c() { std::cout << "\n~HELPER " << this; }
};

template <typename TRAIN_C>
helper_c* make_helper ( TRAIN_C&& c )
{
    std::cout << "\n====>  called make_helper with " << &c;
    return new helper_c ( std::forward<TRAIN_C>(c) );
}

helper_c* make_helper_byval( train_c c )
{
    std::cout << "\n====>  called make_helper_byval with " << &c;
    return new helper_c( std::move( c ));
}

TEST ( functions, trainer )
{
    std::cout << "\n\n==>  indirect ctr";
    auto fee = make_helper (11);
    std::cout << "\n==>  made fee " << fee->m_h.m_x;
    delete fee;
}

TEST ( functions, trainer_by_val )
{
    std::cout << "\n\n==>  indirect ctr";
    auto fee = make_helper_byval( 11 );
    std::cout << "\n==>  made fee " << fee->m_h.m_x;
    delete fee;
}

Запускаем. Получаем:

[ RUN      ] functions.trainer

==>  indirect ctr
====>  called make_helper with 0x7ffcb3a44b6c
-CTR train_c(x) 11 0x5623c3404e44
HELPER_TT 0x5623c3404e40 from 0x7ffcb3a44b6c 0x5623c3404e44 11
==>  made fee 11
~HELPER 0x5623c3404e40
-DTR train 11 0x5623c3404e44

[ RUN      ] functions.trainer_by_val

==>  indirect ctr
-CTR train_c(x) 11 0x7ffcb3a44b6c
====>  called make_helper_byval with 0x7ffcb3a44b6c
-MOVE train ctr 11 0x5623c3404e44 from 0 0x7ffcb3a44b6c
HELPER_TT 0x5623c3404e40 from 0x7ffcb3a44b6c 0x5623c3404e44 11
-DTR train 0 0x7ffcb3a44b6c
==>  made fee 11
~HELPER 0x5623c3404e40
-DTR train 11 0x5623c3404e44

Собственно, в варианте с шаблоном видим вызов конструктора и деструктора. Всё! PF + RVO полностью избавляют и от копирования, и от перемещения. Внутрь до самой сути пробрасывается исходный int.
А в варианте с передачей по значению RVO таки не избавляет от + move ctr + dtr, покуда всё равно конструируется и перемещается временный объект.

И вот ещё про "кучу кода во всех единицах"...

// head.h
#include <bits/move.h>

struct train_c
{
    int m_x = 0;

    template<typename INT>
    train_c ( INT && param )
            : m_x ( param ) {}
};

struct helper_c
{
    int pad = 0;
    train_c m_h;

    template<typename TRAIN_C>
    helper_c ( TRAIN_C && c ): m_h {std::forward<TRAIN_C> ( c )}
    {
    }
};

//foo.cpp
#include "head.h"

int ret42 ()
{
    return 42;
}

//bar.cpp
#include "head.h"

int ret42 ()
{
    return helper_c ( 42 ).m_h.m_x;
}

Смотрим выхлоп от g++ -S foo.cpp (где должна "напородиться куча кода"). Файл целиком:

    .file   "foo.cpp"
    .text
    .globl  _Z5ret42v
    .type   _Z5ret42v, @function
_Z5ret42v:
.LFB19:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $42, %eax
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE19:
    .size   _Z5ret42v, .-_Z5ret42v
    .ident  "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
    .section    .note.GNU-stack,"",@progbits

Не видим вообще упоминаний; что, в общем-то, очевидно.
В случае вызова с оптимизацией О2 g++ -O2 -S bar.cpp результат аналогичен для обоих файлов (кроме имён самих файлов)

    .file   "bar.cpp"
    .text
    .p2align 4,,15
    .globl  _Z5ret42v
    .type   _Z5ret42v, @function
_Z5ret42v:
.LFB19:
    .cfi_startproc
    movl    $42, %eax
    ret
    .cfi_endproc
.LFE19:
    .size   _Z5ret42v, .-_Z5ret42v
    .ident  "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0"
    .section    .note.GNU-stack,"",@progbits

Т.е. ровно одна значимая команда (кроме ret). Что тоже достаточно очевидно.

Ээээ… А вы почему так решили???

В данном контексте цену перемещения нужно измерять не саму по себе, а по отношению к копированию. И для коротких строк перемещение оказывается таким же как и копия. А следовательно, метод "передача по значению + move" оказывается примерно вдвое дороже, чем "передача по константной ссылке + копия", например.

Перемещение такой строки — это семь инструкций процессора вместо четырёх для «пустого буфера» того же размера.

Потому что в С++ явно специфицировано, что если привязать временный объект к ссылке на const в стеке, то жизнь временного объекта будет продлена. Теперь он будет жить столько, сколько живет константная ссылка на него. В приведенном примере все валидно, время жизни s заканчивается с закрывающей фигурной скобкой.

Это все относится только к объектам в стеке. На члены класса это не действует.