[культура прогр-я] вложенные хедеры

a10063

не могу для себя решить, как лучше поступать с вложенными хедерами
например:
a.c использует хедер b.h (вызываются ф-ии, определенные в нем)
b.h использует c.h (структуры в нем)
вопрос: если a.c использует функции из c.h, нужно ли вписывать инклюд c.h в a.h, учитывая, что в c.h стоит проверка на множественные включения?
т.е. я понимаю, что можно не вписывать с точки зрения компилятора, но это скорее вопрос стиля или культуры прогр-я, даже не знаю точно...
как вы думаете?

yolki

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

Maurog

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

a10063

отказ от функций будет не в хедере, а в си-файле

насколько я понял, имел ввиду не функции, а что-то вроде структур (скажем, когда b.h перестает описывать заголовки функций со структурами из c.h)

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

мне кажется, что это не совсем по вопросу
ведь вложенные хедеры иногда необходимы (скажем, когда b.h описывает заголовки функций со структурами из c.h)
дело в другом: нужно ли "показывать" инклюдом c.h в a.c, что в a.c явным образом используются описания из c.h, или нет и насколько это полезно или вредно с точки зрения разработки
с одной стороны, я согласен с
с другой, если b.h может выполнять функцию группировки других хедеров и в a.c лишние инклюды будут лишь мешать, а не подчеркивать (когда файлов подобных c.h с десяток или больше)
хочется найти в одном из вариантов больше плюсов, чем в другом, и пользоваться...

yolki

Для группировки файлов можно использовать, но не более.
А постоянно держать в голове конструкции вида "b.h уже заинклюдил c.h, поэтому его инклюдить больше не надо" - это нерационально.
Например, windows.h инклюдит winnt.h, который инклюдит ctype.h
И что, если мне понадобилась функция isalnum то типа вспоминать, что ctype уже заинклюден из windows.h?

Ivan8209

А приём #ifndef-#define-#endif просто так придумали?
Если более низкоуровневые заголовки используются напрямую ---
включать, иначе пусть используются вложенные.
А зависимости описывать --- в Makefile.
---
...Я работаю антинаучным аферистом...

yolki

Так я в пользу того и говорю - что грамотнее писать
#include <windows.h>
#include <ctype.h>
не взирая на то, что windows.h уже подключила ctype.h
а условная компиляция на месте уже разрулит всё что нужно

sergey_m

Так я в пользу того и говорю - что грамотнее писать
#include <windows.h>
#include <ctype.h>

Наверное уж в обратном порядке.

Ivan8209

> Наверное уж в обратном порядке.
"жу"?
---
...Я работаю антинаучным аферистом...

a10063

не понял
какую роль здесь играет порядок?

Ivan8209

Эстетическую.
---
...Я работаю антинаучным аферистом...

sergey_m

> какую роль здесь играет порядок?
Указанный порядок работает только потому, что windows.h сама включает ctype.h. Если бы этого не было, то не заработало бы.