CreateThreadについて

[NoWest]

先ほどSourceForgeにて、
CreateThread関数を

コード: 全て選択

Declare Function CreateThread Lib "kernel32" Alias "CreateThread" (
	ByRef lpThreadAttributes As SECURITY_ATTRIBUTES,
	dwStackSize As DWord,
	lpStartAddress As LPTHREAD_START_ROUTINE,
	lpParameter As VoidPtr,
	dwCreationFlags As DWord,
	lpThreadId As DWordPtr
	) As HANDLE

から

コード: 全て選択

Declare Function CreateThread Lib "kernel32" Alias "CreateThread" (
	lpThreadAttributes As *SECURITY_ATTRIBUTES,
	dwStackSize As DWord,
	lpStartAddress As LPTHREAD_START_ROUTINE,
	lpParameter As VoidPtr,
	dwCreationFlags As DWord,
	ByRef lpThreadId As DWord
	) As HANDLE

に変更してきました。

これまでのプログラムとは互換性が無くなり、多少問題が発生するかもしれませんが、
そもそもlpThreadAttributesにはNULL以外渡すことが無いのと、
lpThreadIdはNULLで省略することができないという点から見て
これまでよりスレッドの作成が簡単になると判断しました。

何かご意見あれば返信ください。

※この変更は次回のABのバージョンアップで有効になりますので現時点で修正は可能です。

[ゲスト]

それはつまりver5以降のActiveBasicはver4以前のコードとの上位互換性を破棄するという開発者サイドの暗黙的な意思表明とうけとめてよろしいか。

[Na]

>それはつまりver5以降のActiveBasicはver4以前のコードとの上位互換性を破棄するという開発者サイドの暗黙的な意思表明とうけとめてよろしいか。

これまでのプログラムとは互換性が無くなり、多少問題が発生するかもしれませんが、
そもそもlpThreadAttributesにはNULL以外渡すことが無いのと、
lpThreadIdはNULLで省略することができないという点から見て
これまでよりスレッドの作成が簡単になると判断しました。

と、互換性と変更理由について書かれています。

[NoWest]

それはつまりver5以降のActiveBasicはver4以前のコードとの上位互換性を破棄するという開発者サイドの暗黙的な意思表明とうけとめてよろしいか。

少し補足します。

互換性の面で「多少問題」があるというのは
スレッドの機能を一体どれだけの人が使用しているのかという点と、
沢山いるなら変更できませんが、一般的なプログラミングでスレッドを
多用することはありませんし、そもそも使用しないだろうという点につきます。

スレッドを使ったことがある方なら気付いていると思いますが、
lpThreadAttributesパラメータは現在のABの定義では
ByRef指定になっています。
これではByVal NULLという回りくどい指定が必要となります。
また、lpThreadId パラメータはNULLを渡して
値を省略してはいけない仕様になっているため
態々スレッドを作成するためにVarPtr(idThread)のように
アドレスを渡す必要がなくなります。

コード: 全て選択

Dim Id As DWord
CreateThread(ByVal NULL, 0, AddressOf(Thread), NULL, 0, VarPtr(Id))

コード: 全て選択

Dim Id As DWord
CreateThread(NULL, 0, AddressOf(Thread), NULL, 0, Id)

ゲストさんの仰るように「互換性」も大事ですが、
私は上と下を比べた時、下の方が効率的なコーディングができると思いますし、
初心者にも分かり易いと思うのですが如何でしょう？

[xsb7]

Byrefには、そもそも定数は渡せないので、ByrefにNULLが渡されたら、自動的にByval NULLと認識させることはできないのでしょうか。

[konisi]

山本さんがコンパイラのソースコードにちょっと手を加えれば可能になるとは思いますが、コードの記述ミスが多くなるような気がします。

[イグトランス]

同様の変更はほかにもCoCreateInstanceなどで行っています。
これによって起こる非互換は，Declareで宣言した関数も通常の関数同様多重定義できるようになれば解決できるのに……，と私は思っています。
つまりByVal版とByRef版で多重定義するわけです。
ByRef引数にNULLを渡せるようにすることとあまり変わりはしませんが，それより汎用的な機能だと思います。

この方式ではCreateFileなど多用されている関数でもByRef/ByValの変更を適用することができるという利点があります。
私は，Declareの関数が多重定義できないのはバグと思っています。（バグ報告へは書いていませんが）

もっともそれが実現したとしても，今のABではオーバーロードの解決が曖昧ですというエラーの嵐になりそうな気がしなくもありませんが。