C++相談室 part56 - 暇つぶし2ch

C++相談室 part56 ..

764:723
07/09/22 16:14:51
>740, 741
ご返信ありがとうございます。
やりたいこととしては、参照用のリングバッファを書き込み用のリングバッファに
定期的に10KB～300KB程度のデータを移したいと思っております。
(まず初めに最終的にやりたいことを書かなくてすいません)。

この場合は、終端をまたぐケースを考慮して(734さんのコードを参考、
2回の処理に分けるなどをする)、memcpyを使う、という方向で
考えたいと思います。
ただ一点、やはりC++の汎用クラスを使うのがいいのか、単純に
配列を使ってリングバッファを実装すればいいのか悩んでいるところです。

>ここを自前で実装すべきなのは、レアケースであって、その場合には
ここっていうのはreadとかpeak()のことですよね？

>言い切ってやる。高速化すべきポイントはそこじゃない。
この部分ばかりに注目するのではなく、
他の処理アルゴリズムをもっと最適化しろってことでしょうか？

確認ばかりのレスになってすいません。

765:デフォルトの名無しさん
07/09/22 16:15:05
>747
> これは仮想デストラクタがなくても領域自体は確保されるんですよね？
はい。
> Dのデストラクタが呼び出されないのでコンストラクタとかでnewしててそれをデストラクタでdeleteしてる場合はだめだけど
規格上は delete しちゃうと未定義動作。

>755
配列は polymorphic に扱わないというのが基本。理由は >763

766:713
07/09/22 16:16:59
>>750
>私と一緒に働きませんか?w
そう言われるとなんだか嬉しいですwでも私は足引っ張りまくると思いますよ？w

>>755
>for文に入る度にiが確保しなおされるとしたら速度変わるカモな。
なるほど、私の上司は速度についてはそれを言っていたのかもしれません。

私はiのスコープをループの中だけに限定するつもりで
そのように書いていました。（これも本で読んだので・・・）

>>756
私はiやjを使っています。

767:デフォルトの名無しさん
07/09/22 16:25:30
for　(int　iとint　i;　for(で最適化しても
速さに違いが出るようなコンパイラなんて
窓から投げ捨ててしまえ。

そんなことで速さに違いが出るのだったら、
設計思想的に、はなからこんな機能導入されていない。

768:デフォルトの名無しさん
07/09/22 16:28:36
基本的に
for ( int i= )の方が速いのでは？
その都度変数を確保すればレジスタに乗りやすいが、確保してあったままではHDDやメモリに乗っている可能性が高い

769:755
07/09/22 16:31:58
>>757
>>755は>>753に対して何か言ったつもりはないけど、
その話は(他のスレだったかで)聞いたことがアルよ。

>>762
多分 i = index のi じゃないかな。配列で使うことが多い気がする。
jは単にiの次の文字。

>>763,>>765
なるほど、このスレ見なければそのまま使ってたところだ。
勉強中でg++では問題なさそうに見えたからね。情報ありがとう！

>>767,>>768
まあ実際には気にするほどな差が出るとは思わないよね。

770:デフォルトの名無しさん
07/09/22 16:34:23
>>768
いつの時代のコンパイラ使ってるんだ？　お前は。

771:デフォルトの名無しさん
07/09/22 16:36:43
intで差が出るのは糞コンパイラ未満だが、
intでは無くiteratorだった場合差が出ても果たして糞コンパイラ未満と言えるだろうか。

772:デフォルトの名無しさん
07/09/22 16:36:58
しかし、ある言語の常識を別の言語にまで持ち込むバカっているんだなぁ。
C（とCが全盛だった時代の貧弱なコンパイラ）ならまだ分かるかもしれないが、
今の時代のC++でやることじゃないだろ。

絶対に関わりあいたくないから、どこで働いているのか晒してくれないか？ｗ

773:デフォルトの名無しさん
07/09/22 16:38:09
大丈夫
君には入社できないから

774:デフォルトの名無しさん
07/09/22 16:39:42
>>771
前提を変えるなアホ。

そのイテレータのコンストラクタが100MBぐらいメモリを確保するんだったらどうだろうかとか、
いくらでも話を広げられるじゃないか。

775:713
07/09/22 16:41:07
>>772
>絶対に関わりあいたくないから、どこで働いているのか晒してくれないか？ｗ

私の会社ですか？それは勘弁してくださいw

776:デフォルトの名無しさん
07/09/22 16:42:05
ぶっちゃけ日本のC++PGの何割がEffective C++とか読んでんだろうな
板違い気味だけど

>>771
俺だったら滅茶苦茶速度に過敏なコードだったら
例え速度が全く等しくてもポインタにする

777:デフォルトの名無しさん
07/09/22 16:47:58
i,j については↓の「暗黙の型宣言による伝統的・慣習上の変数命名規則の誕生」の項を参照。
Wikipedia項目ﾘﾝｸ

778:デフォルトの名無しさん
07/09/22 16:52:18
>>768
基本的に、C/C++ではローカル変数は全てスタックに確保される。
その場合、その確保作業は関数突入時にのみ行われる。
従って、次のようなコードはどちらも確保に伴うコストに変わりはない。
但し、後者の場合は最初のiと後のiで違うメモリを確保する可能性は、ある。
--
void func()
{
int i;
...;
for (i = 0; i < N; ++i) ...;
...;
for (i = 0; i < N; ++i) ...;
}
void func()
{
...;
for (int i = 0; i < N; ++i) ...;
...;
for (int i = 0; i < N; ++i) ...;
}
--
# 勿論、後者もiの有効範囲が重ならないことは容易に判る訳で、真っ先に最適化の対象にはなりそうだが。

779:デフォルトの名無しさん
07/09/22 16:53:29
>>776
私だったら、滅茶苦茶速度に過敏なケースにコンテナは使わないな。

780:デフォルトの名無しさん
07/09/22 16:57:00
>>778
>後者の場合は最初のiと後のiで違うメモリを確保する可能性は、ある。
つまり関数突入時に二つのiを確保するということかな？
だとすれば、速度／メモリ量共に影響があるじゃないか！

781:デフォルトの名無しさん
07/09/22 16:58:44
>>776
可読性も決して軽視出来ない要素だろ・・・条項

782:デフォルトの名無しさん
07/09/22 16:59:53
>>780
馬鹿だな、全く最適化を考慮しない場合の話だぞ。
それに、速度には全く影響ないじゃないか。

783:デフォルトの名無しさん
07/09/22 17:03:16
>>782
>馬鹿だな、全く最適化を考慮しない場合の話だぞ。
その場合のつもりで言ったんだ。
>それに、速度には全く影響ないじゃないか。
すまん、勘違いだった。

784:713
07/09/22 17:04:42
>>776
>ぶっちゃけ日本のC++PGの何割がEffective C++とか読んでんだろうな

Effective C++は持っていますが難しくて分からないところがたくさんありました。
私の会社ではconstのことを考えるとEffective C++とか読んでるのは私だけですかねぇ・・・。

785:デフォルトの名無しさん
07/09/22 17:06:27
>>780
お前の環境についてはしったこっちゃないが。
俺様の環境ではスタックポインタを4つ減らすか8つ減らすかの違いでしかないな。
あと俺様のコンパイラはお前以上に頭がいいので、ひとつしか使わないがな。

786:デフォルトの名無しさん
07/09/22 17:08:22
頭のいいコンパイラなら
そもそも使わない分までスタックポインタを移動しない。

787:713
07/09/22 17:39:37
あと、他にも会社で禁止にされたことがあります。
ブロック内でfor文やif文など以外のブロックを作成してはならないと言われました。
理由は「行数が増えたりして読みにくくなる」「変数は関数の先頭で宣言したほうが読みやすい」からだそうです。

私はこんな感じで { } を使うことがたまにあります。
void hoge(void)
{
　　　{

　　　}
}

私の会社では禁止なのですが、この書き方は一般的なのでしょうか？
皆さんはこのように { } を使うことはありますか？

788:デフォルトの名無しさん
07/09/22 17:45:51
>>787
デストラクタの実行タイミングを細かく制御したいとき(セマフォなどの共有リソースを使ったりとか)には
よくそういう包み方することはあるな。

789:デフォルトの名無しさん
07/09/22 17:46:42
>>787
変数を使う範囲を明示するために頻繁に使うよ。
その会社には仕事を頼みたくないな…。

790:デフォルトの名無しさん
07/09/22 17:47:53
>>787
俺はあまりやらない。その内側のブロックを関数化するかもしれない。

791:デフォルトの名無しさん
07/09/22 17:49:02
>>713
そんな会社辞めちまえ、ダメプログラマにされるぞ

792:デフォルトの名無しさん
07/09/22 17:49:28
やっぱり出入り禁止だw

>>787
＞理由は「行数が増えたりして読みにくくなる」「変数は関数の先頭で宣言したほうが読みやすい」からだそうです。
この辺でお郷が知れる。
こう書く人が多かったりしない?
--
FILE * fp;
fp = fopen(...);

793:デフォルトの名無しさん
07/09/22 17:55:17
>>713
尻穴みたいな井の中の蛙になりたくないなら
学習の意欲のあるうちに辞めちまったほうがいい

あるいは部署変えてPG以外の業務勉強したほうがためになりそう

794:デフォルトの名無しさん
07/09/22 18:01:32
>>787
それは禁止されてていい

795:デフォルトの名無しさん
07/09/22 18:03:07
ある意味そのレベルでC++使ってるっちゅーのが感動的だナ

C++といいつつ実質Cとして使ってる制御系か？
VC++6.0以前とMFC使ってる業務系か？

制御で「const使うな」はありえんか

796:デフォルトの名無しさん
07/09/22 18:14:00
これで「クラスって何、おいしいの」だったら傑作なんだが。

797:デフォルトの名無しさん
07/09/22 18:16:17
どこが？

798:デフォルトの名無しさん
07/09/22 18:20:00
>>787
関数内の { } は変数などのスコープを限定するツールとして役に立つよ。
スコープを限定するのがどういいのかは、話すと長いが...
グローバル変数がよくない(誰がどういうタイミングでアクセスするのか
把握できなくなる・しにくくなるから)のとおおよそ同じ理屈。

根拠のない(しかもわりと間違っている)ローカルルールが多いね。
チーム内で1人で反抗してもしょうがないとは思うけど、
ちゃんとしたプログラマになるつもりなら、
後学のためにまず初学者向けの良書を読んでおくことをお勧めする。個人でね。

Effective C++よりももうちょっと易しいものから読んだ方がよさげ。
...って何がいいんかね。C++ Coding Standardsってのも良書でお勧めできるけど、
やっぱりちょっと早いような。

799:デフォルトの名無しさん
07/09/22 18:21:02
そんな長い関数を書くなよ

800:713
07/09/22 18:24:51
皆様、レスありがとうございます。

>>792
いいえ、C++ Builderを使っているのでファイルにアクセスするときは
みんなVCLを使っていると思います。
VCLに関連して「Delphiを使うかもしれないからC++のライブラリに依存してはならない」
という理由でSTLも禁止になりました。
STL禁止は守れそうにありません。

>>794
その理由は
「行数が増えたりして読みにくくなる」「変数は関数の先頭で宣言したほうが読みやすい」からですか？

>>795
前述のようにC++Builderを使っています。
パソコンからいろんなものを制御しています。

801:デフォルトの名無しさん
07/09/22 18:29:48
>>800
悪いことはいわんからとっとと逃げ出したほうがいいんじゃないか、その会社。
正直言ってアホしかいねーだろ、どうみても。

802:デフォルトの名無しさん
07/09/22 18:34:13
なんか凄いことになってるな。

>>773
これなら刺身の上にタンポポを乗せる仕事のほうがまだマシだ。

803:デフォルトの名無しさん
07/09/22 18:36:11
標準ライブラリを使っちゃいけないってどんだけー

804:デフォルトの名無しさん
07/09/22 18:40:08
まあ、仕事でやってるとわけ分からんルールは多いね。
　なぜそするの？ → 以前からそうだから。
　こう変えたほうが良いのでは？ → 今までこれでうまく言っているのだから変えるべきではない。
ということが多すぎ(--;

とりあえず社内ルールだからと割り切ってるが、本来どうあるほうが良いのかという勉強は欠かさないつもり。

805:デフォルトの名無しさん
07/09/22 18:40:12
STL禁止か……もはやC++じゃないな。
テンプレートは使えるんだろうか。

というかなぜC++を使っているんだ。
もういっそのこと全部Delphiでいいだろ。

806:デフォルトの名無しさん
07/09/22 18:45:25
この手の社内ルールというのは、
それを決めた時点では妥当だったりそれなりの理由があったりするものだが、
その後状況が変わってもそれを盲信して変えないという状況に陥りがちなんだよな。
なぜそうするのかが忘れさられて、ただルールだからという理由で守られ続ける。

807:デフォルトの名無しさん
07/09/22 18:47:45
STL禁止や標準ライブラリ禁止って組み込みだったらそれなりにあることだと思ってたけど？

808:デフォルトの名無しさん
07/09/22 18:54:41
>「Delphiを使うかもしれないからC++のライブラリに依存してはならない」
コピペ改変コーディングしか出来ない奴が大半と見た

809:713
07/09/22 19:04:23
>>805
>テンプレートは使えるんだろうか。
テンプレートは上司が知らないので使いすぎると
また禁止になる可能性があると思います。

>というかなぜC++を使っているんだ。
>もういっそのこと全部Delphiでいいだろ。
これは私の推測ですが、

C言語は知っている
↓
Windowsの時代になりGUIのソフトを作成しなければならない
↓
Visual C++は難しいのでDelphiを使う
↓
C++Builderが発売
↓
慣れたC言語を使いたくてC++Builderを使う

と、こんな感じではないかと・・・。

>>807
私の会社では組み込みのプログラミングはありません。

810:デフォルトの名無しさん
07/09/22 19:16:04
っていうか組み込みの仕事だっていうから、コンパイラをさらしてくれないと何とも言えない。

上司や同僚が親切に「（このコンパイラでは）～の方が速くてコンパクトなコードが出る」と
教えてくれてるのかもしれないし。

811:デフォルトの名無しさん
07/09/22 19:37:16
その上司は各種ライブラリのリファレンスもconstウゼーな、
とか言いながら読むんだろうな。

812:デフォルトの名無しさん
07/09/22 19:38:53
だんだん「ム」ではなく「マ」の話題になってきたような気がする。

813:デフォルトの名無しさん
07/09/22 19:44:27
あとでっかい機能といえば例外処理と名前空間だろうか。
Delphi移植論でいけば例外処理はありとなってほしいところだが。

814:デフォルトの名無しさん
07/09/22 19:45:11
コーディング規約やその他のコーディングスタイルは、本来プロジェクトごとに決めるべき。
企業としての品質を維持するために共通ルールを設けるのは構わないが、ある程度の幅を持たせておき
その幅をプロジェクトごとにきめる形にするのがいい。

設計段階でのレビュー作業や、コードレビュー、プロジェクト完了時点での反省会議などをきちんとやれる会社でさえ、
コーディングルールは決まっていないことが多いから仕方ないことなのかも知れないが。

815:デフォルトの名無しさん
07/09/22 19:48:48
その辺のC++の「新機能」って初出はARMだっけか？
1990年だからもう20年近く前になるんだが

816:713
07/09/22 20:27:49
>>810
え？>>810は私に対するレスですか？
私はパソコンで使用するソフトを作成しているので
組み込みの仕事では無いと思います。
ついでにコンパイラはC++Builderのそれです。

>>813
名前空間は使っているところをまだ見られていないと思うので分かりません。
上司が名前空間という機能を知っているかどうかも分かりません。
例外処理は勉強不足で私自身分かっていないのでなんともいえません。すみません。

>>814
私の会社はプログラマが少ないせいなのか、決まったルールは無いようです。
入社して間もない私が今まで誰もしなかった書き方をしていたので
上司は他の人も読めるようにしたかったのではないでしょうか。
また、コードレビューや反省会議といったものは特に無いようです。

817:デフォルトの名無しさん
07/09/22 21:01:47
レビューもなく環境的な制限もないのにあれ使うなこれ使うなとか言われるのはやだな。

818:デフォルトの名無しさん
07/09/22 21:05:08
完全に言語／技術の話じゃなくて「いかに俺の会社の上司がドキュソか」っつー
話になってるな
そういうのはマ板でやってくれんか

819:デフォルトの名無しさん
07/09/22 21:29:57
const_<int> i(0);

820:デフォルトの名無しさん
07/09/22 21:45:55
なんかこの流れキモくね？

821:713
07/09/22 21:59:46
納期に間に合わないので明日は出勤します。

>>818 >>820
すみません。

>>819
それはconstのかわりにということですか・・・。
見つかるとそれも禁止になると思います。

スレ違いになってきたようなのでこの話はこのへんで止めます。

レスして下さった皆様、今日はありがとうございました。

822:デフォルトの名無しさん
07/09/22 22:23:46
std::ostreamに空白文字 ' ' をn個出力する処理の、素敵な、シンプルで高速な書き方を教えてください。

823:デフォルトの名無しさん
07/09/22 22:25:24
for(int i=0;i<n;i++) { os << ' '; }

824:デフォルトの名無しさん
07/09/22 22:27:55
>823
現状はそれですが、プロファイラが遅いと言っています。

825:デフォルトの名無しさん
07/09/22 22:28:04
こうかな
cout << setw(n) << ' ';

826:デフォルトの名無しさん
07/09/22 22:32:57
>825
ｿﾚﾀﾞ
どうもありがとうございました。

827:デフォルトの名無しさん
07/09/22 23:20:47
emacsでc++開発をするときの環境に関するサイトってないでしょうか？

meta-x なんちゃら

でDebugからclass構造のブラウズ、リファクタリングまで
なんでもできちゃう環境とか作れるのでしょうか？

elispは最近おぼえました

828:デフォルトの名無しさん
07/09/23 00:28:45
Cの基本的な知識はありますがC++を独学するとしたらお薦めの本はありますか?

829:デフォルトの名無しさん
07/09/23 00:32:30
Cの本は独習C、新・詳説C言語です。

830:デフォルトの名無しさん
07/09/23 00:33:30
じゃあ独習C++でいいんじゃないの？

831:デフォルトの名無しさん
07/09/23 00:50:31
独習C++は勉強になるけどつまらないっていう評判が多いけど、個人的には面白かったよ。
愛だね。

832:デフォルトの名無しさん
07/09/23 01:37:41
独習にします。ありがとうございます。

833:デフォルトの名無しさん
07/09/23 01:39:20
そのあとでいいから
Effective C++, Effective STL, Exceptional C++, Exceptional C++ Style
くらいは読んでね。同僚の迷惑にならんよう。

834:デフォルトの名無しさん
07/09/23 01:43:32
今から独習C++なんて読み始めてる人なら

Effective C++, Effective STL, Exceptional C++, Exceptional C++ Style

を読めるようになるまで５年はかかる

835:デフォルトの名無しさん
07/09/23 01:45:46
>>833-834
ｵﾏｲﾗなんでそんな意地悪なことばっか言うわけ？

836:デフォルトの名無しさん
07/09/23 01:46:46
平均的なプログラマってそんなもんですかね。安心するなぁ。

837:デフォルトの名無しさん
07/09/23 01:48:24
なんで意地悪？？？？？

3番めのはちょっと難しいかなとは思うけど、読まないとダメダメなコード
書いちゃうのがC++なんだから読むしかないべ。

新入社員に読ませてるけど、あんまり脱落しないよ？

838:デフォルトの名無しさん
07/09/23 01:52:49
つーか、何で書籍スレでやらないの？

839:デフォルトの名無しさん
07/09/23 01:53:41
ｲｴﾃﾙ

840:デフォルトの名無しさん
07/09/23 02:12:25
C++を本当にC++らしく書ける奴なんてみたことないぞ
日本人だとｴﾋﾟｽがちょっと書けるかな？
程度

841:デフォルトの名無しさん
07/09/23 02:14:49
ﾌﾟｯ

842:デフォルトの名無しさん
07/09/23 02:25:07

上司「俺の知ってるCの一部の機能だけで書け」
ってことか・・・