Цитата
А вот вариант когда последовательность присоединения базовых хидеров,или наличие лишних влияет на компилируемость,работоспособность весьма интересна.
В подключенном к программе хидер-файле (в своем неймспейсе, этот файл может быть и базовым, как ты выражаешься) описан идентификатор, скажем, перечисление (т.е., enum), или член перечисления. Ты его в своей программе используешь. Все прекрасно и удивительно. Пока ты не подключаешь другой понадобившийся тебе файл, где такой же идентификатор встречается в другом неймспейсе. Приплыли, программа больше не компилируется, из-за неоднозначности, надо вручную указывать, какой именно идентификатор тебя интересует. Кто программировал на Билдере встречались с этим сплошь и рядом. Скажем, в 10-й Indy в файле <IdGlobals.hpp> была описана функция Sleep, которая обламывала использование стандартной виндовой функции с тем же именем. Потому что одна принимала параметр типа unsigned long, а вторая - типа unsigned int. И когда ты писал Sleep(1000), компилятор разрывался между выбором: привести эту 1000 к длинному целому или к обычному... Я надеюсь, заголовки Indy в Билдере не считаются самописными?
Ну, там на самом деле много было примеров, когда при подключении хидеров в одной последовательности (причем, так, как их ставил сам Билдер), программа не компилировалась. Стоило переставить заголовки в другом порядке - все начинало работать. Что-то сразу найти не могу, но в трех обсуждениях подобных глюков я участвовал на Сурсах, как минимум. Найду - дам ссылку. Можешь сам поискать...
Точно так же, многие любят работать одновременно с .H и .Hpp - файлами, в одном проекте. И втыкать куда надо и куда не надо using namespace... Это тоже может привести к проблемам. Мало ли, одна функция/класс описана отдельно, а другая - в своем пространстве имен. Ты сделал using namespace, и перемешал эти 2 сущности. Теперь как компилятор должен знать, какую ты имел в виду?