MQL構文に関する提案

 

このようなトピックを作ろうと思ったのは、私の観察によると、MQL構文の開発は長い間停滞しており、ここ数年、この言語の改善は見られません。 開発者がMQLに全く取り組む気がないのかどうかは分かりませんが、本当に多くの機能が欠けており、その中には決定的に重要なものも含まれています。

このスレッドでは、私の主な要望をリストアップすることにしました。 まず私がリストをあげ、おそらく誰かが他のものを追加し、その後、開発者が参加してビジョンを共有することができれば、それは素晴らしいことだと思います。

このリストは重要性の高い順に並べましたが、私個人の優先順位ではありません。 つまり、言語にとって最も基本的で不可欠なものを最初に並べました。C++やC#の機能をベンチマークとする


1.型を扱う:typedef,decltype,auto

これは、少なくとも最初の2つの指定子については、実は基本的な機能なのです。 ネーミングや型ホッピングの操作は、利便性だけでなく、コードの信頼性や柔軟性のために作られています。 異なる場所で使われる具体的な変数の型に固定値を設定すると、いずれかの型を変更する必要があるときに問題が発生します。

typedefについては、すでにご存知の方も多いと思うが、残念ながらまだ関数ポインタでしか使えない切り札である。decltypeについては、ご存じない方のために説明すると、引数として渡された式の型を返すので、他の型に基づいて変数や関数の型を柔軟に定義することが可能である。

int a=100;
//...
decltype(a) b= a;

typedefを使うか、どちらかです。

typedef int type;
type a= 100;
type b = a;
また、例えば長くて複雑な型(例えば ClassA< ClassB< ClassC,ClassD<ClassE> >)の場合、typedef で包むのは天の恵みです。

C#ではtypedefの代わりにusingが 使用される。

唯一可能なのは、defineを 使った型定義で、これはいくつかの問題をはらんでいる。


2.名前空間:namespace

このテーマは、すでに最近議論されています。私にとっては、この言語の必須機能であるにもかかわらず、なぜまだ実装されていないのか本当に不思議です。特に、コミュニティ、コードベース、グループ開発といった流れを考えると、なおさらです。この場合、名前のマッチングの問題が非常に重要になってきます。

ある関数内のローカル変数の名前が、他のファイルで定義された型の名前と 同じでも、コンパイラはエラーを発生させるという例を挙げていた。とんでもないことです。

しかも、すべてを一カ所に山積みするのは間違っています。


これがないと、ユーザー定義 型は本質的に不完全なものとなり、柔軟性が大きく損なわれてしまうのです。
時間を格納する構造体DATETIMEを作成し、それをdatetimeとして使用できるようにしたいとします。datetimeを受け付けるすべての関数に渡したり、datetimeを使用する式で使用したりします。
通常は、コンストラクタをオーバーロードし、対応する型にキャストすることで、この型と構造体の完全な互換性を得ることができます。

struct DATETIME
{
  DATETIME(datetime time) { ... }
  operator datetime() const { return ...; }
};

しかし、MQLでは、その代わりに、別のメソッドto_datetime() を作成し、その呼び出しをあらゆる場所に記述する必要があります。あるいは、DATETIME & typeのターゲット関数の呼び出しをオーバーロードする必要がありますが、これも快適性と柔軟性を向上させるものではありません。


4.マルチインターフェイス・・・ まあ、すでにいろいろと噂や話は出ているのですが(3年前にサービスデスクで作業中と書いてあったような)、引きずっているんですよね・・・。もし、まったく進行していないのであれば。



5.O OPで統一された作業を行うためには、構造体に対するインタフェースのサポートが 必要です。 現状では、松葉杖を作らなければならないことが多いのです。

この機能は、C#のようにパッケージング/アンパッキング(ボックス化)する方法と、より柔軟な方法として、構造体を含む動的オブジェクトの記述子にリンクした構造体の動的ハンドルを作成する方法の2つが考えられます。


6.構造体を値で渡すことが できます.これは,小さな構造体(上の例では DATETIME)を渡すときに重要で,構造体のコンストラクタがこの型をサポートしていれば,ある型から別の型にその場で柔軟に変換することができます.参照渡しの場合はこのような柔軟性はないが、構造体用のインタフェースが実装されれば、その意味はなくなる。


7.テンプレートの数値パラメータを指定することができます。

template<int N>
struct A
{
  char a[N];
};

A<100> a;
template<int N>
void f(int &arr[][N]) {  }

void start()
{
  int a[][5];
  f(a);
}

2番目の例については、MQL4では、関数があらゆる次元の配列を受け入れるので、なくても大丈夫です。そしてMQL5では、多次元配列によってすべてがより複雑になっています。


8.テンプレートの特殊化(特定の型に対する別個の実装)。

機能例です。
struct A
{
  double _value;
 
  template<typename T>
   T      ToType() { return (T)round(_value); }  
  template<>
   double ToType() { return _value; }
  template<>
   float  ToType() { return (float)_value; }
  template<>
   string ToType() { return DoubleToString(_value, 2); }
};

void f(A& a) { Print(a.ToType<string>()); }

クラスでの例。
template<typename T>
struct CArrayBase    // Базовый класс массива
{
  T _data[];
  int Size()          { return ArraySize(_data); }
  T operator[](int i) { return _data[i]; }
};

template<typename T>
struct CArray : CArrayBase<T> { };  // Основной класс массива

template<>
struct CArray<double> : CArrayBase<double>  // Специализация класса для массива double
{
  double Sum() { double sum=0;  for (int i=0; i<Size(); i++) sum+=_data[i];  return sum; } 
}; 

template<typename T>
struct CArray<T*> : CArrayBase<T*>  // Специализация класса для массива указателей
{
  void DeleteObjects() { for (int i=0; i<Size(); i++) { delete _data[i]; _data[i]=NULL; } }    
};

void start()
{
  CArray<double> arr1;
  arr1.Sum();  

  class A { };
  
  CArray<A*> arr2;
  arr2.DeleteObjects();
}



というように、小さなことでも


9.ポインタの配列をベースポインタの配列に(明示的または暗黙的に)キャストすることができる。昔のビルドではこれが有効で、とても便利だったんです。

interface I { };
class A : I { };

void f(I* &Array[]) {  }

void Main(A* &array[]) { f(array); }

これで、アレイを新しいものにコピーし直して、また元に戻すという無駄な労力を使うことになりました。

10. オブジェクト参照キャスト:(type&)object

これは、参照されるオブジェクトを関数に渡すことができるようにするために必要です。次の例では、クラスBのオブジェクトをベースクラスAのオブジェクトとしてファイルに書き出す必要がありますが、今これを行うには、中間関数を作成するか、オブジェクトを新しいオブジェクトにコピーしなければなりません。

struct A { int a; };

struct B : A { int b; };

B b;

void main()
{
  int h= FileOpen("MyFile",FILE_BIN|FILE_WRITE);
  FileWriteStruct(h, (A&)b);  // '&' - unexpected token
  FileClose(h); 
}


11. 配列や構造体を定数だけでなく、任意の式で初期化することができる。こ のような場合、コードを大幅に削減し、簡素化することができます。

void f(int a, int b, int c, int d, int e, int f)
{
  int arr[]= { a, b, c, d, e, f };
 //......
}


12.ポインタを明示的に数値にキャストすることが可能です。

ポインタの配列を値でソートして、バイナリサーチやハッシュテーブルを作ることで必要なポインタを素早く見つけることができるようになります。 今はテキスト形式に変換することでしか数値を得ることができないので、このアイデア自体が失われてしまっています。

13.デフォルトのテンプレートパラメーターの設定

template<typename T>
struct DefaultConstructor { static T* New() { return new T; } };

template<typename T, typename TConstructor=DefaultConstructor<T>>
struct A
{
  T* data;
  A() { data= TConstructor::New(); }
 ~A() { delete data; }
};

class B { };

A<B> a;
 

私見ですが、これだけのものが必要な人はほとんどいないのではないでしょうか。

Kodobaseのコードから判断すると、95%のユーザーはOOPをほとんど使っていません。そして、残り5%のマジョリティのうち、これらの機能はほとんど使われていない。確かにそれらは楽しいし、便利でもあるのですが、これらの改良に大きな必要性はないと私は考えています。

 
Georgiy Merts:

私見ですが、これだけのものが必要な人はほとんどいないのではないでしょうか。

Kodobaseのコードから判断すると、95%のユーザーはOOPを非常にうまく使っていません。そして、残りの5%のうち、ほとんどの人がこれらの機能をあまり使っていないのです。もちろん、それらは楽しいものですし、便利なものでもありますが、私が思うに、これらの改良に大きな必要性はないでしょう。

そうですね、でもkodobaseの他にFreelanceやMarketがあり、そこではMQは製品の品質に関心があるはずです。 そして言語の品質は、開発やデバッグの品質やスピードに何らかの形で影響を及ぼしますね。

そんなこと言ってたら、そもそもMQL5ってなんでできたんだろう。 OOPとか必要ない古いハードコアなMQL4のままなんだけど......。99%のユーザーが満足している )

おそらく普通のプログラマーは、まだ不完全な言語であるからこそ、MQLに行かないのでしょう。

 
Alexey Navoykov:

私の観察によると、MQLの構文の開発は長い間停滞しており、過去数年間は言語に改善が見られませんでした。 開発者がさらにMQLに取り組むつもりかどうかは分かりませんが、多くの機能が非常に不足しており、その中には決定的に必要なものも含まれています。

このスレッドでは、私の主な要望をリストアップすることにしました。 まず私がリストをあげ、おそらく誰かが他のものを追加し、その後、開発者が参加してビジョンを共有することができれば、それは素晴らしいことだと思います。

このリストは重要性の高い順に並べましたが、私個人の優先順位ではありません。 つまり、言語にとって最も基本的で不可欠なものを最初に並べました。C++やC#の機能をベンチマークとする


1.型を扱う:typedef,decltype,auto

これは、少なくとも最初の2つの指定子については、実は基本的な機能なのです。 ネーミングや型ホッピングの操作は、利便性だけでなく、コードの信頼性や柔軟性のために作られています。 異なる場所で使われる具体的な変数の型に固定値を設定すると、いずれかの型を変更する必要があるときに問題が発生します。

typedefについては、すでにご存知の方も多いと思うが、残念ながらまだ関数ポインタでしか使えない切り札である。decltypeについては、ご存じない方のために説明すると、引数として渡された式の型を返すので、他の型に基づいて変数や関数の型を柔軟に定義することが可能である。

typedefを使うか、どちらかです。

また、例えば長くて複雑な型(例えば ClassA< ClassB< ClassC,ClassD<ClassE> >)の場合、typedef で包むのは天の恵みです。

C#ではtypedefの代わりにusingが 使用される。

唯一可能なのは、defineを 使った型定義で、これはいくつかの問題をはらんでいる。


2.名前空間:namespace

このテーマは、すでに最近議論されています。私にとっては、この言語の必須機能であるにもかかわらず、なぜまだ実装されていないのか本当に不思議です。特に、コミュニティ、コードベース、グループ開発といった流れを考えると、なおさらです。この場合、名前のマッチングの問題が非常に重要になってきます。

ある関数内のローカル変数の名前が、他のファイルで定義された型の名前と 同じでも、コンパイラはエラーを発生させるという例を挙げている。とんでもないことです。

一般的に、1つのスペースにすべてを一山にするのは間違っています。


これがないと、ユーザー定義 型は本質的に不完全なものとなり、柔軟性が大きく損なわれてしまうのです。
時間を格納する構造体DATETIMEを作成し、それをdatetimeとして使用できるようにしたいとします。datetimeを受け付けるすべての関数に渡したり、datetimeを使用する式で使用したりします。
通常は、コンストラクタをオーバーロードし、対応する型にキャストすることで、この型と構造体の完全な互換性を得ることができます。

しかし、MQLでは、その代わりに、別のメソッドto_datetime() を作成し、その呼び出しをあらゆる場所に記述する必要があります。あるいは、DATETIME & typeのターゲット関数の呼び出しをオーバーロードする必要がありますが、これも快適性と柔軟性を向上させるものではありません。


4.マルチインターフェイス・・・ まあ、すでにいろいろと噂や話は出ているのですが(3年前にサービスデスクで作業中と書いてあったような)、引きずっているんですよね・・・。もし、まったく進行していないのであれば。



5.O OPで統一された作業を行うためには、構造体に対するインタフェースのサポートが 必要です。 現状では、松葉杖を作らなければならないことが多いのです。

この機能は、C#のようにパッケージング/アンパッキング(ボックス化)する方法と、より柔軟な方法として、構造体を含む動的オブジェクトの記述子にリンクした構造体の動的ハンドルを作成する方法の2つが考えられます。


6.構造体を値で渡すことが できます.これは,小さな構造体(上の例では DATETIME)を渡すときに重要で,構造体のコンストラクタがこの型をサポートしていれば,ある型から別の型にその場で柔軟に変換することができます.参照渡しの場合は、そのような柔軟性はなく、構造体用のインタフェースを実装すれば、あまり関係なくなりますが。


7.テンプレートの数値パラメータを指定することができます。

2番目の例については、MQL4では、関数があらゆる次元の配列を受け入れるので、なくても大丈夫です。そしてMQL5では、多次元配列によってすべてがより複雑になっています。


8.テンプレートの特殊化(特定の型に対する別個の実装)。

機能例です。

クラスでの例。



というように、小さなことでも


9.ポインタの配列をベースポインタの配列に(明示的または暗黙的に)キャストすることができる。昔のビルドではこれが有効で、とても便利だったんです。

これで、アレイを新しいものにコピーし直して、また元に戻すという無駄な労力を使うことになりました。

10. オブジェクト参照キャスト:(type&)object

これは、参照されるオブジェクトを関数に渡すことができるようにするために必要です。次の例では、クラスBのオブジェクトをベースクラスAのオブジェクトとしてファイルに書き出す必要がありますが、今これを行うには、中間関数を作成するか、オブジェクトを新しいオブジェクトにコピーしなければなりません。


11. 配列や構造体を定数だけでなく、任意の式で初期化することができる。こ のような場合、コードを大幅に削減し、簡素化することができます。


12.ポインタを明示的に数値にキャストすることが可能です。

ポインタの配列を値でソートして、バイナリサーチやハッシュテーブルを作ることで必要なポインタを素早く見つけることができるようになります。 今はテキスト形式に変換することでしか数値を得ることができないので、このアイデア自体が失われてしまっています。

13.デフォルトのテンプレートパラメーターの設定

応援しています。

 
Georgiy Merts:

私の考えでは、これだけのものを必要とする人はごく少数だと思います。

Kodobaseのコードから判断すると、95%のユーザーはOOPをほとんど使っていません。そして、残り5%のマジョリティのうち、これらの機能はほとんど使われていない。もちろん、それらはいいものですし、便利なものでもありますが、これらの改良はあまり必要ないと私は考えています。

この少人数で、みんなが使うようなライブラリを書くことができるのです。

 

14.関数の引数が 定数参照である場合に、一時的なオブジェクトを渡すことができるようにする。

template< typename Type >
struct complex
{
   Type Re;
   Type Im;
   
   complex() : Re(), Im(){}
   complex( Type re, Type im ) : Re(re), Im(im){}
};

template< typename Type >
void Func( const Type& val )
{
}

void OnStart()
{
   Func( 5.0 );
   
   complex< double > C( 1.0, 5.0 );
   Func( C );
   
   Func( complex< double >( 2.0, 4.0 ) );
}

15.友人というキーワード

クラスによっては、特定のクラスにのみプライベート・メンバーへのアクセスを許可し、他のクラスには許可しないようにしたい場合があります。

template< typename Type >
class Matrix;

template< typename Type >
class MatrixData
{
   friend class Matrix< Type >;
   
   int mRefCount;
   int mRows;
   int mColumns;
   
   Type mArray[];
   
public:
   MatrixData();
   MatrixData( int rows, int cols );
};

template< typename Type >
class matrix
{
   MatrixData< Type >* mData;
   
public:
        Matrix();
        Matrix( int rows, int cols );
};

16. 組み込み型のコンストラクタを明示的に呼び出す際に、変数を NULL にする。

これは、テンプレートで便利です。

   double x;         // Не инициализирована
   double y();       // Инициализирована нулём
   double z = 5.0;   // Инициализирована 5.0
 
道標すらない)これ以上基本的なことがあるだろうか?)
 
Alexey Navoykov:

このようなトピックを立てることにしたのは、私の観察によると、MQLの構文開発は長い間停滞しており、ここ数年、言語の改良は行われていません。 開発者がMQLに取り組むかどうかはわかりませんが、多くの機能が本当に欠けており、そのうちのいくつかは非常に必要とされています。

このスレッドでは、主な希望をまとめることにしました。 まず私がリストをあげ、もしかしたら誰かが何かを追加するかもしれません。 そして、開発者たちがつながり、彼らのビジョンを表現してくれたら、それはとても素晴らしいことです。

禁止事項を期待する、経典の批判は許されない :)

PS: 改善は、それほどグローバルなものではありませんでしたが、ありました。

 
secret:
ポインターも持っていない)これ以上基本的なことがあるだろうか)

ないだろう、GCがないとはいえ、言語は管理されているのだから

シャープもアンセーフモードだけにしています。

 
Alexey Navoykov:

そうですね、でもkodobaseの他にFreelanceやMarketがあり、そこではMQは製品の品質に関心があるはずです。 そして言語の品質は、開発やデバッグの品質やスピードに何らかの形で影響を及ぼしますね。

そんなこと言ってたら、そもそもMQL5ってなんでできたんだろう。 OOPとか必要ない古いハードコアなMQL4のままなんだけど......。99%のユーザーが満足している )

普通のプログラマーがMQLに行かないのは、まだ未完成な言語だからかもしれません。

コドベースは95%ゴミで全然ダメ。MT5の新バージョンを久しぶりに見た。レナートは、新しいリリースでグローバルな何かを約束したと記憶しています。

 
Alexey Volchanskiy:

PS:改善点は、それほどグローバルなものではありませんでしたが、ありました。

最後に覚えているのは、ダイナミック・オブジェクトのコピーを可能にする暗黙のコピー演算子ですが、特にあれから多くの時間が経過しているため、それは何でもありません。

理由: