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

新しいコメント
 
Igor Makanu:

のように、ポインタのアドレスを取得するために、StringConcatenate()を使っていました。

StringConcatenateは 知りませんでした、MT5ではデザインが変更され、string sがないと使えないのが残念です。そして、StringFormatは4でより高速になりました。

そして、一般的に、文字列を通してポインタを「ポーリング」するこの操作は、5では2倍遅くなります。
 
fxsaber:

括弧は、式を完全に曖昧にしない。

また、「思いやりコンパイラ」の精神でいくと、バカなプログラマが何かミスをしたときのために、ifの中の式はすべて中括弧で囲むべきでしょう。

より明確にということであれば、スペースを入れれば十分です。

a<<1 | b<<2 | c<<3
 
pavlick_:

このような配列の有用性には、率直に言って疑問があります。それで何ができるのか？配列のメンバーに対して自動的にdeleteを呼び出さないことはご存知ですよね？

オブジェクトのデストラクタは常に仮想です。
 
Alexey Navoykov:
オブジェクトのデストラクタは常に仮想です。

試してみてください。ボイド（※）の場合、チャンスは全くありません。

 

deleteが自動的に呼び出されることは皆無である)。

配列のデストラクタがリストを調べて、必要ならすべてのオブジェクトを削除することを妨げないというのは別の話です

しかし，多くの理由から，共通の基本型を使用し，その参照を保存する方が有利です。
 

CArayObjectを廃棄する場合、ベースクラスの上にラッパー（このhttps://www.mql5.com/ru/forum/170952/page110#comment_9894796 のようなもの）を作り、配列（おそらく自分のもの）に入れる必要がありますが、そうすればvoid*は必要なくなります。

void*に反対しているわけではありません。必要なものですが、別の能力で。

 
pavlick_:

試してみてください。ボイド（※）の場合、チャンスは全くありません。

すべて正常に動作しているのに、なぜこんな作り話を？

class B
{
 public: 
  ~B() { Print(__FUNCSIG__); }
};

class A
{
 public: 
  B b;
  ~A() { Print(__FUNCSIG__); }
};

void OnStart()
  {
   A* a= new A;
   
   void* p= a;
   delete p;
  }

ログで取得します。

void A::~A()
void B::‾B()

それにしても、なぜ私はそれに引っかかったのだろう...。

 
Alexey Navoykov:

また、「思いやりコンパイラ」の精神でいけば、ifの中の式はすべて中括弧で囲むべきで、そうしないとバカなプログラマは混乱する。

より分かりやすくということであれば、スペースを入れれば十分です。

スペースでより明確にしたいのであれば、スペースを入れればいいのです。

 
余分なブラケットについて
class A
{
public:
  int i;
  
  A* GetPtr()
  {
    this.i = 1;
    
    return(&this);
  }
  
  void f()
  {
    Print(this.i);
  }
};

class B : public A
{
public:
  void* GetPtr()
  {
    this.i = 2;
    
    return(&this);
  }
};

void g( A* a)
{
  a.f();
}

void OnStart()
{    
  B* b = new B;
  
//   b.GetPtr().f(); // 'f' - member function not defined
  
  ((A*)b).GetPtr().f();   // 1
  ((A*)b.GetPtr()).f();   // 2
  ((A*)( b.GetPtr())).f(); // Доп. скобки, чтобы подчеркнуть, что именно имелось в виду, не полагаясь на приоритеты.

  delete b;
}
 
fxsaber:

スペースの視認性もなんのその。ようこそ、スタイリングツールの 世界へ。

もしスタイラーのせいで読みにくいコードが読めなくなるなら、わざわざスタイラーを使う必要はないでしょう。

私にとってスタイラーは、そのすべてのルールを柔軟にカスタマイズできてこそ、良いものです。

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