C++相談室 part56

1 名前：デフォルトの名無しさん [2007/07/26(木) 00:33:07 ] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 テンプレその他 >>2-15 付近参照 前スレ class C++相談室lt;part56gt; pc11.2ch.net/test/read.cgi/tech/1170343752/l50 641 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 22:43:20 ] 定義？定義じゃネーヨ 概念だろ 642 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:03:17 ] テンプレート関数にテンプレートクラスを渡したいのですが、可能でしょうか 具体的には std::list<int> a; std::list<double> b; func( a ); func( b ); のようにしたいです 643 名前：642 mailto:sage [2007/09/19(水) 00:12:49 ] 自己解決しました 644 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:17:08 ] template <typename T> void func(std::list<T> x) { }; こんな感じ？ 645 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:17:59 ] そんなちょっと考えたら解決するようなことをいちいち・・・ 646 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:30:38 ] 馬鹿だからなんだぜ？ 647 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 12:05:47 ] KODE 648 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 12:15:12 ] 氷結しよっ！ 649 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 12:43:44 ] >>639 それはOOPっていうか、古くは各種アプリのプラグイン(DLL)に始まる インタフェイス抽象とかコンポーネント化とかの特徴のような気が・・・ 650 名前：デフォルトの名無しさん [2007/09/19(水) 20:34:13 ] >>649 それは呼び出される側の再利用でなくて？ 651 名前：デフォルトの名無しさん [2007/09/19(水) 21:28:47 ] 今ポインタの宿題をしていて　　数値を交換するというやつで実行前の値の表示とでたのですがどういういみですか？ 652 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 21:48:45 ] その質問を訊く身にもなってください。 今流行りのアスペルガーですか？ 653 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 21:48:59 ] 意味がわからんし、C言語スレへ池 654 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 21:49:31 ] 俺に免じて許してやってくれ。彼は5歳なんだ。 655 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 21:54:15 ] 俺アスペルガーだけどこんな奴と一緒にしないで欲しい 656 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 05:03:48 ] 「数値を交換するというやつで実行前の値の表示とでたのですがどういういみですか？」 とはどういういみですか？ 657 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 05:09:02 ] 数値を交換するというやつで実行前の値の表示とでたのですがどういういみですか？ What abhorring is of of display of the value before it executes it by the guy of exchanging numerical values it? 憎悪が交換数値の奴でそれを実行する前の価値の表示のものであること、それ? (ﾟДﾟ)? 658 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 06:20:59 ] >>651 お前があほという意味じゃ 659 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 07:09:57 ] ある仮想関数が、メンバ変数を書き換えないと想定されている場合、constを付けた方がいいんでしょうか？ 例えばこんな感じ↓ class A { public: virtual int GetX() const = 0; }; class B : public A { public: virtual int GetX() const { return x_; } private: int x_; }; const A*型を使う場面があるのかが気になります。 660 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 07:20:55 ] >>659 そうですね。 661 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 07:31:21 ] >>659 つけられるconstは全てつけるべき。 非constである必要ができたら、非const版を追加するかconstを外すか熟考すべし。 662 名前：659 mailto:sage [2007/09/20(木) 07:36:33 ] ありがとうございます。 663 名前：kkptcnZciZ mailto:ekeskb@bokqzg.com [2007/09/20(木) 12:34:39 ] KOMUgI <a href="vunuddokfscm.com/">vunuddokfscm</a>, [url=pliwysnvpdex.com/]pliwysnvpdex[/url], [link=uquzjkpzhomt.com/]uquzjkpzhomt[/link], hukythasnspn.com/ 664 名前：マターリ ◆AbENcvTP5o mailto:sage [2007/09/20(木) 14:27:35 ] いきなりですみませんがこのスレに協力してくれる人を探しています。 ttp://sports2.2ch.net/test/read.cgi/entrance2/1190215633/l50 665 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 14:57:12 ] >>664 マルチすんな。 666 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 15:16:10 ] >>650 ん？ プラグインやインタフェイス抽象は主として呼び出す側の再利用に繋がると思うけど。 呼び出される方の利用の仕方がまちまちだと、 呼び出す側はいちいちそれに合わせなくてはならないわけだけど、 インタフェイスや呼び出し規約(API)という形に抽象化し共通化しておくことによって、 呼び出し側を変更せずに機能を追加してゆくことができる。 もちろん呼び出される側を再利用する仕組みでもあるんだけど、 呼び出される側の再利用だけのためであれば単にAPI公開で十分なわけで。 667 名前：デフォルトの名無しさん [2007/09/20(木) 16:37:16 ] template<class T> class A { public: void (A<T>::*func)(); }; template<class T> class B { public: static void (B<T>::*func)(); }; template<class T> void (B<T>::*B<T>::func)() = NULL; template<class T, class U> class C { public: void (U::*func)(); }; template<class T, class U> class D { public: static void (U::*func)(); }; template<class T, class U> void (D<T, U>::*U::func)() = NULL; クラスDのようにしたいんですけど、どなたかわかる方いませんか？ Visual Studio2005 SP1 668 名前：デフォルトの名無しさん [2007/09/20(木) 16:38:31 ] ちなみにクラスD以外はビルドＯＫです 669 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 16:49:48 ] template<class T, class U> class D { public: static void (U::*func)(); }; template<class T, class U> void (U::*D<T, U>::func)() = NULL; こうだろ？ 670 名前：デフォルトの名無しさん [2007/09/20(木) 17:19:20 ] うぉ、ビルドとおった〜 ありがとう！！ 昨日からずっと考えてたよ。 671 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 18:48:48 ] 横からごめん template<class T, class U> void (U::*D<T, U>::func)() = NULL; ってどういう意味？ 672 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 19:04:46 ] >>671 単なる、staticなメンバー変数funcの定義だよ。 NULLで初期化してるだけ。 673 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 19:05:53 ] void (U::*)() 型のstaticメンバ変数 D<T, U>::func を定義して NULL で初期化している 674 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 20:44:48 ] 最近某入力デバイス共有ソフトのソースと某モデリングソフトのプラグインサンプルのソースと 見る機会があったんだけど そのどっちも、どう考えても継承ツリーの最底辺、絶対継承されっこないし実際されてない javaだったらfinalがついてもおかしくないクラスのメンバで 継承元の仮想関数をオーバーライドしている関数にvirtualがついてた 薄々感じてはいたんだけどどんな状況でもオーバーライドした関数にはその目印にvirtualをつけるっていう 暗黙のコーディングルール（というかおまじない？）のようなのが流行してるのかな？ それともvirtual修飾子の意味をほとんどの人が誤解している？ 675 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 20:51:49 ] かなり昔から流行ってるよね。 676 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 20:56:41 ] C#のvirtual, overrideキーワードを見るよろし 677 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 20:58:33 ] >>676 C# なんか存在しない頃から流行ってるよね。 678 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:24:07 ] 別にはやってないだろ 679 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:26:07 ] 文法的にはどっちでもいいんだっけ？ 680 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:27:37 ] 多分継承元のクラスから関数宣言コピペして、面倒だからvirtual削除してないだけだろ。 681 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:40:33 ] virtualつけてもoverrideかどうかは分からない ということに最近気づいた 682 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:41:32 ] overrideする側はvirtual要らないんだっけ 俺はいつもコメントにoverrideって書くけど C#がうらやましいぜ 683 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:53:43 ] 基本クラスがvirtualなら十分でそれ以降は任意だったと思うがドキュメントが出てこない。 継承が深くなるとvirtualかどうか確認するのにいくつもヘッダーファイルを遡ることになるから、 overrideしたところにもvirtualがあるとわかりやすい。 いま基本クラスと書いたが途中からvirtualっていうのもありなんだよな。 #include <iostream> using namespace std; class A { public: void Say() { cout << "hello A" << endl; }}; class B : public A { public: virtual void Say() { cout << "hello B" << endl; }}; class C : public B { public: void Say() { cout << "hello C" << endl; }}; int main(){  A *a = new C(); a->Say();  B *b = new C(); b->Say();  return 0;} 結果 hello A hello C 684 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 21:59:49 ] 一度virtual付ければ後は無くておｋ。 俺はドキュメントなんか鼻から探すつもりもありませんがｗ 685 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:01:01 ] あ、でもvirtualはいつも付けてる。 理由は>>683と一緒。 686 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:01:12 ] sealedが欲しい。途中から隠蔽ｗ 687 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:06:18 ] #define public protected 688 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:26:15 ] とにかく、C#なんかより前から流行ってるよね。 689 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:35:25 ] >>686 sealedは継承禁止じゃね？ 690 名前：デフォルトの名無しさん [2007/09/20(木) 22:36:54 ] void func(const T& param) { T.Hoge(); } っておかしい？ 型Tは何かわからないからそのメソッドHoge()を呼ぶのはおかしい？ 691 名前：デフォルトの名無しさん [2007/09/20(木) 22:37:32 ] void func(const T& param) { param.Hoge(); } の間違いでした 692 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:38:24 ] 継承される事を前提に作ってないクラスはデフォルトでsealed(final) って仕様だとうれしいんだけど 小規模で作ってる分にはいらないけどさ 693 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:42:09 ] 大規模開発なら「派生型を作らないこと」とドキュメントに書けばいいような・・・ オープンソース物みたいにソースがドキュメントって感じのだと、 そういう言語によるディレクティブは役に立つとは思うけど。 694 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:56:14 ] >>689 メソッドに対するシールド。 class A { public virtual void Say() { .. ; }} class B : A { public override sealed void Say() { .. ; }} 695 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:03:45 ] >>694 それ上書き禁止で隠蔽とはいわないんじゃねーかと。 696 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:09:03 ] >>695 やりたいことはこうよ。 class A { virtual F class B : A { sealed F // Aに対するoverrideだが、この後の継承は上書き扱い(非virtual)になる。 697 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:10:36 ] こんなのはどうだっけ？ class A { public: void a() {}; }; class B : public A { public: template<typename> void a(); /*not implement*/ }; 698 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:13:04 ] >>696 それは隠蔽とは言わんだろ。 AやBにキャストしたら そのまま使えるんだし。 Javaだと覆い隠し(shadowed)とか言ってるような。 699 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:18:46 ] 目印なんだったらコメント使えばいいのになんでそれをトークン使って プログラムそのものを変質させてしまう形でやってしまうのだろう いったい誰がこんな風習を広めたのか気になって眠れない 700 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:19:09 ] >>672 ぁーなるほど。 void (U::*)()の、D<T,U>::funcを。ってことね。 了解しますた。さんくす 701 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:19:49 ] >>698 C#だとこれのことを隠蔽と言うだけどね。VBだとShadows。 sealedといったのは例えが悪かった。このnewがC++に欲しいという話。 class A { public virtual void Say() { .. ; }}  class B : A { public override void Say() { .. ; }}  class C : B { public new void Say() { .. ; }}  702 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:20:25 ] >>690-691 問題ない。 もしTがメンバHogeを持っていなければ、エラーになる。 それなんて動的言語と言いたいところだが、 そこはC++なんでコンパイルエラー。 703 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:43:21 ] >>701 悪い、それ隠蔽だわ。カプセル化の文脈で出てくるデータ隠蔽と勘違いしてた。 704 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:58:00 ] >>703 死ね 705 名前：デフォルトの名無しさん [2007/09/21(金) 00:28:53 ] >>702 サンキュ 706 名前：fIIPJstQwl mailto:woptyu@mail.com [2007/09/22(土) 03:23:44 ] zghXa7 <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0484.html">big cock</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0484.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0531.html">big cocks</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0531.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0682.html">big dick</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0682.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0731.html">big dicks</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0731.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0874.html">big naturals</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0874.html]pussy[/URL] 707 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 06:54:59 ] void func(int n) { 　void *a = (void*)new char[n]; 　/*...*/ 　delete[] (char*)a; } これってメモリリークを起こさずにうまく開放されるんでしょうか？ 708 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 06:57:27 ] 日本語がおかしい。 メモリリークは開放処理を試みた後に発生する。 709 名前：Kusakabe Youichi mailto:sage [2007/09/22(土) 07:16:59 ]   710 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:27:23 ] >>707 途中で例外が投げられてfuncを抜けるなどといった事態が起これば、 メモリリークするね。 711 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 11:06:37 ] 間違って pc11.2ch.net/test/read.cgi/tech/1188748806/770 に書き込んでしまいました。 宜しくお願いします。 712 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 11:22:09 ] お断りします 713 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:05:23 ] >>661 >つけられるconstは全てつけるべき。 自分が読んだ本ではconst使いましょうという感じだったので 今までconst使っていたのですが、会社でconstを使うなといわれました。 const推奨派とconst禁止派みたいなのがあるのでしょうか？ 714 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:18:58 ] 「（たまたま）変更されてない」って理由でつけると結局あとでconst外しまくる羽目になる。 「（概念や仕様から考えて）変更しない」って理由でつけるべき 715 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:23:08 ] 外しまくる羽目になってでも現在付けられるものは 全部付けた方が分かりやすいという考え方もある。 716 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:34:26 ] >>713 const禁止とかどれだけ低脳なんだwww 取り合えず禁止になりうる理由として考えられるのは、 ・API等に非constポインタを渡す必要があり、キャストの排除が最優先ルール ・クラスのconstメンバ関数にコンストラクタで代入できない （↑もちろんメンバ変数の初期化は代入じゃなく初期化子並びを使うべきだが C転向者が多くて教育コストがかかる） ・宣言が長くなるのでちょっと読みにくくなる ・メンバ関数の適切なconst指定も必要になってくるが、C転向（以下略 ・既に非constで作り上げてしまった社内ライブラリを作り直せない。 ・論理バグはコーディング工程で見付ける（コンパイルえらー）のではなく、 デバッグ工程で評価チームが見付けるものとして スケジュールやら人員配分やらが組まれていて直せない。 ・上位の人が勉強嫌い 717 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:39:23 ] >>711 実際にはnew[]するときに、sizeof (T) * 要素数よりも もう少し余分に確保されている可能性がある。 主にデストラクタを呼ぶ回数を記録するため。 もちろん、delete[]ではそれも含めて解放される。 718 名前：NXRoXAzeEmJXNM mailto:doutiregdou@mail.com [2007/09/22(土) 12:50:13 ] IpHLIP <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0942.html">big nipples</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big0942.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big1022.html">big tits</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big1022.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big1155.html">big tits round asses</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=big1155.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=black0124.html">black lesbians</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=black0124.html]pussy[/URL] <a href="www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=black0284.html">black pussy</a> [URL=www.pic.ucla.edu/~nathan/cgi-bin/moin.cgi/Dirioly?action=AttachFile&do=get&target=black0284.html]pussy[/URL] 719 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:51:29 ] >711 >delete[] は type* （この場合 char* ）から >sizeof(type) * (プログラマからは見えない、確保された要素数) >の分だけのバイトを開放するという挙動でしょうか？ 確実に言えるのは new[] で確保された領域が解放される、ということだけ。 サイズについては例えば 16 バイト単位とかに切り上げられてるかもしれない。 なお、delete[] については、静的な型と動的な型が一致することが要請されている。 > 14882:2003 5.3.5/3 >In the second alternative (delete array) if the dynamic type of the >object to be deleted differs from its static type, the behavior is undefined. で、気にしているだろうキャストについては、一度 void* にキャストした後、 元の型に戻した場合、値が一致することは保証されているので問題ない。 > 14882:2003 5.2.9/10 >A value of type pointer to object converted to “pointer to cv void” and >back to the original pointer type will have its original value. 720 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:53:50 ] 静的な型と動的な型の一致とは？ 721 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:01:43 ] >>720 静的な型とはソースコード上の型、 動的な型とは実際の型のこと。 例えば、クラスDがクラスBを継承していたとして、 こういうことはやめてということ。 B* p = new D[n]; delete[] p; 722 名前：713 mailto:sage [2007/09/22(土) 13:05:16 ] >>714>>715>>716 なるほど、参考になります。ありがとうございます。 私のところではconstは一切禁止のようです。 「constを使うとコードの量が増えて読みにくい」 「constを使わずに読みやすいコードを書けば、コーディングミスも少ないから効率がよい」 という理由だそうです。 723 名前：デフォルトの名無しさん [2007/09/22(土) 13:09:35 ] このスレッドがふさわしいかどうかわかりませんが、 質問させてください。 C++でリングバッファを作成しようと思っています。 Read PointerとWriter Pointer、そしてBufferを用意し、 Bufferから"複数バイト"を取得する、という処理です。 for(int i = 0; i < num; i++) if(ReadPointer != WritePointer){ value = Buffer[ReadPointer]; ReadPointer = (ReadPointer + 1)%BufferSize; } else break; } 上記のように1バイトずつ読み込むならこれでいいとおもうのですが、 これでは1バイトごとに条件文＋インクリメントが入るため避けたいです。 一気に複数バイトを読み込むことを考慮した場合、 "ReadPointerがWritePointer"を 越えないことを判断して、バッファを参照することが必要です。 複数バイトを読み込む場合を考慮したリングバッファを実現する スマートなアルゴリズムはあるのでしょうか？ ReadPointer < WritePointerの位置関係からバッファ読み込みを 一気に行うことは容易ですが、ReadPointer > WritePointerの 位置関係からバッファ読み込みを一気に行う処理で詰まっています。 724 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:11:12 ] なんだか前世紀からタイムスリップしてきたみたいな職場だな。 組み込みでCを使ってるって言うのならまだ分かるが、 それでC++かよ。 725 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:15:23 ] #define N 7をconst N = 7;にしたところで コードの量が増えるとは思わないけど。 constにも色々とあるけどさ。 726 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:32:05 ] >>707 auto_ptr 使えば。 727 名前：723 [2007/09/22(土) 13:33:38 ] >724 ご返信ありがとうございます。 特に組み込みなどではありません。 通常リングバッファはどのようにして実装するのが通例となっているので しょうか？セオリーなどが確立しているのでしょうか？ 728 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:42:40 ] >>726 new[]したものをdelete[]しないのは駄目だろ。 scoped_arrayとかshared_arrayとか結局Boost頼み。 729 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 13:46:48 ] >>727 BufferSize-ReadPointer 分だけ memcpy してから、 ReadPointer をゼロにして続きを処理すればよい。 C++ では普通テンプレートベースの汎用クラスを用いる。 高速化の必要がある場合には自前で書く。 （ココに高速化の必要がある場合には、リングバッファから取り出して 別の場所へコピーなどしないでバッファを直接読んで処理する方が 良いことが多いけど） 730 名前：デフォルトの名無しさん [2007/09/22(土) 13:52:42 ] 普通に一バイトずつ読み込めばいいだろが 一度に20バイトずつコピー出来ても大して変わらないだろ 731 名前：723 [2007/09/22(土) 13:57:09 ] >727 ご返信ありがとうございます。確かに2回に分けてBufferを取得すれば 可能です。 テンプレートベースの汎用クラスを用いる、というのはdequeなどを 使用するということでしょうか？ 高速化を目指しております。 >（ココに高速化の必要がある場合には、リングバッファから取り出して >別の場所へコピーなどしないでバッファを直接読んで処理する方が >良いことが多いけど） 汎用クラスを用いず、地道にmemcpyなどを使ってデータを取得したほうが よいのでしょうか？繰り返しの質問になってしまいますが。 732 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:00:44 ] >>721 >B* p = new D[n]; >delete[] p; これダメなの？ これに対応する為にvirtualデストラクタがあるんだと思ってたけど。 733 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:04:13 ] >>731 そうではなくて、ココをチューニングする必要があるのは おそらく数M〜数十Mバイト毎秒の処理を行う場合なわけで、 そんなものをメモリ上でこっちからあっちへコピーする処理自体 無駄なのでやらないようにする、ということです。 例えば映像のデコーダの入力段でリングバッファを用いるような場合、 read(buf, n) などとしていちいちバイト列をコピーして取り出すのではなく、 char* peek(size_t n) のように直接内部のバッファを覗くための関数を用意して、 リングバッファ終端以外では直接バッファ内のバイト列を処理するようにする、等。 734 名前：デフォルトの名無しさん [2007/09/22(土) 14:09:24 ] N 最後のナンバー n番 からdバイトコピーするとする if ( n + d - 1 > N){ memcpy(*,*, N - n - d); memcpy(*,*, n + d - N);} else memcpy(*,*, d); のようにすれば良い 735 名前：723 [2007/09/22(土) 14:11:23 ] >731 ご返信ありがとうございます。理解が乏しいかもしれないので 確認させてください。 readはmemcpyにより格納されたほかのバッファを利用する、ということで peekはmemcpyで移さずにそのまま参照するということですね。 そして、リングバッファ自体はC++の汎用クラスを使って問題ないという ことでしょうか？ >リングバッファ終端以外では直接バッファ内のバイト列を処理するようにする、等。 リングバッファ終端以外はpeak()、終端ではmemcpyなどを使って処理する、 ということでしょうか？ リングバッファの実装が初めてでなかなかイメージがわいてこない状況です。 何度も質問してしまって申し訳ありません。 736 名前：713 mailto:sage [2007/09/22(土) 14:13:21 ] 低スキルなので>>723の質問の意味が分からなくて >>724は私（>>722または>>713）に対するレスかと思ってしまいましたw 違ったのですねw >>725 仮引数とかにconstをつけるとコードの量が増えて読みにくいから禁止なのだそうです。 737 名前：724 mailto:sage [2007/09/22(土) 14:13:58 ] >>727 いや、ひとつ上にレスしただけ。 738 名前：723 [2007/09/22(土) 14:18:17 ] >734 実際のサンプルを教えてくださってありがとうございます。 ぜひ参考にさせていただきます。 739 名前：デフォルトの名無しさん [2007/09/22(土) 14:19:42 ] >>738 コードは間違ってる所あるけど、 終端を乗りこえていたら、分割して先頭からコピーすればいいだけ 740 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:30:07 ] >>735 Q1.前半 Yes. 後半 No. Q2. 用途によります。動画のデコーダなどの場合は一度にリニアに アクセスするのは高々数十バイト程度なので、一時的なバッファに コピーしてそこのポインタを返す、あるいは内部バッファを余分に 確保しておいて、バッファ先頭にある続きのデータをそこに複製して リニアに読めるようにする、等。 読む側の処理が簡単なものなら、終端をまたぐケースだけ 前半、後半に分けて処理するようにしても良いでしょう。 Q1. の後半とも関連するのですが、ただひとつ言えることは ここを自前で実装すべきなのは、レアケースであって、その場合には プロファイラやテストなどを行って確かめつつ最適なコードを書く必要があり、 定石みたいなものは無いということです。 ただまぁmemcpyは各社最適化されていて早いコードで実装されてるので、 チューニングしたいんだけど時間がないとかいうときには便利。 741 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:32:00 ] 言い切ってやる。高速化すべきポイントはそこじゃない。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef