Комментарии 36
Поэтому рекомендуют инклюдить заголовочный файл в его собственный .cpp файл первым, перед всеми остальными даже стандартными.
+3
теперь понимаю, что в этом действительно есть смысл, но во всех проектах, что мне до этого попадались была обратная практика «постепенного уточнения»: сначала stl, потом сторонние библиотеки (например, boost), потом собственные стандартные библиотеки и только потом инклуды того, что находится поблизости.
0
похоже надо этот порядок инвертировать)
+1
Ну не надо полностью инвертировать). Нужно только один хедер file.h поместить первым именно в file.cpp. А в других .cpp включать его как обычно после стандартных хедеров.
0
Есть еще один нюанс: в MS Visual Studio мы используем pch, и тогда это неприменимо.
0
внутри pch включать опцию define-ом типа PROJECT_PCH_OFF и собирать тестовую сборку без них
stdafx.h:
stdafx.h:
#ifndef STDAFX_H_
#define STDAFX_H_
#ifndef PROJECT_PCH_OFF
#include <boost/shared_ptr.hpp>
//...
#endif
#endif
+1
можно и так, но тогда для валидации заголовочных файлов все равно придется выполнять компиляцию в специальном режиме (потому что работать штатно без pch слишком медленно).
И непонятно кто будет гарантировать, что хедер file.h стоит первым именно в file.cpp?
И непонятно кто будет гарантировать, что хедер file.h стоит первым именно в file.cpp?
0
>… собственном диалекте из макросов… Думаю ситуация такая знакома многим C++ девелоперам.
Боже упаси.
Боже упаси.
+11
Безусловно соглашусь, что в C++ есть много альтернатив макросам, но часто приходится иметь дело с тем, что есть.
+1
Вот хочется этим людям ударить книжкой страуструпа по лбу и заставить всё переписывать так, чтобы макросов было по минимуму.
+3
Жизнь не не идеальна, так что порой без макросов ни как не обойтись.
Макросы не зло, но чрезмерное увлечение чем-то, попытка применять это не везде где оно приемлемо, бавет чревата.
Всё таки у них проблема была не из зам макросов а из за кривых заголовочных файлов.
Макросы не зло, но чрезмерное увлечение чем-то, попытка применять это не везде где оно приемлемо, бавет чревата.
Всё таки у них проблема была не из зам макросов а из за кривых заголовочных файлов.
0
Думаю, следует сказать, что описываемая в посте проблема решилась в основном благодаря добавлению в те файлы, на которые указал gcc, инклудов на stl и наши собственные хедеры, еще в нескольких местах пришлось повозиться из-за шаблонов. Но зато теперь dpxygen без проблем строит документацию по всему проекту.
А то как-то все переходит на обсуждение макросов, которые были виноваты лишь косвенно)
А то как-то все переходит на обсуждение макросов, которые были виноваты лишь косвенно)
0
У Вас в проекте используются include guards? Сам получаю такое предупреждение:
warning: #pragma once in main file
warning: #pragma once in main file
0
> Но здесь вышла некоторая заминка связанная с нежеланием gcc принимать на вход выход команды ls через конвейер.
xargs? В крайнем случае xargs -d"\n":
find… | xargs -d"\n" gcc -c -x c++ -I
xargs? В крайнем случае xargs -d"\n":
find… | xargs -d"\n" gcc -c -x c++ -I
0
Мораль: лучше заранее думать о самодостаточности хедеров.
0
Думать-то всегда надо, но вот как ГАРАНТИРОВАТЬ их самодостаточность?) особенно в автоматическом режиме.
в этом-то и вопрос.
в этом-то и вопрос.
0
Гарантировать — как и писали выше, включать их первыми всегда.
0
нет. потому что программы как правило пишут люди, а они ошибаются. и компилятор не скажет им, что данное правило нарушено!
а под гарантиями я подразумеваю некоторое сообщение об ошибке или предупреждение, которое мне об этом скажет.
ЗЫ да и не все могут согласиться с таким стилем инклудов, при котором сначала «свой родной» хедер, а уже потом по нарастающей.
ЗЗЫ и использование pch усложняет эту задачу
а под гарантиями я подразумеваю некоторое сообщение об ошибке или предупреждение, которое мне об этом скажет.
ЗЫ да и не все могут согласиться с таким стилем инклудов, при котором сначала «свой родной» хедер, а уже потом по нарастающей.
ЗЗЫ и использование pch усложняет эту задачу
0
От человеческого фактора нет спасения, тут уж как ни крутись =)
Но можно изначально минимализировать риски, если следовать определённым правилам.
Но можно изначально минимализировать риски, если следовать определённым правилам.
0
безусловно)
но я все-таки предложил вариант, который в автоматическом режиме проводит валидацию хедеров.
но вряд ли он совершенен (там вообще пока вариант только для gcc), так что я ожидал в первую очередь от хабра предложений по его улучшению, а не «пишите правильно, господа, и будет вам счастье!» :)
но я все-таки предложил вариант, который в автоматическом режиме проводит валидацию хедеров.
но вряд ли он совершенен (там вообще пока вариант только для gcc), так что я ожидал в первую очередь от хабра предложений по его улучшению, а не «пишите правильно, господа, и будет вам счастье!» :)
0
Используйте проверку стиля для кода — можно будет проверять включение хедеров, к примеру.
Гляньте на гуглогайд: http://code.google.com/p/google-styleguide/
В том же репозитории есть линт для проверки соответствия С++ гайду.
Хук на прекоммит — и счастье в кармане. :)
Гляньте на гуглогайд: http://code.google.com/p/google-styleguide/
В том же репозитории есть линт для проверки соответствия С++ гайду.
Хук на прекоммит — и счастье в кармане. :)
0
Вашу ситуацию проверяет из коробки, кстати. :)
C:\Sources\google-styleguide-read-only\cpplint>cpplint.py C:\Sources\PMAHomeworks\ThirdWork\ThirdWork.cpp
C:\Sources\PMAHomeworks\ThirdWork\ThirdWork.cpp:3: Found C system header afterother header. Should be: ThirdWork.h, c system, c++ system, other. [build/include_order] [4]
Done processing C:\Sources\PMAHomeworks\ThirdWork\ThirdWork.cpp
Total errors found: 1
0
«Но вовремя остановился я, ибо понял в чем отличие его от компилятора.»…
Вот спасибо Вам огромное за эту праведную мысль.
Вот спасибо Вам огромное за эту праведную мысль.
0
Чтобы быстро вкрутить в свой проект систему документации Doxugen (с минимальными потерями нервных клеток и времени) — ИМХО лучше всего взять за основу готовый пример такого проекта, хорошо документированного и известного. И желательно не очень большого и сложного. Хороший кандидат в качестве такого примера — библиотека USB LUFA (микроконтроллеры Atmel AVR USB). В ней очень гармонично и аккуратно используется Doxygen.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Компилирование заголовочных файлов или документация на халяву