Про boilerplate

Нет, нельзя.

boilerplate это же код повторямый без изменений в разных местах. В чем boilerplate работы с памятью в Си? Т.к. там нет штатного менеджера памяти, тебе буквально надо думать куда вставить free инструкцию, а куда нет. Общего шаблона нет, если ты не напишешь свой собственный менеджер. Так что нет, это не boilerplate.

Но если ты в начале каждой функции делаешь malloc для каждой локальной переменной, а в конце для них всех free, то да, это уже boilerplate.

Вопрос серьёзный, не тральный.

Конечно серьёзный. ~80% сишного кода - это работа с памятью.

Любая программа на С выполняет функции менеджера памяти. Редким имключением являются программы, способные отазаться от выделения heap-памяти.

В чем boilerplate работы с памятью в Си?

В том, что это не относится к реализации т.н. «бизнес-логики».

является boilerplate-кодом

смотря что под этим понимается

То есть весь риал-тайм код :)

В том, что это не относится к «бизнес-логике».

Если ты стремишься выпилить все не связанное с бизнес логикой, то выбор С как технологии для твоего проекта выглядит мягко говоря неразумным.

Ну и да, boilerplate это повторяемые секции кода, а не «не относящиеся к бизнес логике».

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

В чем boilerplate работы с памятью в Си?

В том, что это не относится к реализации т.н. «бизнес-логики».

Это простая терминологическая путаница. «Бизнес-логика» - это задача, решаемая ПО в рамках ТЗ. Если по ТЗ требуется корректная обработка сценария, когда система не может предоставить дополнительную оперативную память, и под корректным понимается дальнейшая штатная работа ПО, а не «аварийное» завершение с сегфолтом по нуллпоинтер икспешену, то вызовы malloc и free решают именно эту «бизнес»-задачу.

Если же по ТЗ всем совершенно насрать, что там будет с программой, если память «кончится», то не надо использовать Си надо использовать аллокатор памяти и проаутсорсить нехватку памяти его рантайму.

Конечно. Всю эту тупую работу можно поручить компилятору, который справится с ней намного лучше.

Кококо.

Кококо

Про автоматическое управление памятью петушок конечно не слышал?

Интересно, а можно ли сказать, что операция сложения двух чисел (которая может встречаться в огромном количестве мест) является boilerplate-кодом?

Операция сложения иденпотентна и компилятор заменит операцию константой.

Можно, конечно. Руками выдели, руками освободи, каждый раз, одинаково.

Нетривиальное управление памятью это одна из причин выбрать для написания программы именно C, а не на какой-то другой язык с автоматическим управлением памятью. Про бойлерплейт интересное мнение в треде. Всегда считал что этим словом называется использование избыточного для решения задачи кода, что так часто бывает при использовании обобщенных библиотек и фреймворков. Т.е. то что впустую греет процессор. А копипаста это другое

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

~80% сишного кода - это работа с памятью.

Открою для тебя секрет, что 100% любого кода на всех языках - это в том или ином случае работа с памятью.

исключением являются программы, способные отазаться от выделения heap-памяти

Для микроконтроллеров это скорее правило, чем исключение.

пример boiler-plate кода с realloc можно?

мне нравится описание роберта мартина. он выделяет «круги» архитектуры. внутри суть программы, то без чего приложение перестанет делать то, для чего прездназначено (суть приложения не меняется с течением его жизни, иначе это будет уже другое приложение, предназначенное для чего-то другого). следующий круг, это тоже бизнес логика, но уже менее связанная с сутью, ее можно поменять или убрать ,при этом приложение будет выполнять свою основную функцию. последним кругом идет реализация интферйсов и прочее (непосредственное создание файлов, чтение сокетов..), так называемый грязый код. с помощью инверсии зависимостей делается так, чтоыб внешнии круги зависили от внутрениих, а не наоборот.

с такой позиции код управления памятью будет в одном из кругов (на своем месте). тут важно чтобы бизнес логика приложения не зависила от способа управления памятью, а способ управления памятью как раз должен зависить от бизнес логики (например какая-то утилита может спокойно память за собой не подчищать, полагаяь на то, что чтобы выполнить функцию памяти хватит).

а вобще в любом коде на любом языке будет какой-то код, который не связан непосредственно с реализумой функцией, а связан с како-йто технической стороной. тем не менее такой код не обходим (если говорить конкретнее, то на си программист обязан как-то памятью управлять, так как предложенного решения нет). исключения могут составлять, разве что, dsl с каким-то очень узким доменом.

Да, если ты каждый раз всё выделяешь и инициализируешь руками.

Нет, если ты написал для этого функцию.