トップページ⇒tech
971コメント269KB

managed C++ やろうぜ！！

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
C#関連のスレは山ほどあるが
managedC++のスレが無いじゃないか。
折角.NETに生き残ったC++、みんなで語ろうぜ。
0797デフォルトの名無しさん2005/06/05(日) 21:09:41
.exeの位置最優先じゃないよ
まったくこれだからカスどもは
0798デフォルトの名無しさん2005/06/05(日) 21:17:40
なんかキレてるｗ
0799デフォルトの名無しさん2005/06/12(日) 14:56:07
C++/CLIですがref value なクラスは定義部だけでなく実装のコードも含めて
すべて *.h に書くのが普通なのでしょうか？
（そもそも定義部と実装コードは分けられないようですが）
VS2005を使うと*.hにコードがあり、#includeだけの*.cppが生成されます。
全部*.cppに書いても問題ないような気がしますがどうなのでしょうか。
0800デフォルトの名無しさん2005/06/12(日) 16:25:02
編集んときに楽じゃん
事情がない限りは.hに書いたほうがいいんじゃね？
0801デフォルトの名無しさん2005/06/12(日) 17:22:05
全部*.cppに書いても問題ない
0802デフォルトの名無しさん2005/06/13(月) 00:51:54
インライン指定にチェック入れない限り、普通に分離して作成されるけど？
0803デフォルトの名無しさん2005/06/13(月) 08:19:04
んなことたずねてないと思うけど。
08047992005/06/13(月) 15:36:41
＞ （そもそも定義部と実装コードは分けられないようですが）
の部分は誤りでした。実装コード側に定義部と同じnamespaceをつけるのを忘れて
エラーが出ていました。C++クラスのテンプレートから作成した場合 802さんの
おっしゃるとおりインラインかどうかを選択できました。
普通のC++のクラスでインラインを多用するとロードモジュールのサイズが
肥大化するので心配していたのですが、Managedクラスの場合はそういう問題は
起きないようで、インラインか否かは表記上の問題で生成されるロードモジュール
に違いはでないようです。
0805デフォルトの名無しさん2005/06/19(日) 00:42:35
C++/CLI めちゃくちゃ違和感ある。
0806デフォルトの名無しさん2005/06/19(日) 01:03:09
みんななんて呼んでるの？
しーぷらぷらしーえるあい？
0807デフォルトの名無しさん2005/06/19(日) 15:01:23
しーしり
0808デフォルトの名無しさん2005/06/19(日) 15:33:53
しぷぷすくり
0809デフォルトの名無しさん2005/06/21(火) 21:56:27
日本語訳も次々と来てるね

C++: .NET Framework プログラミング最良の言語
http://www.microsoft.com/japan/msdn/vs05/visualc/VS05Cplus.asp

STL.NET 入門
http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp
0810デフォルトの名無しさん2005/06/22(水) 08:59:31
日本語訳でて来たね。これも重要だ。

変換ガイド: Managed Extensions for C++ から C++/CLI へのプログラムの移行
Stanley B. Lippman
http://www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp
0811デフォルトの名無しさん2005/06/22(水) 16:32:33
>>810
何か後半中部の訳が変じゃない？(前半部と最後は良かったんだが...

>難解で洗練されていない構文を使用すると、開発プロセスにおける危険性が増大します。これは、フロントガラスの汚れや煙が自動車事故の危険性を高めるのと同じです。改訂されたデザインでは、磨き上げられた新品のフロントガラス並みに構文の透明性が向上しています。
ﾜﾛﾀ
>構文糖
>??
>const char* インスタンスに解決されていた解決が、あいまいとしてフラグされるようになりました。
>コンパイル時間ダウンキャスト
0812デフォルトの名無しさん2005/06/24(金) 23:51:57
＞構文糖
シンタックスシュガー
0813デフォルトの名無しさん2005/06/25(土) 02:22:06
んなこたわかってるよ
0814デフォルトの名無しさん2005/06/25(土) 02:27:14
managed C++って業務で使ったことある人いる？
うち何件か企画はあったんだけど検討の結果全部C#になりました。
0815デフォルトの名無しさん2005/06/25(土) 02:31:00
ライブラリとしてC#への接合部にMC++使ったよ
メインとしてはとても使えないけど、旧来のルーチンをラップするにはベターな選択だ
0816デフォルトの名無しさん2005/06/25(土) 15:11:05
C++/CLIの方に移るからね。managed C++は消えるでしょ。
0817デフォルトの名無しさん2005/06/25(土) 19:54:45
名前はmanaged C++のほうがかっこいいよね
0818デフォルトの名無しさん2005/06/27(月) 13:05:03
C++がCLIになっても、標準ライブラリィとかはどうなんだろう？
0819デフォルトの名無しさん2005/06/27(月) 17:48:00
ネイティブに対しては変わらない。C++/CLI は特徴として、CLI 拡張を使わない限り
標準C++と変わらない
今までの STL はネイティブに対しては今まで通り使えるし、ref 型とかは STL.NETが
用意される
0820デフォルトの名無しさん2005/06/28(火) 23:23:47
>>819
Boostは使えるん？
0821デフォルトの名無しさん2005/06/28(火) 23:33:40
>820
spilit でパーサ使ってるが？

アセンブリという概念が組み込まれてるので、テンプレートはちょっと実用範囲が低下するが
アセンブリ内なら普通に使える
ヘッダ取り込みなんて無様な真似はアセンブリ内で閉じておけと
0822デフォルトの名無しさん2005/06/28(火) 23:34:25
あ・・・、spilit -> spirit ね
0823デフォルトの名無しさん2005/06/29(水) 12:29:16
ref クラス内で ::EnumWindows() を使っており、
LPARAM に this ポインタを渡したいのですが、方法がわかりません。

こういうことはできない、またはすべきでなかったりするのでしょうか？
0824デフォルトの名無しさん2005/06/30(木) 00:03:34
pin_ptr<LPARAM> current = this;
EnumWindows(&func, current);
で駄目なん？
0825デフォルトの名無しさん2005/06/30(木) 01:09:37
レスありがとうございます。でもコンパイル通らなかったです

ref class A {
　void Enum() {
　　pin_ptr<A^> pinnedThis = &((A^)this);
　　EnumWindows(func, (LPARAM)pinnedThis);
　}
};

これなら通りました、ただちゃんと動いているのかは、まだ見てないのですけど・・・
しかし、

ref class A {
　static BOOL Enum(HWND h, LPARAM lp) {
　　A* a = reinterpret_cast<A*>(lp); // <- 結局これができないので、
　　return 1;
　}
};

どうしたものか、というところです
this を渡しているのは、結局 HWND を自分に渡したいからで、
その辺を LPARAM に頼らない形で作ったほうがいいのかな、とも思っています
と言っても static メンバを使うとかしか思いつかないのですけど、、、
0826デフォルトの名無しさん2005/06/30(木) 01:31:52
えっと、

A* a = reinterpret_cast<A*>(lp); を

A^ a = interior_ptr<A>(lp);
では？

まぁ、ネイティブのワーククラス作った方が簡単だと思うんだけど
0827デフォルトの名無しさん2005/06/30(木) 01:32:57
ごめ。間違えた
interior_ptr<A> a = lp;
だね
0828デフォルトの名無しさん2005/06/30(木) 15:23:58
自己レス、できました

interior_ptr じゃないですけど、

GCHandle gch = GCHandle::Alloc(this);
::EnumWindows(enumProc,
　　reinterpret_cast<LPARAM>(GCHandle::ToIntPtr(gch).ToPointer()));
gch.Free();

コールバック先で

A^ This = safe_cast<A^>(GCHandle::FromIntPtr(IntPtr(lp)).Target);
This->hoge(hWnd);

GCHandle なんてはじめて知りました。
0829デフォルトの名無しさん2005/07/11(月) 10:17:57
質問です
ref class 内で、windows.h などにある unmanaged の構造体を
メンバにしようとすると、コンパイルエラーになってしまいますが
こういうときは ref なしの class を作ってやるしかないのでしょうか
0830デフォルトの名無しさん2005/07/11(月) 16:13:57
イベント呼び出しがC#からはうまくいくのにC++からだと失敗するのはなぜ？
こんな感じのユーザコントロール作って、C#からFireEvent()呼ぶと正常。
COMでイベントが発生するとCEvents::OnEvent()が呼ばれる。ここまではOK
で、そこからFireEvent()呼ぶとCOMEvent::OnEvent()呼び出しで
System.ArgumentNullException : 値を Null にすることはできません。
VSでみるとCOMEvent::OnEvent()が<未定義の値>になってる

public __gc class COMEvent:UserControl{
public:
　　__delegate void EventDelegate();
　　__event EventDelegate* OnEvent;
　　void FireEvent(){
　　　　OnEvent();
　　}
};

class CEvents:
　　public IDispatchImpl<IEvents,&IID_Events,&LIBID>,
　　public CComObjectRoot
{
　　BEGIN_COM_MAP(CEvents)
　　　　COM_INTERFACE_ENTRY(IEvents)
　　END_COM_MAP()
public:
　　gcroot<COMEvent*> m_control;

　　void STDMETHODCALLTYPE OnEvent(){
　　　　m_control->FireEvent();
　　}
};
0831デフォルトの名無しさん2005/07/11(月) 18:34:44
>829
ポインタを使えばいけるんじゃないかな？
C++/CLI使ってないから見当はずれかもしれないけど
0832デフォルトの名無しさん2005/07/11(月) 18:51:33
だったら答えるなよ
0833デフォルトの名無しさん2005/07/11(月) 19:10:44
> だったら答えるなよ
> だったら答えるなよ
> だったら答えるなよ
> だったら答えるなよ
0834デフォルトの名無しさん2005/07/11(月) 19:30:47
>829
その通りです。そういったクラスは混合型と呼ばれ、将来拡張予定の機能です。
それまでは、別に管理クラスを作るか >831 の言う通り、IntPtrに new して
持たせてください
0835デフォルトの名無しさん2005/07/11(月) 19:44:01
>830
gcroot<COMEvent*> m_control が null 値なんじゃね？
いつ作ってんの？
08368292005/07/11(月) 20:02:18
>>831
>>834
回答ありがとうございます
IntPtr 使って実装することにしました
0837デフォルトの名無しさん2005/07/11(月) 20:35:18
>830
>835 は間違えた。忘れてくり。
EventDelegate * の OnEvent はどこで生成してるの？
0838デフォルトの名無しさん2005/07/11(月) 20:37:37
>836
追加ですが、.Net Framework 2.0 では IntPtr に加えてリファレンスカウンタなどの Ptr 型が
増えているので、それらを利用するのも手だと思われます
System::Marshal 周りを探してみてください
08398502005/07/12(火) 01:53:55
>837
このUserControlを使うC#コードで生成してます
inst.OnEvent+=new EventDelegate(hoge);
inst.FireEvent();
と書いてみるとここではちゃんと動くんですよね
その後に発生するCOMイベントから
CEvents::OnEvent()経由でFireEvent()がよばれて、そこだとうまくいかないんです

今ソースないので試せませんが純粋仮想関数でも似た結果だったような
0840デフォルトの名無しさん2005/07/12(火) 10:58:35
>839
となると、やっぱり、m_control に値が入っていないような気がするんだけど、これって
どの段階で生成されるオブジェクトなの？
gcroot は非マネージド・オブジェクトがマネージド・オブジェクトを保持するエリアだよね
だから、どこかで COMEvent のインスタンスが渡されていないといけないんだけど
08418502005/07/12(火) 13:21:34
出来ました…
たしかにm_controlに値を入れるメソッドを作るのは後回しにしたままでした

m_controlに値が入ってなければm_control->FireEvent();
の時点で失敗するだろうという思い込みが原因でした

ありがとうございました
0842デフォルトの名無しさん2005/08/18(木) 21:41:58
C++/CLI の STL をいじってるんだけど、
vector<string^>^ a(gcnew vector<string^>^);
微妙な顔文字に見えてきて、微妙。
0843デフォルトの名無しさん2005/08/19(金) 00:23:03
やめろｗ
そういわれたら顔文字にしか見えなくなってきたじゃないか
0844デフォルトの名無しさん2005/08/20(土) 12:50:33
Managed C++ってヘッダーに全部実装書くのが普通なの？
0845デフォルトの名無しさん2005/08/20(土) 23:57:27
C++はメソッドのとかまだなんとついていけたけどC++/CLIとかBoost
入れるとややこしいのが出てくるとついていけない様な感じがして
これから先のC++の印象が…。C#に逃げてしまいそう。
なんかいいH.P.ありませんか？
0846デフォルトの名無しさん2005/08/21(日) 00:37:53
C#でいいじゃん。
ジェネリクスと無名関数オブジェクトがついた以上
C++をあえて使う意味は無くなったよ。
0847デフォルトの名無しさん2005/08/22(月) 13:06:05
>あえて使う意味は無くなったよ。

C++よりもマイナーＣ丼にふさわしい形容。
0848デフォルトの名無しさん2005/08/26(金) 15:32:02
C++/CLI にも無名デリゲートが(　ﾟдﾟ)ﾎｽｨ…
0849デフォルトの名無しさん2005/08/26(金) 21:41:44
boost::function+boost::bind>>>>>delegate

0850デフォルトの名無しさん2005/08/26(金) 21:59:15
( ﾟдﾟ) ､ﾍﾟｯ boost::bind
boost::lambda（・∀・）ｲｲ!!
0851デフォルトの名無しさん2005/08/26(金) 22:15:31
ぁあぁああああぉおぁあああMSﾏﾝｾーーーーーーーー！！！！
0852デフォルトの名無しさん2005/08/26(金) 22:27:55
>>850
そんな色物いらん

ただのシンタックス・シュガーで充分だから、匿名デリゲートがある方がいい
単純な比較やソートに使うだけだから
0853デフォルトの名無しさん2005/08/26(金) 23:17:04
Draft 1.14 Aug 2005 が公開されているのを今更ながらに発見
全然追いつけないぉ
0854デフォルトの名無しさん2005/10/06(木) 20:26:06
ActiveXでmanaged c++使えるの？
0855デフォルトの名無しさん2005/10/08(土) 15:13:43
主語が逆だぞ
0856デフォルトの名無しさん2005/10/08(土) 15:22:31
いや、正しいだろ。逆ならみんな答えてる

>>854
実際どうか、試してみないと何とも言えんから、自分でやれ
0857デフォルトの名無しさん2005/10/22(土) 11:58:51
vs.net2003を買ってC#はある程度かけるようになったのですが
今度C++(学校にある環境はvc++ ver6)を勉強することになりました。

vs.net2003で選べるc++とvc++ ver6のc++って全然別物なのでしょうか？
それとも家でvs.netでc++やっても勉強になるんでしょうか？
0858デフォルトの名無しさん2005/10/22(土) 12:52:22
>>857
managed じゃなければいっしょ。
vs.net の c++ でも、managed を選ばなければ、vc6といっしょだよ。
0859デフォルトの名無しさん2005/10/22(土) 13:11:00
＞８５８
やったことないけど、プロジェクトのコンソールアプリでファイル名.cppにしてもWIN32API使えるんですか？
自分では、プロジェクトでコンソールアプリで.cならC言語、.cppならC++、
WIN32アプリやMFCならVCだという頭があったけど。
0860デフォルトの名無しさん2005/10/22(土) 14:40:06
> コンソールアプリでファイル名.cppにしてもWIN32API使えるんですか

全然使える。
超使ってる。
0861デフォルトの名無しさん2005/10/22(土) 21:30:50
VC6はC++の準拠度が古いと言うか明らかにおかしいので、細かい差異で苦労しそうではある
0862デフォルトの名無しさん2005/11/17(木) 04:14:43
c#から、MC++でラップしたdllを使用したいのですが、
managedなdllを作る場合、コンパイルオプションはどのようにつければよいでしょうか？
以下のコードを"cl /clr /LD ***.cpp"というコマンドでコンパイルしても、managedなdllが作成できませんでした。
どなたかご教授お願いします。

class umgd {
public :
umgd() { }
~umgd() { }
show() { printf( "test\n" ); }
}

__gc class mgd {
public :
mgd() { p_umgd = new umgd(); }
~mgd() { delete p_umgd; }
show() { p_umgd->show(); }
private :
umgd *p_umgd;
}
0863デフォルトの名無しさん2005/11/17(木) 09:23:34
あげ忘れてた・・・age
0864デフォルトの名無しさん2005/11/17(木) 15:10:30
プロジェクトの段階で選んでおけばいいだけ。
0865デフォルトの名無しさん2005/11/17(木) 16:23:34
>>862
＞__gc class mgd {
先頭にpublicが抜けてるだけでは。
LNK4243の問題が無ければP/Invokeよりこっちを使いたいよ。
08668622005/11/17(木) 16:31:44
>>864-865
ありがとうございます。早速試してみます。
0867デフォルトの名無しさん2005/11/17(木) 18:33:29
managed c++ってしょせんC++やってた人と
C#やってた人が同居していちゃいちゃするの
08688622005/11/17(木) 23:43:12
>>864-865
無事dll化することができました。

LNK4243の警告は出ましたが、とりあえずは使えるようなので今はそのまま使っています。
下記に参考になる情報が載っているようなので、もうすこし頑張ってみます。
返答、ありがとうございました。

ttp://support.microsoft.com/?id=814472
ttp://blog.windy.ac/managed_c/
0869デフォルトの名無しさん2005/12/04(日) 21:40:47
ご教授お願いします
CHOCOAのCCAPIを使って.NETでBOTを作ろうと思っています

MFCの時は登録されていたタイプライブラリからCOleDispatchDriverの派生クラスを自動生成し、
CreateDispatch("CHOCOA.Application");で対応するオブジェクトを得ることができたのですが…

"参照の追加"で生成したdllにInterop::ChocoaLib::CHOCOAというクラスができて、
CHOCOA* chocoa = new CHOCOA();
とすると、このクラスはインタフェイスで生成することはできない、とコンパイルエラーが出ます。

で、隠しクラスっぽいCHOCOAClassというのが入っていたので、
CHOCOA* chocoa = new CHOCOAClass();
とすると、実行時に"DA21EA40-0A85-11D2-901F-00000E7C45FA"というCLSIDは見つからない、と言われました。

regeditでHKEY_CLASSES_ROOT\CHOCOA.Application\を見ると
{F3052B65-0A50-11D2-901F-00000E7C45FA}となっているので、
どうもこの辺が合ってない気がするのですが…

それで、このCLSIDでマネージクラスを生成すればどうにかなるんじゃないかと思うのですが、
どのようにしたら生成できるでしょうか？
0870デフォルトの名無しさん2005/12/04(日) 21:41:37
すいません、一応ageておきます
0871デフォルトの名無しさん2005/12/04(日) 22:10:34
>>869
つーかよ、それCOMとして登録されているDLLとInteropに追加したDLLが別もんなんでね？
参照で追加するとき、レジストリに登録されているCOMを指定してやったら？
0872デフォルトの名無しさん2005/12/04(日) 22:26:12
>>871
えっと、その辺がよく分からんのです。。
正直言ってCOMの仕組みにはあまり自信がないので。。。

HKEY_CLASSES_ROOT\CLSID\{F3052B65-0A50-11D2-901F-00000E7C45FA}\ の下に
InprogHandler32 = ole32.dll
LocalServer32 = CHOCOAの絶対パス
ProgID = CHOCOA.Application
というキーがあったので、chocoa.exeを参照すればいいのかと思ったのですが、参照できませんでした。
他にそれっぽいライブラリ系のファイルは見当たらないです。

今はchocoa.tlbっていうタイプライブラリを使っています。MFCの時も一緒です。
ただMFCの時はCreateDispatchで"CHOCOA.Application"を指定できたものの、
.NETのほうではこれに相当する部分がないなぁ、という感じなのです。
0873デフォルトの名無しさん2005/12/04(日) 22:44:14
参照の追加をするときにCOMを指定できるっしょ
その時、COMの一覧の中から、CHOCOAを指定してやったらどう？
どうも、そのタイプライブラリと、登録されているGUIDが一致してないようにしか
見えないんだけど
0874デフォルトの名無しさん2005/12/04(日) 22:58:57
>>873
私も原因はGUIDの不一致だと思います。

で、そこのCOMの一覧にChocoaLibっていうのがあるんですが、
それを選択すると↑で言ったようになってしまうんです。。
0875デフォルトの名無しさん2005/12/04(日) 23:08:11
「参照の追加・・・」でローカルサーバ（EXEサーバ）は追加できない、っていう問題が
あったような気がするけど気のせいかもしれない。

tlbimp hoge.exe /out:hogeexe.dll とかしてinteropアッセンブリを手動で作ってみては？
0876デフォルトの名無しさん2005/12/04(日) 23:38:38
>>875
ありがとうございます。ただ、やってみたところエラーでした。

＞TlbImp error: The input file 'C:\Program Files (x86)\Local\CHOCOA\chocoa.exe' is
＞ not a valid type library

今タイプライブラリから生成されたアセンブリを逆アセして
CHOCOAClassのGUIDを書き換えて再アセンブルする
という方法を思いついたのですが、ちょっと怖いな。。
0877デフォルトの名無しさん2005/12/05(月) 00:02:57
どうやら>>876の方法でできたようです！
何度もご返事くださった方、ありがとうございました。

これはタイプライブラリの生成時がアレだったということなのかなあ。。
0878デフォルトの名無しさん2005/12/09(金) 17:16:46
VC++.NET2003 でVBなどから参照できるクラスライブラリ作成しております。
基本的には機嫌良く動いているのですが、同じクラスライブラリ内のクラスを
継承した派生クラスでデストラクタを記述しようとするとエラーが出ます。
継承関係のないクラスのデストラクタは成功します。
中身を空にしたりvirtual や　void を付けたり取ったりしても同じです。

また普通にFormのプロジェクト内で作成したクラスの継承では問題ありません。

error LNK2001: 外部シンボル ""void __cdecl __CxxCallUnwindDtor(void
(__thiscall*)(void *),void *)"
(?__CxxCallUnwindDtor@@・・・・)" は未解決です。

クラスライブラリ内で継承したクラスにデストラクタをつけるにはどうしたらいいでしょうか？




08798782005/12/12(月) 23:42:31
放置の模様ですので移動します。
0880デフォルトの名無しさん2005/12/13(火) 09:03:18
放置というよりは、最近、mc++ を触っていないのでわからないんだよな
簡単なアプリでも起こせるの？
08818782005/12/14(水) 17:26:38
オオー!レスが!
えっと、肝心なことが漏れてたのですが、__gcクラスのデストラクタでエラーが出ます。
__gcをとるとエラーはなくなります。
↓これでエラー再現しました。(クラスライブラリ(.NET)にて)

// test.h
#pragma once
using namespace System;
namespace test
{
public __gc class Class1
{
public:
~Class1(){;}
};

public __gc class Class2 : public Class1
{
public:
~Class2(){;}
};
}
0882デフォルトの名無しさん2005/12/14(水) 22:35:49
>881
うーん・・・。手元の環境に2003を入れてないので、2005 英語版で試してみたんだけど
/clr:oldSyntax でコンパイル

namespace DestOrth {
public __gc class Class1
{
public:
Class1()
{
}

virtual ~Class1()
{
}
};

public __gc class Class2 : public Class1
{
public:
Class2()
{
}

virtual ~Class2()
{
}
};
}

これちゃんとコンパイルできたよ？
リンク時にトラぶってるのかな
0883デフォルトの名無しさん2005/12/14(水) 23:28:22
ん？　マネージ拡張でデストラクタ？
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpguide/html/cpconusingcdestructorsyntax.asp
08848782005/12/15(木) 02:27:16
ﾚｽｻﾝｸｽ。

>>883
こんなのもあったりで、なにがなんやら・・・
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vcmxspec/html/vcmanagedextensionsspec_4_2.asp

それから、新展開がありまして、ｸﾗｽﾗｲﾌﾞﾗﾘ作成時に自動的に作成されるcppﾌｧｲﾙをはずすか、
cppの中の #include "test.h" をはずせば何とかリンクが通るようです。
しかし、cppにｿｰｽ書くなら#include をはずせないし。

実装はすべてヘッダファイルへ、ってことでしょうか。
そういう通例があるというのもどっかで聞いたことがあるような無いような・・

0885デフォルトの名無しさん2005/12/15(木) 12:15:01
私も気になっています。
VC++では実装はヘッダーファイルに書くことが多いのでしょうか？

クラスライブラリかWindowsフォーム(.NET)か
によっても違うのかもしれませんが。。
0886デフォルトの名無しさん2005/12/15(木) 12:46:19
実装をヘッダーファイルに書くというイディオムが存在する。
名前は忘れたけど。
0887デフォルトの名無しさん2005/12/15(木) 13:47:04
うる覚えなんだが、むかーし、mc++ で空の cpp を使っているとトラブった記憶がある
メソッド増やして実装を入れたらコンパイルできるようになった気がする
0888デフォルトの名無しさん2005/12/15(木) 13:50:25
>VC++では実装はヘッダーファイルに書くことが多いのでしょうか？

STLなんかは全部ヘッダーなんでわ？

>イディオムが存在する。 名前は忘れたけど。

名前があるのは知らなかった。知りたいお。

0889デフォルトの名無しさん2005/12/15(木) 16:25:47
>>888
＞STLなんかは全部ヘッダーなんでわ？

違うよ。C++用のlibファイルが存在する時点で気づこう。
0890デフォルトの名無しさん2005/12/15(木) 21:54:22
>>889
iostreamとかlocale関係はたしかにlibファイルが使われているだろうが，
俺が一般的だと思う意味でのSTLの部分はヘッダに全て実装されている。
（コンテナ・アルゴリズム・イテレータ・関数オブジェクトなど）
0891デフォルトの名無しさん2005/12/15(木) 22:22:07
まぁ、STLっていう言葉自体、規格上の正式な用語ではないからね。
0892デフォルトの名無しさん2005/12/15(木) 22:32:13
じゃあこうしよう。
WTLは全部ヘッダーだ
0893デフォルトの名無しさん2005/12/15(木) 22:32:39
っていうかtemplateやるならヘッダーファイルになるんじゃ？
0894デフォルトの名無しさん2005/12/15(木) 22:51:11
共通実装がlibにはいってるんじゃなかろうか
0895デフォルトの名無しさん2005/12/15(木) 22:54:12
俺が思うにiostreamはcharとwchar_tで明示的実体化したものがライブラリに入っているのではないかと思う。
0896デフォルトの名無しさん2005/12/16(金) 01:00:48
>>890
SGIのオリジナルSTLはそうだね。
STLportやgccのlibstdc++のSTL部分は*.cもある。
■ このスレッドは過去ログ倉庫に格納されています