Старые версии компилятора нормально кушали такие конструкции, взялся перекомпилировать валидный раннее код и ошибка. Это случайно или намеренно отломалось?
а разве классы внутри функций создавать можно по спецификации языка?
а разве классы внутри функций создавать можно по спецификации языка?
По спецификации какого языка? Мкл вообще толком не задокументирован, а в c++ нормальная практика, из справочника:
Local classes
A class declaration can appear in namespace scope (in which case it defines an ordinary class), inside another class definition (in which case it defines a nested class), and inside the body of a function, in which case it defines a local class. The name of such a class only exists within the function scope, and is not accessible outside.
А в ответ тишина, как обычно. Обойти проблему не сложно в общем-то - вместо элегантного размещения внутри функции, вынесу наружу с отпугивающим именем internal__Chart_bar_shift_Comp. Но дело то в другом - взяли и вот так просто урезали подобную конструкцию. Т.е. вообще нет никаких гарантий компилируемости моих писулек завтра. Можно же как-то с ключами для выбора диалекта -std=mql18, например. Но нет же, плевать на обратную совместимость. Мне сложно себе представить, что такое возможно на каком-нибудь gcc.
Наверное, простой скриптовый mql4 был вполне достаточным для торговой платформы. А лучше - импорт плагинов (в динамических библиотеках) со скриптами/экспертами. Но нет, нужна своя, как здесь часто говорят, "инфраструктура", где вы большие и важные.
По спецификации какого языка? Мкл вообще толком не задокументирован, а в c++ нормальная практика, из справочника:
Local classes
A class declaration can appear in namespace scope (in which case it defines an ordinary class), inside another class definition (in which case it defines a nested class), and inside the body of a function, in which case it defines a local class. The name of such a class only exists within the function scope, and is not accessible outside.
где то встречал обсуждение, что это не предусмотрено спецификацией mql5, посмотрите на форуме, там же было обсуждение про лямба, что они так же не предусмотрены
А в ответ тишина, как обычно. Обойти проблему не сложно в общем-то - вместо элегантного размещения внутри функции, вынесу наружу с отпугивающим именем internal__Chart_bar_shift_Comp. Но дело то в другом - взяли и вот так просто урезали подобную конструкцию. Т.е. вообще нет никаких гарантий компилируемости моих писулек завтра. Можно же как-то с ключами для выбора диалекта -std=mql18, например. Но нет же, плевать на обратную совместимость. Мне сложно себе представить, что такое возможно на каком-нибудь gcc.
Наверное, простой скриптовый mql4 был вполне достаточным для торговой платформы. А лучше - импорт плагинов (в динамических библиотеках) со скриптами/экспертами. Но нет, нужна своя, как здесь часто говорят, "инфраструктура", где вы большие и важные.
если честно то не понимаю зачем так делать, проще все вспомогательные сущности проще вынести в отдельный листинг исходников программы, например util.mqh
если честно то не понимаю зачем так делать, проще все вспомогательные сущности проще вынести в отдельный листинг исходников программы, например util.mqh
Это предикат для бинарного поиска, который не является универсальным и используется один раз в одной функции, зачем мне его куда-то выносить? Например, у нас массив структур (нет оператора сравнения, их нельзя топорно сравнить через <, или условие сравнения шибко хитрое), а мы хотим найти элемент через бинарный поиск. В плюсовой библиотеке функции-алгоритмы принимают функтор (удобно передать лямбду), внутри которого мы сравниваем элементы массива. Очень элегантное решение по-моему.
int main()
{
typedef pair<int, double> myPair; // typedef to shorten the type name
vector <myPair> vec(5);
myPair low_val; // reference value (set this up as you want)
auto it = lower_bound(vec.begin(), vec.end(), low_val,
[](myPair lhs, myPair rhs) -> bool { return lhs.second < rhs.second; });
}
Но ввиду ограничений мкл, создал экземпляр класса-предиката.
Это предикат для бинарного поиска, который не является универсальным и используется один раз в одной функции, зачем мне его куда-то выносить? Например, у нас массив структур (нет оператора сравнения, их нельзя топорно сравнить через <, или условие сравнения шибко хитрое), а мы хотим найти элемент через бинарный поиск. В плюсовой библиотеке функции-алгоритмы принимают функтор (удобно передать лямбду), внутри которого мы сравниваем элементы массива. Очень элегантное решение по-моему.
Но ввиду ограничений мкл, создал экземпляр класса-предиката.
кстати интересно насколько такой код будет оптимальным при компиляции ))
Почему не компилируется?
Старые версии компилятора нормально кушали такие конструкции, взялся перекомпилировать валидный раннее код и ошибка. Это случайно или намеренно отломалось?
а разве классы внутри функций создавать можно по спецификации языка?
а разве классы внутри функций создавать можно по спецификации языка?
По спецификации какого языка? Мкл вообще толком не задокументирован, а в c++ нормальная практика, из справочника:
Local classes
A class declaration can appear in namespace scope (in which case it defines an ordinary class), inside another class definition (in which case it defines a nested class), and inside the body of a function, in which case it defines a local class. The name of such a class only exists within the function scope, and is not accessible outside.
http://en.cppreference.com/w/cpp/language/class
А в ответ тишина, как обычно. Обойти проблему не сложно в общем-то - вместо элегантного размещения внутри функции, вынесу наружу с отпугивающим именем internal__Chart_bar_shift_Comp. Но дело то в другом - взяли и вот так просто урезали подобную конструкцию. Т.е. вообще нет никаких гарантий компилируемости моих писулек завтра. Можно же как-то с ключами для выбора диалекта -std=mql18, например. Но нет же, плевать на обратную совместимость. Мне сложно себе представить, что такое возможно на каком-нибудь gcc.
Наверное, простой скриптовый mql4 был вполне достаточным для торговой платформы. А лучше - импорт плагинов (в динамических библиотеках) со скриптами/экспертами. Но нет, нужна своя, как здесь часто говорят, "инфраструктура", где вы большие и важные.
По спецификации какого языка? Мкл вообще толком не задокументирован, а в c++ нормальная практика, из справочника:
Local classes
A class declaration can appear in namespace scope (in which case it defines an ordinary class), inside another class definition (in which case it defines a nested class), and inside the body of a function, in which case it defines a local class. The name of such a class only exists within the function scope, and is not accessible outside.
http://en.cppreference.com/w/cpp/language/class
где то встречал обсуждение, что это не предусмотрено спецификацией mql5, посмотрите на форуме, там же было обсуждение про лямба, что они так же не предусмотрены
А в ответ тишина, как обычно. Обойти проблему не сложно в общем-то - вместо элегантного размещения внутри функции, вынесу наружу с отпугивающим именем internal__Chart_bar_shift_Comp. Но дело то в другом - взяли и вот так просто урезали подобную конструкцию. Т.е. вообще нет никаких гарантий компилируемости моих писулек завтра. Можно же как-то с ключами для выбора диалекта -std=mql18, например. Но нет же, плевать на обратную совместимость. Мне сложно себе представить, что такое возможно на каком-нибудь gcc.
Наверное, простой скриптовый mql4 был вполне достаточным для торговой платформы. А лучше - импорт плагинов (в динамических библиотеках) со скриптами/экспертами. Но нет, нужна своя, как здесь часто говорят, "инфраструктура", где вы большие и важные.
если честно то не понимаю зачем так делать, проще все вспомогательные сущности проще вынести в отдельный листинг исходников программы, например util.mqh
если честно то не понимаю зачем так делать, проще все вспомогательные сущности проще вынести в отдельный листинг исходников программы, например util.mqh
Это предикат для бинарного поиска, который не является универсальным и используется один раз в одной функции, зачем мне его куда-то выносить? Например, у нас массив структур (нет оператора сравнения, их нельзя топорно сравнить через <, или условие сравнения шибко хитрое), а мы хотим найти элемент через бинарный поиск. В плюсовой библиотеке функции-алгоритмы принимают функтор (удобно передать лямбду), внутри которого мы сравниваем элементы массива. Очень элегантное решение по-моему.
Но ввиду ограничений мкл, создал экземпляр класса-предиката.
Это предикат для бинарного поиска, который не является универсальным и используется один раз в одной функции, зачем мне его куда-то выносить? Например, у нас массив структур (нет оператора сравнения, их нельзя топорно сравнить через <, или условие сравнения шибко хитрое), а мы хотим найти элемент через бинарный поиск. В плюсовой библиотеке функции-алгоритмы принимают функтор (удобно передать лямбду), внутри которого мы сравниваем элементы массива. Очень элегантное решение по-моему.
Но ввиду ограничений мкл, создал экземпляр класса-предиката.
кстати интересно насколько такой код будет оптимальным при компиляции ))
кстати интересно насколько такой код будет оптимальным при компиляции ))
Функтор с лёгкостью заинлайнится (stl ведь вся на шаблонах, т.е. доступны исходники - рай для компилятора), не волнуйтесь ))
кто с таким встречался, такое действительно может быть
логе одно время закрытия, а в истории сделок другое
счет демо.
я правильно понимаю, что время закрытия по логу 23:34:14.983
а по истории 00:33:32 +1 gtm