Если перемычку - то да, придеться страдать. С другой стороны, это значит что разводите на 1м слое? Сделайте перемычку 2м слоем и не будет rat-патча.

Уже дошли в треде до соглашения о вызовах ARM ABI/EABI 😁

По своей сути, по умолчанию на архитектуре арм используется модель, похожая на тот же fastcall (если говорим за си). Первые четыре параметра, если их размерность машинное слово и меньше - через r0-r3, остальное через стек.

Если решишь передать 64 битные параметры, например, для AArch32 будут использованы пары r0-r1, r2-3, остальное через стек. И так далее.

Советую почитать за ABI/EABI.  У Арма очень все приятно описано, вплоть до требований выравнивания стека при работе в режиме исключений

Т.е.  при всем желании, начать передачу параметров через стек ранее третьего параметра не получится 😊

Я слегка пропустил тему.
В чем необходимость передачи аргументов именно через стек?

Строго говоря пока в этом интереса не было, но потенциально при передаче переменного числа параметров, без каких либо контейнеров

👌

Про VA_arg похоже время тоже почитать 😉


Или ты их и называешь контейнерами?

Леонид, но Вы же не пропустили мой ответ выше, да? 😊

Какой именно? Про контейнер?

Возможно невнимательно перечитал

Перечитал ещё раз и да. Контейнер сбил меня с толку

Про три параметра, только после которых можно вообще говорить о стеке.

Чуваки я тут выложил репозиторий для пулаОбьектов. Хотя это не совсем классический пуллОбьектов. скорее пулл памяти для объектов ну или специализированная куча под определенный тип объекта.
Может кому то пригодиться: https://github.com/KoynovStas/pool

💪👍

в чем отличие от https://www.etlcpp.com/pool.html ?

эмм щас, пару дней назад писал чуваку который ревью делал секунду

Отличия от ETL

В ETL пулл написан для 03 плюсов из-за чего многие фишки писались руками,
но зато можно юзать в легаси, этот пулл юзает C++17.
Например мы юзаем aligned_storage и можем выбрать любой Align, тогда как в ETL
опять велосипедим. Правда если алигн больше стандартного(нужен new align),
может потребоваться доп флаг для компилятора (TODO: добавить в API)
ETL пул занимает ~1000 строк в сумме. наш ~1500, НО у нас
не один пул, а 7.
У нас хидер онли (ну такое, но всеже) для ETL пула, придется тощить почти процентов 40 всего ETL.
Мне не нравиться в ETL вот этот момент: https://github.com/ETLCPP/etl/blob/master/include/etl/ipool.h#L344
это техника размазывания инициализации при каждом создании обьекта.
У нас инициализация в конструкторе.
В ETL используется односвязный список это наш аналог: SPool_list
В нашем пуле есть как статические пулы, так и динамические (которые используют кучу)
Есть поддержка итераторов для некоторых алгоритмов (можем заюзать for-range - мелочь, а приятно)
Есть возможность в динамическом пуле фиксировать capacity, что позволяет писать код без лишних if-ов
ограничив верхний предел, но при этом увеличивать размер через reserve
Есть возможность включить/выключить исключения std:bad_alloc для методов create/reserve
частая фигня если в эмбедете юзаем (-fno-exceptions)
И мы даем базовую гарантию при исключениях в конструкторе обьекта, в ETL такой гарантии нет.

Для тестов советую еще посмотреть на https://github.com/catchorg/Catch2 Мне прям понравилась :)

да я свое поделие юзаю. там ничего особенного. у нас на работе много проектов на пиках и старых компиляторах от микрочипа. там stest 500 строк прям ништяк заходят.

вот это все очень полезно добавить в документацию в репозиторий.
а aligned_storage разве не deprecated?