Используете ли вы ООП в программировании на MQL4 и MQL5? - страница 3

Новый комментарий
 
Vasiliy Sokolov:

Это правда. Точно также как и правда то, что сам процедурный стиль программирования дает чудовищный оверхед по памяти и быстродействию ЦП. Если используешь процедурный стиль программирования - значит твоя программа тормознутая по определению, т.к.:

  • Снижается повторная использованность кода, и как следствие и ты пишешь велосипед дважды трижды и четырежды. Вместо того, что бы собрать критически важные функции в один класс в область private, ты каждый раз повторяешь одни и те же процедуры не оптимальным способом.
  • Дурачек, все уже написано до тебя! Например: пытаешься создать свою сортировку? - Значит по определению пытаешься превзойти сортировку Хоара. Но кто ты такой, что бы соревноваться с Хоаром? Он ученый и посвятил всю свою жизнь поиску оптимальных алгоритмов. А ты? Выпил пива и решил, что все рожденные до тебя были дебилами, и только ты знаешь как лучше отсортировать множество {1,3,5,10,8,4,5,...}? 
  • Фундаментальные алгоритмы информатики практически все написаны в стиле ООП! Примеры: списки, словари, стеки и пр. пр. Есть куча примеров, где один из алгоритмов в стиле ООП, рвет как тузик грелку процедурное программирование и как в плане использования памяти и как в плане использования ЦП. 
  • Процедурное программирование существенно отличается от человеческого мышления. Объектно-ориентированное программирование - суть человеческого мышления. Но! человеческое мышление оптимизировано по определению эволюционными изменениями и конкуренцией между видами. То, как Вы мыслите - правильно и оптимально с точки зрения информатики, и следовательно, Вы уже являетесь программистом по определению.
  • Повторное или не повторное использование кода никак не влияет на скорость его работы.
  • Никакой связи с ООП. Качественная функция сортировки может существовать сама по себе в языке, а не как метод класса содержащего данные.
  • Вот как раз фундаментальные алгоритмы написаны в процедурном стиле, хотя бы та же самая сортировка.
  • Приведите пример. Как-то не нахожу ни особого сходства с человеческими мышлением ни того ни второго способа программирования, так же как отличия. 
 

В параллельном окне сижу в метаэдите. Тут на сайте меня убеждают, что ну просто везде одни объекты. Открываю страничку под названием "Справочник MQL4" - одни функции! Была  последняя надежда на "Графические объекты", ан нет - функция ObjectCreate".

Во дурят тут, а если бы я, по обыкновению, не читал справочники по языкам? Так бы жил оболваненный ООПовцами! 

 
Vasiliy Sokolov:

Это правда. Точно также как и правда то, что сам процедурный стиль программирования дает чудовищный оверхед по памяти и быстродействию ЦП. Если используешь процедурный стиль программирования - значит твоя программа тормознутая по определению, т.к.:

  • Снижается повторная использованность кода, и как следствие и ты пишешь велосипед дважды трижды и четырежды. Вместо того, что бы собрать критически важные функции в один класс в область private, ты каждый раз повторяешь одни и те же процедуры не оптимальным способом.
  • Дурачек, все уже написано до тебя! Например: пытаешься создать свою сортировку? - Значит по определению пытаешься превзойти сортировку Хоара. Но кто ты такой, что бы соревноваться с Хоаром? Он ученый и посвятил всю свою жизнь поиску оптимальных алгоритмов. А ты? Выпил пива и решил, что все рожденные до тебя были дебилами, и только ты знаешь как лучше отсортировать множество {1,3,5,10,8,4,5,...}? 
  • Фундаментальные алгоритмы информатики практически все написаны в стиле ООП! Примеры: списки, словари, стеки и пр. пр. Есть куча примеров, где один из алгоритмов в стиле ООП, рвет как тузик грелку процедурное программирование и как в плане использования памяти и как в плане использования ЦП. 
  • Процедурное программирование существенно отличается от человеческого мышления. Объектно-ориентированное программирование - суть человеческого мышления. Но! человеческое мышление оптимизировано по определению эволюционными изменениями и конкуренцией между видами. То, как Вы мыслите - правильно и оптимально с точки зрения информатики, и следовательно, Вы уже являетесь программистом по определению.

Ого, а меня еще Dmitriy Skub пожурил за наличие эмоций  )) Вот где кроется настоящий ураган! Василий, я свой, буржуинский, я люблю ООП и пишу на нем, я , собственно, этот опрос-то и затеял. И все, что вы написали, совершенно верно.

Но, говоря об оверхеде, я говорил о embeded программировании на пределе возможностей проца, когда важен каждый такт и каждый байт. А в программировании на MQL этот оверхед  - капля в море, можно о нем и не думать.

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

 
СанСаныч Фоменко:

В параллельном окне сижу в метаэдите. Тут на сайте меня убеждают, что ну просто везде одни объекты. Открываю страничку под названием "Справочник MQL4" - одни функции! Была  последняя надежда на "Графические объекты", ан нет - функция ObjectCreate".

Во дурят тут, а если бы я, по обыкновению, не читал справочники по языкам? Так бы жил оболваненный ООПовцами! 

Смотрите стандартную библиотеку, в справке МТ4 она не описана, надо смотреть в справке пятерки или на сайте.

А нижний слой MQL4/5 действительно построен на обычных функциях. Этот уже обсуждали, пришли к выводу, что метаквоты не захотели отпугивать старичков - процедурников.

 
Alexey Volchanskiy:

Смотрите стандартную библиотеку, в справке МТ4 она не описана, надо смотреть в справке пятерки или на сайте.

А нижний слой MQL4/5 действительно построен на обычных функциях. Этот уже обсуждали, пришли к выводу, что метаквоты не захотели отпугивать старичков - процедурников.

R содержит около 8 тысяч пакетов, в которых имеется около 130 000 ФУНКЦИЙ. В этом языке понятие "объект" доведено до своего логического завершения - всё объекты, включая компьютер, на котором исполняется программа R. Каждая из этих 130 000 функций выдает результат в виде объекта, который может быть как вектором длиной 1 (скаляров нет) или матрицей, так и весьма замысловатым объектом, имеющем по несколько листов наименований других объектов, входящих в этот объект. Объект имеет свойства, над которым можно совершать операции. Так вектор может иметь длину ноль (не содержать элементов), но этот вектор обязательно имеет свойства, которые можно присвоить другому вектору.

Ну и что? Может быть кто-то использует, может нет...  

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

 

А теперь, как автор опроса, ответьте мне на простой и по идее первоначальный вопрос, только конкретно, без люблю-не люблю: что такое "хорошо", и каковы критерии достижения этого хорошо. Вот начну я использовать ООП, чем лучше, в смысле "хорошо" станет мой код и как я смогу измерить степень достижения до этого "хорошо"?  

 

ПС 

Чем дальше, тем больше горжусь своим возрастом - не помещается в голове разного рода новомодная хрень. 

 
СанСаныч Фоменко:

Чем дальше, тем больше горжусь своим возрастом - не помещается в голове разного рода новомодная хрень. 

Прочитал текст СанСаныча и пришло в голову, что вопрос -Используете ли вы ООП? - уже не имеет смысла.) Дело в том, что используют его все, поголовно. СанСаныч, работая с R, только и делает, что манипулирует объектами. Используя MQL, хошь-не хошь, а объекты приходится использовать, возможно и не подозревая, что это объект (скажем, советник - индикатор-скрипт - это уже вполне полноценные объекты), и даже не зная -что за зверь ООП. Так эти действия и есть ООП - для этого оно собственно и создавалось, чтобы каждый мог взять этот объект, и ничего не зная о том, как он устроен, свободно его применять в своих целях.
 
MQLPartner:

Не надо путать и обманывать людей Function Call есть в любом процедурном языке. И вы можете использовать любые заданные функции любое количество раз с любыми параметрами.

Еще напиши, что ассемблер медленнее С++.


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

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

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

Ерунда, я в 2000-2010 г. на 90% занимался embedded programming, а это чистый Си+ASM. Тем не менее, пишу на MQL с использованием ООП, прилично знаю и люблю C#.

Ну да бог с ним, с MQL, кроме него куча различных областей программирования.

Как вы будете писать программу с интерфейсом под Windows без использования ООП? А под Андроид, под iOS?

Фактически, если не брать MQL, программист, который не знает ООП, обрекает себя сейчас на программирование контролеров, там до сих пор в ходу pure C. И будет ковыряться еще 2-3 года с железом типа 4 Кб ОЗУ, 128 КБ ПЗУ. Очень увлекательно.  А больше он нафик никому не нужен. Почему я написал 2-3- года? Потому что и там уже в ходу С++ компиляторы и с развитием железа чистый Си уйдет со сцены.

 
Alexey Volchanskiy:

Ого, а меня еще Dmitriy Skub пожурил за наличие эмоций  )) Вот где кроется настоящий ураган! Василий, я свой, буржуинский, я люблю ООП и пишу на нем, я , собственно, этот опрос-то и затеял. И все, что вы написали, совершенно верно.

Но, говоря об оверхеде, я говорил о embeded программировании на пределе возможностей проца, когда важен каждый такт и каждый байт. А в программировании на MQL этот оверхед  - капля в море, можно о нем и не думать.

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

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

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

Вот asm листинг простейшей программки

struct Sa
{
    int n;
    int m;
};


class Cb
{
public:
    int n, m;
};


int main()
{
    int n = 4, m = 8, result;
    Sa sa = { 4, 8 };
    Cb cb = { 4, 8 };
    result = n + m;
    result = sa.m + sa.n;
    result = cb.m + cb.n;
    return 0;
}

 asm listing

; я убрал все лишнее, типа распределения адресов, пролога и эпилога, оставил только суть
; видно, что закомментированные метки 37, 38, 39 имеют одинаково по 3 инструкции на такт

; 34   :     int n = 4, m = 8, result;

        mov     DWORD PTR _n$[ebp], 4
        mov     DWORD PTR _m$[ebp], 8

; 35   :     Sa sa = { 4, 8 };

        mov     DWORD PTR _sa$[ebp], 4
        mov     DWORD PTR _sa$[ebp+4], 8

; 36   :     Cb cb = { 4, 8 };

        mov     DWORD PTR _cb$[ebp], 4
        mov     DWORD PTR _cb$[ebp+4], 8

; 37   :     result = n + m;

        mov     eax, DWORD PTR _n$[ebp]
        add     eax, DWORD PTR _m$[ebp]
        mov     DWORD PTR _result$[ebp], eax

; 38   :     result = sa.m + sa.n;

        mov     eax, DWORD PTR _sa$[ebp+4]
        add     eax, DWORD PTR _sa$[ebp]
        mov     DWORD PTR _result$[ebp], eax

; 39   :     result = cb.m + cb.n;

        mov     eax, DWORD PTR _cb$[ebp+4]
        add     eax, DWORD PTR _cb$[ebp]
        mov     DWORD PTR _result$[ebp], eax


Но это все для переменных, которые создаются на стеке, в том числе и экземпляры структуры и класса. Сейчас попробуем посмотреть доступ к классу, созданному через new
 
Alexey Volchanskiy:


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

Немного изменил программку

  

    Cb *cb = new Cb;
    cb->n = 4;
    cb->m = 8;
    result = cb->m + cb->n;

Будет выглядеть немного длиннее. Но не из за ООП, а из-за необходимости доставать данные из кучи. Если бы в MQL были нативные указатели на простые типы данных вроде int, результат

result = *n + *m;

 был бы точно такой же, как ниже

; 41   :     result = cb->m + cb->n;

        mov     eax, DWORD PTR _cb$[ebp]
        mov     ecx, DWORD PTR [eax+4]
        mov     edx, DWORD PTR _cb$[ebp]
        add     ecx, DWORD PTR [edx]
        mov     DWORD PTR _result$[ebp], ecx
 
Dmitry Fedoseev:
  • Повторное или не повторное использование кода никак не влияет на скорость его работы.
  • Никакой связи с ООП. Качественная функция сортировки может существовать сама по себе в языке, а не как метод класса содержащего данные.
  • Вот как раз фундаментальные алгоритмы написаны в процедурном стиле, хотя бы та же самая сортировка.
  • Приведите пример. Как-то не нахожу ни особого сходства с человеческими мышлением ни того ни второго способа программирования, так же как отличия. 

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

2. Сортировка была указана лишь как пример. В большинстве случаев требуется сортировать сложные типы данных по нескольким критериям сортировки и без ООП это все превращается в ад.

3. Ну давайте ради интереса, напишите универсальный список List без использования классов и структур. Только функции и базовые типы. А это простейший из алгоритмов. Словарь Вы вообще адекватно без ООП не сделаете, а это один из наиболее часто используемых алгоритмов. Почитайте Кнута - узнаете много нового. Он хотя и использует в качестве примера низкоуровневый вымышленный язык, описание самих алгоритмов идет в виде манипуляций над классическими ООП объектами.

4. Человеческое мышление оперирует композитными объектами и действиями над ними. Например понятие "дверь" включает в себя дверное полотно, ручку/замок, фурнитуру, откосы и прочие мелочи. "Открыть дверь" означает совершить операцию сразу над множеством этих объектов. В ООП парадигме это действие будет таким же как и в жизни: получить объект типа "дверь". Вызвать метод "Открыть" этого объекта. В процедурном программировании все будет иначе: необходимо будет проделать специфические операции для каждого объекта, образующего множество дверь (повернуть ручку, сместить положение дверного полотна, переместить угол открытия петель и т.д.)

12345678910...12
Новый комментарий
Причина обращения: