Griboks, я просил ответ который соответствует всем требованиям. Ваш ответ приводит к фрагментации данных при их удалении, стек не походит я уже указал это - доступ случайный, вы просили ТЗ, поэтому были даны конкретные случаи (вектор, флоат, дабл, примеры фрагментации с типами int8/16/32_t, вектор как место, куда будет помещен аллокатор). Проблему я объяснил четко - мне нужно иметь память со случайным доступом не в теории, а в реальности, в ней не должна быть избыточность, в ней не должно быть медленных способов дефрагментации, в ней надо уметь хранить типы с разным size_t, причем перемешивая их в том числе (в результате неупорядоченного сохранения разных типов). Вы никак не ответили на мой вопрос. Даже на мое конкретное ТЗ с вектором, вектором как место для аллокатора, флоат и дабл. Ничего. Вообще.
Griboks, вы просили конкретный код. С конкретным числом типов, с конкретными размерами. Не важно сколько типов и с каким размером будет создано и положено в вектор, если аллокатор способен работать с разными размерами. Я сказал, что решение проблемы У решит проблему Х, потому что мне нужны идеи для реализации (а в данном случае работа аллокатора через size_t). От вас я пока получил ответ: стек, который не поддерживает случайный доступ (а программа разве вся стек???), незначащие биты (от которых я просил меня избавить еще в вопросе), "задайте другой вопрос, а не этот".
Griboks, зациклился, потому что эти void хранить, когда в них можно хранить еще float - значительная потеря, особенно если такие случаи будут повторятся
Griboks, потому что по определению double имеет длину в 2 раза больше float, float занимает 32бита.
Я привел пример. Но не с реальным кодом. Нет реального кода, потому что аллокатор еще не написал ответам выше.
Если уж совсем конкретно нужно, то - создайте аллокатор на основе аллокатора вектора, чтобы запись vector(float, double) стала верной, если он знает какие ячейки относятся к float, а какие к double.
Griboks, я не говорю о типах с незначащами нулями, я привел конкретный пример - float и double, float берет 32бита, double берет 64бита, это разные объемы
Griboks, это гипотетическая ситуация, когда на ЯП написано цикл каста, где идет рост данных например uint8_t, следущий цикл идет преобразование всех данных в uint16_t, следущий цикл в uint32_t и т.д.. Но при этом доступ к данным не прекращается для остальных потоков (данные для них обновятся только после каста). Допустим у нас был вектор с float и int, то такие преобразования для float нельзя применить, потому что float перемешен с int в 1 области памяти, можно доисать в конец буффер с кастом, но остается вопрос о float которые в результате каста уже не должны быть использованы, потому что есть double
Griboks, он бесконечный, потому что это цикл программы. А есть буффер или нет вряд ли повлияет на память программы на наличие дефрагментации. Меня интересует как я могу ее провести. Просто добавить буффер в конце и убрать ссылки на данные, которые были использованы для цикла, так себе идея. Образовавшеяся пространство может не соответствовать буфферу.
Griboks, у меня нет компиляции, как и число типов не ограничено (но описывается size_t). Меня интересует как удалять так, чтобы пустое пространство могло полностью уйти на новые данные. Потому что мой ЯП не может вечно выделять для себя память, особенно для циклов с преобразованием типов при случайном доступе (при условии, что данные не удалаются, а дозаписываются).
Griboks, variant имеет size_t для double, вектор с float x, y с таким типом может хранить 4 float, но хранит только 2 (чуствуете потерю в 2 раза?). Я не прошу литературу с непрерывной записью данных, а прошу литературу аллокацию данных, когда они разного объема.
Вектор уже использует аллокатор, но хранить он может только 1 тип, мне нужно чтобы была конструкция типа std::vector(float, double) вместо std::vector(std::variant(float, double)). Надеюсь это сделает мой вопрос более понятным. Треугольные скобки не отражались коррекно, заменил на круглые.
Griboks, я не сказал, чтобы было непрерывно в вопросе, я спросил как эффективно хранить информацию, чтобы не возникали пустоты и ненужная информация.
Про пример пустот я привел varian/union, которые имеют один размер но в целом создают повторяющиеся "дыры" которые нельзя убрать.
Если у вас есть литература, где описаны аллокаторы, которые хранят блоки разной длинны и при этом очень эффективно в плане дефрагментации и доступа к данным, то укажите их, пожалуйста.
Griboks, вы где видели программу, данные которой не удаляются? А по поводу данных... ну например float в double, но float лежит не в конце, так что его удалить нельзя, так что делать? хранить мусорный float? Это если без переполнения
virtual void execute(std::vector* argumentspointer, uint64_t* errorcodepointer, bool forced) = 0;
у obj1
возникает
error C2893: Сбой при специализации функции-шаблона "unknown-type std::invoke(_Callable &&,_Ty1 &&,_Types2 &&...) noexcept()"
message : Со следующими аргументами шаблона:
message : "_Callable=void (__cdecl functionfactory::basicfunction::* )(std::vector> *,uint64_t *,bool)"
message : "_Ty1=std::vector> *"
message : "_Types2={uint64_t *, bool}"
error C2780: unknown-type std::invoke(_Callable &&) noexcept(): требует аргументов: 1, имеется: 4