Надо ли еще применять такие предохранительные конструкции?
В С++ я так делал всегда.
Как правило, дефайн делал "с глобальными признаками" - подчеркиванием и капсом: _ORDER_H_
В MQL уже давно не пользуюсь. Насколько я понимаю - при первом инклюде - файл включается в компиляцию, и при последующих инклюдах - он уже не дублируется.
В С++ я так делал всегда.
Как правило, дефайн делал "с глобальными признаками" - подчеркиванием и капсом: _ORDER_H_
В MQL уже давно не пользуюсь. Насколько я понимаю - при первом инклюде - файл включается в компиляцию, и при последующих инклюдах - он уже не дублируется.
Да, так должно быть. Но МК иногда в процессе добавления нового мочат старое. В том билде этот механизм бул отключен. Так что наверное не буду я торопиться, оставлю эти дефайны.
всегда использую правило одного включения, не важно какой компилятор, это спасает от детских ошибок в дальнейшем
У меня довольно большая папка cо своими классами, каждый в отдельном .mqh. И в них стоят инклуды на другие классы. Так что при сборке иногда получаются перекрестные включения. Вообще, омпилятор, точнее препроцесор должен это отслеживать, но такие дефайны подстраховывают.
Когда-то давным-давно в Visual Studio вроде до версии 6.0 включительно было принято в .h файлах (аналог .mqh) обрамлять код вот такими дефайнами
Смысл этого трюка в том, что если есть перекрестные включения двух .mqh файлов, то для избежания реальных множественных включений при компиляции такие дефайны спасали ситуацию. Конечно, это было следствием несовершенства тогдашнего компилятора, который тупо вставлял все #include без проверки того, что файл уже был вставлен.
И вот год или более назад вышла какая-то версия MQL4, после обновления мой робот отказался компилироваться, хотя до этого все было нормально. Высыпались десятки ошибок, я был в панике, потом вспомнил старые времена, все .mqh обрамил вот такими дефайнами и проект стал нормально компилироваться. В следующей версии этот баг пофиксили.
Как говорится, ложечка нашлась, а осадочек остался ))
Что делать в моей личной библиотеке, я перевожу ее на кроссплатформенность. Оставлять эти предохранительные дефайны или можно быть уверенным, что баг не всплывет снова?
Сейчас в VS есть директива:
#pragma onceОна как раз и гарантирует исключение дубляжа. В MQL пока с таким не встречался. Поэтому приходится самому отслеживать очередность включения файлов, строя свою иерархическую систему включения.
Сейчас в VS есть директива:
Она как раз и гарантирует исключение дубляжа. В MQL пока с таким не встречался. Поэтому приходится самому отслеживать очередность включения файлов, строя свою иерархическую систему включения.
В MQL4/5 препроцесор автоматом все это делает, можете проверить. Просто тогда была ошибка в препроцессоре.
ЗЫ: в плюсах еще есть директива покруче #include guards
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Когда-то давным-давно в Visual Studio вроде до версии 6.0 включительно было принято в .h файлах (аналог .mqh) обрамлять код вот такими дефайнами
Смысл этого трюка в том, что если есть перекрестные включения двух .mqh файлов, то для избежания реальных множественных включений при компиляции такие дефайны спасали ситуацию. Конечно, это было следствием несовершенства тогдашнего компилятора, который тупо вставлял все #include без проверки того, что файл уже был вставлен.
И вот год или более назад вышла какая-то версия MQL4, после обновления мой робот отказался компилироваться, хотя до этого все было нормально. Высыпались десятки ошибок, я был в панике, потом вспомнил старые времена, все .mqh обрамил вот такими дефайнами и проект стал нормально компилироваться. В следующей версии этот баг пофиксили.
Как говорится, ложечка нашлась, а осадочек остался ))
Что делать в моей личной библиотеке, я перевожу ее на кроссплатформенность. Оставлять эти предохранительные дефайны или можно быть уверенным, что баг не всплывет снова?