エラー、バグ、質問 - ページ 707

新しいコメント
 
MetaDriver:

しかし、その場合、構造体の配列を 継承 する可能性があり、かつ、一度指定したサービス（ソートやバイナリ検索）をカプセル化するクラスを作成することはできません。

なるほど、具体的な解決策ではなく、抽象的な可能性についての話だったのですね。

外部システムのエッジで 効果的に作業したい場合は、セキュリティ問題と矛盾するような普遍的なソリューションを作ろうとするのではなく、サイト固有のコードを書くようにします。

 
Renat:

いいえ、そのようなハンドリングは行いません。これは完全な悪であり、私たちは最後までその責任を問われることになります。

あまりに無責任だ 危険はないだろう
 
MetaDriver:
あまりないですね、危険は見えませんから。

巨大なハンドラップテーブルの必然性を指摘したのです。巨悪である。

あなた自身はインデックスを使いたくない、不便だと言っているのに、突然MQL5内の巨大で遅いハンドルのテーブルが「何の危険もない」と言い出したのです。

 

Renat:

...............................セキュリティの問題と矛盾するような一律的な解決策をとるのではなく

レナット、構造物へのハンドルの危険な使い方の例を一つでも挙げてください。 頑なに見当たりません。 思い出そうとしているのですが、見つからないのです。 何か見落としているのでしょうか？

--

パラメトリック構造についてはどうでしょうか？ 長期的にはあるのでしょうか？ すべてはプリプロセッサのレベルで解決されるので、セキュリティの問題は一般的に問題外です。 また、便利なデータコンテナに関する多くの問題は、非常にうまくコンパクトに解決されるでしょう。

 
Renat:

1.巨大なハンドル照合テーブルの必然性を指摘した。これは大きな悪です。

あなた自身はインデックスを扱う気もなく、いかに不便かを語っているのに、突然MQL5の巨大で遅いハンドルのテーブルが「何の危険も伴わない」と言い出したのです。

1.テーブルが巨大なのではなく、ユーザーが「扱った」ものであり、動的に拡張可能。 その時、文字列も悪である。それなら、1行のシンボル数を128個に制限しよう。 そうすれば、世の中の悪が少なくなるだろ？:)

2.本当はインデックスの仕事もしたい。 ただ、何度も何度も仕事をするのは嫌だ。自分の仕事を継承して、必要な時に再現したい。（ずさんなコピーペーストの修正で新たなエラーを発生させる）書き直しはしたくない。

 
MetaDriver:
でも、もうその話もしないし、した方がいいのかも？
どちらかというと、少なくとも一票の支持を得たことになりますね :)
 
MetaDriver:

1.テーブルが巨大ではなく、ユーザーが "nahndled "として - 動的に拡張可能です。それなら、1行のシンボル数を128個に制限しよう。 そうすれば、世の中の悪が少なくなるだろ？:)

文字列は内部で束縛され、外部でそれを要求する人はいません。つまり、テーブルで表示される公開用ハンドルを管理する必要はないのです。そこでは、すべてが素早く、隠されているのです。

"User nahndled" - それは巨大でブレーキがかかるテーブルです。

いきなり問題を起こしたりしない。だから、この問題を強調しすぎるのはやめよう。この問題は解決済みで、どんな議論でも変えることはできないのだ。

 
MetaDriver:

パラメトリック構造についてはどうでしょうか。 長期的な計画ではありますか？ そこではすべてがプリプロセッサのレベルで解決されるので、セキュリティの問題は一般的に解決されます。 また、使えるデータコンテナに関する多くの問題は、非常にうまく、コンパクトに解決されるでしょう。

テンプレートはまだ予定にありません。

今は静的クラスのミームと演算子のオーバーロードを解放して います。

 
Renat:

現在、静的クラスのミームと演算子のオーバーローディングを解放して います。

インターフェースに期待していいのか、それともこの問題は解決したのか？
 
Renat:

1.テンプレートはまだ予定にありません。

2.静的クラスのミームと演算子のオーバーローディングを解放 することになりました。

1.残念、企画した方がいいかもしれませんね。

2.このために - 巨大な人間感謝、ビルドを楽しみにしています。

1...700701702703704705706707708709710711712713714...3185
新しいコメント