Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
если верно понял, всё равно желательно ставить guard`s и остаются ещё особые требованию к коду ?
В своих заголовочных файлах - да, guard'ы нужны. Мы ведь первым этапом прогоняем через шланг, он составляет большую портянку из всех инклудов и это уже идёт к мкл компилятору. Без гуардов будут повторяться определения и мкл компилятор выдаст ошибки.
Из требований по коду, да только одно в принципе - специфичные мкл директивы препроцессора упаковываем так
ну дабы об этот импорт не споткнулся clang при анализе и компиляции. Если mql специфичная конструкция, но не директива препроцессору, то без mqlcpp_ (можно и не делать, но с точки зрения шланга это какая-то ошибка)
Разыменовывать ли указатели через -> и ставить ли & перед массивами - на выбор, но следование с++ стилю даст лучшую поддержку со стороны clang.
ЗЫ: кстати, не рассказал как определяется "первая компиляция" в контексте добавления guard'ов. Смотрится Include/Object.mqh и если там не находим гуард, то компилция первая. Ещё бы хотел добавить возможность формировать черный список для тупых ворингов....
А вообще вопросы неправильные у вас появились, интереснее другие - я вот за пару дней на коленках сделал ide со всеми плюшками и значительно более высоким качеством нежели метаэдитор ...
Читал, читал....
Надоело смотреть на эти выпендрежи.
Все эти штучки вобще не нужны трейдеру, который пишет торговую стратегию для себя.
А уж на заказ тем более, т.к. заказывают в основном новички. Там заказы из серии детской невинности, которые реализовываются в несколько строк кода.
Конечно же понравилось то, что планируется поддержка питона.
Это - да, вполне полезная доработка.
...Остальные и дальше будут молиться на МК, покорно ставить амперсанды перед массивами и разыменовывать через точку.
Точно! Сколько имен переменных и функций так поменял. Немного дольше чем в VS, но контроля больше.
Что касается точки, это ведь удобней и лаконичней, плюс совместимость с ООП языками. Я вот наоборот часто думал, что было бы неплохо чтоб в С++ сделали такую же возможность. Есть и оборотная сторона конечно, но всё ж плюсов больше, я считаю
Тогда надо будет выкинуть умные указатели, итераторы, ... . Нужно же как-то различать вызов функции самого указателя и указываемого типа
Точку нельзя перегружать, т.е. гарантированно доступ к внутренностям.
А уж на заказ тем более, т.к. заказывают в основном новички. Там заказы из серии детской невинности, которые реализовываются в несколько строк кода.
Уж трейдеру точно плевать на заказы, я пишу для себя, поделился с такими же, а не со всякой околорыночной публикой.
Тогда надо будет выкинуть умные указатели, итераторы, ... . Нужно же как-то различать вызов функции самого указателя и указываемого типа
Точку нельзя перегружать, т.е. гарантированно доступ к внутренностям.
Не путайте обычную автозамену текста в файле с контекстно-ориентированной заменой.
И зачем она? На случай, если в одном файле одинаково названы переменные с разным контекстом? Замена по смыслу, а не тексту? Будьте добры, поясните где и зачем использовать. Вдруг, всем нужно, а кто то не знает.
Ну вы всё верно поняли в принципе.