std::vector<T>::iterator, оптимальное названия макроса по разыменовыванию итераторов в MQL (детали в первом посте) - страница 3

 
Alexey Navoykov:

Попробуйте передать const int.

А насчёт ошибки компиляции - так вы обратите внимание, в каком месте она возникает. И как вы собираетесь искать первоисточник ошибки.  Здесь то у вас всё очевидно, т.к. весь код перед глазами. А если ваш проект содержит кучу файлов, и данный метод вызывается из сотен мест в программе?  Причём он мог быть вызван не напрямую, а опосредовано, из других шаблонов. Т.е. чтобы добраться до сути, придётся разматывать весь клубок шаблонных переходов.  Я в своё время хлебнул горя с этим в MQL.   Теперь напрямую шаблонные методы практически не вызываю.  Только посредством обёртки из макроса, выполняющего предварительные проверки наподобие Sfinae.

Мдя. Не получилось отсутствие r-value ссылок обойти.
 
Alexey Navoykov:

Без поддержки SFINAE, шаблоны - тот ещё гемор.

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

так вот SFINAE делает этот гемор немного удобнее, листинг подстановки не пять страниц, а две ) ну и ошибки нагляднее, но это все равно гемор.

А все что нужно для sfinae это нормальные typedef-ы внутри классов.

 
TheXpert:

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

так вот SFINAE делает этот гемор немного удобнее, листинг подстановки не пять страниц, а две ) ну и ошибки нагляднее, но это все равно гемор.

А все что нужно для sfinae это нормальные typedef-ы внутри классов.

Да, там конечно бывает гемор в их громоздкости и мудрёности.  Но зато один раз написал - и всё, дальше спокойно пользуешься.  А здесь это превращается в постоянный квест.  Кстати иногда даже в библиотеке STL оказывается пропущена какая-то из необходимых sfinae-проверок, в результате чего получаем ошибку компиляции где-то в недрах их библиотек.  И вот там разобраться - это уже гемор в квадрате!  Так что лучше уж чуток заморочиться на стадии написания шаблона, чем потом разгребать всё это.  Впрочем нормальная IDE позволяет проследить, откуда был вызван шаблон.  А здесь об этом можно только мечтать.

Но вообще ведь в новом стандарте C++ решили всё значительно упростить, сделать наглядно и по-человечески:

template<typename T>  requires requires (T x) { x + x; }
T add(T a, T b) { return a + b; }
Или может даже ещё проще можно...
 
Sergey Dzyublik:

Подход используется, но в описанном случаи получается не указатель, а скорее некий object_id, так как единственная доступная операция - проверка на равенство.


Доброго времени суток! Можно узнать, на какой стадии находится разработка библиотеки? Или вы забросили ее? На стандартные контейнеры смотреть страшно, а альтернатив особо и нет.

 
Sergey Dzyublik:

Наверно, многие из нас, по крайней мере те, кто знаком с С++, мечтали о импорте STL (Standard Template Library) в MQL.
И, к сожалению, многие годы это было действительно невозможно.
Но, благодаря всем нам, а особенно - разработчикам, MQL не просто жив, а медленно но уверенно развивается...Спасибо.

Сергей, позвольте высказать мнение со стороны. Ваш уровень программиста высок и не вызывает вопросов. Но все же, есть такое альтернативное мнение, Вы уж простите что его озвучу. Так вот, не все здесь присутствующие исповедуют С++. И то, что MQL начинает мимикрировать под Си++ может быть не развитием а коллапсированием в язык, скажем так не самый популярный, и безусловно самый специфичный хотя и любимый многими. Я и сам помню свой первый Why Effect от знакомства с этой STL и С++. Но сейчас почему-то, все это как-то перестало казаться актуальным и важным, на фоне действительных проблем, которые проникают в MT все вновь и вновь.