Интервью со Станиславом Стариковым: особенности нового MQL5 - страница 8

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

Не думаю. Какой смысл делать нечто подобное ООП, если свои типы данных делать нельзя?

 

вот вот.

какое может быть ООП если нет задела по типам данных и их адресации.

т.е.

-адресная арифметика не отлажена, в границы не попадает, с переменной размерностью типа структур не работает.

- надстройка адресной арифметики в виде дефайна своего типа отсуствует,

ну какие тогда объекты.

Может быть разработчики осознают и откажутся от революционных изменений.

например, дадут нам "MQL-4+" = полный Си по Керригану с дефайнами и препроцессором.

 

Меня такой MQL4+ вполне устроил бы. И не надо никаких классов со всеми прочими премудростями от лукавого. Просто Си с торговой надстройкой.

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

 

Посмотрим на торговое дело с другой стороны.

- есть индюкатор ВВ, но его как бы нет потому что множитель целое число, и так из сборки в сборку.

- есть тестер, который трудно рос от своей полной непригодности до нашей неполноценной работы.

и в нем, в тестере, доступны таки мультивалютные данные, но увы, они не синхронизированы с моделируемым интервалом.

- есть тики, есть таймфреймы и есть механизмы их трансформации, но не дают средств ихнего отображения.

это означает - не жди милостей.

ЭТО ВСЕГО ЛИШЬ ТЕРМИНАЛ с начинкой типа "Велика советская Власть".

это всего лишь придаток доброго ДЦ.

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

 
Korey >>:

Посмотрим на торговое дело с другой стороны.

- есть индюкатор ВВ, но его как бы нет потому что множитель целое число, и так из сборки в сборку.

- есть тестер, который трудно рос от своей полной непригодности до нашей неполноценной работы.

и в нем, в тестере, доступны таки мультивалютные данные, но увы, они не синхронизированы с моделируемым интервалом.

- есть тики, есть таймфреймы и есть механизмы их трансформации, но не дают средств ихнего отображения.

это означает - не жди милостей.

ЭТО ВСЕГО ЛИШЬ ТЕРМИНАЛ с начинкой типа "Велика советская Власть".

это всего лишь придаток доброго ДЦ.

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

а какие проблемы ? писать на Си++  и сейчас можно и раньше можно было

 

вы можете в принципе все организовать на Си++... 

оставив скрипту только механику работы с ордерами  и как средство доступа к счету, не более

   и у Вас вся мощь Си++ в руках... 

 

упрощенно как вариант - что то типа илюстрации мысли

--

start()

{

   siganl = ВызываемСвоюDLLнаписануюНаСи++("что то ей передаем или не передаем - если внутри  индикаторы тоже решены  ")

  if ( signal  == OP_BUY )

  {   

     // 

  }

  if ( signal == OP_SELL)

   {

       // 

   }

}

 

Да есть проблемы даже с вызовом dll. Например попробуйте вызов системной функции GetLastError (совпадает по названию с функцей терминала)?


Нужна команда переименования импортированных функций чтобы разрешить такие конфликты. Например так:


#import "kernel32.dll"

int GetLastError() windowsGetLastError;


Другая проблема - преобразование типов. Так как нет работы с ссылками и боюсь, что не будет, то надо решить и следующую проблему:


Пусть у меня есть функция F, которая принимает параметры неопределенного типа. Не такая уж и редкая ситуация, тем более в Windows API, где сплошь и рядом передаются адреса LPVOID.

В результате, если мне надо вызвать функцию для double и для string, то мне надо объявить импорт для каждого типа, но опять же имя-то у функции одно(!) Объявить для обоих типов невозможно.


И хотелось бы иметь следующую возможность. Передачу неопределенного количества параметров неопределенного типа.

#import "my.dll"

void myprintf( string formats, ...);

#import

myprintf("%s %f", TimeToStr(Time[i]), High);

myprintf("%d %f %f %f %f", iBarShift(null, null, StartDate), Low, High, Open, Close);

 


попытаюcь более конструктивно

узкие места.

отсутствие ООП не являектся узким местом MQL, т.к. не пишут больших программ
....больших программ не пишут потому что
а) не таких идей, средний размер советника 1000-2500 строк (всего то!)
б) не на чем их тестить идеи то.
в) нет в MQL очень нужных мыслящему программисту форматов и структур данных,
(любое проектирование начинается с данных)
г) удивительно медленные if (), особенно для bool переменных!!!)))
д) подозрительно недоступное графическое отображение
Это узкие места, шкуродер.недодел, эджи вонючие.
(вонючие потому что, например, слабо сделатьТФ терминала не константой, а переменной?)
Но опять же - что происходит с публично известными узкими местами,
прежде всего с тестером стратегий, со структурами данных, с тем же ТФ экрана.
А ничего не происходит.
Вместо этого обещают ООП.
т.е. мы привыкли что МТ-4 меняется от сборки к сборке, согласны с этим, и вправе расчитывать что узкие места,
шкуродеры будут также преодолены незаметно для внешнего слаза) как и раньше от сборки к сборке.
Мы готовы к недоделам, недостроям, недобросам, т.к. с ними то как раз и работаем каждый день.
Мы отказываемся от Светлых Идей ради веры в Приход MQL-5.
и что же?
ну почему мы решили что MQL-5 окажется доделаной лошадкой.
прозвучало волшебное слово ООП и все поплыли, все простили)))
....
Люди у нас хорошие.

 
Korey >>:


попытаюcь более конструктивно

узкие места.

отсутствие ООП не являектся узким местом MQL, т.к. не пишут больших программ
.... больших программ не пишут потому что
а) не таких идей, средний размер советника 1000-2500 строк (всего то!)
б) не на чем их тестить идеи то.
в) нет в MQL очень нужных мыслящему программисту форматов и структур данных,
(любое проектирование начинается с данных)
г) удивительно медленные if (), особенно для bool переменных!!!)))
д) подозрительно недоступное графическое отображение
Это узкие места, шкуродер.недодел, эджи вонючие.
(вонючие потому что, например, слабо сделатьТФ терминала не константой, а переменной?)
Но опять же - что происходит с публично известными узкими местами,
прежде всего с тестером стратегий, со структурами данных, с тем же ТФ экрана.
А ничего не происходит.
Вместо этого обещают ООП.
т.е. мы привыкли что МТ-4 меняется от сборки к сборке, согласны с этим, и вправе расчитывать что узкие места,
шкуродеры будут также преодолены незаметно для внешнего слаза) как и раньше от сборки к сборке.
Мы готовы к недоделам, недостроям, недобросам, т.к. с ними то как раз и работаем каждый день.
Мы отказываемся от Светлых Идей ради веры в Приход MQL-5.
и что же?
ну почему мы решили что MQL-5 окажется доделаной лошадкой.
прозвучало волшебное слово ООП и все поплыли, все простили)))
....
Люди у нас хорошие.

 

1 тестер универсален - для скорости можно и нужно писать свой

2 советники бывают от 3000тыс кода и более -  встречал

3 проектирование  , верно, методов представления данных мало

4 скорость нужна только если работаем с встроенным тестером  ( пишем свой проблемы обходим )

    в принятиях решения открыть закрыть скорость не нужна - ну если вы не пипсуете на спред 

5 графика - немного нехватает верно

---

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

или добавление структур данных ?

  в готовый проект вставинь новую субстанцию - которая изначально не пректировалась - достаточно сложно

--

да никто не считает что что то особое произойдет в MQL5,

будет просто удобней и проще будут новые форматы данных как я понимаю,

будет более быстрый исполняемый код - обещают... 

будет больше объектов и методов управления...

и будет скорее всего много патчей по началу! и это нормально

я например не жду никакой особо доделанной лошадки - будет просто вместо жигулей мерседес,

более удобный и комфортный - но ему тоже бензин будет нужен и сервис

---

 
TedBeer писал(а) >>

Да есть проблемы даже с вызовом dll. Например попробуйте вызов системной функции GetLastError (совпадает по названию с функцей терминала)?

Нужна команда переименования импортированных функций чтобы разрешить такие конфликты. Например так:

#import "kernel32.dll"

int GetLastError() windowsGetLastError;

Ну так в человеческих языках (;-) бывают такие штуки как alias

Declare Function DAQmxCfgChangeDetectionTiming Lib "C:\bas\RapidQ\RQIDE\nicaiu.dll" Alias "DAQmxCfgChangeDetectionTiming" (_

TaskHandle as long,_

risingEdgeChan as string, _

fallingEdgeChan as string, _

sampleMode as long, _

sampsPerChan0 as long,sampsPerChan1 as long_ 'uInt64

) as long 'int32


Может MQL5 сделать Basic-like?

;-)

 


1.
Почему вдруг ООП в MQL-5?
Жизнь поставила задачу коммерческого программирования.
Коммерческое программирование это якобы Объекты.
Поэтому MQL-5 - об'ектный.
Объектный потому что объекты - это якобы защита кода))))
Но все не так как учат преподаватели информатики.
Задача Коммерческого Программирования для МТ-4 это прежде всего невозможность декомпиляции.
Но в защите от декомпиляции об'екты вообще говоря левые.
Т.е. защита кода не требует объектного подхода и не нуждается в объектных решениях.
ООП и защита кода от декомпиляции никак не совпадают!
но объявив объектынй язык разработчики оказались в тяжелом положении.
у них нет платформы от которой можно было бы создать эффективный ОО язык.
Сочувствую.

2.
Почему нельзя перепрыгнуть в ООП прямо из MQL-4.
...на базе Си стандарта "Керриган" или Мs С 3.0, или Borland C 3.0 где есть структуры и определение пользовательских типов,
а также имеется развитый препроцессор
на этой прочной базе повяился С+ или Ms C5.0, Borland С 5.0, т.е. первое ООП
т.е. развитая адресная арифметика послужила средой для Объектного программирования.
Не иначе как благодаря хорошо отлаженной платформе С 3.0 были легко реализуемы объекты С+.

MQL-4 далеко до возможностей С 3.0.
MQL-4 не может быть исходным продуктом для развития в ООП.
Для реализации ООП нужен проверенный промежуточный уровень.
и прежде перехода на объекты этот промежуточный уровень должен быть глубоко и всесторонее протестирован.
Поэтому уровень С3.0 как платформа для ООяза необходим, обязателен, и его нельзя пропустить или перепрыгнуть.
Было бы разумно выпустить версию MQL-4+ уровня C3.0 (Керриган) в публичное тестирование (без объектов)
Это может быть Metalang по выбору, типа бета тестирования.
Это даст ощутимый результат в отладке MQL-5.
Это будет тестовым полигоном для отладки защиты от декомпа.
И это же будет прочной основой для создания удачного корректно работающего объектно ориентированного языка.

Повторю предложение:
предоставить народу в бета тестирование язык терминала в нотациях Керигана (С 3.0), назовем условно такой язык MQL-4+

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