C++相談室 part135
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part134
http://mevius.5ch.net/test/read.cgi/tech/1516406742/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>576
趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。
もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。 >>576
コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。 C++のスレで言うのもどうかとは思うが、
初心者が覚えるのに相応しい言語はJavaじゃないかなと思う
アルゴリズムだけを学びたいなら、C言語が良いかもしれない
他の人の意見も聞いてね >>577
そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい >>579
>>580
参考になりました。
ありがとうございました。 >>578
アセンブラかVerilog/VHDLあたりじゃね？
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ Cはアルゴリズム勉強にはあまり向いてないと思う
以前各言語向けのアルゴリズム辞典みたいのを見比べてみたけど
Cのだけ異質な感じ
forのカウントいじってあったりして勉強しにくい
少なくともオブジェクト指向入れた言語じゃないと後で生かしにくい オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
下層レイヤを上手く隠せないから段階的に積み上げていくというのがやり難い。
学習段階では上から下まで見えているって方が分かりやすいということはあるかもしれないので、
どちらが良いかというのは考え方とか好みにもよるので一概には言えないと思う。 アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
オブジェクト指向については、別の機会に学べば良い そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが >>585 に書いた「段階的に積み上げていく」の意図ね。
かといってそれで全体像が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。
やりやすいと思った方でやるしかしょうがないんじゃね。 C言語で書かれたアルゴリズムが読み解けるようでないと
後で困るだろう C以外だとリストのシャッフルはshuffleだけで済ませられる
Cだとshuffleの中身を書かないといけない
C以外だと「Combination()を使おう」
Cだと「Combination()を実装しよう」
くらいの差がある
アルゴリズムがどこまで指すのか分らないが、楽しいことから先にやればいいんじゃねえの、ということで、C以外から アルゴリズムを学習するって、その実装の中身を理解することだろう 個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。 みなさん、ありがとうございます。
セジウィックとウエインのアルゴリズムの本に載っているのは、おそらく
ジェネリクスを使っているので一般性もあって、かつ効率もいいプログラム
だと思います。
ライブラリのようなクオリティーでプログラムを作るというのが理想です。 アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
やっと C++ で書かれた日本語の本が最近出版されましたね。
セジウィックとウエインの本よりももっと初歩的な本のようですが。
データ構造とアルゴリズム (電子情報通信レクチャーシリーズ B-8) 単行本 ? 2018/2/1
岩沼 宏治 (著), 美濃 英俊 (著), 鍋島 英知 (著), アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
ただ環境構築なんかの障壁もあるだろうし最終的にCは触るだろうけどアルゴリズム以外の所で詰まりにくいという意味でC#を推してみる >>594
勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた C#はLinqが便利すぎてお勉強用としてはどうなんだろうなぁ
何やるかによるけど ああ勘違いしていた
アルゴリズムを勉強したいのではなく
>>もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
>>アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
なのね
であれば >>573 氏が現役バリバリな時の主流の言語なんて今からじゃ予想つかないだろうし、実務なら最も適した言語が使われるだけだからC++をそのままやり続ければいいと思う
コンピュータサイエンス自体死ぬほど広範囲な学問で、実務のプログラミングとの間にもやっぱり開きがあって万能な言語なんて無いよ
敢えて言うなら物理と数学、これだけは裏切らない >>585
そこがいいんだよ
隠蔽されたことを忘れたフリをし
本当は忘れていないということの練習に向いている
忘れたフリが綺麗なコードの練習
本当は忘れていないことが性能評価につながる
両立した技能の練習に向いているということだ >>571
>>572
そもそもROMの反語はRAMじゃねぇし(SAMってのもある)
SHARCだとDMのサイズは0でも、PMさえあれば動く
で、PMの事隠してマウンティングすればお前らは受け入れるのか？ 今はどうか知らないけどcは標準でvectorやlistやmapがないから
そこから始めないといけないのでめんどくさい
アルゴリズム辞典見たら配列をdefineされたNやMで確保してた
ライブラリとして使う気ゼロ >>600
世の中のほとんどのチープなワンチップマイコンはROM/RAM構成なんだよ
世の中を知ってたら>>557に対して>>566なんて考えは出ないはずだ >>601
Cはチープな環境やOS関連で使われるくらいだからなあ
コストのデカイlistやmapなんて無くて当然
必要になったら必要最低限の機能で自力で作る世界 >>603
コスト云々よりジェネリクスが無いから汎用コンテナを作るのが難しい 数十バイトしかないなら、普通アセンブラで書くだろう >>605
別に難しくない
標準化されてないから広まってないだけで
作ってる人はいっぱいいる >>600
だから何？
いいよ、じゃあSAMもありにしようや
で、スタックの量がCに適するのか適さないのか
おまえさんなりの考えを言ってみな >>611
普通にvoidポインタに置き換えるだけだが。
何が難しいの？ 初期の JAVA もコンテナを使うときにキャストが必須ってアレな仕様だったよな。 昔は仕様がダメで段々改良されていくということがありますが、
それはなぜなのでしょうか？
その当時はハードウェアの性能上そういう仕様にせざるを得なかったというような
理由があるのでしょうか？
それとも単に思慮が足りなかったというだけでしょうか？ >>615
知見が足りなかったというのが最大の理由だと思うけど、
せざるを得なかった場面よりもその程度で充分だったという方が多いと思う。 仕様が固まらないうちに作る時は、それなりの暫定仕様か何らかの制限事項を設けて開発したな 知見が足りなかったなんてのは少数派と思う
シンプルな仕様からだんだんと機能追加で肥大化の方向
ってのがほとんど >>619
C89 からの「関数の引数として構造体が（実体渡しとして)OK」というのは、私には堕落以外のなにものでもないと 昔のC++にあった（今もある）糞の山は、今のモダンな他言語たちへの反面教師として大いに役立った >>613
メモリぶっ壊しやすくなるのは十分問題だと思うが
ライブラリ利用者側の責任で何とかしろってのはリソースの条件が厳しけりゃしょうがないがさもなくば正当化しかねる 独習C++は一通り読んだんだが次に読む本ある？問題集みたいなのとか >>624
私がお勧めしているのは
https://www.amazon.co.jp/dp/4894714221/
https://www.amazon.co.jp/dp/4881357786/
前者は実は難があって、変てこな実装をしている部分もありますが、それを自分で調べて解決すれば、強くなれると思います
後者は STL の解説本です
いずれも C++11 以前で今となっては古いのですが、代わりになるような本がない…
両方とも私は読んでいますので、普通の質問には答えることができます どの言語でも、入門書の次は、Effective 何々 >>625
「なぜ」そうするのか
「なぜ」そうなっているのか
他にどんな選択があったのか
という思考回路の俺には合わない本だ >>623
それは低級言語に求める物じゃない
C/C++は低級言語として数十年間圧倒的なシェアであり続けている
これってすごいことだと思う >>623
データ構造の要素が静的に型が決まろうがそうでなかろうが、必要な要素数のメモリを確保する作業に違いはない。
せいぜい型のサイズを余計に掛け算するくらいだ。
確保するサイズが間違っていれば静的に型が決まろうがメモリ破壊は起きる。
もう少し具体的に示してくれないか？ 静的な型の恩恵がどうたらって
mallocがvoid*を返すのと同じだろ
問題ちゃ問題だがそんなもん怖がるやつぁC使いに向かない >>629
静的なら実行時パフォーマンスには影響しない
>>630
「既に壊しうるのだからちょっとくらい壊せる場所増やしてもいいでしょ」には無条件では同意しかねる
>>631
向いていようがいまいがCの案件はあるわけで, 可能な限り安全にコーディングしたいと思うのは可笑しいか？
で話を戻すと, 汎用コンテナのCでの実装には, 大きく分けてもdefine使った型安全な実装とvoid *を使ったオーバーヘッドあり型安全なし実装が考えられるわけで, まずそれだけでこうして対立し得る
実装上でもいずれもpros/consがあるわけで, そりゃ規格がまとまる道理がないよね, って主張
別に必要最小限の機能で自分で実装することを否定するわけじゃないし, 型安全が絶対だという気もない 高速コンパクトと安全性利便性は相反するものだ
諦めろ >>627
独習の次に Effective C++/Effective Modern C++ は飛躍しすぎではないかな？
ついてこれるのか >>632
> void *を使ったオーバーヘッドあり
とは何？サイズ管理＋アドレスの計算のこと？
だったらC++の汎用コンテナでも同じ事を内部でやっているし、オーバーヘッドはないが。
見た目でしか分からない人はCに向いていないぞ。
というか、型安全が欲しければC++を、
そんなん要らんから小さくて早いコードを、というのならCを、ってだけだろ。
その分自分で管理する項目が増えるだけの話で。
選択肢はユーザー側に与えられているのだから、それ以上は要らんだろ。 >>632
できねえこと言ったってしゃーないだろ
Cにはテンプレートがない
諦めるしかない とりあえずスクリプト言語やC#で書く→速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
これが正解
どれかにこだわって対立させて排他するのはアホ >>638
同意。
若い奴が統一言語「○○だけ勉強すれば全ておｋ」を求めるのは自然だが、
そうなっていないのは理由があって、つまりは手抜きと実行効率（速度）の兼ね合いだ。
一時期Cが統一言語だったが、それは他言語がゴミだったから（対抗馬がLisp)であって、
C++で再統一されることはないよ。特に今のC++では。 オーバーヘッドについては撤回
>>636-639
だから基本的にそういう役割分担について否定しているわけじゃない
Cで汎用コンテナが標準化されることはないだろうっていうのが元々の主張 >>638
Cで書けることは基本C++で書ける
C++で最適化出来ない所はCでも無理
アセンブラしかない >>636
CやC++に関わらず専用なコードは汎用に比べて高速コンパクトに出来る事がある
つまり、
void*で作って全てのコンテナサイズ(型)同一コードよりも型ごとにコードを作る方が速いことがある
C++のコンテナは全て専用コードなので
コードの肥大化と引き換えに微妙に速いかもしれない
コードの肥大化によってキャッシュミスして遅い可能性もあるけど >>638
> 速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
asmはいいとしてC++→Cでもっと速くなるケースなんてあるのか？ >>632
>すでに壊してるのだから
一体どこからそんな主張を読み取ったんだ？
勝手に人の主張を捏造せずに、ちゃんと質問に答えてくれないか？
あと、void*使わなくても、生成時に型サイズを受け取る方法もある。
汎用コンテナ作るのにdefineで型定義なんてするわけないだろう。 >>642
qsortやbsearchとかそうだよな
C++のsortやbinary_searchには絶対に敵わない >>644
FF外から失礼します
「すでに壊してるのだから」とはどこにも書いてないと思うのですが
なぜあなたこそ勝手に人の主張を捏造しているのでしょうか？
FF外から失礼しました >>646
面倒なやつだな。
「既に壊しうるのだから」
これでいいか？ 汎用バイナリ < 汎用コード専用バイナリ < 専用コード
速度的にはこう
速度が非常に重要であれば
CだろうがC++だろうが専用コードを書くのが一番 >>643
間接参照を抜ける場合とかだろ。
逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
実際にC++はCより遅いってのは事実だし。
>>645
お前が値配列と参照配列の区別が付いてないだけだろ。 >>653
アンカーミスったか？
qsortとstd::sortはどちらも値であろうが参照（ポインタ）であろうが使えるぞ >>653
> 間接参照を抜ける場合とかだろ。
それC++のまま書き換えればいいだけ
> 逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
そんな主張はしてない
> 実際にC++はCより遅いってのは事実だし。
だからどんなケースなんだよ
STLとか使いまくって遅いとかなら使わないように書き換えればいいだけだろ 厳密に言うと
C11の可変長配列はC++には無い
C++では例外処理を実現するために関数コールに微妙なオーバーヘッドがある場合がある
って感じでCの方が有利な事がある
どちらもガシガシに最適化した場合の話 x86-32
例外処理を有効にすると
関数コールに微妙なオーバーヘッドが加わる
x86-64
例外処理の為のオーバーヘッドは無い
その代わり例外発生時の処理は非常に遅い
Cの可変長配列のような、スタックに可変長サイズを確保する手段はC++には無い
当然ダイナミックなメモリアロケートよりはスタックに確保した方が速い
ただし実際にはあまり使われていないと思われる >>654
ミスってないぞ。
>>656
Cの場合は抽象化してくれないんだから、関数を直接呼ぶしかないんだよ。
だから動的解決をしている場合はC++の方が遅く、静的解決の場合は同速になる。
CのほうがC++より遅いケース出してみろ。ないから。
C++は機能的にはCをラップしてるんだよ。
例外とか、クラスの動的解決とか、スマポ（ｷﾘｯとか。その分管理が楽だが、速度は遅くなる。
Cの場合はC++のラッパ抜きで直接呼ぶことになるから、その分速い。それだけ。 >>658
> x86-64
> 例外処理の為のオーバーヘッドは無い
> その代わり例外発生時の処理は非常に遅い
これマジ？
煽りじゃなくて仕組みを知りたいから、キーワードかURLくれ。
こちらでググって確認する。 自分でディスアセンブルしたり
バイナリ比較したり実測してわかったことで
仕組みがまとめて書いてあるような所は知らない >>656
> だからどんなケースなんだよ
探してやったぞ。
> 実験によれば 6-13% の実行時間が単なる関数のディスパッチに用いられ、オーバーヘッドは場合によって 50% に達する[1]。
> https://ja.wikipedia.org/wiki/%E4%BB%AE%E6%83%B3%E9%96%A2%E6%95%B0%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB
C++は動的な型の変更はなしなので、コンパイル時に対象関数は確定するだろ。それが仮想関数であってもね。
だからvtblを用いた実装自体がコンパイラの単純さを採って、実行速度を捨ててる。
JavaScriptみたいに、実行時に型を変更してしまえる言語ではないのだから、
型毎にテーブルを持つこと自体が冗長で、
テンプレートみたいに、仮想関数が上書きされた毎時点で平面的に展開し、直接それを呼ぶ実装も出来るんだよ。
勿論オブジェクトコードは膨らむが。
Cの場合は、どちらでやるにしても「自前で」実装するしかない。だから当然、選べる。
C++の場合は、選べないでしょ。一般的にvtblの実装になる。（コンパイラの都合だが） C/C++で基本同じ結果となるコードが書ける
同じ結果となるコードを書けば結果は同じ
ってだけで
当然違う結果となるコードを比べれば違う結果になる
当たり前 >>661
ちなみに計測したときのOSは何？
なおその兆候が正しいなら、x64の場合はハードウェアで対応していることになる。 クラス関数はthisを第一パラメータとして渡してるだけで、これは構造体でも同じことが出来る
virtual関数は関数ポインタテーブルへのポインタを持ってるだけ
同じことは当然Cの構造体でも出来る
テンプレートは型ごとにコードを書くのと同じ >>663
だから、いわゆるC++の機能を使ったら、管理が楽になる分だけ遅くなる、というだけ。
C++の機能を全く使わないコードはCと言うんだよ。
だから、C++はCより常に遅い。それだけ。 >>664
そういえば、
例外発生時のスタックにあるリターンアドレスを検索するとかどこかでみたような
どこかに仕組みが書いてあった気がしてきた >>665
> virtual関数は関数ポインタテーブルへのポインタを持ってるだけ
> 同じことは当然Cの構造体でも出来る
Cでやる場合は、関数ポインタを引数で渡すことも出来るんだよ。
(勿論C++でも出来るが、クラスを使う意味が無くなるから普通はやらない）
この場合、間接参照が抜ける分だけ速くなる。
（実際はメモリアクセス1個よりはキャッシュを壊すことの影響の方が大きいとは思うが） C++独自の機能を使うとCより常に遅い？
それは嘘だな >>669
C++にだけ独自の縛りを設けてCのが速い？
強引に主張を通したいのはわかるが
そろそろ痛いぞおまえ >>667
それはスタックウォークという、従来の例外実装方法だ。
君の場合なら、x86がそれになってる。
>>670
ならC++の機能を使って、Cよりも速くなるケースを挙げてみろ。
ないから。 もとは>>638だ
C++で最適化に行き詰まった時に
わざわざコンパイラをCに変えて最適化する事なんてないから
Cっぽい記述とかアセンブラっぽい記述とかなら
そりゃいくらでも >>672 前半
自分で調べろ
>>672 後半
ええと、...
「C++独自の機能を使うとCより常に遅い」
の否定はわかるかな？ >>658って単に32bitプログラムを64bit CPUで走らせてオーバーヘッドがーって言ってるんじゃね？ >>674
君は理解できてないようだから、定義を確認しておこう。
ただしこれは一般的な解釈であり、おそらくこのスレの住民は共有してる。
・テンプレート、クラス構文、スマポ等、
C++コンパイラではないと通らない機能を使ったコードを、C++のコードという。
・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。
> 一般に、カーネルモジュールをC++で設計するやつは、以下のいずれかだ。
>
> (a) 好んで厄介事に巻き込まれたい者
> (b) 自分が書いているのは実はCだと気がついていないC++バカ
> (c) 授業でそういう課題を与えられた者
>
> (d)を付け加えるなら好きにしてくれ。
>
> Linus
> https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html
君は多分(b)だね。
今の話題はC++のコードとCのコードの速度比較ということでよろしく。
>>673
> C++で最適化に行き詰まった時に
> わざわざコンパイラをCに変えて最適化する事なんてないから
そんな話は誰もしてない。
勿論その場合はCのコードに変更し、C++コンパイラを使うに決まっている。
じゃないと他の部分が通らないだろ。
君の定義は、C++コンパイラを使っていればどういう書き方であってC++ということだったのか。
なら話は噛み合わないさ。 ■ このスレッドは過去ログ倉庫に格納されています
