Как заставить оптимизацию возвращаемого значения в msvc

Нетрудно сделать так, чтобы ваш код соответствовал стандартам и работал.

Во-первых, оберните массивы T дополнительными дополнительными отступами. Теперь вы знаете макет.

Для владения используйте уникальный ptr вместо необработанного. Если это vapid, оператор T * возвращает его, в противном случае, буфер. Теперь ваш ctor хода по умолчанию работает, как и NRVO, если перемещение не удалось.

Если вы хотите поддерживать не POD-типы, небольшая работа позволит вам поддерживать и ctors, и dtors, а также перемещать элементы массива и бит заполнения для бита.

Результатом будет класс, который не будет вести себя удивительно и не будет создавать ошибки, когда кто-то попытается скопировать или переместить его в первый раз — ну, не первый, это будет легко. Код, как написано, будет взорваться по-разному в разное время!

Соблюдайте правило трех.

Вот явный пример (теперь, когда я отключен от телефона):

template <size_t T, size_t bufSize=sizeof(T)>
struct CBuffer {
typedef T value_type;
CBuffer();

explicit CBuffer(size_t count=1, size_t extra=0) {
reset(count, extra);
}
void resize(size_t count, size_t extra=0) {
size_t amount = sizeof(value_type)*count + extra;
if (amount > bufSize) {
m_heapBuffer.reset( new char[amount] );
} else {
m_heapBuffer.reset();
}
}
explicit operator value_type const* () const {
return get();
}
explicit operator value_type* () {
return get();
}
T* get() {
return reinterpret_cast<value_type*>(getPtr())
}
T const* get() const {
return reinterpret_cast<value_type const*>(getPtr())
}
private:
std::unique_ptr< char[] > m_heapBuffer;
char m_Buffer[bufSize];
char const* getPtr() const {
if (m_heapBuffer)
return m_heapBuffer.get();
return &m_Buffer[0];
}
char* getPtr() {
if (m_heapBuffer)
return m_heapBuffer.get();
return &m_Buffer[0];
}
};

Выше CBuffer поддерживает конструкцию перемещения и назначение перемещения, но не копирует конструкцию или назначение копирования. Это означает, что вы можете вернуть их локальный экземпляр из функции. RVO может произойти, но если этого не произойдет, приведенный выше код все еще безопасен и легален (при условии T это ПОД).

Прежде чем запустить его в производство, я бы добавил T должно быть POD утверждает выше, или обрабатывать не POD T,

В качестве примера использования:

#include <iostream>
size_t fill_buff(size_t len, char* buff) {
char const* src = "This is a string";
size_t needed = strlen(src)+1;
if (len < needed)
return needed;
strcpy( buff, src );
return needed;
}
void test1() {
size_t amt = fill_buff(0,0);
CBuffer<char, 100> strBuf(amt);
fill_buff( amt, strBuf.get() );
std::cout << strBuf.get() << "\n";
}

И для (надеюсь) случая NRVO:

template<size_t n>
CBuffer<char, n> test2() {
CBuffer<char, n> strBuf;
size_t amt = fill_buff(0,0);
strBuf.resize(amt);
fill_buff( amt, strBuf.get() );
return strBuf;
}

который, если происходит NRVO (как и должно быть), не нуждается в перемещении, а если NRVO не происходит, то неявное перемещение, которое происходит, логически эквивалентно не выполнению перемещения.

Дело в том, что NRVO не полагается на четко определенное поведение. Однако NRVO почти наверняка произойдет, и когда это произойдет, он сделает что-то логически эквивалентное выполнению опции move-constructor.

Мне не нужно было писать такой Move-конструктор, потому что unique_ptr является конструируемым в движении, как и массивы внутри structs. Также обратите внимание, что копирование-конструкция заблокирована, потому что unique_ptr не может быть создан с помощью копирования: это соответствует вашим потребностям.

В отладке вполне возможно, что в конечном итоге вы создадите движение-конструкцию. Но в этом не должно быть никакого вреда.