LINUX.ORG.RU
Форум — Development  

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

 ,


10

6

Сто лет назад прочитал K&R и всегда хватало, а если я хочу углУбить?

// друг спрашивает :)

UPD: собрал из темы списочек, особо не редактируя (экстримов и модернов поболее одного, но пусть будет) – думаю, заглянувшим в будущем будет полезно:

  • modern c by jens gustedt
  • Thomas Mailund - Pointers in C Programming (2021)
  • Gustedt - Modern C (2020)
  • Kalin - Modern C Up and Running (2022)
  • King - C Programming. A Modern Approach, 2nd ed. (2008)
  • Хэзфилд «Искусство программировани на C»
  • «Язык C в XXI веке»
  • Экстремальный Си
  • extreme c programming
  • «UNIX. Профессиональное программирование» Уильям Ричард Стивенс, Стивен А. Раго
  • C Interfaces and Implementations: Techniques for Creating Reusable Software
  • Peter van der Linden, Expert C Programming: Deep C Secrets https://progforperf.github.io/Expert_C_Programming.pdf
  • Чан Теренс «Системное программирование на С++ для Unix»
★★★★★

Последнее исправление: pihter (всего исправлений: 3)

 ← 1 2 3 →
Ответ на: комментарий от etwrq

Adopting Erlang

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

–

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

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

necromant ★★
()
Последнее исправление: necromant (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

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

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

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

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

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

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

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

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

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от iron

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

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

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

Virtuos86 ★★★★★
()

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

wheelman
()
Ответ на: комментарий от wheelman

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

urxvt ★★★★★
()
 ← 1 2 3 →
Development