ラウンジでPLOについて語る - ページ 8

 
Maxim Dmitrievsky:

おそらく、私はこのコードをほとんど理解していないためです :)

すみません、私はプログラマーとしては素人なので...OOPは基本的なレベルしか知らないのですが...。

まあ、理解できないのは、あなただけではありませんから...。詰め込めないものをマクロに詰め込むというこのスタイルには、一長一短があります。私が気づいた限りでは、同僚のfxsaberは 利点(柔軟性、クロスプラットフォームなど)しか示して いません。しかも、そんなコードをデバッガで確認できないって、何それ?まあ、このようなスタイルは読みやすさには疑問が残りますが。でも、師匠は師匠と言うし...。

 
Комбинатор:
C++では、クラスと構造体は同じで、いくつかのデフォルトが異なるだけです。

構造体へのポインタはどうするのですか?

 
Vasiliy Sokolov:

だから、正しい事例から学ばなければならないのです。しかもSBにはない。CObjectを例にとると、型制御を提供 せず、オブジェクトとのインターフェースレベルの作業も提供せず、Save()やLoad()のような実際には再定義されることのない無意味なメソッドを含んでいるのです。m_prev と m_next ポインタは、単一のCList クラスで 使用されますが、その子孫のすべてのクラスでバラストとして存在します。最も便利なのはComparer()メソッドです。実際には最も頻繁に上書きされます。しかし、普通に考えれば、Comparer()はインターフェースなので、CObjectではなく、別のクラスとして定義した方が良いのでしょう。

制御について、よくわからないので説明してください。どのようなものですか?一般に、これはフィールドやメソッドを持たないダミークラスであるべきです。その唯一の目的は、他のクラスに共通の祖先を提供することです。開発者がゴミを詰め込んだのは大失敗だ。

そこにCompareはないはずです。ダミークラスであること。

 
Alexey Volchanskiy:

制御について説明してください、理解できません。どんなものを使って?フィールドやメソッドを持たないダミークラスであること。その唯一の目的は、他のクラスの共通の祖先を提供することです。開発者がゴミを詰め込んだのは大失敗だ。

そこにCompareはないはずです。ダミークラスであること。

これはSmallTalkではなく、すべての実践(そして理論も)が、Adamからオブジェクトツリーを出力することは、平均的な悪であることを示しています。そしてSTはそれが許されている、自分の汁(自分の仮想マシン)の中にいる。

この暑さなら、3月8日にはトライ・キャッチ・スローができるのでは?:-)もちろん女性の祭典になるが、飲まないのは罪である。

 
Maxim Kuznetsov:

これはスモールトークではなく、すべての実践(理論も)は、アダムからオブジェクトツリーを派生させることは残酷な悪であることを示しています。そしてSTが許されるのは、自分のジュース(自分の仮想マシン)の中にいることだ。

3月8日にはトライキャッチスローが期待できるかもしれませんね。:-)もちろん女性の日ではあるが、飲まないのは罪であろう。


いや、休みはない。例外はない、とレナートは言った。参照https://www.mql5.com/ru/forum/168361 、 誰かが持ち出しました。私自身は、「エクセプツに何か予定があるのだろうか?答えは、残念ながらNOだった。

しかし、コンパイラには、重要なチェックボックスがあります。)3月8日までに「check array bounds...」のチェックボックスが入るのを待ちます。そして、同様のチェックボックスがある別の25ページが表示されます。抜粋の作り方がわからないんですよね。

SZY:C#のベースクラスObjectも最低限見てみました。画像はmsdnより


Почему в MQL5 нет исключений?
Почему в MQL5 нет исключений?
  • 2017.01.29
  • www.mql5.com
Не нужны, надо все условия руками проверять, по старинке оно надежнее Нужны, почему нет - не знаю А что это такое? Хочу посмотреть...
 
Dennis Kirichenko:

まあ、理解できないのはあなただけではありませんから......。詰め込めないものをマクロに詰め込むというこのスタイルには、一長一短があります。私が気づいた限りでは、同僚のfxsaber は利点(柔軟性、クロスプラットフォームなど)しか示して いません。しかも、 そんなコードをデバッガで確認 できないって、何それ?まあ、このようなスタイルは読みやすさには疑問が残りますが。しかし、よく言われるように、マスターはボスです。

なぜ、具体例に 含まれていないものを属性化するのか?

マキシム・ドミトリエフスキー

全く同じようにプログラミングを学ぶには、どのようなモデルがあるのでしょうか。:) とてもいい感じです。

独学だから、どこも追わないんです。私はツポレフ方式で、"美しい機体だけがよく飛ぶ!"と言っています。

 
Maxim Kuznetsov:

これはスモールトークではなく、すべての実践(理論も)が、アダムからオブジェクトツリーを派生させることは残酷な悪であることを示しているのです。そしてSTはそれが許されている、自分の汁(自分の仮想マシン)の中にいる。

この暑さからすると、3月8日にはトライ・キャッチ・スローができるのでは?:-)もちろん、女性の休日にはなりますが、お酒を飲まないのは罪ですからね。


空のベースクラスのポイントは、そういうものを書けることです。先に言っておくと、この例は役に立たない、その場しのぎで作ったものだ。ポイントは、どんな派生クラスも CObject*に還元できることです。

CObject* objarr[12];

void OnStart()
{
    objarr[0] = new CAccountInfo;
    // еще что-то подобное, кладем в массив указатели на объекты абсолютно разных классов, но с одним предков
    objarr[11] = new CDealInfo;
    // обращаемся и работаем
    CAccountInfo * ai = (CAccountInfo*)objarr[0];
    //
    
    for(int n = 0; n < 12; n++)
        if(CheckPointer(objarr[n]) == POINTER_DYNAMIC)
            delete objarr[n];
       
}

*

 
Alexey Volchanskiy:

構造体へのポインタはどうするんだ?

正直、質問の意味がよくわからないのですが、いずれにせよクラスの
 
Комбинатор:
正直、質問の意味がよくわからないのですが、いずれにせよクラスの

大変申し訳ないのですが、どの言語の文脈でこの結論を出しているのでしょうか?:-)



 
Комбинатор:
正直、質問の意味がよくわからないのですが、どちらにしても、クラス

class C {};
struct S {};

void OnStart()
{
    C *_c = new C; // так можно
    S *_s = new S; // указатели на структуру не допускаются 
}