Компилирование заголовочных файлов или документация на халяву

[al_one]

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

[pixelshader]

теперь понимаю, что в этом действительно есть смысл, но во всех проектах, что мне до этого попадались была обратная практика «постепенного уточнения»: сначала stl, потом сторонние библиотеки (например, boost), потом собственные стандартные библиотеки и только потом инклуды того, что находится поблизости.

[pixelshader]

похоже надо этот порядок инвертировать)

[al_one]

Ну не надо полностью инвертировать). Нужно только один хедер file.h поместить первым именно в file.cpp. А в других .cpp включать его как обычно после стандартных хедеров.

[pixelshader]

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

[EndUser]

Отладочные макросы, вызывающие vfprintf(...) полетят…

[pixelshader]

Есть еще один нюанс: в MS Visual Studio мы используем pch, и тогда это неприменимо.

[pogorskiy]

внутри pch включать опцию define-ом типа PROJECT_PCH_OFF и собирать тестовую сборку без них

stdafx.h:
#ifndef STDAFX_H_
#define STDAFX_H_
#ifndef PROJECT_PCH_OFF
#include <boost/shared_ptr.hpp>
//...
#endif
#endif



[pixelshader]

можно и так, но тогда для валидации заголовочных файлов все равно придется выполнять компиляцию в специальном режиме (потому что работать штатно без pch слишком медленно).
И непонятно кто будет гарантировать, что хедер file.h стоит первым именно в file.cpp?

[pogorskiy]

Я имел в виду, что придерживаться правила ставить хедер на первое место, иначе смысла нет, гарантировать никто не сможет. И штатно работать с pch время от времени проверяя компилируемость хедеров.

[tangro]

>… собственном диалекте из макросов… Думаю ситуация такая знакома многим C++ девелоперам.

Боже упаси.

[pixelshader]

Безусловно соглашусь, что в C++ есть много альтернатив макросам, но часто приходится иметь дело с тем, что есть.

[ivan2kh]

Если дело происходит в техническом ВУЗе, то такие выкрутасы вполне можно переписать. На вас же финансами не давят. Заодно, будет, что студентам показать.

[pixelshader]

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

[Gorthauer87]

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

[elmm]

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

Всё таки у них проблема была не из зам макросов а из за кривых заголовочных файлов.

[Gorthauer87]

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

[pixelshader]

Думаю, следует сказать, что описываемая в посте проблема решилась в основном благодаря добавлению в те файлы, на которые указал gcc, инклудов на stl и наши собственные хедеры, еще в нескольких местах пришлось повозиться из-за шаблонов. Но зато теперь dpxygen без проблем строит документацию по всему проекту.
А то как-то все переходит на обсуждение макросов, которые были виноваты лишь косвенно)

[Unforgiven]

У Вас в проекте используются include guards? Сам получаю такое предупреждение:
warning: #pragma once in main file

[pixelshader]

да, у нас в проекте стражи включения на макросах (как Страуструп учил)

[Andruh]

> Но здесь вышла некоторая заминка связанная с нежеланием gcc принимать на вход выход команды ls через конвейер.
xargs? В крайнем случае xargs -d"\n":
find… | xargs -d"\n" gcc -c -x c++ -I

[Paul]

Лучше наверное find… -print0 | xargs -0 заодно не нужно будет думать о путях с пробелами.

[yetanotherman]

как-то так имхо нагляднее:

gcc -c -x c++ -I./ `find. -name *.h`

[silvansky]

Мораль: лучше заранее думать о самодостаточности хедеров.

[pixelshader]

Думать-то всегда надо, но вот как ГАРАНТИРОВАТЬ их самодостаточность?) особенно в автоматическом режиме.
в этом-то и вопрос.

[silvansky]

Гарантировать — как и писали выше, включать их первыми всегда.

[pixelshader]

нет. потому что программы как правило пишут люди, а они ошибаются. и компилятор не скажет им, что данное правило нарушено!
а под гарантиями я подразумеваю некоторое сообщение об ошибке или предупреждение, которое мне об этом скажет.
ЗЫ да и не все могут согласиться с таким стилем инклудов, при котором сначала «свой родной» хедер, а уже потом по нарастающей.
ЗЗЫ и использование pch усложняет эту задачу

[silvansky]

От человеческого фактора нет спасения, тут уж как ни крутись =)
Но можно изначально минимализировать риски, если следовать определённым правилам.

[pixelshader]

безусловно)
но я все-таки предложил вариант, который в автоматическом режиме проводит валидацию хедеров.
но вряд ли он совершенен (там вообще пока вариант только для gcc), так что я ожидал в первую очередь от хабра предложений по его улучшению, а не «пишите правильно, господа, и будет вам счастье!» :)

[pogorskiy]

под студию можно в проекте для всех хедеров указать в Build Tool C/С++ Compiler и откомпилировать их (разумеется, в таком виде проект подходит только для валидации)

[pixelshader]

это интересно, надо посмотреть что из этого может получиться.

[Goder]

Используйте проверку стиля для кода — можно будет проверять включение хедеров, к примеру.
Гляньте на гуглогайд: http://code.google.com/p/google-styleguide/
В том же репозитории есть линт для проверки соответствия С++ гайду.
Хук на прекоммит — и счастье в кармане. :)

[Goder]

Вашу ситуацию проверяет из коробки, кстати. :)

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

[Wyrd]

«Но вовремя остановился я, ибо понял в чем отличие его от компилятора.»…

Вот спасибо Вам огромное за эту праведную мысль.

[Derailed]

Чтобы быстро вкрутить в свой проект систему документации Doxugen (с минимальными потерями нервных клеток и времени) — ИМХО лучше всего взять за основу готовый пример такого проекта, хорошо документированного и известного. И желательно не очень большого и сложного. Хороший кандидат в качестве такого примера — библиотека USB LUFA (микроконтроллеры Atmel AVR USB). В ней очень гармонично и аккуратно используется Doxygen.

[pixelshader]

спасибо, посмотрю.
хороший пример — это всегда здорово, сам как-то искал)