Комментарии 171
Спасибо за статью.У меня есть вопрос, по поводу вендоринга в C и в C++, какая лучше всего практика по использованию и подключению сторонних библиотек и контроля их версий? И смотрели ли Вы в сторону таких молодых языков как Rust или Go?
В крупных проектах (во всяком случае, в тех, в которых я участвовал) все необходимые библиотеки (включая libc-библиотеки) содержатся в исходниках и компилируются при сборке.
То есть, в проекте присутствует только одна версия библиотеки. Хочешь другую — нужно озаботиться этим и установить её в проекте.
В паре наших проектов видел такую практику: в папке с библиотекой хранятся исходники нескольких её версий в архивах, а в файле конфигурации сборки есть параметр, отвечающий за версию библиотеки. Указываешь версию и при сборке она будет разархивирована и собрана. Не знаю, насколько это часто используется, но можно рассмотреть как вариант.
А вообще есть clib, но я с ней не работал, ничего сказать о ней не могу:)
Ну или, вот это менее популярное решение.
С Rust я пока еще не знаком, с Go недавно начал возиться. Пока все очень нравится — система импорта пакетов после сей не перестает меня радовать :)
То есть, в проекте присутствует только одна версия библиотеки. Хочешь другую — нужно озаботиться этим и установить её в проекте.
В паре наших проектов видел такую практику: в папке с библиотекой хранятся исходники нескольких её версий в архивах, а в файле конфигурации сборки есть параметр, отвечающий за версию библиотеки. Указываешь версию и при сборке она будет разархивирована и собрана. Не знаю, насколько это часто используется, но можно рассмотреть как вариант.
А вообще есть clib, но я с ней не работал, ничего сказать о ней не могу:)
Ну или, вот это менее популярное решение.
С Rust я пока еще не знаком, с Go недавно начал возиться. Пока все очень нравится — система импорта пакетов после сей не перестает меня радовать :)
Да, но Go пока позволяет использовать только последнюю версию библиотеки.
А вот как раз Cargo в Rust позволяет выбирать любую версию.
Так что, советую ознакомиться, если будет время.
Мне, например, очень нравится подход, который они используют.
А вот как раз Cargo в Rust позволяет выбирать любую версию.
Так что, советую ознакомиться, если будет время.
Мне, например, очень нравится подход, который они используют.
Ну, я только начал знакомство с Go, у меня еще не было проектов на нем, где требовалась бы не последняя версия библиотеки:)
Ну, надеюсь, что все еще впереди.
Rust недавно расхваливал один хороший знакомый, так что рано или поздно я к нему приду, думаю.
А Cargo — уже как получится. Пока вообще не представляю, что это за язык:)
Ну, надеюсь, что все еще впереди.
Rust недавно расхваливал один хороший знакомый, так что рано или поздно я к нему приду, думаю.
А Cargo — уже как получится. Пока вообще не представляю, что это за язык:)
Rust недавно расхваливал один хороший знакомый, так что рано или поздно я к нему приду, думаю.
А Cargo — уже как получится. Пока вообще не представляю, что это за язык:)
Если что, cargo это пакетный менеджер раста.
Cargo — это не язык, это утилита для Rust — пакетный менеджер, который отвечает за структуру проекта, сборку и за библиотеки.
Вендоринг в go позволяет заморозить библиотеку на нужном коммите (если только там не разветвленная цепь зависимостей, которые вытянуть проблематично. Еще есть мой любимый gopkg.in (от создателей mgo), позволяющий использовать даже несколько версий одного пакета в одном приложении. Но тут проблема доверия и оф.поддержки для многих может стать решающим фактором.
Область применения Rust или Go несколько отличается от системного программирования, особенно Go.
Интересно, почему область применения rust — не системное ПО? Он в этой нише, в первую очередь, и интересен.
По скорости Rust не дотягивает до C, насколько я могу судить.
В каких кейсах, при каких структурах данных, при каких используемых абстракциях?
http://benchmarksgame.alioth.debian.org/, если что, не аргумент, там много откровенно кривых бенчмарков.
Если в проекте используется CMake, то есть ещё один вариант: таки указать в CMakeLists.txt репозитории и конкретные версии, которые нужно тянуть. К примеру, в мануалах ко многим библиотекам от Google рекомендуется подключать их именно так.
НЛО прилетело и опубликовало эту надпись здесь
Да, возможно. Выбрал довольно абстрактную тему для статьи — сложно охватить все и разом. Правда, inline я вижу постоянно, а те же volatile и restrict — довольно редко, даже в тех местах, где их использование напрашивается.
Скажем так, узнать про inline проще, чем про restrict и volatile — вот я и решил это упомянуть :)
А register — да, потихоньку выходит из использования. Тем не менее, иногда — полезная вещь.
Скажем так, узнать про inline проще, чем про restrict и volatile — вот я и решил это упомянуть :)
А register — да, потихоньку выходит из использования. Тем не менее, иногда — полезная вещь.
register вообще ни на что не влияет в современных компиляторах при уровне оптимизации -O1 и выше. (современные — это где-то с конца 1980х). Но на -O0 может влиять. Вот например обсуждение в рассылке GCC: https://gcc.gnu.org/ml/gcc/2010-05/msg00098.html
Когда писал программы на streetinterview (сейчас hackerrank.com) моя программа не вкладывалась по времени буквально на процент в отведенный лимит. Я исключительно с помощью register (скорее методом итеративного поиска, чем логически, потому что были и очень не очевидные последствия) подобрал так чтобы программа на моем AMD работала процентов на 5 быстрее. Отправил программу на streetinterview и увидел падание производительности на все 10% на их XEON. Для убедительности запустил пару раз и с тех пор register не использую, чтобы не снился.
Да, только он только на однопоточный простейших приложений и работает. В более-менее сложном чем-то он тупо замедляет все раз в 100 примерно и ничего толком не работает. Мне больше нравится вариант использовать jemalloc с опцией дебага heap-а. Там можно и в рантайпе профили снимать, графы смотреть, что откуда пришло. Различные графики строить и тд. Ну и утечки тоже ищет. И оно почти не замедляет ничего(по крайней мере приложение приемлемо работает с ним), памяти только больше жрет, что ожидаемо.
https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
НЛО прилетело и опубликовало эту надпись здесь
Как я понимаю jmalloc это нестандартный аллокатор и отладчик для хипа. А valgrind это проверка всего и сразу. Хотя часть можно отключить. Он проверяет переполнения, обращения по некорректным адресам, утечки и д.р.
Еще есть более быстрый вариант. Это asan/ubsan. Он может проверять уже кое что, чего valgrind не может, но в тоже время чуть менее надежно.
Для использования *san надо собирать приложение с нужными флагами. Работа замедляется в несколько раз, но получается почти c/c++ с проверкой корректности работы с памятью.
Еще есть более быстрый вариант. Это asan/ubsan. Он может проверять уже кое что, чего valgrind не может, но в тоже время чуть менее надежно.
Для использования *san надо собирать приложение с нужными флагами. Работа замедляется в несколько раз, но получается почти c/c++ с проверкой корректности работы с памятью.
НЛО прилетело и опубликовало эту надпись здесь
Например?
Скажем у вас есть структура что-то вроде
struct
{
int a[15];
int b;
};
a[16] для valgrind скорее всего будет корректен, если не вставится паддинг после a. А ubsan или asan выведет ошибку.
Или тоже самое, только уже разные структуры или массивы, но по указателю из первой структуры через переполнение индекса вы попадете, во вторую. Тут тоже asan/ubsan должен сработать.
Пропустить может если там будут указатели а не массивы.
Другие случаи не помню, но они тоже есть.
НЛО прилетело и опубликовало эту надпись здесь
да, конечно я имел в виду что индекс задается в рантайме. Скажем читается из файлы, или как-то вычисляется.
P.S. А вот cppcheck не поймал, даже если индекс явно 16 влепить.
Возможно баг, или информации анализатору не хватает. Вообще он такое ловит:
(error) Array 's.a[15]' accessed at index 16, which is out of bounds.
Насчёт sanitizers — отличные инструменты. Замедляют программу значительно меньше valgrind, а находят зачастую больше проблем, хотя бы за счёт большего объёма информации о программе. Пересобирать надо, да, но оно того стоит.
Объявляйте переменные в начале функции.
Совет так себе. "Совершенный код" рекомендует объявлять локальные переменные как можно ближе к месту использования, чтобы при чтении не приходилось "вспоминать" типы увиденных переменных.
По возможности инициализируйте переменные при объявлении. Численные с помощью нуля, указатели — NULL.
В основном совет справедлив только для языков/компиляторов, где компилятор не проверяет инициализацию переменных. Небольшой оффтоп, но например в Java так лучше не делать (я понимаю, что эта статья для С-шников, но сейчас мало кто пишет только на С, а статью могут читать все).
примеры (java)
Не инициализируем сразу:
int a;
if(something){
a = 3;
b = 5;
c = 9;
}else{
// тут забыли присвоить a=1;
b = 2;
c = 1;
}
f(a,b); // не компилируется (a не инициализирована), сразу исправляем.Инициализируем сразу:
int a=0;
if(something){
a = 3;
b = 5;
c = 9;
}else{
// тут забыли присвоить a=1;
b = 2;
c = 1;
}
f(a,b); // компилируется (a инициализирована, но не тем, чем надо), ловим баги в рантайме.Не уверен, но мне кажется, что в настоящее время ключевое слово register не влияет ни на что, по крайней мере на самых распространенных платформах.
Объявляйте переменные в начале функции.
Как минимум это релевантно в Си, ибо не перечит стандарту ansi
В ansi c, насколько я помню, "не в начале" объявить даже нельзя, в С99 — можно. Если уже есть компилятор С99, не всегда нужно следовать ansi c.
Более того, хватает компиляторов с поддержкой c11
Но как правило последний стандарт не отражает стандарт который используется (требуется поддерживать)
На самом деле можно объявить и не в начале, если создать новый scope, то есть выглядить это будет что-то вроде:
void foo() {
uint32_t i;
uint8_t c;
/* do something */
{
uint32_t k = 1;
/* do something else */
}
/* do yet another thing */
}НЛО прилетело и опубликовало эту надпись здесь
И да, кстати
Не уверен, но мне кажется, что в настоящее время ключевое слово register не влияет ни на что, по крайней мере на самых распространенных платформах.
src без register
int sqr(int a) {
return a*a;
}
src c register
int sqr(register int a) {
return a*a;
}
Это с -O2?
clang, icc компилируют одинаково; gcc начиная с -O1 — одинаково, а без оптимизаций — так, как на скринах.
https://godbolt.org/g/F5IFpG
Нет (: пример с оптимизацией будет придумать посложнее
НЛО прилетело и опубликовало эту надпись здесь
Дельное замечание.
На самом деле, в си есть такая вещь, как предварительное объявление функции.
То есть, если ты уверен, что это будет полезно для читаемости, ты можешь объявить переменную в начале, а инициализировать в коде, но так же с объявлением типа.
Например:
Конечно, это противоречить пункту о инициализации при объявлении, но каждый сам решает, чему отдавать приоритет.
На самом деле, в си есть такая вещь, как предварительное объявление функции.
То есть, если ты уверен, что это будет полезно для читаемости, ты можешь объявить переменную в начале, а инициализировать в коде, но так же с объявлением типа.
Например:
int foo;
/* ... спустя n строк в той же области видимости...*/
int foo = VALUE_FOR_FOO;
Конечно, это противоречить пункту о инициализации при объявлении, но каждый сам решает, чему отдавать приоритет.
Лучше вообще стараться иметь иммутабельные переменные, везде где можно (слово можно тут надо понимать с разных точек зрения). Это упрощает поведение кода и в итоге его анализ.
А это предполагает автоматически, что инициализация при объявлении, один раз и навсегда. Так что совет-то как раз годный. И для всех языков осмысленный. И именно в java есть смысл так делать почти всегда, добавив еще и final.
НЛО прилетело и опубликовало эту надпись здесь
По-моему, каждый программист Си в своем развитии обязательно проходит через этап, когда зуд в каких-то частях тела (то ли мозга, то ли пятой точки) становится нестерпимым и побуждает сесть и написать очередной баян про то, как следует писать программы на Си.
Мне не нравится идея писать макросы-функции капсом. Я рассуждаю логически (логика и программирование — это же стороны одной монеты, не так ли?): макрос-функция скрывает в себе некое законченное действие, т.е. по смыслу неотличим от функции. Так зачем выделять внешним видом его из ряда функций? Только для того, чтобы знать, что это макрос? И что дает это знание? Рано или поздно может возникнуть ситуация, когда макрос на самом деле придется заменить на функцию, и тогда придется править тонны кода, меняя капс-идентификатор на некапс-идентификатор…
С моей т.з. логично и правильно отличать идентификаторы переменных от констант, для чего и служит капс-выделение. Отличать функционально завешенный блок кода, решающий часто повторяющуюся или логически обособленную задачу, оформленный макросом или функцией смысла не вижу.
Что касается других «рекомендаций», то увы и ах, при работе с встраиваемыми системами некоторые «правильные» принципы не работают: «красиво завершиться, напоследок сказав, что именно пошло не по плану» программа попросту не может… Например, популярный нынче квадрокоптер: в случае ошибки «красиво завершиться» — это значит, перед падением на асфальт сделать мертвую петлю? Или осколки разбросать в виде кода ошибки? Во многом количестве встраиваемых систем НЕТ ОС, которая могла бы воспользоваться кодами ошибок. И так или иначе приходится писать программы, умело игнорирующие ошибки, т.е. допускающие деление на ноль без видимых для пользователя последствий.
Хотя сам принцип -да, разумен. Но не абсолютен.
И, таки-да, автор сам себе противоречит, выделяя функции-обертки капсом…
Мне не нравится идея писать макросы-функции капсом. Я рассуждаю логически (логика и программирование — это же стороны одной монеты, не так ли?): макрос-функция скрывает в себе некое законченное действие, т.е. по смыслу неотличим от функции. Так зачем выделять внешним видом его из ряда функций? Только для того, чтобы знать, что это макрос? И что дает это знание? Рано или поздно может возникнуть ситуация, когда макрос на самом деле придется заменить на функцию, и тогда придется править тонны кода, меняя капс-идентификатор на некапс-идентификатор…
С моей т.з. логично и правильно отличать идентификаторы переменных от констант, для чего и служит капс-выделение. Отличать функционально завешенный блок кода, решающий часто повторяющуюся или логически обособленную задачу, оформленный макросом или функцией смысла не вижу.
Что касается других «рекомендаций», то увы и ах, при работе с встраиваемыми системами некоторые «правильные» принципы не работают: «красиво завершиться, напоследок сказав, что именно пошло не по плану» программа попросту не может… Например, популярный нынче квадрокоптер: в случае ошибки «красиво завершиться» — это значит, перед падением на асфальт сделать мертвую петлю? Или осколки разбросать в виде кода ошибки? Во многом количестве встраиваемых систем НЕТ ОС, которая могла бы воспользоваться кодами ошибок. И так или иначе приходится писать программы, умело игнорирующие ошибки, т.е. допускающие деление на ноль без видимых для пользователя последствий.
Хотя сам принцип -да, разумен. Но не абсолютен.
И, таки-да, автор сам себе противоречит, выделяя функции-обертки капсом…
Так зачем выделять внешним видом его из ряда функций?Явное лучше неявного. Макрос — не функция (например, его нельзя передавать как аргумент в другие функции), и нет никакого смысла обманывать читающего код разработчика, делая вид, что это не так.
Рано или поздно может возникнуть ситуация, когда макрос на самом деле придется заменить на функциюНе надо писать макросов, которые можно заменить на функции.
Функции с результатом void тоже нельзя передавать, как аргумент в другие функции, — и что?
Любая попытка давать ОДНОЗНАЧНЫЕ рекомендации будет ошибочной.
Функции, макросы — это все абстракции, призванные что-то от читающего скрыть, упростить, уменьшить количество анализируемых сущностей. С точки зрения человека их смысл именно в этом. Поэтому сущности с одинаковым смыслом (в человеческом понимании) не стоит явно разделять.
Вот объясните мне логику создателей GCC, которые спокойно сделали два макроса _BV(x) и bit_is_set(a,b) — какой логикой они руководствовались, делая один заглавными, а второй нет?
Любая попытка давать ОДНОЗНАЧНЫЕ рекомендации будет ошибочной.
Функции, макросы — это все абстракции, призванные что-то от читающего скрыть, упростить, уменьшить количество анализируемых сущностей. С точки зрения человека их смысл именно в этом. Поэтому сущности с одинаковым смыслом (в человеческом понимании) не стоит явно разделять.
Вот объясните мне логику создателей GCC, которые спокойно сделали два макроса _BV(x) и bit_is_set(a,b) — какой логикой они руководствовались, делая один заглавными, а второй нет?
Функции с результатом void можно передавать. Я имел в виду что-то вроде
Макросы (в современном языке) нужны только там, где функций недостаточно. Там, где нужно генерировать названия функций, например. Или как-то ещё расширять синтаксис языка.
Логику создателей GCC я вам объяснить не смогу, я не принадлежу к их числу.
void do_things(void) {
...
}
void do_async(void (*what)(void)) {
...
}
...
do_async(do_things);
Макросы (в современном языке) нужны только там, где функций недостаточно. Там, где нужно генерировать названия функций, например. Или как-то ещё расширять синтаксис языка.
Логику создателей GCC я вам объяснить не смогу, я не принадлежу к их числу.
Я не нес в своей статье посыл «Пишите только так и никак иначе» — каждый волен выбирать, какого стиля придерживаться. Те рекомендации по оформлению кода, что я привел — сборка наиболее часто используемых принципов как из проектов компании, где я работаю, так и из opensource проектов.
У новичка, читающего данную статью, появится представление о том, как обычно делают более опытные ребята в самых разных проектах :)
А по поводу оберток — они нужны не в эксплуатации — конечный пользователь не будет смотреть логи работы программы -, а в отладке. Надо же тестерам и разрабам понимать, что и где упало в случае ошибки.
У новичка, читающего данную статью, появится представление о том, как обычно делают более опытные ребята в самых разных проектах :)
А по поводу оберток — они нужны не в эксплуатации — конечный пользователь не будет смотреть логи работы программы -, а в отладке. Надо же тестерам и разрабам понимать, что и где упало в случае ошибки.
Да, кстати, капсом я обертки не выделяю
о_О
Я пишу их с заглавной буквы.
Кто то использует _ перед именем обертки, кто-то — другие обозначения. Тут тоже есть свобода выбора :)
О_о
о_О
Я пишу их с заглавной буквы.
Кто то использует _ перед именем обертки, кто-то — другие обозначения. Тут тоже есть свобода выбора :)
О_о
Если у вас есть сомнения: написать макрос или функцию — пишите функцию, не прогадаете. При соблюдении этого простого правила макрос никогда в жизни не выродится в функцию.
Увы, и Ваша рекомендация не панацея. Частенько приходится делать как переход от макроса к функции, так и наоборот. Это же не С++ с его шаблонами… Простой пример
Или в «малых» встраиваемых системах: работу с портом ввода-вывода выгоднее делать макросом в силу большей скорости исполнения кода…
#define max(x,y) ((x)>(y))?(x):(y)
Или в «малых» встраиваемых системах: работу с портом ввода-вывода выгоднее делать макросом в силу большей скорости исполнения кода…
Ага, а потом кто-то пишет
И удивляется результатам. Ну или правило о том, что так нельзя делать, пишется в Code Style Guide, который в итоге раздувается.
x = max(a++, b);
И удивляется результатам. Ну или правило о том, что так нельзя делать, пишется в Code Style Guide, который в итоге раздувается.
Или в «малых» встраиваемых системах: работу с портом ввода-вывода выгоднее делать макросом в силу большей скорости исполнения кода…Всегда пишу такие
#define CLR(a,b) ((a) &=~(1<<(b)))
static void clr(volatile uint8_t *PORT,uint8_t bitN)
{ *PORT &= ~ (1<<bitN); }А с учетом что в коде у меня (и не только, не нахожу статью на хабре), присутствуют далее такие короткие функции:
static void Led_Off(void)
{ clr( &DDRC, 3 );
clr( &PORTC, 3 ); }При этом компилятор и их заоптимизирует в две инструкции, но вот прежде чем писать такие трехэтажные макросы я бы трижды подумал.
P.S. В «малых» встраиваемых системах у меня все функции static (кроме main), сборка простая — в основной файл сначала все .h файлы инклудяются, потом все .c — все для того чтобы у компилятора были все возможности.
Зуд происходит неспроста. Человек который +- постоянно пишет на си, прекрасно знает, какое там раздолье на стрельбу по конечностям.
Вполне себе распространенное развлечение написано выше. Вот только беда: с беззнаковыми целыми работать не будет, хотя скомпилируется. Если я напишу это капсом, то это явный намек коллегам о том, что это макрос и надо осторожнее работать с этим.
По поводу операционных систем: скоро линукс и его собратья будут в каждом чайнике стоять. И это прекрасно. В mbed есть тоже есть всякие RTOS. Причем ошибки все равно обрабатываются, нередко для этого заводят обработчики по systick.
#define cmp(x, y) (x - y)
Вполне себе распространенное развлечение написано выше. Вот только беда: с беззнаковыми целыми работать не будет, хотя скомпилируется. Если я напишу это капсом, то это явный намек коллегам о том, что это макрос и надо осторожнее работать с этим.
По поводу операционных систем: скоро линукс и его собратья будут в каждом чайнике стоять. И это прекрасно. В mbed есть тоже есть всякие RTOS. Причем ошибки все равно обрабатываются, нередко для этого заводят обработчики по systick.
Системщикам неплохо бы помнить, что C является основным языком при программировании встраиваемых систем и узлов IoT на малых микроконтроллерах.
И там совсем другие подходы.
Поэтому статьи по C надо начинать с дифференциации.
Т.е. сразу предупредить, о программировании каких платформ идет речь и о каком организационном подходе к проектированию.
Например проблема сопровождения для малых микроконтроллеров у многих программистов отсутствует в принципе. Код пишется только для себя и не для кого больше.
Отсюда проистекает бессмысленность большинства советов в статье.
К примеру не надо зацикливаться на правилах названий функций и переменных, программист делает рефакторинг своего кода каждый день. Какая нибудь функция или переменная может поменять свое название десятки раз за время жизни проекта.
Постоянный рефакторинг на самом деле лучше закрепляет в памяти понимание работы программы, чем бесплодные попытки с самого начала дать правильные имена.
Более того, когда возвращаемся к старому проекту, то и тут можно сразу начать с рефакторинга. Это поможет быстрее восстановить в памяти структуру программы.
Соответственно код должен быть адаптирован к рефакторингу, вместо того чтобы подчиняться неким соглашениям об именованиях.
Ну и конечно о рефакторинге бессмысленно говорить не упомянув в какой среде разрабатывается код и в какой компилируется.
И там совсем другие подходы.
Поэтому статьи по C надо начинать с дифференциации.
Т.е. сразу предупредить, о программировании каких платформ идет речь и о каком организационном подходе к проектированию.
Например проблема сопровождения для малых микроконтроллеров у многих программистов отсутствует в принципе. Код пишется только для себя и не для кого больше.
Отсюда проистекает бессмысленность большинства советов в статье.
К примеру не надо зацикливаться на правилах названий функций и переменных, программист делает рефакторинг своего кода каждый день. Какая нибудь функция или переменная может поменять свое название десятки раз за время жизни проекта.
Постоянный рефакторинг на самом деле лучше закрепляет в памяти понимание работы программы, чем бесплодные попытки с самого начала дать правильные имена.
Более того, когда возвращаемся к старому проекту, то и тут можно сразу начать с рефакторинга. Это поможет быстрее восстановить в памяти структуру программы.
Соответственно код должен быть адаптирован к рефакторингу, вместо того чтобы подчиняться неким соглашениям об именованиях.
Ну и конечно о рефакторинге бессмысленно говорить не упомянув в какой среде разрабатывается код и в какой компилируется.
Как я писал в комментариях выше, я не говорю, что нужно писать только так. Это — рекомендации, сделанные на основе самых распространенных практик оформления кода в самых разных проектах.
А по поводу адаптации к рефакторингу… Это очень сложная тема.
Когда я только начинал учить Си, меня часто тюкали по голове за то, что я пишу по-своему, игнорируя общепринятые вещи. Тогда же мне довелось участвовать в небольшом проекте, на последней стадии разработки которого одному опытному программисту поручили выполнить рефакторинг моего кода, ибо он не соответствовал кодстайлу проекта. А кодстайл проекта мы взяли такой же, как в ядре Linux.
Однако, каждый волен сам выбирать свой кодстайл, главное чтоб он не противоречил соглашениям, принятым в проекте:)
А по поводу адаптации к рефакторингу… Это очень сложная тема.
Когда я только начинал учить Си, меня часто тюкали по голове за то, что я пишу по-своему, игнорируя общепринятые вещи. Тогда же мне довелось участвовать в небольшом проекте, на последней стадии разработки которого одному опытному программисту поручили выполнить рефакторинг моего кода, ибо он не соответствовал кодстайлу проекта. А кодстайл проекта мы взяли такой же, как в ядре Linux.
Однако, каждый волен сам выбирать свой кодстайл, главное чтоб он не противоречил соглашениям, принятым в проекте:)
Разрешите поинтересоваться, это какие же подходы используются при разработке для малых микроконтроллеров, что указанные автором подходы не приенимы?
Не знаю что имел в виду автор, но встречал как «тяп ляп и впродакшн» так и «я художник, я так вижу» (ну с очень индивидуальным подходом в программировании). Такой код write only и стоит его почитать, но ровно с той целью с которой стоит посмотреть картины авангардизма.
Хотя я такой подход не приветствую, но по своему опыту скажу что можно сдать код который «пора бы отрефакторить», но можно прицепить еще один костыль и будет работать.
Правда бывают и требовательные заказчики, один у меня уже обновления в течении пяти лет заказывает, вот там в исходнике — красота, хоть на выставку.
Хотя я такой подход не приветствую, но по своему опыту скажу что можно сдать код который «пора бы отрефакторить», но можно прицепить еще один костыль и будет работать.
Правда бывают и требовательные заказчики, один у меня уже обновления в течении пяти лет заказывает, вот там в исходнике — красота, хоть на выставку.
Редко, когда я, почти, полностью согласен с содержанием статьи. Автору спасибо!
потихоньку был вытеснен из десктопа и энтерпрайза
Да неужели?
https://habrahabr.ru/company/hh/blog/318450/
Да, у Java там почти в два раза отрыв по сравнению с С++, но что-то подсказывает, что это не десктоп с энтерпрайзом.
Я вот сейчас пишу с ПК на котором одно приложение на C# и штук пять на Java. И это не что-то такое особенное, вполне себе мейнстримовая ОС. Остальное, С++ и C. Странно, да?
НЛО прилетело и опубликовало эту надпись здесь
Там ещё и ошибка была, вероятно. Если только в make текущий каталог не сбрасывается при переходе к следующей строке блока в Makefile, то make будет вызван в sound/, sound/graphics/, sound/graphics/engine/.
Пример мейкфайла я набросал на скорую руку, каюсь, но, да, он сам сбрасывается в директорию, из которой был вызван, так что все должно быть в порядке.
Я бы, всё же, очень попросил исправить вас этот Makefile к виду с вызовами $(MAKE) вместо make. Иначе это ломает многопоточную сборку.
А ещё лучше — совместить это с makefile'ом от Sirikid. :)
В make каждая строка выполняется в отдельном сабшелле, поэтому все сбрасывается.
В данном конкретном случае я бы использовал переменные (особенно когда количество директорий начинает расти), но это уже вопрос по make, а не по C.
Альтернативный вариант — исходники раскидать, а объектники свалить в одну кучу, используя VPATH. Но это опять вопрос сборки, не относящийся напрямую к языку.
В данном конкретном случае я бы использовал переменные (особенно когда количество директорий начинает расти), но это уже вопрос по make, а не по C.
Альтернативный вариант — исходники раскидать, а объектники свалить в одну кучу, используя VPATH. Но это опять вопрос сборки, не относящийся напрямую к языку.
НЛО прилетело и опубликовало эту надпись здесь
С конкретно такими «подпроектами» сильно красиво не получается, поэтому через шелл циклы:
Или с макросами
Вобщем все печально, если не поступить примерно так:
Мы не можем использовать имена каталогов в качестве таргетов (то есть можем, но будем при этом страдать), потому что они с одной стороны существуют, а с другой стороны ни от чего не зависят. Можно было бы для каждого каталога определить связанную с ним статическую либу (sound -> libsound.a), которую бы и собирал соответствующий sub-make, но это не спасет от необходимости делать clean все равно по каталогам (find -name '*.o;' это тоже не самый правильный путь).
Я бы предпочел иметь всю сборку в одном мэйкфайле, чтобы там иметь и список всех исходников, и список всех объектников и все на свете. Но это лично мои предпочтения. Так-то можно и automake использовать и иметь в каждом каталоге совсем крошечные Makefile.am.
SUBDIRS = sound graphics engine
.PHONY: all build clean
all: build
build clean:
for dir in $(SUBDIRS); do \
make -C $$dir $@; \
done
Или с макросами
SUBDIRS=sound graphics engine
define SUB
# DO NOT REMOVE THIS LINE
$(MAKE) -C $(1) $(2)
endef
.PHONY: all build clean
all: build
build clean:
$(foreach dir,$(SUBDIRS),$(call SUB, $(dir),$@))
Вобщем все печально, если не поступить примерно так:
SUBDIRS=sound graphics engine
SOURCES=$(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.c))
OBJECTS=$(subst .c,.o,$(SOURCES))
.PHONY: all clean
all: program
program: $(OBJECTS)
$(LD) -o $@ $^
clean:
-rm $(OBJECTS)
Мы не можем использовать имена каталогов в качестве таргетов (то есть можем, но будем при этом страдать), потому что они с одной стороны существуют, а с другой стороны ни от чего не зависят. Можно было бы для каждого каталога определить связанную с ним статическую либу (sound -> libsound.a), которую бы и собирал соответствующий sub-make, но это не спасет от необходимости делать clean все равно по каталогам (find -name '*.o;' это тоже не самый правильный путь).
Я бы предпочел иметь всю сборку в одном мэйкфайле, чтобы там иметь и список всех исходников, и список всех объектников и все на свете. Но это лично мои предпочтения. Так-то можно и automake использовать и иметь в каждом каталоге совсем крошечные Makefile.am.
НЛО прилетело и опубликовало эту надпись здесь
Потому что make умеет из коробки в параллельность и инкрементальные сборки. А мне почему-то регулярно приходится разбирать конструкции вида «тут мы из мэйка вызовем шелл, а в нем мэйк, а там опять шелл, а уже он окончательно последний мэйк».
Я бы очень хотел, чтобы описанная выше архитектура была преувеличением. Но нет, это суровая реальность на моем текущем месте работы.
Я бы очень хотел, чтобы описанная выше архитектура была преувеличением. Но нет, это суровая реальность на моем текущем месте работы.
Эскобар.jpg recursive make considered harmful.
Да-да, как раз хотел кинуть это. Пишут Makefile рекурсивные и потом жалуются на скорость работы make.
Тут не скорость работы make-а, а проблема отслеживания зависимостей. Тк make тупо не знает про вложенные и не может правильно понять, что нужно пересобрать.
Знает, если ему объяснить. В приведенном примере make ничего не объяснили о зависимостях.
А каким образом ему можно сообщить? Простой пример.
Поменяли файл локальный bin.c, не из libsound/. В этом примере make попытается пересобрать libsound.a, тк на этом уровне он не знает, что libsound.a не зависит от bin.c.
Если сделать это без вложенного make в libsound можно сделать полный граф зависимостей и тогда make-у будет понятно, что libsound.a не зависит от bin.c и его трогать не нужно.
Как можно тут указать правильно все от чего зависит libsound.a не дублирую Makefile из libsound?
mybin: bin.c libsound.a:
cc $(^) -o $(@)
libsound/libsound.a:
make -C libsound
Поменяли файл локальный bin.c, не из libsound/. В этом примере make попытается пересобрать libsound.a, тк на этом уровне он не знает, что libsound.a не зависит от bin.c.
Если сделать это без вложенного make в libsound можно сделать полный граф зависимостей и тогда make-у будет понятно, что libsound.a не зависит от bin.c и его трогать не нужно.
Как можно тут указать правильно все от чего зависит libsound.a не дублирую Makefile из libsound?
Он зайдет в libsound, запустит там make, увидит, что делать ничего не надо, выйдет. Да, уйти в sub-make придется, но и все.
Есть вариант, который используется в некоторых проектах, поставить libsound.a в зависимость libsound/stamp, на который делается touch в конце сборки libsound.a, а при любой правке в каталоге libsound придется делать touch на этот stamp. Такое имеет смысл, если предполагается, что содержимое libsound будет меняться редко и вообще это сторонний код, которому мы верим.
Есть вариант, который используется в некоторых проектах, поставить libsound.a в зависимость libsound/stamp, на который делается touch в конце сборки libsound.a, а при любой правке в каталоге libsound придется делать touch на этот stamp. Такое имеет смысл, если предполагается, что содержимое libsound будет меняться редко и вообще это сторонний код, которому мы верим.
Если представить проект, где, например, с десяток таких библиотек и они по-разном зависят от каких то хедеров. Если Makefile общий с include вместо вызова вложенного make, тогда есть полный граф зависимостей и будет правильно работать -j например. Сразу будет понятно, что можно распараллелить, а что нет. В случае с раздельными же, нужно либо както этот -j передавать ниже, либо всегда с ним запускать. Так же, подобные внешние вызовы будут своего рода барьерами, мешая make-у работать параллельно иногда и ожидая вложенного завершения. Короче в статье, которую привели выше все хорошо описано и почему не нужно так делать, если хочется нормальной сборки. Минусов у единого Makefile, если это один проект, я не вижу. Некой модульности можно достичить include-ами, если хочется собрать только одну либо, то можно написать make libsound/libsound.a
Я просто сталкивался в относительно большом проекте(2М строк), как раз с реккурсивным make и неправильным отслеживанием зависимостей отчасти из-за этого. Сборка была очень медленной(С++ с шаблонами, бустами всякими и подобным шлаком), плохо параллелилась и делала много лишнего на каждый чих, когда не нужно.
Я просто сталкивался в относительно большом проекте(2М строк), как раз с реккурсивным make и неправильным отслеживанием зависимостей отчасти из-за этого. Сборка была очень медленной(С++ с шаблонами, бустами всякими и подобным шлаком), плохо параллелилась и делала много лишнего на каждый чих, когда не нужно.
-j передается в sub-make автоматически (в отличие от некоторых других флагов), если внешний make понял, что это sub-make. Для этого стоит либо использовать $(MAKE) вместо make, либо (надежнее) ставить + перед соответствующей строкой. На самом деле в этом случае sub-make даже идет параллельно с «внешним», джобы общие и вообще все шикарно работает.
На самом деле я всеми руками за один единственный Makefile. Просто его чуть труднее правильно готовить, а многие разработчики, которых я видел, почему-то не хотят научиться это делать как следует.
На самом деле я всеми руками за один единственный Makefile. Просто его чуть труднее правильно готовить, а многие разработчики, которых я видел, почему-то не хотят научиться это делать как следует.
-j передается в sub-make автоматически
Польза от этого сомнительная. Получается общее количество потоков, используемое всеми запущенными makeами, будет отличаться от указанного. Это может ощутимо сказаться на времени сборки и используемой памяти.
Как раз наоборот.
The ‘-j’ option is a special case (see Parallel Execution). If you set it to some numeric value ‘N’ and your operating system supports it (most any UNIX system will; others typically won’t), the parent make and all the sub-makes will communicate to ensure that there are only ‘N’ jobs running at the same time between them all. Note that any job that is marked recursive (see Instead of Executing Recipes) doesn’t count against the total jobs (otherwise we could get ‘N’ sub-makes running and have no slots left over for any real work!)тыц
char c[IP_UDP_DHCP_SIZE == 576 ? 1 : -1];
Лично у меня, когда я это увидел, повис вопрос: «Чеееееееее?».
Это абсолютно необходимая проверка для компиляции на разные архитектуры и разными компиляторами. Дело в том, что отключение выравнивания в разных компиляторах выполняется по-разному. Опять-таки архитектуры бывают разные, вплоть до 32битных байтов.
Второй момент — почему так странно, а не просто assert. Дело в том, что обычный assert отрабатывает во время исполнения, а такой — во время компиляции. Сейчас обычно делают макрос CCASSERT, но тут, похоже, код древний, и на общепринятый макрос просто не перешли.
Если интересно, то вот код макроса:
#define _x_CCASERT_LINE_CAT(predicate, line) typedef char constraint_violated_on_line_##line[2*((predicate) != 0)-1];
#define CCASSERT(predicate) _x_CCASERT_LINE_CAT(predicate, __LINE__)
// Usage: CCASSERT(1) to pass; CCASSERT(0) to fail
/*
typedef struct {
long x;
long y;
}foo ;
CCASSERT(sizeof(foo) < 10) // will not complain
*/
Это — пример того, как делать не стоит. Никогда. Иначе случится насилие. Рано или поздно.
В целом, когда у нас есть внутренняя структура, являющаяся образом какого-то внешнего пакета, то является хорошим тоном проверить хотя бы её длину (в идеале — ещё и смещение до ключевых полей).
Если вы когда-нибудь будете портировать ваш проект на пяток архитектур и пяток разных компиляторов, то сами нарветесь на проблемы со структурами. И на своем горьком опыте начнете ставить assert и CCASSERT.
Костыль, созданный с одной целью — вставить его, как палку, в колеса тому, кто будет расширять этот код.
Ну кто же мог подумать, что расширять код будет человек, который впервые сталкивается с проблемами портирования? :-))) Кстати, совет — держитесь в рамках ANSI C-88, все более новое, могут и не принять в код. Не на все платформы есть компиляторы, понимающие более новые стандарты Си.
НЛО прилетело и опубликовало эту надпись здесь
MS-DOS, МСВС 3.0 (там gcc 2.95.4 и обновлять нельзя), думаю что PDP-11, VAX-11 и так далее… Плюс вагон военных машинок с нестандартной архитектурой…
НЛО прилетело и опубликовало эту надпись здесь
Суть в том, что в МСВС сертифицируется конкретная сборка под конкретную машину. Поставить более новую версию — это заново потратить год (и пару миллионов) на сертификацию. Так что если сертифицирована 3.0 — себе дороже затевать сертификацию 5.0.
НЛО прилетело и опубликовало эту надпись здесь
Новые версии МСВС есть. Но кто будет сертифицировать новую версию на то железо, на которое уже сертифицирована старая? А сертифицируется именно бинарная сборка, если пересобрали из сорцов -уже сертификации нет. Принесли любой бинарнкик — опять сертификация слетела. Провели компиляцию не на МСВС — опять сертификации нет.
Из рассказов коллег:
— И предоставьте исходный код в распечатанном виде.
— Там 600 тысяч строк, будет 15 тысяч листов, вес листа 80 грамм — итого 1200кг. Грузовик дадите?
— Ладно, давайте на CD.
:-)
Ну в общем, если сертификация важнее всего, то остальным можно пожертвовать.
Из рассказов коллег:
— И предоставьте исходный код в распечатанном виде.
— Там 600 тысяч строк, будет 15 тысяч листов, вес листа 80 грамм — итого 1200кг. Грузовик дадите?
— Ладно, давайте на CD.
:-)
Ну в общем, если сертификация важнее всего, то остальным можно пожертвовать.
Вообще-то, лист весит около 5 граммов, получается всего 75 кг.
Вы правы. Значит там по размеру получался грузовик
Если в одну стопку сложить, то при стандартной плотности (80 г — толщина 0.1 мм) получится около 1.5 метров — тоже никак не гузовик. Может, у вас листов было в 10 раз больше?
По размеру это 6 коробок размером порядка 0.3х0.3х0.3 м (если спрессовать так плотно, как A4 обычно лежит в пачках). То есть, 30 пачек A4 по 500 листов.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите вот этот мой комментарий, и комментарий выше.
Понял ошибку, исправился :)
Понял ошибку, исправился :)
В использовании оберток есть небольшой минус, который, если захотеть, можно решить костылем. А что это за минус — можете предположить в комментариях :)
Там минус очень существенный — на каком бы сокете не произошел сбой — сообщение об ошибке будет одинаковое. Так что надо как минимум добавлять вызываемые параметры. А ещё лучше — лишний параметр в обертке — текстовая строка с назначением сокета, которая выводится в сообщений.
А «небольшой» минус — это то, что как закроются сокеты — зависит от библиотеки. Если успели сделать connect по TCP/IP — сокет скорее всего закроется жестко и вторая сторона не будет в курсе, что мы уже отвалились. Так что лучше использовать atexit.
Храните заголовочники в директории include.
А не могли бы вы объяснить, какой смысл делать отдельную директорию include? Я в этом вижу только минусы:
- нужно прописывать еще один путь в настройках проекта
- дерево проекта увеличивается вдвое, ведь внутри папки include приходится повторять всю структуру папок с файлами .c
- в файле xx.c нельзя просто написать include «xx.h», приходится писать полный путь до него — #include «yyy/zzz/xx.h»
- чтобы скопировать какой-то «модуль», вам приходится копировать два файла из разных мест
Гораздо удобнее, на мой взгляд, группировать файлы в папке по принципу «модулей». Допустим, модуль Common — это отдельная папка, в ней common.c и common.h. Этот модуль приобретает «позиционную независимость», т.е. когда вы его копируете в другой проект, вам не надо переписывать инклуд в файле common.c. Ну и все минусы, описанные выше, пропадают.
Возможно, я выбрал не очень удачный пример в статье. Да, группировка — очень хорошая практика. И она прекрасно дополняет метод с include'ом.
Я уже писал — ко всему надо подходить с умом. Заголовки общего пользования, библиотечные заголовки, которые должны быть доступны во всем проекте. include — для них самое подходящее место.
Возьмем тот же busybox. В исходниках все группируется именно так, как вы сказали. Каждая утилита в отдельной папке. И .c, и локальные заголовки. Но тем не менее, директория include там тоже есть, и все библиотечные хэдеры живут там:)
Самый популярный файл во всем busybox — обитающий там заголовочник с интригующим названием «Libbb.h»
По поводу полного пути — тут вы не совсем правы. Когда мы указываем директорию include, то поиск заголовочников при линковке будет происходить в ней. Так что можно обойтись указанием имени файла в кавычках :)
Я уже писал — ко всему надо подходить с умом. Заголовки общего пользования, библиотечные заголовки, которые должны быть доступны во всем проекте. include — для них самое подходящее место.
Возьмем тот же busybox. В исходниках все группируется именно так, как вы сказали. Каждая утилита в отдельной папке. И .c, и локальные заголовки. Но тем не менее, директория include там тоже есть, и все библиотечные хэдеры живут там:)
Самый популярный файл во всем busybox — обитающий там заголовочник с интригующим названием «Libbb.h»
По поводу полного пути — тут вы не совсем правы. Когда мы указываем директорию include, то поиск заголовочников при линковке будет происходить в ней. Так что можно обойтись указанием имени файла в кавычках :)
По поводу полного пути — тут вы не совсем правы
Я просто подумал, что вы предлагаете в папке include дублировать всю структуру каталогов для исходников, а не держать там только глобальные заголовочники. Если в папку include не совать вообще все заголовочные файлы, а только глобальные, то никаких возражений у меня нет.
В папку include нужно класть только внешние заголовки библиотеки. Все внутренние заголовки удобнее держать рядом с компилируемыми файлами (.c), тут вы правы. Делается это для того, чтобы избежать роста сложности в настройках проектов использующих ваш модуль. Представьте, что в ваших внешних includa-x есть ссылки на include-ы сторонних библиотек, которые вы используете. В таком случае, пользователь вашей библиотеки просто не сможет использовать ее без настойки правильных путей к внешним библиотекам.
Например, если есть module1 использующий module2 который, в свою очередь использует module3, а во внешних include-ах всех модулей присутствуют включения друг-друга, то module1 не получится использовать без include-ов модулей 2 и 3, хотя на самом деле достаточно только .lib файлов.
Например, если есть module1 использующий module2 который, в свою очередь использует module3, а во внешних include-ах всех модулей присутствуют включения друг-друга, то module1 не получится использовать без include-ов модулей 2 и 3, хотя на самом деле достаточно только .lib файлов.
Не совсем понятно почему часть про кодстайл описана в контексте Си. Сейчас, на мой взгляд, кодстайл должен быть неотъемлимой частью любого проекта.
Не понимаю в чем профит группирования заголовочных файлов в одном месте, если это не какая-то библиотека. Когда работал с одним самописным игровым движком (не моим) был бинарник и куча .h файов, который служили интерфейсами дял подключения. Когда не видишь реализации — это удобно. В остальных случаях скачки фокуса между папками include и src довольно неудобны и в чем польза такой группировки мне непонятно.
Не совсем понятно почему возникает необходимость использовать volatile переменные как в примере. Как минимум это усложняет код и добавляет магии в процесс разработки. Можно больше примеров когда такая магия оправдана?
НЛО прилетело и опубликовало эту надпись здесь
Скажу снова: по поводу оформления кода — это не «абсолютные истины», а рекомендации. Практика, которая встречается чаще всего. Кодстайл всегда зависит от конкретного проекта.
По поводу заголовочников стоит написать отдельную статью. В идеале, все заголовочники должны быть оформлены так, чтобы из них можно было понять как можно больше интерфейсов взаимодействия внутри программы.
+ надо понимать, что ничего не стоит делать бездумно. В том же busybox заголовочники бывают 2х типов: общего пользования и локальные. Общего пользования лежат в include в корне, а локальные — в папках с утилитами (подпроектами).
Очень правильный комментарий вот тут, группировка — очень хорошая практика. Однако в системе вынос в инклуд я встречаю гораздо чаще.
Volatiole надо использовать, когда переменные могут быть изменены неявно. Например, если у нас многопоточное приложение, в котором потоки имеют общий доступ к каким-либо переменным.
Тогда любое изменение этих переменных, которое будет сделано из другого, будет неявным для компилятора. Отсутствие volatile в этом случае может положить весь механизм IPC в приложении.
По поводу заголовочников стоит написать отдельную статью. В идеале, все заголовочники должны быть оформлены так, чтобы из них можно было понять как можно больше интерфейсов взаимодействия внутри программы.
+ надо понимать, что ничего не стоит делать бездумно. В том же busybox заголовочники бывают 2х типов: общего пользования и локальные. Общего пользования лежат в include в корне, а локальные — в папках с утилитами (подпроектами).
Очень правильный комментарий вот тут, группировка — очень хорошая практика. Однако в системе вынос в инклуд я встречаю гораздо чаще.
Volatiole надо использовать, когда переменные могут быть изменены неявно. Например, если у нас многопоточное приложение, в котором потоки имеют общий доступ к каким-либо переменным.
Тогда любое изменение этих переменных, которое будет сделано из другого, будет неявным для компилятора. Отсутствие volatile в этом случае может положить весь механизм IPC в приложении.
Каюсь, про многопоточность не подумал.
Volatiole надо использовать, когда переменные могут быть изменены неявно. Например, если у нас многопоточное приложение, в котором потоки имеют общий доступ к каким-либо переменным.Насчет C я не знаю, но нас ведь могут читать люди, пишущие на разных языках.
В C++ использование volatile в многопоточной среде — это очень вредный совет! Он просто не имеет свойств, которые могут быть нужны в многопоточной среде — например, атомарности изменений. Подробное обсуждение есть на stackoverflow
НЛО прилетело и опубликовало эту надпись здесь
Вы не правы. Модификатор volatile не имеет к многопоточности никакого отношения. Это абсолютно перпендикулярные вещи. В общем случае, кроме чтения/записи байта, вы не сможете атомарно менять переменную, не используя специальные функции (примитивы) предназначенные для этого. volatile никак не влияет на барьеры памяти в С, в отличие, например, от Java-ы.
Ещё забавно, как сочетается volatile и переупорядочивание строк компилятором. Тут можно придумать что-то кроме вставки на асме или специфичных для процессора инструкций?
Вы веткой не ошиблись?
Если нет, то, видимо, это я выразился неясно. Собственно, я то и имел в виду, что использовать volatile для доступа к разделяемой памяти без какой-либо внешней синхронизации небезопасно по большому количеству различных причин, и нужно применять существующие примитивы.
Если нет, то, видимо, это я выразился неясно. Собственно, я то и имел в виду, что использовать volatile для доступа к разделяемой памяти без какой-либо внешней синхронизации небезопасно по большому количеству различных причин, и нужно применять существующие примитивы.
Да, извините. Я отвечал Indever2. Не пойму как так вышло.
Я прочитал ваш комментарий.
Да, я не прав. Многопоточное приложение тут не при чем, компилятор в состоянии отслеживать изменения переменных в потоках.
А вот когда несколько процессов могут менять одну переменную — другое дело :)
Когда речь идет о изменении переменной извне процесса, то тогда оно будет неявным для компилятора.
Да, я не прав. Многопоточное приложение тут не при чем, компилятор в состоянии отслеживать изменения переменных в потоках.
А вот когда несколько процессов могут менять одну переменную — другое дело :)
Когда речь идет о изменении переменной извне процесса, то тогда оно будет неявным для компилятора.
Да. Но если совсем точно, то компилятор ничего не знает про потоки, абсолютно. Не знаю как в C, а в C++ только-только стали появляться TLS в стандарте, а вся работа с многопоточностью реализована в библиотеке. В любом случае на месте обращения к разделяемой потоками переменной будет нетривиальная функция или intrinsinc и компилятор нечего не выкинет. С volatile все по старинке.
del. Ниже комментарий более подробный: https://habrahabr.ru/post/325678/#comment_10158130
Вы неправы. Точнее не совсем правы. Компилятор в состоянии отследить изменение в разных потоках.
volatiole нужен в том случае если переменная изменяется снаружи.
Например у нас есть обработчик прерываний. И его вызова нету в тексте программы, так-как его вызывает(передает управление на него) процессор/контроллер в произвольный момент времени.
Или например у нас есть переменная которая связанна с некоторым физическим адресом(регистром периферии) в SoC.
И нам нужно записать а потом сразу считать значение так-как этот регистр обрабатывается особым образом.
И если мы напишем что-то типа
и reg будет без volatile то копилятор вправе выкинуть этот код.
Или например мы пишем вот так
Без volatile опять компилятор выкинет предыдущие операции и оставит только последнюю.
volatiole нужен в том случае если переменная изменяется снаружи.
Например у нас есть обработчик прерываний. И его вызова нету в тексте программы, так-как его вызывает(передает управление на него) процессор/контроллер в произвольный момент времени.
Или например у нас есть переменная которая связанна с некоторым физическим адресом(регистром периферии) в SoC.
И нам нужно записать а потом сразу считать значение так-как этот регистр обрабатывается особым образом.
И если мы напишем что-то типа
reg = 0x10;
if(reg == 1)
{
do_somthing;
}
и reg будет без volatile то копилятор вправе выкинуть этот код.
Или например мы пишем вот так
reg = 0x10;
reg = 0x11;
..
reg = 0x35;
Без volatile опять компилятор выкинет предыдущие операции и оставит только последнюю.
НЛО прилетело и опубликовало эту надпись здесь
… а слова в названиях отделяются нижним подчеркиванием
А какие еще бывают подчеркивания?
У меня вызывает внутреннее противление приведённая в статье реализация функции
Далее, название функции:
В конце-концов, было бы крайне любопытно (и эффективно?) иметь текстовую строку, описывающую текущее состояние объекта, каждый символ которой связан с некоторым элементом описания модемного соединения. Делая простой проход по этой строке, можно было бы сразу получать ответ на нужный вопрос. А, если само символьное представление делать более сложным (XML?), то можно было бы автоматизировать выдачу диагностических сообщений (например, соединяя друг с другом строки состояния для различных элементов в единую строку).
static int CheckModemConnection()
Возвращает 1, если параметры, связанные с модемным соединением изменились, и 0, если нет.Насколько я помню, это традиционно для Си возвращать именно такие значения, чтобы в месте вызова можно было бы реализовать обработку для случая произошедших изменений. Было бы логичнее иметь в качестве кода возврата
bool, но это же Си! (NB: надо свериться с последним стандартом!)Далее, название функции:
CheckModemConnection. А если придётся проверять ещё чего-нибудь, то надо будет писать отдельную функцию для вот этого самого чего-нибудь? Мне бы ужасно захотелось бы обобщить и иметь общую для всех функцию проверки. Даже, если в Си нет классов. (Всегда можно ввести.) К тому же, для того, чтобы иметь возможность проверять состояние, неплохо бы как-то формализовать сие понятие и сделать так, чтобы, например, пробегать по списку необходимых свойств в цикле, а не создавать длинное условие для оператора if. В конце-концов, было бы крайне любопытно (и эффективно?) иметь текстовую строку, описывающую текущее состояние объекта, каждый символ которой связан с некоторым элементом описания модемного соединения. Делая простой проход по этой строке, можно было бы сразу получать ответ на нужный вопрос. А, если само символьное представление делать более сложным (XML?), то можно было бы автоматизировать выдачу диагностических сообщений (например, соединяя друг с другом строки состояния для различных элементов в единую строку).
НЛО прилетело и опубликовало эту надпись здесь
Если бы надо было проверить что-то еще — да, мы бы написали отдельную функцию.
И она бы вызывалась вместе со всеми проверками. CheckModemConnection() — одна из сотен функций, которые вызываются при обработке пришедшей конфигурации. То есть все — и сеть, и voip, и iptv имеет подобные проверки.
Нужно это, чтобы группировать параметры, и, когда надо добавить новый, знать, где находится проверка группы связанных параметров.
Конфигурация приходит в виде дерева, по конкретным нодам в цикле не пройтись. Разве что, можно создать массив/перечисление с указателями на параметры, и идти по нему… Но это не слишком целесообразно, ибо будет гораздо сложнее найти источник и сразу не скажешь (не смотря на массив), какие параметры подвергаются проверке.
И она бы вызывалась вместе со всеми проверками. CheckModemConnection() — одна из сотен функций, которые вызываются при обработке пришедшей конфигурации. То есть все — и сеть, и voip, и iptv имеет подобные проверки.
Нужно это, чтобы группировать параметры, и, когда надо добавить новый, знать, где находится проверка группы связанных параметров.
Конфигурация приходит в виде дерева, по конкретным нодам в цикле не пройтись. Разве что, можно создать массив/перечисление с указателями на параметры, и идти по нему… Но это не слишком целесообразно, ибо будет гораздо сложнее найти источник и сразу не скажешь (не смотря на массив), какие параметры подвергаются проверке.
"Традиционно" для Си функции действия add, get, write_ и т. д. должны возвращать отрицательный код ошибки, 0 или положительное значение в случае успеха. А функции предиката аналог bool — 0 и 1.
В данном примере CheckModemConnection() из названия должна возвращать 0 — всё ок или отрицательный код ошибки. Поэтому лучше её было бы назвать как-то так: isModemConnectionChanged(), тогда сразу бы было ясно, что она "Возвращает 1, если параметры, связанные с модемным соединением изменились, и 0, если нет.".
Слово традиционно я намеренно заключил в кавычки, т.к. если говорить о традициях, то язык Си неразрывно связан с историей Unix. Поэтому приверженцам традиций лучше следовать Linux kernel code style — пункт 16, либо KNF.
Костыль, созданный с одной целью — вставить его, как палку, в колеса тому, кто будет расширять этот код.
Вернее, не так.
Это — костыль, который ясно вам скажет: не надо повторять мою реализацию, хочешь пакет больше — указатели, динамическая память и динамическое вычисление размера тебе в помощь!
Это — пример того, как делать не стоит. Никогда. Иначе случится насилие. Рано или поздно.
Вы не поняли, и делаете неправильные выводы.
Это проверка, что компилятор корректно упаковал структуру с нужным размером.
См. https://git.busybox.net/busybox/commit/?id=6884f665bd7bc101f56ff9047afaffbc06dc99e2
если мы захотим сделать реализацию, в которой размер пакета будет вычисляться динамически (из соображений этики и следования стандартам, только такая реализация и имеет право на жизнь)
Это бессмысленное усложнение, т.к. нужна структура/буфер под максимальный размер DHCP пакета. Динамика — оверкил в условиях, когда пакеты обрабатываются строго последовательно и максимальный размер пакета заранее известен.
Если DHCP клиент не обозначил серверу максимальный размер (57 опция), то сервер не имеет права по RFC отвечать пакетами бОльшего размера. Однако, это только в идеальном мире, поэтому есть опция UDHCP_SLACK_FOR_BUGGY_SERVERS, в которой задается размер дополнительного места в буфере с максимумом 924, что дает возможность принимать пакеты до 1500 байт.
См. https://git.busybox.net/busybox/commit/?id=72e76044cfda377486a5199a0d35d71edf669a42
Такой небольшой размер — прямое противоречие RFC с описанной в нем 57й опцией.
Никакого противоречия нет. Такой небольшой размер находится в полном соответствии с минимальным MTU, ниже которого быть не может. Соответственно, т.к DHCP протокол основан на UDP без подтверждения доставки, этот небольшой размер дает "гарантию", что DHCP пакеты не потеряются по пути из-за более меньшего MTU.
Чтобы информировать сервер о максимально поддерживаемом размере, добавляется 57 опция, с размером — IP_UDP_DHCP_SIZE == 576, вне зависимости от дополнительного буфера UDHCP_SLACK_FOR_BUGGY_SERVERS.
См. коммиты 2007 и 2010 года:
https://git.busybox.net/busybox/commit/?id=35ff74676b54b1cae5a6324d2517568393fedbc8
https://git.busybox.net/busybox/commit/?id=b3af65b95de883e9be403e065f57b867d8ea8d43
Таким образом, чтобы "законно" получать пакеты больше стандартного размера, нужно
1) увеличить размер UDHCP_SLACK_FOR_BUGGY_SERVERS до максимально возможного
2) уведомлять сервер о реально поддерживаемом размере 57й опцией с учетом текущего MTU интерфейса.
И тут, всё давно придумано
https://github.com/wl500g/wl500g/commit/57fd93bd29399d6b08643bb79a3e41f330b6cd9a
Объявляйте переменные в начале функции.
Всегда страшно горело из-за этого правила. Вы можете обьяснить зачем это делать? В случае если переменная определена в месте первого использования, ее сразу можно инициализировать нужным значением, в случае рефакторинга кода ее тут-же можно удалить, не нужно искать тип переменной если видем присвоение ей значения, и еще много причин.
Даже Google думает не так, как написано:
C++ allows you to declare variables anywhere in a function. We encourage you to declare them in as local a scope as possible, and as close to the first use as possible.
Вы можете обьяснить зачем это делать?Чтобы код компилировался на старом компиляторе, например.
Или если вы по какой-то причине считаете, что именно в этой функции вам важнее уметь находить все переменные функции за один раз, чем удобство просмотра инициализации какой-нибудь одной.
Да мало ли причин может быть. Но, на мой взгляд, действительно не стоит преподносить это правило в качестве рекомендации на все случаи жизни.
НЛО прилетело и опубликовало эту надпись здесь
Сюда же в правило обычно добавляються переменные в `for loop`-ах. От этого горит еще больше.
ИМХО такое объявление добавляет читабельности: сразу прочитав список переменных, уже примерно понимаешь, с чем имеешь дело и что делает код.
Отличное руководство. Как раз для таких начинающих как я. Спасибо большое.
По поводу инициализации переменных не соглашусь. Если переменные не инициализировать, компилятор будет ругаться, если она была использована без инициализации. Несколько раз это серьёзно выручало при написании конечных автоматов на case-ах.
С другой стороны, иногда gcc матерился в тех же автоматах, что переменная может быть использована без инициализации, хотя явно в это состояние можно было попасть только из того состояния, где переменная была инициализирована, в этом случае, после скурпулёзных проверок, переменная в начале цикла инициализировалось.
А ещё, начинающим сишникам я бы порекомендовал поизучать код nginx, отличный код, интересные решения.
С другой стороны, иногда gcc матерился в тех же автоматах, что переменная может быть использована без инициализации, хотя явно в это состояние можно было попасть только из того состояния, где переменная была инициализирована, в этом случае, после скурпулёзных проверок, переменная в начале цикла инициализировалось.
А ещё, начинающим сишникам я бы порекомендовал поизучать код nginx, отличный код, интересные решения.
Если вы постоянно работаете с трекерами (вроде RedMine), то при внесении правок в код можно указать номер задачи, в рамках которой эти правки были внесены. Если у кого-то при просмотре кода возникнет вопрос а-ля «Зачем тут этот функционал?», ему не придется далеко ходить. В нашей компании еще пишут фамилию программиста, чтобы если что знать, к кому идти с расспросами.
/* Muraviyov: #66770 */
Плохой совет. Плохой он оттого, что комментарии никто не поддерживает.
Мировой опыт (выраженный в книжках МакКоннелла, Р. Мартина и пр.), а равно и мой скромный, говорит, что комментарии редко бывают актуальными, тем более, такие.
«Кто, когда и почему?» — на эти вопросы достоверно отвечает система контроля версий (должна отвечать… у вас-то какая?).
Когда мы делаем git blame в каком-нибудь огромном файле, в который каммитили все, кому не лень, найти изменения по какой-то конкретной фигне может быть довольно долго.
+ даже зная, кто и каким каммитом добавил функционал, не всегда можно понять, в рамках какой задачи это было сделано. (не все и не везде указывают).
Да и в любом случае, просто вбить заранее указанный номер задачи в трекер будет в разы быстрее, чем сначала искать «кто, где и зачем».
По поводу того, что комментарии не поддерживают — не соглашусь.
Я бы посмотрел на того, кто бы взялся сопровождать тот же bb, не будь он так хорошо задокументирован)
Если комментарии не нужны, то почему так много рекомендаций из самой различной литературы и интернета отмечают умение грамотно писать комментарии одним из правил хорошего тона?
+ даже зная, кто и каким каммитом добавил функционал, не всегда можно понять, в рамках какой задачи это было сделано. (не все и не везде указывают).
Да и в любом случае, просто вбить заранее указанный номер задачи в трекер будет в разы быстрее, чем сначала искать «кто, где и зачем».
По поводу того, что комментарии не поддерживают — не соглашусь.
Я бы посмотрел на того, кто бы взялся сопровождать тот же bb, не будь он так хорошо задокументирован)
Если комментарии не нужны, то почему так много рекомендаций из самой различной литературы и интернета отмечают умение грамотно писать комментарии одним из правил хорошего тона?
Когда мы делаем git blame в каком-нибудь огромном файле
я отсюда делаю вывод: файлы не должны быть огромными :)))
даже зная, кто и каким каммитом добавил функционал, не всегда можно понять, в рамках какой задачи это было сделано. (не все и не везде указывают).
это ничем не отличается от наличия/отсутствия (обсуждаемого нами) коммента
это вопрос дисциплины и гайдов оформления текста коммита, только вот в отличие от отсутствия комментария с причинами «забыл/лень/не хочу/не знаю» текст коммита легко валидируется хуками, что способствует гайдам
просто вбить заранее указанный номер задачи в трекер будет в разы быстрее
с «быстрее вбить» спорить даже не собираюсь (я сам люблю one-click переходы)
но Вы забываете про достоверность
Я бы посмотрел на того, кто бы взялся сопровождать тот же bb, не будь он так хорошо задокументирован)
я не знаю, что такое bb
но с высоты своего опыта поддержки многолетних активно меняющихся legacy-продуктов могу утверждать, что такие комментарии бессмысленны чуть менее, чем совсем
отмечают умение грамотно писать комментарии одним из правил хорошего тона
я выделил ключевое слово ;)
del (не туда)
Согласен с
Названия макросов и макрофункций пишутся капсом, слова в названиях отделяются друг от друга нижним подчеркиванием.
Названия переменных записываются в нижнем регистре, а слова в названиях отделяются нижним подчеркиванием
Логически группируйте .c файлы в папки.
Не согласен с
Храните заголовочники в директории include
Остальное не важно
Вот мой реестр
51 Атрибут Хорошего С-кода (Хартия Си программистов)
https://habr.com/ru/articles/679256/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пиши на C как джентльмен