std::any без аллокаций

Как можно исправить вызовы конструкторов?

Вроде во всяких букварях типа от Меерса написано.

А точно нужен именно std::any, а не std::variant? Для высоконагруженного кода variant предпочтительнее, а для всего остального лишние аллокации обычно не так критичны

В лучших традициях int&& != template<typename T = int> T&&: первая — это rvalue-reference, а второе — universal reference.

Опытные ходители по граблям советуют https://stackoverflow.com/questions/7863603/how-to-make-template-rvalue-refer...

P. S. кстати, gcc ругается, что new пытается создать reference type в строке 86, что можно исправить new (...) typename std::remove_reference<T>::type(std::move(value))

Кстати, есть посмотреть на std::any — там тоже только конструктор с универсальной ссылкой. Как бы не было противно, лучше ознакомиться с тем, как это сделано в стандартной библиотеке.

первая — это rvalue-reference, а второе — universal reference.

«Первое — это фрукт, а второе — яблоко»?

A forwarding reference is an rvalue reference …

«Первое — это фрукт, а второе — яблоко»?

Ах если бы все было так просто.

#include <stdio.h>

#define D(type) template<typename T> void foo(type) { puts("tmpl :: " #type); }

D(const T&);
D(T&&);

#define I(type) void bar(type) { puts(#type); }

I(const int&);
I(int&&);

int main()
{
	int x = 5;
	foo(5); // tmpl :: T&&
	foo(x); // tmpl :: T&&
	bar(5); // int&&
	bar(x); // const int&
}

Надо было Страуструпу под universal reference какую-нибудь отдельную закорючку придумать. Например, &&&. :)

Собственно, в обоих случаях проблема в том, что вызывается конструктор template Any(T &&value) вместо template Any(const T &value)

Логично, шаблон с универсальной ссылкой генерит более специализированную версию, которая и вызывается. Нужно либо писать constraint для универсальной версии, либо генерить SFINAE ошибку (если цпп20 нет).

Ну вот я сделал типа такого:

template<typename T> Any(T &&value) noexcept requires std::is_rvalue_reference_v<T> {
	using TT = typename std::decay<T>::type;
	if constexpr (sizeof(TT) > sizeof(m_storage) || alignof(TT) > alignof(std::size_t)) {
		m_heapStorage = new TT(std::forward<T>(value));
	} else {
		new (m_storage) TT(std::forward<T>(value));
	}
	m_operations = &OPERATIONS<T>;
}	

И теперь вместо этого конструктора вызывается copy constructor, даже когда я передаю не Any.

В стандартной библиотеке проще ситуация. У них там any нешаблонный тип. Соответственно, они могут легко написать реализацию конструкции any из any и any из любого другого типа. А мне непонятно как сделав универсальный конструктор различать внутри него экземпляры моего Any (специализированные с разными размерами буферов) и всё остальное.

Нужен минимальный воспроизводимый тест, с указанием ожидаемого результата, мне лениво парсить портянку и разбираться. Но абсолютно точно всё можно решить через constraint’ы.

А мне непонятно как сделав универсальный конструктор различать внутри него экземпляры моего Any (специализированные с разными размерами буферов) и всё остальное.

Отнаследовать Any<> от Any_mark?

Сделал новую версию:

https://pastebin.com/3JyJ7Akq

Работает, но иногда крашится в деструкторе, никак не могу понять почему.

template<typename T> Any(T &&value) noexcept requires std::is_rvalue_reference_v<T>

И такое условие сработает ровно никогда.

Как-то многовато reinterpret_cast на квадратный сантиметр портянки.

Где void*, там и reinterpret_cast.

Как-то многовато reinterpret_cast

И маловато std::launder 🤡

Сделал новую версию:

https://pastebin.com/3JyJ7Akq

std::size_t m_storage[(STORAGE_SIZE + sizeof(std::size_t) - 1) / sizeof(std::size_t)];

🤡

А почему pmr не используешь?

В какое место ты предлагаешь воткнуть pmr?

На 136й строчке, ты вызываешь new, а можно алоцировать из memory_resource. Это иногда более хорошая альтернатива для any чем буфер внутри.

На 136й строчке, ты вызываешь new

Я?!

а можно алоцировать из memory_resource

Так это нужно более общую поддержку аллокаторов пилить, а не pmr.

Это чтобы буфер был выровнен на размер указателя. Так как такое выравнивание подходит большинству объектов.

https://timsong-cpp.github.io/cppwp/n4868/basic.life#1.sentence-4 (https://timsong-cpp.github.io/cppwp/n4868/basic.life#1.5) 🤡

Так это нужно более общую поддержку аллокаторов пилить, а не pmr.

Ну хотя для аллокаторов придётся делать класс шаблонным, а memory_resource этого не треба.

Я?!

Не ты, сорян

Ну да, фишка any как раз ведь а том, чтобы можно было какой нибудь объект без шаблонов передавать. Если уже на шаблонах, то в нем смысла и нет.

может быть в твоем случае вообще лучше использовать concepts? Поскольку там можно смело проверять размер типа на этапе компиляции.