ООП, шаблоны и макросы в mql5, тонкости и приёмы использования - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1. Всё же лучше сразу вести разговор о чём-либо там, где это "что-то-либо" находится, а не думать как бы сделал модератор. А то действительно всё расплылось по двум веткам, и теперь, даже если модератор решит, что обсуждение должно быть там-то, или там-то, то нормально перенести обсуждение с сохранением очерёдности постов и их смысла, является весьма трудоёмким занятием.
2. Обсуждение действий модератора - это не каждый чих... Это если начинается всеобщее и публичное оспаривание его действий, причём действий по наведению порядка или утихомириванию разбушевавшихся. А если у вас есть своё мнение, то кто ж вам его запрещает выразить? Может ваше мнение является весьма рациональным предложением, а вы боитесь его сказать, дабы не попасть под нелюбимое меню модератора? Так сиё чушь :)
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Вы, вроде бы, пока не модератор, чтобы определять, в какой ветке что более уместно. А модераторы уже четко обозначили, что обсуждения особенностей нужно вести не в ветке самих особенностей, а в отдельной ветке, т.е. здесь.
В Вашем описании вообще не понятно, как единообразно обращаться к методу класса по ссылке и по значению типа T. Не знаю, о чем идет речь у Вас, но у меня там шла речь именно об этом.
Здесь вот какая ситуация: я понял, что не всё можно подогнать под особенности те, которые участники форума ожидают видеть в той ветке. Здесь идёт обсуждение (и там оно шло, потому и перенёс сюда) достаточно специфичной темы, которую я решил выделить в отдельную ветку. Пусть там будут более общие и понятные большинству особенности, а здесь - классы, хитрые приёмы работы с ними, в том числе макросы (та ещё головоломка для многих).
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Я уже скопировал сюда код из той ветки пару постов назад поэтому имхо дополнительных действий не требуется.
Я уже скопировал сюда код из той ветки пару постов назад поэтому имхо дополнительных действий не требуется.
Добро.
Апдейт на тему интерфейсов через шаблоны и статики. Точнее не интерфейсов, а скажем так удобно параметризуемых операций над произвольными типами, реализуемых через внешние классы. В данном случае сравнение (Comparer) и приведение типов (Caster)
Учел частично предыдущую критику, класс "интерфейса" (хотя это не интерфейс) не наследуется от класса параметра (такая метода не прижилась...), и без использования dynamic_cast разумеется. Надеюсь, что эта модель будет выглядеть логичнее.
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
Только сразу говорю - на мкл не проверял, прогнал лишь через сишный препроцессор для проверки, МКЛ ведь с особенностями, если что допиливайте.
получил выхлоп (gcc -E):
дополнительные аргументы вы/докидывать в ARGS список.
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
Пока только так придумал. Вот если бы разрабы прикрутили переменное число параметров, как в С, то короче можно сделать было бы.
Пока только так придумал. Вот если бы разрабы прикрутили переменное число параметров, как в С, то короче можно сделать было бы.
Что-то я переусложнил )).
Ну и пусть использует первый, самое оптимальное, наверное.
#define TEST(dId)
Написать несколько раз TEST не проблема ведь.