Проект на чистом Си

Подпишусь, пожалуй. Иногда сам думаю о таком же :)

З.Ы. Вангую, что щас тебе расскажут про Rust и «не нужно».

Я бы сел писать что-то системное на C99. Драйвер там какой, или просто баги в ядре пофиксить. Эт было бы полезно.

или просто баги в ядре пофиксить.
ПРОСТО

Ага, только сначала надо изучить и понять как ядро работает, изучить и понять данную подсистему, понять что хотел сказать автор и как пофиксить баг, чтобы работало. ЭТО ЖЕ ТАК ПРОСТО. ппц 0\

пакетные менеджеры, линтеры

make для сборки, man для доки и вперед.

Полный минимализм, а иначе зачем тебе C?

https://www.oreilly.com/library/view/21st-century-c/9781491904428/
https://www.amazon.com/Modern-C-Jens-Gustedt/dp/1617295817

В любом случае, будешь таскать с собой (g)libc и переизобретать некоторую часть стандартных фич C++ по ходу написания. Вопрос: зачем? Бери сразу плюсы и пиши на них как на си, если на столько упорыш. Со временем все равно поймешь, что C++2b удобней и будешь писать по-новому, а не по-старому.

Маловато информации сообщил(или я не понял). Что это будет за проект? Приложение? Библиотека? Насколько большой проект? Или ты еще не решил какой проект это будет и тебе нужны варианты?

Я не большой специалист, но по описанию звучит так, что скорей всего тебе хватит c11/gnu11 с Makefile (для начала). Новых книг по С не так много, по диагонали можно полистать, что-то может пригодится:

Effective C (позиционировалась как для начинающих)
21st Century C
Extreme C

И да, скорей всего этот регистрант прав, но сам я не осилил С++. Слишком умно для меня.

man для доки

man для документации – это худшее, что можно придумать. man – это справочник, когда ты УЖЕ знаешь, что тебе нужно, просто уточняешь синтаксис.

Попробуй какой-нибудь курс на udemy по языку с новыми стандартами сразу. На много легче для понимания, чем книги Страуструпа. Если не лезть в дебри, плюсы очень красивый и простой ЯП.

Я имел в виду, что это было бы полезно в отличие от какого-то проекта, нужного самому автору и только.

Какой стандарт сейчас считается «правильным» для использования и какую литературку/доку по нему почитать? Буду благодарен, если покидаетесь статьями или книгами.

cppreference.com

это еще полезно иногда читать:

https://wiki.sei.cmu.edu/confluence/display/c/

Ну там пакетные менеджеры (а они вообще есть?)

Nix можно использовать как пакетный менеджер/сборщик.

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

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

Ну вообще всё сильно зависит от того, какой проект, есть ли GUI, есть ли сеть и др.

Но я бы для начала заложился на стандарт C99 (чтобы собираться на любом утюге и при этом не быть вынужденным писать int вместо bool например), а в качестве системы сборки взял бы meson/muon.

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

Тогда уж лучше перевести deadbeef на Gtk4.

Meson нынче в каждом утюге?

Не лучше. Зачем что-то там переписывать если можно написать с нуля без всякого легаси.

как проекты на Си принято начинать в 2024

так

А не тролль ли ты? Даже аватар подходящий.

Вопрос - как проекты на Си принято начинать в 2024?

int main(int argc, char **argv) {
}

Ну там пакетные менеджеры (а они вообще есть?),

Пакетный менеджер это часть ОС, например в дебиане это apt+dpkg.

линтеры и прочее счастье.

Обычно не используется.

Какой стандарт сейчас считается «правильным» для использования

Обычно тот который дефолтный у gcc без аргументов.

Либо тот который тебе больше нравится, я использую gcc -std=c89 обычно (не путать с ISO C89 - это другое, хоть и похоже).

и какую литературку/доку по нему почитать?

Никакую. Если писал значит и так всё знаешь.

Пишешь в блокноте, потом gcc superproga.c, иначе киркоров

Принято не начинать. Пишут на нём только остановившиеся в развитии деды, соответственно и тулинга нормального не появляется. В случае пакетных менеджеров это и хорошо (нужно использовать системные пакеты), в остальном есть разве что форматтеры кода (uncrustify), санитайзеры и кланговсикие -W. В своей убогости язык вплотную приблизился к динамическим язычкам, когда ошибки обнаруживаются только в рантайме.

Если тег вещества не просто так, то упарываешьмя следующим образом. Содаёшь мегахрущ. Одна структура со всем, что может понадобиться программе, инициируется в начале. Далее ни единого выделения памяти, ни единого указателя

ни единого выделения памяти, ни единого указателя

ни единого разрыва

c11, meson, ubsan

всё то же самое, что в 1990 году, только без old-style деклараций. Я для проектов на Си зачастую даже makefile не пишу т.к на 1-2 файла можно запустить сразу компилятор

meson

может ещё scons какой-нибудь или autotools предложишь?

scons и autotools сломаны и устарели. А meson или cmake даже для hello world из одного файла строго обязательны. Потому что даже прожжённые любители напердоливать руками мейкфайлы эти мейкфайлы писать не умеют, и обязательно или CC= вместо CC?= напишут, или DESTDIR не поддержат, или дефолтную цель забудут, или несовместимых аргуметнов для install напихают. А уж то что майкфайл не будет совместим с bsd’шным мейком - это к бабке не ходи. Потому что цель - выставить на показ свою псевдоуникальность, а не сделать продукт которым можно и удобно пользоваться. Только по этой причине, например, можно предлагать «запустить сразу компилятор».

cmake ничем не лучше и по сути уже является большим функциональным языком чем хаскелль. Поэтому как всегда выбор только из двух стуьев.

можно и не таскать glibc:
https://hub.mos.ru/mittorn/http-folder-uploader/-/blob/master/nolibc.h

ладно ещё cmake, он везде поддерживается и де-факто уже считается стандартом.
Но месон то тут каким боком? И почему это autotools и scons сломаны, а meson нет? Он ведь изначально сломан...

Если не лезть в дебри, плюсы очень красивый и простой ЯП.

Ну так то и сову рисовать пара пустяков - раз кружок, два кружок, ну и там детали.

как проекты на Си принято начинать в 2024

Точно так же как в 2014, в 2004, в 1994 и в 1984. Ты сам решаешь как, исходя из твоего личного опыта. Поэтому в остальном и буду рассказывать про мой опыт в Си. :)

Ну там пакетные менеджеры (а они вообще есть?),

Есть. Одним нравится vcpkg, другим conan. Я попробовал оба, мне оба не нравятся, это всё какой-то Windows way. Проще полагаться на зависимости из репозиториев своего Linux дистрибутива, то что не опакечено опакетить или таскать в git submodule.

линтеры

Хороший набор из строгих -Werror к компилятору (опционально отключаемых, мало ли, что сломают в очередном релизе GCC/Clang?). Ещё clang-tidy рекомендую, есть интеграция для него в Qt Creator. У статических анализаторов немало false positive, но это не значит что ими нельзя пользоваться, просто скорее в фоновом режиме.

прочее счастье

Для меня счастье началось как я перестал пользоваться генераторами мейк-/ниндзяфайлов.

Какой стандарт сейчас считается «правильным» для использования и какую литературку/доку по нему почитать?

Хорошо бы определиться со своей целевой аудиторией. Можно писать по фану на Си под множество платформ, в том числе устаревших. Можно писать вообще исключительно под GNU/Linux, и намеренно не замечать существования других, не то что платформ и компиляторов, а даже libc как например musl и bionic.

существование musl просто не замечать, ведь он никак не представляется препроцессору

или DESTDIR не поддержат

несовместимых аргуметнов для install напихают

cmake

Я напомню, что CMake без специального прописывания install(…) не будет добавлять соответствующую цель. И среди CMake лапши я примерно одинаково часто вижу либо отсутствие install цели, либо прописанные нестандартные пути. Это как по мне не сильно отличается от прописывания ручками install в мейкфайле, хотя ладно, DESTDIR он хотя бы учтёт.

Его обычно замечаешь когда лезешь в sys/ хедеры и что-то начинает резко отличаться от glibc.

Ну там пакетные менеджеры (а они вообще есть?), линтеры

Хрен тебе. Это не Go, не C# и не Rust.

ладно ещё cmake, он везде поддерживается и де-факто уже считается стандартом.
Но месон то тут каким боком?

А каким нет? Он тоже сборочная система, тоже достаточно популярная, и тоже делает свою работу правильно. Где-то даже лучше, например в работе с зависимостями и кросс-компиляции.

Я напомню, что CMake без специального прописывания install(…) не будет добавлять соответствующую цель.

Зачем нам это напоминание когда всем известно что это обязательное поведение любой сборочной системы?

И среди CMake лапши я примерно одинаково часто вижу либо отсутствие install цели либо прописанные нестандартные пути

Ну тут он строго не хуже мейка, где тоже возможно не добавить install цель когда она нужна, или прописать нестандартные пути. На этом сходства заканчиваются, потому что в make возможно сделать (и постоянно делается) неправильно ВСЁ остальное.

Но да, я согласен с тем что хотя бы GnuInstallDirs должны быть по умолчанию.

и тоже делает свою работу правильно

Разве что если считать его заменой автотулза, но даже в этом случае со своей работой он справляется крайне плохо. Если автотулз при всех своих недостатках зависел только от make+sh, то это говно при всех своих зависимостях имеет все проблемы автотулза и даже больше. Да и даже так - заменили шило на мыло, и что он выполняет свою работу правильно - 4.2

Muon для этого и сделали, чтобы питон не тащить.

может ещё scons какой-нибудь или autotools предложишь?

Нет, не предложу. meson прекрасен.

Разве что если считать его заменой автотулза, но даже в этом случае со своей работой он справляется крайне плохо.

Автолулзы тратят по 20-60 секунд (в зависимости от окружения) проверяя равен ли один байт восьми битам. Он справляется прекрасно.

Only half of programming is coding. The other 90% is debugging.

https://github.com/oz123/awesome-c

А структуры данных?

Хрен тебе. Это не Go, не C# и не Rust.

Ну для плюсов же сделали Conan.

Да никто автотулз не защищает тут, но meson - кусок говна