uintFileReadStruct(
int file_handle, // handle файла constvoid& struct_object, // структура, куда происходит считывание int size=-1// размер структуры в байтах
);
struct X {
X( int i ) : i( i ) {}
constint i;
};
voidOnStart()
{
X x( 5 );
FileReadStruct( 0, x, -1 ); //(1) нормально ???
ZeroMemory( x ); //(2) Error: 'x' - not allowed for objects with protected members or inheritance
}
4番目のエラーは、あなた自身が報告したものです。なぜZeroMemoryは{}より悪いのですか?つまり、何らかの理由でコンパイラが検出できないような、プライベートへの不正なアクセス機構があるのです。
デベロッパーが直さないことを見越しているのでしょうか?一時期、コンパイラはZeroMemoryにも 反応しませんでした。
4番目のエラーは、あなた自身が報告したものです。なぜZeroMemoryは{}より悪いのですか?つまり、コンパイラが何らかの理由で検出できない、プライベートへの不正なアクセスの仕組みがあるのです。
エラーではないと思うのですが。構造体はコンストラクタを持たないが、初期化中である。FileReadStruct - それは本当に怖いことです...。
エラーとは思えません。構造体はコンストラクタを持たず、初期化される。それにしてもFileReadStructはなかなか怖いですね。
説明から判断すると-ある種の自己欺瞞である
説明を読む限り、 ある種の自己欺瞞のような気がします。
まあ、そうなんですが......全部、ごまかしなんですよ。
説明から察するに、これは ある種の自虐的なものである
コピーペーストの人工物にこだわらず、ドキュメントに言及する - 不思議だ。
コピーペーストの成果物を気にせずドキュメントにリンクする - 不思議だ。
私は全く初めてこの機能を参照してください - 彼らは、記述に誤りがあることを私に通知することができました
説明文の他に構造上の誤りがあります。
なぜZeroMemoryはFileReadStructより悪いのですか?
また、開発者が気づかない、先送りする、修正するのが億劫になる(下線部)という希望も?
私の主張は単純で、一時期ZeroMemoryはこれらすべて(privateを 含む)をコンパイルしていたが、それに気づき、手を入れ、修正した、というものです。
この機能は初めて見ました。説明文に間違いがあることを教えてくれてもよかったのに。
この機能の説明を見たことがない。名前からしてすべてが明確です。
記述の他に構造的なミスもあります。
以下のコードでは、エラーは発生しません。
便利さに退屈は勝てない!?
なぜZeroMemoryはFileReadStructより悪いのですか?
ドキュメントを参照するのが好きなんですね。そこには、ZeroMemoryの限界がすべて書かれています。しかし、File*の制限については何も書いていない。ゼロメモリに関しては、自分が持っているもので判断しています。今となっては不便ですが、わざわざそうしているようなものです。
しかし、この2つの関数を比較すると、FileReadStructは単純な構造体に対してのみ動作します。これは根本的な違いです。
このテーマは、MQL5の特殊性についてのものです。1を指しました(MQL4では動作しません)。このダイアログは、残念ながら、時間の無駄です。
以下のコードにエラーはありません。
ドキュメントを参照するのがお好きなようですね。そこにZeroMemoryの限界がすべて書いてある。しかし、File*の制限については何も書かれていない。ZeroMemoryに関しては、手持ちのものに頼っています。今となっては不便ですが、わざわざそうしているようなものです。
この2つの関数を比較すると、FileReadStructは単純な構造体に対してのみ動作する。これは、根本的な原理の違いです。
それは、クラスの外部の 関数(つまりFileReadStruct)が、このクラスの保護されたメンバに直接アクセスすることであり、private, protectedの概念そのものに矛盾して いることです。
また、この機能はZeroMemoryや他の何百もの機能より どのように優れているのでしょうか?何もない!- 開発者がまだ本腰を入れていないだけです。ZeroMemoryも 以前はドキュメントで制限を明記して いませんでした。しかし、今はあるのです。それは、何か不都合が生じるからではなく、単一の原理が働くからです。FileReadStructでもZeroMemoryでも、その他何百もの類似の関数でも、すべてが等しい のです。
百害あって一利なし
FileLoad/FileSaveを不等号ボックスへ。
便利さには勝てない!?
自分で自分の足を撃つ必要はないのです。
FileLoad/FileSaveをもっと不等号ボックスに。
自分の足を撃つ理由はない。
プライベートと 宣言して、自分の足を撃っているのはあなた自身です。自分自身へのアクセスを制限した上で、外部機能でパブリックアクセスが必要なコードが突然動かなくなったことを不思議に思うようになる