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 >>721
大抵のプロセッサの浮動小数点ユニットにはオーバーフローしたら例外を発生させる機能がある
それを有効にしてるかどうかは環境による
あとC言語の話で割込ハンドラーとか言ってる>>717は単なる知ったかなのでスルーした方がいい >>726
＞大抵のプロセッサの浮動小数点ユニットには
「浮動小数点ユニット」なんですね、ここで確認しておきます。
＞オーバーフローしたら例外を発生させる
演算結果が ±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね
>>726
＞C言語の話で割込ハンドラー
lsi-c ver3, MS-C ver6 あたりでは、そういうのもあったと記憶してます、 matherr() ですね
だから >>717 はあながち間違いとはいいきれない面もあります >>725
世間では「どちらのコンパイラを使うか」ではなく、
「どちらのスタイルで書いているか」でCとC++を区別してるんだよ。 >>727
> 演算結果が ±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね
それ反対、オーバーフローしたら結果をinfにしてるだけ >>729
inf も NaN も浮動小数点表現の中にあるので「オーバーフロー」と呼びにくい、と思っています、まあ人それぞれ >>730
だから誰もinfがオーバーフローとは言ってないだろ
オーバーフローしたらそれっぽい値としてinfを入れてるだけ >>728
それなら
Cスタイル、C++スタイル
と言えば良い
CかC++かは当然コンパイラで決まる
C++は元々上位互換を目標に作られた物だ >>732
> C++は元々上位互換を目標に作られた物だ
そうだ。そしてだからこそ、スタイルで区別されるんだよ。
元々C++はCの完全上位互換だった。
だから君らの定義なら、C++が登場したときから全てのCは消滅し、C++になっているはずだろ。
実際はそうじゃない。
「○○のコードはCで書かれています」
「○○のコードはC++で書かれています」というのは、
世間では俺の言った定義(>>676)で使われてる。
その後、CとC++が仕様的に分離してしまったから、
今現在はCコンパイラで通るコードがC++コンパイラで通らないケースが存在する。
だから今は明確に「どちらのコンパイラを使うか」を想定しておく必要があるが、
それもコーナーケースで、
大半の「Cのコード」はC++コンパイラでもそのまま通る。
お前らがC++信者でC++の範囲を広く取りたいのは分かるが、世間はそうじゃない。
C++がCの仕様を全て取り込んだら、
お前らにとってはCは消滅、全てはC++になり、お前らは幸せになれるだろうさ。
ただ、その後も世間はCとC++を引き続き区別するだろうよ。 お前用語の定義の説明とかどうでもいい
スタイルの意味ならスタイルと書け >>734
それは嘘だなぁ
extern "C"が無いとCライクに見えるオブジェクトを吐かない事が常となっているC++(コンパイラ)について、いくらpure Cライクなコードを書いてもpure Cでないextern "C"を書かないとCライクに見えるオブジェクトは吐けないってそれはもうC++でしょう
他の内容にも誤りがあって君の世間ではCライクなコードであればCで書いたと宣言していいらしいけど、少しでも世間のOSSのコードを見て回れば良いよ
Cで書かれているのはCだから お前らが誤解したままでいるのはお前らの自由だが、
お前らの定義だと、CとObjective-Cを区別できないだろ。
あれはCの完全上位互換で、Cコードそのまま食えるらしいからね。
お前らも少し考えれば自分で矛盾に気づけるはずだが。 >>734
それは言い過ぎでしょ。
流石にそれは、世間を知らなすぎ、と言われても仕方ない意見にみえてきたなあ。。。 ならもうちょっと分かりやすい説明をしてやる。
>>677-678について、お前らの定義では『コード』について議論できないだろ。
俺の定義では、677は「Ｃのコード」で、678は「C++のコード」だ。コンパイラに依らない。
お前らの定義では、678は明確に「C++のコード」だが、677については、
「Cコンパイラを通した場合、677はCのコード」
「C++コンパイラを通した場合、677はC++のコード」
になってしまうだろ。
それだと、CとC++の『コード』の速度比較自体が定義できないだろ。
677をCコンパイラを通した場合とC++コンパイラを通した場合の速度差は、
「コードの差」ではなく、「コンパイラの差」なんだよ。
当たり前だろ。
というか、C++erもここまでレベルが落ちたのか。世も末だな。 std::filesystemで片方のスレッドでファイルを出力し
もう片方のスレッドでファイルが存在していたら読み込むというプログラムを書いた場合
出力中に存在すると判定されて読み込んでしまいそうですが、
そんなことないでしょうか？
もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
判定する以外の方法はあるでしょうか？ >>739
お前が考えた定義とかどうでも良いって言ってるの というか何でお前らそんなに必死なんだ？
俺の言ってる定義が世間一般の定義だよ。
そうじゃなきゃ『コード』の善し悪しの議論が出来ないだろ。自明だと思うが。
繰り返すが、C++がCよりも遅いのは事実で、それもググレばいくらでも出てくるだろ。
ただこれはC++そのものよりもオブジェクト指向の弊害だが。
http://chrismdp.com/2015/04/how-i-doubled-the-speed-of-my-game-by-giving-up-on-c-plus-plus/
https://www.quora.com/Why-is-object-oriented-programming-OOP-slower-than-procedural
逆に言えば、C++の機能をふんだんに使ったとして、Javaに対する速度優位がどれだけあると思ってるの？
C++で世界が再統一されることは、今のC++の仕様/方向性ではあり得ない。C++ではCを殺しきれない。
だからRustが生まれた。
>>711の表を信じるなら、RustはCの代替としてはC++以上に上手く行ってる。 お前の定義じゃないと議論が出来ないのは
おまえがアホだから 面白くていいじゃないですかぁ…
ここで linus メールをコピペ（省略） >>742
面白い表ですね
つい C# とか lisp の立ち位置を確認してしまった… >>739
だからお前のオレオレ定義なんてどうでもいい
そもそも>>638みたいな話でC++→Cで全面書き換えなんてする奴はいないだろ
まともなプログラマーならボトルネックを見つけてその部分を書き換える
例えば１つのファイルに関数f1()とf2()があってf2()がボトルネックだからC++からCの範囲で動くようなコードに書き換えたとする
お前はそのファイルの記述言語は何て言うんだよ？
関数毎に記述言語が違うとか言い出すのかよ w >>740
> 出力中に存在すると判定されて読み込んでしまいそうですが、
> そんなことないでしょうか？
そりゃ普通にそんなことあるだろ
> もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
> 判定する以外の方法はあるでしょうか？
そもそも何をしたいのよ？
出力完了してから読みたいだけなら出力完了してから読み込む側のスレッド起動するとかする方法もあるだろうし >>749
お前がIDコロコロしてまでも定義にこだわる理由が分からん。
お前の定義なら、仮に全面インラインアセンブラで記述してあっても、
Cコンパイラを通したらそれは「Cのコード」であり、
C++コンパイラを通したらそれは「C++のコード」になり、
Objective-Cコンパイラを通したらそれは「Objective-Cのコード」と言うんだろ。
そんな定義の奴はいない。それは「アセンブラ」と言うんだよ。
ただこの定義はもういい。
君は間違いを認めないようだし、仮に俺が間違っていたとしても、
お互いの認識のズレは確認できたのだからそれでいいだろ。
そして>>638は最初からそう言っているだけだ。
お前は「コンパイル単位」でしか言語を規定できないからおかしな事になっている。
世間は「コード単位」でも言語を規定する。だから、お前が
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換え
と言うのを、世間では「f2()をCコードに書き換え」と言うんだよ。
仮にお前の定義が正しくても、これを日常的にやるようなら、じきに略されて
俺（世間）の言い方に落ち着くのも分かるだろ。
だから>>638は最初から、お前の言葉で言う、
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換える
「f2()がボトルネックだからC++からアセンブラの範囲で動くようなコードに書き換える」事を
> もっと速くしたい所をCやasmで書く
と表現している。元々「コンパイル」単位ではなく、「コード」単位なんだよ。
その「コード」について議論するのに、「コンパイル」単位を持ち出すのはおかしいだろ。
「速くしたい『所』」ってのは一部限定って事を明示してるだろ。
お前はどうしても認めないようだが。
お前は根本的に考え方がおかしい。それではまともな議論が成立しないだろ。
議論している粒度に合わせた言葉を使え。 >>751
> ただこの定義はもういい。
> 君は間違いを認めないようだし、仮に俺が間違っていたとしても、
> お互いの認識のズレは確認できたのだからそれでいいだろ。
いきなり弱気になってて笑うわ w 自己解決しました。
仮の名前でファイルを書き出してからリネームすれば書き込み中か書き込み済みか
判定する処理をなくせるみたいでした。 >>751
コンパイラが変わらない単なる最適化で
C++からCにする
なんて言わないから普通
少なくともエンジニアの会話では無い
簡単にいう場合は「最適化」「チューニング」だし
詳しくいう場合は中身を具体的に言う
頭の悪い文系を騙すのには使えるのかもしれないけど C言語風なコード
と
C言語のコード
全く意味が違う 「C++で書く」→カジュアルにSTLとか使って読みやすく書く
「Cやasmで書く」→キャッシュやSIMDとか低級に考慮してガリガリ最適化する
くらいの軽い気持ちで書いただけなのに紛糾しすぎててワイ将困惑 >>756
おまえさんの頭がC++03のまま更新が止まってしまっていることはわかった C++xx
この末尾のへんなナンバリングが施されるようになったのっていつ頃から？ >>762
元々はC++09を狙ってたらしいから2008年頃じゃね？ >>759
STLが03から入ったと思ってんのか
あと
＞Cコンパイラってポインタ周りは最適化をかけないから、多分、
＞速度差はコンパイラ起因であって
こんなこと言ってる時点でID:PbE4ojLD0の話は聞くに値しない >>766
あの流れからどうやってSTLが03からという話になったんだ？ >>756
馬鹿につき合ってすまんかった。
少なくとも俺とLinusは君と同じ定義で使ってるよ。俺の認識では世間もそう。
俺はこれでこれまで話が通じなかったことはないから。
おそらくはCをやらずにC++だけやってる世代と、
必ずCをやったうえでC++に進んだ世代の違いだ。
ゆとりだけで閉じてる世界では、彼らの主張する定義なのかもしれん。
ただまあ、話を聞いてる限り、こいつらは色々と無知だし、無知なことに無自覚だね。
まあもういいが。
自分が知らないだけのことをすべて間違いだと断定しているようでは上達しない。
C++erもここまでゆとり化が進んだのは残念だ。 本当に通じていたのかな？
いわゆるフツーの人達は、めんどくさいから適当に話し合わせてテキトーに打ち切るものだが… ついでだからもう少し書いておいてやるよ。
ゆとりC++erが「C++は速い」ということにしたがるのは、C++「言語」以下の解像度がないからだ。
「C++コンパイラさえ使えばおｋ」になってくれてないと困るからこそ、そこに異常にこだわる。
(他言語でも同様に、低位実装を直感的に推測できない馬鹿はこの傾向がある）
お前らは>>722-723の結果、同じデータ構造で同じアルゴリズムを適用した物に対し、
速度差が出た場合にそれを「言語の差」と言い張るようだが、
それは明確な間違いだ。ただの不勉強でしかない。
実際、それだとそれ以上の最適化は出来ないだろ。
C出身者なら、必要ならasm書いてチューニングすることも出来る。
現在C++は失敗しつつある。
それはRustを見ても明らかだ。以下ページを見てみろ。
https://imoz.jp/note/rust-functions.html
スマポ(ｷﾘｯな連中にとってはC++よりもRustの方が明らかにいい言語だろ。（後発なので当たり前だが）
C++だけにすがるのは止めとけ。
もうそういう時代じゃないし、C++はそれを満たせる言語ではない。 別にC++とCの宗教論争に加わるつもりはないが、
お前qsortがstd::sortより遅くなりがちな理由わかってないだろ
アセンブラ使わんでも自分で書きゃCでも同等の速度は出る
（というかVCの最適化にハンドアセンブルで本当に勝てるんか？こいつ）
＞CよりもC++の方が速くなるコードの方があり得ないと思うが。
＞CのほうがC++より遅いケース出してみろ。ないから。
調べもせずにこんな決めつけを書く低レベルさ以前に
これをC++のスレで書くお前はどう見てもただの荒らしだから。 >>771
お前は根本的に勘違いしている。
出発点は自前のコードでもいいが、逆アセンブル結果でもいいんだから、
改善できなくとも、遅くなることはあり得ない。
アセンブラを読めない君らでは、これは無理だ。
そして、遅くなる可能性の方が高いからやらないってのは、
馬鹿な君らなりの対処法としては正しい。
まあ、C++スレではC++マンセーしないと荒らしだ、ってのは理解した。
C++erがそこまで落ちぶれたのは残念だが、俺は去るよ。 それぞれの言語の良くある使い方であれば
Cの方が速いコードもC++の方が速いコードも
どちらも存在する
同じ処理を同じように書けば普通は同じ速度
(ただし、一部細かい例外あり) 一般的な使い方では
C++の方が開発効率が高く
Cの方がバイナリの性能が高い事が多い
(もちろん逆になる要素もある) >>772
以前ここに書いたこともあるけど、最近ET＋simd（SSE、NEONのイントリンシック）で
ゲーム用の自前の線形代数ライブラリとか作ったんで
＞アセンブラを読めない君ら
残念ながらこれは当てはまらないよｗ
どれだけ逆アセ読んで比較したか・・・・
＞C++マンセーしないと
お前が”正しい批判をしてれば”荒れてないんだよ
ついでに言えば、
＞「C++で書く」→カジュアルにSTLとか
STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
「流行に流されて自分で考えることを放棄する」という、かつてJavaの流行に荒らされた時代と
同じ愚を犯してるな、とは思うけどねぇ
C++er憎し、では色々と話がおかしくなるよ 同じ処理を同じ動作で記述出来ない例
Cの可変長配列
C++の例外処理 もうアホらしくなって途中離脱したけど
例えば関数内のループで使ってるstd::unique_ptr が遅いからその部分だけ生ポインタに書き換えたら ID:tSRcUD9w0 は何言語で書いたって言うんだろ？
って言うのはちょっと気にはなる
まあまた明後日の長文書くだけだと思うけど w >>775
> どれだけ逆アセ読んで比較したか・・・・
ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
それでその言い方には矛盾を感じるけどね。
> STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
その発言は俺ではないが、
基本的には抽象度を上げるのは簡単にプログラミングする為であって、
「カジュアル」という表現は妥当だ。
Cみたいに全部手でゴリゴリ書く意味なんて無い。
速度が問題ない部分は出来るだけ手抜きすべきだ。STLがそれに適しているのなら使えばいい。
ただ、「STL使わなくてもどうとでもなる奴が手抜きでSTLを使う」のと、
「STLを使わないと何も出来ない連中がSTLを使う」のは全然意味が違う。
とはいえ、俺は後者が前者になるべきだとは思ってない。
ただ、後者ならC++ではなくJavaやC#を使った方が妥当だとは思うが。
君が見落としているのは、STLをカジュアルと呼ぶ連中は、
基本的に、STLを使わずに最速な実装が出来るものの、面倒なので、
「手抜き」を「カジュアル」と言い換えてごまかしているだけだということだ。
連中は君みたいにSTLが無いと何も出来ない馬鹿ではないんだよ。
> C++er憎し、では色々と話がおかしくなるよ
これは違うぞ。俺は無知なくせにデタラメを言い張るゆとりは死ねと思っているだけだ。
ただし、お前が無知のままで死ぬ権利は尊重するので、
有用な情報は書かないようにするが。 >>772
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。 >>780
> ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
爺いは早めに滅びればいいのに constexpr+UCS=ニューパラダイムのはずだったんだがなぁ。
コンパイルタイムは夢がある。 昔はライブラリもそんなに充実してなかったしアルゴリズム事典とか読み漁りながら色々自作してやってたけどね
しかしまぁ便利な時代になったもんだ
Ｃ言語だと型が変わるだけで使い物にならなくなっていたものが大半だったけど
型に囚われないSTLライブラリは本当に有能だよ
型に囚われない部分は全部インラインになっちゃうけどね 実行可能形式はC++、スクリプトはPython。
これができる大人の選択。 スタイルについての質問なんですけど、Cの文法で書けるならできるだけCで書いたほうがいいのでしょうか
上司のC++のコードがもうほんとゴリゴリのCって感じで、C++でcharの配列も無かろうよと思ったりするんですよ
確かにその方が分かる人は多くなるかもしれないですけど >>792
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 いや別に
C++で問題ない
上司の意図は知らんが
パフォーマンスを考えたコードとか
互換性を考えたコードとか
そういう可能性も
5chの一般的な価値観とは違って
C++っぽいのが良いコードって訳じゃない 逆に若者はコストも考えずに安易に汎用コンテナを使ったりと思うことがある ものによるのじゃん？
メモリイメージを意識するならCスタイルの方がきれいにおさまる。 バグを生む可能性が一切ないならCスタイルのほうがいいに決まってる 最近のC++は、std::vectorが配列に最適化されるのか？ 遅いだろ C++11以降ならstd::array使うけど、覚えることがともかく多い 区間チェックしてくれる配列を簡単に指定できると嬉しいの† 例えば、[ ]を二重に書くと添字チェックしてくれるとか。どうかな。
int a[[10]]; 例外投げるインデクサと投げないインデクサ両方ありますから。 >>802
attributes構文と紛らわしい。 C++のコストの大部分は例外に起因するらしい。
Cでコンパイルできるコードであっても、C++としてコンパイルするとバイナリが肥大化する。
その原因は例外。 x86-32だと割り込み発生時に対応出来るように
関数コールの度にスタックに情報を埋め込む
x86-64はこれが不要
割り込み処理がなければコストはかからない >>813
組み込み開発の株式会社○○みたいなサイトで読んだんだけどな。
なかなかためになる内容だったしブックマークしとくんだった。
見つけたらリンクくれ。 俺の見解では、例外にコストが割かれるなら、それは必要なコストだと思うんだよな。 元記事消えてるっぽいからアーカイブだけど
http://bytepointer.com/resources/pietrek_amd_x64_primer.htm
Windowsの例外機構がx64ではスタックベースからテーブルベースの通過するだけならゼロコストなものに変わった
ただしバイナリサイズは増える >>816
例外を使うならコストがかかるのは当然なんだが、
例外が通過しないかもしれないのにそこかしこで情報を積まないといけないのは良くないってことなんよ。
そんでまあ例外を投げたときだけにコストが生じる方式がいいよねっていう話。 例外が発生しない時のコストなんてゴミみたいなもんだけどな 64ビット化するとサイズが1.5倍になるらしいけどな。 今時コードのサイズなんて問題にならんだろ
その代わりに得るものは大きい 1.5倍って40㎏の可愛い少女が60㎏のオバはんになるってことではないだろか。
さあどっちか選ぶんだ。 どうしても対応し続けないといけない32bitのレガシーデバイスがあるなら頑張って
そうじゃなけりゃもう32bitなんて捨てろ ■ このスレッドは過去ログ倉庫に格納されています
