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

新しいコメント
 
Igor Makanu:

現在、VSフォームを.dllでMT5に簡単な方法で添付したいのですが ))))- ボタンのクリックハンドラをクラスでラップし、ハンドラ関数のポインタ配列をトラバースして呼び出したいのですが、EAのメインコードでVSと同じ関数名、つまりbutton2_Click() ...button2_Click() を書けるようにしたいのです。

SZY：これはEOPの 問題です))))

悪気はないのですが、よく思い出してしまうのです。


1
 
Ilya Malev:

- 動的なOOPの中で自動的な構造を作ることはナンセンスである

では、スタックオブジェクト：myclass obj;はナンセンスなのか？それなら、私はハンディキャップを負っていることになりますね :)

 
pavlick_:

では、スタックオブジェクト：myclass obj;はナンセンスなのか？だから、私は手芸家なんです :)

いろんなタスクがあるんですよ。レトリックの練習は、具体的なタスクを記述しなければ、何でも思いつく...。

そう、「スタッカブル」（自動的な意味か）オブジェクトは基本的にナンセンスなのです。私の率直な意見ですが、これは決して真実ではなく、最後の例でもないのですが......。
 
ジョーカーには、OOPの主要な機能であるポリモーフィズムの 特性を発揮しないオブジェクトが必要なのですね。このような変数に、内容によって異なる性質を持つオブジェクトを代入することはないでしょう。リスト内のこの「変数」に別のオブジェクトをマッピングすることは全くできなくなります。なぜオブジェクトが必要なのですか？ 代わりに構造体を使ったほうがいいのでは？μl構造体は自分自身への参照を返すことができないからでしょうか...。そして、創造、破壊、自己複製など、絶え間ない暗黒が始まる。
 
Ilya Malev:
OOPの主要な機能であるポリモーフィズムの 特性を満たさないオブジェクトが欲しいのですか？このような変数に、内容によって異なる性質を持つオブジェクトを代入することはないでしょう。リスト内のこの「変数」に別のオブジェクトをマッピングすることは全くできなくなります。なぜオブジェクトが必要なのですか？ 代わりに構造体を使ったほうがいいのでは？μl構造体は自分自身への参照を返すことができないからでしょうか...。そして、創造、破壊、自己複製など、絶え間ない暗黒が始まる。

ポリモーフィズムのない生き方 ...もし、90％以上のケースで多型がなくても大丈夫だと言ったら？SOLID依存関係逆転の原則」を例にとると、まともなプロガーであれば、あらゆるところに抽象化、仮想メソッドを作るべきです（もちろん、高いオーバーヘッドを伴いますが）。C#の熟練者なら、このような書き方をするはずだ。https://pro-prof.com/forums/topic/dependency-inversion-principle。 あるいは、テンプレートを使って、こんな風に書くこともできます。

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


また、Buttonはポリモーフィズムやインターフェイスを一切使用せず、ディテールに依存しない。ポリモーフィズムにはニッチがありますが、それは彼らが言うよりずっと狭いものです。

ZS: まあ、誰も禁じてはいないんですけどね。

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
もちろん、ポリモーフィズムを使わないこともできますが、この場合、オブジェクトではなく、単純な構造 体を使う方が、はるかに誠実で論理的です。そうでなければ、顕微鏡で釘を打つことになります。より正確には、µl5の場合、非オブジェクト構造を完全に使用できない（オブジェクトと異なり、ポインタを渡すことができない）「実装機能」を回避しているのです。これは全く別の問題で、もはやOOPではなく、ただのOOです
 
pavlick_:

ZS: まあ、誰も禁じてはいないんですけどね。

いろんな松葉杖やスケマタを禁止する人はいないけど、なぜ？例えば、自動生成されたオブジェクトが、思いもよらないところで突然自爆してくれたら楽しいでしょう？

 
OOPのポイントは、あなたが選んだボタンを押す方法を使うことではなく、テンプレートや関数ポインタで実装できるのと同じように、システムのあらゆるオブジェクトに、リストのような、CArrayObjなどの ような松葉杖や関連する面倒なことをせずに、リスト構造に自己組織化して、適切なタイミングで任意の選択を作成できる、 Select, Query, Compare, Sortなどのメソッドをオーバーロードできるメソッドを適用するだけなんだ。(Clone/Copyでも、リスト/配列にコピーするかどうか、コピーする場合はどのようにコピーするかを、各オブジェクトが勝手に 決めることができます)。
 
Ilya Malev:

松葉杖やスケマタを作ることを誰も禁じてはいないが、なぜ？例えば、オートオブジェクトが予期せぬ時に突然破壊されたら、面白いですよね？

なぜなら、スタックオブジェクトは、ヒープ内のオブジェクトよりもはるかに高速だからです（メモリ割り当て）。自滅か？- それは何か新しい発見ですね :)しかし、もちろん必要な場合もあります。例えば、オブジェクトの数が実行時にしか分からない場合などです。

ZS: そうでない方が快適かもしれませんね、個人的な問題ですが。

 
Ilya Malev:
OOPのポイントは、あなたが選んだボタンを押す方法を使うことではなく、テンプレートや関数ポインタで実装できるのと同じように、システムのあらゆるオブジェクトに、リストのような、CArrayObjなどのような松葉杖や関連する面倒なことをせずに、リスト構造に自己組織化して、適切なタイミングで任意の選択を作成できる、 Select, Query, Compare, Sortなどのメソッドをオーバーロードできるメソッドを適用するだけなんだ。(Clone/Copyでも、リスト/配列にコピーするかどうか、コピーする場合はどのようにコピーするかを、各オブジェクトが勝手に 判断できる場合)。

私は、-ポリモーフィズムは 独自のニッチを持っている、と書きました。しかし、実践してみると、（少なくとも私個人は）それほど大きな意味はないことがわかります。テンプレートで問題を解決する方がよっぽどいい。

1...11121314151617181920
新しいコメント