Недоработка компилятор или чудеса программирования на MQL5 - страница 2

 
Renat:

Битый указатель (именно указатель как сущность и рабочая единица языка) контролируется системой и безопасно обрабатывается, выдавая при необходимости рантайм ошибку, указывая на ошибку автора. А вот "физическая" ссылка не может быть проконтролирована

Почему не может если ссылка это именованный указатель? )) а указатель как вами сказано безопасно обрабатывается?
 
Renat:

А зачем нам усложнять язык и в разы понижать производительность языка?

Ну не думаю, что счетчик ссылок сильно повлияет на производительность. Ведь счетчик ссылок это i++ в случае присваивания объекта к переменной(указателю) и i--; if(i<1)FreeMem() после уничтожения указателя. За секунду можно создать, присвоить и уничтожить десяток тысяч объектов.
Renat:

А зачем? Тем более с таким безумием как OLE.

Ну, что вы к OLE придрались :) OLE отличная технология, хоть и не самая быстрая (из-за позднего связывания и вызова "на лету"), позволяющая управлять не только внутренними данными приложений, но и пользовательским интерфейсом. Поставляйте вместе с терминалом DLL с необходимыми стандартными функциями, процедурами и типами данных, или это тоже плохое решение, потому как раннее связывание с DLL долго выполняется?
Renat:

Функционала в MQL сейчас столько, что можно написать почти все что угодно для расчетов, контроля и принятия решений

Это все очень здорово, но все это сходит на нет из-за отсутствия нормального визуализатора торговых стратегий, если стратегия предусматривает больше чем 1 индикатор, то на графике все они рисуются по умолчанию красным (я так и не нашел возможности их разукрашивать при тестировании); Дебаг ТОЛЬКО В РЕАЛЬНОМ ВРЕМЕНИ, от него польза как от полета на луну без скафандра. Print теперь самая любимая процедура :) Кароч, отлаживать советников не реально. Думаю другие более менее опытные юзеры со мной согласятся. Полагаю полная отладка советника делается так: 1) Пишется советник; 2) На месяц другой запускается на демо счете; 3) Читаются километровые логи; 4) Исправляются ошибки логики советника 4) goto begin... Если стратегия не пипсовка на тиках, то на отладку 3-9мес уходит я думаю :) Это нормально?

Уж не говорю о скудной стандартной библиотеке. 

 
Bonifacy:
Ну не думаю, что счетчик ссылок сильно повлияет на производительность. Ведь счетчик ссылок это i++ в случае присваивания объекта к переменной(указателю) и i--; if(i<1)FreeMem() после уничтожения указателя. За секунду можно создать, присвоить и уничтожить десяток тысяч объектов. Ну, что вы к OLE придрались :) OLE отличная технология, хоть и не самая быстрая (из-за позднего связывания и вызова "на лету"), позволяющая управлять не только внутренними данными приложений, но и пользовательским интерфейсом. Поставляйте вместе с терминалом DLL с необходимыми стандартными функциями, процедурами и типами данных, или это тоже плохое решение, потому как раннее связывание с DLL долго выполняется?

Это все очень здорово, но все это сходит на нет из-за отсутствия нормального визуализатора торговых стратегий, если стратегия предусматривает больше чем 1 индикатор, то на графике все они рисуются по умолчанию красным (я так и не нашел возможности их разукрашивать при тестировании); Дебаг ТОЛЬКО В РЕАЛЬНОМ ВРЕМЕНИ, от него польза как от полета на луну без скафандра. Print теперь самая любимая процедура :) Кароч, отлаживать советников не реально. Думаю другие более менее опытные юзеры со мной согласятся. Полагаю полная отладка советника делается так: 1) Пишется советник; 2) На месяц другой запускается на демо счете; 3) Читаются километровые логи; 4) Исправляются ошибки логики советника 4) goto begin... Если стратегия не пипсовка на тиках, то на отладку 3-9мес уходит я думаю :) Это нормально?

Уж не говорю о скудной стандартной библиотеке. 

У Вас неверное представление о разработке в целом. Советник средней сложности пишется и отлаживается в среднем 2 недели. Если Вы (программист) планируете разработку в течение 3-9 месяцев, это пагубно отразится на вашем бизнесе.

Более того, для чего Вам необходим MT4 как OLE объект? Брутфорс паролей? ))) Почему бы не сделать из VisualStudio IDE OLE объект?

Если хотите, работайте с OLE из MQL. 

Счетчик ссылок ? ))) Вы когда-нибудь проектировали интерпретатор/компилятор? Знакомы с языками COCO/R, LEX ?

И для чего к структуре обращаться как к массиву? Хотите массив - определяйте массив и работайте с ним. Хотите память в чистом виде - пишите DLL, принимайте в функцию адрес структуры в памяти и делайте что хотите с ним.

P.S. void Print(...) здесь, как и в Си есть функция.

 
TheXpert:
Почему не может если ссылка это именованный указатель? )) а указатель как вам сказано безопасно обрабатывается?

Потому что это не так.

Это не С++, где ссылка и указатель на физическом уровне одно и то же. Указатель в MQL5 фактически является хендлом, а не физической ссылкой, что дает нам возможность жестко контролировать этот хендл.

Если вам интересна тема компиляторов, то почитайте соответствующую литературу, пожалуйста. А потом реализуйте простейший компилятор до состояния кодогенератора.

Особенно удивит уровень потерь ресурсов на обеспечении таких веселых сущностей как ссылки в managed языках. Именно после спуска на уровень практической реализации, а не на уровне теоретических рассуждений, где все кажется просто и красиво.

 

Bonifacy,

Похоже, что вы плохо знакомы с платформой. Визуализация тестера наоборот отличная, включая рилтайм, шаблоны тестер.тпл в помощь для раскраски.

Отладка в тестере будет, но и сейчас с этим не все так плохо. Отладчик есть, профайлер, режим визуализации позволяет показывать массу информации по ходу теста, а без распринтовки мало где выживешь, если вокрут масса тяжелых данных.

Кроме библиотеки есть бесплатная кодобаза, фриланс сервис и целый интернет, заваленный тоннами исходников.

 
Renat:

Ссылку нельзя передавать, так как объект может быть уничтожен в другом месте.

Всё это потому что в MQL до сих пор не реализована обработка исключительных ситуаций (exceptions), как в полноценном ООП. Была бы обработка исключений, код во многих местах можно было бы упростить в разы. Без них приходится решать проблемы дедовскими алгоритмическими методами, затыкая дыры всевозможными if-ами. Но ведь всего не предусмотришь, особенно того, что не зависит от программиста, а например, зависит от брокера или качества связи между клиентом и сервером.
 
Мда, ну хоть бы понимали в теме, перед тем как вставлять свое про эксепшены.
 
elugovoy:

У Вас неверное представление о разработке в целом. Советник средней сложности пишется и отлаживается в среднем 2 недели. Если Вы (программист) планируете разработку в течение 3-9 месяцев, это пагубно отразится на вашем бизнесе.

Более того, для чего Вам необходим MT4 как OLE объект? Брутфорс паролей? ))) Почему бы не сделать из VisualStudio IDE OLE объект?

Если хотите, работайте с OLE из MQL. 

Счетчик ссылок ? ))) Вы когда-нибудь проектировали интерпретатор/компилятор? Знакомы с языками COCO/R, LEX ?

И для чего к структуре обращаться как к массиву? Хотите массив - определяйте массив и работайте с ним. Хотите память в чистом виде - пишите DLL, принимайте в функцию адрес структуры в памяти и делайте что хотите с ним.

P.S. void Print(...) здесь, как и в Си есть функция.

Я совершенно не собираюсь тут троллить чей-то труд. Вас явно что-то задело и вы не вникали в смысл моих срок это точно, перечитайте еще раз, хотя бы часть о 3-9мес разработки. Это была риторическая фраза не требующая ответа.

Я программы пишу в IDEшках. Компиляторы я не никогда не писал и скорее всего не буду, потому глубоко в этот вопрос не погружался и пугать людей COCOнями не надо :)

Все выше мной сказанное следует воспринимать как адекватную\неадекватную критику программного продукта MQL5 и учесть\не учесть это при дальнейшей разработке. Я дня 3 изучаю MQL5 и многое удивляет. Складывается такое впечатление, что разработчики писали MQL5 ради собственного самолюбия, а не для пользователей.

Тут у вас джентльмен присутствует Anatoli Kazharski, один из немногих кто правильно пишет код (точнее других я больше не наблюдал). Вы гляньте какие это километры логики и кода в его статьях. Все то, что он написал как пользователь, должно быть в стандартной библиотеке.

Reshetov:
Всё это потому что в MQL до сих пор не реализована обработка исключительных ситуаций (exceptions), как в полноценном ООП. Была бы обработка исключений, код во многих местах можно было бы упростить в разы. Без них приходится решать проблемы дедовскими алгоритмическими методами, затыкая дыры всевозможными if-ами. Но ведь всего не предусмотришь, особенно того, что не зависит от программиста, а например, зависит от брокера или качества связи между клиентом и сервером.

Согласен,  такое ощущение, что пишешь в QBasic или что-то постарше.

 
Reshetov:
Всё это потому что в MQL до сих пор не реализована обработка исключительных ситуаций (exceptions), как в полноценном ООП. Была бы обработка исключений, код во многих местах можно было бы упростить в разы. Без них приходится решать проблемы дедовскими алгоритмическими методами, затыкая дыры всевозможными if-ами. Но ведь всего не предусмотришь, особенно того, что не зависит от программиста, а например, зависит от брокера или качества связи между клиентом и сервером.

Согласен, но здесь уже, наверное, какие-то религиозные соображения Рената не дают ему согласиться с этим :) Я несколько лет назад поднимал тему исключений, но был вежливо послан Ренатом подальше :)

Хотя как сильно это упрощает код, например в java. Логика становится прозрачной и не тонет в многочисленных и if-ах, огромная часть которых там только из соображений надежности написания софта и никогда не исполняется! И так в каждом необходимом месте!

Это все равно, что, к примеру, отменить функции и в каждое место вызова функции полностью вставлять ее тело. Вот сейчас у нас такая обработки ошибок!

А как хотелось бы в полной мере использовать преимущества современных языков программирования :) 

 
Renat:
 

Скоро мы выпустим очередную версию MQL4/MQL5 среды, скорость которой будет на уровне абсолютно нативных C++ программ. То есть, код на MQL5 будет работать так, что больше никто не сможет сказать "я пишу DLL, так как там быстрее работает мой код".

Ну зрасте, о какой ещё абсолютной нативности идёт речь, если вы сами в этой ветке рассказываете про указатели в виде хэндлов и прочее прокладки, якобы оберегающие нас (бестолковых ламеров) от прямого доступа к ресурсам системы.

Так что с С++ сравнивать бессмысленно. Равняться можно лишь на управляемые языки, например C#.  Но даже в относительно них я не разделяю ваш оптимизм. Ибо слишком много "защиты от дурака" в вашем MQL, и отходить от этой концепции вы не собираетесь.

Ну и кроме того, в настоящей среде программирования мы можем задействовать ресурсы системы по максимуму, организовав многопоточность и загрузив все ядра процессора. В вашей же среде процессор загружается полностью лишь в оптимизаторе стратегий, а это слишком узкий круг задач. Т.е. для обычной программы (допустим ресурсоёмкий индикатор) вы уверяете нас, что в MQL на одном ядре он будет работать так же быстро, как на на четырёх ядрах в C++? :)