Бесплатные электронные книги по C11/C18/C2x

Modern C

Посредственная книжка, читал ее. Вообще, в современном С нет ничего такого, что потребовало бы новых книг. К&Р хватит всем. А новшества вроде маллока на стеке лучше не использовать... Да и от дженериков фактически смысла нет.

Золотые слова.

электронные книги по ... C2x

Ну, начни отсюда, хе-хе.

Alloca появился лет 20 назад, вы об этом? Гнуси это очень удобно на самом деле.

Да, я о динамических массивах. Плохая идея.

А restrict? А _Generic? А всё остальное?

Плохая идея.

Почему?

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

Вольдемар

Не нужно. Только вред от них. restrict 100% не нужен.

Stack overflow легко поймать. Malloc же есть!

Я тут одну тему поднимал. На сколько я понял, без restrict надо быть знатоком компилятора, чтобы помочь ему оптимизировать код. Мне кажется, что restrict всё-таки нужен.

А потом будут приколы как с memcpy? Ну зачем на пустом месте UB придумывать?

С одним malloc не получится делать что-то вроде:

double (*cube)[y][z] = malloc(x * y * z * sizeof(double));
cube[1][2][3] = 2.0;

Придётся писать:

double *cube = malloc(x * y * z * sizeof(double));
cube[1*y*z + 2*z + z] = 2.0

Что менее очевидно и подвержено ошибкам (я совсем не уверен, что написал правильно).

UB будет, если программист сам напишет restrict и сам же подаст на вход такой функции 2 указателя на одну память. Это не «пустое место» это злонамеренный выстрел себе в ногу. Вот если бы restrict был дефолтом, как в фортране, тогда бы я с вами согласился.

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

Ну так баг с memcpy в этом и заключался!

Баг заключался в передачи memcpy 2х указателей на одну память? Получается, программист, который этот баг допустил не был в курсе С99 и restrict в частности, но использовал его. Было б хорошо, чтобы язык ограждал программиста от излишних сложностей и такие языки есть(правда за такую защиту приходится платить), но С задумывался авторами другим языком. Языком, где программисту даны большие возможности, а с ними и большая ответственность. Кому это не надо – могу писать на таких замечательных языках как java или python. На сколько мне известно, там UB нет.

https://github.com/fffaraz/awesome-cpp#books

GH://EbookFoundation/free-programming-books#c

Знаю небесплатную: «Ben Klemens — 21st Century C: C Tips from the New School».

Это не самостоятельный учебник, но скорее подробный обзор языка для устранения пробелов между K&R и актуальным стандартом.

устранения пробелов между K&R и актуальным стандартом.

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

А как же designated initializers, compound literals?

Я пишу как мне удобно, gnu11 со всеми нестандартными расширениями, потому что мне так нравится. Но на практике все пишут либо c89 либо (реже) c99 и если код чужой, тебе придётся придерживаться. У msvc опять же проблемы будут если не позаботиться об этом заранее.

Сорян, я was not clear enough. Под «никто не придерживается» я имел в виду компиляторы.

Ну гцц есть, это стандарт. Он много чего поддерживает из актуального. Если чего-то в нём нет, то нет. Разработчики конечно сказали поддержка тех же тредов это проблемы глибц, но так ли они нужны? Жили ведь как-то с pthread.

designated initializers

Вообще-то, это С99! Я ими пользуюсь иногда, очень удобно. Чаще - для частичного заполнения полей структур.

compound literals

Этим не пользуюсь. Но тоже вполне вменяемая штука.

Я против С99 ничего не имею, сам в нем собственно и пишу!

С одним malloc не получится делать что-то вроде:

Получится. Нужен только C11.

Читаю драфты, там же не особо много текста.

Атомики?

Ну ты даешь, restrict же можно и не использовать, а можно использовать и получать профиты! Ты прям как растер «давайте уберем возможности, и тогда никто не будет стрелять в ногу!».

Да ненужны они, там что то виндузятское ограниченное.

Атомики?

Честные? Иногда нужны. Но я сомневаюсь что-то в их честности.

restrict же можно и не использовать

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

Просто си нужно как-то конкурировать с фортраном. До сих пор сливает ему по всем параметрам.

О, вы из секты свидетелей фортрана?

С как был прост, так и остался. Restrict же просто подсказка для компилятора.

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

Я видел как как использование слова register ускоряло цикл раз эдак в 10000. А вы говорите подсказки бесполезны.

Из за чего он более эффективный? Это вообще высокоуровневый язычек, а С все же низкоуровневый, и для оптимизации у него возможностей больше, интриски там всякие, низкоуровневые штучки. Где сейчас Fortran вообще используется? Он же как COBOL, древность нинужная. Церн на плюсы давно перешел к примеру...

А бесконечный цикл за сколько выполнялся? %)

Я видел как как использование слова register ускоряло цикл раз эдак в 10000. А вы говорите подсказки бесполезны.

С -O0 собирали?

Нет, -O3 -ffast-math -funroll-loops и всё остальное было перепробовано, в том и дело. Компилятор производил производительный код только с прогоном pgo, так и выяснилось.