テンプレート・パラメータ = void* のコンパイラ・バグ - ページ 7

新しいコメント
 
Alexey Navoykov:

私ならこうする。

私はこのスタイルに違和感を覚えます。つまり、「フェルトペン」に行き着くのである。

 
fxsaber:

では、あなたも警告が欲しいのですか？このダブルスタンダードは何なのでしょう。どちらの場所でも行動は明確なのに、括弧付きでは警告に反対し、ここでは賛成しているのでしょうか？

わかりにくいミスをしないために、警告が必要なのです。つまり、難易度は主観的な評価なのです。だから、ブラケットではミスをしないのに、ここではミスをすることができるのです。そして、私にとってはその逆です。

では、警告を発するルールはどちらに合わせるべきなのでしょうか？

ダイナミックキャストは常に明示的な操作でなければならない、という点を理解していないようです。C++、C#、Java、その他のOOP言語など、通常の言語では、このようなコードはコンパイルできません。これが信頼性の高いOOPの基本です。しかし、ここではなぜか忘れ去られていた。 ブラケットの比較は、ここではまったく適切でないと思った。

 
Alexey Navoykov:

信頼できるOOPの基本中の基本。

曖昧さをなくすことが基本。

 
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の寿命が尽きたときにデストラクタが呼ばれる）ので、ラップが必要です。
 
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_:

プラス面では、void*の削除はUBです。

ちなみに、今まで考えてもみませんでした、ありがとうございます。 この場合のdeleteはfree()と似ていることがわかりました。 deleteはオブジェクトに対する位置づけで、単にルールを回避してメモリを解放しているだけなので、禁止されているはずです。

ここでもデストラクタが呼ばれるのだが、C++に移植する場合、問題が発生することがある。

 
pavlick_:
ああ、それでいい。しかし、まだラッピングが必要です。結局のところ、私たちは普遍的な配列を必要としているので、削除を行う必要があるポインタを持つこともあれば、持たないこともあります（まあ、単なるポインタの束ですが、別の配列で何かを見つけた結果です）。

まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか（お好みで）、といったオプションを追加で渡すことは誰も禁止していないのですが。結局のところ、アイテムを削除したいのかどうか、推測することはできません))。

追伸：ちなみに、配列に入れる前にポインタをラップしても、配列を削除するときにそのベースオブジェクトを削除する必要があるかどうかという問題は解決しません))
 
fxsaber:

括弧を追加したことで、言語の優先順位による影響を完全に排除することができました。すべてが完全に曖昧になるのです。これにより、次のビルド以降に何も壊れないという100%の信頼性が得られます。

このことを踏まえて、まとめておこう。


A100
デベロッパー
ファクスセーバー
括弧
必要不可欠な場所だけに
もしかしたら、今までMQL4が違っていたところにも
何処でも必要とされている
じょうちょう
必要ない
以前はMQL4が異なっていた場所のみ
要所要所
優先順位
が必要です。
要
不要

もし私が正しく述べていないのであれば、訂正してください。

 
Ilya Malev:

まあ、配列を作るときに、削除するときに要素を削除するかどうか、デフォルトでオンかオフか（お好みで）、というオプションを追加で渡すことは誰も禁止していないんですけどね。なぜなら、アイテムを削除すべきかどうか、推測するのが難しいからです))。

一般的には、はい、そのようにできます。

追伸：ところで、ポインタをラップしてから配列に入れるからといって、配列を削除するときにそのベースオブジェクトを削除する必要があるかどうかという問題は、これ以上明確にならないでしょう))


包まなければ消さない、包めば消す、透き通っています。

ZS: でも、もしやるなら、標準のプラスライブラリとなるべく似たようなこと（名前、動作など）をやるので、僕には選択肢がないんです。すでにすべてが書かれているのに、なぜわざわざ別の仕様書を作るのか？

1234567891011121314...20
新しいコメント