現在Windows用某製品のプラグインを開発しています。
そのプラグインはC言語ベースで開発されており、SDKのマニュアルには、マルチスレッドには対応していない旨書かれています。
ここで質問なのですが、MFCのシングルスレッド用スタティックライブラリというのは存在するのでしょうか?やはりシングルスレッドではMFCを諦めるしかないのでしょうか、、
ご存知のかたぜひご教示ください。

このQ&Aに関連する最新のQ&A

A 回答 (4件)

>>そんな事はありません。



MFCはマルチスレッドを想定していますよ。スレッド毎にメッセージマップのインスタンスを持ちます。今も昔も変わりません。
もしかして、GOOD-Frの飼い犬かね?

MFCはマルチスレッドを想定しているので、シングルスレッド、マルチスレッドの両方のライブラリがあったこの時代でも、リンクするライブラリは常にマルチスレッド用のものです。
ちなみに、現代のVisualC++には、シングルスレッド用ライブラリが存在しません。

アプリケーションのメインウィンドウはプライマリスレッドで動作します。
明示的にサブスレッドを作成しない限り、スレッドの数は常に1個です。
関数呼び出しの際に排他制御の必要はありません。
    • good
    • 0

>MFCはもともとマルチスレッドを想定してつくられている



そんな事はありません。MFCで作られた、プログラムでも明示的にスレッドを起こさない限り主スレッドで動きます。

新規にMFCプロジェクトで実行ファイルを作って起動させ、タスクマネージャでスレッドの数を確認すれば一つしかない事がすぐにわかります。
    • good
    • 0

>たしかCWinAppなどを使うと初回時にスレッドを一本立ててアプリは最低でも


>その下で動くようになる、、など、気付かないところでスレッドをたてられて
>しまうので、マルチスレッドバージョンのMFCは使えないのではないかという
>気がしています

これってCWinAppを使用すると内部でメインスレッド以外にワーカースレッドを
作成してしまうって事ですか?

ちなみにプラグインというのはDLLみたいな形で作成するのでしょうか?

この回答への補足

すみません、、補足を書いたのですが正常に書き込まれていませんでした。

>これってCWinAppを使用すると内部でメインスレッド以外にワーカースレッドを
>作成してしまうって事ですか?

詳しくは覚えていないのですが、CWinAppでRunを実行するとスレッドが一本走り、
それ以降の処理はそこで行われますよね。それを言いたかったのです。本来Windowsアプリはスレッドが1本もなくても動くものですから、、(もしくは最近のWindowsだと起動時のプロセスもスレッド扱いとなっているのかな、、?シングルスレッドと呼ばれるだけに。そこまではちょっとわかりません。もしくは理解を誤っているようでしたらすみません、、)
つまりMFCはもともとマルチスレッドを想定してつくられているので、MFCクラスを使用すると裏でスレッドが走るケースがあるのではないかということです、、

>ちなみにプラグインというのはDLLみたいな形で作成するのでしょうか?

説明不足で申し訳ありません。たしかにおっしゃる通りDLLで作成します。

補足日時:2002/01/22 14:24
    • good
    • 0

MFCをどのように使用するのか分からないので何ともいえませんが


基本的にプラグイン側からMFCをシングルスレッドで(関数等を)使用すると
いうのであれば特に問題はないのではないでしょうか。
逆にMFCでの処理をマルチスレッドで書いていて非同期に製品側にアクセスする
(多分ないと思いますが..)場合には排他制御等のしかけが必要と思います。

この回答への補足

ご回答ありがとうございます。
MFCはアプリケーションを利用する際にしか用いたことがないのであれなのですが、、
やはりライブラリはマルチスレッドバージョンしか用意されていないようなのでコンパイラオプションはマルチスレッドにするしかないのでしょうね、、
たしかCWinAppなどを使うと初回時にスレッドを一本立ててアプリは最低でもその下で動くようになる、、など、気付かないところでスレッドをたてられてしまうので、マルチスレッドバージョンのMFCは使えないのではないかという気がしています。

補足日時:2002/01/22 10:49
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QC++言語のプラグインについて。 現在、開発しているプログラムにプラグインを読み込むシステムを追加し

C++言語のプラグインについて。

現在、開発しているプログラムにプラグインを読み込むシステムを追加したいと考えているのですが、ネットで "プラグイン"などのキーワードで検索しても、公開されている既存のプログラムのプラグインに関することがほとんどで、あったとしても手掛かりがつかめない状態です。

自分のプログラムにプラグインを読み込むシステムを導入したい場合、どんなことを勉強したらいいのでしょうか。取っ掛かりとなるキーワードだけでも教えて欲しいのですが...。

Aベストアンサー

案1. 動的ライブラリとして実装し、動的リンクで呼び出す
参考)
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/dlsym.3.html
https://msdn.microsoft.com/ja-jp/library/cc429241.aspx

案2. ECMAScript などのスクリプトとして実装し、実行エンジンを使って動かす
参考)
https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
https://ja.wikipedia.org/wiki/Google_V8_JavaScript_Engine

案3. プラグイン専用の言語を定め、その言語のテキストを動的に実行するプログラムを実装する
参考)
https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E5%9B%BA%E6%9C%89%E8%A8%80%E8%AA%9E
https://ja.wikipedia.org/wiki/NScripter

案1. 動的ライブラリとして実装し、動的リンクで呼び出す
参考)
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/dlsym.3.html
https://msdn.microsoft.com/ja-jp/library/cc429241.aspx

案2. ECMAScript などのスクリプトとして実装し、実行エンジンを使って動かす
参考)
https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
https://ja.wikipedia.org/wiki/Google_V8_JavaScript_Engine

案3. プラグイン専用の言語を定め、その言語のテキストを動的に実行するプログラムを実装する
参考)
https://ja....続きを読む

Q「MFCを使用しない」から「MFCのスタティックライブラリを使用」

VC++初心者ですが、

Win32Applicationで「MFCを使用しない」で作成したプログラムが正常動作しました。 そこで
「MFCを使用しない」から「MFCのスタティックライブラリを使用」にしてビルドしたところ、リンク中に
どんどんエラーがでます。 関数関係のエラーなのですが。

(1) どうすればエラーを無くせるのでしょうか
(2) 「MFCのスタティックライブラリを使用」にするとどの様なメリットがあるのか(説明している参考URLなど)。

教えて下さい

Aベストアンサー

>(1) どうすればエラーを無くせるのでしょうか

プロジェクトを作り直すのが手っ取り早いです。ソースを修正したり、プロジェクトのリンク対処のライブラリを変更したりすれば何とかできることはできますがおすすめしません。

作り直したプロジェクトに、自分が追加ソースをコピペしていけばちゃんと動くと思います。(ウィザードが自動で追加した分も含む)

>(2) 「MFCのスタティックライブラリを使用」にするとどの様なメリットがあるのか(説明している参考URLなど)。

簡単に書くと、

メリット
・使用しない
実行ファイルサイズが小さくなる。

・使用する
実行するときにMFCのランタイムDLLが不要になる。


デメリット
・使用しない
MFCのDLLに依存するので、DLLのバージョンの違いで動作に不具合が出る可能性がある。

・使用する
実行ファイルのサイズが馬鹿でかくなる。

QSDKやMFCでの開発について

私はサンデープログラマなので趣味でSDKなどで簡単なプログラミングをしています。MFCにも挑戦しようかと思っているところなのですが、いかんせんVisualと名前がついているのにSDKもMFCもぜんぜんVisualではありませんので開発にかなり時間がかかってしまいます。ダイアログベースでのプログラミングがあるかとは思いますが、コントロールのインターフェースの制御などに制限があるように思えます。
●やはりソフトハウスなどでは画面(ウィンドウ)を作るとき、
コントロールの位置など直接確認できないので、
その専門の人(画面を作る人たち)がいて、
コントロールの位置を設定して(CreateWidnow関数などのTop,Left引数の位置に座標を設定して)
いちいちその度にビルドをし、コントロールの位置を確認して画面を制作しているのでしょうか?
●また、私はC#に興味があります。それはなぜかというと、SDKや特にMFCに比べて、やはりVBのように画面を作りやすくするため、VBのようなデザイン画面を取り入れたり、XMLなどを操作できるようにしたり、MFCのようにオブジェクト指向でWindowsの性能を最大限に引き出すことができる(まとまった一連の動作はオブジェクトで実行し、単機能の動作は直接APIにアクセスし実行することができる)VBとMFCとJAVAのいいところをすべて網羅した言語のように思えます。この認識は正しいのでしょうか?

私はサンデープログラマなので趣味でSDKなどで簡単なプログラミングをしています。MFCにも挑戦しようかと思っているところなのですが、いかんせんVisualと名前がついているのにSDKもMFCもぜんぜんVisualではありませんので開発にかなり時間がかかってしまいます。ダイアログベースでのプログラミングがあるかとは思いますが、コントロールのインターフェースの制御などに制限があるように思えます。
●やはりソフトハウスなどでは画面(ウィンドウ)を作るとき、
コントロールの位置など直接確認できないので、
...続きを読む

Aベストアンサー

○画面の作成の仕方
ユーティリティ系のものでは、HTMLで作るものもありますし、ホビー系のものは、ボタンのON/OFFまですべて自前で描画することもあります。
基本的には仕様書を作って、デザイナーも開発者もそれに添って開発するのが基本です。が、実際はビルドを繰り返してトライ&エラーで調整することも多いです。

サンデープログラマのいいところは、自分の気のままに適当に作って、後で納得いくまで直せるところではないでしょうか。
仕事でやるときは、作業量を見積もり、その見積もりに添ったスケジュールで行う必要があります。
ただ、最近のソフトの開発は、開発→レビュー→見直しを何度も繰り返しながら、スパイラルアップする手法の方が、仕様書作りに追われずにすむということで、トレンドになっているようです。
興味がありましたら、「エクストリーム・プログラミング」とか、「アジャイル開発」とかで調べて見てください。

○C#について
おっしゃっているC#の特性を見るかぎり、VisualStudio.net で、C#.netの開発をするということですよね?

その場合、利点も欠点も、JAVA+VBだと思って下さい。
JAVAのアプリを動かすのに、JAVA VM が必要なのと全く同じように、C#.netのプログラムを実行するには、.net framework というものをインストールする必要があります。

利点はおわかりのようなので、欠点を。
・Cでコンパイルしたプログラムより遅い。
 C#.net は、JAVAと同じく中間コードを .NET FrameWork というインタプリタで実行します。
速度がさほど気にならないものならOKです。
・.NET FrameWorkがインストールされている必要がある。
 Windowsなら、WindowsUpdateで勝手に入りますが、それでもインストールが必要であることには変わりないです。
・コードが逆生成できる。
 中間コードをツールにかけると、なんとソースが出てくるそうです。(コメントはつきませんが・・・)
 個人のコードなら問題ないと思いますが、業務用だともしかしたら問題になるかもしれません。


上の3つは微妙に関係していますね。
なにかの本で読みましたが、VB.NetとC#.netを比べた場合、VBを選ぶ理由はないとのことです。

○画面の作成の仕方
ユーティリティ系のものでは、HTMLで作るものもありますし、ホビー系のものは、ボタンのON/OFFまですべて自前で描画することもあります。
基本的には仕様書を作って、デザイナーも開発者もそれに添って開発するのが基本です。が、実際はビルドを繰り返してトライ&エラーで調整することも多いです。

サンデープログラマのいいところは、自分の気のままに適当に作って、後で納得いくまで直せるところではないでしょうか。
仕事でやるときは、作業量を見積もり、その見積もりに添ったスケジ...続きを読む

QSusieプラグインのスタティックリンク

ウィンドウズアプリのソース
winapp.cpp
とSusieプラグイン
susie.spi
をスタティックリンクして実行ファイル
winapp.exe
を作ることはできるのでしょうか?

Aベストアンサー

Susieプラグインの正体は DLL(ダイナミックリンクライブラリ) です
(拡張子は".spi"に変更されていますがDLLです)。
ということですので、スタティックリンクは無理かと...
http://www.asahi-net.or.jp/~kh4s-smz/spi/make_spi.html

参考URL:http://www.asahi-net.or.jp/~kh4s-smz/spi/make_spi.html

QMFCマルチスレッドについて

MFCマルチスレッドについて
COMやIOボードからの入力に応じて動作するアプリを作っています。
AfxBeginThreadにてそれぞれワーカスレッドを作成しCOMやIOから入力があれば
AfxBeginThreadを呼んでいるクラスにあるメンバ関数を実行しようとしています。
AfxBeginThreadにて*thisを送り、制御関数内で、mycls->OnButton***()というような
感じで現在は作っています。(OnButton***になっているのはデバッグ用にボタンで
あらかじめ作成している関数のためです。)
このときに、mycls->OnButton***()は親スレッドで動いていると考えていいのですか?
あくまで親スレッドのクラスのメンバ関数を制御関数が動いている子スレッドで実行
しているだけなのでしょうか?
実は、ログ表示のため制御関数の中(受信データを表示)と、mycls->OnButton***()の中
(作業結果を表示)に同じエディットコントロールへの表示部分があります。
表示部分の処理は、いったんCStringで読み込んできて最大文字数チェックを行い、
再度文字数を調節して書き直しということをやっているため、一応クリティカル
セクションにはしているのですが、実際どう動いているか分からないため、やり忘れ
ていることや、やってはいけないことをやってそうです。
すいませんがご教授願います。

MFCマルチスレッドについて
COMやIOボードからの入力に応じて動作するアプリを作っています。
AfxBeginThreadにてそれぞれワーカスレッドを作成しCOMやIOから入力があれば
AfxBeginThreadを呼んでいるクラスにあるメンバ関数を実行しようとしています。
AfxBeginThreadにて*thisを送り、制御関数内で、mycls->OnButton***()というような
感じで現在は作っています。(OnButton***になっているのはデバッグ用にボタンで
あらかじめ作成している関数のためです。)
このときに、mycls->OnButton***()は親スレッドで動...続きを読む

Aベストアンサー

>AfxBeginThreadにて*thisを送り、制御関数内で、mycls->OnButton***()というような
感じで現在は作っています。

この方法なら、
「親スレッドのクラスのメンバ関数を制御関数が動いている子スレッドで実行しているだけ」
になります。

ここで問題になりそうなのは、
1.同じ関数を別々のスレッドが実行することになるので、同期処理が必要になるかもしれない。
2.親スレッドがウィンドウプロシ-ジャを実行している場合、子スレッドからは親スレッド所有のウィンドウ操作を行うことはできない。

1に関してはクリティカルセクションで保護しているようなのでよさそうですが、2に関しては、親スレッドがウィンドウを所有している上に再度表示をしなおすということなので、問題になるかもしれません。

表示に関わるコードがある場合は、その部分をメッセージハンドラとして実装し、子スレッドから#1さんが挙げているSendMessage、PostMessageなどを利用して親スレッドに実行させる方がよいかと思います。


人気Q&Aランキング

おすすめ情報