Comments 36
Поэтому рекомендуют инклюдить заголовочный файл в его собственный .cpp файл первым, перед всеми остальными даже стандартными.
теперь понимаю, что в этом действительно есть смысл, но во всех проектах, что мне до этого попадались была обратная практика «постепенного уточнения»: сначала stl, потом сторонние библиотеки (например, boost), потом собственные стандартные библиотеки и только потом инклуды того, что находится поблизости.
Есть еще один нюанс: в MS Visual Studio мы используем pch, и тогда это неприменимо.
внутри 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
>… собственном диалекте из макросов… Думаю ситуация такая знакома многим C++ девелоперам.
Боже упаси.
Боже упаси.
Безусловно соглашусь, что в C++ есть много альтернатив макросам, но часто приходится иметь дело с тем, что есть.
Вот хочется этим людям ударить книжкой страуструпа по лбу и заставить всё переписывать так, чтобы макросов было по минимуму.
Думаю, следует сказать, что описываемая в посте проблема решилась в основном благодаря добавлению в те файлы, на которые указал gcc, инклудов на stl и наши собственные хедеры, еще в нескольких местах пришлось повозиться из-за шаблонов. Но зато теперь dpxygen без проблем строит документацию по всему проекту.
А то как-то все переходит на обсуждение макросов, которые были виноваты лишь косвенно)
А то как-то все переходит на обсуждение макросов, которые были виноваты лишь косвенно)
У Вас в проекте используются include guards? Сам получаю такое предупреждение:
warning: #pragma once in main file
warning: #pragma once in main file
> Но здесь вышла некоторая заминка связанная с нежеланием 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
Мораль: лучше заранее думать о самодостаточности хедеров.
Думать-то всегда надо, но вот как ГАРАНТИРОВАТЬ их самодостаточность?) особенно в автоматическом режиме.
в этом-то и вопрос.
в этом-то и вопрос.
Гарантировать — как и писали выше, включать их первыми всегда.
нет. потому что программы как правило пишут люди, а они ошибаются. и компилятор не скажет им, что данное правило нарушено!
а под гарантиями я подразумеваю некоторое сообщение об ошибке или предупреждение, которое мне об этом скажет.
ЗЫ да и не все могут согласиться с таким стилем инклудов, при котором сначала «свой родной» хедер, а уже потом по нарастающей.
ЗЗЫ и использование pch усложняет эту задачу
а под гарантиями я подразумеваю некоторое сообщение об ошибке или предупреждение, которое мне об этом скажет.
ЗЫ да и не все могут согласиться с таким стилем инклудов, при котором сначала «свой родной» хедер, а уже потом по нарастающей.
ЗЗЫ и использование pch усложняет эту задачу
От человеческого фактора нет спасения, тут уж как ни крутись =)
Но можно изначально минимализировать риски, если следовать определённым правилам.
Но можно изначально минимализировать риски, если следовать определённым правилам.
безусловно)
но я все-таки предложил вариант, который в автоматическом режиме проводит валидацию хедеров.
но вряд ли он совершенен (там вообще пока вариант только для gcc), так что я ожидал в первую очередь от хабра предложений по его улучшению, а не «пишите правильно, господа, и будет вам счастье!» :)
но я все-таки предложил вариант, который в автоматическом режиме проводит валидацию хедеров.
но вряд ли он совершенен (там вообще пока вариант только для gcc), так что я ожидал в первую очередь от хабра предложений по его улучшению, а не «пишите правильно, господа, и будет вам счастье!» :)
Используйте проверку стиля для кода — можно будет проверять включение хедеров, к примеру.
Гляньте на гуглогайд: http://code.google.com/p/google-styleguide/
В том же репозитории есть линт для проверки соответствия С++ гайду.
Хук на прекоммит — и счастье в кармане. :)
Гляньте на гуглогайд: http://code.google.com/p/google-styleguide/
В том же репозитории есть линт для проверки соответствия С++ гайду.
Хук на прекоммит — и счастье в кармане. :)
Вашу ситуацию проверяет из коробки, кстати. :)
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
«Но вовремя остановился я, ибо понял в чем отличие его от компилятора.»…
Вот спасибо Вам огромное за эту праведную мысль.
Вот спасибо Вам огромное за эту праведную мысль.
Чтобы быстро вкрутить в свой проект систему документации Doxugen (с минимальными потерями нервных клеток и времени) — ИМХО лучше всего взять за основу готовый пример такого проекта, хорошо документированного и известного. И желательно не очень большого и сложного. Хороший кандидат в качестве такого примера — библиотека USB LUFA (микроконтроллеры Atmel AVR USB). В ней очень гармонично и аккуратно используется Doxygen.
Sign up to leave a comment.
Компилирование заголовочных файлов или документация на халяву