Почему в MQL5 нет исключений? - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
[Цензура Artyom Trishkin]
Вот это правильно, а то грохнут пост, кто... почему...зачем...
Артем, поздравляю с назначением модератором!
Вопрос был более конкретный: сравнение одного try/catch с одним if.
Если 8-мь делений, то 8-мь if, тут конечно if проиграет. А вот 1:1 как?
Просто у меня деление - это редчайшее явление и если бывает ,то не больше 1-го за раз.
Так в одном делении никто и не будет использовать ексепшены )) Конечно if
Эксепшены тянут за собой накладные расходы, зависящие от реализации компилятора
Мне представляется, что событийная модель тут подойдёт при отсутствии try...catch.
P.S. Прочитал свой же ответ и улыбнулся. Чаще всего спасаюсь просто if'ом, реже самописной функцией Assert().
В dll надо еще данные передавать, котировки, состояния ордеров, не все так радужно, на старом MQL4 только так и писал, тоже хватало проблем.
Не понимаю, какие проблемы в передаче данных в ДЛЛ? Обратно, да, есть небольшие, т.к. инициатором такой передачи д.б. МТ, но в любом варианте все идет по событиям МТ (тикам и пр.), так что, в общем, без разницы.
А вот преимущества многократны.
Кстати, проводил ли кто эксперимент по событиям советника. В смысле, порождают ли события советника новые потоки и обрабатываются независимо, или все в одном и кто первый, того и тапочки.
Конечно, можно перед любой небезопасной операцией производить проверки. Но что, если этих проверок десятки или сотни, а вероятность ошибки одна на миллион? Мы резко теряем в быстродействии, да и писать такие проверки сущее мучение.
Я извиняюсь, что вмешиваюсь в дискуссию авторитетных специалистов. Но, если память не изменяет, в MQL есть 3 критические ошибки. Только три!
Мне представляется, что событийная модель тут подойдёт при отсутствии try...catch.
Откуда взят постулат что исключения быстрее работают, чем обычный код?
Дело в том, что они вообще не работают и никак не влияют на быстродействие и пр. Начинают работать, только и исключительно, когда возникает ошибка, и управление передается блоку try...
Алексей ранее приводил пример с парсингом строки.
Откуда взят постулат что исключения быстрее работают, чем обычный код?
Из просмотра ассемблерного листинга. Вот пример, VS 2017 C++, включена оптимизация
Исходный код, самый примитивный
int main()
{
n++;
try
{
n++;
}
catch(...)
{ }
return 0;
}
Теперь смотрим ассемблер, красным - мои комменты
EXTRN @__security_check_cookie@4:PROC
EXTRN __imp____CxxFrameHandler3:PROC
?n@@3HA DD 010H ; n - занеcли в n значение 16
_DATA ENDS
PUBLIC _main
; Function compile flags: /Ogtp
; File c:\myp\xamarin\consoleapplication1\consoleapplication1\consoleapplication1.cpp
; COMDAT _main
_TEXT SEGMENT
_main PROC ; COMDAT
; 9 : n++;
; 10 : try
; 11 : {
; 12 : n++;
00000 83 05 00 00 00
00 02 add DWORD PTR ?n@@3HA, 2 ; n - компилятор соптимизировал, сразу прибавил к n 2
; 13 : }
; 14 : catch(...)
; 15 : { }
; 16 : return 0;
00007 33 c0 xor eax, eax - получил в регистре eax ноль
; 17 : }
00009 c3 ret 0 - и вернул его, финиш
_main ENDP
_TEXT ENDS
END
Как видно, никакого оверхеда блок try-catch не прибавляет. Более того, для оптимизатора блок try прозрачен.
Я не силен в устройстве компиляторов, но так понимаю, ексепшены генерятся в результате того, что в процессоре при ошибках (например деление на ноль) вызывается аппаратное прерывание и дальше уже идет функция его обработки. А на нормально работающую программу ексепшены влияние не оказывают
Не понимаю, какие проблемы в передаче данных в ДЛЛ? Обратно, да, есть небольшие, т.к. инициатором такой передачи д.б. МТ, но в любом варианте все идет по событиям МТ (тикам и пр.), так что, в общем, без разницы.
А вот преимущества многократны.
Кстати, проводил ли кто эксперимент по событиям советника. В смысле, порождают ли события советника новые потоки и обрабатываются независимо, или все в одном и кто первый, того и тапочки.
Как видно, никакого оверхеда блок try-catch не прибавляет. Более того, для оптимизатора блок try прозрачен.
Я не силен в устройстве компиляторов, но так понимаю, ексепшены генерятся в результате того, что в процессоре при ошибках (например деление на ноль) вызывается аппаратное прерывание и дальше уже идет функция его обработки. А на нормально работающую программу ексепшены влияние не оказывают
Столь же чудовищная ссылка на интерпретируемый Матлаб с заявлениями про замедления в 1000 раз. У нас компилируемый в натив язык, который не позволяет так тормозить. Доп проверка может вообще ничего не стоить, но дает гарантию корректности.