Comments 24
Для того, чтобы сделать это, можно передавать пользователю ссылку на массив данных, а не на саму структуру вектора. Н
Это делают стандартные функции malloc,calloc, realloc.
У Вас в чем отличие?
test.c не тянет на тест. Он должен начинаться с cvec_new(int, 0); .
Незачёт!
==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x719f53220020 at pc 0x757f54f4d4e2 bp 0x7fffd63f9840 sp 0x7fffd63f9000
WRITE of size 4 at 0x719f53220020 thread T0
#0 0x757f54f4d4e1 in memcpy (/opt/compiler-explorer/gcc-15.1.0/lib64/libasan.so.8+0x11f4e1)
#1 0x000000401d38 in __cvec_push /app/example.c:115
#2 0x000000401357 in main /app/example.c:51
Ну я тут за пару часов чего то накодил (ц) Умвр (ц)
https://godbolt.org/z/qv755j1fb
vec[0] = 20;
vec[9] = 0;
vec[5] = 40;
cvec(int) vec1 = cvec_new(int, 1);
vec1=cvec_copy(int,vec[9]);==1==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 20 byte(s) in 1 object(s) allocated from:
#0 0x7a0a3703fd8b in malloc (/opt/compiler-explorer/gcc-15.1.0/lib64/libasan.so.8+0x121d8b) (BuildId: f3722c88f6a9d6f23162523d828eaae8bffb1fff)
#1 0x00000040189c in __cvec_new /app/example.c:90
#2 0x000000401549 in main /app/example.c:57
#3 0x7a0a36629d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
SUMMARY: AddressSanitizer: 20 byte(s) leaked in 1 allocation(s).вот еще, хотя я не до конца понял как копи копирует, думал доку посмотреть а её не было на тот момент когда смотрел
Отдалённым аналогом AUR для DEB-дистрибутивов и RPM-дистрибутивов может служить Open Build Service. Сам пользуюсь несколько лет
Спасибо, обязательно посмотрю, что это
https://mpr.makedeb.org/ для deb.
capacity никогда не меняется и странно взаимодействует с size. Непохоже, что перераспределение памяти может работать
Не помню уже почему, давно было, но realloc лучше не использовать
Да и я бы как forward структурку объявил, а хэдер и вовсе незачем пользователю библиотеки видеть, как и прямой доступ к данным тоже незачем, а функции можно привести к виду this_call и все смещения хранить в заголовке, а не указывать каждый раз
В общем это моё мнение, на истину не претендую
советую учиться у крутейших на сегодня это покачто GNOME открываете их либу и там лучшая реализация покачто, так как Гном отвечает последним пискам моды по десктопу(там много штук, которые просто по последним пискам работают, сомневаюсь что такая мощ сериализации сокрыта в КДЕ) не просто так Майкрософт смотрят в сторону Гном )
так вы показали пример со встроенным типом данных, хорошо бы если бы это были кастомные типы данных и тут на реддите когда я знакомился около 2-3 советов как делать
Очень похоже на попытку реализовать обычный динамический массив, но как-то не до конца...
Неочевидна стратегия расширения массива (сколько памяти выделяется когда емкость исчерпана и пытаемся добавить новый элемент?). Не видно итераторов. Не видно интерфейсов обращения к произвольному элементу массива...
Если это делалось специально под конкретную задачу, то хорошо бы описать что именно за задача, какие требования и сценарии использования всего этого.
Все вроде понятно, но какую функцию выполняет здесь поле magic у структуры cvec-header? И почему в функции __cvec_new ему присваивается значение 'CEVC'?
Если в __cvec_push произойдёт вызов __cvec_realloc, то ptr может стать невалидным, что сломает дальнейшее использование этого вектора.
Норм контейнер. Позабавил и ЯП. Видна Рука Маэстро:
KaKaLang - KaKaшковый яп
kaka.py херхз
(с) https://tvoygit.ru/vi_is_lonely/kakalang:)))
Стоит всё таки упомянуть другие реализации, которые я рассматривал. Вот их список:
Все эти реализации имеют один или более перечисленных ниже недостатков:
Макросы-функции. <...>
Определение вектора как структуры. <...>
Приятно, конечно, увидеть свой проект в списке, но увы, здесь написана неправда. В моей библиотеке никогда не было ни того, ни другого. Начинал я при этом тоже с динамического массива, и тоже писал статью на Хабре по итогам: https://habr.com/ru/articles/324210/. Она даже по структуре похожа на Вашу. :)
А так - плюс за старания! Правда, только если это не плод стараний очередной нейросети.
Действительно, я слишком обобщил вашу библиотеку. Стоило сказать про неё, что она просто вынуждает писать boilerplate. Хотя у вас библиотека действительно очень "сишная").
Действительно, я слишком обобщил вашу библиотеку. Стоило сказать про неё, что она просто вынуждает писать boilerplate.
В каком месте?
Хотя у вас библиотека действительно очень "сишная").
В этом и была цель. Так-то на макросах можно любой стриптиз станцевать (например: metalang99), вот только чаще всего это означает, что для задачи был неверно выбран язык. Никогда не следует выходить за пределы заданной языковой парадигмы, это в принципе невозможно сделать грамотно.
Я аж в маны полез, думал, что у меня старческий маразм начинается. А, нет, это просто ошибка в реализация функции __cvec_realloc(). Она у вас реаллоцирует на тот же размер памяти.
Ну и после реаллокации легко получить невалидный указатель. Вы бы хоть его передавали как __cvec_push(&ptr, ...), чтобы внутри можно было изменить.
std::vector в C?