Накидайте книг для продвинутого Си под онтопик

Adopting Erlang

Мне этот ресурс показался интересным в 2019м, что сейчас еще более modern не сильно в курсе.

–

По онтопику добавлю книгу более прикладного характера:

«UNIX. Профессиональное программирование» Уильям Ричард Стивенс, Стивен А. Раго

Я, мягко говоря, удивлён.

Так это как раз часть философии «о переностимости лучше позаботиться заранее». Если мне нужно иметь 64 бита, но именно для хранения больших значений, а не для IPC/persistence, то имеет смысл брать (u)int_fast64_t/_least64_t, т.к. их наличие гарантируется стандартом.

Кроме шуток - одно из основных требований к последнему серьёзному обновлению было «делайте что хотите, но предполагать что end points будут обновлены in-sync вы не можете».

Так у меня же и ситуация была попроще: всего один исполняемый файл, разделившийся на N процессов для обеспечения надежности. При необходимости обновления он все эти N процессов убиваются, а затем происходит запуск нового образа из нового каталога.

Так это как раз часть философии «о переностимости лучше позаботиться заранее».

Вот здесь наши взгляды фундаментально различаются: нет, дичь я конечно творить не буду, но и прилагать существенные усилия чтобы покрыть гипотетические cases / platforms (которые я, спешу заметить, даже оттестировать не могу в виду их «гипотетичности») - тоже. В философии которой я придерживаюсь это попадает под категорию «coding for the future». И только когда возникнет необходимость их покрыть - вот только тогда и будем тратить на это время.

то имеет смысл брать (u)int_fast64_t/_least64_t

Расскажите мне во что Вы сохраняете результат int_fast64_t * int_least64_t, или их сумму? Вы понимаете к чему я веду?

Так у меня же и ситуация была попроще: всего один исполняемый файл

Везёт Вам. А у меня мало того что «зоопарк» процессов, так ещё имеется «производственная необходимость» их даже без учёта updates перестартовывать на разных schedules. А при наличии updates всё становится ещё веселее…

C Interfaces and Implementations: Techniques for Creating Reusable Software

Вот то, что тебе по настоящему нужно

Расскажите мне во что Вы сохраняете результат int_fast64_t * int_least64_t, или их сумму? Вы понимаете к чему я веду?

Я так понимаю, что к UB при переполнении знаковых чисел.

Ну так и 64-битовые типы выбираются для того, чтобы переполнения не было.

С другой стороны, не int_least64_t, а какой-нибудь условный long long, и его все равно не хватило. И?

Расскажите мне во что Вы сохраняете результат int_fast64_t * int_least64_t, или их сумму? Вы понимаете к чему я веду?

Я так понимаю, что к UB при переполнении знаковых чисел.

Вовсе нет. Мне не очевидно как именно Вы предлагаете выбирать тип результата любой операции над комбинацией fastXX и leastXX. ПодЕлитесь секретом?

Это (ре)имплементация GLib в форме книги? Но зачем? Есть же C++.

Мне не очевидно как именно Вы предлагаете выбирать тип результата любой операции над комбинацией fastXX и leastXX.

Не помню, чтобы мне пришлось такие комбинации делать.

К тому же это далеко не первый вопрос, первый вопрос: а какой вообще тип выбирать fastXX или leastXX? :)

Не могу сказать, что у меня есть хороший ответ.

Peter van der Linden,

Expert C Programming: Deep C Secrets

Не стоит. Один тут из Москвы тоже хотел углубить и расширить, и такая фигня получилась…

Expert C Programming: Deep C Secrets

Глубокие тайны? Это типа, какой-то портал в другое измерение открывается?

Expert C Programming: Deep C Secrets

Книга в свободном доступе.

Месье желает отныне плодить UB не в приличном количестве, а в прямо таки неприличном? Достойная эволюция сишника!

Месье желает отныне плодить UB

Так должен же кто-то этим заниматься. А то наплодилось растофилов… Скоро про UB вовсе забудут. Не порядок)

Месье желает отныне плодить UB

Так должен же кто-то этим заниматься.

У него с этим всё в порядке, раз он уже сишник. Но надо же соблюдать умеренность во всем.

Плюсы показывают, как не нужно развивать Си. Хотя бы потому, что там место уже занято С++.

Тут вопрос больше в том, зачем писать на си, если тебе надо руками переписывать GLib? В таком случае, лучше взять инструмент поудобнее.

Интересно было бы почитать (думаю автору тоже) книги по, скажем так, архитектуре сишных приложений. К примеру, ситуация, есть SPI периферия, RTOS и много тредов, можно, например, набросать функций с прямым доступом (spi_send, spi_recv) и защитить их мютексом, а можно добавить тред в драйвере, слушающий очередь на указатели, по которому драйвер заполнит буфер и дёрнет семафор/тред. В каких ситуациях оправданы одни механики, а в каких другие, возникают вопросы.

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

Есть Чан Теренс «Системное программирование на С++ для Unix», довольно близко к тому, что wheelman хочет, но там именно плюсы, не сишка.

Вынес списочек в ОП: мож кому будет полезно