PLO - ページ 8

[Flops]

関数のパラメータで参照を返すにはどうしたらよいですか？

このようなコードでは問題が発生します。

CMy* obj; // global
bool func(CMy* obj)
{
...
  obj = new CMy();
...
}

obj を操作しようとすると、無効なポインタ・ アクセスが発生します。

&を追加してみた。

bool func(CMy*& obj)

効くんです。関数のパラメータでの参照戻り値はドキュメントにはありませんでした。

類推するに、C++でこのようなトピックを見つけました。http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter。

しかし、ここでは**は通用しない。の代わりに*&ですか？

5.00.630 x64

[Yedelkin]

flops:

ドキュメントの関数のパラメータにリファレンスリターンが見つかりませんでした。

これのことですね。MQL5リファレンス / 言語の基礎 / データ型 / リファレンス。修飾語 & とキーワード this?

[削除済み]

flops:

関数のパラメータで参照を返すにはどうしたらよいですか？

このようなコードでは問題が発生します。

obj を操作しようとすると、無効なポインタ・アクセスが発生します。

&を追加してみた。

効くんです。関数のパラメータでの参照戻り値はドキュメントにはありませんでした。

類推するに、C++でこんなトピックがありました。http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter。

しかし、あなたの**はうまくいきません。の代わりに*&ですか？

5.00.630 x64

IMHO（昔の話です）。

引数でポインタを渡すことはできず、参照を作成します。クラスの新しいインスタンスを参照にバインドすることはできません。そうすると、次のような道が残ります。

CMy* func()
{
...
  CMy* obj;
  obj = new CMy();
  return(obj);
...
}

[Andrei01]

Vigor:

私はボトムアップでプログラミングすることの利便性を理解したため、OOPの支持者です。オブジェクト相互作用のインターフェースからクラスの実装まで。

インターフェースはクラスの外部にあるのでは？

[Flops]

220Volt:

IMHO（昔の話です）。

引数でポインターを渡すことはできず、参照を作成することができます。そのクラスの新しいインスタンスは、参照に添付することができません。そうすると、こんな選択肢が残されています。

質問の定義を間違えていました。

ポインタの参照渡しを 行う。というのは、*&の バリアントを使ってもいいのかどうか、また、さらなるバージョンアップでカバーされることはないのでしょうか？C++では、このような構成は合法と思われる。

[Flops]

Yedelkin:
参考にしているんですね。MQL5リファレンスガイド / 言語の基礎 / データ型 / リファレンス。修飾語 & とキーワード this?

正しい情報があればいいのですが・・・。

記事中

https://www.mql5.com/ru/docs/basis/function/ParameterPass

は、オブジェクトの操作に関する情報を追加することもできます。

[Igor Volodin]

Andrei01:
インターフェースはクラスの外部にあるのでは？

オブジェクトにどのような違いがあるのでしょうか？この解釈では、インターフェースはデータ型であり、その記述はオブジェクトの特性を十分に明確に定義しているからである。そして、実は、モノの外見的な振る舞いを定義しているのです。

引用した資料の中で、OOP反対派は、アルゴリズムを実装せずにすぐにクラス構造を 作ることは不可能であり、だからこそOOP環境ではリファクタリングを頻繁に実践し、クラスが永遠に再設計されることで開発の妨げに なると述べています。そして、これは本当にそうなんです。 新しいことを導入しても、それが何につながるか理解できていないと、授業をやり直したり、何度もやり直したりしなければなりません。

良いクラス・アーキテクチャを作ることは、初心者がつまずくところです。要するに、OOPプログラミングのポイントは、自分自身の「言語」を書くこと、つまり、将来にわたって簡単かつ高速に作成できる言語を書くことなのです。インターフェイスとは、そのタスクのために設計された言語の本質である。インターフェイスは、実のところ、クラスの「型の」構造として理解されてはならず、クラスの契約として、コードで実行されなければならない（MQLでは、それは存在せず、インターフェイスの役割は、仮想メソッドによって弱々しく実行することができる）。

例えば、新しいEAを作成するための「言語」を作成し、数行でオブジェクトからEAの一般的なスキームを組み立てることができるようにすることができます。シグナルやコンディションは既製品を使うこともできますし、シグナルのクラスを独自に開発し、類推して独自のライブラリを作成することも可能です。この可能性は、MQL5 Wizardによって 提供されます。

多くの場合、アプリケーションのスキームはすでに開発されており、「OOPプログラミング」は本質的に、既存のクラスを使い、独自の機能を書く自由度を制限することに集約される--これは便利である。そのため、フレームワークが普及しているのです。実際、自分で何かを書くということは、フレームワークのクラスの継承クラスを作成し、その中に、アプリケーション全体のロジックにすでに組み込まれている特定のバックエンドメソッド（例えば、OnInitやOnTickなど）の実装を書くということなのです。

[Vasiliy Sokolov]

Vigor:

...

有能なクラス・アーキテクチャの作成は、初心者がつまずくところです。要するに、OOPプログラミングのポイントは、自分自身の「言語」を書くこと、つまり、将来にわたって簡単かつ高速に作成できる言語を書くことなのです。インターフェイスとは、そのタスクのために設計された言語の本質である。インターフェイスは、クラスの "型 "の構成要素としてではなく、コードで実行されなければならないクラスの契約として理解されるべきです（MQLでは、それは存在せず、インターフェイスの役割は仮想メソッドによって検証することが可能です）。

...

OOPのポイントは、むしろ自分でアーキテクチャを書くことにあるのです。明確で直感的なアーキテクチャがあれば、すべてがうまくいき、プロジェクトの 複雑さやボリュームが制約要因にならなくなるのです。しかし、この明確なアーキテクチャを実現するためには、最初は漠然としていた理想に近づくために、一つ一つクラスを書き換えていかなければなりません。

[Vladimir Gomonov]

C-4:
むしろ、OOPのポイントは、自分でアーキテクチャを書くことです。明確で簡潔、かつ直感的に理解できるアーキテクチャがあれば、すべてがうまくいき、プロジェクトの複雑さやスコープが制約要因にならなくなるのです。しかし、この明確なアーキテクチャを実現するためには、漠然とした理想に近づくために、一つ一つクラスを書き換えていかなければなりません。

+1