1 名前:デフォルトの名無しさん mailto:sage [2010/01/29(金) 23:15:45 ] エスケープシーケンスやWin32APIなどの環境依存なものでもOK。 ただしその場合、質問者は必ず環境を書きましょう。 ※sage禁止です(と代々スレに書いてありますが自己判断で)。 【前スレ】 【初心者歓迎】C/C++室 Ver.70【環境依存OK】 pc12.2ch.net/test/read.cgi/tech/1258873470/ 【アップローダー】(質問が長い時はココ使うと便利) kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/joyful.htm codepad.org/ (コンパイルもできるし出力結果も得られるのでお勧め) ◆ソースのインデントについて 半角空白やTABでのインデントはスレに貼ると無くなります。 そのため、アップローダーに上げるのも手ですが直接貼る場合は、 全角空白か に置換すると見栄えだけはよくなります。
82 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 16:13:05 ] 行番号とかよりも どの関数から/どのデータが原因で投げられたのか、といった情報を入れたほうがいいんでないかい out_of_rangeなら、どの配列からout_of_rangeが出たのかによって それが分かるような例外クラスを作ってrethrowするとか
83 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 16:37:42 ] つ boost::exception
84 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 17:48:55 ] >>81 >>83 やっぱり継承するなりなんなりするしかないか
85 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 18:37:02 ] >>78 デストラクタを private にしてみるとか。 class Hoge { private: ~Hoge() {} };
86 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 18:50:11 ] まともに使えねえよ
87 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 19:06:09 ] C++0xの[[final]]も継承禁止じゃないしな
88 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 19:08:30 ] iface *create(...) { class local : public iface { ... }; return new local(...); } 制限はあるけどこれでfinalだよ
89 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 20:52:17 ] 教えて下さい。 今お仕事のデバッグ用にSDカードのセクタをFATではなく セクタ直接アクセスするコードを今使ってます。 そのソフトでドライブ選択をGetDriveType()でリムーバブルディスクのみを 選択できるようにしておるのですが、これではカードリーダーライターに 刺さったディスク全て選択できてしまいます。(例えばCFとかUSBメモリとか) 自分だけで使う場合は注意すればいいだけなのですが、チームで使ってるんで できればドライブ選択をSDカードONLYにしたいと思っているのですが、 どのようなコードにすればいいでしょうか? 環境 WindowsXP Microsoft VisualC++ 6.0 MFC
90 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 00:22:22 ] >>71 どの方法にも何のメリットも感じられない。 そのままにしとくのが一番スマートな気がする。 >>80 #define OUT_OF_RANGE(what) (std::out_of_range(std::string(__FILE__":"BOOST_PP_STRINGIZE(__LINE__)": ") + (what)))
91 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 01:59:50 ] >>62-63 ありがとう。できるだけ根本的に修正するようにしてみる。 ついでに、このコードについても教えてくれないか。 ttp://codepad.org/novJOf5Z これ、仕事で使ってるgcc4.1.1とcodepad(gcc4.1.2)では警告されるのに、cygwinのgcc4.3.2だと、 -fstrict-aliasingと-Wstrict-aliasingを指定しても警告されないんだ(-Wstrict-aliasing=2を加えれば警告される)。 このへんの動作って4.1.2以降で変更されてる? gccのchangesを見たけど、関係ありそうなのは4.2の The C++ frontend now also produces strict aliasing warnings when -fstrict-aliasing -Wstrict-aliasing is in effect. くらいしか見つけられんかった。
92 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 05:32:31 ] >>91 どうしてそんな碌でも無いコードばかり書くんだ… GCCのchangelogに書いてあるのは大きなものだけだから 知らないうちに内部の動作が少々変わることはありうるよ 無印の-Wstrict-aliasingで警告がでないのが正しいかはわからん そこらへんの加減はgccの中の人にしかわからんだろうから…
93 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 09:36:50 ] #include <iostream> #include <fstream> #pragma pack(push, 1) struct POD { int a, b; char str[5]; int x, y, z; }; #pragma pack(pop) void test(POD &pod) { std::cout << "a: " << pod.a << std::endl; std::cout << "b: " << pod.b << std::endl; std::cout << "str: " << pod.str << std::endl; std::cout << "x: " << pod.x << std::endl; std::cout << "y: " << pod.y << std::endl; std::cout << "z: " << pod.z << std::endl; }
94 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 09:37:33 ] void save(POD &pod) { std::ofstream out("test.bin", std::ios::binary); out.write((char*)&pod, sizeof(POD)); } void load(POD &pod) { std::ifstream in("test.bin", std::ios::binary); POD tmp; in.read((char*)&tmp, sizeof(POD)); pod = tmp; }
95 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 09:39:19 ] int main(void) { POD pod1 = {1, 2, "test", 3, 4, 5}; test(pod1); save(pod1); POD pod2 = {0}; load(pod2); test(pod2); return 0; } 上記のコードは自分のマシンだと期待通りに動いてるようなんですが ほかのマシンに移植しても大丈夫でしょうか?
96 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 09:44:54 ] intの奇数番地アクセスに問題ないCPUだったら、大丈夫かも
97 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 10:01:24 ] >>96 レスありがとうございます 念のためpack(push, 4)にしてみます
98 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 10:07:15 ] 移植性考えるなら stdint.hを読み込んで int を int32_t とかに
99 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 12:44:50 ] >>98 レスありがとうございます バイト数も揃えてみます vc++にstdintが無いのが困りものですがvs2010にはあるようなので・・・
100 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 13:21:04 ] >>92 >どうしてそんな碌でも無いコードばかり書くんだ… ごめんw 実は>>91 は、社内製コードでLoadFileAsync(const char* filename, void** buffer)っていうのがあるんだけど、 これがgcc4.1.1にしたら警告が出たので、調査用に書いたんだわ。 動作は、filenameを非同期にディスクから読み出して、読み出したメモリ領域のアドレスをbufferに返す。 非同期ロード用クラスでも作って、void**を置き換えればいいんだろうが、 既にあちこちで呼ばれてる関数だから手を出しづらいんだよね。
101 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 16:21:27 ] >>99 ttp://www.kijineko.co.jp/node/63 こういうのがあるよ
102 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 23:42:27 ] >>100 それでもその強引なキャストは要らんのでは? A a; void* p; f(&p); a.str = static_cast<char*>(p); もしかしてメモリ領域の確保も非同期なの?
103 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 01:25:07 ] ヘッダファイルの中で#includeの替わりに,classが使われている時があります #includeをclassにすると、何かいい事があるのでしょうか? また、QWidgetは#includeもclassも書かれていませんが なぜ、使う事ができるのでしょうか? calmlight.s2.zmx.jp/Qt4Examples/SimpleMenu.html
104 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 01:34:59 ] 「#includeの替わりに,classが使われている」わけじゃない 前方宣言でググれ というかC/C++の#includeはJavaのimport、C#のusingとは違うぞ
105 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 06:58:32 ] >>103 もうC言語やC++のプリプロセッサっていう勉強をした方がいいんじゃないか?
106 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 09:24:40 ] 継承元クラスを引数で受けた時に、そのprotectedメンバにアクセスできないのは どういう理由でそうなっているのでしょうか? class A { protected: int x; }; class B : public A { public: void operator=(const A& a) { x = a.x; //a.xはprotectedで操作できない }; };
107 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 09:30:31 ] >>106 別のクラス class C : public A (略)などが、 B とは違う都合でそいつを使っている かもしれないから。 めんどくさいから protected なんて最初から使わなけりゃいいんだよ。 private or public でいけないのか、よく考えたほうがいい。
108 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 09:45:32 ] >>107 適当なこというな >>106 自分がAをpublicに継承してアクセス可能になるのは this->aであって 引数としてAを受けた時は外部からのアクセスになる つまりAのpublicなメンバにしかアクセスできない (自分がAを継承してるかなんて全く関係ない) 上のケースでやろうとしてるのはこれと変わらない void f(const A& a){ int a=a.x; } protectedなメンバは 「この機能は継承してから使えな」、っていう意思表示なのに 継承前のAのデータにアクセスできたらおかしいでしょ
109 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 10:04:23 ] だったら外からアクセスしてるのに同じクラスのprivateにアクセス出来るのはおかしいはず
110 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 10:05:47 ] >>108 あんたのそれは何か根拠があるのかね? > 自分がAをpublicに継承してアクセス可能になるのは > this->aであって > 引数としてAを受けた時は外部からのアクセスになる protected がそうなってる( private と違う)理由を聞かれてるんだよ。 ちなみに、 A の継承が public であるかどうかは関係ないし、 this->a 以外にも B& b という引数に対してなら b.a でアクセスできる。 > protectedなメンバは > 「この機能は継承してから使えな」、っていう意思表示なのに > 継承前のAのデータにアクセスできたらおかしいでしょ その説明だと、別の派生クラス C の C& c について B のメンバ関数内で c.a にアクセスできない理由の説明にならないね。
111 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 10:17:53 ] >>100 >>92 に追記しておくけど -Wstrict-aliasingは全ての問題があるケースを警告するとは限らない -Wstrict-aliasingは-Wstrict-aliasing=3と同じで -Wstrict-aliasing=1が最も「少しでも怪しければ警告にする」けど それでもit has very few false negativesとしか言われてない gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Warning-Options.html#index-Wstrict_002daliasing_003dn-317 製品としてgccの最適化によるバグを絶対回避したいなら -fno-strict-aliasingにしてこの種の最適化を無効にするしかない
112 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 10:23:47 ] >>111 > -Wstrict-aliasing=1が最も「少しでも怪しければ警告にする」けど > それでもit has very few false negativesとしか言われてない それ、 "when higher levels do not ... , as it has very few false negatives" の ところで、 1 より上のレベルについて言ってるところだよ。レベル 1 については "it has many false positives" ってなってる。
113 名前:112 mailto:sage [2010/02/05(金) 10:28:46 ] ん?ごめん、読み違えた。 Level 1 だと false negative が少なくて(でもゼロじゃなくて)、かわりに false positive は多いってことか。 112 は忘れて。
114 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 15:57:26 ] ifstream と Win32 ReadFile のメリットとデメリットを教えてください ReadFileはwindows依存していることは知ってます、ifstreamの内部ではReadFileを使っている(?)とかどってでみた気がする 速度を比較してみたらifstreamの方がはやかったです
115 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 16:02:59 ] 1バイトずつReadFileを呼び出したりしていないか? ifstream等は内部にバッファを持って一度の呼び出しで多くのデータを読み込むようにしてAPIの呼び出し回数を抑えているはず
116 名前:114 mailto:sage [2010/02/05(金) 16:10:02 ] ReadFile引数のブッファ指定のところでファイルサイズ渡しているので1バイトずつではないはず
117 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 16:45:56 ] 普通のファイルを普通に読むとOSは勝手にディスクキャッシュするよ
118 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 17:24:52 ] それだとReadFileが遅い理由にならんのでは
119 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 17:28:37 ] いきなりファイル全体キャッシュするわけじゃないから
120 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 18:04:54 ] ディスクアクセスのコストはOSのディスクキャッシュで隠蔽できても システムコール(カーネルとのモード遷移)のコストは隠蔽できません。 ReadFileを何度も何度も呼び出している限り。
121 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 19:48:25 ] ifstreamが速い理由にならんぞ
122 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 20:15:36 ] ナニ言ってんだオマエは
123 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 20:16:50 ] ちなみに stdioと比較してifstreamは全然速くない。
124 名前:デフォルトの名無しさん [2010/02/05(金) 20:23:02 ] 比較しちゃだめだろ iostreamの良い所は別にあるんだから。 何かというとそれは次の人どうぞ ↓↓↓
125 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 20:39:29 ] 継承によって作られている所です つまり入力元や出力先だけではなくstringstreamのように 根本的な構造が異なっても全く同じイメージで操作できる事です とでも言って欲しいのか?
126 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 21:52:34 ] >>114 どんなコードで比較したのかわかるようにコードを晒さないと答えられないな。
127 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 22:16:09 ] >>114 ReadFileの使い方を間違ってるんじゃないか? ifstreamを書いた人はReadFileの使い方をよく知ってるんだと思うよ。
128 名前:デフォルトの名無しさん [2010/02/05(金) 23:44:41 ] メッセーッジについて教えてくれ WM_NOTIFYとON_NOTIFY_REFLECTの関係がわからない 調べたところWM_NOTIFYのメッセージが贈られるとるとON__NOTIFY_REFLECTが呼び出されれウ みたく書いてあったけど じゃあON_NOTIFY_REFLECTがもってる通知メッセージは何よ? わかりやすくおしえてね
129 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 23:49:40 ] >>128 は? 頭おかしいの?
130 名前:デフォルトの名無しさん [2010/02/05(金) 23:50:12 ] >>128 Win32API質問箱 Build86 pc12.2ch.net/test/read.cgi/tech/1265350980/
131 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 23:52:04 ] どっちかというとMFCのほうだな
132 名前:デフォルトの名無しさん [2010/02/06(土) 02:27:22 ] PaintDCの描画領域のクリア方法教えて
133 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 10:22:50 ] InvalidateRectもしくはValidateRectのことか それともFillRectのことだろうか
134 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 13:22:55 ] template< int Foo > class CHoge { public: CHoge(int ini) : m_hoge(ini){} int m_hoge; char m_foo[Foo]; static const CHoge<Foo> sc_Zero; }; //const CHoge<Foo> CHoge<Foo >::sc_Zero = CHoge<Foo>(0); // Foo : 定義されていない識別子です。 sc_Zero を初期化したいんだけど,どのようにすればいいでしょうか?
135 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 13:38:26 ] Fooの値は決まる必要があるんじゃね? template< int Foo > class CHoge { public: CHoge(int ini) : m_hoge(ini){} int m_hoge; char m_foo[Foo]; static const CHoge<Foo> sc_Zero; }; CHoge<1> h(10); const CHoge<1> CHoge<1>::sc_Zero(h);
136 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 13:41:57 ] template < int Foo > const CHoge<Foo> CHoge<Foo >::sc_Zero = CHoge<Foo>(0);
137 名前:134 mailto:sage [2010/02/06(土) 13:51:57 ] >>135-136 ありがとうございます.初期化出来ました.
138 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 17:31:35 ] 前方宣言をすると普通に#includeするよりも、コンパイルが速くなりますか?
139 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 17:33:57 ] 前方宣言はコンパイル依存性を減らしたりするために あると思うんだけど
140 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 17:39:20 ] >>138 コンパイルが速くなるっていうよりも、コンパイルしなおさなければいけなくなるファイルが 減るっていうのが正しいかと。
141 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 18:05:26 ] 前方宣言が必要なパターン class B; class A { B b; }; class B { A *a; }; あとはpimplイディオムで少し似た使い方したり。
142 名前:138 mailto:sage [2010/02/06(土) 18:06:41 ] >>140 やっぱり、そうだよね thx
143 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 22:06:12 ] newとmallocは似たような動作をしますが、 バックグラウンドではnewがmallocを呼び出しているのですか?
144 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 22:09:27 ] >>143 そういう実装も多いけども、そうとは限らない。 それが問題になるようなプログラムを書くべきではないし、書く必要も無い。
145 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 22:48:57 ] WinAPIを使わずにマウスをプログラム側から操作するにはどうしたらよいでしょうか?
146 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 22:50:12 ] そういうライブラリを探す。
147 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 22:57:22 ] >>145 それは不可能だろう。 ラッパライブラリがあれば可能だろうが、 そのラッパもやはりWinAPIは使っているだろうな。
148 名前:デフォルトの名無しさん [2010/02/06(土) 23:43:39 ] VS2005、C/C++でコントローラ(Joystick)の状態を取得するにはどうすれば良いのでしょうか? 調べても中々出てこないみたいなので。助けてください。 プロジェクト設定はWin32コンソールアプリケーションです。 ひどいくらい初心者ですが、よろしくお願いします。
149 名前:デフォルトの名無しさん mailto:sage [2010/02/06(土) 23:53:46 ] GetJoystickState
150 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 00:13:35 ] >>148 Windows APIか、DirectXのDirectInputを使う Joystick Reference (Windows) ttp://msdn.microsoft.com/en-us/library/dd757121(VS.85).aspx DirectInput ttp://msdn.microsoft.com/en-us/library/ee416842(VS.85).aspx ttp://msdn.microsoft.com/ja-jp/library/bb219802(VS.85).aspx
151 名前:デフォルトの名無しさん [2010/02/07(日) 00:30:49 ] DirectInputは使っています。 printf("%d\r\n",js.lX); で一応、初期値の -8 とプリントされているのですが、 動かしても変動がありません。どうも倒しながらキーボードを入力すると数値が変動するようです。 現在はキーボード入力で入力したときだけOpenGLが再描画されるのですが これをJoystickを倒した時に再描画されるようにするにはどうすればよいのでしょうか? switch (key) { case 'd': { Point NextPos( PosX+0.2, PosY ); if( !ColCheck( NextPos ) )PosX +=0.2; glutPostRedisplay(); } ソースはこんな感じになっています。キーボード入力時のみの再描画ではなく、常に?描画するにはどうすればよいのですか? 初心者ですみません。書き込んでいて何を言ってるのかわからなくなってきました。
152 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 00:45:10 ] OpenGLスレで聞いてみれば?
153 名前:デフォルトの名無しさん [2010/02/07(日) 00:50:10 ] はい、そうしてみます。ありがとうございました。
154 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 02:47:37 ] void *型から何かの型へのポインタへキャストする時にそれが有効か調べるいい方法はあります? 今のところハッシュにアドレスとtype_infoのペア保存しておくという微妙な方法しか思いつきません
155 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 07:03:04 ] >154 dynamic_cast かな。 でもどっちかっていうと型判別しなきゃいけないこと自体がどっかおかしいような気がする。
156 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 07:19:04 ] void * にdynamic_castは無理
157 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 08:14:09 ] C++にはリフレクションがないから無理だろ
158 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 10:01:05 ] >>154 shared_ptr があるよ
159 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:15:33 ] struct hoge { int bar1; char *buf; int bar2; }; こんな構造体のbufに文字列入れるなりmallocするなりするとメモリ的にはどうなるの? bar2がその分後ろにずれたりするの?
160 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:22:14 ] template<size_t T_size>struct hoge { int bar1; char buf[T_size]; int bar2; };
161 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:22:50 ] >>155 void*なんか使わないほうがいいと言えばそのとおりなんですが スクリプトと拡張型のポインタをやり取りするのに一回void*に変換されて型情報がなくなってしまうのです スクリプト側で変なことしなければ問題はないんですが、間違えるとエラーも出せずに落ちてしまうのでどうにかできないかな、と >>156 ,157 やっぱり無理・・・でしょうか >>158 すいません 詳しくお願いできますか?
162 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:45:30 ] void*のポインタ先をデータの生ポインタではなく、 struct ptr_holder { void *ptr; type_info ty; }; のポインタとかにはできないの?
163 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:54:49 ] >>161 void*を何かのクラスに変換するのはプログラマの責任になるんだね。 変換方法はプログラマから決めないといけないけど、1種類のクラスしか扱えないのが実情。 そこで、複数のクラスを扱うには、>>162 のように1種類のクラスを挟んでクラスを識別できるようにして変換する。 それをやっているのが>>158 の方法。shared_ptr<void>へのポインタshared_ptr<void>*をvoid*として渡し、shared_ptr<void>*に戻す。その後、shared_polymorphic_cast<Hoge>(*Ptr);で変換。型が違えば例外が投げられる。
164 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 11:56:54 ] >>159 ずれない +------+ 0x11111100 | bar1 | |------| 0x11111104 | buf | ---> NULL |------| 0x11111108 | bar2 | +------+ ↑こんな感じのが ↓こんな感じになるだけ +------+ 0x11111100 | bar1 | |------| 0x11111104 | buf | ----+ |------| | 0x11111108 | bar2 | | +------+ | +------+ | 0x22222200 | 文字列 | <--+ +------+
165 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 12:13:53 ] >>163 shared_ptrのその使い方はshared_ptrの本来の使い方の一部にしかすぎない。 shared_ptrの本来の使い方を知った上で使うべき。
166 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 12:13:58 ] >>162 残念ながら、ptr_holder*をvoid*にして渡すという形になりますので 結局のところvoid*がptr_holder*に戻せるかという、ほぼ同じ問題に戻ってしまいます >>163 やはりvoid*がshared_ptr<void>に変換できる保証はないので、完全では無いですね でも同一プロジェクト内でならshared_ptrに統一することは可能なので試してみたいと思います みなさんレスありがとうございました
167 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 12:39:16 ] >void*がptr_holder*に戻せるか そこは当然ptr_holderしか使わないという縛りが必要になる
168 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 12:50:54 ] void*やshared_ptr<void>ではなく、boost::any(あるいはany*やshared_ptr<any>)にしたらいい。
169 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:23:09 ] LinuxでC++勉強したいんだけど ライブラリって何が標準なの?
170 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:25:02 ] gccとかのこと?
171 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:25:38 ] >>169 まずは C 標準ライブラリと C++ 標準ライブラリだな。
172 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:29:38 ] >>171 boostというのが標準ですか?それともSTLというのですか?
173 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:35:08 ] >>172 boost は標準ではないが、将来の標準に含まれるものを含んでいる。 STL は昔の名前で、今は C++ 標準ライブラリに含まれている。
174 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:38:54 ] >>172 boostは標準ライブラリではない。 だが信頼性・移植性のある外部ライブラリだと思う。 あとboostのすごいところは最先端をめっちゃ追求しているところかな。
175 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:45:36 ] boostは盛りだくさんだから、ひとくくりで全部OKとかダメだとは言いにくいな。
176 名前:progress_display mailto:sage [2010/02/07(日) 15:49:25 ] >>175 私のことお呼び?
177 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 16:40:18 ] 昨日違うスレで質問しましたが、質問させてください public void setXXX(Foo* f)というメソッドがあった場合、 1.setXXX(f);→fはポインタ 2.setXXX(&f);→fはポインタではなく、fのアドレスを渡している 普通にプログラミングをした場合は、1 or 2のどちらでも大丈夫だと思います しかし、GUI関係をプログラミングした場合は、2の方法はダメな可能性が高いと思うのですが 結局はGUI Tool Kitに依存するといいうことでしょうか?
178 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 16:47:07 ] fがFooのポインタなら1だし、Fooのインスタンスなら2 ツールキットとかそういう問題じゃない そもそもpublic void setXXXは通常なら構文エラー
179 名前:177 mailto:sage [2010/02/07(日) 16:51:15 ] >>178 1はFoo* f = new Foo(); 2はFoo f; で宣言しています >そもそもpublic void setXXXは通常なら構文エラー 何故?
180 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 16:58:25 ] そのGUIオブジェクトがローカルスコープ限りで削除されるような場合は別に2でも問題ないと思うけれど デバイスコンテキストとかはそういう使い方をしそうだがウィンドウとかはあまりそういう使い方をしないだろう
181 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 17:06:54 ] >>179 エラーってのは、publicの後ろにコロンが付いてないだけのことだと思う。
182 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 17:06:54 ] >>177 > GUI関係をプログラミングした場合は、2の方法はダメな可能性が高いと思うのですが なんで? 意味わかんない。 可能性が高いとかグダグダ言ってないで、関数の仕様を確認すればいいのに。