テンプレート・パラメータ = void* のコンパイラ・バグ - ページ 7 1234567891011121314...20 新しいコメント fxsaber 2018.12.20 07:48 #61 Alexey Navoykov:私ならこうする。 私はこのスタイルに違和感を覚えます。つまり、「フェルトペン」に行き着くのである。 Alexey Navoykov 2018.12.20 07:52 #62 fxsaber:では、あなたも警告が欲しいのですか?このダブルスタンダードは何なのでしょう。どちらの場所でも行動は明確なのに、括弧付きでは警告に反対し、ここでは賛成しているのでしょうか?わかりにくいミスをしないために、警告が必要なのです。つまり、難易度は主観的な評価なのです。だから、ブラケットではミスをしないのに、ここではミスをすることができるのです。そして、私にとってはその逆です。 では、警告を発するルールはどちらに合わせるべきなのでしょうか?ダイナミックキャストは常に明示的な操作でなければならない、という点を理解していないようです。C++、C#、Java、その他のOOP言語など、通常の言語では、このようなコードはコンパイルできません。これが信頼性の高いOOPの基本です。しかし、ここではなぜか忘れ去られていた。 ブラケットの比較は、ここではまったく適切でないと思った。 fxsaber 2018.12.20 08:05 #63 Alexey Navoykov:信頼できるOOPの基本中の基本。曖昧さをなくすことが基本。 pavlick_ 2018.12.20 08:30 #64 Ilya Malev:リファレンスコードの意味がわからない(標準ライブラリも使わないけど)。オブジェクトを配列に格納する際に、そのオブジェクトのコピーを作成する必要がある場合、このクラスで代入メソッドまたはコピーコンストラクタを明示的に宣言し記述しなければなりません。オブジェクトへの参照を配列に入れるだけなら、ラッパーは全く必要ありません(なぜ?) そのような配列が必要な理由は何ですか?プラスベクトルにほぼ類似しているので、vector<int>, vector<class_name>, vector<class_name*> のように動作するはずです。μlによって包み隠さず実装できるのであれば、良いことです(できないと思いますが)。配列を実行してデストラクタを呼び出す( _data[i].‾Destr( ) )方法も、部分特殊化も、SFINAEトリックもありません。このラッピングにより、例えばvector<int>で作業する可能性を壊すことなく、ヒープ上のオブジェクトへのポインタに適した配列になります。 vector<unique_ptr<my_class>> v1;vector<my_class> v2; vector<int> v3; ZS: なんというか、vector<クラス名*>はプラスでも期待通りに動かない(vectorの寿命が尽きたときにデストラクタが呼ばれる)ので、ラップが必要です。 Ilya Malev 2018.12.20 08:51 #65 pavlick_:ZS: なんというか、vector<クラス名*>はプラスでも期待通りに動かない(vectorの寿命が尽きる時にデストラクタが呼ばれる)ので、ラップも必要なんですよね。うまくいくかな?) template<typename T> void del(T par){printf("%s не удаляем",typename(T));} template<typename T> void del(T *par){printf("%s удаляем",typename(T));delete par;} class A{public:void~A(void){printf("удаляем %i",&this);}}; void OnStart() { int var1; A *var2=new A; del(var1); del(var2); } 追伸:類推するに、関数はvoidの代わりに何でも返すことができ、SFINAEは必要ありません。 pavlick_ 2018.12.20 09:01 #66 はい、それで結構です。しかし、まだラッパーが必要です。普遍的な配列が必要なので、削除する必要があるポインタを持つこともあれば、持たないこともあります(まあ、ポインタのセットだけですが、他の配列で何かを見つけたときの結果です)。 Alexey Navoykov 2018.12.20 09:07 #67 pavlick_:プラス面では、void*の削除はUBです。ちなみに、今まで考えてもみませんでした、ありがとうございます。 この場合のdeleteはfree()と似ていることがわかりました。 deleteはオブジェクトに対する位置づけで、単にルールを回避してメモリを解放しているだけなので、禁止されているはずです。 ここでもデストラクタが呼ばれるのだが、C++に移植する場合、問題が発生することがある。 Ilya Malev 2018.12.20 09:12 #68 pavlick_: ああ、それでいい。しかし、まだラッピングが必要です。結局のところ、私たちは普遍的な配列を必要としているので、削除を行う必要があるポインタを持つこともあれば、持たないこともあります(まあ、単なるポインタの束ですが、別の配列で何かを見つけた結果です)。まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか(お好みで)、といったオプションを追加で渡すことは誰も禁止していないのですが。結局のところ、アイテムを削除したいのかどうか、推測することはできません))。 追伸:ちなみに、配列に入れる前にポインタをラップしても、配列を削除するときにそのベースオブジェクトを削除する必要があるかどうかという問題は解決しません)) A100 2018.12.20 09:55 #69 fxsaber:括弧を追加したことで、言語の優先順位による影響を完全に排除することができました。すべてが完全に曖昧になるのです。これにより、次のビルド以降に何も壊れないという100%の信頼性が得られます。このことを踏まえて、まとめておこう。 A100デベロッパーファクスセーバー括弧必要不可欠な場所だけにもしかしたら、今までMQL4が違っていたところにも何処でも必要とされているじょうちょう必要ない以前はMQL4が異なっていた場所のみ要所要所優先順位が必要です。要不要 もし私が正しく述べていないのであれば、訂正してください。 pavlick_ 2018.12.20 09:58 #70 Ilya Malev:まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか(お好みで)、というオプションを追加で渡すことは誰も禁止していないんですけどね。なぜなら、アイテムを削除すべきかどうか、推測するのが難しいからです))。一般的には、はい、そのようにできます。 追伸:ところで、ポインタをラップしてから配列に入れるからといって、配列を削除するときにそのベースオブジェクトを削除する必要があるかどうかという問題は、これ以上明確にならないでしょう)) 包まなければ消さない、包めば消す、透き通っています。 ZS: でも、もしやるなら、標準のプラスライブラリとなるべく似たようなこと(名前、動作など)をやるので、僕には選択肢がないんです。すでにすべてが書かれているのに、なぜわざわざ別の仕様書を作るのか? 1234567891011121314...20 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
私ならこうする。
私はこのスタイルに違和感を覚えます。つまり、「フェルトペン」に行き着くのである。
では、あなたも警告が欲しいのですか?このダブルスタンダードは何なのでしょう。どちらの場所でも行動は明確なのに、括弧付きでは警告に反対し、ここでは賛成しているのでしょうか?
わかりにくいミスをしないために、警告が必要なのです。つまり、難易度は主観的な評価なのです。だから、ブラケットではミスをしないのに、ここではミスをすることができるのです。そして、私にとってはその逆です。
では、警告を発するルールはどちらに合わせるべきなのでしょうか?
ダイナミックキャストは常に明示的な操作でなければならない、という点を理解していないようです。C++、C#、Java、その他のOOP言語など、通常の言語では、このようなコードはコンパイルできません。これが信頼性の高いOOPの基本です。しかし、ここではなぜか忘れ去られていた。 ブラケットの比較は、ここではまったく適切でないと思った。
信頼できるOOPの基本中の基本。
曖昧さをなくすことが基本。
リファレンスコードの意味がわからない(標準ライブラリも使わないけど)。オブジェクトを配列に格納する際に、そのオブジェクトのコピーを作成する必要がある場合、このクラスで代入メソッドまたはコピーコンストラクタを明示的に宣言し記述しなければなりません。オブジェクトへの参照を配列に入れるだけなら、ラッパーは全く必要ありません(なぜ?)
そのような配列が必要な理由は何ですか?プラスベクトルにほぼ類似しているので、vector<int>, vector<class_name>, vector<class_name*> のように動作するはずです。μlによって包み隠さず実装できるのであれば、良いことです(できないと思いますが)。配列を実行してデストラクタを呼び出す( _data[i].‾Destr( ) )方法も、部分特殊化も、SFINAEトリックもありません。このラッピングにより、例えばvector<int>で作業する可能性を壊すことなく、ヒープ上のオブジェクトへのポインタに適した配列になります。
vector<unique_ptr<my_class>> v1;
vector<my_class> v2;
vector<int> v3;
ZS: なんというか、vector<クラス名*>はプラスでも期待通りに動かない(vectorの寿命が尽きる時にデストラクタが呼ばれる)ので、ラップも必要なんですよね。
うまくいくかな?)
追伸:類推するに、関数はvoidの代わりに何でも返すことができ、SFINAEは必要ありません。
プラス面では、void*の削除はUBです。
ちなみに、今まで考えてもみませんでした、ありがとうございます。 この場合のdeleteはfree()と似ていることがわかりました。 deleteはオブジェクトに対する位置づけで、単にルールを回避してメモリを解放しているだけなので、禁止されているはずです。
ここでもデストラクタが呼ばれるのだが、C++に移植する場合、問題が発生することがある。
ああ、それでいい。しかし、まだラッピングが必要です。結局のところ、私たちは普遍的な配列を必要としているので、削除を行う必要があるポインタを持つこともあれば、持たないこともあります(まあ、単なるポインタの束ですが、別の配列で何かを見つけた結果です)。
まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか(お好みで)、といったオプションを追加で渡すことは誰も禁止していないのですが。結局のところ、アイテムを削除したいのかどうか、推測することはできません))。
追伸:ちなみに、配列に入れる前にポインタをラップしても、配列を削除するときにそのベースオブジェクトを削除する必要があるかどうかという問題は解決しません))括弧を追加したことで、言語の優先順位による影響を完全に排除することができました。すべてが完全に曖昧になるのです。これにより、次のビルド以降に何も壊れないという100%の信頼性が得られます。
このことを踏まえて、まとめておこう。
もし私が正しく述べていないのであれば、訂正してください。
まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか(お好みで)、というオプションを追加で渡すことは誰も禁止していないんですけどね。なぜなら、アイテムを削除すべきかどうか、推測するのが難しいからです))。
一般的には、はい、そのようにできます。
包まなければ消さない、包めば消す、透き通っています。
ZS: でも、もしやるなら、標準のプラスライブラリとなるべく似たようなこと(名前、動作など)をやるので、僕には選択肢がないんです。すでにすべてが書かれているのに、なぜわざわざ別の仕様書を作るのか?