配列(1次元2次元)から要素を削除するにはどうすればよいですか? - ページ 6 123456789 新しいコメント Ilya Malev 2018.12.23 23:10 #51 Aliaksandr Hryshyn: 次元の定義に問題があるのでしょうか?定義に問題はない。関数のパラメータとして異なる次元の配列を取得する際に問題があります。 Dmitry Fedoseev 2018.12.23 23:10 #52 ここでは、配列は4次元以上にはならない。だから、4種類の機能を書けばそれで終わりです。 Aliaksandr Hryshyn 2018.12.23 23:15 #53 Ilya Malev:定義に問題はない。関数のパラメータとして異なる次元の配列を取得する際に問題があります。 そういうのはクラスを使ってください。異なる配列を持つクラスのインスタンスを関数に渡す... Ilya Malev 2018.12.23 23:16 #54 Dmitry Fedoseev: ここでは、配列は4次元以上にはならない。だから、4種類の機能を書けばそれで終わりです。1より大きいサイズの配列は全く使ってはいけないし、異なるフィールドを持つものを操作する場合は、構造体の配列やオブジェクトのリストを使うことができる。私自身、自分で何かを書くときは必ずそうしています。しかし、私も遭遇する他の人のコードでは、多次元配列の ようなオプションにも遭遇します。そして、ここからが楽しいところなのですが...。 Ilya Malev 2018.12.23 23:17 #55 Aliaksandr Hryshyn: そういうのはクラスを使ってください。異なる配列を持つクラスのインスタンスを関数に渡す...異なる次元の配列に適用される関数呼び出しが 同じように見えるようにクラスを定義してみる。 Алексей Тарабанов 2018.12.23 23:18 #56 Ilya Malev:普通の質問、スレッドのタイトルの括弧を無視すればよかったのに。要素の数を知らなくても - できる。次元がわからなければ、無理 です。恐ろしい秘密を教えてあげよう。配列は1次元です。種類は問わない。もう言っただろ... Ilya Malev 2018.12.23 23:20 #57 Алексей Тарабанов:とんでもない秘密を教えてあげよう。配列は一次元である。種類は問わない。もう言ったはずだ... イリヤ・マレフそして、それがあなたのタスク(タスクのクラス - 関数を介して異なる次元の配列を扱う統一的な作業)とどのような関係があるのでしょうか? Aliaksandr Hryshyn 2018.12.23 23:20 #58 Ilya Malev:異なる次元の配列に対する関数呼び出しが 同じに見えるように、クラスを定義してみてください。 つまり、必要な配列はクラスで定義し、そのクラスのインスタンスを関数に渡せばいいのです。 Dmitry Fedoseev 2018.12.23 23:21 #59 興味深い現象が・・・。 コレクション用の関数を書くとき、(チェックなしで)速く動くようにするのがいいのか、それともパラメータの妥当性をチェックして修正できるようにフールプルーフにするのがいいのか、という疑問が出てくる。 void ArrayDelete(int & a[],int Start,int Count=1){ ArrayCopy(a,a,Start,Start+Count); ArrayResize(a,ArraySize(a)-Count); } あるいは、フールプルーフプロテクションで、合理的なパラメータをチェックし、調整できるようにするか?ここで、高速版は簡単に書けてしまうので、コレクションに値しないことがわかります。また、すべてのチェックを終えたバリアントは、不要なブレーキが不要なため、ミュージアムピースとしてのみ有効です。それが、まったく必要ないわけです。 Ilya Malev 2018.12.23 23:22 #60 Aliaksandr Hryshyn: つまり、必要な配列はクラスで定義し、そのクラスのインスタンスを関数に渡します。このように考えると、多次元配列は 一切宣言せず、異なるフィールドを持つ構造体の配列を使うべきということになります。しかし、問題はそれではなく、任意の(事前にわからない)次元の既存の配列で何ができるのか? 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
次元の定義に問題があるのでしょうか?
定義に問題はない。関数のパラメータとして異なる次元の配列を取得する際に問題があります。
定義に問題はない。関数のパラメータとして異なる次元の配列を取得する際に問題があります。
ここでは、配列は4次元以上にはならない。だから、4種類の機能を書けばそれで終わりです。
1より大きいサイズの配列は全く使ってはいけないし、異なるフィールドを持つものを操作する場合は、構造体の配列やオブジェクトのリストを使うことができる。私自身、自分で何かを書くときは必ずそうしています。しかし、私も遭遇する他の人のコードでは、多次元配列の ようなオプションにも遭遇します。そして、ここからが楽しいところなのですが...。
そういうのはクラスを使ってください。異なる配列を持つクラスのインスタンスを関数に渡す...
異なる次元の配列に適用される関数呼び出しが 同じように見えるようにクラスを定義してみる。
普通の質問、スレッドのタイトルの括弧を無視すればよかったのに。要素の数を知らなくても - できる。次元がわからなければ、無理 です。
恐ろしい秘密を教えてあげよう。配列は1次元です。種類は問わない。もう言っただろ...
とんでもない秘密を教えてあげよう。配列は一次元である。種類は問わない。もう言ったはずだ...
そして、それがあなたのタスク(タスクのクラス - 関数を介して異なる次元の配列を扱う統一的な作業)とどのような関係があるのでしょうか?
異なる次元の配列に対する関数呼び出しが 同じに見えるように、クラスを定義してみてください。
興味深い現象が・・・。
コレクション用の関数を書くとき、(チェックなしで)速く動くようにするのがいいのか、それともパラメータの妥当性をチェックして修正できるようにフールプルーフにするのがいいのか、という疑問が出てくる。
あるいは、フールプルーフプロテクションで、合理的なパラメータをチェックし、調整できるようにするか?ここで、高速版は簡単に書けてしまうので、コレクションに値しないことがわかります。また、すべてのチェックを終えたバリアントは、不要なブレーキが不要なため、ミュージアムピースとしてのみ有効です。それが、まったく必要ないわけです。
つまり、必要な配列はクラスで定義し、そのクラスのインスタンスを関数に渡します。
このように考えると、多次元配列は 一切宣言せず、異なるフィールドを持つ構造体の配列を使うべきということになります。しかし、問題はそれではなく、任意の(事前にわからない)次元の既存の配列で何ができるのか?