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

Здравствуйте, пффф, Вы писали:

П>1) #include с угловыми скобками для своего барахла. Я привык так никогда не делать, давным давно, и уже и не соображу, чем плохо. Ну и эмоции, переполняющие при виде всего этого, мешают

Кавычки ищут в "текущей" директории (там, где сишник лежит), а потом уже по путю. Угловые скобки сразу ищут только по путю. Удобно использовать кавычки для "внутренних" ашников в "модуле" (в Си нет модулей, но разбивая проект на директории мы, фактически, их и делаем) а угловые скобки для ашников, которые "общие", "публичные".

П>2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

Если ашников очень много, пути позволяют структурировать пространство имен. Когда ашников пяток, пути ничего ценного не добавляют.

П>3) порядок инклудов. Ведущие собаководы рекомендуют размещать "" перед <> и вообще располагать инклюды по мере специализации — более частные первыми — чтобы ловить ошибки, когда где-то чего-то не хватает, каждый хидер должен быть самодостаточным и всё такое.
П>Но у некоторых собаководов я встречал рекомендацию сортировать инклуды не только по "" и <>, но и по алфавиту, эта рекомендация несколько конфликтует с рекомендацией по ордеру по уровню специализации. Что думаете?

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

Остальные я тупо сортирую по алфавиту. Так в них проще ориентироваться.

П>4) проект на CMake. Я бы понял, если бы кроссплатформа. Но наша часть чисто виндовая. Генерация с CMake'ом полчаса-час, а нафуа? Полчаса — это ещё без сборки. Потом на сборочном серваке собирается при помощи NMake+JOM, а на девелоперских машинах чтобы в студии поотлаживаться — отдельно надо генерить студийные проекты, и этого нет в репе, каждый извращается как умеет. Я бы перевел бы всю систему сборки чисто под MSVC/MSBuild, там не так страшно, как кажется, если не использовать автоматом генерённые MSVC-проекты, а руками править ихний xml, и быть в курсе, что там тоже есть инклуды. Я давно так живу, и это пиздаточень удобно. За недельку другую я бы всё сделал бы на MSVC/MSBuild зашибись без говна CMake'а. По этому пункту в принципе я и сам обоснований накидаю, но может кто что-то новое скажет

Это ты не победишь. CMake, как позорная инфекционная болезнь, проник повсюду. Хуже него только git.

Здравствуйте, DiPaolo, Вы писали:

DP>1-3 — это какая-то мелочь. Если это самые большие "проблемы", то за вас можно только порадоваться. Но что-то мне подсказывает, что вы занимаетесь не тем, чем следовало бы заняться на проекте.

Не мелочи. Если в организации проекта допустима неряшливость, это наводит на мысль, что и в коде допустима неряшливость, и в тестах, и в следовании спецификации. И что к внесению изменений можно относиться так: тесты проходит, ну и ладно.

Pzz>CMake тошнотворен уже тем, что использует расширение .txt для своих служебных файлов. Ну какой, нахрен, .txt, в них же не "Понедельник начинается в субботу" Стругацких записан, а код на мутном языке программирования.
Пишем cmake-файл с удобным для нас расширением
пишем командный скрипт, в котором копируем cmake-файл с нужным расширением, запускаем cmake и удаляем копию cmake-файла
Нормально вроде получится

Здравствуйте, пффф, Вы писали:

П>1) #include с угловыми скобками для своего барахла. Я привык так никогда не делать, давным давно, и уже и не соображу, чем плохо. Ну и эмоции, переполняющие при виде всего этого, мешают

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

П>2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

Наоборот, очень важно не использовать или ограниченно использовать пути
в "больших" проектах. В "больших" проектах очень важно контролировать граф зависимостей
на уровне системы сборки, а не на уровне исходников. И не использование путей в include,
заставляет прописывать зависимости в системе сборки.
Например:

add_library(foo OBJECT foo.cpp foo.hpp)
target_include_directories(foo PUBLIC libfoo/includes)

target_link_libraries(otherlib PRIVATE foo) # (1)

Без строчки (1) include foo.hpp выдаст ошибку, а вот если путь указать то работать будет,
но отсутствие явно прописанных зависимостей не позволяет ускорить сборку.


П>3) порядок инклудов. Ведущие собаководы рекомендуют размещать "" перед <> и вообще располагать инклюды по мере специализации — более частные первыми — чтобы ловить ошибки, когда где-то чего-то не хватает, каждый хидер должен быть самодостаточным и всё такое.
П>Но у некоторых собаководов я встречал рекомендацию сортировать инклуды не только по "" и <>, но и по алфавиту, эта рекомендация несколько конфликтует с рекомендацией по ордеру по уровню специализации. Что думаете?

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

П>4) проект на CMake. Я бы понял, если бы кроссплатформа.

Ну у него есть много фишек, все возможные интеграции с разными инструментами от clang-tidy до ccache.
С кем нет интеграции можно использовать compile_commands.json который он умеет генерировать.

А то что он генерирует проекты кучу времени это очевидно баг. Для Qt и llvm он же не генерирует проекты
по несколько часов, максимум минут 10. Вряд ли у вас кодовая база больше.

И "Visual Studio" умеет же открывать CMakeLists.txt напрямую как проект,
так не будет быстрее, чем генерировать vcproj?

Здравствуйте, пффф, Вы писали:

П>Но у некоторых собаководов я встречал рекомендацию сортировать инклуды ... по алфавиту, эта рекомендация несколько конфликтует с рекомендацией по ордеру по уровню специализации. Что думаете?

Я думаю, если тут есть рациональное зерно, то оно в следующем. Такая рекомендация как миксер перемешивает инклуды и заставляет проявляться ситуации, когда от порядка инклудов не должно ничего зависеть, но что-то зависит.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, пффф, Вы писали:

Ой, надо же. Два раза на один и тот же постинг ответил. Ну и ладно, пусть будет. Хорошо хоть, ответил примерно одно и то же

Здравствуйте, Pzz, Вы писали:

Pzz>Ой, надо же. Два раза на один и тот же постинг ответил. Ну и ладно, пусть будет.

Его перенесли из другого форума в cpp.applied, вот он и всплыл


Pzz>Хорошо хоть, ответил примерно одно и то же

Было бы смешно, если бы ответил что-то противоположное первому ответу

Здравствуйте, sergii.p, Вы писали:

П>>2) #include без путей.
SP>единственный бонус вижу в том, что если включаемый файл куда-то переедет, не надо будет менять по коду все include.

Это если файл, а не каталог. Если вдруг надо выделить подпроект в отдельный проект, то правка затронет множество файлов... Короче: никаких путей в инклюдах — исходники не должны зависеть от файловой структуры.

Привет!

1) #include с угловыми скобками для своего барахла. Я привык так никогда не делать, давным давно, и уже и не соображу, чем плохо. Ну и эмоции, переполняющие при виде всего этого, мешают

2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

3) порядок инклудов. Ведущие собаководы рекомендуют размещать "" перед <> и вообще располагать инклюды по мере специализации — более частные первыми — чтобы ловить ошибки, когда где-то чего-то не хватает, каждый хидер должен быть самодостаточным и всё такое.
Но у некоторых собаководов я встречал рекомендацию сортировать инклуды не только по "" и <>, но и по алфавиту, эта рекомендация несколько конфликтует с рекомендацией по ордеру по уровню специализации. Что думаете?

4) проект на CMake. Я бы понял, если бы кроссплатформа. Но наша часть чисто виндовая. Генерация с CMake'ом полчаса-час, а нафуа? Полчаса — это ещё без сборки. Потом на сборочном серваке собирается при помощи NMake+JOM, а на девелоперских машинах чтобы в студии поотлаживаться — отдельно надо генерить студийные проекты, и этого нет в репе, каждый извращается как умеет. Я бы перевел бы всю систему сборки чисто под MSVC/MSBuild, там не так страшно, как кажется, если не использовать автоматом генерённые MSVC-проекты, а руками править ихний xml, и быть в курсе, что там тоже есть инклуды. Я давно так живу, и это пиздаточень удобно. За недельку другую я бы всё сделал бы на MSVC/MSBuild зашибись без говна CMake'а. По этому пункту в принципе я и сам обоснований накидаю, но может кто что-то новое скажет

Такие дела

1-3 — это какая-то мелочь. Если это самые большие "проблемы", то за вас можно только порадоваться. Но что-то мне подсказывает, что вы занимаетесь не тем, чем следовало бы заняться на проекте.

4 — тут важно понять мысль, что не все пользуются виндой, вижуальником и MSVC. Второе — некоторые проекты имеют свойство "перетекать" на другие платформы (поддержка Линукса и т.п.). Во всех этих случаях CMake будет только в плюс. Просто вы что-то делаете не так в вижле. И, как тут уже сказали, вижла давно умеет поднимать CMake-файлы из коробки, ничего там генерит не надо.

PS топик к управлению проектами не относится. Этот раздел форума не про вижуальне проекты (vcproj), а про проекты в смысле создания ПО (задачи, команда, ресурсы, менеджмент, вот это вот все).

Здравствуйте, DiPaolo, Вы писали:

DP>1-3 — это какая-то мелочь. Если это самые большие "проблемы", то за вас можно только порадоваться. Но что-то мне подсказывает, что вы занимаетесь не тем, чем следовало бы заняться на проекте.

Возможно ты прав


DP>4 — тут важно понять мысль, что не все пользуются виндой, вижуальником и MSVC. Второе — некоторые проекты имеют свойство "перетекать" на другие платформы (поддержка Линукса и т.п.). Во всех этих случаях CMake будет только в плюс. Просто вы что-то делаете не так в вижле.

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

DP>И, как тут уже сказали, вижла давно умеет поднимать CMake-файлы из коробки, ничего там генерит не надо.

Уметь то она умеет, но там но нафига они вообще нужны?


DP>PS топик к управлению проектами не относится. Этот раздел форума не про вижуальне проекты (vcproj), а про проекты в смысле создания ПО (задачи, команда, ресурсы, менеджмент, вот это вот все).

А топик и про проект в смысле создания ПО, в том числе

Здравствуйте, пффф, Вы писали:

П>1) #include с угловыми скобками для своего барахла.
Внешние глобальные зависимости (SDK например) в угловых, внутренние в обычных.

П>2) #include без путей.
Не вижу проблемы если на диске всё правильно организовано.

П>3) порядок инклудов.
Первым обязательно идёт одноимённый с .cpp — тогда всегда точно знаешь что он самодостаточен.
Остальные в общем то пофигу. У меня они добавляются через VAX Add Include а не руками. Я иногда причёсываю, группируя однотипные вместе но это скорее по зову чуЙства прекрасного чем какой либо практической необходимости.

П>Я бы перевел бы всю систему сборки чисто под MSVC/MSBuild
+1

Здравствуйте, пффф, Вы писали:

П>1) #include с угловыми скобками для своего барахла. Я привык так никогда не делать, давным давно, и уже и не соображу, чем плохо. Ну и эмоции, переполняющие при виде всего этого, мешают

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

Логично отделить одно от другого, чтобы другим модулям были видны только публичные хидеры, но не внутренние.

Единственный способ это сделать — выделить публичные хидеры в отдельную директорию, добавить ее в include path и включать их через угловые скобки. А внутренние хидеры модуля, в самом модуле включать через кавычки.

П>2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

Пути в include — это способ разделения namespace имен заголовочных файлов. Чтобы добавляя очередной заголовочный файл, не надо было париться, есть такой уже, или нет.

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

П>3) порядок инклудов. Ведущие собаководы рекомендуют размещать "" перед <> и вообще располагать инклюды по мере специализации — более частные первыми — чтобы ловить ошибки, когда где-то чего-то не хватает, каждый хидер должен быть самодостаточным и всё такое.
П>Но у некоторых собаководов я встречал рекомендацию сортировать инклуды не только по "" и <>, но и по алфавиту, эта рекомендация несколько конфликтует с рекомендацией по ордеру по уровню специализации. Что думаете?

Я пишу по алфавиту и не парюсь. Отдельно группирую (1) системные хидеры (2) публичные хидеры проекта (3) внутренние хидеры модуля. В каком порядке, не важно, но консистентно в пределах проекта. Так, по крайней мере, легко проверить, что какой-то хидер по ошибке не подцепили два раза.

Чтобы убедиться в самодостаточности хидера, надо придумать правило, благодаря которому каждый хидер хоть где-то включается самым первым. Например, логично, что если есть хидер foo.h, то имплементация заявленного в нем живет в файле foo.c, и вот именно в этом файле этот хидер включается самым первым, до всех остальных.

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

П>4) проект на CMake. Я бы понял, если бы кроссплатформа. Но наша часть чисто виндовая. Генерация с CMake'ом полчаса-час, а нафуа? Полчаса — это ещё без сборки. Потом на сборочном серваке собирается при помощи NMake+JOM, а на девелоперских машинах чтобы в студии поотлаживаться — отдельно надо генерить студийные проекты, и этого нет в репе, каждый извращается как умеет. Я бы перевел бы всю систему сборки чисто под MSVC/MSBuild, там не так страшно, как кажется, если не использовать автоматом генерённые MSVC-проекты, а руками править ихний xml, и быть в курсе, что там тоже есть инклуды. Я давно так живу, и это пиздаточень удобно. За недельку другую я бы всё сделал бы на MSVC/MSBuild зашибись без говна CMake'а. По этому пункту в принципе я и сам обоснований накидаю, но может кто что-то новое скажет

CMake тошнотворен уже тем, что использует расширение .txt для своих служебных файлов. Ну какой, нахрен, .txt, в них же не "Понедельник начинается в субботу" Стругацких записан, а код на мутном языке программирования.

П>Такие дела

Угу.

Здравствуйте, Pzz, Вы писали:

Pzz>Чтобы убедиться в самодостаточности хидера, надо придумать правило, благодаря которому каждый хидер хоть где-то включается самым первым. Например, логично, что если есть хидер foo.h, то имплементация заявленного в нем живет в файле foo.c, и вот именно в этом файле этот хидер включается самым первым, до всех остальных.
Pzz>Это не я, кстати придумал, а один мой очень умный коллега несколько работ назад.
Это правило ещё с прошлого века известно. Похоже народ его переоткрывает раз за разом.

Pzz>CMake тошнотворен уже тем, что использует расширение .txt для своих служебных файлов.
+1

Здравствуйте, пффф, Вы писали:

Pzz>>Хорошо хоть, ответил примерно одно и то же

П>Было бы смешно, если бы ответил что-то противоположное первому ответу

С меня станется

Здравствуйте, пффф, Вы писали:

П>1) #include с угловыми скобками для своего барахла. Я привык так никогда не делать, давным давно, и уже и не соображу, чем плохо.

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

П>2) #include без путей.

единственный бонус вижу в том, что если включаемый файл куда-то переедет, не надо будет менять по коду все include.

П>3) порядок инклудов. ... Что думаете?

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

П>4) проект на CMake. Я бы понял, если бы кроссплатформа. Но наша часть чисто виндовая.

тогда используйте студию и каждый день благодарите всевышнего за это

Вопрос к высказавшимся за то, что одноимённый инклудник должен идти первым.

Коллеги, я правильно понял, что precompiled headers вы не используете?

Здравствуйте, Conductor, Вы писали:

C>Вопрос к высказавшимся за то, что одноимённый инклудник должен идти первым.

C>Коллеги, я правильно понял, что precompiled headers вы не используете?
На ручнике нет, при правильной организации include (каждый header первым включает master header в котором собраны основные FW + SDK includes) нормальный промышленный компилер разруливает это всё сам.

Здравствуйте, Conductor, Вы писали:

C>Вопрос к высказавшимся за то, что одноимённый инклудник должен идти первым.

C>Коллеги, я правильно понял, что precompiled headers вы не используете?

Я использую. clang/gcc не накладывают никаких ограничений на то как должен
писать код программист при использовании "precompiled headers".
Можно передавать "-include" параметр gcc/clang, можно рядом с каждым заголовчным
файлом положить ".pch" / ".gch" файл, и gcc/clang если их увидят, будут использовать их,
а не парсить исходники.

Здравствуйте, CreatorCray, Вы писали:

C>>Коллеги, я правильно понял, что precompiled headers вы не используете?
CC>На ручнике нет, при правильной организации include (каждый header первым включает master header в котором собраны основные FW + SDK includes) нормальный промышленный компилер разруливает это всё сам.

Прости, пожалуйста: 1. "на ручнике" — имеется в виду "явно не прописываются"? 2. под "промышленным", в данном контексте, что следует понимать?

Здравствуйте, Zhendos, Вы писали:

C>>Коллеги, я правильно понял, что precompiled headers вы не используете?

Z>Я использую. clang/gcc не накладывают никаких ограничений на то как должен
Z>писать код программист при использовании "precompiled headers".
Z>Можно передавать "-include" параметр gcc/clang, можно рядом с каждым заголовчным
Z>файлом положить ".pch" / ".gch" файл, и gcc/clang если их увидят, будут использовать их,
Z>а не парсить исходники.

Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Здравствуйте, Conductor, Вы писали:

C>Здравствуйте, Zhendos, Вы писали:

C>Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Ну здесь два рубежа защиты,
во-первых cmake'овском target_precompile_headers есть опция PRIVATE,
и значит за пределах библиотеки этот заголовочный файл не вылезет,
во-вторых CI, которая собриает без "precompile headers",
уж там-то все ошибки вылезут.

Здравствуйте, Zhendos, Вы писали:

C>>Вопрос в данном случае о работоспособности концепции "проверка самодостаточности инклудника". Я сам gcc (ну и опосредованно clang) использую + cmake + ninja, и получается, что при включении какого-либо инклудника в precompiled используемые в нем инклудники на автомате становятся видны остальным.

Z>Ну здесь два рубежа защиты,
Z>во-первых cmake'овском target_precompile_headers есть опция PRIVATE,
Z>и значит за пределах библиотеки этот заголовочный файл не вылезет,
Z>во-вторых CI, которая собриает без "precompile headers",
Z>уж там-то все ошибки вылезут.

Да понятно, что всё можно сделать, используя как технические методы, так и организационные. Вопрос только в стоимости овчинки и выделки, целесообразности и важности этих мероприятий. Один случай, когда либа отдаётся на сторону как продукт (особенно в исходниках), тогда да, API-хедера должны быть вылизаны по полной. И другой случай если это внутренние компоненты, рамки продукта не покидающие. Понятно, что единообразие приводит к меньшему бардаку, но преувеличивать значение и рассматривать самодостаточность всех хедеров как архиважный и архипринципиальный вопрос я бы не стал. Всё же в рамках большого продукта достаточное количество более существенных проблем.

Здравствуйте, Conductor, Вы писали:

C>1. "на ручнике" — имеется в виду "явно не прописываются"?
Имеется в виду не надо производить какие то специальные действия, типа копирования файлов или прописывание конкретного файла в опции компилятора.
Компилятор сам анализирует где и что можно reuse

C>2. под "промышленным", в данном контексте, что следует понимать?
Тот же ICC например.

Здравствуйте, Zhendos, Вы писали:

П>>2) #include без путей. Вот везде в сорцах инклуды практически везде без путей — чисто имя файла без всего вот такого "somelib/impl/helpers/bla-bla-helper.h", а тупо #include "bla-bla-helper.h" или даже <bla-bla-helper.h>, но компилятору зато подсовываются все всевозможные пути поиска инклудов. Есть аргумент за то, чтобы ничего не менять — всё же собирается и работает. Но это какое-то гавно

Z>Наоборот, очень важно не использовать или ограниченно использовать пути
Z>в "больших" проектах. В "больших" проектах очень важно контролировать граф зависимостей
Z>на уровне системы сборки, а не на уровне исходников. И не использование путей в include,
Z>заставляет прописывать зависимости в системе сборки.
Z>Например:

Z>

Z>add_library(foo OBJECT foo.cpp foo.hpp)
Z>target_include_directories(foo PUBLIC libfoo/includes)

Z>target_link_libraries(otherlib PRIVATE foo) # (1)
Z>

Z>Без строчки (1) include foo.hpp выдаст ошибку, а вот если путь указать то работать будет,
Z>но отсутствие явно прописанных зависимостей не позволяет ускорить сборку.

Есть такая практика — собирать каждый таргет в своей песочнице. Тогда забытая зависимость — неважно, укажешь абсолютный путь или относительный — сразу вылезет. Симлинков на нужные папки с хедерами не окажется в песочнице.
Правда, я не знаю, как это можно сделать в голом симейке.
В ниндзе и базеле это решается с помощью магии. (Я эту магию сам не настраивал, но вовсю пользуюсь).