mql5言語の特徴、微妙なニュアンスとテクニック - ページ 211

新しいコメント
 
fxsaber #:

4番目のエラーは、あなた自身が報告したものです。なぜZeroMemoryは{}より悪いのですか？つまり、何らかの理由でコンパイラが検出できないような、プライベートへの不正なアクセス機構があるのです。

デベロッパーが直さないことを見越しているのでしょうか？一時期、コンパイラはZeroMemoryにも 反応しませんでした。

 
A100 #:

4番目のエラーは、あなた自身が報告したものです。なぜZeroMemoryは{}より悪いのですか？つまり、コンパイラが何らかの理由で検出できない、プライベートへの不正なアクセスの仕組みがあるのです。

エラーではないと思うのですが。構造体はコンストラクタを持たないが、初期化中である。FileReadStruct - それは本当に怖いことです...。

 
fxsaber #:

エラーとは思えません。構造体はコンストラクタを持たず、初期化される。それにしてもFileReadStructはなかなか怖いですね。

uint  FileReadStruct( 
   int          file_handle,        // handle файла 
   const void&  struct_object,      // структура, куда происходит считывание 
   int          size=-1             // размер структуры в байтах 
   );

説明から判断すると-ある種の自己欺瞞である

 
A100 #:

説明を読む限り、 ある種の自己欺瞞のような気がします。

まあ、そうなんですが......全部、ごまかしなんですよ。

 
A100 #:

説明から察するに、これは ある種の自虐的なものである

コピーペーストの人工物にこだわらず、ドキュメントに言及する - 不思議だ。

 
fxsaber #:

コピーペーストの成果物を気にせずドキュメントにリンクする - 不思議だ。

私は全く初めてこの機能を参照してください - 彼らは、記述に誤りがあることを私に通知することができました

説明文の他に構造上の誤りがあります。

struct X {
    X( int i ) : i( i ) {}
    const int i;
};
void OnStart()
{
    X x( 5 );
    FileReadStruct( 0, x, -1 ); //(1) нормально ???
    ZeroMemory( x );            //(2) Error: 'x' - not allowed for objects with protected members or inheritance
}

なぜZeroMemoryはFileReadStructより悪いのですか？

また、開発者が気づかない、先送りする、修正するのが億劫になる（下線部）という希望も？

私の主張は単純で、一時期ZeroMemoryはこれらすべて（privateを 含む）をコンパイルしていたが、それに気づき、手を入れ、修正した、というものです。

 
A100 #:

この機能は初めて見ました。説明文に間違いがあることを教えてくれてもよかったのに。

この機能の説明を見たことがない。名前からしてすべてが明確です。

記述の他に構造的なミスもあります。

以下のコードでは、エラーは発生しません。

struct MqlTick2 : private MqlTick {};

void OnStart()
{
  MqlTick2 Ticks[4] = {};

  uchar Bytes[];
  
  StructToCharArray(Ticks[0], Bytes);
  CharArrayToStruct(Ticks[1], Bytes);

  FileReadStruct(0, Ticks[0]);
  FileWriteStruct(0, Ticks[1]);
  
  FileWriteArray(0, Ticks);
  FileReadArray(0, Ticks);
}

便利さに退屈は勝てない！？


なぜZeroMemoryはFileReadStructより悪いのですか？

ドキュメントを参照するのが好きなんですね。そこには、ZeroMemoryの限界がすべて書かれています。しかし、File*の制限については何も書いていない。ゼロメモリに関しては、自分が持っているもので判断しています。今となっては不便ですが、わざわざそうしているようなものです。

しかし、この2つの関数を比較すると、FileReadStructは単純な構造体に対してのみ動作します。これは根本的な違いです。


このテーマは、MQL5の特殊性についてのものです。1を指しました（MQL4では動作しません）。このダイアログは、残念ながら、時間の無駄です。

 
fxsaber #:

以下のコードにエラーはありません。

ドキュメントを参照するのがお好きなようですね。そこにZeroMemoryの限界がすべて書いてある。しかし、File*の制限については何も書かれていない。ZeroMemoryに関しては、手持ちのものに頼っています。今となっては不便ですが、わざわざそうしているようなものです。

この2つの関数を比較すると、FileReadStructは単純な構造体に対してのみ動作する。これは、根本的な原理の違いです。

それは、クラスの外部の 関数（つまりFileReadStruct）が、このクラスの保護されたメンバに直接アクセスすることであり、private, protectedの概念そのものに矛盾して いることです。

また、この機能はZeroMemoryや他の何百もの機能より どのように優れているのでしょうか？何もない！- 開発者がまだ本腰を入れていないだけです。ZeroMemoryも 以前はドキュメントで制限を明記して いませんでした。しかし、今はあるのです。それは、何か不都合が生じるからではなく、単一の原理が働くからです。FileReadStructでもZeroMemoryでも、その他何百もの類似の関数でも、すべてが等しい のです。

 
A100 #:

百害あって一利なし

FileLoad/FileSaveを不等号ボックスへ。

便利さには勝てない！？

自分で自分の足を撃つ必要はないのです。

 
fxsaber #:

FileLoad/FileSaveをもっと不等号ボックスに。

自分の足を撃つ理由はない。

プライベートと 宣言して、自分の足を撃っているのはあなた自身です。自分自身へのアクセスを制限した上で、外部機能でパブリックアクセスが必要なコードが突然動かなくなったことを不思議に思うようになる

1...204205206207208209210211212213214215216217218...247
新しいコメント
理由: