Используете ли Вы ООП по максимому или избегаете его ? - страница 4

Новый комментарий
 
Alexey Volchanskiy:

А почему вы решили, что ваш процедурный код будет исполняться иммено так, как он написан??? Сначала его изменит оптимизирующий компилятор, это раз. Потом, уже на уровне машинных инструкций, его во время исполнения прооптимизирует любой современный процессор, может инструкции местами переставить, какие-то выполнить параллельно даже на одном ядре (да-да, у процов на одном ядре несколько блоков АЛУ для целочисл. вычислений и поменьше для вещественных). Так что такие рассуждения на уровне ЭВМ 60-х годов.

К сожалению, у компиляторов МТ4/5 нет опции посмотреть генерируемый ассемблерный код. Но я копался в ассемблере, который генерит Intel C++ на высшем уровне оптимизации. Поверьте, если бы не комментарии, которые вставляет компилятор, я бы свой код вообще не узнал ))
Конечно, у MQ должно быть не так круто, но все же.

А, забыл, на МТ ведь все это крутится внутри среды исполнения, которая для нас вообще черный ящик. 

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

Чудесно обхожусь без ООП. Пишу аналитическую часть на R, а исполнительную на МКЛ4.

Никаких проблем с написанием и исполнением.

А уж после внедрения R в МТ4, вообще праздник будет(разработчики обещали после новой пятерки сделать.). Ждем

 
Vladimir Perervenko:

Чудесно обхожусь без ООП. Пишу аналитическую часть на R, а исполнительную на МКЛ4.

Никаких проблем с написанием и исполнением.

А уж после внедрения R в МТ4, вообще праздник будет(разработчики обещали после новой пятерки сделать.). Ждем

Насчет ООП, сомневаюсь, что все чудесно. А вот про вывод основной программы за пределы МТ, тоже подумываю. Сложности только в организации обратной связи. Т.е. двустороннего обмена.
 
Boris:
Было бы нормально, если бы перевод с процедурного на ООП, если уж он так необходим, делал бы автоматический транслятор. Большинство не имеет профессионального образования ни базового по программированию. 
Это нереально технически и не нужно по существу. Не нужно потому, что ООП нужно исключительно программисту для ускорения работы. Когда все скомпилировано в машинные коды, процессору без разницы, как писалась программа, на асме, процедурном, декларативном или ООП.
 
Alexey Volchanskiy:
Это нереально технически и не нужно по существу. Не нужно потому, что ООП нужно исключительно программисту для ускорения работы. Когда все скомпилировано в машинные коды, процессору без разницы, как писалась программа, на асме, процедурном, декларативном или ООП.

Тогда я не понимаю. В ООП объект создается и уничтожается в памяти. Как бы, по нашему хотению. Да и со связыванием там не клеится. Вроде в процедурном это никак... Или что-то путаю.

Процессору м.б. и без разницы, но в организации нативного кода разница большая.

 
Vladimir Perervenko:

Чудесно обхожусь без ООП. Пишу аналитическую часть на R, а исполнительную на МКЛ4.

Никаких проблем с написанием и исполнением.

А уж после внедрения R в МТ4, вообще праздник будет(разработчики обещали после новой пятерки сделать.). Ждем

Последние несколько месяцев пишу на МКЛ4 - после R уже оплевал все вокруг насколько неудобно.
 
СанСаныч Фоменко:
Последние несколько месяцев пишу на МКЛ4 - после R уже оплевал все вокруг насколько неудобно.
Давайте замутим DLL, или, по крайней мере, обсудим ее интерфейс и способы организации взаимодействия (обратной связи) с МТ.
 
Yuriy Asaulenko:

Тогда я не понимаю. В ООП объект создается и уничтожается в памяти. Как бы, по нашему хотению. Да и со связыванием там не клеится. Вроде в процедурном это никак... Или что-то путаю.

Процессору м.б. и без разницы, но в организации нативного кода разница большая.

Да, в MQL можно создавать/уничтожать в памяти только объекты классов. В С/С++ можно что угодно. В С вообще просто тупо выделяется область памяти с заданным количеством байтов, это совсем низкоуровневый язык.

В MQL нет полноценных указателей, вместо них дескрипторы объектов, в этом все дело. 

 
Alexey Volchanskiy:

Да, в MQL можно создавать/уничтожать в памяти только объекты классов. В С/С++ можно что угодно. В С вообще просто тупо выделяется область памяти с заданным количеством байтов, это совсем низкоуровневый язык.

Да, помню, malloc, calloc. Давненько не брал в руки шашек. :)
1234567891011...13
Новый комментарий