◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:【初心者歓迎】C/C++室 Ver.104【環境依存OK】 ->画像>3枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1545944692/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります
コードを貼れる所
http://codepad.org/ https://ideone.com/ 前スレ
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://2chb.net/r/tech/1530384293/ c++builder10.3 community
わけのわからん言語をこねくり回して、つまらんことしてちゃ、つまらん。
>>997 UTF-8 は char * に入れるもの
char32_t * ならぎりぎりセーフ
wchar_t * は wcs 用
UTF-32 を wchar_t * に入れる
utf8は漢字仮名に3バイト使ってることわかってんのか
調べる羽目になるっていうけど、たったそれだけのことでしかない
>>8 c++17は調べてないが、
char32_tだと文字列処理のライブラリも正規表現も使えないだろ。
既存のライブラリ使うためにまた変換するのか？
>>9 たったそれだけて、文字列処理なんか主たる作業じゃないC/C++プログラマにとっては、
utf8の文字コード常に思い浮かべながらコーディングするなんてのは不快極まるだろ。
*x == 'あ'
これが書けないことがたったそれだけかよ
そもそもchar32_tてutf32用だろwwww
このなかで一番美人なのって真ん中だよね？深キョンレベルだと思うのだが
ちなみに向かって右は目も鼻も整形してるって本人が公言してるけどそれ抜きにして誰が一番美人だと思う？
http://bigsta.net/media/1933567086757747003_3564907098 VSだとwchar_tは16ビットだろ。
次から次へと嘘を並べるのがウリナラ
環境：Win10/VC++2015
>>18 selectは「複数ソケットのとき」という先入観があったのですが、
1ソケットのときでも使うんですね。
ありがとうございました！
gccでしか確認してないが、warningは出るんだが
【ＴＯＫＩＯがまた被曝を応援】 「不勉強」「操られている」のはローラではなく、安倍と食事した奴
http://2chb.net/r/liveplus/1546137382/l50 >>21 いったいいつの時代の話してるんだ古すぎるんだよ情弱
C++17から問題なく使用できる
情弱がねごとほざくからそのたんびにイラン労力強いられることとなる
どうせだったら、utf8専用のchar8_t型も用意しといてくれたら良かったのに。
教えてください。
>>27 それ以外の何を望むの?
特定場所への挿入v.insertぐらいしかないじゃん
27です。レスありがとうございます。v.insertでうまく行きました。
>>30 まともなpush_backの実装なら対策されているので問題ないはず。
無対策でも明示的にコピーコンストラクタを呼べばうまくいかくも。(要素の型をTとする)
v.push_back(T(v[2]));
あ～そういうことか
>>27 意図しないエレメントが追加されてしまうC++は何？バージョンも併せて教えてよ
環境書くのを忘れてました。すみません。
>>32 まともでない実装ってのはどのテンプレート？つかコンパイラ？
>>35 thx
なるほど10年前のコンパイラならstlにバグ残ってる可能性あるわな
2011、2014、2017でずいぶん新しくなってるよ
仕事で2008指定されてるとかじゃなければ2017入れて損することあんまないと思うけど
さすがにvectorではまともでない実装にお目にかかったことはない。
マジかよ MFC 最低だな！
vsに2011ってのもあったのか、いやあ勉強になるなぁ
>>31 参考になりました。ありがとうございます。
gnuのobstackってざっくり理解するなら普通にデータ構造としてのstackのいち実装って認識であってますか？
Privateにメンバ関数を置くのって別にいいですか？
いいんじゃね？
デバッガってどう動いたら正常なんでしょうか
リクツを語ると
Win32APIなんですが、
>>56 そちらはスレが盛んでないので、こちらでお聞きしました･･･
>>55 http://eternalwindows.jp/control/controlbase/controlbase06.html http://chokuto.ifdef.jp/urawaza/api/SetWindowLong.html SetWindowLong 関数で変更されたそのデータは SetWindowPos 関数が呼び出されるまで反映されません
👀 >>59 SetWindowLong()後にSetWindowPos()はコールしていたのですが、
WM_SETICONをSendMessage()するときのアイコンハンドル取得方法がまずかっただけでした（汗）
（LoadIcon()のHINSTANCE引数が正しくなかった）
今は問題なくアイコンが表示できています。
お騒がせしました！
>>60 https://g.co/kgs/ZEZu9X 👀 >>57 盛んでないなら先ず盛んにしろよ
欲しい者は先ず自ら与えると言うぞ
C++て3年周期で新規格リリースされるんだなC++20が来年発表て、
C言語の需要はそういうところじゃねえの
>>65 もしそうしたければ古い版の規格で書いてもええんやで。
C++20 が出ても C++11 が消滅するというわけでなし。
まあ主要なコンパイラがサポートしなくなったらしょうがないけど……
C++11が神過ぎる。
>>67 言語って自分だけで済まんだろ
キャッチアップしていかんと人の書いたコードが読めなくなる
こんな短期間でアップデート繰り返すんじゃなくもっと精査した上で規格変更しろといいたい
アップデート繰り返す度にユーザ減少してるだろ
>>66 new/delete無造作に使ったコードを組込なんかで書くと、
メモリフラグメント作りまくるだけだからな。
ハードウェアの一部としてRTOS上で安定動作させるためには、
ポインタ使いまくりのbetter Cとして書くしかない。
4kB メモリのRL78でコード書いてみろと
>>69 C++の良かったのは仕様が枯れてることだったのにな
今は逆を逝っててどんどん人が離れて逝ってる
utf-8の文字コードが格納されてるchar配列から、デコードされた文字をstd::string型に入れる方法を教えてください
>>72 aiの最後にnull文字は入れないの？
入れないなら
srd::string str { ai, sizeof(ai)/sizeof(ai[0]) };
>>69 時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。
一度の変更が大量になるよりは小さな変更を頻繁にした方が良いというポリシー。
その方が実際の運用で出た問題をフィードバックしやすいという利点もあるしな。
>>73 配列の大きさを知るには std::size か std::extent を使えよ。
C++ には C 以来伝統の sizeof / sizeof 以外に
ちょっと知ったかは、よくよく初心者を馬鹿にする。
std::sizeが使えなかったとしても(主要なゲーム機の環境の1つはC++14止まりだし)、テンプレートで取得するのはC++の移植性には影響しなくないか？
ていうかGUIとかマングリングの統一とかvtblが最初に来ることとか
配列の要素数を取得するだけのものを自分で書くならこんな感じかな。
C++標準じゃないけどVC++の_countofが重宝してる
>>75 >時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。
同じ訳ないだろが、
仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。
auto_ptrはどーした。
だから3年なんて製品のモデルチェンジ並の仕様変更じゃなく、言語オタク共がもっと時間をかけて精査して、
10年に一度ぐらいの変更にしとけってこった。
そもそもCのプリプロセスだったわけで、
Cとの整合性は確保した上で双方同時に仕様変更しろといいたい。
だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？wwww
3年ごとなのはいいと思うけど、クラステンプレートの引数推定なんか
>>84 > 同じ訳ないだろが、
> 仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。
同じだよ。
散々使ったからようやくわかったことで、ただの言語オタクどもがどんだけ理屈をこねた
ところで現実的なプロダクトの実際なんかわかりゃしない。
精査をしっかりすれば事前にどうにか出来てたと本当に思うのか？
> auto_ptrはどーした。
これはまあ……アレだ……
これ自体は擁護しようがないほどアレだけど、
一番アレなのを抜き出して言うのもちょっとどうかなって。
強いて言えば、当時としてはスマートポインタという概念を提示出来たという
成果といえなくもないんじゃないかな……。
> 10年に一度ぐらいの変更にしとけってこった。
> だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？
そうならないために言語オタクにゆだねない (実際の運用で見極める) という選択なのに、
お前はもっと言語オタクに活躍しろって言ってんだぞ。
おかしいだろ。
仕様変更が止まってる言語はともかくとして仕様策定のない言語に比べればC++の更新スパンは割と長い方という認識がある
まぁ、TypeScriptは年6回updateしてるけど次が待ち遠しいな。
426名無しでいいとも！＠放送中は実況板で2019/01/10(木) 18:17:49.03ID:b7PfIJnh0
古いという感覚を持つと話をしただけで古いものが悪いとは一言も言っていないが……？
これな
>>82 配列の参照のsizeofは配列のサイズじゃないから害はあるな()
>>84 は面白いよな、散々使うことで問題が見付かるって自分で初っ端から言ってるのに「だからスパンを長くしろ」つまり散々使うことが出来ないようにしろって言ってる
そして最後には言語オタクのセンズリかって、言ってる事が弾けまくってるな。
言語オタクのセンズリになってるのが不味いから、積極的に一定毎に更新するようにしていってるんだがな
おれは
>>84 に同意だな
数年で更新ってそれがどれだけワークしてるのさ
だいたいどれだけ認知されてるのかようわからん小さい機能追加が山盛りな一方で
大規模なconstexprとかひかえめにいって大クソじゃん？
理論もなければ、現実のワークフローなにも考慮にはいってない
結局オナニーでしょ、何オタクかはしらんが
1.仕様が確定してからでなければ実務には使われない
>>97 c++14のconstexprは条件分岐とかループにも対応してるから、そこそこ使えるよ。
文字列リテラルの長さを取得する関数とかも定数化できるし。
テンプレートの非型引数をあれこれする関数を定数化したりとか。
機能追加したい人が、ブランチして機能追加して実務で実証して、
仕様を確定させないと各コンパイラでの実装と互換性チェックとか出来ないし、
>>99 その程度の最適化はコンパイラが勝手にやればよくね？
もっと大規模なことしたいからわざわざconstexprなんてキーワード追加して
かつ人間様がわざわざそれを指定するんだろ？
で大規模なことをできる仕様か？あれが？
どうせみんなデバッグするときにconstexprをはずしてんだろ？
アホと思わないか？
>>103 Visual Studioでしか試してないけど、わざわざ外さなくてもデバッグビルドでは定数化されないのが普通じゃないの？
constexpr相当を勝手にやられたら、参照してるほうがリコンパイルが必要か判断できなくなるんじゃないの？
constexpr指定を使わずに同じような定数化を自動でやるとなると、
定数畳み込みなんて古典的な最適化手法だし、
その最適化をコンパイラ依存でなく標準規格化したことに意味があると思うんだけど。
珍説どうも
constexpr 相当のことはコンパイラが最適化で頑張るのが筋だというのは
pythonやmatlabみたいに配列やvectorを:とかでスライス抽出できないんですか？
技術スキンだけ高い奴が、できる奴と思い込んでるチキン。
++20のfilterでスライスみたいな事ができるようになる
>>110 constexpr指定はコンパイラにはわからない関数呼び出し先で
定数化できる計算であるとコンパイラに教えられるので
指定できるならした方がいいだろうけど
＞本当に速度が必要な個所のチューニング
そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
まず滅多にないんだけどね
>>115 >> 本当に速度が必要な個所のチューニング
> そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
> まず滅多にないんだけどね
constexpr はコンパイラに対するヒントであるだけでなく、プログラマにとっての制約でもある。
「そういう (速度が必要な) 箇所」であるにもかかわらず実行時の値に依存しているということを
プログラマが気づくことが出来る (ので分離するなどの工夫をする機会があるかもしれない)
というのは十分に便利だよ。
わかってないな
あと、
オフラインで複雑な計算して、結果をバイナリで埋め込んでおくことはよくやる
>>117-118 やりたいときに出来る方法があるというのは無いより「マシ」と私は
>>110 で述べたが、
それが君にとっての妄信なのかい？
要するに、 constexpr の成果は限定的すぎると言いたいんだろ？
ほとんどの機能は個別に見ればどうでもいいような些細なものなのは普通のことだ。
何度も言ってきたが、負けを認めたら死ぬ病気なのか？君は
>>122 じゃあ何が問題なんだい？
指定できるならした方がよくて、指定できるようになってるのは指定できないより良いというのなら意見は一致してるじゃないか。
＞本当に速度が必要な個所のチューニング
(途中送信してしまった)
>>125 速度が必要な個所が「なるべく」移植性が高い形で表現できればそれに越したことは無いし、
更にそれ以上が欲しいなら移植性を犠牲にすることも出来るんだから、
constexpr の導入に何の問題もないだろ？
C++で有名人になりたいです
>>128 c++ のコンパイラを c で記述すれば、それだけで有名になれると思います
gcc が c から c++ になったときは心底残念に思っていました
>>94 はちみつなんとかもそーだけど、
おまえもほんま馬鹿やね。表面しか読めないんだな。
10年間、言語オタを隔離してしまえといってるのだよ間抜けちゃん。
世の中から隔離された世界でせんずりこいてろといってる。ザーメン臭でくさいやつは地上に出るな。
大体、大規模プログラミングはすでにC++には向かないことが露呈して久しく、
せいぜいbetter Cとして生き残るぐらいしか道はないのにどういう意図を持っての3年ごとの改訂なんだ。
ポリシーなき改訂ははた迷惑なだけ
これだけ頻繁に改訂されると、スペック以外の解説本では、すでにストラウストラップ本自体改訂をキャッチアップできてない。
その邦訳ともなればますます現行仕様から浦島太郎になるのは必至。せっかく覚えた頃に新スペックの登場か？
C++初心者はいったいどの本買ってるのさ？キチガイ言語オタ江添本でも買うのか？
結局、ユーザー減少させてるだけだろうが
もしかして、最初の「なる」はNULLと掛かってる？
>>131 一応買ってみました
でもどうせコンパイラ作るならC++でClangとかの実装を勉強したい
C++好きな人って、C‡‡、Java嫌いな人が多いのって偏見ですか？
>>132 C++ の言語としてのポリシーはこのように提示されている。
Stroustrup 自身がその著書に書いたもの。
委員会の公式な文書にするとかどうとかいう議論はあったけど、
結局どうなったのかは知らない。
・C++ の進化は現実の問題をその動因とする
・完全主義にはこだわらない
・C++ は今現在役に立つ言語でなければならない
・人に何かを強制しない
・静的タイプシステムに対する暗黙の違反が無い
・同じ機能なら人に教えやすい方を選ぶ
・C のプリプロセッサは使わないように
・C との正当でない非互換性が無い
・C++ 以外に他の低レベル言語を必要としない (アセンブラは除く)
・使わない機能はコストを発生させない
これらの考え方に基づいて今要求されているものが (不完全でも) より素早く反映しやすくする
リリース体制として ship train model が導入された。
多くの人が関わるので妥協はあるだろうが、一環したポリシーの下で改定されている。
そのポリシーを気に入らないでいる自由はあるし、それはどんどん主張して良いが、
ポリシーが無いというのは事実誤認だし、自分にとって妥当ではないからといって
必要としている人を侮辱するべきではないよ。
俺が以前「D&E読んでないのか」、って言ったせいではちみつはD&Eの受け売りするようになったな・・・
http://i-saint.hatenablog.com/entry/20101012/1286822888 「あるプログラム言語を使うためにその言語の弁護人になるべきではない。」
そういうただの弁護人になってるバカは大抵C++を実用レベルで使ってない人間ばっかりだ
>>140 ？
このスレで言われたから読んだということは無いはずだが、どの発言のこと？
正確に覚えてないけど
私が持ってるやつは (日本語版の) 初版だからたぶん 2006～2007 年頃には読んでるはず。
現実的な問題があるならそれは解決されなければならない問題であって、
>>138 回文には気づかなかった。
「なるな」「人間に」がそれぞれ反転同一で、
それらフレーズを反転同一になるように並べて作成した回文か。
「人間になるな人間に」でも構造的には同じね。
いくらかPPAPな感じがしないでもない。
あと、正規表現のパズルっぽくもある。
酢にピリッとした風味を足すのに使えます
はちみつと関係ないと思ったけど、餃子の方には関係ありそう。
真摯かねぇ・・・・希望的観測で詳しくないことに首突っ込んだり
>>145 風味って鼻から空気が出る時に感じる食べ物の香りかと思ってたわ
c++が対象にしてる現実問題って何だ？
c++で書かれたc++のコンパイラのことだろ
じゃあLLVMのコーディングスタンダードこれな
https://llvm.org/docs/CodingStandards.html 例外、RTTI、iostream使わない
現実に使えるソフトってのはこういう制約で作るわけだ
C++の標準化やってる連中はメタプログラミングで遊んでるだけ
現実問題なんて何もわかってない
だから、ブラウザ、ロケット射的距離のシミュレーション、機械学習
>>153 初心者ってのはC++の例外のバイナリモデル説明できねーやつのことな
>>154 でC++がそれらに対してどんな問題解決してくれたんだ？
>>152 そこらへんはしゃーない。 便利な機能も害悪な場面は有るし、
ある時点では有用だったものが後には足を引っ張ることもある。
あるプロジェクトで縛りを設けるからといって
それが現実の全てというわけではない。
ただ、例外を使わない方向というのは大きなプロジェクトでは
そこそこあるかも？
>>153 例外が忌避されるのは他の言語と接続したときに、
呼出した側が例外を捕捉できないというのが致命的で、
つまりはそういった場面が想定されるようなライブラリでの一般的な規則。
外へ出る前に例外を全部キャッチしてしまうってのでも、
まあなんとかならんことはないが、
近頃では std::optional を活用した方がいいという雰囲気はある気がするね。
Go や Rust は最初からそういう方向だし。
このスレ、初心者を見下す者ばかりだし、
optionalはヒープ使わないだけでnullと大差ない
趣味でC++齧ってるやつと本気で仕事としてやってるやつじゃ格が違うんだよ
C++では好きなだけ効率を犠牲にして安全を手にすることができる
業務で使ってない素人は平気で例外禁則とか言って返り値チェックで死ぬほど汚いコード書くんだよな
まぁ業務と違って趣味は時間を無駄につぎ込めるから
>>163 例外禁止されるのは業務の方だろ
一見汚くなるがそちらの方がバグが少なくメンテしやすいという判断で
トップダウンで強制される
趣味なら最新の機能ばんばん使って自由にやりゃいい
実際には例外を禁止するとバグが増えてメンテしにくくなるんだけどな
そのソフトが気に入らないなら、
単なるエラーを返すのに例外機構みたいな大域脱出って牛刀感あるよな。
エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業
なあに、例外のcatch漏れや例外安全を欠いていないか注意するのと比べたら
>>179 そのへんはチェックするツールとかあったりしない？
知らんけど。
実はキャッチ漏れは戻り値処理漏れよりはるかに少ない
同じ理由で、忌み嫌われてるgoto文も、実はけっこう便利だと思う
正しく使えば何だって便利だし、
>>183 >>180 プログラミング辞めてツールでチェックしてもらえば？
>>180 それが検査例外じゃないかな。
いろいろ批判もあるけど、例外の内容に応じてそれぞれ異なるリカバリを確実に行うことを
保証する手段としては今のところそれ以外無いかなと思う。
まぁ、erlang/swiftあるいはgoのpanicのように、エラーの種類なんて気にせず「この下の
処理が失敗した」とだけ捉えるのが例外の扱いとして妥当なところかも。
>>181 使い捨てでないまともなプログラムはいたるところにエラーリカバリー処理が入る
つまり例外だといたるところにtry catchかつ外に投げる例外は誰がcatchするのか仕様が複雑
仕事で大規模なプロジェクトに関わったことない人はこういうのが理解できていない
例外押しのやつはどうせほとんどcatchせずにそのままexitさせてるだろ
例外が有用なのってネットワークとストレージのioぐらいという認識
>>188 そういうバグが原因の例外はcatchしなければいいんでは？
>>189 だから現実的にそういうのに例外をなげる仕様にありがたみがないでしょ
>>190 なんで？SEGVも起こさずに潜在的なバグとして残り続けるよりよくない？
>>191 自分でcatchするならtry catchがうざい
バグ扱いでcatchしないならそもそも例外投げずにpanicされた方が調査が楽
また下手にどこかでcatchされたらバグに気づかない危険性がある
以上の理由により
ID:cHsPUmRi ってcatchで全ての例外がキャッチされると思ってるのか？
例外が発生しました
例外機構は誰がキャッチするのか別の問題を作った
>>197 エラーを返却値で返すことにしたところでそれは同じでしょ。
どこまで上に (返却値によって) 伝播すべきかってのは
どこでキャッチすべきかと問題は同じだよ。
ダウソファイルのファイル名置換する簡単なプログラムをC++とC#で書いてみた(C++で作って、それ見ながらC#に変換した)
リターンコードスタイルにすると
>エラーコード追加時に全ての呼び出し元を精査しなければならない
>>203 返り値でエラー通知するようなセピア色の世界にいるとわからんかもしれんが普通に解決するぞ
参照透過性ってそういう意味だっけ？w
>>203 リターンコード方式や例外と参照透過性になんの関係があるんだろう…
>>205 > 最近例外ない言語増えてる事実はどう考える？
Go以外にあったっけ？
まぁ、実際関係ないね。
「呼び出し元を精査」とかプログラム内のデバッグに例外使ってるような書き方やね
戻り値形式ではそもそも式として書けないから参照透過性もクソもないということをまずは理解しろ
Real Programmers Don't Use Exception.
>>206 rust
swiftは最初なくて後で追加
積極的に使うスタンスでない
>>209 そこに丹念なエラー処理を追加していくと、あら不思議どっちもあまりかわらない
>>211 それってやっぱりいるじゃん
ってことだよね w
>>212 え？
何言ってるの？
エラー処理ってなんのこと？
具体的に書いてみて
>>213 エラー処理って言ったらまぎらわしかった
異常系の対応ってこと
何にでも丹念なエラー処理が必要になることはないし
>>214 エラー処理でも異常系の対応でもいいから具体的に書いてくれよ
>>209 程度ならたいしたことないだろ
>>216 具体的にするには前提がいるでしょ
f、gは外部から与えられてる関数で中身を書き換えることはできない
かつ至る所で使われている
p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
異常の場合は何かおかしかったの後で調査できるようにログに残す、
または人間にフィードバックしてリトライさせる必要がある
製品レベルのソフトウェアならいたって普通の前提と要件
これを実現するとどうなるかは想像つくでしょ？
おれは例外否定派ではないよ
役に立つところは限定的と言う主張
>>188 がおれだから
まぁ確かにどちらかで言えばなくてもいいとは思ってる
ただ現状C++の標準ライブラリは例外ありきの設計に突き進んでいるから
エラーコードで突き進むのは筋が悪いのは確か
>>218 > p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
意味わからん
コード書けないならそう言えば？
普通は馬鹿に割く時間がもったいないからコード書けません
信者ですらわずかなサンプルコードを書くのをためらうほどには戻り値スタイルは厄介な代物ということがわかったね
勝利宣言の後で申し訳ないけど
やっぱり例外機構はオカルトだった。皆が長い間この迷信に惑わされ疲弊した
>>231 >>225 でcatch書かなきゃf()やg()で発生した例外はそのままh()の呼び出し側に伝搬すること知らんのか？ ほらな言った通りになった
戻り値スタイルはただ異常処理を上位に委ねるだけでも多量のコードを書かなければならない
だから本当に処理すべき異常や正常系の処理が異常伝達に埋もれてしまいコードの可読性が著しく低下してしまう
>>225 が
>>209 のサンプルコードの意図を誤解した理由がこれだ
>>225 が間違えたのは予想された事だったんだ
>>225 が例外スタイルでは必要ない障害伝達を書いてしまった理由も根は同じ
戻り値スタイルを書き続ける事によって関数コールの周りに障害伝達を書くのは当たり前の事なんだと頭の中に刷り込まれて思考停止してしまった
結果として例外スタイルを書く際にもいつもの癖で不要な障害伝達を書いてしまった
そして戻り値スタイル派の人々は自分達が戻り値スタイルの常識にしたがって書いた例外スタイルの酷いコードを見てこう言うのだ
「ほらやっぱり例外はダメじゃないか」
とね
>>232 > > だとより複雑になる
> なんてことはない
具体的にコードで書けよw
要件は
>>218 な
h()が異常処理の責任を持つ前提でな
上に例外伝搬させてるだけでは問題は何も解決しねーから
あと
>>225 で例外投げなおしてるのは本質じゃない
単にそこでなにかしら異常系の対応をするという意味合い
人間にリトライさせることを考えると h()を呼び出したのがUIのフレームワークで
呼び出し側が "arg p is invalid" というメッセージでどっちの間違いが判定するなど
(現実には文字列で判定させる実装にしないだろうが、例な)
そこをそのまま exception_invalid_arg_f を上に伝搬させればいいだろと思うのはど素人
h() から外部ライブラリの exception_invalid_arg_f、exception_invalid_arg_g がそのまま
あがってくるというのは一般的にソフトウェアのレイヤー構造を崩してる
もちろん自分が担当している範囲ならありだが、
h() を外部に公開するような場合は仕様の責任をもつために自分で定義した例外で
投げなおすのは当たり前
とりあえず戻り値スタイルでコード書いてくれよ
>>235 ほら何もわかってない
エラー発生箇所でなんでも解決しなきゃならないと洗脳されてんだね
何もなくてもエラー処理コードを書かなければならない戻り値スタイルの書きすぎで感覚がおかしくなってる
>>236 戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
そして本当に変換が必要な例外は何かということも考えなくなってしまう
必要かどうかわからないけど何かしなきゃって強迫観念に苛まれてるのだろうね
戻り値スタイルだと伝達処理が必須だから例外スタイルになると不安になるのだろうな
戻り値を使う例
配列・ポインタ・構造体・クラス→「プログラミング楽勝ンゴｗｗｗｗｗｗ」
はい誰もコード書かないw
やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した
>>244 だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ
って書いてあるだろ
例外とあまり変わらないんだから書けるよね？
あのなぁ、俺は他の機能についての話で何度か書いてるけど、
異常系の処理がシビアになればなるほど例外が有利になる
例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな
>>250 ここ数10レスほど続いていた中身のない不毛なやり取りより
>>248 の1レスの方が有意義だと思うぞ
>戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
>>251 例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。
ただ、 SJLJ 以外の方法というのはデバッグ情報を使うためにツールチェインとの連携が必須だとか、
ハードウェアの機能を使うとかいった制約があって移植性に難があったりもするので、 SJLJ も滅びずに残ってる。
要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)
>>255 リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる
例外でイベント発生させて、イベントハンドラで受けるのはど？
>>255 > この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は
>>249 の言う通りその場所で必要なものをキャッチして処理をすればいいだけ
swith caseで分岐する場合もあれば、
>保証は言語側でやってくれるから言及する必要がないだけのこと
保証なんてしないよね？catch忘れたらそのまま上まですっ飛んでいくだけ。
Javaのような検査例外ならそこに差異があることを意識されられるかもしれないけど。
>そもそも例外は
>>249 の言う通りその場所で必要なものをキャッチして処理をすればいいだけ
そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。
大前提が間違ってる
>>261 > catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが
>>249 の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと
>>262 半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。
(検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
すべての例外を把握する必要はない
>>247 だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん
catchしたい人が必要なところでcatchすればとか言うんだろうけど
例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
その回避はどうすればいいかが不明瞭になっていくってのは
散々語られてる例外の欠点
リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
エラーを上位に伝搬させるか、リカバリーするか、その場でクラッシュさせるか
ローカルに記述が完結できてる
APIとして外部に公開するときもインタフェースの仕様にきっちり責任持たせることができる
ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
見ればすぐわかるんだから
大規模な開発を経験したことない人はこういう観点でソフトウェア開発を
考えられないんだよ
最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね
>>262 > 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
これがど素人の意見
ソフトウェアの品質について考えたことがない
「不正な入力です」
>>269 それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね
まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
>>267 仕様は
>>218 が決めるんだから
>>218 がコードを提示すべき
>>236 みたいに後出しの条件出されても困るからな
>>267 > 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ
> リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
だからそれはすぐ上位で処理することが前提になってるだろ
上位に何度も伝搬したら例外と同じになる上に伝搬するコードをそこら中に書く羽目になる
> ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
例外処理を書かないことはエラーを無視するんじゃなくてそのまま上位に伝搬してるだけ
書かないと無視してると取るのは例外をきちんと理解してないってこと
> 見ればすぐわかるんだから
お前の能力がな w
>>267 例外を使いこなせていないね
例外の型とパラメータをみれば何が起こったかはっきりわかる
おそらく君は例外の種類を使い分ける習慣がないだろ？
あったとしてもせいぜい標準ライブラリの例外をなんとなくふり分ける程度だろうね
でないとこんな発言はしないから
まずは例外を定義するところから初めてごらん
それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる
リターンコードスタイルをレビューに出すと袋叩きにされるぞ
>>275 考え方自体には同意するけど、
>>271 で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる
>>276 訂正
極めて困難で、実際には絵に描いた餅
>>276-277 必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？ って話だと思うけど
>>279 文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ
>>280 ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど
>>281 result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ
>>282 スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？
>>283 だからそれが例外安全だよ
勉強になったね
>>283 基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね
で、そんな当たり前のことを言って何が言いたいの？
例外機構は宗教
戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？
Cにそんな機能あったっけ？
>>265 そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。
検査例外を否定するのであれば例外型に頼らない(
>>264 の後者)か、プログラマの努力で
整合をとってやる(
>>261 の最後)カウボーイ的プログラミングになる。
>>265 はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。
>>291 ＞プログラマの努力で整合をとってやる(
>>261 の最後)カウボーイ的プログラミングになる。
…
…
これって「カウボーイ的」と形容されるべきものだったんですか？
catch の引数は値ではなくて、「型」だから、
テキトーな super class ERROR の下に個別エラー用派生クラスを列挙しておき、
臨機応変に catch (ERROR &e) を噛ましています…
>>256 一応例外を投げておくけれども、まじめにサポートする気はさらさらなく、
そもそもやる気は皆無・全くゼロであることを、ただ、それだけを全心全霊で表現するためだけに
throw 13;
例外の処理速度については、こういう提案もある。
https://ezoeryou.github.io/blog/article/2018-07-10-static-exception.html 要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。
環境の方の質問NGなら完全スルーでお願いします
業務で使った経験は一切ないです
TEST::TEST()
TEST::TEST(int param) : クラスのパラメータ(param)
>>297 委譲コンストラクタでググると出てくると思う。
たしかC++11で追加された機能。
>>295-296 LSI-C試食版 って Windows 用どころか MS-DOS (16bit) の、しかもスモールモデルしか作れないじゃん。
使い捨ての、いいかげんな富豪的プログラミングしたらすぐメモリ足りなくなるぞ。
ワイとしては Open Watcom C++ を推すやで。
LSI-Cとかなっつｗ
>>302 Cマガの付録CDに常に収録されてたよな！
>>298-299 TEST::TEST(int param) : TEST()
{
増やす機能
}
で出来ました。ありがとうございました。
bcc32c でコンパイルしたバイナリが Win98SE 上で動くことを確認…
>>295 > VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか
なんで試さんの？
LSI-C試食版ｗｗｗ
古いOSでも動作させたいけど、ソースは新しい規格で書きたい、
と言うのは要望としてはありうるな。
>>295 はLSI-C試食版(C89相当だっけ?)を使ってるようだから、
そのクチではないのかも知れんけど。
>>310 今時なら仮想マシンでやればいいだけだろ
>>312 コメント前に // つけるより
/*
コメント
*/
あるいは
#if 0
コメント
#endif
のほうがすっきりしないか？
だから何？
C言語の a=b; って
>>318 CPU の種類による。
アセンブラはアセンブラという言語の規格があるわけではなくて、
各コンピュータの機械語の単語を便宜的に読みやすい書式に置き換えた
ものの総称なので、使える命令は各アーキテクチャのデザインに従うし、
書式のバリエーションもある。 いくつかの伝統的な習慣はあるけれど。
データの移送にレジスタを経由しなければならないようなデザインの CPU もあるし、
そうでないものもある。
メモリアクセスをする命令とその他演算の命令を明確に分離するようなデザインの
アーキテクチャを特に Load?store architecture と呼んでる。
https://en.wikipedia.org/wiki/Load%E2%80%93store_architecture コンピュータの設計の根本を左右する方針の違いなので、
理解があやふやとはいえ、ここに引っかかりを感じたというのは才能を感じる。
>>319 自分が勉強してたCPUがたまたまレジスタ必要とするものだったということですね。ありがとうございます。
あと、intelとryzenは、どちらのCPUであっても殆どのソフトは動作しますが
この2つのCPUのアーキテクチャオペランドは同じということでしょうか？
ゲームなんかは高速化の部分でアセンブラ使う場所も頻繁にあるんじゃないかなと思うのですが。
>>317 wwww
逆に、だから何？
エディタが/* 入力と同時に
*/ を自動挿入してくれるなら全く変わらないだろ
それともおまえのエディタは / 入力で
もひとつ/ を自動挿入するように設定でもしてるのか？
ゆとりもここまで来るとどーしよーもねーな。
>>318 >>319 状況によるが、
a = b;
はメモリを介せず、できるだけレジスタ間コピーになるように最適化される。
んでメモリ to メモリを許すのはCISCと相場が決まってる
RISCはメモリ to メモリは命令にない 。命令セットを減らしてるからこそ reduce
このおかげで回路が簡単になり、所用クロック数をほぼ等しくして、クロック(Hz)をあげることができた。
このタイプはメモリ→レジスタ→メモリとせざるを得ない
今は、パイプラインを深くして、CISCでもクロックをあげられるようになったのでRISC/CISCはあんまり関係なくなった。
CICSの代表はx86なのでメモリ→メモリ命令セット調べてみ。
CISCの歴史的な経緯がわかるのは、これもCISC代表のx68kやH8は、命令セットごとに大幅に所用クロック数が違う。
それに対してx86の流れをくむ最新設計のRL78だとほとんどの命令セットが1クロックとなって。RISCと変わらない上に、
メモリ to メモリが可能となってる。それでも メモリ to レジスタに比べて1クロック増えてる。
メモリ to メモリ とレジスタ to メモリを同クロック数で実行しようとするなら、 バスラインがもう一組(例えば32bit)必要になった上に、
2ポートメモリが必要になってしまうwwww
>>322 自分で複数行が前提だと言っときながら何言ってんの君
>>325 */の自動補完は複数行だろうが単一行だろうが関係ないだろが。
おまえがエディタ支援による入力補助を持ち出したから応じてやっただけだろゆとり
入力の手間はむしろ/* */の方が楽なんだよお馬鹿さん
>>325 それとさ俺が複数行限定といってるのに
>>317 >単一行コメントのときに面倒なのは変わらないよね
また単一行の話をしてるのはそっちだろーが。
おまえは朝鮮人か？それともボケてんのか？
まあ例えばインテルアーキテクチャでも、
Z80Aで、おおむね4Mhzだったような
>>329 μPD780C-1な。870だと電卓チップになってしまう。
詰めが甘いな :-P
初心者です
関数テンプレートというものが一応存在する。
>>333-334 ありがとうございます
オーバーロードでしたね＾＾；
>>335 Variantが使えるならVariant
対照的にunionはおすすめしない
>>336 variant勉強します
ありがとうございます
投機実行がセキュリティホールになるなんて
いやー
煽ってたら論文ネタに困った情報系の役にたたん学者が投機実行を攻撃に使った実用法をひねり出したらどうすんだ
>>340 手元にようやく SandyBridge(IvyBridge) を確保しましたのでいろいろ試してみようと思っています
Googleだったっけ、見つけたのは？
C++って未だにasync,awaitがないんだな？
futureでいいんじゃね。C#のawaitもFutureパターンの実装でしょ。
>>345 .net動いてるのとそれが前提でないC++では全く同じにはいかんのだろな
教えてくれてありがと
コルーチン拡張は提案段階なんだっけ？
>>346 いや別に
C#のasync/awaitって単なるステートマシンジェネレータだし
標準化は至難だろうけど技術的にはC++でできない理由はない
>>344 再帰includeとdefineの組み合わせでも大抵はなんとかなったりするなw
templateは型に縛られてるから安全な反面、不便なこともあるよね。
sjisとutf8が区別できないし。なぜchar8_tを作らなかった…(´･ω･｀)
テンプレートよりObjective-Cのやり方の方が好き
江添なんて最新仕様知ってる俺スゲーやりたいだけの奴だからな。
>>351 江添とか書いてることみてるとムカっ腹立たないか？
何様だこいつ。しかもやってることキチガイだろ
>>357 は？お前じゃあ江添より仕様に詳しくてC++のコンパイラを実装出来るような能力なのかね？ええ？
例え世界一の物知りでもそんな口の効き方をする人とは
この3冊は、日本人が作った神の書。
Linuxの黎明期にman page 書いていたのは janneさん事、中谷千絵さんだよ
>>363 ざべは読んだことないけど、Cマガでεπιστημηの名前はよく見たな。
今では Teratail で C++ の質問をするとたまに回答者として出現するよ。
>>364 そうでしたか、CUJJとかは買っていたけど...CMAGは
時々だったので
>>361 えぴすてーめーと高橋のC++テンプレ本は神だわ。
なんというか、読者に理解させてあげたいという熱意が伝わってくる
江添とは大違い
江添にお布施するつもりは毛頭ない。死ねばいいのに
>361 の3冊は、単なる規格の文章ではなく、それをソースコードの実例にした所がすごい！
エピスや高橋ageて江添sageってのもよくわからんな
>>361 エピさん単著は買わないですね、エピさんの文章は今の言葉で表現するとすれば「ポエマー」が近い
同じくポエマーに分類される私がいうことではないのですけど…
元々は、Kerrisk も、江添やMISRA‐C のメンバーも、
MISRA はBOSCH を引き込み損なった時点で絵に描いた餅でしょうね
>>371 >規格をソースコードの実例で、表示してやろうという、とんでもない企画
いや言語の解説本は規格をわかりやすく、ソースコードを例示して解説するでしょ。
それがなければ、規格だけでいいわけで、解説にならない。
わかりやすく書こうとしてるけど、そこの熱意の持ち方と、おつむのレベルでほんとにわかりやすいかどうかが問題なんだろ。
そら商業目的の本だったらわかりやすく書くの当たり前だろ
>>371 >こういうのは、忍耐力がある日本人が得意なんだろう。
>外人は、まずやらない
K&R も Stroustrapも規格になるまえからやってますがな
ソース示してこつこつと。
何もプログラム言語だけじゃないわ。人に説くこと、伝道師のようなwriterは日本人よりむしろ、英米人に多い。
クヌースの The Art of Computer Programmingあたり読んでみ。
>>374 反響見て、読んだやつにバグだしさせてたあとブログ印刷物なり、ebook販売するんだから
金取ろうが、無償でやるかはどーでもいい話
日本語のコンピュータ書籍なんて販売数からしてとてもとてもメシ食えないから
ほぼ実益のないめんどくさいだけの作業
ブログでわかりにくければ本になってもわかりにくいことは保証する
クヌースの4-1巻目は、かなりの分量をZDD/BDDの説明に割いていて
>>377 警察に喧嘩売って訴訟おこしたこと以外知りませんがな
きちがいの所業なんざ
まぁC++テンプレートテクニックがわかりやすい良書なのは同意するけど
ま、江添が好きならどーぞご勝手に俺は願い下げってだけ
好きとは言ってないよ
というか江添のブログでも「あれ？おかしくね？」みたいなことあったから
型指定するのが嫌だから最初にautoを使うc++入門書籍を書こうとしてたり、
>まともにプログラム開発してたら最新の仕様を追えないので開発しないとか言い出す奴とか
すみません
>>389 SetTimer API を使って WM_TIMER イベントの発生を待つのが妥当な方法だと思う。
イベントが発生するまでは何もせずに待つだけなので低負荷。
>>390 windows API をつかう方法で行ってみます
ありがとうございます。
標準C++ で導入された
thread とchrono を用いて、while (1 )を回すという方法がGoogle検索で 出てきますが、低負荷な方が良いので、windows API で行ってみます。
ありがとうございます。
whileは単なる無限ループじゃなく、スレッドが立ち上がるまで、sleep で CPU を眠らせてるんじゃないの？
https://ja.cppreference.com/w/cpp/compiler_support gccは並列STLまだ実装できてないんだな。がかーり
C++2xは後回しでいいから先に実装してもらいたいな
msvcがしらん間にgccを上回るC++17準拠状況になってるんだな
msがかなり頑張ってるのがかなり意外
MSが標準をわざと外して潰し合う戦略を取ってたのは遥か昔
Class TA{
>>401 new したのなら delete は必ず書かないといけない
https://ideone.com/z0IYgT >>403 理解はしますが薦める気にはならないのです…
メンバ変数にクラスを持つときはポインタ型にしてコピーコンストラクタを作るべきですか？
実体で用が足りるならすべて実体でよい
値型とエンティティを意識して作って下さい
>>412 インスタンスがアイデンティティを持つならエンティティ
>>413 実数はエンティティですか？
符号付整数はエンティティですか？
>>415 現実を見据えて追求すると自然と出てくる答えです
親クラスとライフサイクルが同じか数値型なら実体、そうでないならポインタでいいだろ。
どうせそこまで最適化も厳密なメモリ管理も必要なプログラムじゃないだろ。
OS作ったり、ブラウザ作ったり、3Dバリバリのゲームを作ったり、他の言語向けに機械学習や科技計算等のライブラリを作ったり、いろいろあるよ
>>423 天才達だけに許された言語なのでしょうか？
もっと身近なプロダクトはないんですか？
古い例だとニコニコ動画がC++
>>425 聞いてばっかりじゃなくてお前がどういうものを探しているか書いたら？
CADとか画像処理とかビット演算系アルゴリズム(cf.ZDD)なんかは
>>426 ＞開発がスケールせずオワコン化した
これってどういう意味ですか？
JavaからC++勉強中です
>>431 時と場合によりますので一般的な答えはありません
>>431 Javaのオブジェクト参照はC++のポインタに該当する。
C++のオブジェクトは、型を持ったバイト列だと考えていい。
C++で自動変数を宣言すると、スタックにバイト列が割り当てられる。
newやスマポやコンテナを使うと、ポインタによりヒープでメモリーが割り当てられる。
ポインタも型を持ったバイト列。ポインタは配列のように周りのメモリーにアクセスできる。
C++のクラスは構造体に関数群を追加したもの。C++でクラスを継承すると、関数群とバイト列を引き継いだサブクラスになる。
>>431 大体、その3つの通りで、そこに述べられたものの上から優先的に選ぶ。
つまり、普通にメンバ変数にオブジェクトとして宣言するのがC++では
最も効率が良くて伝統的な書き方。それでは問題が生じる場合にオブジェクトの
ポインタとして持たせる。スマートポインタは後になって導入されたもので、
人気があるものではないので無視して良い。
二番目のポインタとして持たせるのは、例えば、今定義している最中の
クラス（自分自身）と同じ型のデータで、子どもや親にあたるデータへ
リンクを作りたいようなときか、または、ある基本クラスを継承した
色々なクラスのオブジェクトを持ちたい場合に用いる。
C/C++では、sizeofキーワードを使えば、簡単にvoid以外の型のサイズがコンパイル時に取得できる。Javaではオブジェクトのサイズを簡単に取得することはできない。
結局CのポインタってJavaとかの言語で表すなら何なんだ？
なぜなら、例えばスタックに巨大なデータを割り当てると、スタックオーバーフローというエラーが発生するし、
>>434 氏他
丁度今、ウェブ上のC++で書かれたCompositeパターンのソースを読ませて頂いてました
正に2番目で実装されてましたが、都度メモリ解放処理書くくらい当たり前なんですね、流石C++です
独学なもんで、こうはっきり言ってもらえると本当にありがたいです、使い分けて行きたいと思います
他の皆様もありがとうございました、勉強になりました
>>436 Javaの動的配列はCのポインタに近いが、Javaの配列では危険なアクセスは制限されているし、参照カウントで管理されている点が異なる。
Javaのオブジェクト参照は、参照カウントで管理されており、C++の構造体／クラス型に対するstd::shared_ptrに該当する。
しかし、std::shared_ptrはヌルポを指定できるが、Javaはできない。
>>438 >>441 ナマポの場合、代入したらまずいよ。例外安全にも問題があるし。
>>441 良い子のみんなは
>>441 の危険性が理解できるまではスマートポインタを使ってね
おじさんとのお約束だよ
>>445 のデストラクタでnullチェック必要？
nullポインタをdeleteしても問題ないはずだが
二重解放防止にはならんし意味わからん
>>448 超独自仕様の組み込み開発とか、メモリー管理がbuggyなプログラムでは意味があるらしい。
例えば解放したメモリーブロックをアクセスするような行儀の悪いプログラムでは意味がある。
>>441 >>445 初心者なので確認
>>451 「C++ 例外安全」でググれ。ナマポを使わずに、素直に生配列、コンテナ、スマポのどれかを使えば済むこと。マネージされてないナマポは村八分にしろ。
なんとなくわかった ような気がする
ちょっち理解は大変だけど生ポはスマポにドンドン置き換えたい
スマポならコピーコンストラクター・代入のややこしさからも解放される。
まあまあ。
所有権の管理は人類には早すぎる。
こんなときはナマポを使ってもよい:
生ポはスマポのオーバーヘッドすら許容できないときに使うものです
>>434 スマポは後になって導入されたもので人気がない、なんて意見は一般的ではないので無視して良い
エアプwwwwwwwww今は参照カウントじゃねーよw残念だったなクソ蟻wwww
それで、Cの生ポってC/C++以外で表現するなら何なんだ？
>>464 仮装アドレス的な意味で来るとは思ってなかったwでも本質はそうだよなあ
>>463 今の言語は極力「生のポインタ」が見えないようにしてるからなぁ。
オレの乏しい知識で無理矢理ヒネリ出すなら、
「古いBASICの peek, poke のアドレス指定に変数を使った場合」かのう。
型のない単なるアドレスって言うか数値だけど。
>>463 訂正：
行儀よく バッファなんて 守れやしなかった
まあstatic変数やglobal変数使ってリークしてないとか言い張るバカよりかは
昔研究室の後輩でポインタがわからないから全部グローバル変数でプログラム作ってるって奴がいて、
>>476 スマートポインタを使うとコード修正効かなくなるの？どういうこと？
mp4boxをちょこっといじったのを作ろうとしたんだけど、
>>481 「-2112000 / 48000 の結果が 89434」
その環境を持ってないんで分からないけど、
-2112000 の32bit16進数表現が 0xffdfc600
89434 * 48000 == 4292832000.000 == 0xffdf6b00
両者のビットパターンが一致することと関係ありそうね。
被除数の -2112000 を64bitで表現する際に
符号拡張 0x_ffff_ffff_ffdf_c600 とすべきなのに
ゼロ拡張 0x_0000_0000_ffdf_c600 にしちゃって、
その後の計算は64bit正数でやってる感じかな。
>>480 本人がスマポ理解できてないってオチだろ
>>477 組み込みが得意でポインタがわからない後輩
設定に無理がありすぎw
再び
>>481 「-2112000 / 48000 の結果が 89434」 (間違いを訂正)
-2112000 の32bit16進数表現が 0xffdfc600
89434 * 48000 == 4292832000.000 == 0xffdf6b00
ビットパターン一致してないね。桁数多くて見間違えちゃった(テヘペロ)。
-2112000 を32bitで表現すると 0xffdfc600 であり、
これをゼロ拡張した 0x_0000_0000_ffdf_fc600 == 4292855330 を
48000 で割り算して小数部を捨てれば 89434 という答えが出る。
ということなら合ってるかな。
>>481 どうせ48000がunsignedなんじゃねーの
それにつられて -2112000もunsignedになって4292855296
その結果が薬師美代ちゃん
>>479 自分が何してるか判って使う分には問題無いな
適材適所だ
>>480 >スマートポインタを使うとコード修正効かなくなる
どういう風に読むとそういう理解になるのか。。
まずは日本語の理解が必要だな。
超初歩的な質問になるのですが
for(i=0;i<20;i++) if (scanf("%d",&num[i]) != 1) break;
>>490 scanfや標準ライブラリの関数など、参考書とかで普通の使い方はわかると思うけど、細かい仕様をmsdnやmanコマンドで調べるようにするとかなり理解が広がると思うよ。
中途半端なUI使うよりもcsvパーサーを作るかどっかからとってくるかすれば？
>>494 むしろ遅くなる方に振れるでしょうけれど、そんなのどうでもいいのでは？
autoって変数の型宣言の話だよね？
C++ の auto は右辺と一致させるように推論するだけの単純機構で、
autoはむしろコンパイル速くなるんじゃない？
>>496 C++を言語として選択した時点で「記述の時間やコンパイル時間を投資して実行時間を稼ぐ」という思想なのでは？コンパイル時間を短くする努力はする気がないと思います
>>498 ＞いちいち型を解決せずとも、既に解決済みの型を右から左へコピーするだけ
この記述はコンパイル時を想定しているの？それとも実行時を想定しているの？
はっきりさせたいので念のために確認します
>>490 サーバーの 503 エラーに引っかかって昨日のうちに書けなかったんだが…。
>>491 の方法だと Enter が単純に読み捨てられて scanf() が終了せず
まだ入力をよこせと言ってくるからダメみたいね。
11 22 33 (Enter) だと読み込みが継続、期待通りに動作しない
11 22 33 x (Enter) なら x を解釈する時点で scanf() が 0 を返してループ脱出
先に文字列として1行読み込んで sscanf() と思ったけど…
ndat = sscanf(s, "%d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d",
&num[0], &num[1], &num[2], &num[3], &num[4], &num[5], &num[6], &num[7], &num[8], &num[9],
&num[10], &num[11], &num[12], &num[13], &num[14], &num[15], &num[16], &num[17], &num[18], &num[19]);
実際に読めた値の個数は ndat に入る。
これは書くのもメンテナンスするのも嫌だなぁ。
strtol() で1個ずつ数値を拾いつつ、地道にポインタ進める方が良いかも。
>>500 自分は
>>498 の人じゃないけど。
ごく簡単な場合ながら、例えば
int val_a = func(para); // func() がint互換の値を返すかチェックが必要
auto val_b = func(para); // func() の返す型そのまんまで val_b を作ればいい
てな具合に考えると auto で定義した方がコンパイル時の手間が少ない、
という考え方にも一理あるかと。
瑣末なことだけど val_a, val_b って変数名は良くなかったね。
>>501 ありがとう。ちゃんと確認してなかったわ。
タブに空白に改行はスキップしやがるんでしたか
別案としては fgets() ⇒ sscanf() になるんかな
505の後半は無しで
>>501 scanf は禁止
>>505 が正しい
人間の様な邪悪なものからの入力でscanfは使うなと、ばっちゃは言ってた
>>502 ＞func() の返す型そのまんまで val_b を作ればいい
この発想は実行時なのでは？
＞てな具合に考えると auto で定義した方がコンパイル時の手間が少ない、
実行時の発想をコンパイル時に適用していいのでしょうか？
>>509 賛成です、そういうのは1ラインを秘術を尽くして何とか読み込み、後で sscanf() とかを使うべき
>>512 今回の例(
>>490 ) のように可能な限り %d で抜き出して打ち切るとなると sscanf 単発では面倒
なんとか行単位でバッファに詰めた後
連続空白などでトークンに区切ってそのトークン単位で sscanf をぶんまわすような
ほのかな中途半端感が
>>510 別に実行時の発想じゃないでしょ
型を書けばコンパイラはその型名に対応する型を解決しなければならないし、
型変換の要否や可否のチェックも必要
>>514 ＞型変換の要否や可否のチェック
これは10中8, 9 コンパイル時にすることなのでは？
>>515 初めからずっとコンパイル時間の話をしている。お前さんだけ噛み合ってないから、もう黙っててくれ。
C++です
>>517 クラス定義の中に書かれたメンバ関数の定義は
自動的にインライン関数になる(関数の実体の定義ではない)
この場合は、複数の場所にメンバ関数の実体が作られるわけじゃない、
という説明でどうかな。
>>516 そもそも「実行時」「コンパイル時」の区別がついていないのでは、コンパイル時間の話なんかできないのでは？
だから「実行時」「コンパイル時」どちらを適用するかに執着しているだけです
>>518 なるほど
クラス内に定義を書くとインライン関数になって普通の関数としては扱われないんですね
もう少し理解するために調べたのですが、インライン関数は内部リンケージのみを持つものとしてコンパイラに解釈されるらしいですね
だからコンパイラはファイル間での関数の重複を調べようとしない
そしてインクルードによって複数のファイルで同じものを読み込んだとしてもエラーにはならないと・・・
理解です
勉強になりました
ありがとうございました
失礼、なぜか
>>510 を見逃してて(黙殺するような意図はまったくなかった)。
C++ は関数を宣言・定義するときに返り値型を書くから
auto で受けてもコンパイル時に曖昧さは生じないと考えたんだけど。
実行時まで返り値の型が決まらない関数って作れるんだっけ？
これは純粋に質問、教えを乞いたい。
あんまり高度な話だと振り落とされるかも知れないけど。
型推論が実行時に行われるとかトンチキこいてるやつが一人騒いでるだけ
>>521 おそらく君の書いた｢func()の返す型～｣をqz某が勝手に勘違いしているだけだからスルーしていいよ。
初心者が必ずしも正確な用語を使わないことくらい想像つくだろうし、文脈からして普通ならそんな勘違いはしないはずなのだが。
>>521 出来ない。
強いて言えば C++17 からは std::any があるけれど、
これはこれで実行時に型が決まるわけではなくて
コンパイル時に std::any 型であることは確定する。
>>520 > もう少し理解するために調べたのですが、インライン関数は内部リンケージのみを持つものとしてコンパイラに解釈されるらしいですね
どこにそんな嘘書いてあった？
https://timsong-cpp.github.io/cppwp/n4659/dcl.inline#footnote-94 > The inline keyword has no effect on the linkage of a function.
>>525 IBMのサイトに書いてありました・・・
と思って今見返したらこれはIBMの統合開発環境のページなのでその開発環境の仕様かもしれないですね
失礼しました
https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_72/rzarg/inline_linkage.htm ＞インライン関数は内部リンケージを持っているものとして処理されるので
>>526 「C のみの始まり」～「C のみの終わり」で囲まれているとおり、それはCの仕様だね。
>>525 それは inline キーワードで束縛された関数は、inline 展開される多数の実体と、外部リンケージによって外部からコールできるものとで別の実体をコンパイラは作成する、ってことですか
まあ inline しまくって無駄にバイナリーを増やすくらいだったら、ついでに1 個の外部リンケージで呼べる実体を追加したって、いろいろな面で大差がない、とはいえますね
>>528 「それ」が何を指して言ってるのかよくわかんないけど、 inline 関数に対して
インライン展開されてない「実体」を生成するのもしないのもコンパイラの自由。
外部リンケージを持つ関数について複数のコンパイル単位でアドレスを取って
==, != で比較した場合には一致させないといけないので、アドレスを取られた場合には
そういうコード生成をするのが一般的だろうとは思う。
引数や関数にはconstつけられるところは全部つけるべきですか？
つけて問題ないならつけるべきだけど、まあ実際は面倒くさくなければという程度…
>>530 内部で書き換えないポインタや参照の引数には必ずconstをつけるべき。より自己文書化されるし、付けてないと使う側の手間が増える。
>>531 は元javaプログラマ
今は良いけど、半年後の自分は既に他人だと思わないと
530みたいな質問する奴はそもそもconst気にする前に関数が長すぎたり
入門書の類が、最初のうちは const なしで説明しておいて、
戻り値を const char* してても、
クソミソみたいなjavaのconstと違ってC++のconstは
「かなり安全な」
残念ながらバカはmutable使い出すから無意味。
俺は書換られたりはしない たぶんしないと思う
いやまてまて・・このスレの99%はネタでできてるけど
こいつ能力低いなと思う奴のソースを見ると、
>>543 ちょっとわかるわｗ
あと3文字くらいが良かった
constはキーボード入力の観点からはそんなに苦じゃない
const char* a = "hoge";
そんな違いを意識しないと読めないコード書く方がバカだと思う。
（そんな初歩中の初歩でマウンティングドヤ顔して大丈夫っすか先輩）
>>545 >>544 のこと言ってるの？
>>537 は、ポインタの指し先だけでなく、戻り値を格納する変数自体を定数にしなければさほど意味がないっていう主張だと理解したけど、合ってる？
ローカル変数を定数化したければ呼び出し元が勝手にやればいいし、戻り値をconst char*にする重要性に比べたらそれをする必要性なんてごく僅かで"さほど意味がない"なんてとても言えないと思うけど
C++ってC言語の負の遺産を引き継いだ言語だろ？
constみたいな糞どうでもいい些末なことより
>>557 そこはCの負の遺産を引き継いだのではなく、可能な限り実行時オーバーヘッドを小さくする実装手段を提供するというCの基本スタンスを継承しただけだろう。それが負の遺産というなら他の言語の方が適切なんだからそれを選択すればいいよ。
C++を使いたく、ある程度の実行時オーバーヘッドが許容できるときはstd::vectorという選択肢があるけど、それじゃダメなのか？
>>556 const に関しては C++ で新規導入された仕様を ANSI C に逆輸入、
みたいな感じじゃなかったっけ?
そのせいか、定数としてconst変数を使えないとか中途半端になってる。
C++ が C の負の遺産を切り捨てるべきだったとしても、
const はその「C の負の遺産」の範疇に含まれないかと。
いずれにせよ、今さら言っても、現に存在する C++ はどうもならんよね。
そういう新プログラミング言語が出ても、それは C++ じゃない別物ってことで。
とりあえず数値以外はconst参照渡しが基本でおｋ？
>>557 at()使え。
>>556 constが負の遺産とか頭おかしい。
ドキュメントにこの変数は内部で変更しませんとか書くよりよっぽど楽だろ
>>562 負の遺産だよ。
const キーワードを廃止して
デフォルトの挙動を const に出来れば
どれほど良いことか。
という意味で。
>>563 それなら同意するけど
>>556 にそんな意図はないでしょ
>>564 皮肉っぽい言い回しをしてみたかっただけ。
そこまで挙動を変えるなら別言語でやれば良いし、実際rustとか他の言語としてあるだろ。
使わないで済ませる事ができるなら、使わないで置く方がうまく行く
>>563 >>567 も書いてるけど、それ何てRust？と思った。
負の遺産でも互換性とのトレードオフだしな。
>>563 引数だけなら同意してもいいけど変数はどうするんだ？
for(variable int i = 0; i < 10; i++){
とかはあまり書きたくないぞ
>>571 まあそこはもしもの話だから。
最初から const なら文法もそれに
沿ったものになってただろうさ。
確かに、関数内で作ったローカル変数だけデフォルト変更可能、
そうそう、だから普通にC++書いてる人は
引数じゃなく method の const は後悔することがちょいちょいと
constつけときゃいいってのもなんか胡散臭い印象しかないな。
const が必要なところに付けるって考えるよりは
const連鎖くらったらほどほどでいいやと思うようになる
なんというかもう修正が一切されないコードしか想定してない印象を受ける。
やりすぎオブジェクト指向といっしょで
複雑怪奇で理解不能にしておくと、
初心者で申し訳ないんですが、c/c++を学ぶため何か作りたいのですが、cで作る意味のあるいいお題はないでしょうか。JavaやC♯、rubyは一通りかける感じですがcはmallocなど知ってはいても使ったことはないレベルです。よろしくお願いします！
>>583 ビットマップ画像を読み込んでブラーをかけてビットマップ画像として出力
>>583 いきなり「実務的な」プログラムを書くのはオススメしないよ。
C/C++ には歴史的経緯によってクソな落とし穴と「未定義」がたくさんあるので、
たとえ期待通りに動いたとしても正しくないプログラムであることは多い。
初心者向けのしょうもない (他の言語でやる入門と大差ないような) 題材で小さなプログラムを書いて
ブログとか Qiita とかに書いておけばベテランがよってたかって指摘してくれるさ。
そういうので基本的な落とし穴くらいは理解してから進んだ方が良いと思う。
HDDの中を検索するプログラムとか、整理するプログラムとか
おっさんらジイさんらの世代だと
>>584 >>585 >>586 ありがとうすごく参考になりました。デスクトップランチャーとかほしいと思って作るならWPFだし、Cで実用的なほしい物ってむつかしいんですよね。初心者向けの小さなプログラムは上記のブラーとかでしょうか？Cで書く意味がある題材ってわからなくて。。。
>>588 そもそも自分がC/C++を身につける意味があるかというとこらから見直した方がいいのでは？
直ちに必要な訳ではないが将来的に身に付けたいというなら、先に他の人が言っていたようにいきなり実用的なプログラムから入るより練習問題レベルの小品をコツコツ作っていった方がいいと思う。
どうしても自分が欲しくて既存のものがないってケースでも、
>>588 例えば容量の大きなHDDだと、同じファイルが複数場所にあったりするじゃない？
そういうのを見つけて、チェックした後削除すれば容量節約という実利もあるよ
>>588 C/C++ で書く意味ということに最初は拘らなくてよいと思う。
こだわらなくてもプログラムの構成の仕方、書き方には確実に違いがあるから、
むしろ比較しながら学んだ方がいいかもしれない。
C/C++使う必要性がわからないならやらないのが正解
先に他の言語やらんとC++の必要性はわからんと思う
こんなにレスもらえると思いませんでした、他の言語スレや板だともっと殺伐としてます。。。ありがとうございます。
低レイヤを高速で処理できるのが魅力だと思うので最終的には任意のパケットを送受信できるデーモンを作りたい。ので、
>>591 のいう同名ファイル検索デーモンから始めようと思います。
ならechoサーバーから入ってhttpサーバーという定番ソケットプログラミングコースもおすすめ
>>595 同じファイルというのをどう判定するかだな
ファイル名なのかハッシュ(中身)なのか
globalに宣言されてる変数と同じ型同じ名前で
>>595 なんで、そんな面倒くさい事をしなきゃならないんだ？
Ruby なら、PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、
何も考えなくても、これでブラウザからアクセスできる
http://localhost:8080 >>599 お前は相手の意図を理解する気がまったくなく、人とのコミュニケーションができないことをさっさと理解して、巣にかえって閉じ籠っていてくれ。
ここはお前に用がある奴は一人もいない。
みなさんありがとう
>>598 gcc/clang だと -Wshadow だな。
-Wall -Wextra とは別に指定する必要があるようだ。
細かいことを言えば、同じ型でなくても、名前が隠される場合は警告が出る。
今ネットで調べて確認、これからオイラも使うことにする。
同じ意味だけど型が違うときの変数名ってどうされてますか？
>>603 float2でfPosって付けてるならXMFLOAT2ならxPosとかでいいと思うが…
>>603 よくシステムハンガリアンは悪と言われるけど、この例のように同じ内容で型名の違いに意味がある場合は、型名に関するプリフィックスをつければいいんでない？
とあるライブラリに渡す境界部分ならそのライブラリ名に関するプリフィックスとか。
初心者ですみません、こんなコードをみたのですが2点わかりません。
char packet[1500];
memset(buf, 0, sizeof(buf));
ether_header *eh;
eh = (struct ether_header *)packet;
たぶん、1500byteのメモリを確保して0埋め、ether_header構造体のポインタを宣言してpacketのアドレスを渡す、としたいのだと思います。
分からないのは0埋め対象が宣言されていない変数bufであること、packetのアドレスを渡すのにわざわざether_header型のポインタにキャストしている2点です。よろしければ教えてください。
https://qiita.com/marufeuille/items/81f323a52a6fd3bd530c >>606 の引用元を見るとコード片だから、実際にはコンパイルしてないんだな。
char packet[1500];
memset(buf, 0, sizeof(buf));
は、packet と buf が同じもので、正しくは
char packet[1500];
memset(packet, 0, sizeof(packet));
なんだと思う。最初は両方とも buf と書いてあったけど
「もっと自ら語る変数名にしよう」と packet に変えたはいいが、
memset() の方では直し忘れた、というお話かと。
(struct ether_header *) のキャストは、コンパイラの警告対策だな。
…って言うか、これキャストしないでも警告だけで通るのね。
やってきたパケットのうち 頭のEthernet Header にフォーカスしてる意図でのキャストかな？
>>604 >>605 どうせ長ったらしい関数書いてんだろ
>>607 >>608 >>609 ありがとう、cがとんでもなく難しい言語かと誤解するところだった。
いやーCは簡単な言語だけどC++はとんでもなく難しい言語だと思うぞ
しかも、言語仕様の改訂が3年ごとと早すぎて、
なんか皆C++はむずかしいむずかしいっていうが、そんなむずかしいか？
有名所のライブラリでラムダ式使ってるの見たことない
『プログラミング言語C++』第4版は電話帳より厚いね。
C++は新しい言語仕様が次々に追加されるせいで、
>>615 CもC++も仕様は簡単
ライブラリやアルゴリズム考えるのが面倒で生産性が低いだけ
それを難しいと勘違いしてるだけ
こういうc++の危険さをまったく認識できてないやつが一番困る
C++11以降とそれ以前で違い過ぎるのが問題では？
>>623 「徐々に理解しながら」は、 C を既に知っている人を明らかに想定していて、
今では C がそんなに支配的でもないという状況を思うと適切な動線とは言えないという意味でも
あまり役に立たなくなってきていると思う。
ただ、追加された機能を見ると、
新しい書き方の方が間違い難くて綺麗で一貫していることが多いので、
肥大化するから追加するのをやめろとも言い難いんだよな……。
皆、ドワンゴ江添亮の本を読んでいないから、C++ の恐ろしさがわからないのだろう
詳細を突っつくと、無限にややこしいものが出てくるw
だから江添でさえ、詳細は省略しますって書いてあるw
>>610 1バイトずつ、check sum を計算するような場合は、そういうように、union にするのが定番
udpパケットを送れるようにはなったのですが、wiresharkで確認するとudpフレームのchecksumが未定義となっていました。。。
enumについて教えてください
よくわからんが、識別子の定義を変えたいということか？
>>631 調べた方が足りませんでした、NICのTCP offloadingという機能が有効になっていたせいで、NICより手前でキャプチャするとunverifiedとなっているようです。大変失礼しました。
>>619 ＞今時のECMAScript
いや、ハードウェアに固定されたバイナリーですらなく、ソフトウェア上で決められた決め事になんら意味を見出せないのですが、それでも javascript とかに熱意を抱けるコツがあったら教えてください
>>629 いいかげんにニコ動をなんとかしてほしいです、昔も重かったけれども今も重い、これはなんとかならないのですか？
>>636 >>619 の書き込みのどの部分を読んでその質問がでてきたんだ？なんかバグってね？
引数のmove受け一つとってもrustの3倍くらい難しくなってるわな。
物作った事の無い人の重箱の隅つつき＋詳細未記載本なんて
ソース書くときに気を付けるのはとにかく引き継ぎしないといけなくなったときに楽になるようにって点かな。
構造体で例えば
ああできた
構造体一括代入はANSI以降の機能だからOS/9とかCP/M68K
C++だと
>>644 たぶんそうだったと思います
ありがとうございます
>>645 C++11 以降なら p = {3, 4}; でもいけるよ。
C の p = (struct POINT){3, 4}; は、構造体の一括代入に違いないけど、
>>643 理由が"面倒"だったのに、文字数増えてるよねそれ
>>649 これは、C++ に合わせてほしかったな、と思うのです
c++の規格って言ってもその辺、c++のいつの規格だよって話になるんじゃないの？
>>629 会社の売り上げに貢献せず、警察を提訴するような
キチガイ高卒社員が資産食い潰してるんじゃね？wwww
>>622 すでに3版でも電話帳より厚いよ
まともに読む気になるのは2版までだな。
熱意あるうちはともかく、ふと我に返ると俺何してんだろって。
そんで、言語覚えただけじゃプログラムてかけないしな。
C++でまともなWebサービス作れるエンジニアなんて相当単価高そう
サービスを書くのに C++ の比率は高くないかもしれんが、
「困った」と
まあJavaは糞これは間違いない
Javaはコボラーと同じく湿った猫のような臭いがします
Java並に大規模な開発事例ってC++にはあるの？
>>670 人月商売をやってるだけで大規模（）とは言わない
Linuxカーネルほど大規模なのはJavaではない
unreal engineとかクッソ大規模に見えるけどどう？
工数でいえばそんなもんクフ王のピラミッドには遠く及ばないだろう
甘い
20年前で70万ステップぐらいでビルドに1Hぐらいだったなあ
むしろ
>>670 が思う大規模なjavaプロジェクトを知りたい
人数かけて、webページの遷移ごとに別人が開発して、似たような処理をするコードが100倍くらいに膨れ上がって収集つかないようなのが大規模なんじゃね
c++じゃなくてcでnamespaceって使えますか？あるいはnamespace相当の機能ってどうすれば実現出来ますか？
重力波を検出するのに世界中の電子望遠鏡を接続してリアルタイムに通信してるようだけど
>>685 cでは使えない
ほぼ上位互換だからc++使えばいいじゃん
>>686 マジレスすると、ああいうのはファイルに落として時々バッチ処理してるだけ
言語はだいたいFortranかC++が多いだろうね
std::chronoにnanoseconds取り扱う型があるけど
c++11以降はあれ明らかに生産性下がってんだろ。。
>>691 表現できるだけ
計測できるとは言っていない
じっさいにやったらわかるが、結局 Windows API の持ってる精度までしかでない
>>694 試そうと思ったらどう試すのがいいんだ？
短時間、というか連続で何度も時刻の値を入手して、
差をとってその偏差を見ればいいんでは
std::vectorの最初の要素数は
結構難しいと思うがね。
>>701 std::vector<std::vector<foo>> a(100, std::vector<foo>(200));
Cで書かれたライブラリから来た構造体にスマポをあてる方法はありますか？
どうなんだろ？
>>706 スマポ弄ってアロケートだけしないようにすればいいんじゃね？
「来た」というのが構造体へのポインタをfree責任ごと渡されたという意味ならカスタムデリータだろうな。
ありがとうございます
最近スマポ使えスマポ使えってうるさい割にはカスタムデリータ指定出来ることも知らなかったりするんだな
codecvt_utf8
最近カスタムデリータ知ったから嬉しがってる奴がいるなw
>>711 すいませんね、リファレンスなんかそっちのけで、ネット情報だけで、プログラム組んでます。
>>714 図星だったか、すまんな
というかマウント取るための屁理屈考えてる暇あったら手動かした方がいいよ
図星しとか意味分からん
ひょっとして
>>711 disってるのか？ w
最近図星って言葉を覚えたので使いたいんだろう
>>711 で言ったことが図星だったか？という意味なんだが
アホが多いインターネッツですね
今度はインターネッツという言葉を覚えたのか
カスタムデリータごときでよくそこまでドヤれるもんだなw
実際c++やるやつのほとんどの動機がマウントとりたい以上のものではない。
大学四年かけてC++と機械学習学べば年収1000万とか本気で言ってる奴らだからな（）
相談なのですが
ライブラリＡが要求するのは
>>728 ヘッダーと共有ライブラリのセットです。
>>729 やっぱ他にないですよね…
継続的にバージョンアップ重ねて提供してるんですが、ライブラリAについては今後も使い続けるか微妙なんでお客さんに～のように運用してくださいってお願いするのはまだやめておきたいんですよ。
まあその面倒ごとを避けようとするスタンスが一番よくないのかもしれませんね。
というか自分がお客さんの立場にたってみれば、「カレントディレクトリにライセンスファイル置いて使ってください」と言われたら「はいOKです」ですむ問題ですよね。
>>730 どう配布すんのかしらんけど
共有ライブラリと同じとこに置いて固めるなり、インストーラー書くなりすれば十分やろ
たいして報われん努力やと思うわ
それよりライブラリAは何がしたいんか気になるわ
意味あんのかそれ
>>733 ライブラリAはwebAPI叩くからその時にアクセス権限チェックでライセンスファイルを使うようです。
>>732 ロードされてる共有ライブラリのパスはとれるはずやから、
そこにライセンスファイル置いておく手はある
変数と型についてなんだがメモリは2進数でデータを記録していて、それを何byteで区切って、どういう意味を持つか（正の整数のみとか）を型で決めてるんだよね？だとしたらポインタに型があるのはなぜ？どれもアドレスを示すんだからある意味int型でいいと思うんだけど
>>736 そういう言語もあったよ。
でも、ポインタを経由しただけで型がわからなくなるんじゃ、
型システムが意味を成さないだろう。
元と違った型としてアクセスしようとしたときに、
型情報がなけりゃコンパイラが捕捉しようもない。
それはプログラマの責任で正しく扱うってのならそれでもいいし、
実際、 C/C++ はプログラマがやりたければポインタを整数に型変換することも出来るけど、
(言語仕様としてはほとんど保証はないが。)
人類は間違うのでな。
型が合わないエラーなんてたびたび出しちゃうもんだろ。
もし型がなければそれはスルーされてわけのわからない挙動をするプログラムになるんだぞ。
そういうのはもうやめようって話。
>>736 ポインタに格納されるアドレス値は32bitとか64bitとかの整数でそれ自体は同じ型として扱えるとしても、そのポインタの指す先にある物の型が分からないと色々困るでしょ。
ポインタ型としてvoid*だけでプログラムを書こうとすればその必要性がわかるはず。
同じバイト表現だからといって同じ型で表さなければならない道理はない。用途や演算結果が異なるのだから別の型として扱うのはある意味自然なことだと思うよ。
>>736 参照はずし、つまり*演算子で「ポインタの指す内容」を取り出すときに
そのポインタがどんなデータを指すポインタか分からないと困るでしょ。
構造体を指すポインタで p->menber とかする場合も同様。
>>738 の「void*ポインタだけ使って書いてみる」ってのは、
ポインタに型のある有り難さを実感できる良い課題だね。
Cのポインタ型はK&Rのプログラミング言語Cに書いてある通り、単なるアドレスを保持する型じゃなくて配列の仲間なのよ。
Cのポインタ型はK&Rのプログラミング言語Cに書いてある通り、単なるアドレスを保持する型じゃなくて配列の仲間なのよ。
>>741 >>741 ＞*(p+1)の様に書くと、ちゃんとcharサイズ分ずらしたアドレスを指してくれる。
*(cp+1)の間違い
>>737 >>738 >>739 >>740 ヒューマンエラー防止
型のないポインタを宣言すると中身のbyte長が不明
ってことかありがとう
740のコードを見て疑問に思ったんだけど*cpは一つのアドレスしか記録できないから配列の先頭（文字a）のアドレスを記録するよね。このとき配列の長さが3だという情報はどこにあるの？（脱線するけどNULL終端も数えて長さ4？）
>>743 ポインタが指す先にいくつ分の領域があるか(いくつ分を参照してよいか)は記録されてないから、プログラマが自分の責任で管理するしかないよ
>>743 直接長さを示す情報はどこにもないよ
だから、cの「文字列」は単なる文字の配列だけではなく、0終端が必要
>（脱線するけどNULL終端も数えて長さ4？）
その通り
（NULLはnullptrとしてのみ使ったほうがいいよ
混同してないならいいんだけどね）
>>740 >>741 ＞ポインタが示す先の型とサイズやらの心配はC言語では不要だ、すげーだろ？的な。
サイズって型のサイズでした、すみません。
配列長さは
sizeof(*cp) / sizeof(型)で取ってねって書いてあったよね？
\0終端が来るまで確保されていると想定して受け取り側は動作する
便乗質問でごめんやけど
>>746 char *cpで宣言してるならその計算じゃ配列サイズはとれないよ。
要素数の算出は
コンパイル時に確定する値だから
sizeofは演算子だから動的じゃないかな
>>748 実装依存だと思うけど、p[-1]とかに長さが書いてあったりする
アンカー長くなるから省略するけど
VLAのこと完全に忘れてた sizeof(配列) は動的だわ
sizeof の結果は動的な判断が必要な場合 (いわゆる VLA) を除いて整数定数であることは保証される。
>>756 >>744-755 というアンカー表示方法も、知っておいてね。
昔はstd::extent持ち出したりしたが今はstd::sizeだな
uint8_t *addrb =(uint8_t *)0x00F00000;
>>762 ・整数だから昇格するよ
・整数即値をポインタ型に変換してるよ
ポイント先のデータは多分、バイト型だよ
マップドIO系のCPUではよく見るパターンだね
＞ポインタはそれより小さくて問題ないのでしょうか。
ありがとうございます。
アドレス自身にもサイズはあるけどね。
メモリ消費についてききたい。
>>767 ポインタ先をチェック・確保するのにヒープメモリーと計算コストが掛かる。
>>767 宣言次第ですね。
メモリ節約だとdを配列にしておくといいかなとおもいました。
>>767 それ実体の24byteが別に要るだろ…
下のソースをコンパイルしてコマンドプロンプト(cmd)で実行すると「鷗」の字が出力されません
Windows は、Visual Studio だろ
UNICODE
fwprintf
>>767 もしかして windows で 24bitカラーを取り扱いたい話？ union で楽する
#pragma pack(push,1)
typedef union {
BYTE e[3];
struct { BYTE B, G, R; };
} BPP24_t;
#pragma pack(pop)
>>768-770 >>775 ありがとう説明不足だった
厳密にはL2フレームを実装したくて
DMAC6byte
SMAC6byte
TYPE2byte
とかを結合して送りたい。
んだが、結合用の変数を用意するとメモリ消費二倍な気がしていやだなと。
で、それぞれはポインタにして結合用の変数の0、6、8byteめを指定してやればいい気がして聞いてみた
>>776 プロトコルスタックでそういうデザインはよくある
nicにわたすときのdmaもそんな感じ
しかしその数バイトの処理はこだわるところじゃない
規格で標準ライブラリ中のメソッドがconst指定されていない場合これをconst指定するのは規格違反ですか？
>>776 フレームの組み立ては迷うことなくstructでいいと思うのですがどうでしょう。ちなみにpingではは素直にstructで組み立ててあります。
>>777 確かに数バイトなんだけどね
>>779 cppで書いててクラスのプライベート変数として持ってます
結合どうするかだけ悩ましい
>>780 ああ、なるほど。structでガワ作っておいて、ペイロード書き換えてバッファに溜めていくって感じでしかやった事しかないですけどケースバイケースなんでしょうね。
C++難しすぎねえか？
>>783 別に網羅せんでも使えるところだけ使えば良い。
常に新しい機能を把握しておく必要はない。
使わない方が良い機能というのは有るので、駄目な部分を把握する方が大事だと思う。
(その結果として新しい機能に行きつくこともあるけど。)
新しい機能を使わないと回りくどくなるだけだが、
駄目な機能は致命傷になる (という可能性をコンパイル時にエラーに出来ない) こともあるので。
今の C++ で nullptr でなく NULL を使う理由は全然ない、みたいなのとか。
てかコンセプトが待ち遠しい
コンセプトとモジュールは C++er の悲願って感じだからな……。
配列のアドレスが表示できません。何が悪いのでしょうか。結果はからになります。
>>788 &a[5] は「unsigned char を指すポインタ」なので
cout << では「'\0'で終端する文字列」として表示しようとするのよ。
なもんで
>>790 の通り void* にキャストして、
具体的なデータを指さない「単なるアドレス」扱いしてくれと指示。
ちなみに
>>789 は効果ないでしょ。
でも C++ の作法としては static_cast<void*>(&a[5]) と
長々しい名前付きキャストを使うべきなんじゃろか。
個人的には static_cast<const void*>(&a[5]) まで書きたいけど。
inline const void *to_voidptr(const void* p) {return p;}
てな具合に、字数を減らすための変換用の関数でも使うか。
…何か標準的で短い書き方があったりするのかしら。
文字はcharだけでsigned/unsignedは整数扱いするとかしてくれりゃよかったのにな。
coutなんて使うのが悪い
qDebugばっか使ってたからcoutの使い方なんて忘れてたわｗ
そういえば「cout << &a[5] でアドレス値が表示されない」ってのは
operator<<(ostream&, T*) の再定義をしないライブラリで
gccのiostreamのソース辿れば全部書いてあるよ。
>>797 ほう、どこに書いているのかわかってそう言っているのですね、それはすごいですね
ライブラリのソースコードを辿っていくとビルトイン関数だったりして萎えることもあるので、
>>799 ostream のヘッダ単独は意外に分量少なくて一通り見られたよ。
char系以外には...
operator<<(nullptr_t); // #if __cplusplus >= 201703L で条件コンパイル
operator<<(__streambuf_type* __sb);
があるみたい。本当にこれだけか確実ではないけど。
nullptr_t の方は「nullptr が送り込まれたら "nullptr" と表示しろ」だと思うが
__streambuf_type* __sb は分からん(定義は別ファイル、みたいだし)。
現在アルゴリズムの勉強をしています
puts(“aaa”)やputs(“jais”)はprintf(“a[%d]は%d ～”)の3つは、プリントデバグのために書いたものです…消し忘れました
>>803 https://ideone.com/gIcJzp 納得がいくまで printf() を仕掛けるのはいいことだと思います。
class C
ClassAのメンバにClassBがあってコンストラクタかsetterで外部から与えたいんだけど、
> m_b.reset(&b);
>>809 この場合にスマートポインタは違うようですね
メンバは実体にして渡すときにムーブすればコピーは発生しないという認識は正しいですか？
ClassAはClassBそのものを所有するのか
>>810 スマホ使う前にオブジェクトの所有権を明確にせよ。
ClassBの構築に使う引数も大きいためコピーを避けたいところです
なんでそこでわざわざコピーしたいの？
AにB*とunique_ptr<B>を作って
2つ持つという発想はありませんでした
昔、openGLを使ってC++出遊んでたんですけど、また最近触りたくなりました
>>817 昔作ったツールがひょんなことで役立っています…
あるディレクトリを別のドライブにコピーするだけのことなんですが、いや、まあ、Windows はなかなか御しがたく、path 文字列長が一定範囲を超過すると止まってしまう変てこなコマンドラインツールが未だに現役だったりするのです…
http://2chb.net/r/tech/1434079972/53 >>818 システムコールってやつですか？
オブジェクト指向と並列処理を勉強したいと思ってるのでQtもいいかなと思ってます
どうでしょうか？
Qtのデメリットはライセンスだけだから個人でやる分には良い選択
オブジェクト指向を学ぶのにRubyあたりを使うのは
>>821 せっかく新しい言語を学ぶなら、近い将来役に立たなくなる言語より他の役に立つ言語を選んだ方が合理的だと思う
pythonて破壊的な変更があったのは20年近く前なのに、未だに古い仕様で書かれた入門書が出回っているなら、オブジェクト指向学習に最適化どうかとは別に、問題な気が。
Qt5.12.2はLGPLライセンスでインストールしとけばok?
"Qt Creator 4.8.2 CDB Debugg..." と "MinGW 7.3.0" 64-bit" 入れたら Hello World の窓が表示できるようになったけど、
しばらく正常に動いてるように観えてても
どのような問題が発生しうるのでしょう？
ID:K5RuTlhq です
>>826 https://www3.sra.co.jp/qt/licence/index.html を見て『グラフ作成パッケージQt Charts入れておいた方が便利かも』と思い
いったんアンインストールしてみたのですが、
[Qt 5.12.2 のセットアップ] の画面で
Qt Charts
Qt Data Visualization
Qt purchasing
Qt Virtual Keyboard
Qt WebEngine
Qt Network Authrozation
Qt WebGL Streming Plugin
にチェックを入れたとしても LGPL が選べるようです
サードパーティーの追加パッケージで問題となりうる…？
>>828 具体的に「どのような問題が顕在化」し「どのように困る」ことになるのでしょうか
クラスとメンバ関数のみの指摘でも構わないので、示していただけませんか？
また、その問題を回避する方法は何なのでしょうか？
>>832 LGPLを選べたとしてもQt Chartsを使っていればGPLｖ3
GPLと非互換のライセンスのライブラリを使うなら問題になる
だがそもそも練習段階ならライセンスなど気にせずどんどん書け
昔は知らんが5.12.1ならQt ChartsはLGPLで許諾されるよ？
はっきりとGPLv3と書かれてる
https://www.qt.io/download Open Source->Additional features->Data visualization の？を参照
条項はこれから確認する
>>837 インストールの操作手順からしたら
不意打ちも良いとこだなあ
Qt Charts をチェックした状態で[次へ(N)]ボタンを押したときに
「修正を受けたGPLv3」以外のラジオボタンが無効になってないと
UIとしておかしくねえか
あと「100%GPLv3と一致で修正条項なし」なん？
そうだとしたら、なおさらおかしい
そういえば
純粋に「Qt のライセンス」の話なのでスレチ？
書き込み制限受けたので続き。多分コレで終わり。
int& a;
「すべき」というのは規格表での『shall』のことですか？
std::add_lvalue_reference<int>::type a;
そんなこと気にする前に参照の変数を未初期化で使おうとするなよ。
int& a, &b;
>>847 > 未初期化で使
コレの解釈は揺れそうだが、たとえば
int *i;
とか、
int *i;
int j;
i = &j;
とかいうかんじのことかしらん
わからない事をここで質問しようとレスを書いてる最中に「わかった！」
自己解決パターン
>>851 何が駄目なのかわかれば解決法は自明であることが多い。
逆に言えば、解決法がわからないときは問題が何であるかわかってなかったりするんだよ。
だから、きちんとした形に質問をまとめれたなら、それはもうほとんど解答でもあるんだ。
この手法を利用してバグを取り除くやり方としてラバーダックデバッギングというものが知られている。
C++erならRust学べって風潮嫌い
>>849 あんまり大それた意見とではなくて
void func()
{
int &a;
...
}
と宣言したら、参照先不明の &a を作ろうとしてるから
必ずコンパイルエラーになるじゃろ、程度の指摘。
…ただ、この投稿を書こうとして気がついたんだけど、
class samp {
int &a;
...
};
てな具合に、クラスのメンバとしての宣言ならエラーにならないね。
ちゃんとコンストラクタで a に参照先を与えるなら許される。
要するに
>>847 の前半部分は間違ってた、ということ。
正しい場合もあるけど、常に正しいわけじゃない。
その場合でもコンストラクタで初期化してなかったらエラー出るんだから
>>853 テディベアをおいておくというエピソードなら有名だね
>>854 難しいことも違った方向から見るとわかりやすくなることもある。
質問です。
cinの戻り値のistream&がなんでif(cin)みたいに真偽判定に使えるのかが発端です。
https://stackoverflow.com/questions/8117566/why-istream-object-can-be-used-as-a-bool-expression こことか見たんですけど、
1.istreamはbasic_iosを継承してて、
2.basic_iosで型変換演算子explicit operator bool() const;が定義されてる
ってとこまでは理解しました
ここからが質問なんですけどこの型変換ってのは勝手に行われるもんなんですかね
if(something)って書いたらif(bool(something))っていつもやってるんでしょうか
型変換以前に0やnullポインタを評価するとfalse、0以外の値はtrueと評価されると決まっているからだろ。
if 文の条件判定部は bool 型を要求してる前提で解釈,翻訳してるんじゃない
>>859 yes.
条件部はブールを要求し、もしブールでない場合は常に型変換する。
前橋和弥さんのC言語ポインタ完全制覇という本で、
windows間だから「別環境」ではなく「同じ環境」
>>865 Windows環境であれば、別PC(別ハード)でも同環境とみなして良いのですね
>>WindowsではBMPファイルをfwriteでファイルへダンプしていていかにもWindowsらしいとも書いてある
読み直したら、違ってましたm(_ _)m
可変長構造体の節で、
WindowsではBMPをfwriteなどで可変長構造体まるごとダンプしていて、
BMPのような他の環境にもっていく可能性が高いファイルを構造体まるごとダンプしているのがWindowsらしい
というような内容でした
Windows級の一流プログラマーでも構造体まるごと出力を使っているのであれば、
ゲームのセーブデータで構造体やクラスをまるごとバイナリ出力しても問題ないととらえてよいのかな？
>>866 bmpファイルには仕様があるので「Windowsのプログラマがどうたら」なんぞ関係無く仕様に従って読み書きすべし
（現実には仕様に従わない入出力をやらかすアプリ毎に対処することはあるが）
自分で定義した構造体でも外部に公開するなら仕様を決めそれに準ずるべし
公開しないならそれこそ構造体丸ごとダンプなり好きにすれば良い
実際にそういう実装は珍しいものじゃない
どうせ環境の変化で困るとしてもそれは自分だけだからね
>>864 今でもそうだよ
書いたコードがたまたま正常っぽく動くからと言って
仕様にない動作を期待するコードは糞
つまり、後で困りたくなかったら、フォーマット(読み書きするサイズと順番？)を決めて
異なる環境で扱う可能性のあるファイルならフォーマットを決めるのは当然だが
構造体まるごと fread/fwrite した後に
どういう読まれ方をするか分からない時はXML型式のテキストファイルにしてしまう
>>871 有能！
と思って調べたら、ホスト トゥー ネット(ホストのバイト順(リトルエンディアン)からネットワークのバイト順(ビッグエンディアン)への変換)ですか。
バイトオーダーはこれで問題なさそうですね。
でも、まだです！まだですよー回答者様！
次はCPUによってアライメントの行い方(パディングの量)が違う問題についてです！
fread/fwriteで構造体まるごとバイナリ読み書きする時のパディング値が別PCで異なる場合に良い対処法を教えて下さいませ！
ないなら諦めて
>>872 さん
のオススメのXMLを勉強します！
自分では使ったことないけど、BoostのSerializationは？
パーサコンビネータはバイナリファイルに使ってもいいんだよ。
VC++用に使ってるマシンのCPUがivy bridgeのi5の3570なんだけど、
>>876 E8400の機があるから調べてみよっか？
何で検索したら調べ方出てくるか教えてくれたらやってみるよ
>>877 ありがとう
これでどうかな？
//-------------------------------------------------
#include <stdio.h>
#include <conio.h>
class ClassName
{
public:
int int_1;
double double_1;
char char_1;
double double_2;
};
int main(void)
{
ClassName class_obj;
printf("クラスインスタンスのサイズ:%d\n",sizeof(class_obj));
printf("int_1のアドレス:%p\n",&class_obj.int_1);
printf("double_1のアドレス:%p\n",&class_obj.double_1);
printf("char_1のアドレス:%p\n",&class_obj.char_1);
printf("double_2のアドレス:%p\n",&class_obj.double_2);
_getch();
return 0;
}
//-------------------------------------------------
クラスインスタンスのサイズが24なら4の倍数バイト、32なら8の倍数バイトの境界になってると思う
(8の倍数バイトの境界なら、各メンバのアドレス(16進数表示)が全部8違いになってるはず)
>>878 ソースありがとう
クラスインスタンスのサイズ:32
int_1のアドレス:0036F7A0
double_1のアドレス:0036F7A8
char_1のアドレス:0036F7B0
double_2のアドレス:0036F7B8
これで情報足りるかな？
>>879 どうもありが㌧㌧
Core2Duoで8バイト境界になってるなら、もう4バイト境界の環境の事は無視しても大丈夫なのかもね
思ったんだけど、もしかしたら、32bit(4バイト)のみ対応のCPUと32bit/64bit(8バイト)両対応のCPUの違いなのかな？
違うかな？そんなに単純な話ではないか・・・
本質じゃないがxmlじゃなくてjsonがオススメ
YAML は人間が読むこともあるなら可読性とのバランスで選ぶことはあるかもしれんが、
何にじゃねえな
yamlは最近dockerとかkubanetessとかansibleとかインフラ/環境系ツールのせいでやたら触る事が多い
もう16バイト境界なんてのも出てきてるのか
既定のアライメントというのはふつう、メンバの単純型のサイズに合わせられるはず。
問題ないなら旧環境との互換性重視で4バイト境界にするのもありかな？
互換性重視なら、各メンバを自然なアライメントに配置して手でpaddingを挿入して#pragma pack(1)。
>>891 #pragma pack なんて MS の方言でしょう？そんなのを使いながら「互換性重視」とか矛盾してませんか？
C言語ならともかくC++なのに例外を避けようとする人ってあたまおかしいのかな
>>894 例外の実装方法の一つ sjlj に抵抗を感じるのなら、それは感覚として正常だと思います
C で sjlj を使用しての例外実装コードが書けますか？書けない場合は
>>894 は単なる馬鹿か宗教者だと思います
>>895 何が言いたいのかわからん
sjljが重いのが嫌なのか
あの仕組み自体が気色悪くて嫌なのか
でも今時sjljで例外実装なんてしていないよね
わざわざ選ばない限り
SJLJの話じゃないです
例外もまともにキャッチされないので
エラーの発生頻度によるのでは？
システムによる
>>899 入力の検証、パース以外で頻繁に発生するエラーって例えば何でしょうか？
そもそもthrowはコストそんなに高くないのでは？
エラー情報(コード、メッセージ、下位エラー情報、スタックトレース等)を戻りでコピーしまくるほうが高く付くと思います
>>896 自分で実装できないものを、その仕組みもわからないのにホイホイ使ってしまってもいいのでしょうか？
他の言語ならともかく、C/C++er がそういうところに無自覚なのは大いに問題があるのでは？
そんなことでデバッグできますか？
>>896 ＞今時sjljで例外実装なんてしていないよね
じゃあ win32api の構造化例外sehでも許容しますよ
>>902 内部構造がわからないものでもAPIドキュメントを読んで使えるようになるのが正しいプログラマでは？
まあそういう賢いプログラマなら当然の様にSpectreの可能性に気づいて対策していたんだろうね。
>>904 他の言語ならそうですね
でもC/C++ において、そんな態度でいいのですか？
つまりすべてのAPIをスクラッチでかける人間以外使うなと言うことなんだな
大体sj,ljが肝なのだから、そこ丸投げしたら同じようなもの
内部構造まで把握してなきゃ使っちゃだめなんていう烏滸がましい思想を持ってると
なんかライブラリ使ってるだけの輩がイキリ出しとるなw
静的例外の提案がある。
使える例外オブジェクトに制限があるし、
静的例外を投げる可能性がある関数は型として明記しないといけないけれど、
見かけ上は例外の構文を使いつつ
実質的に返却値と合わせて例外オブジェクトを受け渡すような方法をとれる。
https://cpplover.blogspot.com/2018/07/c.html 江添氏もこれには期待しているらしいことを書いている。
>>911 SOLIDを実践しないからそんなおかしなテストを書くはめになるんでしょうな
例外便利だけど、例外が高確率で起こる場面じゃ使うと遅くなるから、仕方なく結果コード判定してとかの糞コード書かなきゃいけなくなる。
>>912 いいアイデアですね
早く実現して普及して欲しいものです
エラーコードを返す非常識なコードが世界から駆逐されますように
俺は戻り値をboolにするかbool*のout引数を用意してエラー内容はメンバに記憶しておき、
>>914 入力の検証、パース以外でそんな場面ありますか？
それと、その場面は一般的なシステムでもよく採用されるのでしょうか？
ファイルシステムでパスが存在するかとか権限があるかとか
>>916 例外を使わないとこうやってエラー処理がガラパゴス化するんですよね
私が今日弄ったシステムでも一部のコードだけ中途半端に特殊なエラー処理ルールを採用しています
本当に困ります
胃が痛いです
そりゃそのシステムの問題じゃね？
>>918 ボトルネックになるほど存在しない確率が高いファイルに連続アクセスしているならそんな小さな最適化前に見直すべきところがありそうですね
リソースについても同様といえます
>>920 人間のやることなので完璧は無理でしょうな
比較の問題になります
例外とエラーコード返しを比べればどちらが標準的な型式に収まりやすいか？という問題なら例外が圧倒的に優勢でしょう
例外にすればエラー検知は簡単になるでしょうが
例外はcatchで標準化されますが？
戻り値がboolならそれが正常終了したかどうかを表していることは誰にでもわかる
>>925 boolの解釈は人それぞれ
bool is_invalid() const;みたいなのもあるよね
あるいはただのビットフラグのON/OFFを示してるかもかもしれない
そもそもそれが処理の成否を表しているかどうかすら統一されてない
リターンコード方式ではリターンコードと分岐の洪水による目くらましでコーディングミスが多発する
それは必要なcatchを書き忘れる確率よりもずっと高い確率で発生する
例外は処理すべきものだけしか書かないから見通しが良く仕様書との比較もしやすい
リターンコード形式では何もしなくてもいいのに定型処理を書かねばならず
それによってどのエラー処理が仕様書に書かれた本当に必要なエラー処理なのか目で見てわかりにくい
catch 以降でエラー内容に応じて振り分ける訳ですか？
>>927 あぁ
そもそも例外の文法すら知らないのか
>>919 リターン値方式に比べて exception のメリットは何でしょうか？
そしてそのメリットは本当にメリットでしょうか？
>>916 エラー値を取得するタイミングがずれるようだとスレッドセーフを保障できなくなるのでは？
>>922 ＞標準的な型式
なにを「標準的」とするかは世代差があるのではないですか？
java や c# に慣れた人は exception を推すでしょうし
ここで
>>922 を私が強く非難している理由は、「標準的」というバズワードで自説を合理化する、その自分勝手さという点にあります
>>925 ＞ｔｒｙ-catch忘れ
>>925 が return-value 派か exception 派かはここでは問題にしません
しかし、この「try-catch」忘れ、という単語の存在そのものが、exception の利点が利点になっていないことを如実に表現していると思います
忘れないようにするための exception が忘れるもとになってしまっている、とか、全然おかしいんじゃないのでしょうか
>>929 レスを読んでください
>>931 異なる世代の衝突があった場合は今を優先すべきでしょう
過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません
ちなみにC++の標準ライブラリは例外を採用しました
>>932 例外はエラー対応を忘れないようにするためのものではありません
例外はエラーの通知方法を標準化することとコーディングの労力を大幅に低減するための機構です
エラーコード形式でも分岐を忘れることはありえます
むしろ不要な分岐も定型処理として書かなければならないエラーコード形式ではノイズが多くミスや忘れが多く発生します
>>933 ＞レスを読んでください
どのレスかアンカーをいただけませんか？
>>933 ＞異なる世代の衝突があった場合は今を優先すべきでしょう
＞過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません
「今の方が昔よりよくなった」という世界観に立脚しているのであれば、その説は説明できますが
「今よりも悪くなった」と考えている人を説得することができないのではないでしょうか？
>>933 が必要なのは「今の方がよくなった」と言い切れるメリットがなにか具体的に明示することだと思います。
単に「新しい方がよい」という主観だけを振り回しても、アンチ exception の意見を持つ人は納得できません
>>933 は具体的なメリットを明示することをせずに「新しい方がよい」という主観ばかり述べているのだから、議論の仕方をしらない「馬鹿な文系」に私からはみえるのです…
>>934 私の考えるところの exception の利点の一つは、exception の発生した階層から遠く離れたところでも、その exception を catch して処理を記述できるところにある、と考えています
もう一つは exception を catch するとき指定するのは class だから、このエラークラスを派生関係として階層化することで、エラー体系の構造化ができるところでしょうか（派生クラスでも基底クラスでも catch できる、という点です）
しかし exception の話が持ち上がる度に、私の思う上記二点の excption の利点は言及されたためしがありません…
これでは exception の本当にいいところがメリットとして理解されていない、というか、メリットになり得ていないようですね…
exception は単なる無駄コスト食らいなんじゃないですかね…
>>935 沢山あるので面倒です
今日のレスを読み直してください
悪くなったのが事実であれば新しいものが普及する前に消えるでしょう
普及してしまった時点で一部のロートル以外は良くなったと考えている証拠です
>>936 離れた位置で捉えられる点はコーディングの省力化に暗に含まれると考えていいでしょう
全ての階層で定型処理を書かなくてもいい==離れた階層でも捉えたいところでだけ処理を書けばいい
ということです
例外の階層化についてはその通りですね
地味なので忘れがちですが便利です
>>934 ＞エラーの通知方法を標準化することとコーディングの労力を大幅に低減する
ここでもバズワード「標準化」を使っていますね、漠然とした抽象的な単語を並べればいい、という思考の粗さが気になります
それに異常系の記述はどうあがいても、場合わけして都度逐一記述するしかないのは、return-value 派にしても exception 派にしても同じで、記述する中身が減るわけじゃありません
それとも exception で書けば記述が減るというのなら、何か書いてみてください
>>934 を読むにつけても、
>>934 は本当に物事を突き詰めて考えているのですか？
世間がこういっている、とか、Java や C# ではそうしている、とかいう空気の読みあい、ポジション取りの忖度しかしていないのでは？
>>934 はたぶん文系プログラマなんでしょうね、私には強くそう推察されるのです…
>>937 アンカーを書くことくらいもできないのですか？
>>937 ＞悪くなったのが事実であれば新しいものが普及する前に消えるでしょう
google のコーディング規約では exception を推奨しないようですよ
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions 悪いものでも消えずに、もっと悪いことには悪疫として蔓延しているものもありますよ、もしかすると C++ の exception もその一つなのでは？
ちなみに例外はもうすでに新しいものではありません
>>939 エラーに対するハンドリングのコードについては例外とエラーコードの比較の外だとすでになんどか書きました
例外によって削減されコードは無意味な定型処理のことです
googleが例外使わない理由は、例外を否定する類いのものでは無かったような
>>942 ＞例外に変わるエラー処理機構が流行らなかった
というか exception そのものが流行らなかった、というべきでは…
なんども繰り返しますが「新しいものがいいもの」「枯れた機能」とかいう主観はいらないから、「exceptionの具体的な利点」を書くべきです
>>943 言っている意味がわかりません、お手数ですが、少し字数を使って説明いただけますでしょうか？
>>944 「例外安全」を保障するのが、これは滅茶苦茶しんどいので、その一点で嫌われているんだとおぼろげながら感じています
>>941 googleが常に正しいわけではないでしょう
例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです
そして、さっきも書きましたがリターンコード形式では余計な定型処理がノイズとなってそういったミスをしやすくなることが問題です
コントロールフローが追跡難化するリスクも全く逆でダラダラと必要ない定型処理を書かれた方が追跡が難しくなります
自分で考えずに権威を盲信する人を文系と揶揄することがありますが
もしかしてあなたも文系なのでしょうか？
>>945 例外を受け取ると何もせず上位に通知するメソッドを考えてください
例外形式ではコーディング量は0です
リターンコード形式では少なくともリターンコード値が正常系か異常系か判断して戻す分岐が必要です
これは少なくとも1行の無意味な定型処理を追加しなければならないということです
実際にはそのプロジェクトの規約によって1行どころでは済まないことが多いのですが…
>>947 リターンコード形式で発生する余計な定型処理のノイズの例と例外でそれを回避できるケースの例をください
書かなきゃいけないコード量は本来大差ないはずです
例外安全というか、googleで想定しているリソース解放漏れって要はRAIIになっていないって事だよね
>>946 リターンコード形式でも例外安全性(エラー安全性とでもいうのでしょうか)を守るには大きな労力がかかるはずです
リターンコード形式なら自動的にリソースが安全に解放されて全ての状態が実行前にロールバックされるといったことはありません
例外でもリターンコード形式でもリソースの解放と状態のロールバックの責任はプログラマあります
>>947 ＞例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです
そこで exception の実装に話が戻るのです
exception の実装（例えば sjlj, seh のどちらかひとつでいい）はどうしても（隠れたところに）グローバル変数を必要とするのではないですか？
これはスレッドセーフや例外安全を考えるときに、大きな癌になりうるでしょう
一方、return-value 方式は、頑張ればローカル変数だけで記述できる
return-value 方式の方が考えるのが楽ではないですか？
＞自分で考えずに権威を盲信する人を文系と揶揄することがありますがもしかしてあなたも文系なのでしょうか？
かりにそうだったとしても最初は「新しいものはいいものだ」で押し通そうとした、あなたには言われたくないですね…
>>949 例外の場合
T val = f(...);
エラーコード場合
T val;
int ret = f(..., val);
if (is_error(ret)) return ret;
最小だとこの程度でしょう
とはいえ膨大なコードベースになるとこれだけでもうんざりしますが
>>948 その例外の上位への素通し、って、確かに
>>936 では私も例外の利点だと書いてしまいましたが、でも実際には嫌われることなんではないですか？
java は下位ルーチンが発生させる例外（のうちのある種類）は、上位側で catch しとかないとコンパイラが怒るんではないでしょうか？
嫌われないよ
>>956 なるほど、だとすると、
>>936 で書いた「exception の発生した階層から遠く離れたところでも、その exception を catch」できる、というのは無条件では c++ では利点にならないですね、return-value 式とほとんど変わらない…
>>952 たとえグローバル変数を使った実装だったとしても例外の利用者にとっては透過的なので問題はありません
スレッド処理でも問題はありません
同じスレッドでは利用者は何も気にせずに例外使えます
スレッドを結合するところでは例外を転送してください
そのための標準的な方法も用意されています
エラーコード形式の場合はスレッド間転送も標準のない独自形式になるのでより難しそうですね
>>954 Javaには例外時に自動でリソースを閉じるための構文が存在しない時期がありました
検査例外はそのときの名残です
GCされるまで自動で閉じられることはないからちゃんと手動で解放しろと注意喚起する意味では検査例外にも価値があります
逆に言うとRAIIやusing/IDisposeのような機構が適切に使われている場合はうっとおしいお節介でしかないわけです
ちなみにリターンコード形式場合はリソースを確保していない場合でも定型処理を書かなければなりません
したがってそのうっとおしさは検査例外とは比較にならないほどの負担になります
いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
納得させる気は最初からないからね
機械学習とかアプリケーションレイヤの開発をしてて普段はJavaとかpythonで書いてるんだけど相談。
例外安全という言葉には色々と含まれるけど、
>>960 ＞いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
あれ？れれ？
おっかしーなー、私もプログラムを書く人だし最低限自分の作ったバグくらいはさっさと片付けたいので、そのためにも、いつも論理的でありたいと願っているのですが…
そういうとこだよ
>>963 ＞違いはないがどちらかに一貫させるのが望ましいと考えると、
＞C++ の基本的なライブラリに併せるべきだということになって例外を使うのが妥当という判断になる。
この意見に対しては私は痛烈な批判を浴びせることになるでしょう
曰く、C/C++ の人なら言語的な統一感よりもコスト、というか単純性を優先したくなるのではないですか？
UML のグジャグジャ感をみるにつけても、「言語法律家」なるものはきわめて忌むべき存在と私は考えています
exception を実装するためには、隠れグローバル変数をどうしても準備しなければならない
シングルコアで exception の履歴を単一スタックに全部のせることができるのなら、ローカルで sjlj を駆使して、あるいは書き手からみえないところで純ローカル変数的世界に納めることもできたかもしれませんが、
今やマルチコアで実際に複数のスタックとプログラムカウンタが走る時代で、exception の実装は OS に丸投げの複雑怪奇、ついでにコストも複雑怪奇でパンピーには理解が及ばない…
そんな巨大かつ複雑なスケールの実装を必要とするのに見合った exception のメリットは何か、今も自問自答を繰り返しているのです
単純さを選んだら例外になったというお話だったのさ。ちゃんちゃん
なぜsjljにこだわるのか
c++の言語仕様に例外の実装にはグローバル変数使えとかSJLJ使えなんて縛りあったっけ？
>>971 実装方法までは言語仕様に記述されないでしょうね…
>>972 ということは例外の実装にまで踏み込んで考えるのはナンセンスなのでは？
ちなみにおれはc++の例外は大規模開発でworkしないと思ってるから
>>968 いつの話をしてるんだよ。 モダンな環境では例外送出の実行コストは充分に小さい。
特別な環境で特別な対処をしなきゃならない場合を例に出しても意味がないぞ。
ふーん、そういう場合はそうするんですねとしか言いようが無い。
>>976 sjljでない場合
例外がおこらない分にはオーバーヘッドないけど、起こったときのスタック巻き戻しが重い
こういうこと知らずにクリティカルなとこで気軽に例外発生させるバカをよく見る
抽象化ができずどんな粒度でも低級のセオリーを通そうとする
>>978 アホみたいにmap使いまくって後でひどい目に遭うアホもよく見るな
>>980 それが必要なのってC++コード全体からすると何パーセントくらいなの？
>>982 しらないけどクリティカルな処理ないならc++使わなくていいんじゃないの
なんでわざわざこんなしんどい言語使う？
>>981 別にmap使いまくってもいいよ
ちゃんと抽象化しとけば後でチューニングするのは簡単だから
>>984 まさかw
データ構造大事だよ初心者さん
合ってるね
>>988 そこで作り直すから低スキルなんだよな
前任者がせっかく変更に強いシステムを組んでやったのに台無しにするんだ
>>989 変更に強いとかの内輪の都合よりUXの方が大事だよ
初心者さん
>>990 その大事な大事なUXを向上させるために抽象化するんだよ新人君
さすがにそれは意味不明では？
そういうのいいから
UXの向上にはフィールドバックと変更のループが必要
御託ご苦労さん
>>977 そりゃあクリティカルなところという特別な場合には特別扱いが必要ですねって
だけのことで、そんなこともわからんやつは例外を使おうと使うまいと駄目だよ。
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/tech/1545944692/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「【初心者歓迎】C/C++室 Ver.104【環境依存OK】 ->画像>3枚 」 を見た人も見ています：・おかあさんがチンパンジーみたいな顔でお昼寝してた 【悲報】ツイッター浪人界隈、大麻が出回り始め終わる むかしあの雨の夏日夕立が風鈴鳴らして昼寝からさめた 欅坂の菅井が腰痛のケアのために数百万の機器をフランスから買い寄せたことが欅坂界隈で話題 消えた2千円札を探せ 今も1億枚が現役…沖縄では流通増えていた 誕生してからもう18年経ちました 【任豚悲報】NHKアニメ人気ランキング、ポケモン348位！妖怪ウォッチ400位圏外 駅メモ界隈のイケメン金持ちといえば橿原なな ヒモ界の憧れ 坂田亘お通夜会場 離婚してからの一人暮らし 31 雑談 胸の鐘の音を鳴らしてよ 【FF14】パンデモ界隈粘着スレ 【詐欺運営】ポケモンマスターズ148【佐々木悠】 ホモ界のブラックシープ 石川大我豊島区議、社民党に離党届を叩きつける 【画像】ホモ界隈、サウナで邪魔なホモジジイを先に手コキで逝かして追い出す『成仏』という技が流行 【ホリエモン×ひろゆき】グーグルイヤホンの自動翻訳を称賛『ドラえもんの「ほんやくコンニャク」に匹敵する技術』 バイクをブンブン鳴らしているヤツに一言！ 楽器鳴らして騒いで革命？笑わせるなよ 実際、イイ音鳴らしてる場所ってどこよ？ ニー速してから天使の囀りがきこえる クラクション鳴らして気を集める むかしあったボーリング場レーン スタンド出してからこのスレ開け 【悲報】ポケモンカード界隈、中国から大量の偽造品が出回って終わるｗｗｗｗｗｗｗ King Gnuお気持ち表明「鳴らしてる音が全てだろ？」 野生ポケモンの世界 怪獣ポケモン萌えスレ もっと怪獣ポケモン増えろよ ポケモン界で立ちそうなスレ ぼくがポケモン界に産まれたらね ポケモンの世界に行きたい！けど… 膝関節ポキポキ鳴らして軟骨すり減らしたら身長伸びるんじゃね チンフェ、緊急地震速報をむやみに鳴らして混乱させる 「プロは扇子を鳴らして読みのリズムを取る」←これ JK「ライターで高校の火災報知器鳴らしてみたｗｗ」 ドラクエ発売してから本当イカ2忘れ去られたなぁｗ 軽の分際でクラクションを鳴らしてる奴がいた お前ら、5chが再稼働してから競馬板に立て放題だぞw ◆◆◆昔むかしあったとさ◆摂津の国川辺郡◆◆◆ いまからきみたちにはころしあいをしてもらいます そういや長らくクラクション鳴らしてないなぁ 尾木直樹からハッとして目のさめるような教育論って ポケモン全世界同時操作でプレイ 実況★152 ポケモン、世界中の国民から叩かれ始める 各世代の各タイプポケモン数を集計してみた 【新型肺炎】ポケモン世界大会、開催中止！ 工藤由愛「初めましてのお魚！もうかさめ。サメです！ご存知の方いらっしゃいますか？？」 ポケモンと妖怪ウォッチを仲良く語ろうぜ 4 相談所「頼むからおじさんはもういい加減にしてくれ。令和の時代におじさんはモテない」 【悲報】子連れまんさん、自転車のベルを鳴らしてどかなかっただけで男を盗撮して炎上 ポケモンと妖怪ウォッチを仲良く語ろうぜ 04 現実がポケモンの世界だったら入りたい団 世界中で大流行のポケモンGO、NXと連動か ポケモン最新作各シリーズの糞な所ｗｗｗ 【速悲報】ポケモン世界大会、またミラー ポケモン実況者界隈、あゆみん一強になる 各都道府県の「ぬしポケモン」を決める ポケモン界最強はメタモンじゃないか？ 【悲報】ポケモンカード界隈がひどい ポケモン二次創作の世界観で好きな設定 ヒーリングっど プリキュア 第21話「はじめまして！わたくし、風鈴アスミです」★3 ポケモンの世界のSDGsにありがちなこと Windows10のアップデートしてからキー入力が異常にもっさりしてるんだがウチだけ？ 子供達がポケモンから妖怪ウォッチに流れた理由 【国際】「平和の鐘」鳴らして和平訴え 創設７０年で国連事務総長ら[9/21] お前ら、プログラミング勉強しとけよ 出来んと就職してから困るぞ
08:33:02 up 63 days, 9:31, 0 users, load average: 7.96, 7.67, 7.38
in 0.10420298576355 sec
@0.10420298576355@0b7 on 061921
