Как последовательно перебрать перечисление? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну а продемонстрированные тут примеры (case 1: return value1; case 2: return value2; case 3: return value3... и т.д.) - это вообще образец глупости. Адекватный человек поместит все значения в массив и будет просто получать нужное значение по его индексу. А для обратной задачи воспользуется бинарным поиском.
Двумя руками за красивый код с массивами. Но при написании более быстрой NormalizeDouble, чем штатная, столкнулся с эффектом оптимизатора - красивое решение через const-массив было заметно медленней, чем громоздкое через switch-case. Оставил второй вариант, поскольку NormalizeDouble в тестере ой как много используется. Засунул в инклудник и не смотрю на это страшилище. Зато бэктесты бегают быстрее.
Видать доработали switch. Просто помню как-то была ветка с его обсуждением, где разрабы говорили лишь о реализации в виде бинарного поиска, а это естественно существенно медленней, чем просто доступ по вычисленному индексу. Но теперь видимо сделали по уму: если шаг постоянный, то вычисление индекса, в противном случае бинарный поиск. Тогда само собой, нативная реализация всегда быстрее обёрточной.
Тут конечно уже надо отталкиваться от твоих приоритетов. Но имхо, если столь критична скорость, что ты готов изобретать костыли, тогда надо отказываться и от ООП, да и вообще от MQL ;) Хотя я уверен, при правильном построении кода эта разница в скорости будет не столь существенна. Это в тестовых замерах ты тупо гоняешь функцию в цикле миллионы раз. А в реальном коде используешь более рационально, не так ли?
Видать доработали switch. Просто помню как-то была ветка с его обсуждением, где разрабы говорили лишь о реализации в виде бинарного поиска, а это естественно существенно медленней, чем просто доступ по вычисленному индексу. Но теперь видимо сделали по уму: если шаг постоянный, то вычисление индекса, в противном случае бинарный поиск. Тогда само собой, нативная реализация всегда быстрее обёрточной.
Компилятор, если не тупой, обязан был бы const-массив и единственное типовое к нему обращение по индексу превратить в код switch.
Тут конечно уже надо отталкиваться от твоих приоритетов. Но имхо, если столь критична скорость, что ты готов изобретать костыли, тогда надо отказываться и от ООП, да и вообще от MQL ;) Хотя я уверен, при правильном построении кода разница в скорости будет не столь существенна. Это в тестовых замерах ты тупо гоняешь функцию в цикле миллионы раз. А в реальном коде используешь более рационально, не так ли?
Компилятор, если не тупой, обязан был бы const-массив и единственное типовое к нему обращение по индексу превратить в код switch.
Дык массив просто конст? А как насчёт статик? Если да, тогда действительно всё должно быть равнозначно. Да и почему "код switch", тут ведь простейшие операции: сравниваем значение индекса с размером массива/перечисления, если меньше то получаем адрес нужного элемента как адрес массива + индекс, ну и прочитываем оттуда значение. Мне казалось, такая ерунда должно компилироваться одинаково.
Дык массив просто конст? А как насчёт статик? Если да, тогда действительно всё должно быть равнозначно. Да и почему "код switch", тут ведь простейшие операции: сравниваем значение индекса с размером массива/перечисления, если меньше то получаем адрес нужного элемента как адрес массива + индекс, ну и прочитываем оттуда значение. Мне казалось, такая ерунда должно компилироваться одинаково.
Не помню точно, можно ли статик-массивы делать конст. Методы - точно нельзя. Принципиально делал именно конст, а не статик. В расчете на ум компилятора. После компиляции в потрохах вообще не должно было быть и намека на массив. Статик - гораздо сложнее конструкция, чем конст. Поэтому был уверен, что со статиком компилятор уж точно не справится. Но надо будет попробовать.
Не помню точно, можно ли статик-массивы делать конст. Методы - точно нельзя. Принципиально делал именно конст, а не статик. В расчете на ум компилятора. После компиляции в потрохах вообще не должно было быть и намека на массив. Статик - гораздо сложнее конструкция, чем конст. Поэтому был уверен, что со статиком компилятор уж точно не справится. Но надо будет попробовать.
А, ну тогда всё понятно. Не стоит рассчитывать на излишнюю интеллектуальность компилятора, мол он за вас дооптимизирует плохо-спроектированное решение. Если вы сами поленились/не додумались сделать как надо, мол "статик гораздо сложнее" (хотя чего там сложного, непонятно), то чё ж после этого обвинять компилятор?
А, ну тогда всё понятно. Не стоит рассчитывать на излишнюю интеллектуальность компилятора, мол он за вас дооптимизирует плохо-спроектированное решение. Если вы сами поленились/не додумались сделать как надо, мол "статик гораздо сложнее" (хотя чего там сложного, непонятно), то чё ж после этого обвинять компилятор?
Всегда пожалуйста. Будет урок на будущее, что надо 7 раз подумать, прежде чем бежать изобретать костыли )
Теперь выходит, что я рано похвалил свитч, точнее его разработчиков. Значит там всё только через бинарный поиск реализовано, даже когда перечисление идёт с кратным шагом. Нехорошо.
Всегда пожалуйста. Будет урок на будущее, что надо 7 раз подумать прежде чем бежать изобретать костыли )