IPB
ЛогинПароль:

 
 Ответить  Открыть новую тему 
> Порядок Хидеров.
сообщение
Сообщение #1


Профи
****

Группа: Пользователи
Сообщений: 652
Пол: Мужской
Реальное имя: Алексей

Репутация: -  20  +


Тут поднялся вопрос
Цитата
Цитата
но вообще не используются,то ошибкой это назвать нельзя,это просто бесполезные строчки кода,единсвенное,что они делают это захламляют программу и возможно(точно не уверен) увеличивают время сборки проекта.На работоспособность они никак не влияют
Это неверное утверждение. Даже порядок подключения хидеров влияет на работоспособность, особенно в С++. Если интересно - подберу несколько ярких примеров. Но об этом - не здесь

Собственно вопрос интересный.Вариант,когда влияет последовательность самописных хидеров вместе с базовыми библиотеками не интересует,так как сталкивался с этим сам(мультифайловый проект или как там его называют).А вот вариант когда последовательность присоединения базовых хидеров,или наличие лишних влияет на компилируемость,работоспособность весьма интересна.

Сообщение отредактировано: Krjuger -
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #2


Гуру
*****

Группа: Пользователи
Сообщений: 1 013
Пол: Мужской
Ада: Разработчик
Embarcadero Delphi: Сторонник
Free Pascal: Разработчик

Репутация: -  627  +


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

Ну, там на самом деле много было примеров, когда при подключении хидеров в одной последовательности (причем, так, как их ставил сам Билдер), программа не компилировалась. Стоило переставить заголовки в другом порядке - все начинало работать. Что-то сразу найти не могу, но в трех обсуждениях подобных глюков я участвовал на Сурсах, как минимум. Найду - дам ссылку. Можешь сам поискать...

Точно так же, многие любят работать одновременно с .H и .Hpp - файлами, в одном проекте. И втыкать куда надо и куда не надо using namespace... Это тоже может привести к проблемам. Мало ли, одна функция/класс описана отдельно, а другая - в своем пространстве имен. Ты сделал using namespace, и перемешал эти 2 сущности. Теперь как компилятор должен знать, какую ты имел в виду?
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 

 Ответить  Открыть новую тему 
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 





- Текстовая версия 19.04.2024 7:52
500Gb HDD, 6Gb RAM, 2 Cores, 7 EUR в месяц — такие хостинги правда бывают
Связь с администрацией: bu_gen в домене octagram.name