Программирование на C в эпоху ООП. Оно такое⁠⁠

Я в свое время учился по какой то книге где это было упомянуто совсем вскользь, мол это дело такое - для узкоспециализированных спецов, вам скорее всего не пригодится. А потом я уже во взрослом возрасте столкнулся с программированием микроконтроллеров, совершенно случайно полез разбираться что это и меня как по голове стукнули - это же гениально !

Ну так если вам не нужны битовые поля и целочисленные типы кроме int32_t/int64_t, то не стоит по этому поводу переживать. Переживать надо начинать, когда они понадобились

Больше всего бесит, что такой подход работает

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

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

Ну то есть если бы условный Кибарпанк писали с нуля на С так, чтобы он максимально эффективно использовал каждый бит и каждый такт, он бы не был в два раза быстрее. Он бы не был даже отложен до 2022 года. Его бы просто никогда не существовало. Современное ПО часто невозможно реализовать на том же уровне абстракции, на котором пишется софт для микрожелезок.

Сушить портки на свитче - это отдельный вид быдлокодерства, ящитаю... 3-5 строк, а дальше - по рукам бить. Но тут тоже как и в ретарне про KISS скорее, и про комплексную сложность, и конкретно свитч тут не причем, пяток экранов в ветке if тоже не сахар.

Две из шести претензий я разделяю.

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

Битовые поля -- это не поля класса, хотя они выглядят такими. Для них не работает адресная арифметика, а еще для них не работают привычные гарантии многопоточной работы. Так что использовать их там, где они не необходимы, я бы не стал. Если нужны только флаги -- пускай это будет bitfield или просто int -- они хотя бы не притворяются тем, чем они не являются.

Да это так.

Но это не правильно. Школа программирования вырождается из решения шахматной задачи в бухгалтерию перебора библиотек. Библиотек написанных брутфорсом. Уже начинает вступать в силу жизненные реалии. когда продукты жиждятся на какой-нибудь библиотеке, которую вдруг перестают поддерживать по чисто физиологическим причинам.

Я не говорю что этот подход нижизнеспособен. Наверное он единственный в текущей системе мировоззрения.

Я смотрю тут каждый своё разделяет.

Тут надо смотреть кто в какой области и на чём пишет.

Я вот goto вообще не использую,  return один на всю процедуру.

мне претит. Я бы ещё и циклы в список добавил. Кроме главного.

Вот что можно сделать циклом, чего не позволяет сделать аппаратура МК?

Циклы - потенциал для зависания МК.

А битовые поля и разные длины типов - так на раз. Иначе-то как на МК программировать?

По мне и ООЯ для МК это лишний машинный код. хотя щас и МК залили просто как ОЗУ так и флэш. О ресурсах вообще не думаешь. Разве только для оптимизации скорости. Языки ООП нужны для скорости написания кода и его кооперативности(взаимное использование). Хоть и порождают они монструозов типа прикрутил теплоход в качестве поворотника на велосипед.

Как рассказик о роботе которого научили брать+наливать+ставить на плиту+зажигать газ=кипятить чайник, а потом задачу облегчили. Чайник полный на плите. Робот вылил воду и свёл задачу к первой...

Но МК есть МК. Хотя кому-то и тут недосуг даже ручками прописать инициализацию. пользуют библиотеки которые мигать светодиодом преобразуют в пару килобайт кода, а не в десяток-два команд.

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

Не си, но джава - я встречал сетевой хендлер длиной в 14к строк на условиях, это локальный адок. Переделал на обсерверы - стало просто, понятно, и гибко.

Если совсем современнить - то можно DI применить, и даже вручную регистрировать все классы в хендлере не придется.

Хеш-таблицы, безусловно, медленнее линковки, но всё еще достаточно быстры для подобных задач.

Давайте писать такой код, который прочитает даже школьник. Это ведь важнее.