ab.com コミュニティ https://www.activebasic.com/forum/ |
|
Interfaceステートメントを追加!? https://www.activebasic.com/forum/viewtopic.php?t=314 |
ページ 1 / 1 |
作成者: | NoWest [ 2005年9月09日(金) 12:30 ] |
記事の件名: | Re: Interfaceステートメントを追加!? |
引用: > ユーザーの皆様、COMの取り扱い方についてちょっとご相談。
私はC++は仮想関数では無く、純粋仮想関数を使ってインターフェイスを定義していると理解しているのですが、、、> AB4では、C++のそれと同じように、仮想関数を定義することでCOMインターフェイスを定義しています。しかし、実体を持つクラス(ここでは、メンバ変数を持つという意味)を多重継承できないなど、ちょっとした制約があることも事実です。 ActiveBasicも純粋仮想関数を導入してはどうですか? C++のインターフェイスで関数の後に=0がついているのが純粋仮想関数 コード: virtual HRESULT Hoge(DWORD dw) = 0;C++ではvirtual指定があっても、後に=0が付くか付かないかで 仮想関数か純粋仮想関数かになります。 山本様もご承知の通り、この二つは別物です。 ※もしかして、 ABの仮想関数がC++でいうところの純粋仮想関数なのでしょうか? 引用: > また、仮想関数とインターフェイスメソッドの違いなども問題になっています。コンパイラが生成する仮想関数は、オブジェクトのThisポインタがecxレジスタを介して渡されますが、インターフェイスメソッドへのインターフェイスポインタの引き渡しはスタックを介して行われます。細かい部分ですが、コーディング作法にも影響してくるところなので、ちょっと気になる点です。
OLEドロップの細かい挙動がおかしくなるのもこの影響なんですね?まぁ、詳しくは分からないので何とも言えませんが。。。 引用: Interfaceステートメントは、複数のインターフェイスの実装を可能にするつもりです。
> > あと、Classステートメントで定義される仮想関数のフリをしたインターフェイスについてですが、Interfaceステートメントを導入したら、廃止しようと思います。まぁ、クラスの仮想関数がインターフェイスとして使えなくかもしれないってことです。 > > 何かご意見、アドバイスなどありましたらご返信願います。 いろいろオブジェクト指向の周りを整備していこうとしているのであれば 追加すべき事柄がたくさんありますよ。 たとえば、現状ではインターフェイスIDをユーザが構造体変数として自力で 定義しないといけなくなっています。 ですのでCでいうところのexturnなんぞを導入して GUID型の特定の名前の変数を定義したら自動的に初期化してくれるような 機能が必要ですし、 今のようにずらずらとClass~End Class間にメンバ関数を定義していく状態だとかなり大変なことになりますよね。 これらはポリモーフィズム以前の問題です。 あとはブログにもあったようにvtableの上書きですね。 とにかく、問題が山積みだと思いますので 頑張ってください。 P.S. 他にも欲しい機能がありました。 ・クラス内にスタティックメンバを入れられるとか ・フレンドクラスとか ・関数のオーバーロード←絶対必要 これじゃきり無いな。。。 |
作成者: | イグトランス [ 2005年9月09日(金) 19:32 ] |
記事の件名: | |
私はInterfaceには賛成です。 そして、それとは別に仮想関数に対する純粋仮想関数(抽象メソッド/Abstruct, Prue, = 0など構文・用語はともかく)を将来的には用意してほしいと思っています。 (クラスの多重継承をできるようにするかどうかとは無関係に) 純粋仮想関数の用途は大きくこの2つに分類できるので用途別に構文も2つにわけた方が良い、と思っているからです。 > ・関数のオーバーロード←絶対必要 個人的には密かに型チェックの厳格化はこのための布石ではないかと思っています。 ついでに演算子の多重定義があればStringを特別扱いからただのクラスにできますね。 少なくともoperator =だけは早期に導入したほうがいいのではと思います。 話はそれますが。 > Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord riidはByRefにしませんか。Interfaceを導入するときについでにやってしまえばいいと思います。(それともByRefは使わない方針でしたっけ?) |
作成者: | 山本 [ 2005年9月10日(土) 16:06 ] |
記事の件名: | |
NoWestさん、イグトランスさん、アドバイス助かります。 引用: 私はC++は仮想関数では無く、純粋仮想関数を使ってインターフェイスを定義していると理解しているのですが、、、ActiveBasicも純粋仮想関数を導入してはどうですか?
双方を導入する予定です。構造的には、VC++と同等のものを用意したいのですが、構文のほうが悩ましいところです。単純に、インターフェイスでは純粋仮想関数のみを利用することがわかっていれば、コード: Interface IUnknown Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord Function AddRef() As DWord Function Release() As DWord End Interfaceこのような構文を下記のようにコンパイラが解釈すればよいということになります。 コード: Class IUnknown Public Pure Virtual Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord Pure Virtual AddRef() As DWord Pure Virtual Release() As DWord End Interface"Pure"が先頭に付くことで、そのメンバ関数が純粋仮想関数であることを示し、プロトタイプ宣言という扱いになります。 "Virtual"のみの場合は、実装と共に定義される仮想関数になります。 何もつかない場合は、通常のメンバ関数になります。 引用: ※もしかして、
お察しの通り、AB4で"Virtual Function"と定義されているものはすべて純粋仮想関数です。実装は定義できません。しかも、現状ではサブクラスでのオーバーライドもできていません(現状では、通常のメンバ関数のみ、オーバーライド可能となっています)。ABの仮想関数がC++でいうところの純粋仮想関数なのでしょうか? 仮想関数のオーバーライド機能はかなり重要なものになってくることは認識しておりますので、構文案がまとまり次第、実現させようと思います。 引用: たとえば、現状ではインターフェイスIDをユーザが構造体変数として自力で
こいつは、VC++で言う、"#import"に相当する機能ですよね。外部インターフェイスと連携を取るプログラムを書き場合は、絶対に必要ですね。定義しないといけなくなっています。 ですのでCでいうところのexturnなんぞを導入して GUID型の特定の名前の変数を定義したら自動的に初期化してくれるような 機能が必要ですし、 今のようにずらずらとClass~End Class間にメンバ関数を定義していく状態だとかなり大変なことになりますよね。 COMで機能を提供しているDLLの内容を読み取り、インターフェイス周りの識別子情報を取得するためのプログラムを書けば、実現できそうですが、こちらはこれから資料集めです/(--)/ 引用: ・クラス内にスタティックメンバを入れられるとか
どれも重要な要素ですので、順に追加していこうと思います。関数のオーバーロード、早めに実装できるようにしますので、今しばらくお待ちください。演算子のオーバーロードもなるべく早めに…・フレンドクラスとか ・関数のオーバーロード 引用: そして、それとは別に仮想関数に対する純粋仮想関数(抽象メソッド/Abstruct, Prue, = 0など構文・用語はともかく)を将来的には用意してほしいと思っています。
具体的には、仮想関数、純粋仮想関数の仕分けを記述できる構文("Pure"指定)を導入すると共に、Interfaceステートメントの導入を検討しています。(クラスの多重継承をできるようにするかどうかとは無関係に) 純粋仮想関数の用途は大きくこの2つに分類できるので用途別に構文も2つにわけた方が良い、と思っているからです。 Interfaceステートメントは、Classステートメントの構文仕様の関係でインターフェイス定義が冗長的にならないよう、プリプロセッサ的な働きをするものです。ようは、よりスマートにパブリックな純粋仮想関数を定義できるってことですな。 引用: Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord
ウーン、どっちが妥当なんでしょうか…。ポインタを隠そうとする昨今の言語事情を考慮すれば、「参照型」を積極的に活用していくことは非常に大きな意味を持つことになると思います。しかし、ABはシステム記述型の特性をもつ、C/C++の派生言語のような構造をしているんですよね。こうなると、ポインタベースの仕様が一番自然にはなってくるのですが…。riidはByRefにしませんか。Interfaceを導入するときについでにやってしまえばいいと思います。(それともByRefは使わない方針でしたっけ?) 私は、C/C++のような、コアな技術者向けのスマートなコーディング作法が好きですが、それと同時に生産性を向上させるようなJava/C#的なコーディング作法にも非常に関心を持ちます。 結局のところ、こういう細かいところを今後どうしていくのかは、まだ考え中といった段階です。裏づけになるいい資料、「こういうところを勉強しなよ~」といったところがありましたら、引き続き、アドバイスをいただけると助かります。 |
作成者: | Tomorrow [ 2005年9月10日(土) 22:32 ] |
記事の件名: | Re: Interfaceステートメントを追加!? |
引用: 引用: Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord
ウーン、どっちが妥当なんでしょうか…。ポインタを隠そうとする昨今の言語事情を考慮すれば、「参照型」を積極的に活用していくことは非常に大きな意味を持つことになると思います。しかし、ABはシステム記述型の特性をもつ、C/C++の派生言語のような構造をしているんですよね。こうなると、ポインタベースの仕様が一番自然にはなってくるのですが…。riidはByRefにしませんか。Interfaceを導入するときについでにやってしまえばいいと思います。(それともByRefは使わない方針でしたっけ?) C++では コード: virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void **ppvObject);というふうになりますが、ここでREFIIDは コード: #define REFIID const IID &と定義されてるので、参照渡しです。どうやら入力の引数(メソッドに渡す)は値渡しや参照渡し、出力の引数(メソッドから受け取る)はポインタ渡しとなっているみたいです。(ただし、インターフェイスへのポインタはインターフェイスポインタ型とでもいうべき独立な型として扱っている。) 引用: コード: Class IUnknown Public Pure Virtual Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord Pure Virtual Function AddRef() As DWord Pure Virtual Function Release() As DWord End Interface"Pure"が先頭に付くことで、そのメンバ関数が純粋仮想関数であることを示し、プロトタイプ宣言という扱いになります。 "Virtual"のみの場合は、実装と共に定義される仮想関数になります。 何もつかない場合は、通常のメンバ関数になります。 具体的には、仮想関数、純粋仮想関数の仕分けを記述できる構文("Pure"指定)を導入すると共に、Interfaceステートメントの導入を検討しています。 Interfaceステートメントは、Classステートメントの構文仕様の関係でインターフェイス定義が冗長的にならないよう、プリプロセッサ的な働きをするものです。ようは、よりスマートにパブリックな純粋仮想関数を定義できるってことですな。 無論、Pure Virtualの方が構文解析上都合がよい、あるいは"純粋"、"仮想"の名にふさわしいなどの理由なら、こちらの方が良いですが。(^^; Abstractだと抽象メソッドと呼んだ方が良いですね。 それから、 引用: また、仮想関数とインターフェイスメソッドの違いなども問題になっています。コンパイラが生成する仮想関数は、オブジェクトのThisポインタがecxレジスタを介して渡されますが、インターフェイスメソッドへのインターフェイスポインタの引き渡しはスタックを介して行われます。細かい部分ですが、コーディング作法にも影響してくるところなので、ちょっと気になる点です。
とのことですが、つまりCOMインターフェイスの仕様と、ABの純粋仮想関数(現在のVirtual指定)の仕様が異なるということですよね。だとするとABで実装予定のInterfaceステートメントはCOMインターフェイスとしてしか使えないのでしょうか? というのは、Javaにあるような言語仕様内で使えるポリモフィズムや多重継承を実現するためのインターフェイスがあると分かりやすいと思うからです。 引用: 引用: 私はC++は仮想関数では無く、純粋仮想関数を使ってインターフェイスを定義していると理解しているのですが、、、ActiveBasicも純粋仮想関数を導入してはどうですか?
双方を導入する予定です。構造的には、VC++と同等のものを用意したいのですが、構文のほうが悩ましいところです。 |
作成者: | イグトランス [ 2005年9月10日(土) 23:58 ] |
記事の件名: | Re: Interfaceステートメントを追加!? |
引用: 引用: Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord
> ウーン、どっちが妥当なんでしょうか…。ポインタを隠そうとする昨今の言語事情を考慮すれば、「参照型」を積極的に活用していくことは非常に大きな意味を持つことになると思います。しかし、ABはシステム記述型の特性をもつ、C/C++の派生言語のような構造をしているんですよね。こうなると、ポインタベースの仕様が一番自然にはなってくるのですが…。> riidはByRefにしませんか。Interfaceを導入するときについでにやってしまえばいいと思います。(それともByRefは使わない方針でしたっけ?) そのため呼ぶときにはVarPtr(IID_なんとか)とする必要があります。 するとこれがポインタ渡しだと実感できます。しかし、ここでポインタ渡しだと実感しても何のありがたみもありません。 本来は値渡しで十分なのですが、ポインタ・参照渡しのほうが効率が良いので使っているだけに過ぎないからです。 なので呼び出し時に値渡し同様に書ける参照渡しが良いと私は思うわけです。 引用: 引用: 引用: 私はC++は仮想関数では無く、純粋仮想関数を使ってインターフェイスを定義していると理解しているのですが、、、ActiveBasicも純粋仮想関数を導入してはどうですか?
> 双方を導入する予定です。構造的には、VC++と同等のものを用意したいのですが、構文のほうが悩ましいところです。 |
作成者: | NoWest [ 2005年9月11日(日) 12:43 ] |
記事の件名: | Re: Interfaceステートメントを追加!? |
引用: Function QueryInterface(riid As *GUID, ppvObj As DWordPtr) As DWord
密かにこのメソッドの第2引数はポインタのポインタなので値を取り出すには コード: Dim a As *IHoge a=GetDWord(ppvObj)最新のActiveBasicはどうなのか分かりませんが、、、 OLEドロップに挑戦している頃、結構これが面倒でした。 最終的にByRef指定のVoidPtrという引数していましたが。。。 引用: Absuructだと抽象メソッドと呼んだ方が良いですね。
Abstructは響きがいいですね。ただ、あまり馴染みの無い単語ではありますが、、、 話は変わりますが、、、 少し前に書き込んで未だご意見を伺っていないことがあるんですが UNICODEへの対応はどうなっているのでしょうか? |
作成者: | イグトランス [ 2005年9月13日(火) 17:55 ] |
記事の件名: | Re: Interfaceステートメントを追加!? |
引用: 引用: また、仮想関数とインターフェイスメソッドの違いなども問題になっています。コンパイラが生成する仮想関数は、オブジェクトのThisポインタがecxレジスタを介して渡されますが、インターフェイスメソッドへのインターフェイスポインタの引き渡しはスタックを介して行われます。細かい部分ですが、コーディング作法にも影響してくるところなので、ちょっと気になる点です。
とのことですが、つまりCOMインターフェイスの仕様と、ABの純粋仮想関数(現在のVirtual指定)の仕様が異なるということですよね。だとするとABで実装予定のInterfaceステートメントはCOMインターフェイスとしてしか使えないのでしょうか? というのは、Javaにあるような言語仕様内で使えるポリモフィズムや多重継承を実現するためのインターフェイスがあると分かりやすいと思うからです。 コード: Class Base Public Virtual Sub Print() Print "Hallo" End Sub End Class Interface IPrint Sub Print() End Interface Class Derived Inherits Base Implements IPrint End Class(構文は想像を交えてあります) こういう例では問題になります。しかし面倒ですが、DerivedのIPrintのPrintにはStdCall→ThisCallへ変換してBaseのPrintを呼ぶサンクを置けばいいのではないかと思いました。 #考えるだけならいくらでもできるんですけどね |
作成者: | イグトランス [ 2005年9月18日(日) 21:38 ] |
記事の件名: | オーバーライドとオーバーロード |
引用: 5. 関数のオーバーロードが可能
AB Ver4.2で実施するポリモフィズム対策のページにこのような文章がありますが、これではオーバーライドとオーバーロードを混同して書かれてしまっているように思ってしまいます。パラメータ特性が異なれば、同じ名前の関数(またはメソッド)を複数定義できるようになります。関数呼び出し側は、指定されたパラメータの特性を判断し、適切な関数を呼び出します。 関数をオーバーライドするときは、2つ目以降の関数の定義文にOverride修飾子を付けなければなりません。Override修飾子をつけずに、重複した関数名を定義しようとするとエラーになります(この仕様はミスを防ぐためのものです)。 Override識別子は抽象メソッドのところで扱っているので重複していますよね。 それともまさかOverloadなんて導入するのでしょうか? |
作成者: | 山本 [ 2005年9月19日(月) 21:22 ] |
記事の件名: | |
まず、パラメータの参照方法についてですが、参照型(ByRef)が妥当な箇所は、ポインタ型を経由せずに素直にByRef扱いにしてやったほうがよさそうですね。メジャーバージョンアップでタイミングを見計らってライブラリを整理する必要がありそうです。 引用: 少し前に書き込んで未だご意見を伺っていないことがあるんですが
対応できなくて申し訳ありませんでしたm(__)mUNICODEへの対応はどうなっているのでしょうか? UNICODE、早めに対応したいです。知識不足ながら、UNICODEへの対応方法を勉強中です。下記のような手順でいけるんでしょうか?? 1. リテラル文字列を内部でUNICODEとして扱う。 2. 文字列関連の標準関数、及びAPI関数をUNICODE対応のものへと書き換える。 1番目の事項は一時間で終わるのでいいとして、問題は2番目ですね。ASCIIとは別に、新たにライブラリを用意しなければなりません。NameSpaceあたりを取り入れて、うまくやりくりすれば案外とキレイにUNICODEライブラリを追加できるかもしれません…。 引用: AB Ver4.2で実施するポリモフィズム対策のページにこのような文章がありますが、これではオーバーライドとオーバーロードを混同して書かれてしまっているように思ってしまいます。
そうですそうですf(^^;;;。通常の関数(クラスに属さない関数)のオーバーロード時にOverride修飾子を使えというのは、矛盾しておりますね。Override識別子は抽象メソッドのところで扱っているので重複していますよね。 修飾子が必要だという旨の文をページ内容から削除しておきました。 |
作成者: | イグトランス [ 2005年9月19日(月) 22:35 ] |
記事の件名: | |
引用: まず、パラメータの参照方法についてですが、参照型(ByRef)が妥当な箇所は、ポインタ型を経由せずに素直にByRef扱いにしてやったほうがよさそうですね。
ありがとうございます。こういう風になってほしかったのです。引用: 少し前に書き込んで未だご意見を伺っていないことがあるんですが
ええと、これはNoWestさんが書かれたものですね。たしかに私もUnicodeサポートは将来的には必要と思っていますが。UNICODEへの対応はどうなっているのでしょうか? 引用: 2. 文字列関連の標準関数、及びAPI関数をUNICODE対応のものへと書き換える。
VC++ではTCHARなどを使って単一ソースでマルチバイト/Unicode両対応のコードを書けるようにしていますよね。どうやって実現するのかはともかくとしてABも単一ソースで両対応ということになるのでしょうか? それとも原則、全ての文字をUnicodeとして扱うことになるのでしょうか? Overrideの件 ありがとうございます。たしかに直っていました。 |
作成者: | 高信期 [ 2005年9月23日(金) 00:49 ] |
記事の件名: | |
「関数のオーバーロードが可能」にあるパラメータ特性ですが、 これはBytePtrやWordPtrのようなポインタの種類も区別されるのでしょうか? 個人的にはちゃんと区別されてほしいですね。 |
作成者: | 山本 [ 2005年9月23日(金) 02:15 ] |
記事の件名: | |
引用: 「関数のオーバーロードが可能」にあるパラメータ特性ですが、
内部的に厳密な型チェックが可能となっておりますので、関数のオーバーロードを実現する際は、ポインタの種別も認識できるようにする予定です。これはBytePtrやWordPtrのようなポインタの種類も区別されるのでしょうか? 個人的にはちゃんと区別されてほしいですね。 P.S. は~、またこんな時間まで起きていてしまった… |
作成者: | Tomorrow [ 2005年9月26日(月) 00:35 ] |
記事の件名: | インターフェイスの定義について |
Ver4.2のポリモフィズム対策、拝見しました。かなりJavaに近い構文みたいで、見やすくて良いですね。 単なる誤植の指摘みたいで申し訳ないですが.. 「4. インターフェイスの定義が可能」のところで 引用: ×:他は抽象メソッドと同じようなものです。例えば、下記の定義は同等です。
ではないでしょうか?↓ ○:他は抽象クラスと同じようなものです。例えば、下記の定義は同等です。 また、 引用: 多重継承(複数インターフェイスの実装)が可能。
とありますが、インターフェイスの実装にはJava風にImplementsキーワードとか導入するのでしょうか?それともC系言語のように(ちょっと語弊がある..)Inheritsで共用するのですか? |
作成者: | 山本 [ 2005年9月27日(火) 02:53 ] |
記事の件名: | |
引用: 「4. インターフェイスの定義が可能」のところで
Tomorrowさんのご指摘通り、「抽象クラス」が正しい表現でした。早速修正しておきましたので、ご確認ください。引用: ×:他は抽象メソッドと同じようなものです。例えば、下記の定義は同等です。
ではないでしょうか?↓ ○:他は抽象クラスと同じようなものです。例えば、下記の定義は同等です。 引用: 引用: 多重継承(複数インターフェイスの実装)が可能。
とありますが、インターフェイスの実装にはJava風にImplementsキーワードとか導入するのでしょうか?それともC系言語のように(ちょっと語弊がある..)Inheritsで共用するのですか? |
ページ 1 / 1 | 全ての表示時間は UTC+09:00 です |
Powered by phpBB® Forum Software © phpBB Limited https://www.phpbb.com/ |