◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:C++相談室 part135 ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1522495206/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part134
http://2chb.net/r/tech/1516406742/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://2chb.net/r/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
この64ビットが主流になりつつある時代にSTL使うとファイルサイズｶﾞｧとかよく耳にしますが、時代についてこれていない老いぼれの戯言なのでとっとと見限って先に進みましょう
STLつかうと一気に実行ファイルサイズが10倍に?！
>>1 乙だが
さすがに
>>2 がテンプレとかないわ；；
えー、どっちもﾜｼ(
>>1 )が貼り付けたわけじゃないのにー
このRTL使うとファイルサイズが減るとかおもいっきり頭悪い回答した奴とSTLをごっちゃにするテンプレいい加減やめれ
コレ老いぼれが仕掛けているマッチポンプにも見えなくはないしな
原発も飛行機も、自動車も？固定メモリ空間で、確保解放なんて一瞬の手間すら惜しんで全部上書きでしょ（知らんけど）
インターネットにつながってる原発とか、USB接続ができる原発なんてあり得ないから。フロッピーもダメ。ROMカセットならギリギリOK。
EMP対策とか防火対策とか銃器対策もしないといけない。
確実な「保証」が必要だからなぁ。
全部アナログに任せてるから操作間違ってこんなんになっているんやろ
コントロールルームの写真見るとありえんくらい計器とボタンついてるから
マウスで原子炉の制御棒を操作するのか？ 冗談すぎる。
作業員に１人テロリストが混ざっていたとしても、原子炉を暴走させることが出来ないようなシステムにしないといけない。
二人が同時にキースイッチをカチッとオンにすると発射！
原発関係の諜報活動はかなりシビアで、どこかの国では、国家犯罪的なコンピューターウイルスにやられて原発が稼働できなくなったらしい。
16bit時代は、友人にウイルスを集める奴が、居たよな。今では所持だけで犯罪になっちゃったけど。
原発は既に発電原価が他の発電方法よりも割高なんで、やめても良い
>>23 その頃はしょせん個人がいたずら目的で作ってた程度だからな
今の違法なビジネスで作られてるものとは性質が違う
あの頃は、ウイルス対策の概念が浸透してなくて、雑誌の付録にもウイルスが付いていたらしい。MS-DOSとWin9x時代のデジタル発掘には危険が伴う。
ウイルス蔓延に対する答えが、プログラムファイルの保護、ウイルス対策、UAC、SmartScreen、デジタル署名なんだよな。
C++20では、生ポインタが非推奨になるんだよな？
>>28 生ポインタを取り出すstd::to_addressが追加されるんだが
じゃ、勘違い。
リスクオフで世界的に株安なだけでインテルの業績が悪化しているわけではない
>>31 しったか乙
アップルがIntel捨てるからだよ
ん？ノートがARMにでもなるの？ちょっとむりない？
独自CPUだよ
>>34 あいほんはARMベースじゃなかったっけ。自社カスタムしてるけど。
仮にインテルから自社製造に切り替えが本当だったとしても、
これまでのニュース記事
>>32 最近の下げ調子からちょっと戻したところをイースター休暇を狙って仕掛けがあったんだが
個別のちょっとしたニュースの影響なんて掻き消える事態なんだよ
ITだけでもほぼ全部下げてる
https://stocks.finance.yahoo.co.jp/us/ranking/?kd=4& ;tm=d
アップル 前日比-1.10（-0.66%）
マイクロソフト 前日比-2.75（-3.01%）
アマゾン・ドット・コム 前日比-75.35（-5.21%）
IBM -3.36（-2.19%）
グーグル -25.32（-2.45%）
インテル 前日比-3.16（-6.07%）
エヌビディア -10.54（-4.55%）
AMD 前日比-0.52（-5.17%）
クアルコム -1.60（-2.89%）
オラクル -0.74（-1.62%）
フェイスブック -4.40（-2.75%）
ツイッター 前日比-0.97（-3.34%)
ヒューレット・パッカード -0.78（-3.56%）
シスコ・システムズ -1.88（-4.38%）
>>15 >メモリ確保に失敗したら安全な終了シーケンスの実行も難しいだろうし。
これに関しては起動時にまとまったメモリを終了処理用にmalloc()しておくという古典的なテクニックがある
（1 MBのメモリを起動時にmalloc()しておき、ヒープメモリが無くなったらそいつを解放すれば
終了処理に1 MB使える
メイヤーズの本にも載ってる
Java最高！プログラムの未来はJavaにある！面倒なメモリ管理もなくなるし移植でコード書き直す必要もなくなるぞ！
class Manager {
すみません派生クラスのコンストラクタにpublic:つけてませんでした・・・
make_shared使ってるのにnewするなんて
こうしなさい
まずはManagerとかControllerとかいった名前をたやすく使うのをやめるべき。
>>51 なんで？シェアードポインタに限っては内部カウント増えてコピーされるだけだよ。
うにーくはmoveしたいけど、mapには入らないみたい。
違うよ
せっかく make_shared 使うのに明示的に生ポインタを new する人って…
auto変数はスコープ外れたらどうせ破棄されるしmove要らない
いままでC♯使ってたけど、最近つーかおととしくらいからC++使い始めたんだよ。
＞最近つーかおととしくらいからC++使い始めたんだよ。
>>59 自分の環境くらい理解しよう。UnityなのかUnrealなのか。
何を言っているのかわからないし
YAMLをC++で読む簡単な方法はなんですか？
>>62 いや、いま使ってたのはUnityでC♯だったが、
それとは別にVisualC++とFBXSDKでってのをやってみようと思っておとといから始めたわけだよ。
でFBXファイルを読み込んでノードの取得あたりまでは進んだけど、
よく見るとVisualC++のファイル新規作成に３Dシーン（FBX）ってのがあるわけ。
もしやこれ使うとFBXSDKはいらないのかな？とも思ったりしたんだけど、
何しろまだ右も左もわからないし、その３Dシーンにオブジェクトを置くやりからもわからないし、
そのシーンを一応とってつけてつくってみたウインドウズ実行ファイルから呼び出すためのコードの書き方もわからないしで、
こうやってみなさまにご教授を求めた次第ですよ！！
私の認識が正しければ、SDKはSoftware Development Kitだから、実際の実行時に使うライブラリーのことだろうよ。
実行時に動かすなら、SDKにリファレンス(またはドキュメント)があるはずだ。
ドキュメントがないなら、そんなマイナーなフレームワークを使うな、で終わり。
>>68 まだ正式なリファレンスはいろいろ暇がなくて読んでない。
日本語で簡単に解説してあるウェブサイトは見たけど、
取得したFBXファイルのいろんな情報を文字列で表示するプログラムが載ってるだけで、
実際にその３Dオブジェクトを画面に表示する方法が載ってない。日本語のサイトで解説してあるのは、どうもここまでみたいなので、
やはり英語の正式なリファレンスを見ないとダメかな？ｗｗｗ
ゲーム製作板に、くわしく知ってる人が居るかも知れない。
業界へ出るなら、英語アレルギーは克服すべし。自動翻訳が使えれば、詠めるかもしれない。蘭学から学べることは多い。
>>70 ＞ゲーム製作板か、CG板の方がいいかもしれない。
いやゲームはもう作りたくないし、CGも特に興味ない。
実はMakeHumanみたいな３Dキャラ作成ツールがつくりたくてね。
まだ始めたばかりで、そこまでの距離は１００億光年ばかりあるけど・・・
これってやっぱりちゃんとしたプログラム技術板向きの話題だよね？
ゼロから3D作りたいなら、DirectX, OpenGL, Valkanあたりを勉強することになる。
>>76 DirectX便利ですよね
魚眼を再現しようとして挫折しましたが...
iPhoneXでリアルタイムでVtuber作れる時代に素人が3Dモデラー作るのは、技術のムダだろう。
数学のベクトル、射影、非ユークリッド幾何学が理解できるくらいの数学力がないと魚眼レンズはムリだろう。ムリムリ。
物理学的に考えると、魚眼は屈折率の差から発生する現象だから、モデラーの物体に屈折率を設定するだけでいい。
カメラの特性で、レンズの広角が設定できればそれに越したことはないが。
>>80 エピポール幾何はいるでしょうねぇ
AR/MR/VRするなら
>>83 度重なるありがとうございます。
勉強します。とりあえず処理重そうです(・・;)
ゲーム作ろうと思っても大体はゲームエンジン作り始めて途中で飽きてやめる
CGもオブジェクト指向になっているから、撮影スタジオで実際に物体やカメラの位置を決めるのと同じように、シーンを構築すれば、それが映像になる。
ニュースセンターで使われるような、再現ＣＧを自由に作れるようになったら、引っ張りダコだよ。
そうなったら、映像クリエイターになって仕事を請け負って独立できるぞ。プログラマーよりも働き甲斐があるかもしれん。
やたら伸びてると思ったら1人あたりのレス数多すぎだろ(しかも知らんことに口出し過ぎ
C++で用意されているキャストと
static_cast … 無理のない互換性のある変換。
>>92 C スタイルのキャストは dynamic_cast 以外の C++ スタイルキャストを兼ね備えている。
安全なキャストも危険なキャストも見た目にわかんないから、
うっかり危険なキャストをしないようにカテゴリ分けしたやつを使った方がいいなって話。
reinterpret_cast や const_cast がどうしても必要な状況になったら、
それはそのプログラムが悪いデザインだというサインだ。
(デバイスドライバとか OS とかの低水準プログラムだと仕方なく使う機会は多いかもしれないけど)
『プログラミング言語C++』第4版のどこだったかに、
すいませんchar str[1000]に格納されてるこの文字列を、str2[0][]=64 str2[1][]=9 という感じで上手くデータだけ取り出す方法は無いでしょうか
ありがとうございます
>>96 cならsscanfかね
c++ならregexを使うか
そもそもc/c++でやりたい範囲ではないが
>>96 テキストなのなら、一行ずつ読んで、=で半分にしましょう。
んで、""の中の空白以外を全部取り去って、std::mapにでも突っ込みましょう。
>>99 >>100
めっちゃ難しそうな回答きた・・
ちょっと調べて頑張ってみますありがとうございます
danger_cast は言い過ぎとして、unsafe_cast くらいにして欲しかった
>>96 ・str2はポインタの配列、idxはstr2の添字とする
・1文字ずつループして以下を処理
「=」が現れるまでまで読み飛ばす
「 」「"」以外の文字が現れたらstr2[idx++]にその文字へのポインタ格納
・「;」までスキップして¥0に置き換え
>>104 なんかできそう！やってみますありがとうございます！
reinterpret_cast をポインタ以外に使うのはない
c向けのライブラリをc++で開発するときは躊躇なく使うかな>reinterpret_cast
reinterpret_castはゼロオーバーヘッド？
コンパイラさんが解釈かえるだけだから。新しくなにも確保しない。
>>107 の「あとは」以下の用例多いよね。
スレッドのエントリポイントの引数だの libcurl のコールバックの引数だのそんなので
バリアント型が無いために野蛮なキャストが生きながらえるんじゃ
>バリアント型が無いために野蛮なキャストが生きながらえるんじゃ
Windowsとかのメッセージのパラメータなんて、
>>112 > さっさとリフレクションとプロパティーとバリアント型を規格に盛り込みなさい
C+++でも作って勝手にやっててくれ
C++++でしょ
static_castは長いから、ただのcastにしてほしい
デフォルトをstatic_castで解釈しないのはなぜ？
>>117 #define cast static_cast
>>118 互換性には２種類ある
クラスポインタ変換の場合を例に挙げると
一つは拡張クラスからベースクラスへのアップキャスト
こちらはキャストの明示は必要ない暗黙の型変換が行える
もう一つはベースクラスから拡張クラスへのダウンキャスト
こちらはベースから拡張クラスへの変換に確証が得られている
わけではないのでstatic_castを用いて変換してやらないといけない
このときdynamic_castを使うと実行時に型をチェックしてくれる
のでよりstrictな変換を行わせることができる
できるといってもエラーを発生させるかさせないかの違いだけだけど
>>121 それは互換性じゃなくC++独自の話だね
互換性というからには何と互換なのかという相手がいる
ちなみに、かつて暗黙dynamic_castが提案されて否決となった
コンソールプログラムのwhile()ループで1文字入力したらループを抜けるときに使うやつって何でしたっけ・・
標準に「止まらないキースキャン」はない
linuxならファイルディスクリプタにselectが使えるけど
>>125 getch()絡みで調べてたらkbhit()って出てきましたこれです
ありがとうございました
ちゃんと任意のキー押したら抜けれました
それって結局はビジーループの一種じゃね？
>>128 まずいですかね？
一日ランニング試験してみたんですが良い感じに動いてるのですが・・
ビジーループにSleep挿入して100msづつ位休む感じでアイドルに見せ掛けるハッタリを噛ます
低優先度タスクからのプリエンプションが無いOSでSleep(100 ms)したら
DOS並にコンソールがクソな環境も珍しいよな
>>132 ウィンドウズの話だけど、threadヘッダのスリープは起こし忘れが少ない気がする。
未だにGUIがまともにならないLinuxも珍しいよな
Class A
済みません、途中送信してしまいました・・・
void A(B** b)
馬鹿だから分からないんだが教えて
>>142 A(B*&b) {
A(B*&b){_b=b=new B();}
受け取ったインスタンスを全く使ってないがそれが意図した動作なのか
参照オブジェクトの概念がよくわかってない
>>150 >>142 で「インスタンスを受け取り」と書いてあるから
ポインタ(の参照)でだけどインスタンスを渡しているのだろう
何故受け取っているのかとかの説明は無理だが
それにしてもbをnewするとかイミフ
古いインスタンスを_bに格納して新しいインスタンスをbに返したいのか
>>152 b を new するってのは
＞b = new B();
のことか？参照で返してるんだよ
何故返す必要があるのかはこれも答えられないが
>>142 に new して返そうと思っていますとあるからな
_b=new B() は見当たるが
>>142 コイツのソース見る限りbに対しては何もしてないでしょ
すまんすまん
>>142 ＞B* b;
＞A* a = new A(b);
を見落としていた
インスタンスを渡すといっておいてインスタンスを渡していないとは思いもしなかったw
>>147 であってるんだろうね
>>142 AのコンストラクタにBへのポインタのポインタだか参照だかを渡さなくても
Aが_bをdeleteするために管理するだけのクラスだとしたらスマポ使えという話になる
舌足らずでもうしわけありませんでした・・・
BをAしか使わないならAの中に隔離する
c++じゃポインタのこともインスタンスっていうのか
理解不足を言い換えてミスしてない風にするのが流行ってるのかな
質問あるのですが、
そもそも別にする理由は何？
同一PC内なのにソケットとNICの通信量って何か関係あるの？
>>168 ソケットって、その場合はUNIXドメインソケットのことだろ。 NIC は関係ない。
プロセス間通信としてはほどほどに速度もあって、ほどほどに疎結合なので十分に選択肢の範囲内だと思う。
unix domain ソケットがお手軽で便利だけど
共有メモリだとリングバッファとか排他とか自分で作り込まなきゃいけんやろ
windowsはファイルマッピングオブジェクトでしょ
unix domain socket なんて使ったことないな
>>173 ,174
共有メモリは例えば/dev/shmのRAM領域にあるメモリマップですよね
同一PC内のソケットのボーレートってほぼクロック数なんですか？
同一PC内の通信であったとしてもネットワークドライバの実装するプロトコルスタックを経由してしまうので、
その分のオーバーヘッドの分だけ速度が落ちる、という解釈ですが
iperfとかで同一PC内で速度測ったらどれくらいいきます？
>>179 ドロップしないから楽なんだよ
デメリットは仰る通り
>>180 あなた知識が色々おかしいので何も考えずに教えられたとおりにした方が良いですよ
昨日の安全確保支援士の試験にC++が出ていたが、メンバ変数にm_が付いていた。
>>183 同一PCのTCP通信はどういう経路通るの？
未だにシステムハンガリアンなやつみたいに変なのとも
Windowsのネットワーク関係APIはkernel内に実装されていない
ネットワーク関係に限らずAPIはすべてサブシステムだね
class Sample{
>>191 const を外すのは const_cast じゃなきゃ出来ないことになっている。
だいぶん昔からそう。
でなきゃわざわざ分けている甲斐がない。
const char *a = "hoge";
>>192 やっぱりそうですよね、何か特別な動作かとも思ったのですがVC++のバグか仕様なんですね・・・
>>191 VS2017では警告されるぞ（おそらくVS2015でも）
cl 191.cpp /c /W4
Microsoft(R) C/C++ Optimizing Compiler Version 19.13.26129 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
191.cpp
191.cpp(7): warning C4213: 非標準の拡張機能が使用されています: 左辺値でキャストしました。
後はわかるな？
ポインタや参照のconst外しは合法だが
static_cast<double>(this->val)自体は合法でしょ
途中で書き込まれてしまった
std:stringを引数や戻り値で使う場合、値渡しでも大丈夫ですか？
stringは内部に参照カウンタを保持した共有リファレンサを持っているから&&使用せずに直で渡しても特に副作用もなく何の問題もないよ
今どきのstringはヒープじゃなくスタックを使ったりもするね
>>205 貴様は過去を否定するのか？
温故知新という言葉を知らないのか？
青二才
ありがとうございます
いやいや老害に騙されちゃだめですよ。
>>208 何言ってんだおまえ
頭悪すぎるにもほどがあるだろ
COWなstringは効率が悪くてマルチスレッドとの相性が最悪なのでとっくの昔に打ち捨てられました
値渡しや戻り値で戻せることと、
>>213 まあそうだけれど無駄なコピーはなるべく避けましょうということで
今時のコンパイラは、そこらの人間よりよっぽど高度な最適化をするから、素直で単純なコードを書くと速くなる。
stringを値渡しせずにconst参照等々で渡すことはc++の基本なので、素直で単純なコードの部類に入ると思うが。
先生！OpenMPへの展開も自動でやってくれるんですか？
値渡しを素直なコードとか言う人って他人の書いたコード読まないんだろうな
const参照渡しが基本だったのって C++11 以前の世界の話だよね…
初心者です。
>>224 そのエラーとやら、もしかして警告か？
エラーは直すまで何度コンパイルしても絶対に通らない
警告はコンパイルが完了しオブジェクトファイルができる
そのコンパイルとやら、もしかしてビルドか？ それともmakeか？
ビルドやmakeはオブジェクトファイルとソースファイルの日付を比較して
ソースファイルのほうが古いとコンパイルを省く
だから警告が出てからもう一度ビルドしても同じ警告は出ない
おそらく、こういうことだと見受ける
>>227 日本語読めないのかよ...
> 実行すると、エラーが出たり出なかったり謎の挙動を起こします
実行してるということはコンパイルは通ってるということだと思う
>>230 「実行すると」
ビルド時のコンパイラなどからのエラーではなく、
プログラムを実行したときの挙動についての質問のようですよ
初心者つってるから
コンパイルして(リンクを)実行すると
しつけえな
>>224 何を実行するのか目的語をはっきりさせろ
プロ意識が欠けている
pthread を使ってループ処理をマルチスレッド化したのですが、シングルスレッドと同じスピードしか出ませんでした。
流石に情報が少なすぎて
pthread使うとひとつの処理が倍速にでもなると思ったのだろうか
舌足らずですみません。コードはこんな感じです。
>>243 この世界では、何かやって思い描いてたようにならなかった場合
まず自分の能力不足を疑うのが鉄則
>>248 アハハハハ！ジョークのつもりかなんか？
そうじゃないならjoinの動きを勉強しろ
いまだに関数ポインタ使ってるのか。野蛮人。
いまだ関数ポインタが使いこなせないんだけどやばいかな？
考えたらjoinの問題じゃないか
>>253 未だに関数ポインタなんて使ってるほうがやばい
画像処理で合成処理をパラメータでもらう場合があるんだが
ダメってわけじゃないけどさあｗ
std::byteが邪魔すぎるんですけどg++で無効にするオプションってありますかね？
>>257 あんた昨日のおじいちゃんだろ。
functionの時代もとっくに終わってるぞ。
autoとlambdaで関数ポインタを使うべき。
>>258 ライブラリ制作者でもなければ関数ポインタなんぞ触らんよ。
よほどCとの兼ね合いが無いと。
>>248 threadcountいくつになってるの？
忘れがちなことだが std::function は実行時の型を扱う。
>>248 関数名からして、一度のreduce処理量は大したことなくて、何度も繰り返し呼んでない？
thread処理に必要な処理量が相対的に無視できなくなってるんじゃね？
スレッドは4本に制限して、各スレッドが処理する量を増やすかスレッドプール式にしては？
C++だから関数ポインタ使わないとか頭おかしい
富豪かどうかはおま環だろ
どんなスペックだろうと他のソフトがどれだけメモリや処理時間を喰い潰していようと自分の処理はサクッと終わらせたいといつも思う
>>260 へんてこりんなマウンティングするやつだなあ
ちなみに昨日なんて俺書き込んでないからｗ
>>248 調べてみたけどさっぱり判りません。
pthread_joinで各スレッドの終了を待って、その後、集計処理をするというのはごく渡り前の処理に見えるのですが、
何が行けないのでしょうか？
別の方法でスレッドの終了を待たねばならないのでしょうか？
自分勝手デスミア線が、具体的に問題点、改善点を指摘して下さいm(_ _)m。
いいから「単なる加算処理」全部見せろよこの包茎野郎
threadFunctionが、
そのコード見ても
fでメモリのどっかから数値を読んでいるんだと思うけど、
これがなるべく連続したアクセス(局所化を謀る)になるようにループを構成できれば速くなるかもしれない。
この辺りはググれば色々参考になるページがあると思うが
いまググッたらそれらしいページがあったので書いておく
http://myoga.web.fc2.com/prog/cpp/opti02.htm 仕様として外からfが与えられるなら無理な話かもしれない。
もちろん interval が 1 で f(x) が { return v[x]; } のような最適なケースよりは速くならないので
その辺りは無駄な努力をしないよう測っておきましょう。
fの中身が公開出来るなら公開して
>>250 joinについて勉強しろとか偉そうに言ってたのは何だったの
>>278 こりゃ「多分」joinの問題じゃないなと判断して
>>254 を書いたんだが
これくらいのコンテキスト読めないとマルチスレッドは無理だよ
fやら具体的なargsの内容やら処理時間測定のやりかたも記述されてないし
>>279 違う違う
なんで明らかに間違えてる事を偉そうに述べられるのかと聞いてんだけど
読解力もスキルもないのか
>>281 本当に「明らかに」だと思ってるの？バカですか？
サンプルレベルのJoinの使い方をみて
cin で、個数の決まっていない整数たちを読み込みたいのですが、どうすればいいでしょうか？
>>282 明らかにだろどう見ても。
何をどう勘違いしたのか説明してくれよ。
>>285 他に入力がないなら cin.eof() で入力の終了を検出できるよ。
cin のブール演算を使ってもいいけど、どうにも慣れなくてね(個人の見解)。
>>287 ありがとうございました。
別の質問なのですが、一般的に、vectorの使用頻度というのはどれくらいでしょうか？
配列でやれることもすべて vector を使ってやるという人は多いでしょうか？
それとも、効率などを考えて配列で極力済ませるという人が多いでしょうか？
もちろん、ケースバイケースでしょうけれども、そのあたりの常識がないので、大体
どんな感じなのかが知りたいです。
自分としては、効率など細かいことは考えずに、vectorを使って問題ない
vector<int> v;
>>290 生のnew/deleteは、なるべく使わないのがいい。delete忘れ、例外などでバグの元や維持コストになる。
>>291 ありがとうございました。
ということはできるだけvectorを利用したほうがいいということでしょうか？
>>292 動的にサイズが変わらないなら配列かstd::array。
動的にサイズが変わるならstd::vector。
>>290 上だったらv.reserve(n)しておこう
>>289 私は書き始めは std::vector を専ら使っており、後で他のコンテナに換えています
>>296 普通の人間なら、文脈を読み取れるけど、俺はコンピューターに近いんだ。
>>289 実用上の問題が無いことがわかっている範囲内であれば、
深く考えずに vector だけで乗り切るのも悪い選択じゃないと思うよ。
ただ、使い分けることで意図を表現しやすい。
たとえば list を使っていれば要素の挿入や削除が頻繁なデータなんだなって思うし、
array が使われていれば要素の個数が固定なんだなって思う。
速度的に影響がない程度の規模であっても、
それが適しているような操作をこれからするのだという意思表明は人間がプログラムを読むときのヒントになる。
そして、そういうヒントは書いている途中にこそ必要なものなので、
>>295 のように後から整理していくスタイルは個人的には好きじゃないな。
>>298 ＞それが適しているような操作をこれからするのだ
うーむ、いろいろと考えさせられます
std::vector でなら使えても、std::list では使えない、というのはあるから、最初からそれを考慮しておくのは…よくありますねえ
vector は list に比べた場合、
BidirectionalIteratorとRandomAccessIteratorだろ
std::listはメモリ局所性がないので今どきのマシンだとクソ遅い
メリットとデメリットを見極められないとコンテナを使いこなすのは難しい
>>303 その使い所がよほど特殊な状況以外にないんだよ
大規模C++ソフトウェアデザインという本を読んでいます。
#pragma once って規格化されたんだっけ？
されてない
243です。
>>305 その特殊な状況の為にlistが存在する
私の場合は特殊なプログラムを書くことが多いので
使いどころは多いのかもしれない
また、普通の組み込みC言語でも簡易な片方向リストとかを使ったりする (C++じゃないのでlistは無い)
>>309 技術的な問題ってなに？
既に実装してる環境の方が多くね？
>>313 プリプロセッサは C++ じゃないからね
C++ 以外の言語と共有しているツールなので
それらと歩調を合わせる必要があるし
プリプロセッサだけ独立の規格にするなら
C++ を含め、諸言語の規格も
プリプロセッサのバージョンとどう付き合うのか
策定せにゃならん
>>316 意味わからん
C/C++の規格にプリプロセッサの仕様もあることを知らんのか？
そもそも他の言語と共有してる環境なんて見たことないし
現行では、 #include ディレクティブは「対象ファイルの内容がそこに書かれているかのようにふるまう」という規則なので、
ヘッダファイル内のプラグマ (#pragma once) の解釈が始まるのはインクルードされた後になる。
もちろん対象範囲がコンパイル単位全体に及んでしまっては #pragma once の意味がないが、
現状の仕様に辻褄を合わせるとそうなる。
実装した処理系がもうあるんだから実装に沿うように規定しなおすってことはできなくは無いんだろうが、
#pragma once を仕様に入れるのに #pragma once の項目を追加すれば済むわけではないってことは理解してくれ。
それと、プリプロセッサの仕様は C/C++ の一部なのは確かだが、
挙動を規定しきれていないのじゃないかということは指摘されている。
https://qiita.com/ruiu/items/4d471216b71ab48d8b74#3%E6%9C%8817%E6%97%A5 うやむやでやってきてるところを整理する必要は有ると思う。
>>317 Haskell (GHC) は C プリプロセッサを使うよ。
汎用的に使いたいなら M4 とかの方がいいとは思うけど、
Cプリプロセッサに慣れている人は多いから……。
また別な話
ハードリンク、シンボリックリンクが無いファイルシステムだったとしても、サーチパスの問題も思いつくな。
#if ****
>>318 > 実装した処理系がもうあるんだから実装に沿うように規定しなおすってことはできなくは無いんだろうが、
規定すればいいだけだろ？
どこに技術的な問題があるんだ？
政治的な問題だと言うならまだしも
>>319-320 みたいな話は処理系定義ですむ話
>>321 は少し悩ましいがそもそも途中まで読んでから#pragma onceとか言われても面倒だから書くならファイルの最初に書けとかの制限をつければいい
> 挙動を規定しきれていないのじゃないかということは指摘されている。
いやいや、その子ちゃんと規格読めてないだけでしょ w
> Haskell (GHC) は C プリプロセッサを使うよ。
仕様を流用してるだけでしょ？
何かのコンパイラと共有してるわけじゃないと思うが
君よりよっぽど賢い人達が20年間悩み続けて未だに出来てないことを舐めない方がいい
>>323 別に悩み続けてなんていないでしょ w
#pragma onceで事足りてるからわざわざ政治的なことに足突っ込みたくないだけ
新規格の季節になると毎回のように標準化委員会の議題に上がってるんだが？
モジュール方式になったらヘッダファイルが要らなくなる？
>>322 > 処理系定義ですむ話
それはおかしいでしょ
ハードリンクできる処理系からできない処理系に移植したtarボールの
#includeの挙動が未規定なら結局インクルードガードを自前で書くことになる
>>325 でも誰も進めようとしないんだろ w
よくある話
>>327 C/C++ ってそういう言語だしそもそも環境変える予定があるならそんなものに依存したファイル構成にしないでしょ
#pragma once なんて
>>322 トピックとして大きすぎるので面倒くせえってだけの話。
#pragma once
むしろプリコンパイルヘッダーが規格化されないの方のが悩ましい…
ていうか#pragma onceとか#ifdef～#endifによるインクル～ドガ～ドのシノニム以外の何者でもないと思うが
一方#ifdef～#endifによるインクル～ドガ～ドは
「対象ファイルの内容がそこに書かれているかのようにふるまう」
という規則の下で立派に機能していると思うし、
>>321 のように等価な#ifdef～#endifによるインクル～ドガ～ドが存在し得ない場合はエラーにしたら良いと思うし、
ハードリンクできる処理系かどうかに関係なく#ifdef～#endifによるインクル～ドガ～ドは機能していると思うし
（だいたい1バイナリのビルド中にハードリンクの中身が変わるみたいな想定をする方がおかしい＝ハードリンクはそうでないファイルと区別がつかないとみなせるﾊｽﾞ
だったら#pragma onceも問題なく規格化が可能なのでは…
少なくとも技術的な問題とかとうていナッシング？
ちょっとはググれよ。
↑ググってもボンクラが書いたような駄文が見つかるだけなので却下。
インクルードガードを自前で書くたびに
要するに同じファイルであるかをどうやって判定するかの問題
>>338 #ifndef 形式のインクルードガードを自前で書くとタイプ数が多いし
識別名を打ち間違える危険もあるから .h のファイルを新規作成したときに
自動的に入力されるようにエディタのマクロにしたよ。
まぁ、識別名をファイル名から作ってるから、ファイル名の変更でアレだけど。
昔(フロッピーでやってた時代?)は #ifndef 形式でガードすると
どのみちヘッダファイルをまるごと読み込まなきゃならないから、
#pragma once の方がコンパイル時間において優れてる、などと言ったけど、
ハッシュを計算して同一か検証するとか手間が増えるなら
時間の面での優位性はなくなったのかな。
「技術的な」というときの技術は「プログラミング技術」の意味じゃないこともあるんだよ。
前置きが無い限り広すぎてあんまり意味ない。
実装がいくつもあるのに、仕様策定にあたっての言葉で出てくる「技術的な」なんだから文脈でわかれよ。
仕様に落とし込む難しさが元々の論点。
ハードリンクの話題は「同一のファイルとは何か」を定義する難しさの一例で、実装のことなんか言ってない。
このスレで既に上がっている選択肢だけでも
・ 内容が同じ
・ 絶対パスが同じ
・ #include ディレクティブ中の表現が同じ
・ inode が同じ (ハードリンクは同一とみなす)
があり、内容の一致を選択する場合以外は言語の外の世界の環境に関する記述が必要になる。
世の中にある色んな環境のことを考慮して文面にする難しさってのはわかるだろ？
そんなわけで、個人的には内容の一致だけで判定するのが (仕様として定義するにあたって) 一番簡単だと思う。
ODR に関するルールの中にも同じトークン列を要求するものがあるし。
それに加えて
>>318 で取り上げた展開手順の規則をなんとかする必要はあるが、
>>321 に解を与えるような上手い簡単な規則は思いつかないな。
既に多く書かれてしまっているコードの現状との互換性を考えると
>>322 のいうような、
#pragma once を書ける場所を制限するような規則は選択できないと思う。
結局は複雑なものにならざるを得ない。
そんなのほっといてモジュールの導入に邁進しようぜっていうのは妥当な方針だろ。
>>339 みたいに独善的なやつは標準化委員に向かないタイプだね
提起された問題を個人的に考えるのがイヤだから却下とかやってたら
みんなやる気なくすし
>>341 > 「技術的な」というときの技術は「プログラミング技術」の意味じゃないこともあるんだよ。
そういう人がいるからわざわざ「政治的」って言う言葉を入れてあるんだが理解できなかったのか？
で、あんたの言う技術的な問題ってなに？
具体的に書いてくれ
>>342 >
>>339 みたいに独善的なやつは標準化委員に向かないタイプだね
> 提起された問題を個人的に考えるのがイヤだから却下とかやってたら
意味わからん
俺が提示した内容がダメだと言うならもっといい案を提示すればいいだけ
こんなスレで独善的とか頭大丈夫？
提示してねえだろ、おまえは無視つったんだよ
>>345 私はこの件について、技術的な問題があるとは述べてない。
その箇所の後に技術的という言葉は広範すぎて (言い換えれば、具体性がないので) 意味ないという意味のことを書いてるつもりなんだが。
それとは別に、私の考える問題を端的に言うと仕様の文面に落とし込むのは難しいねっていう、そんだけのこと。
>>348 現時点での問題点をはっきりさせることに意味はあると思いますよ…
>>346 理解できないなら絡んでくるなよ w
「アホな利用者は相手にしない（=無視する）」って言う仕様を「提示」してるって話だ、ボケ
>>350 スレチ
意味があると思うなら他にスレ立ててやれ
>>351 科学技術的な議論にアホなんて用語を使うあたりお里が知れるな
形容詞には比較基準や単位をつけろボケ
俺は
>>339 が正しいと思うぜ。
というか
>>341 は明確に間違ってるだろ。色々と。
「ハードリンクガー」なんてのは論外。規格で定めるべき事項ではない。
規格で定めるべきなのは、
・全く同一の中身だが実体が異なる場合でも #pragma once は有効か？
(cp A.h B.h の場合にも B を読み込むか？)
だ。そしてこれは当然現行のインクルードガードと同じ方向に揃えるべきであり、
・読み込んではいけない
という仕様になるのも自明だ。
絶対パスやinodeやハードリンクというのは、
・通常のファイルシステムであれば、絶対パスが同一なら同じファイルを参照する
（＝同じ中身であることが保証される）
・inodeでファイルシステムが実装されているのなら、
同じinodeを指すファイル（＝ハードリンク）の場合には、同じ実体を参照する
（＝同じ中身であることが保証される）
であって、これらは「全く同一の中身」であることを確認する手段でしかない。
これらが有効な環境では間引くのに用いればいいだけ。勿論ハッシュを使ってもいい。
これらが別物に見えるのなら、それは抽象思考が出来ない馬鹿だからだよ。
ファイルシステム毎にC++の規格をいちいち決め直す必要があるなんて、おかしいだろ。
今後新しいファイルシステムが考案される毎に、毎回C++の規格を刷新するつもりか？
例えばWindowsでは同一ドライブに複数のドライブレターを割り当てることが出来るが、
それでどうなるかをC++の規格に定めるべきだと？マジで馬鹿だろ。
最終的に規格に定めるのはつまり、
そしてやる気がないのは今更意味がないからだろ。ほぼ全ての環境で実装済みだ。
> Cray C and C++ 以外では全て実装済み
>
https://en.wikipedia.org/wiki/Pragma_once 勿論糞長いパスとかにしたらはまることもあるが、これもよくある話でしかないし、ユーザ責任でいい。
規格に「パスは○○文字まで」と決めるわけにも行かんし。
> 途中でバッサリとパスが切られて、まったく同じシンボル名になって、
> 初めてincludeしたファイルなのにスキップされるという、
> なかなか原因解明が困難な不具合に襲われる……といったケースがあるかもしれません。
> ……はい、体験談です。
>
http://cpp.aquariuscode.com/include_guard 二重にインクルードすることを想定しているヘッダーファイルって、存在するものなの？
>>358 <pshpack?.h>
<poppack.h>
>>355 要旨が混乱していますね
＞例えばWindowsでは同一ドライブに複数のドライブレターを割り当てることが出来る
つまり、今読み込んでいるヘッダファイルがかつて読んだファイルと同じ実体かどうか、を決める方法は**基本的にない**と主張しているのですよね
そう主張するのなら、
＞・読み込んではいけない
＞という仕様になるのも自明だ。
「読み込んでいいかどうか」を決める方法がないのに「読み込んではいけない」と決めていいのですか？
条件を満たすかどうかチェックする手段がないのに、その条件を仕様とするのは無意味ではないですか？
>>358 たくさん存在する。
インクルードする前後のマクロ定義によって挙動を切り替えて使うようなものもある。
基本としては宣言というか、別のコンパイル単位にある関数などのインターフェイスを取り込むために使うものなんだけど、
アクロバティックな使い方をしてるものはそれなりに多いよ。
プリプロでループを実現するには再帰includeは欠かせないからな
>>361 むしろそっちのほうに、
二重インクルード可能みたいな宣言を用意してほしいわ
>>360 マジで言ってるんなら死ね。
俺の意見は、
・#pragma once は現行のインクルードガードと同じ方向に仕様化すべき
であって、実際これで文句が出ることはないし、妥当だろ。
つかお前、
>>340 を理解してるか？
int lengthOfLcs_r(const char x[], const char y[], int ix, int iy, int xsize, int ysize) {
#include "/dev/tty" も知らない雑魚はもう黙ってろよ
>>365 の関数は、再帰的な関数です。
その再帰的な関数内で static な配列を利用したいのですが、動的に確保した
領域を解放するにはどうすればいいのでしょうか？
再帰的な関数なので単純に関数の最後で解放するというわけにはいかないので
困っています。
>>365 動的計画法で配列に計算結果を記録しておき利用したいんです。
なので static にしています。
>>364 わけて考えてみますね
インクルードガードはプリプロセッサ名前空間内の一つのプリプロ識別子を犠牲にして、機能させようとしているわけですよね
#progma once が犠牲にする**べき**ものは何でしょうか？
>>365 の関数はまだ書きかけなので、計算結果を記録した配列の値はまだ利用していません。
>
>>365 lengthTableのポインタ値をなんとかしてグローバル変数に持ち出してatexitに登録するか
最初からそのグローバル変数でnewするか
どうせプログラム終了時にヒープ丸ごと消えるんだから放置するか
一から書き直すかの4択
>>365 あ、すみません。
なんかおかしなことを書いてしまいました。
>>371 ありがとうございました。
すみません。質問がちょっとおかしかったので、質問を代えさせていただきます。
ある特定の関数内でしか見えないグローバル変数のような変数というのはC++にありますか？
考えているのは、関数 func でそのグローバル変数のような変数 a を宣言する。
func 内で呼び出している再帰関数 rec_func 内でのみそのグローバル変数のような
変数 a を利用したい。グローバル変数のような変数なので、 rec_func の引数として
a を渡す必要はない。
何度も呼び出される再帰関数に引数として同じ変数を渡し続けるのはなんか
>>373 でいう変数 a の代わりに、クラスを作って、メンバ変数を利用すればいいですかね？
rec_func はメンバ関数にすればいいですかね？
でも、そのためだけにクラスを作るというのもなんだかな―という感じがします。
>>360 一応添削しておくと、
> 今読み込んでいるヘッダファイルがかつて読んだファイルと同じ実体かどうか、を決める方法は**基本的にない**
× 同じ実体かどうか、を決める方法は
○ 同じ実体かどうか、をパス等で決める方法は
ただし俺はそもそも「中身」を見て確認すべきで、同じ実体だったら云々、という話はしてない。
cp A.h B.h の場合にインクルードガードでBを弾くとして、
当然Bは「ファイルとしては」「読み込まれ」、「コンパイル対象としては」「読み込まれない」だろ。
#pragma once はインクルードガードの自動版なんだから、インクルードガードと同じ仕様でいいんだよ。
そして逆に、実体が異なっていてもこの場合はインクルードガードは利くのだから、#pragma once も利くべきなんだよ。
ファイルパスでの識別ではこれは実現不可能だろ。
>>369 意味不明。何も犠牲にするべき物は無いと思うが。
というかな、規格化するなら方向は自明で、
・#pragma once はインクルードガードの代わりに使われているのだから、
現行のインクルードガードを機械的に #pragma once に置き換えして問題ないように仕様化すべき
でしかないだろ。これで誰も文句ないと思うが。
>>374 の心配があるんだったらクラスにしたって裏でthis渡すようになるだけだから一緒よ
ポインタ渡すコストが気になるならグローバル変数にするしかない
>>365 のコードのままなら末尾再帰の最適化かかるだろうから問題にならんと思うけどな
クラスを作ってそのプライベートなメンバ変数を、
>>373 > ある特定の関数内でしか見えないグローバル変数のような変数というのはC++にありますか？
見た目だけの話ならラムダでキャプチャすればいい。(クロージャ）
ただ、今気づいたが、C++のラムダって名前付けられないから再帰できないね。
変数の直接呼び出しも試してみたが、以下は通らない。
auto f = [](int x) {return x? x+f(x-1) : x;};
なんでこんな糞仕様にしたんだ？
JavaScriptも当初はそうだったが、不便だったので名前が付けられるように変更した。
この変更を知ってて無視してるのなら頭おかしいし、
知らないのなら不勉強だし。（言語仕様に携わる奴は他言語の動向も見ておくべき）
名前を付けられて悪いことはないし、技術的に不可能って事も無いと思うが。
ID:4xU9Va0kM=ID:HtO+dzj70
>>353 反論されてぐうの音もでないのかよ
５チャンは初めてか？ w
同じファイル
>>382 > ID:4xU9Va0kM=ID:HtO+dzj70
勝手にアホな認定するんじゃねーよ
そもそも俺はハードリンクとかのファイルシステム依存の話は処理系依存にした方がいいって思う
>>384 人を嘘つき呼ばわりして謝ることもできない奴がなに言ってるんだよ w
効いてる効いてるｗ
>>381 自己レス。
すいません出来ました。以下通ります。autoは無理のようです。
std::function<int (int)> f = [&f](int x) {return x? x+f(x-1) : x;};
>>373 見た目だけなら、上記のようにラムダで再帰すれば書ける。
またいつもの奴が暴れてるのか
それで結局#pragma onceが採用されてこなかった理由はなんなん？
所詮 pragma だから
>>388 >>351 にまともな反論してから出直してこい w
>>393 反論とは論に対して反駁することをいう
おまえは論を示していない
結果に至る思考過程をすっ飛ばしている
おまえこそ日本語を憶えてから出直して来い
もう一度言う、反論とは論に反駁することだ
まともに反論できないことはよくわかったよ w
事実ってなんだよ
そういう意見を書いてあると言う「事実」な
>>397 それは違う
何からどう演繹した結果なのかを示さねば戯れ言に等しい
戯れ言でよければ過程は伏せたままでいいぜ
どーせそんなもんバカにはねえだろうがな
>>400 じゃあ俺も、お前はここに二度と来ないでに全財産を福島と熊本に寄付した上で家族もろとも自殺するべきであると意見するわ
こういう意見を書いてあるという事実に反論できなければお前の負けな
>>401 お前が何を言っても
>>339 に書いた「無視」と言う文言を理解できなかった
>>346 がいたと言う事実は変わらない
しかも誤魔化すために話そらそうと必死な
>>353 がいた事実も変わらない
>>402 別に意見を言うのはいいんじゃね？
それに何の意味があるのか知らんけど w
C/C++の規格はgets()とかいうアホな使い方しか出来ないアホ関数を30年も削除出来なかったくらいアホに気長に付き合う規格なんだよ
>>403 もう一度言う
提示してねえだろ、おまえは無視つったんだよ
人をアホよばわりしようと焦るあまり
論議そのものを粗末に扱ったのが
おまえの運の尽きだ
そこでどんなに暴れようが
おまえは何も論じていない
よって論に反駁してもらえることもない
ましてや事実に反駁というシュールなことをする者もいない
>>405 マジで言ってるの？
gets() なんてアホには使えない関数の典型だろ
バッファーオーバーフローはプログラマーの責任
って言う言語だぞ w
>>376 言葉尻を捕まえて悪いが、クラスや関数を作ることをそう大仰に捕らえることはない。
単純な機能のクラスや関数など幾らでもある。
>>406 >>351 を読み直せ
無視するのは誰で誰を無視するのかを答えてみ
まあ恥ずかしすぎて答えられないだろうからまた明後日の話に逸らそうとするんだろうけど w
>>410 読み直して欲しいのかよ
お願いしろよ
読み直してやるかも知んねーからｗ
りかいできないならからんでくるなよダブリュー
C/C++は池沼お断りの言語なんだから、このスレも同じノリでいいと思うぞ。
ていうか#pragma once規格化不能論者が言い立てる不可能ケースは
(1) #ifdef～#endifインクル～ドガ～ドでも曖昧さが残り処理系依存になるケース
(2) #pragma onceで自動的にガード条件を設定する際の困難（#ifdef ～の記号をうまい具合に考え出すことに相当
(3) #ifdef～#endifインクル～ドガ～ドにおける既存のアクロバティックな使い方への対応（
>>361 (4) #pragma onceで想定されるアクロバティックな使い方の解釈（
>>321 のn種類しかない
(1)は#pragma once固有の問題ではないから、#pragma once規格化の障害とは言えない ハードリンクとかの件でここまで費やされた長い紙数はムダすぐる…
(2)と(3)は、#pragma onceが力量不足ならそのケースだけいつでも#ifdef～#endifインクル～ドガ～ドに戻ることができる プリプロセッサの基本特性まで変えようというのではないのだから…
(4)はエラーにすればよい #pragma onceの解釈を単純な#ifdef～#endifインクル～ドガ～ドの置き換えと限定するなら可能なはずや
いままで20数年にわたって規格化委員会で話題に上りながら規格化されないのは、
この件の抜本的な技術である「モジュール」の規格化が控えていると全員が錯誤していること、これにつきるだろうＪＫ
>>416 とりあえず、
#pragma onceの仕様を文章にしてみて
そんなに簡単じゃないから
■ #pragma onceの俺様仕様
>>418 #pragma onceってファイル先頭に置くものだと思ってた
ファイル末尾とかにおけばいいの？
ソフトウェアが巨大化してくると、サブモジュールが各々同一のSDKを抱えてるなんてことがある。
訂正；
>>420 >>418 の仕様によるヘッダファイルの展開のどこにヒューリスティック要素があるのかkwsk、
>>418 >ファイル名で識別
過去遺産をすっぱり切り捨てる斬新な発想に目から鱗
>>423 藻前は
>>418 の仕様の項番4を理解していない
出直せ
今後ヘッダファイル名にはドメイン名を頭につけなきゃいけないね。
>>417 適当な処理系の言語リファレンス見ればいいだけ
そんなに難しくはないぞ
>>422 420が提起した問題に答えろ
kwskはそれからだ
>>427 是非は置いといて、ファイル名で識別するって書いてあるじゃん
文盲なの？
つまりfooSDK/interface.hとbarSDK/interface.hは同一として判定するんだな
#pragma onceの前に改行があったらエラーですかwww
>>420 それ単に管理がなってないだけだろ
どのバージョンのヘッダーを読み込むかを管理できてないとか怖すぎる
>>432 どう管理しろと？
混用しているライブラリに偶然同じファイル名があって
どちらもインクルードガードされているということを
「管理」で回避できるのか？
>>432 えー、cvs keywordはどうするのー？
サブモジュールを格納してたリポジトリ毎に値が異なるよ？
自動的に改行コードを修正してくれるリポジトリの場合はー？
まずは世の中のプリプロセッサのpragma onceの仕様がどうなっているかを調べるべきかと
>>433 話の流れを理解せずに無駄に絡んでくるなよ...
インクルードガードならとりあえずビルドできるって言う話だぞ
>>434 同一のSDKなんだから同一のものを指すようにすればいいだけだろ
目的は
インクルードのループを防ぎたいのと
同じ定義を複数回行うことでエラーになるのを防ぎたい
ってことだよな
これをインテリジェントに行ってくれるのが理想
インテリジェントな物を仕様にするのは難しいし、
時代が進めばインテリジェント具合も変わる
>>418 みたいなあまりにショボい仕様だと
後々不満が出ることになる
>>437 答えになってないぞ
今 #pragma once について話しているよな
インクルードガードを #pragma once でやっていたらどうなんだ
>>429 >>434 現行のヘッダファイルでうまく行っているのならそのままでええ（
>>418 項番4はそのためにある
そうではなくて、もしも（例えば）マイクロソフトのVisual C++の#pragma onceを使って書かれた過去の遺産の尊重が大事なら
そのときは
>>418 の方の#pragma onceを#pragma once2とかに代えれば良いが
そりゃー（例えば）マイクロソフトのVisual C++の#pragma onceが先行して規格になった後の話なので今は無視
>>435 >417からの流れと考え合わせるに、
「僕ちゃんの考えた理想の#pragma onceじゃないと嫌なの！！！>418のｸｿ単純な仕様は正しくとも認められん！！！」ってことですかそうですか…
なお
>>431 の指摘は評価する
>>436 抽象的な言い回しで無意味に高尚な議論に見せかけている連中の方が多数派
空っぽなのに…
当然互換性の問題もある
今まで動いていたものが正しく動かなくなるのであれば支持されない
だから
>>435 も非常に重要
>>441 時間差だったかもしれんが
>>440 の最初のパラグラフ参照
存在しない規格との互換性の問題を喚かないでいただきたい、というのはあるが
回避策も示しているのだからオール無問題
>>429 の例で
2重インクルードを防ぎたい場合とそれぞれ別にインクルードしたい場合があるってのは書かなくてもわかるよな
中身が全く同じであれば防ぎたいし
全く別の定義であればそれそれぞれをインクルードしたい
>>442 #pragma onceの仕様はVisual C++しか実装してないと思ってる？
>>443 >>444 >2重インクルードを防ぎたい場合とそれぞれ別にインクルードしたい場合があるってのは書かなくてもわかるよな
ああ
>>443 の脳内にはそういう要求もあるんですねわかります
その場合は
>>418 項番4でﾄﾞｿﾞｰ
藻前ら
>>418 の単純さをバカにするが藻前らの論理展開のアレっぷりも相当なもんやぞ…
いずれにしろ
>>418 みたいなチープな仕様じゃ誰にも支持されない
ツッコミ殺到でボコボコなのに勝利宣言してやがるな
>>418 ,421はミニマムの仕様を提示しただけで、つまり、
この仕様で問題ない場合は #pragma once で手抜きが出来て、
無理な場合は従来通りインクルードガード使えってことだろ。
俺はありだと思うぜ。仕様ってのはこういう割り切り方をしないと決まらない。
C++のラムダなんて後付で仕様を拡張して行っているし。（このやり方がいいとは思わないが）
ただ、この仕様だと現行の #pragma once よりも割り切っているのがイマイチで、
「今」この仕様では却下されるだろう。
「#pragma once が全くない世界」なら、とりあえずここから出発するのもありだっただろう。
現行の #pragma once は常識的に考えて、
・ファイル実体が同じ場合(ハードリンク/シンボリックリンク）は対応可能
・コピーの場合(ローカルに xxx.h を tmp_xxx.h にしてデバッグ出力を改変したり）には対応不能
だろう。だから使用条件としては、
・全ファイルがローカルファイルシステム上にあり、ヘッダファイルの改変は行わない
であり、普通に個人レベルで開発する場合はこれで全く問題ないし、妥当だ。
会社で10-20人レベルで開発する場合、どのみちルールを子細に決めることになるし、
そういう場合は従来のインクルードガードでやれ、という割り切りも妥当だよ。
なお俺が推す仕様は、
もう書かなくて良いよ
インクルードのネストがn段
>（ディレクトリパスは無視）
>>438 ,
>>446 >
>>418 みたいなあまりにショボい仕様だと
> 後々不満が出ることになる
でも具体的には指摘できない
ってか w
static変数(クラスのインスタンス)がプログラム実行時にそのメンバ関数呼び出し時にその中で、
>>460 99%以上の確率であなたのバグです。
1行目の意味はよく分かりませんが。
ああすまん、何となく1行目の意味は分かった。
ふつうに、
>>450 >>464 日本語でおｋ
お前は半島に帰れ
>>452 それでお前は何パスだと思うのさ？
予言してやる。お前は言えない。
なぜならお前は馬鹿であり、それがばれるのが怖いから。
ひとまず俺の一つ目の予言は的中だな。
次に行こう。
>>467 ID:aIENMcPWd
お前の日本語の間違いをすべて訂正してみろ。
2つ目の予言をする。お前は言えない。
なぜならお前はゴキブリ韓国人であり、間違いを認識できていないから。
C++でプラットフォームに依存しない音楽再生ライブラリってある？特にlinuxで使いたいんだけど。
質問ですが
>Q2
>>472 std::numeric_limits<double>::lowest()
まりがとうございます
>>473 >>475 すばらっし
>>474 言葉足らずでｽﾏﾝｶｯﾀorz
具体的型名で特殊化する普通の特殊化ではfloatとdoubleのそれぞれについて特殊化した定義を与えねばならないので
>>473 みたいなやつを求めていたのです！ヽ(＞∀＜)ﾉ！！！１１１！１！
たまにはlong doubleも思い出してあげてください
Boost.Optionalを使う際に、
対象クラスが自分自身の有効無効を変更できるようにしようとしてみたところ、
宣言時に宣言対象を引数にとって初期化できることに気づきました。
変数の引数に変数自身を使うのは仕様的にありなのでしょうか？
https://wandbox.org/permlink/YLKYol7KdEOhpyGU CObject obj; 👀
今時newなんかを自分で書いてることに疑問を持ったほうがいい
手っ取り早く動かしたいその場限りのコードならそういうことをやることもある
ポインタじゃないものにnewしたもの格納できるとでも思っているのかジャバグラマ上がりのトーシロー
deleteしてからnewすることにします・・・
>>488 こうでしたorz
CObject* obj;
>>480 C++的には
for(i=0; i<N; i++)
{
CObject obj;
・・・（処理)・・・
}
でいいんじゃね
大規模なコードで大量にオブジェクト生成するならアリだと思うけど
>>482 クラスのメンバ変数に他のクラスインスタンスを召喚するときとか
コンストラクタでnewしてやらないといけないと思うの
>>494 複数のプロジェクトで使いまわせる
>>495 スマポ(かコンテナ)で大体のnewは回避できる
そのケースも回避できる
>>495 別にnewしなくてもよくね？
なんかサンプル出してみ？
new無くしてやっから
>>497 >>498 class CTest
{
CFoo cfoo;
void CTest(): cfoo()
{
}
};
メンバ初期化子知らんのか
ちなみに非PODならメンバ初期化子に書かなくてもデフォルトコンストラクタで初期化子される
>>499 そ、そうやって初期化したcfooはdeleteしなくてもいいんでつか？
>>504 変数の寿命を理解してないのか？
C/C++で変数の寿命を理解せずコード書くとメモリリークだらけになるから止めるか横着せず勉強するかしてくれ
>>504 何言ってんだお前は
そもそもdelete出来んだろ
教えてください
やりたい事は ↓
https://stackoverflow.com/questions/14706954/how-to-override-the-text-displayed-for-a-property-in-the-propertygrid ここに出てるようなPropertyGridで、数値配列の値を16進で表示したい
[0] 0x0001
[1] 0x0002
[2] 0x0003
....
例えば↑とか、単にこれだけ
そうとう調べまくったんだが、配列の例はみつけられなかった
配列でなければ、実装例は結構見つかるんだが・・・
一見簡単そうなんだけど、俺のレベルでは不可能
>>507 それC++の質問なの？
.NETのライブラリ(=>C++/CLI)じゃなくて？
ごめん間違えた、ここ C++のスレだった
>>505 >>506 >>512 み、みんな、親切にありがとう・・・
>>494 一度に作る分量が減るので間違えにくい
別々の人間が手分けして作れる
>>503 >>498 はコンパイルエラー（もしくは警告）になるだろ... どうせ
>>498 の
CFoo cfoo;
はこれまた
可能な限りスマートポインタを使え、そしてスマートポインタで駄目な場合はほとんどないってのはその通りなんだけど、
もうスマポはスマポとして理解させたほうがいいような気がするけどな
ポインターをdeleteせずに扱う猛者がいると聞いて駆け付けてきた
delete をしない戦略ってのは無くはないよ。
組み込みだとそもそも終了なんてものがなかったりする
>>526 placement new の意味が今でもよくわかりません…どんなときに使うのかなあ…
char buf[MAX_BUF];
char buf[sizeof(MY_STRUCT)];
>>527 VRAM みたいな特殊なメモリを C++ のオブジェクトに見せかけたい場合とか
すでに確保したメモリーブロック上でコンストラクターを発動させる。
組み込みとかゲーム機のような、最初に一気に確保する環境で使うんじゃないかね
クラスを丸ごとDLL化するときにはnew系をオーバーロード
unique_ptrの配列版でメモリの再確保を行いたい場合どのように行うのがベターですか？
>>534 unique_ptr::reset( ) じゃねーの？
[][][] [[[ ] X_[[[ [] ][ [] ][][[[]
以下のように、派生クラスのメンバ関数で基底クラスのメンバ関数を呼ぶように
基底クラスが派生クラスに強制する方法はないでしょうか？
https://wandbox.org/permlink/K4IHMYwOsutPQz3i FAQやな
レスありがとうございます。
>>544 pure virtualなのに関数定義することなんてできたのか…
f()とbase::f()は同じ関数なんだよね？
}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\
>>547 12行目のbase::f()はvirtualを抑止してpure virtualを呼び出す
13行目のf();は動的結合でchid::f()を呼び出す
baseは抽象クラスでnew base{}できないので
13行目の動的結合がbase::f()を呼び出すということは起こりえない
だからif(typeid(*this) != typeid(base))のようなチェックをしていない
ちょっと根本的な質問を。
MSのOSしか使わないなんちゃてPGならC#で十分じゃないの
mono/Xamarinはしんどいと言う事を知らない世界の内はいいんじゃない？
ざまりんが苦しい人は信仰が足りないのです
>>551 余計な依存関係をかかえないのが嬉しいです
Boostとか使ってると余計な依存関係をかかえてしまうけどな
一番多くの環境で使えるのはC言語
数十バイトだとスタック領域ももパンクしそう、厳しいのではないか？
知らないで盛ってると言うのはどうかと
調べたら勘違いで自分の持ってたのはSRAM64バイトのpicだった
ＰＩＣ１２Ｆ６０９とかでもプログラム領域は1Kwあるけど
PIC10F200はRAMが16バイトですね
C++どころかCすらやってはいけないレベルだな
>>562 ROMとRAMの区別がつかない人がなんでこのスレにいるのか？
ハーバードアーキテクチャのデータメモリサイズだけ書くの
>>557 を受けての話だから
そのチープなマイコンで開発にCが使えてる
>>551 競技プログラミングとかunity覚えるの面倒とか？
>>566 RAMってしっかり書いてるじゃん
チープなマイコンだとROM/RAMに別れてるのが普通だよアーキテクチャー関係無しに
スタックの話だよね
C# と C++ は世の中でどちらのほうが使われているのでしょうか？
>>574 ありがとうございます。
結局、どのプログラミング言語を習得するのがおすすめでしょうか？
Python のような言語は除いて。
>>576 趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。
もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。
>>576 コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。
C++のスレで言うのもどうかとは思うが、
>>577 そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい
>>579 >>580 参考になりました。
ありがとうございました。
>>578 アセンブラかVerilog/VHDLあたりじゃね？
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ
Cはアルゴリズム勉強にはあまり向いてないと思う
オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが
>>585 に書いた「段階的に積み上げていく」の意図ね。
かといってそれで全体像が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。
やりやすいと思った方でやるしかしょうがないんじゃね。
C言語で書かれたアルゴリズムが読み解けるようでないと
C以外だとリストのシャッフルはshuffleだけで済ませられる
アルゴリズムを学習するって、その実装の中身を理解することだろう
個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。
みなさん、ありがとうございます。
アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
>>594 勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた
C#はLinqが便利すぎてお勉強用としてはどうなんだろうなぁ
ああ勘違いしていた
アルゴリズムを勉強したいのではなく
>>もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
>>アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
なのね
であれば
>>573 氏が現役バリバリな時の主流の言語なんて今からじゃ予想つかないだろうし、実務なら最も適した言語が使われるだけだからC++をそのままやり続ければいいと思う
コンピュータサイエンス自体死ぬほど広範囲な学問で、実務のプログラミングとの間にもやっぱり開きがあって万能な言語なんて無いよ
敢えて言うなら物理と数学、これだけは裏切らない
>>585 そこがいいんだよ
隠蔽されたことを忘れたフリをし
本当は忘れていないということの練習に向いている
忘れたフリが綺麗なコードの練習
本当は忘れていないことが性能評価につながる
両立した技能の練習に向いているということだ
>>571 >>572 そもそもROMの反語はRAMじゃねぇし(SAMってのもある)
SHARCだとDMのサイズは0でも、PMさえあれば動く
で、PMの事隠してマウンティングすればお前らは受け入れるのか？
今はどうか知らないけどcは標準でvectorやlistやmapがないから
>>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 データ構造の要素が静的に型が決まろうがそうでなかろうが、必要な要素数のメモリを確保する作業に違いはない。
せいぜい型のサイズを余計に掛け算するくらいだ。
確保するサイズが間違っていれば静的に型が決まろうがメモリ破壊は起きる。
もう少し具体的に示してくれないか？
静的な型の恩恵がどうたらって
>>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 面倒なやつだな。
「既に壊しうるのだから」
これでいいか？
汎用バイナリ < 汎用コード専用バイナリ < 専用コード
>>643 間接参照を抜ける場合とかだろ。
逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
実際にC++はCより遅いってのは事実だし。
>>645 お前が値配列と参照配列の区別が付いてないだけだろ。
>>653 アンカーミスったか？
qsortとstd::sortはどちらも値であろうが参照（ポインタ）であろうが使えるぞ
>>653 > 間接参照を抜ける場合とかだろ。
それC++のまま書き換えればいいだけ
> 逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
そんな主張はしてない
> 実際にC++はCより遅いってのは事実だし。
だからどんなケースなんだよ
STLとか使いまくって遅いとかなら使わないように書き換えればいいだけだろ
厳密に言うと
x86-32
>>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を第一パラメータとして渡してるだけで、これは構造体でも同じことが出来る
>>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++ということだったのか。
なら話は噛み合わないさ。
#define SIZE 100000000
#define SIZE 100000000
>>657-658 そういやスタックにとる可変長配列はC++にないんだな
まあメジャーな環境でalloca( )使えないものはないと思うが
例外は使わないようにすればいいだけかと
>>678 一応、基本的確認をするが…データは同じなんだよな？
俺の予測では同速。多分そちらの期待も同じだと思うが。
>>676 > ・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。
可変長配列とか使ってないならC++のコードでもある
つまりC++の範疇で書き直してるだけ
って言うのが大方の人の解釈だと思うが
>>676 それは単なる君の定義
100歩譲っても5chで一般的なだけ
普通C言語, C++と言えば、
その規格や規格に準拠したコードを表す
>>681 それは君の勘違いだね。
その定義ならC/C++を区別する理由がないし、多分LinuxもC++になってしまうだろ。
>>676 たとえばヘッダファイルなんか、同一のファイルを
Cコンパイラに入力したり
C++コンパイラに入力したり
ってこともあるよな
内容には無関係で単に
Cコンパイラに入力したらCのコードで
C++コンパイラに入力したらC++のコードだろ
最適化の内容だってrestrictのように
CとC++で違ってくる可能性はあるしな
>>682 最適化の掛け忘れでは？
Cの方はほぼ最適コードだが、(メモリアクセス減らして一時変数に取れとかその程度）
C++の方は最適化無しだとトンデモコードが出てくるが、
最適化でそれを消すからおｋというノリだったと思ったぞ。
最適化無し同士の比較は意味がない。最大最適化同士の比較やってみそ。
使うモジュールの差を言語で言うから話が紛れる
>>686 gcc unko.c -O3でやってる
>>685 > 内容には無関係で単に
Linus全否定かよ。
>>682 オールゼロでクイックソート？
それは...
>>687 > 君の定義であるごく一般的な記述を行った場合の話であれば
> C++の方が速いこともあるしCの方が速いこともある
ねーよ。
実例挙げてみ？
それって単なるコンパイラの適性であって、コード自体の速度ではないだろ。
C++とCの本質的な速度差ってのは絶対にひっくり返らないものであって、
例えば、スマポを使っている限り参照ポインタを管理する分だけ遅くなる、というもの。
コンパイラがどう進化しても、「０」「ADDまたはDEC命令」の差はひっくり返らないんだよ。
> C++例外処理も有効で、
> これによって処理が速くなる場合がある
ねーよ。Cは最初から全部noexceptだ。
ソートって
clでやってみたら期待どおりの結果になった
>>677 1.789[sec]
>>678 0.623[sec]
最適化は/Ox
>>690 ああ、それは確かに
テストデータをまじめに作るか。。。
>>688 となるとアセンブラを確認するしかないね。
(いいサイトはあったはずだが、普段使わんから忘れた)
>>693 それさ、以下の3条件でやってみ。
1) Cのコード(677)を、Cコンパイラ
2) Cのコード(677)を、C++コンパイラ ←追加
3) C++のコー(678)を、C++コンパイラ
Cコンパイラってポインタ周りは最適化をかけないから、多分、
速度差はコンパイラ起因であって、コード起因では無いと思う。
>>696 > (b) 自分が書いているのは実はCだと気がついていないC++バカ
>
https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html 君の定義が正しければ、上記(b)の定義が出来なくなるだろ。
>>691 C++が遅くなる例だけあげてC++が遅いって言ってもねえ
C++が速い例
double p = 1.;
int n;
for (n = 1 ; ; n++){
p *= n;
}
C++だと例外処理をつかって、いつオーバーフローするかわかるんだけど
例外を使わないとどういうコードになるかねえ？
---
Cで普通に汎用vectorを作るとすると
普通は汎用バイナリで作ることになるんで
関数ポインタを経由する事になっちゃうけど
C++のテンプレートだとだとそれぞれ専用なんで
関数コールが速いよね
アドレス計算も即値の乗算だから色々なテクニックが使える
>>699 > C++が速い例
Java出身か？死ね
C++だとコンテナを使ってまともなソートを簡単に書けるけど
>>701 ん？
良くわからんが負け宣言てことでいいのかな？
>>684 何を言ってるのか意味不明すぎる
よほど感覚が独自なんだろうな w
>>699 おっとすまん、ポインタアクセスでのメモリオーバーフローと勘違いしてた。
doubleの無限大の例外って事？
俺はそっちには詳しくないが、浮動小数点例外をソフトウェアで検出するのなら同じだし、
ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。
vectorについては完全に君の勘違いだぞ。
Cではそれぞれ専用の物を作るのが基本であり、それを一つにかけるようにしたのがテンプレートだ。
多分、理解の仕方が逆だ。
>>699 > Cで普通に汎用vectorを作るとすると
> 普通は汎用バイナリで作ることになるんで
速度云々議論してるところでそんなことする奴はバカって言われてもしょうがないと思う
>>705 > ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。
Cだと言語の範疇ではその割り込みを処理できない
なのでif文とかでオーバーフローするのを検出するとかが必要
って話だろ
>>707 > if文とかでオーバーフローするのを検出するとかが必要
ほう。ならそのコードを書いてみ。
そしたらそのコードの中でオーバーフローするから無限ループだね。
そんな言語が実用だったとでも？
>>705 例外については「お前は頭が悪すぎて会話にならん」とだけ
コンテナは
「C++の方が遅い例だけ扱って、速い例は自分の想定と違う」
という主張を続けるならお前と会話しても無意味だ
IDが変わってしまった
ちなみに速度比較についてはいろんな人が様々やってるけど、
俺的にまあ公平だと思えるのはこれだね。俺の体感ともだいたい一致する。
おれはC++は1.1-1.3位かと思っているけど。
> C 1.00
> C++ 1.56
> Java 1.89
> C# 3.14
>
>
https://jaxenter.com/energy-efficient-programming-languages-137264.html C++の機能をバリバリに使ったら、そりゃJavaと大して変わらんだろ、ということになるし。
スマポってのは良くできたGCとコストはほぼ同じだし。（GCは全自動なだけ）
Javaは以前は3程度だったが、ゴリゴリチューニングしてきているらしい。
>>706 速度優先のコード前提ってことなら
保護されまくった高機能汎用コンテナを使うこと自体アホってことになるねえ
さらに条件を加えちゃってもう
>>708 なんで喧嘩腰なのかがよくわからないけど、
C言語では「n <= DBL_MAX」というif文が必要ってことだろ？
double p = 1.;
int n;
for (n = 1 ; n < DBL_MAX; n++){
p *= n;
}
>>714 いやオーバーフローするのは p だろ。
と思ったが、もしかして n の方なのか？
>>716 通じたようで何より。
だからオーバーフローの検出はソフトウェアでは辛くて、通常はハードウェアのはずだ。
そしてその場合は割り込みとなり、Cの場合は割り込みハンドラにコードを書くことになる。
C++の場合は『そこから例外処理ルーチンまで引っ張ってきてくれるコード』をコンパイラが用意し、
ユーザーのcatchコードを実行する。つまり、上記『』内コードでラップされてる分だけ遅い。
（実際にはラップだけではなくスタックウォークも行うから相当遅いはずだが）
なんだが、実際俺はゼロ割例外しか見てないからオーバーフローについてはよくは知らん。
ハードウェア的には上記の動作になる。
一般的にはオーバーフロー例外は出ない環境（無限大に貼り付けるだけ）で使うのではないかと。
Cではアホみたいにゼロ割チェックやってるよ。
これはC++でも同じだと思うが、C++erはやらないのが作法なのか？
とはいえ、ゼロ割はCMP+Brachであり、通常は分岐しないから、x86ではほぼゼロコストだ。
割り込みは関数呼び出し自体が遅くなるから、結局これもCの方が速いはずだが。
>>712 お前話の流れが読めてないだろ w
>>638 から読み直せ、バカ
overflowてexception吐くんだっけか
>>708 バカはこれだから w
isfinite( ) マクロとかも知らんのかよ
>>717 オーバーフローで例外や割り込みが起動することはないのでは？
普通、無符号ならキャリー、符号有りならオーバーフローのどっちかのフラグで判定するかと
unsigned long long array[100000000];
途中で書き込まれてしまった
>>698 そこの２通目に箇条書きしてある部分は
1992年当時に俺が思っていたことに近い
・例外がクソ
うん、マジクソだ
C++11以後マシになったが下痢が治ったという程度
・newいらねー
演算子newを初めて聞いた瞬間、
mallocの設計理念が大声でわめき立てた
C++11以後ブーイングが更にエスカレートした
・キーワードclassいらねー
禿自身が認めやがった
・・・しかし、それがなぜ
>>685 への反駁に引用されるのかがわからん
>>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だから
お前らが誤解したままでいるのはお前らの自由だが、
>>734 それは言い過ぎでしょ。
流石にそれは、世間を知らなすぎ、と言われても仕方ない意見にみえてきたなあ。。。
ならもうちょっと分かりやすい説明をしてやる。
>>677-678 について、お前らの定義では『コード』について議論できないだろ。
俺の定義では、677は「Ｃのコード」で、678は「C++のコード」だ。コンパイラに依らない。
お前らの定義では、678は明確に「C++のコード」だが、677については、
「Cコンパイラを通した場合、677はCのコード」
「C++コンパイラを通した場合、677はC++のコード」
になってしまうだろ。
それだと、CとC++の『コード』の速度比較自体が定義できないだろ。
677をCコンパイラを通した場合とC++コンパイラを通した場合の速度差は、
「コードの差」ではなく、「コンパイラの差」なんだよ。
当たり前だろ。
というか、C++erもここまでレベルが落ちたのか。世も末だな。
std::filesystemで片方のスレッドでファイルを出力し
>>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++以上に上手く行ってる。
お前の定義じゃないと議論が出来ないのは
面白くていいじゃないですかぁ…
>>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++で書く」→カジュアルにSTLとか使って読みやすく書く
>>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の宗教論争に加わるつもりはないが、
>>771 お前は根本的に勘違いしている。
出発点は自前のコードでもいいが、逆アセンブル結果でもいいんだから、
改善できなくとも、遅くなることはあり得ない。
アセンブラを読めない君らでは、これは無理だ。
そして、遅くなる可能性の方が高いからやらないってのは、
馬鹿な君らなりの対処法としては正しい。
まあ、C++スレではC++マンセーしないと荒らしだ、ってのは理解した。
C++erがそこまで落ちぶれたのは残念だが、俺は去るよ。
それぞれの言語の良くある使い方であれば
一般的な使い方では
>>772 以前ここに書いたこともあるけど、最近ET＋simd（SSE、NEONのイントリンシック）で
ゲーム用の自前の線形代数ライブラリとか作ったんで
＞アセンブラを読めない君ら
残念ながらこれは当てはまらないよｗ
どれだけ逆アセ読んで比較したか・・・・
＞C++マンセーしないと
お前が”正しい批判をしてれば”荒れてないんだよ
ついでに言えば、
＞「C++で書く」→カジュアルにSTLとか
STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
「流行に流されて自分で考えることを放棄する」という、かつてJavaの流行に荒らされた時代と
同じ愚を犯してるな、とは思うけどねぇ
C++er憎し、では色々と話がおかしくなるよ
同じ処理を同じ動作で記述出来ない例
もうアホらしくなって途中離脱したけど
>>775 > どれだけ逆アセ読んで比較したか・・・・
ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
それでその言い方には矛盾を感じるけどね。
> STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
その発言は俺ではないが、
基本的には抽象度を上げるのは簡単にプログラミングする為であって、
「カジュアル」という表現は妥当だ。
Cみたいに全部手でゴリゴリ書く意味なんて無い。
速度が問題ない部分は出来るだけ手抜きすべきだ。STLがそれに適しているのなら使えばいい。
ただ、「STL使わなくてもどうとでもなる奴が手抜きでSTLを使う」のと、
「STLを使わないと何も出来ない連中がSTLを使う」のは全然意味が違う。
とはいえ、俺は後者が前者になるべきだとは思ってない。
ただ、後者ならC++ではなくJavaやC#を使った方が妥当だとは思うが。
君が見落としているのは、STLをカジュアルと呼ぶ連中は、
基本的に、STLを使わずに最速な実装が出来るものの、面倒なので、
「手抜き」を「カジュアル」と言い換えてごまかしているだけだということだ。
連中は君みたいにSTLが無いと何も出来ない馬鹿ではないんだよ。
> C++er憎し、では色々と話がおかしくなるよ
これは違うぞ。俺は無知なくせにデタラメを言い張るゆとりは死ねと思っているだけだ。
ただし、お前が無知のままで死ぬ権利は尊重するので、
有用な情報は書かないようにするが。
>>772 >俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>>780 > ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
爺いは早めに滅びればいいのに
constexpr+UCS=ニューパラダイムのはずだったんだがなぁ。
昔はライブラリもそんなに充実してなかったしアルゴリズム事典とか読み漁りながら色々自作してやってたけどね
実行可能形式はC++、スクリプトはPython。
スタイルについての質問なんですけど、Cの文法で書けるならできるだけCで書いたほうがいいのでしょうか
>>792 C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
いや別に
逆に若者はコストも考えずに安易に汎用コンテナを使ったりと思うことがある
ものによるのじゃん？
バグを生む可能性が一切ないならCスタイルのほうがいいに決まってる
最近のC++は、std::vectorが配列に最適化されるのか？ 遅いだろ
C++11以降ならstd::array使うけど、覚えることがともかく多い
区間チェックしてくれる配列を簡単に指定できると嬉しいの†
例えば、[ ]を二重に書くと添字チェックしてくれるとか。どうかな。
例外投げるインデクサと投げないインデクサ両方ありますから。
>>802 attributes構文と紛らわしい。
C++のコストの大部分は例外に起因するらしい。
x86-32だと割り込み発生時に対応出来るように
>>813 組み込み開発の株式会社○○みたいなサイトで読んだんだけどな。
なかなかためになる内容だったしブックマークしとくんだった。
見つけたらリンクくれ。
俺の見解では、例外にコストが割かれるなら、それは必要なコストだと思うんだよな。
元記事消えてるっぽいからアーカイブだけど
http://bytepointer.com/resources/pietrek_amd_x64_primer.htm Windowsの例外機構がx64ではスタックベースからテーブルベースの通過するだけならゼロコストなものに変わった
ただしバイナリサイズは増える
>>816 例外を使うならコストがかかるのは当然なんだが、
例外が通過しないかもしれないのにそこかしこで情報を積まないといけないのは良くないってことなんよ。
そんでまあ例外を投げたときだけにコストが生じる方式がいいよねっていう話。
例外が発生しない時のコストなんてゴミみたいなもんだけどな
64ビット化するとサイズが1.5倍になるらしいけどな。
今時コードのサイズなんて問題にならんだろ
1.5倍って40㎏の可愛い少女が60㎏のオバはんになるってことではないだろか。
どうしても対応し続けないといけない32bitのレガシーデバイスがあるなら頑張って
32bitがレガシーだあ？
クラスのconst配列メンバをコンストラクタで初期化するにはどうしたらいいでしょうか？
>>828 できないからあきらメロン
素直にconst外してアクセサで制御するか、vector使うかしとけ
テンプレートとかを駆使して無理に実現しようと試みるのはいかにも頭が悪いし時間の無駄
constの問題というよりサイズが決まってないからダメなんじゃないの？
ここ3年ほど32bitの組み込み機器に触ったことない
今はほとんど64bitの上で無理矢理32bit動かしてるんだよ
>>829 了解です、constは諦めマスカット
>>830 どんなサイズの配列が来るかはコンストラクタが呼び出されるまでわからないんで
サイズは未定にしておきました
vc++のマルチコアのオプティマイズなんて甘々だから余裕で
そりゃあ頑張れば勝てるだろう
VCもそうだけど大体のコンパイラは並列化や自動ベクタライズは強くないと思う
>>828 template<std::size_t N>
class A {
public:
const double array[N];
template<typename ...ARGS>
A( ARGS&&... args ): array{std::forward<ARGS>(args)...} {}
};
template<typename ...ARGS>
inline auto make_A( ARGS&&... args ) -> A<sizeof...(args)>
{
return A<sizeof...(args)>(std::forward<ARGS>(args)...);
}
auto a{ make_A( 1.0, 2.0 ) };
こんな感じだろうか。
要C++11以降。
>>どんなサイズの配列が来るかはコンストラクタが呼び出されるまでわからないんでサイズは未定にしておきました
要素数が決まってないとコンパイル時に困るので、テンプレートクラスにしちゃったけれど…
参考にしてみた
https://wandbox.org/permlink/3asRA3QSPQXmmn8l C++17ならヘルパー不要にはなる・・・(コンストラクタに与えた引数から推定
けどどっちにしても配列数可変にはできない
ていうか配列の参照とか初めて使ったw
>>828 C++14のinteger_sequence使ってみた
#include <iostream>
#include <utility>
template <size_t N>
class A
{
const double array[N];
public:
template <size_t... I>
A(const double (&temp)[N], std::index_sequence<I...>) : array{temp[I]...}
{
for (auto x : array) std::cout << x << std::endl;
}
A(const double (&temp)[N]) : A(temp, std::make_index_sequence<N>()){}
};
int main()
{
double t[] = {1.1, 2.2, 3.3};
A<sizeof(t)/sizeof(t[0])> a(t);
//A a(t); // C++17
}
アンチパターンを生み出すための新機能が次々出てくるのがc++だ！
こういうのからiostreamみたいになってゆくんだろうな
つか引数にconst double(&temp)[]って何だと渡せるのこれ
何も渡せないよ
>>842 VS2017 15.7.1のVCのReleaseモードだとtemplateの部分が赤の下波線になるな
Debugモードにするとなぜか消える
そしてReleaseモードはエラーが出ているのにコンパイルして実行可能
バグじゃね
>>847 仮引数として表れる場合はポインタに調整されるんじゃなかったっけ？
配列への参照ってのはあるんだけどね
>>848 > バグじゃね
未定義ならコンパイルできて実行できると言うのも規格に準拠してる正しい動作
>>854 見当違いのレスだな
DebugとReleaseでエディタの動作が首尾一貫してないって言ってるんだがな
15.7.2が来たから入れてみる
>>855 普通の知能を持ってたら
> コンパイルして実行可能
に突っ込まれてることぐらいわかるだろうに...
>>856 15.7.2にしたらReleaseでも赤い波線出なくなったぞ
エディタのバグが直ったようだ
だから「エディタの」バグと書き忘れただけなのにお前らしつこいな
書き忘れとか知らんがな w
>>859 気にするな。俺には
>>854 の方がよほど的はずれなことを言ってると思うよ。
>>861 >>856 同じようなレスを書いてループさせるのも低能にありがちな行動
未定義の意味を理解してないなら絡んでこない方がいいぞ
エラー
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
この文脈でエラーとか警告とか言い出す時点でアホ丸出しなんだが...w
VisualStudioはインテリセンスとコンパイルに使うコンパイラが違う
あるコンテナaとコンテナbを連結？するようなクラス（イテレータ）を作りたいんだが
>>871 concat_iteratorでググるとそれっぽい実装がチラホラ
C++で2Dのwindowsで動くゲーム作ろうと思っているのだけど、ライブラリって何使えばいいんだ?
windowsに限定するならopneGLにする意味は薄い
DirectX tool kit なるものは一般的なDirectXの上位互換みたいな捉え方でおk？
Siv3D とかも楽に使えると思う。 (3D という名前がついてるけど 2D もいける)
今の時代なら cocos 2d とかモバイルでも使えるライブラリ使った方がいいんじゃないのか
string::size_type についてですが、
>>893 ありがとうございます。
string::size_type は companion type というものらしいのですが、
この companion type とは何でしょうか？
メンバ関数の引数や戻り値、メンバ変数などで使用するためにクラススコープで定義された型のこと
クラス(この場合はstd::string)を利用する側は、
実際にはその型がなんであるかを知る必要なく
文字列のサイズの型としてstring::size_type を用いることができる
参考
https://stackoverflow.com/questions/41471741/string-companion-types std::threadでサブスレッドで処理をしているのですが、処理をキャンセルするためthreadをdetachすると
>>897 スレッドローカル記憶域とか破棄されたあとにアクセスしてんじゃないの？
std::threadのdetachってスレッドを手放すだけでキャンセルはしないのでは
一般にスレッドのキャンセルは難しいので適当に処理を終わらせてjoinするのが良いも思う
https://ideone.com/3LDXGx 質問です。定期的に同じ関数をスレッドで起動するクラスを作りました。
んでコード中のここ無駄って書いてある行を削除する方法はありませんか。
開発はVCでやってますが、GCCでも通ればいいなーと思っています。
すみません。言葉足らずでした。
メインスレッド：GUI、サブスレッド：既存のライブラリでデータ補間の重い処理
を担当していて、途中でデータ補間パラメータを変更したくなった場合
キャンセルボタンを押してやり直す、という処理を考えています。
CPUは複数コアあるのでサブスレッドが走り続けてリソース開放が遅れるのは
構わないのですがjoinするとそこで処理終了まで待ってしまうのでdetachしたいわけです。重い処理のループの中にキャンセル用フラグでも用意できればキャンセル通知後
ループを抜けて速やかにjoinするところまで到達させる等の方法があるのですが、
既存ライブラリなのでそうはいかず諦めてdetachしようと考えています。
そのまま走り続けるだけだから結果を回収せずほっておけば良いのかと思ってましたが
甘かったみたいです。
>>898 thread_localは使っていないです。
>>899 アドバイスありがとうございます。関数オブジェクト作ってキャプチャは使っていないです。
>>901 スレッドを平和理に終了させる方法はなさそうなのでdetachできなければ諦めてjoinするしかなさそうですね…
とりあえず最小の再現例を作ってみることにします。
重い処理の方を別プログラムのプロセスにしちゃって止めるときはブチ殺すのがシンプルで良さそうに見える
>>903 async つかえ。
wait_forっていう関数がプロミスにある。
基本的にstd::threadでキャンセルは不可能。
強引にスレッドを殺すと、
そのスレッドが使用するメモリ等のリソースを全て
スレッド終了まで保持していても
>>897 ＞メモリを破壊しているようで全然別の箇所で色々なエラーが出てきます。system_errorは送出されていません。
となるなら、そもそもそのライブラリがスレッドセーフじゃないのかもしれない。
>>904 式に別プロセス化するのが一番なのかもね
ぷぅうううううううううりいいいいいいいぃいいいいいいいいいずへーーーーーーーるぷみーーーーーーーーーー。
関数の中にif(cancel)return;みたいなのを大量に仕込んで外からフラグを立てて止めろ
基本的にはフラグで止めるか別プロセスで実行するのが定石だが
join なんて、カラクリが良く分からないものを、よく使う気になるなぁ
joinが嫌ならdetachすればいいのよ
世の中には信じられないメンタリティの人がいるもんだなあ
標準ライブラリが嫌ならpthread使えばいいのよ
いろいろアドバイスありがとうございます。
どうもdetachした後に局所変数が確保されるとスタックを破壊してしまうようで、
局所変数を確保する前に
>>911 氏のいうようにif(cancel)return;入れるとLinuxでは落ちなくなりました。
ですが、windowsでは改善せず諦めました。atomicにするのものも面倒ですし。
結局キャンセルするときは結果を回収せず、さらに別スレッド立ち上げてjoinすることで
メインスレッドのGUIに制御が戻るようにしました。長期的には別プロセス化するしかなさそうですね。
ありがとうございました。
> 既存ライブラリなのでそうはいかず
って書いてあるのに
>>905 ,
>>907-908 ,
>>911 とかバカなら黙っとけよ...
913はスレッドを自爆させた後joinしないのであろう…
子スレッドが一つならjoinで待っててもいいけど、複数個になったら無限ループで待つよね
ていうか「重い処理かつ終了に時間が要するスレッド」複数個を所有するサーバみたいなスレッドを一発噛ませて、
>>921 ウィンドーズならWaitForMultipreObjects()とかその亜種で複数の終了待ちができうる
そうでなくともイベントフラグの同時待ちはだいたいどんなマルチタスクOSでもできるから
それを使って類似のしくみを作れうる、。
>>923 できうる、作れうるって日本語的におかしいだろう
ウインドーズとか何か別物感あるし、multipleのスペルもおかしいし大丈夫か
色々なところで糞が露呈している
デザインとしては Windows の方が現代的なんだけど、
POSIXに準拠できないWindowsがどうかしている
>>928 昔は POSIX 準拠にしてたよ。
アメリカの政府が採用するのに POSIX を要求してたみたいで、仕方なくやったって話。
だけど、基本的なモデルが違うものに API だけ接ぎ木してもなぁ。
windowsでpthread使うたびにトラブル起こってつら
>>921 他に条件があるならともかく、普通にjoinで待てばよくね？
>>931 別に、joinで済むならjoinでいいんじゃね
キャンセルしたくなるほど長い処理ならスレッドキューイングする利点はない
C++を使うなら、Windowsでいいんじゃないの。
サブスレッドでjoinして結果を使わない、というのとデタッチするのとどう違うんやろな。デタッチってなんのメリットあるんやろか。
自分で書いてる通り結果を使わなくて終了も待ちたくないなら join せずデタッチ。
連結リストのクラス list があります。
・stack : protected listとして、必要なメンバをstackで明示的に公開する。
・assert、throw等で警告するだけのaddFirst、removeFirstをstack側に作りオーバーライドし、規約で使うなと言っておく。
・基底クラスbasic_listを設け、そこからlistとstackを別に派生する。
>>935 釣りか？
MSYSがあるからなんとか我慢して作業できるが
仕事以外でそんな苦痛を受けながらプログラミングなんかしたくはない
wslを有効にしてコルタナにウブンツと言えばすぐ使えます。
wslでWindowsネイティブなバイナリ作れんの？
>>944 > 仕事以外でそんな苦痛
でもどんな苦痛なのかは書けない w
さあどうだろ？
俺のおすすめの使い方は、Windowsバイナリはcl、Linuxバイナリはwsl上のgccで作る。
>>939-943 ありがとうございました。
Macを使っている人はいませんか？
コンピュータサイエンティストって大抵Macのノートパソコンを使っているイメージがあります。
>>952 mac使ったところでmacしか使えないだけ
本物になりたいならシェアが高いウインドゥスを使え
もしくはLinux
>>952 念の為、標準ライブラリにlistもstackもあるからね。
あと標準ライブラリのlistは継承して使えるように設計されてないからね
リスト構造のスタックなんて簡単なんだからゼロから作っちゃえば？
push pop size
stackはlistではないし継承は間違ってるわな
俺、リストツリーっていうの考えたんだけど、聞きたい？
>>953 >>955 ありがとうございました。
>>956-959 実は、
最近出版された岩沼宏冶他著『データ構造とアルゴリズム』（コロナ社）
という本にスタックとキューのそのような実装が書いてあるんです。
まず連結リストをテンプレートを使って実装しています。
その関係で質問しました。
まえがきに「本書の前半ではC++言語での実装コードを示すが、これは
初学者によいコードを読ませることが目的であり、Art of Programmingに
つながるような解説を付記するように努力する。」と書いてあります。
下手が伝染るから、クヌースを取り寄せしたほうが良いぞ
>>965 横レスだけど複数スレッドがあったとき
・どれかの終了を待つならjoinでは無理
・全ての終了を待つなら適当な順でjoin
というだけのことでは
>>938 そういうことをやるなっていうのが「リスコフの置換原則」
「外から見えるインターフェースが変わらなければ
派生クラスのアクセス制御、と書くべきだったかな。
>>932 言葉足らずだったｽﾏﾝ
スレッドハンドルの配列があったとして、[i]についてjoinしたら[i]を再利用できる（再びスレッドをcreateしなおせば良い
、の意味
joinせずとも済むやり方もあるが、
（「重い処理かつ終了に時間が要するスレッド」の関数本体をそのままスレッドにするのではなしに、
普段イベントを待ち、イベントが来たら「重い処理かつ終了に時間が要するスレッド」の関数本体を普通にcallし、そいつがreturnしてきたら
再びイベントを待つ、というループするスレッドとしてwrapすれば良い、等
結局「重い処理かつ終了に時間が要するスレッド」が使っていた資源が開放されたことを論理的に知る必要からは逃れられず、
一番簡単なのがjoinですよという意味で
>>922 ではjoinと言ったので察してﾎｽｲ、
ほむほむ、ところでgtestとBoost.Testはどっちが良いですかな？
>>972 自分でこれまで勉強した範囲で疑問なり興味なり沸いてきて、あれこれコード書いて試して見ようとしたことは無かったの？
もし全くないのならもう諦めた方がいい。
>>972 純粋な言語部分
プリプロセッサ
標準ライブラリ
特定のOS, 特定のライブラリ
組み込み
どの辺の課題？
「計算機プログラムの構造と解釈」（SICP）を読んで演習課題を解いたら良い
>>975 まだ scheme 手習いが終わっていないのです（泣）
リトルインディアン、ビッグインディアンも教えない職場があるんだな。
>>977 周知のこととして扱われているのかもしれませんね。
私は学校で教わりました。
>>977 インディアンかー
俺も教わった覚えないな
One little, two little, three little Indians
エンディアンなのかインディアンだったかいつも忘れる
「リトル・エンディアン」「ビッグ・エンディアン」て用語は
>>985 それはほんと、小人国での卵の割り方にちなみます
>>977 今どきバイトオーダー意識するようなプログラム書くような職場じゃなきゃ教えないよ
アライメントなんかも同様
SEなら尚更知っておかないと
>>986 調べたら小人同士の戦争の原因なのね。巨人国は関係ないな。
実は空の国の「学者の無意味な論争」の一例だと思い込んでいたんだわ。
>>989 「ウチはCのコーディングスタイルとしてAT&T式を基本とします」
ってところはあるかも知れん。
何でもネットに繋がらなきゃならないこの時代にhtolやltohを避けて通れるもんなのか？
今時C++と言えどhtol()とかltoh()なんて低レイヤーの関数使うことなんて滅多にないだろ
>>995 ソフトウェアがなんでもかんでもネットワークに繋ぐ必要があると思ってるの？ここC++スレだぞ
C++使うくらいだからXMLとかJSON使うんだろ
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/tech/1522495206/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「C++相談室 part135 ->画像>4枚 」 を見た人も見ています：・C++相談室 part152 C++相談室 part153 C++相談室 part154 C++相談室 part156 C++相談室 part155 C++相談室 part148 C++相談室 part124 C++相談室 part157 C++相談室 part164 C++相談室 part133 C++相談室 part137 C++相談室 part136 C++相談室 part144 C++相談室 part143 C++相談室 part146 C++相談室 part134 0からの、超初心者C++相談室 Cygwin + MinGW + GCC 相談室 Part 8 C♯相談室 Part20 自営業 悩みごと相談室 16 C#, C♯, C＃相談室 Part93 自営業 悩みごと相談室 52 C#, C♯, C＃相談室 Part94 C#, C♯, C＃相談室 Part91 MFC相談室 mfc23d.dll C#, C♯, C＃相談室 Part97 C#, C♯, C＃相談室 Part98 自営業 悩みごと相談室 48 C#, C♯, C＃相談室 Part95 C#, C♯, C＃相談室 Part91 自営業 悩みごと相談室 51 自営業 悩みごと相談室 47 自営業 悩みごと相談室 41 自営業 悩みごと相談室 46 【不倫.浮気】お悩み相談室 C#, C♯, C＃相談室 Part94 0からの、超初心者C言語相談室 【男飯】Rickの相談室【言霊】 ライダーマンのお悩み相談室 【イエス』ユダの相談室【口寄せ】 [特設]サマータイム対応相談室 ♪♯☆ IRCnet相談室 part2 ♪♯☆ アパート経営なんでも相談室【135号室】 ■コンサル田中の経営相談室。■ 【太気拳】なんでも相談室 part6【意拳】 【真剣相談】大阪市営住宅の浴室給湯器設置 アパート経営なんでも相談室【136号室】 【太気拳】なんでも相談室 part3【意拳】 シーバスなんでも相談室 17©3ch.net MM（MI）型カートリッジ相談所 第5会議室 【ハゲ】髪の毛の悩み相談室 in DQO【彡⌒ミ】 黒田塾黒田広史行政書士相続まちがど相談室非弁 アパートマンション経営なんでも相談室【152号室】 【NTT】ドコモ お客様相談室【docomo】 アパートマンション経営なんでも相談室【154号室】 アパートマンション経営なんでも相談室【151号室】 アパートマンション経営なんでも相談室【150号室】 アパートマンション経営なんでも相談室【137号室】 黒田広史行政書士相続まちがど相談室非弁高額報酬 アパートマンション経営なんでも相談室【154号室】 アパートマンション経営なんでも相談室【153号室】 アパートマンション経営なんでも相談室【154号室】 No A012-2 【ジャマイカン恋愛相談室】広告対策 アパートマンション経営なんでも相談室【158号室】 アパートマンション経営なんでも相談室【155号室】
11:59:57 up 62 days, 12:58, 0 users, load average: 10.76, 9.56, 9.49
in 2.8670189380646 sec
@2.8670189380646@0b7 on 061900
