- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
template<class T>
class smartest_ptr
{
std::unique_ptr<T> m_p;
std::array<char, sizeof(T)> m_data; // массив размером с объект
public:
void New() {m_p = new(&m_data) T();}
operator ->() {return m_p;}
};
// никакого выделения памяти из кучи!
smartest_ptr<CFoo> pFoo; // типа nullptr
// pFoo->Method(); - нельзя, nullptr
pFoo.New();
pFoo->FooMethod();
pFoo->AnotherMeth();
Follow us!
О мудрейший и могущественнейший из указателей!
разве так можно? У unique_ptr выпили же operator =
P.S. А ведь unique_ptr потом сделает этому буферу delete... И кровь-кишки-распидорасило...
Я подозреваю, что это концепт, который спасёт мир от медленых аллокаций памяти в крестах
- Это же заумный указатель! Ты ничего не понимаешь в крестах, нуб!
На фоне мудрейшего указателя
> smartester_ptr
уникью_птр смотрится как тупой.
Ниже chtulhu написал вариант без std::unique_ptr.
Зачем оно надо?
Какую проблему решает?
Нихера не пойму.
Целый крестофорум наркоманов дни напролёт только тем и занимается что придумывает какие-то замысловатые конструкции ебанутее прежних...
Решение: запилить на стеке место под объект, и отложить инициализацию до вызова New().
наличие свободного времени :)
в нем сочетается одновременно любовь к написанию велосипедов и не умение их писать.
а чем им не угодили rvalue semantics? Это же чистый перфоманс
Для чистого перфоманса исходный объект надо нафиг забывать. А в кривтах исходный объект надо приводить к состоянию, из которого можно безопасно вызвать dtor.
Или есть другие пути?
Это например возврат значения из функции.
Не путать с std::move! std::move разрешается применять к объекту посреди его жизненного цикла, а тот move, про который я думаю - он только для конца жизненного цикла. То есть любой объект в конце жизни должен быть либо уничтожен, либо перемещён.
> Придется какой-то флаг хранить, что черезголова по памяти.
Да, именно это текущая система и предлагает! Любой объект обязан хранить флаг "не занулён ли", в перемещателе я должен занулять флаг, а в деструкторе проверять флаг на зануление.
В моей схеме флаг не нужен. Если объект переместили, то к нему после этого обращаться тупо запрещено, если только не ССЗБ. Это как с ручным вызовом конструктора в нынешней схеме.
По делу мы с тобой вроде всё на крестофоруме обсудили.
predicate
Сначала перемещение его обнулит, а потом он будет уничтожен.
>Да, именно это текущая система и предлагает! Любой объект обязан хранить флаг "не занулён ли", в перемещателе я должен занулять флаг, а в деструкторе проверять флаг на зануление.
При создании объектов хорошим тоном будет предоставить конструктор без параметров, который не будет захватывать ресурс, и методы для инициализации и освобождения ресурсов. В деструкторе, естественно, происходит освобождение, если есть что освобождать. Таким образом, объект обязан хранить информацию о том, захватил ли он ресурс. Хоть флаг, хоть специальное значение(nullptr, -1, INVALID_HANDLE итп)
>Если объект переместили, то к нему после этого обращаться тупо запрещено, если только не ССЗБ.
объект остаётся на месте, а его ресурсы переходят к другому объекту и теперь этот другой отвечает за их освобождение
Так это и есть переголова!
Почему нельзя просто нихера с ним не делать?
> При создании объектов хорошим тоном будет предоставить конструктор без параметров, который не будет захватывать ресурс
А если я хочу блин такой объект, который не может иметь нулевое состояние? То текущая схема не даст мне его создать.
Да и даже если допустить нулевое состояние - то в текущей схеме имеем переголову на то, чтобы занулять объект, а потом проверять, не занулили ли его.
> объект остаётся на месте, а его ресурсы переходят к другому объекту и теперь этот другой отвечает за их освобождение
Я знаю. Если ресурсы объекта перешли другому и сам объект уходит из зоны видимости, то не лучше ли тупо забыть про него?
БАЙТОЁБСТВО
>Почему нельзя просто нихера с ним не делать?
то есть вместо оперции перемещения и деструктора надо запилить операцию перемещения при выходе из фукнции, перемещения с помощью std::move итд?
Вместо того, что разбить сложные операции на примитивы будем реализововать конкретный каждый случай?
Как в твоей схеме будет работать такая ситуация?
>А если я хочу блин такой объект, который не может иметь нулевое состояние? То текущая схема не даст мне его создать.
Такое может иметь смысл, если объект живет на стэке и является чем-то вроде mutex_locker
>Да и даже если допустить нулевое состояние - то в текущей схеме имеем переголову на то, чтобы занулять объект, а потом проверять, не занулили ли его.
Maybe boost::option или наиумнейший указатель из соседнего треда
>Я знаю. Если ресурсы объекта перешли другому и сам объект уходит из зоны видимости, то не лучше ли тупо забыть про него?
Про целостность(как языка, так и объекта) тоже лучше забыть?
Ручной вызов моего move - это операция, которую могут делать лишь те, кто отвечает за последствия, как и ручной вызов конструктора, деструктора итд.
Ничё скоро начнут юзать - за уши не оттянешь. Оно так всегда с достижениями прогресса.
PS
>>не умение их писать
>>не состоятельностью
>>без оговорочно
Простите, но всё это пишется слитно.
Сниму порчу с памяти, верну потерянные указатели, найду забытые деструкторы. Гадание на gdb в присутствии заказчика или по снимку памяти. Дорого.