std::vector<T>::iterator, оптимальное названия макроса по разыменовыванию итераторов в MQL (детали в первом посте) - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Попробуйте передать const int.
А насчёт ошибки компиляции - так вы обратите внимание, в каком месте она возникает. И как вы собираетесь искать первоисточник ошибки. Здесь то у вас всё очевидно, т.к. весь код перед глазами. А если ваш проект содержит кучу файлов, и данный метод вызывается из сотен мест в программе? Причём он мог быть вызван не напрямую, а опосредовано, из других шаблонов. Т.е. чтобы добраться до сути, придётся разматывать весь клубок шаблонных переходов. Я в своё время хлебнул горя с этим в MQL. Теперь напрямую шаблонные методы практически не вызываю. Только посредством обёртки из макроса, выполняющего предварительные проверки наподобие Sfinae.
Без поддержки SFINAE, шаблоны - тот ещё гемор.
с поддержкой тоже. начинал карьеру девелопера на проекте, где главный разработчик весьма любил шаблоны. Настолько весьма, что на них было практически все (из-за них потом уперлись в проблему размера pdb)
так вот SFINAE делает этот гемор немного удобнее, листинг подстановки не пять страниц, а две ) ну и ошибки нагляднее, но это все равно гемор.
А все что нужно для sfinae это нормальные typedef-ы внутри классов.
с поддержкой тоже. начинал карьеру девелопера на проекте, где главный разработчик весьма любил шаблоны. Настолько весьма, что на них было практически все (из-за них потом уперлись в проблему размера pdb)
так вот SFINAE делает этот гемор немного удобнее, листинг подстановки не пять страниц, а две ) ну и ошибки нагляднее, но это все равно гемор.
А все что нужно для sfinae это нормальные typedef-ы внутри классов.
Да, там конечно бывает гемор в их громоздкости и мудрёности. Но зато один раз написал - и всё, дальше спокойно пользуешься. А здесь это превращается в постоянный квест. Кстати иногда даже в библиотеке STL оказывается пропущена какая-то из необходимых sfinae-проверок, в результате чего получаем ошибку компиляции где-то в недрах их библиотек. И вот там разобраться - это уже гемор в квадрате! Так что лучше уж чуток заморочиться на стадии написания шаблона, чем потом разгребать всё это. Впрочем нормальная IDE позволяет проследить, откуда был вызван шаблон. А здесь об этом можно только мечтать.
Но вообще ведь в новом стандарте C++ решили всё значительно упростить, сделать наглядно и по-человечески:
Или может даже ещё проще можно...Подход используется, но в описанном случаи получается не указатель, а скорее некий object_id, так как единственная доступная операция - проверка на равенство.
Доброго времени суток! Можно узнать, на какой стадии находится разработка библиотеки? Или вы забросили ее? На стандартные контейнеры смотреть страшно, а альтернатив особо и нет.
Наверно, многие из нас, по крайней мере те, кто знаком с С++, мечтали о импорте STL (Standard Template Library) в MQL.
И, к сожалению, многие годы это было действительно невозможно.
Но, благодаря всем нам, а особенно - разработчикам, MQL не просто жив, а медленно но уверенно развивается...Спасибо.
Сергей, позвольте высказать мнение со стороны. Ваш уровень программиста высок и не вызывает вопросов. Но все же, есть такое альтернативное мнение, Вы уж простите что его озвучу. Так вот, не все здесь присутствующие исповедуют С++. И то, что MQL начинает мимикрировать под Си++ может быть не развитием а коллапсированием в язык, скажем так не самый популярный, и безусловно самый специфичный хотя и любимый многими. Я и сам помню свой первый Why Effect от знакомства с этой STL и С++. Но сейчас почему-то, все это как-то перестало казаться актуальным и важным, на фоне действительных проблем, которые проникают в MT все вновь и вновь.