◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:C++相談室 part148 YouTube動画>17本 ->画像>2枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1580471646/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part147
http://2chb.net/r/tech/1576659413/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://2chb.net/r/tech/1556142878/ ■長いソースを貼るときはここへ。■
http://codepad.org/ https://ideone.com/ [C++ FAQ]
https://isocpp.org/wiki/faq/ http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
gotoの話でもするか？ それともマクロ？ ハード絡みのところなんか俺的にはオモロイが
前スレ999だけと循環してないよ
こらこら、前スレ999は俺だぞ
>>7 999へのレスって意味ね
文脈で理解してほしいところだが
で循環論法でないことわかった？
環境を限定しないならこれ以上続けても無駄
struct AutoDeleteFile {
それではおじいちゃんのaddress談義
ともかく最初に思ってることがあって
でも、もともと主張がおかしかったから、釣りだったのはホントじゃないの。
釣りっていうかただの構ってちゃんな。何か深い考えがあるというわけでもないし。
釣りじゃなかったら相当痛い人だし。
ところで僕は自分の職業の板ってまったく見ないんだけど。
わしも見ない
break break;
ネアンデルタール人はホモサピエンスの基底クラスであったか。
ネアンデルタール人のＤＮＡ、アフリカの現生人類からも検出 新研究
https://www.cnn.co.jp/fringe/35148770.html 2020.01.31 Fri posted at 13:15 JST
多重ループを抜ける方法
ループに名前は名前を考えるのがイヤ
break [数字] は数えるのがイヤ
関数を分けてreturn はもっとイヤ
変数を使ってbreakで抜けるのは論外
でもgotoはなんとなくイヤ
全ての要望に答えたのが
>>32 バカの要望を聞いてさらにロクでもない方向に行ってしまうっていう
ん？
あえて説明してるところで恥ずかしいことになってる奴ｗ
>>37 while(){} や do{}while(); で使えないので却下
for(int x = 0; i < ... )
>>37 何個の break を書くのか、と break の後に書く数字は? で
結局のところ同じように数えなきゃならないでしょ。
>>32 はcontinueを混ぜられるのが面白いけど、やるならこうだな。
break n;
continue n;
こういうしょーもないシンタックスの話って馬鹿でもしやすいのが盛り上がる理由なんだろうな。
特定の言語のスレ
break 9;
>>55 C++ ではオブジェクトの寿命の管理と辻褄を合わせなきゃならないんだから full continuation は無理だぞ。
ループに名前を付け、その名前で離脱や継続を行う。
途中で送信してしまった。面倒だから書き直さないが、
gcc5ぐらいから一気にgcc10にしたらエラー表示とかデフォルトの警告とか色々変わっててわろた
>>61 まあね。だけどgotoはフリーダムすぎて良くないでしょ。
いや全然そう思わない
>>52 コンパイラ毎の最適化における癖とか、例外の実装についての差異なんかも語ってもいいんだぞ。
>>63 goto は自由すぎるけども、ループを何段階も一気に抜けたいとかいう状況がすでにだいぶん自由だと思うぞ。
そういう状況が生まれたらもう駄目なんだよ。
ごちゃごちゃとした使い分けを考えるよりおとなしく goto した方が「そこが悪い」ってのが目立って良い。
一番使いたいのは2段break
構造化を壊さないことを保証した仕組みで脱出したいってことでしょ
2次元構造の2個のループを抜ける為に
>>67 gotoは悪、多重ループは悪、みたいなどこかで聞いたルールを杓子定規に常に遵守すべき絶対ルールのように考える人が少なからずいるんだろうね。声が大きいだけかもしれないけど。
gotoの利用にコンパイラの補佐があればよかったのに
中カッコ、変数の有効範囲含め
一切禁止とか言うから
>>67 ここでワイが「悪い」って言ってるのは使うなとか別の方法がとれるとかいうほどの強い意味じゃなくてさ、
気を付けなきゃならないポイントとして目立ってもらわなきゃ困るって程度の意味。
だけど、日常的にそこら中でそういうポイントがあるのならやっぱり悪いとは思うけど……。
二重ループの脱出は
関数オブジェクトはまともなコンパイラならインライン展開される
贅沢言いすぎだね
Pascalは完璧な構造化言語を目指したから
[&]{
抽象的なレベルで考えたら break は
[&]{
>>82 break 2 も gotoでループを抜けるのも同じ
>>83 それは最悪
throw 3; って書いてもチェックされないし
>>67 ３重ループは？ ４重ループは？ なんで２だけなの？
[&]{
>>87 答えられないならレスしないで下さい
ウザいだけです
for () {
>>90 だな
必要になったことを変に偽装する悪癖を治すべき病人多すぎ
ほんまになぁ。
>>89 日本語が不得意みたいなので英語で説明しますね
Double loop frequently appears to treat a two dimension structure such as matrix or image data,
so "break from double loop"is used by programmers related mathematical or visual product.
>>67 states that is good reason and s not always bad design.
>>93 意味わかんね
なんでそんなことするの？
アホだから？ それともバカだから？
>>94 It's purely kindness for non-Japanese speaker. Did you not like it?
>>92 構造化的には
breakも途中でreturnもgotoでループを抜けるのも同じだよ
Пожалуйста, говорите по-японски.
なんだロシア人か
Я не понимаю
>>67 , потому что я не понимаю японский?
>>96 同じだからそれ以上に新しい文法を持ち込んでもそれほど綺麗にならんって！ ということを言いたい。
>>96 gotoは正しく使えばという但し書きがつくでしょ
そこをなんとかしたいという話だと思ってる
それが論点だとするとgoto使えというのは解にならない
>>102 正しく使う前提なのは当たり前
なんでgotoだと正しく使わない前提になるのか不思議
危ない操作はできないようにしようってのが言語の進化だからな
>>104 構造化プログラミングの概念は知ってるんだよね？
gotoを正しくしか使えないように改良したのがreturn、break、continue
>>104 構造化プログラミングでは使わない制御構造を
使うべきでない理由が構造化プログラミングって論法に
抜け出せない枠があるとは思わないの？
>>108 continueだけ、それで正解なんだが
他はみんな間違ってるよ
見てください皆さん、ID:BhmlSyWc ← ひどいですよ
>>106 どの辺からgotoが危ない操作だと思うの？
まあ1万行ある関数の中で、5千行目ぐらいにgotoがあって、ラベルが関数の先頭付近にあるとか、それに近いのは見たことあるが、あれはどう考えてもgotoの悪い例だからな
>>110 きつくて気の毒だな
不勉強なやつは自業自得なので同情はしない
>>112 １万行か・・・これ↓より重症だなｗ
http://www.pro.or.jp/ ~fuji/mybooks/cdiag/cdiag.10.4.html
不定値や無限ループの危険はgotoに限ったことじゃないし
gotoはどこへ飛ぶか分からないから読みにくいんだよ
どこに飛ぶかわかる名前にするってのが普通の発想
>>117 飛び先じゃなく飛ぶこと自体の問題なんだがｗ
つまりはそういう話で、追いやすいように飛び先を制限したいよねーってのが根底に有って
構造化プログラミング知らずにgotoいきって使うのはさすがにやばい
>>122 どうなっていれば「追いやすい」のかを
まず明らかにしようぜ
俺ルールでもいいし
広く認知されているルールでもいいし
巻数はどこに飛ぶか分からないが、必ず元に戻ってくる(のが基本)
使い所でgotoが使えないのはセンス無い
本心では誰もgotoは否定していないんじゃないかな
多段breakは考えた奴は脳味噌が糞すぐる…
ああ、そうだな
画像処理とかで2重ループ良く書くけど、最近2段階breakしたくなった記憶がないな
まーC++がプリプロセッサを殺すために進化しているのと同様
goto とか break とか continue とか、他の言語（javaとか）でもいろいろ小手先的に弄られているけれども、それに何の意味があるのかいつも不思議におもいますね
ループを抜ける為にだけ使われる変数を使ったループ抜け
>>136 gotoが使わないで済むように進化してくのは期待している。
ただ現状として、多重ループを抜ける場合みたいにgotoを使うのがシンプルで分かりやすいならば、毛嫌いしたり盲目的に原則振りかざすよりgoto使えばいいだけのことだと思うよ。
>>138 お前ほんとに病気だな
多重ループ脱出でgotoが簡潔なのはみなわかってる
でもgotoは自由度が高すぎて構造を壊す可能性があるわけ
だから改善するとしたら何があるかという話をしてるだけであって
別にgoto禁止とかの話はしてない
好きなだけ使ってろよ
あと構造化プログラミングぐらい知っとけ
for () {
for () {
Pythonはループにラベルをつける手が使えた
またgotoの話になってんのかよ。。
ただ、凝りに凝った複雑怪奇なテンプレートより
多段breakの使用頻度がそれほど多くないことを加味すれば
breakの後にマジックナンバーを書くのが気に入らない
ただし、break n;のnの部分が変数でもOKとかなってたらかなりウザいが
breakとbreak nが同じとか意味不明な主張をなさる御仁がいらっしゃるが
別にcontinue n;
do {
break nなんてやるくらいならbreak label で抜けるループを明示的に指定したいな
break nが良いとか言ってる椰子は
do{
そういう機能要望みたいなのここでやる意味ある？
,,-―--、
>>149 break n なんて間抜けの極みだと思いますね
java にはラベル付き break が存在して、ほとんど goto です
https://www.sejuku.net/blog/20100 >>136 Cはgoto殺すために進化してねえよ
Cのgotoが関数外に飛べないのはスタック巻戻しのような仕掛けが複雑になりすぎるからで
構造化プログラミングで否定されるからという理由ではない
構造化プログラミングで否定される制御構造を持たないことにするなら
breakやlongjmpは存在できないはずだ
結論が先にあって理由が後付けだから支離滅裂、一貫性の欠片もない事を書く
ほんと、宗教だね
>>159 根底がわかってねえやつが多いからだよ
古典的な基本がわかってねえやつは若造と爺のどっちに多いだろうね
頓珍漢なことを書いて袋叩きにされたからって逆恨みする精神性なやつはどっちに多いだろうね
break labelでいいんじゃね
gotoは便利なswitchだからね。
さすがにgotoでジャンプテーブル化の最適化までやる処理系は
アドレス直接指定なのに、テーブル必要ないんじゃないの。
（条件分岐無しの素のgotoだけでどうやってswitchの便利な代替品にするつもりなのやら…
頑張ってひねり出した！！
>>175 お前が何をいってるのか、何を考えてるのか理解できないのに、お前を納得させられる奴なんていないぞw
お尻にラベルつけて break ラベル; がいいとか言ってる奴は構造化の意味がわかってなさ過ぎ
名前使うならこんな感じか
>>176 俺自身何を言っているのかよくわからないのだが。
もしくは、forの直後
ループの先頭にラベルを書くくらいなら
あの、スレとは全然関係ないんだけど。
NDEBUGを知らなかったからです。
NDEBUGってISO/IEC9899やん
今の一重ループを抜けるときの普通のbreakにはラベルを付けないのに
下方向にだけ飛べるgoto相当機能があればgotoは要らなくなるんじゃない？
>>190 は、Cにgoto <label>とbreakがあるのになぜCはbreak nを設けるところまで踏み込まなかったのか、とか
break <n>で即値<n>に行き当たったコード閲覧者が行き先を知るために何をせねばならないかとか、
考えた方が良いので
は…
>>190 break nを勧めている人？
対象が1段なのと複数段とでは大きなギャップがあるでしょ。単純に対称性があると言えるものではないと思う。
ラベルつけるならgotoと手間が変わらないというのは同意。ただ、重要なのは手間が減ることではなく、複数段のループの外に出ることが明示されることだから、gotoと意味が混同されず同じ程度の手間でできる記法があるならそれは嬉しい。
現実のC++について話せ
手間が減ることは重要だよ
大体だよ、多重ループはbreakで抜けれないので、仕方なくgoto使うときの
ソースコードチェック目的でプログラム読むとき、gotoが出てきたら
そんなに名前が無いと発狂するんならもうgoto使えば？って思うし
関数コールも問題のないコールかどうかチェックしないといけないから
それならもうポインタもグローバル変数もマルチスレッドも大量のチェックが必要だから使ってはいけないってことで
>>199 私と認識が似ていますね
>>137 ＞goto とか break とか continue とか、他の言語（javaとか）でもいろいろ小手先的に弄られているけれども、それに何の意味があるのかいつも不思議におもいますね
>>164 java にはラベル付き break が存在して、ほとんど goto です
https://www.sejuku.net/blog/20100 現行のC/C++にはgoto <label>がある一方、break <n>は無い
>>201 現実ありえないのは重々承知したうえで書くけど
100重ループを脱出するとき数を数えたくないだろうなって思うじゃん
ほかにも3重ループとかで2ndと3rdのループから共通の脱出先ラベルにもできるわけじゃん
文法を拡張する前提ならそこまで想定すべきだと思うね
粗野な即値の数字じゃなくて意味ごとに名前をつけられるようにしてきたのが
プログラミング言語の進化の歴史なのでおれは自然だと思うよ
というかそういう観点からラベル付きbreakというのは他の言語にはあるわけで
で今話してるのはもっと書きやすく読みやすくできないかというトピックでしょ
break Nは使えるだろうけど洗練されてない感じ
break [n] はラベル名を考えなくて良い利点がある
break n とか言ってる奴は何故か
>>150 をスルーしてて笑うわ
他の人は「マジックナンバー」だと思わなかったからでは。
foobarやhogeを超える人気なダミー文字列を考えたほうがよほど建設的だぞ、君たち。
break 5; //C
マジックナンバーがイヤなら
関数で置き換える
>>214 多重ループを単一関数に書くって前提だね
>引数がめんどうならラムダで置き換える ←New!
>>217 左様
それがラムダ式を適用して解決づべき適切な場合である（ｷﾘ
ジーオーティーオーというスペルでなければ
スレとはあまり関係ないんだけど、nodiscard属性を無視するにはどうしたらいいですか？
変数で受けといてその変数をガン無視すればいいんじゃないの
>>210 お前の言う「他の人」はマジックナンバーの意味わかってないってことか？
このスレ見てたらありえなくもないかと思えてきたわw
あと三日くらいしたらお前より出来るようになってるから。
>>208 昔のBASICは、行番号を勝手に付けてくれていたのでgotoでもラベル名を考えなくて済んだのでとても便利だった。
>>226 なお、アセンブラでは行番号がなかったのでラベル名を考える必要があったが、
意味のあるラベル名を考え出すのは大変だったので、分かり易い場所以外は、
多くの人が、lab1: lab2: lab3: のような連番を使う傾向があった。
>>226 ＞昔のBASICは、行番号を勝手に
auto 文だったかな…
すまん俺の聞き方が悪かったのかもしれん
検索はstd::setやstd::unorderd_setより速いけど、挿入が一桁遅い。
初学者的な質問です、よろしくお願いいたします。
バイナリーファイルを
std::fstream f;
f.open(filename, std::ios::in | std::ios::out | std::ios::binary);
でオープンし、同一ファイルのオープン中に
f.read(), f.seekg() でガンガン読むと同時に
f.write(), f.seekp() でガンガン書き込む
を試しているのですが、seekg(), tellg() と seekp() tellp() は名前は別でもあるにもかかわらず、実はファイルポインタの実体は両者で同一なのでは？
という疑いが発生しました。つまり、seekg()/tellg() と seekp()/tellp() とは独立でない、と推測しています
①この解釈で正しいですか？
②こういうのは、C++ iostream レファレンスのどこを見て洞察するべきなのでしょうか？
実際のお題は相変わらずエラトステネスのふるいです
https://ideone.com/6Ww9nq >>231 ,233
私は今のところエラトステネスの篩にご執心、という体たらくです…
エラトステネスのふるいで
>>244 結構昔から
http://www.asahi-net.or.jp/ ~KC2H-MSM/pbsb/pbsbm006.htm
にとても興味を持っていたのです、二つの隣り合った素数の差を「素数のギャップ」と呼ぶことにしたとき、
『素数のギャップが取りうる値の頻度。はじめは２、４が多いが、そのうち、６の方が多くなる。』
『６がチャンピオンの座を降りるのはいつか。』
『少なくとも 10^14 以下では６がトップであり、それ以降、いつ、６以外の数がトップになるかは、知られていない。』
10^14 までの数であっても全部、篩としてメモリに載せられないので、さてどうしたものかと思案中です、最終的には年スパンでずっと計算させ続けるのに耐えられるようにしたい、と
その問題だけなら
>>246 コメントありがとうございます
＞間隔も大して大きくならないのでヒストグラムはオンメモリで済む
確かに 10^10 まででも最大 354 というのには驚きました、案外密に分布しているんですね
＞2次キャッシュに収まるくらいに分けてふるえば速い
constexpr unsigned int windowSize_Default = 30 * 5000000; はでかすぎ、ですか
いただいたアイディアは、どれも私には難易度が高いのですが、ぼちぼち書いていきます…
AVXレジスタを使って小さな素数の倍数を消して
>>229 100 WIDTH 80,25:CONSOLE 0,25,0,1:SCREEN 1:CLS 3
110 XXX
120 XXX
130 IF XXX = XXX GOTO 110
のようなもので、最初に入れるときは自分で行番号も手で打つのが基本ではありました。
115 YYY と入れると、110と120の間に行が挿入されると言う仕組みです。
それだと9個以上は挿入できなくなるので RENUM 命令を使うと行番号を自動的に
振り直すことができました。その場合、GOTOやGOSUBの行番号も連動して変わる
仕組みです。
>>248 コメントありがとうございます！
＞大きな素数の倍数は210ずつ処理する
私は、2*3*5 = 30 でわりと満足していましたが、2*3*5*7=210 まで拡張されたのですか！？うーむ…
>>249 mon に入って、プログラムタイトルのコメントの行番号を手打ちで全部 0 にする、とか…
どうでもいい話でごめんなさい…
素数は、6n ± 1 か。
A = 6n + 1, B = 6n + 5 とすると、
>>242 たぶんこの一文。
> A joint file position is maintained for both the input sequence and the output sequence.
N3337 だと 27.9.1.1 の第 3 段落にある。
あくまでも std::basic_filebuf ではそうなってるってだけなので、
ストリームバッファ全般に言えるわけではなくて、
独立した位置情報を持つようなものも作れないわけではない。
FILE の fseek のラッピングとして実装することを想定したんじゃないかなぁ。
>>250 ビット命令が48個続くだけ
それほど大変じゃない
今だともっと良い命令があるかも
>>254 コメントありがとうございます。いまいちよくわかっていない iostream. の全体像を掴めるよう、いただいたヒントも頼りに潜ってみます
＞FILE の fseek のラッピングとして実装することを想定したんじゃないかなぁ。
fseek() が 64bit オフセットならいいのですが
あるいは win32api：：SetEndOfFile() のような、オフセットを指定して trunc する方法があればいいのですが
>>242 のバイナリファイルは単に uint64_t な素数を突っ込んでいるものですが、ある日末尾が中途半端にちょん切れてしまったのです…
>>256 それファイルに書く必要ある？
仮想メモリ頼りにメモリでやれば？
>>256 巨大なファイルにちょくちょくシークしながらアクセスするなら
メモリマップトファイルを使った方が楽やで。
>>256 ググってみたら iostream まわりの継承関係を表した図がすぐ見つかったわ。
https://www.ntu.edu.sg/home/ehchua/programming/cpp/cp10_IO.html だけど継承関係の他にストリームがバッファとロケールを所有しているという関係もあるのが分かり難いかも。
cpprefjp の rdbuf の項目を見たらストリームのバッファを入れ替える例が載ってる。
https://cpprefjp.github.io/reference/ios/basic_ios/rdbuf.html 本当に「入出力」を司っているのはバッファであって、
ストリームはそれに書式化の機能をかぶせている感じ。
>>257 それはダメでした。win7, 16GB、素数の大きさが10^11 程度でスラッシングが発生して win7 では使い物になりません
GIMPS cli のように、普段は意識することなく3年くらいかけて計算するようにしたいです
>>258 着々と容量が増加するファイルに対して mmap は使えるのですか？win32api：：CreateFileMapping では mmap を確立した後にファイルサイズを増やしてはいけない制限がありました
>>260 そんな制限があるんか。
連続した巨大なメモリを予約しておいて、
適当な大きさに区切ってファイルにマッピングすればええで。
ファイルを複数に分けることになるけど、
見かけ上は巨大なメモリとして扱えるし、
容量が増加する都度に新しいファイルを作って割り当てればええ。
というやり方を思いついたので具体的に出来るんかいなと思って調べてみたら
MapViewOfFileEx の最後の要素でアドレスを指定する機能がある。
VirtualAlloc で予約した範囲は MapViewOfFileEx で使えないので、
どうやって空いているメモリ空間を探せばええんやろと思ったら
VirtualAlloc で予約した直後に VirtualFree をつこうたらええんやて。
https://stackoverflow.com/questions/12121843/mapviewoffileex-valid-lpbaseaddress なんという泥臭い方法や……。
てなわけで、若干の面倒くさい手順が要るけどそれっぽいことは出来る。
この手順をいい感じに抽象化するクラスを作ったら色々と使えそうやな。
期待してるで！
普通にAPIで巨大ファイル作れてるけど
最初からどでかいファイルを作る余裕があるならその方が簡単ではあるわな。
CreateFile
こんな感じ？
STLコンテナ (仮にvとする) のサイズの分だけfor文を回したいってときに
コンパイルの警告のためだけだから
手でタイプするコストうんぬん言うなら
>>267 最も正統派なのはこうかな？
for(decltype(v)::size_type i=0; i<v.size(); i++)
常識的に考えてコンテナの size_type が std::size_t より大きいことはあまりない (大抵は等しい) と思うので、面倒なときは std::size_t を使う。
本当に上限が限られていてその上限が変更されることがあり得ないほどそのプログラムにとって
本質的なものだと判断すれば int でいいやってこともあるといえばあるだろうし、
同じようなパターンが何度も現れるならアダプタを作った上で範囲forというのも考えられる。
状況によるでしょ。
int i = 0; と書かずに size_t i = 0; と書くのはどうだい？
>>267 コスト(性能)最優先か
見やすさ最優先か
タイプ数最優先か
次第
キャストのコストって言うけど
intとv.size()のサイズが違えば
どのみち型変換する
コンテナ使うような場所でこんな微妙なコストを気にしてもしょうがないし
>>270 は面倒
(業務外だと)私は警告放置が多い
警告を消したい場合はsize_tにするか
コンパイラの設定を変えるか
業務で集団でのコーディングの場合は
他の部分を見て空気を読む
for(unsigned int i=0, len=v.size(); i<len; i++)
>>269 template <typename T> inline auto len(T s) { return s.size(); }
>>274 その形が一番、速度的には良い。
forの第二式は毎回評価されるが、v.size()の部分をコンパイラが自動的に最適化するのは非常に難しい場合があるから。
v.size()の値が、ループ内で変化しない「ループ定数」であると判断するのは
コンパイラにとってはものすごく難しい場合がある。
ループ定数であると判断された場合にのみ、
>>274 のような最適化が行われる可能性が出てくるが、判定できなければループするたびに毎回評価されてしまうのでループの実行速度が遅くなってしまう。
>>283 本人だけが開発していて、記憶力が優れていて絶対に使い方を間違いなければ特に問題ないと思うが、使い方を間違うと危険なことがある。
エラーも出ずに変な動作をしてしまうことがある。
でもそれさえ気を付けていれば特に問題ないとも言える。
>>269 マクロで書く場合、
#define LEN(_s_) ((int)((_s_).size()))
と書いたほうが良い。
特に、s や _s_ を()で囲むのは必須。
sを_s_と書くのは、ミスタイプがあった場合の備え。
例えば、マクロの仮引数にsと書いているのに、マクロの定義部分をtと
書き間違えていて、かつ、マクロを使う場所に t という変数がたまたま使われて
いたとすれば、エラーにならないのに間違った動作をしてしまう。
_s_と書いていれば、_s_という変数は絶対に使われないのでこの心配がない。
そのため、マクロの引数は伝統的に、_s_などのように書くことが推奨されている。
>>280 適してるかどうかはともかく
>>269 は解決にはなってる
>>276 は解決になってない
皆さんありがとうごさいます。
結構難しいですね。
>>274 > for(unsigned int i=0, len=v.size(); i<len; i++)
これは
for(int i=0, len=(int)v.size(); i<len; i++)
としても性能上そう変わらないですよね？
ループ変数はintであってほしいと思うので、これが自分には向いているように思いました。
キャスト一回って機械語４つくらいじゃあないの？
糞コンパイラまで考えてパフォーマンスを考えると
>>288 だけど
そもそもコンテナ経由でアクセスする時点でそんな事は誤差
そのループに非常に時間がかかるなら
ループ全体で最適化しないと
>>290 同じBIT数やBIT数が少なくなる場合の整数型から整数型へのcastは、マシン語では0命令（命令が出力されない）。
高級言語では違う型でもマシン語レベルでは変わらないため。
BIT数が多くなる場合には、x86の場合は、movzx や movsx が使われる。
>>292 実際には、最適化が上手く行かないことも多いので差が出てくることは多い。
>>293 つまり、符号無しや符号付の区別はマシン語ではないので C/C++言語で
castしても高級言語レベルでの意味が変わるだけでマシン語レベルでは
何の命令も増えることはない。
素直にrange-based-for
普通のコンパイラなら
未だindexループよりrange-basedのほうが早い処理系がない件
>>298 v[i]が重いってどんなstlコンテナだよ
>>267 ＞警告を一つ残らず潰したいタチだから
ここまでは同感です
＞毎回こういうのはintにキャストしてるんだが、
私なら int i を unsigned int i にしますが
templete<typename T>auto LEN(const T& v)->signed T{return (signed T)v;}
とりあえず大きい方に合わせとけば間違いないんだからsize_tでいいじゃん
>>300 整数のキャストに比べればはるかに重い
そのレベルを気にするなら生ポ
>>304 vectorだと生ポと変わらんでしょ
もちろん最適化前提で
>>300 range-basedはiterator
c++のiteratorはindexが速くなる連続アドレスのコンテナならpointerと同じコンパイル結果になる
indexアクセスがpointerより遅くないなら、それはコンパイラの最適化のお陰
>>306 生ポと変わらなきゃ良いんだけど
変わるんだよ
VisualStudioやチープなコンパイラだと
いずれにしろここから先は
具体的な環境とループ回数やループの中身全体で考えないと意味がない
なんせ1クロックレベルのことを気にしてるようなので
実はメモリアクセスが支配的で
他の最適化は全く意味がないとか
SIMD命令 / DSP命令 / スレッド分け / GPU
ところで元々の質問の >>267 は整数の型が合わないのどのくらい気にする？ >>278 業務外だと、とは書いてあるけど一応突っ込んでおくと
もしそれがコンパイラの警告レベルを下げるとか小さい型へのキャストの警告を無くすとかなら
それはバッドノウハウだよ、真似しないように
じゃあ俺、えっ、それって駄目だったん？ 派でお願いします。
>>311 わし、こうみえて「警告される箇所は仕様の詳細を調べる派」や
その上で、問題なければ「状況と程度による派 (柔軟派)」に再度ブランチする派
Boostは警告を無視する派、GoogleはMicrosoftの問題なので修正する予定はない派。
目grepが難しいので、警告は消すしかないんだけど。
変数の大きさが変わると同じ値のビット表現が変わるのはしんどいので、符号が一番右端にあったほうが良かったんじゃないの。
型違い面倒だからautoにしても警告出るから何でやおもたらi=0でintだったでござる派
HTMLにしろコンパイラにしろ、Microsoft案のほうが合理的と思うけどな。
>>302 signed Tはできねえぞ
std::make_signed_t<T>にしないと
> コンパイラの警告は潰す派
基本的にはsize_tとかsize_typeとか使え派
i は int にしたいって言ってるんだから
>>298 vがグローバルなオブジェクトである場合や、ヒープから確保されたオブジェクトの参照型である場合、コンパイラには v.size() がループ定数であるかどうかを判定するのは難しいことが多い。
このスレでもグローバルに確保された構造体型のメンバを参照する場合、最適化され無い事が指摘されていたが、それと同じことが原因。
C/C++ではポインタや参照があるのでグローバル変数やグローバルなオブジェクトのメンバ変数が変化しないことをコンパイラが見極めるのが難しい。
for(auto i=v.size()+1; 0<len; --i)
reverse_iterator first(v.end()), last(v.begin());
64bit/32bitまたぎできるソース汎用性を考えれば、負の数が必要ないなら size_tを使うのが最善でしょ。
size_tはunsignedなのがうざい
ポインタ + size_t == ポインタ
>>326 仮に毎回アクセスしたとしてもv[i]の方が重い
毎回アドレスを計算して毎回メモリアクセスするわけで
ばかでかいループをたくさん作るなら
8086時代の苦しみを知っている人なら
ループの中身も知らないで良く言うね
今日日4GB越えとかWindowsNT4.0サービスパックですか、と。
納品したときに
あと警告が出ないからと言って
>>342 それはお前が悪い
そんなんで納品するな
客先と同じビルド環境で警告対応しないのは落ち度だね。次の仕事なくなるでしょ。
>>333 BYTE v[数値];
のような生配列の場合、ループの中のv[i]は、最適化が効いてものすごく効率の良いコードになることが多い。
この場合、vがグローバルに確保されたオブジェクトや参照型であったとしても最適化には余り悪影響はない。
vがstd::vector 型の場合で、かつ、vがグローバル・オブジェクトや、参照型の場合は、コンパイラはv[i]を上手く最適化できないかもしれない。
>>346 すまん。
後半部分は勘違いかもしれない。
>>346 VCはvectorでも生ポインタに近い最適化はしてくれてるみたいだぞ
客や同僚から使えないプログラマ認定されていることに気づけず独りよがりな考えに凝り固まる人いるよね・・・
標準ライブラリのコンテナのイテレータを sizeof で見ればわかるが、ほとんどの場合で void* と同じ大きさ。
>>349 おまえがきちんとした仕様を提案できないで投げっぱにしてるからそんなことになってんじゃないの？
>>340 64bit空間で64bit以外のインデックスを使うべきループの中身とやらを書かないあんたが悪い
書けないんじゃないのか？
intだとたったの2G要素でオーバーフローして無限ループになるのが怖い
イテレータよりポインタのほうが速いよ。
>>351 「無視して良い警告」とか勝手に判断する困ったPGにきちんと仕様を提案しても無駄でしょ。解雇するわ。
unsigned だと
警告で指摘された問題点に対処もせずに、キャストやらで無理やり消す位なら、出たまま放置の方が100倍マシ
ヒープ作るとき、マイナスの値は空きノードのリンクリストに使ったりするので、その手の比較は多発する。
うーん、近頃はちょっとした作法レベルのところまで警告として口出しすることがあるからなぁ。
仕事ではやってんなら手を抜くなぼけ
従来cppcheckなどの静的解析ツールが出していた警告をコンパイラも出すようになってくれたのは良い動き。
>>360 すごい偉そうにしてるけど大丈夫？
>>327 ;0<len; って···
>>360 俺はプログラミングについては趣味者だから実務のことは知らんのだわ。
すまんな。
しかしな、必要以上の品質にするくらいなら手抜きで安くしろって言う客の方が多いと思うぞ。
必要より下になったらあかんのでそこを制御していい感じの
手抜き具合にするのが難しいわけだが、そこを上手くやるのが
手抜きしないことよりもプロに必要な資質じゃね？
手抜きしないよりも適切に手を抜く、どうやって手抜きするか知っていることが大事だ。
仕事は経済的に割に合う形でしか継続できないんだからさ。
そりゃあいつも十全な仕事が出来る時間的・経済的余裕があるならうれしいが、
現実はそうではないだろ。
>>366 何言ってんだ？
手抜きしたいからこそ、コンパイラの警告に素直に従うんだぞ。
DirectX関連使ってるとenumよりenum classを優先しますという警告出るんだけど、ライブラリ変えるわけにもいかなく、どう対応するのが正解なんだろ？
そもそも警告って規格で定められている訳でもなく、コンパイラが独自の基準で勝手に出してくる物だからね
>>370 議論のための議論とか、言いがかりのような仮定の話に、いちいち付き合わないことが重要。
>>371 変な作法が追加されることなんて良くあるんだぞ。
今じゃ gcc や clang で -Wall オプションを付けたら
a || b && c
みたいな式にすら警告が出る。
優先順位を間違えやすいとこだから括弧で明示した方が良いんだと！
演算子の優先順位くらい把握しとるわ！
こんなの警告されるようになると想像したことあったか？
他の演算子でも同様の警告を出すようになることくらいはあるかもしれんぞ？
確かに
>>370 は極端な例ではあるが、ようわからんところでしょうもない警告が出るようになる
かもしれんという懸念は無い話ではないぞ。
>>374 趣味でしかやってない人の意見なんて無視しろ、というが私の回答です。
>>379 ゲームのチートツールとか。
汎用的な便利なツールは色々とあるけど、個別のソフトをいじるには行き届かないこともあるので。
念のため言っとくけど買い切りの RPG かフリーゲームだけ。 ネットゲームはやってないよ。
ちなみにそのツールは公開してない。
その他に作った有用そうなものは公開してるんで、身バレするから言えない。
>>380 そうなんですか。
ずいぶん詳しいのに仕事じゃないというから不思議に思ってました。
つまり、はちみつ某は、なんの思い入れもない他人のソースを読まされる身になった経験が少ないわけか。
アルゴリズム考えるときは、図を必ず書くと思うんだけど、皆さんは何を使ってますか？
>>382 せやな。
そんなわけで、他人のバイナリを見る機会はあるけどソースはそれほどでもって感じかも。
結果的に読まなきゃならないことはあるけど、所詮は趣味だから嫌になったらいつでも止められるし、急がなくてもいいし。
プレッシャーに晒されながらクソみたいなソースを読むってことはない。
C++なんざ仕事で嫌々書かされるだけの言語だと思ったけど
>>383 曖昧なところから思考を整理するなら紙と鉛筆でいいと思うけど、
それなりに書式の整ったようにするなら PlantUML とか。
GUI で自由にってことなら Dynamic Draw くらいが手頃かもしれない。
完全な趣味目的でC++を触る変態はそうそういないと思う。
>>386 禿１読んで信者になった変態もおるんやで
>>386 ゲームのチートとかするために
既存のプロセスに割り込んだりする処理を書こうと思うと C か C++ くらいしかまともな選択肢なくね？
C で足りるなら C で済ませることもあるけど、もうちょっと高級なことがしたくなったら C++
ってのは妥当な選択肢というか、唯一解でしょ。
まあ近頃は Rust にも興味があるけど……。
カッコつけろって人
> えっ？何か意味があるの？
優先順位を完全に把握しているなら機能的には意味のない括弧だと理解しているんだろうが
(a + b + c) + (d + e)
>>393 と言ってる趣旨が違ってないか？
実際に
>>397 みたいなコードを見たことがあるの？
同じ印象だって話
ちなみに、
わざわざ
>>397 のようなカッコを付ける時はある
協業できない人があれこれC++について論じるのは害でしかない。
まずプログラム言語っての読み書きする人間のためにあるって大前提忘れてるか自覚してないやつ多いな
>>399 マイナスが混ざっているならわからんでもないが、
>>393 で言っている優先順位の話とは関係ないように思うが？
見やすいかどうかは主観なので、他人や未来の自分が読んで誤解しないようにすることが肝でしょ。
まさか、「数値リテラルの桁区切り文字」にまでかみついたりしないよね？
https://cpprefjp.github.io/lang/cpp14/digit_separators.html 主観で見やすい表記にする
>>374 >
>>371 > 変な作法が追加されることなんて良くあるんだぞ。
> 今じゃ gcc や clang で -Wall オプションを付けたら
> a || b && c
> みたいな式にすら警告が出る。
> 優先順位を間違えやすいとこだから括弧で明示した方が良いんだと！
> 演算子の優先順位くらい把握しとるわ！
把握してても間違えやすいからだと思うね
実際にはa,b,cには比較演算子を使った式が入ることが多いだろう
そうするとけっこうな長さになったりする
で全体の構造が見えにくくなる
そりゃ書いてる真っ最中は問題ないさ
しかし後から読んだときにすぐ理解できなかったり、手を加えるときに間違えたりする
warningを出すべきかは議論の余地があると思うけど、
出すべきと考える理由はわかる
それはエディタの機能でかっこを表示したら良いのでは。
主観は重要だろう。
&,|とか&&,||は*,+の関係と同じだから括弧つける方が冗長で分かりづらくなると思うんだが
一度書いた四則演算の数式を書き換えることはほとんどないけど、bool論理演算は頻繁に書き換えるでしょ。
数式を遅延評価するオブジェクトを作れば
テクニックの限りを尽くしてbetter C++を実現したら良い
プロなら抽象的な質問には回答しないでしょ。時間泥棒にあう。
自分の職業の板には一切いかないから、ここも職業プログラマはいないと思う。
職業プログラマって？
たとえば、外科医が匿名の掲示板で効果的な治療法について話し合ったりしないでしょ。
プロの対義語はアマ。素人の対義語は玄人。
>>374 -Wallとは別に「お節介は一切禁止」というオプション欲しいね
>>374 はわかるけど
>>393 ,
>>397 で警告出すコンパイラとか見たこと無い
私も見たことは無い
カッコを付けろって結局警告が出るから付けろってことで
警告の出方がコンパイラによって違うわけで
>>426 それはつけた方がいいだろ。
見づらいのはスペースの使い方に問題がある。
えっ？
>>428 演算子の優先順位くらい勉強しておけよ
手間かけさせんな
>>366 手抜きがどうこうと最もらしいこと言ってるけど
>>359 で言ってるのは「警告に対処するのが面倒くさい」ってことだろ？
仕事で手を抜くべき場所とそうでない場所、みたいな次元の話じゃない
あと警告レベルは最大にしたりすると標準ライブラリにすら警告出るけど、標準より下げるのは良くない
そういうこと平気でやってると必ず後で本格的に面倒くさい原因不明のバグが頻発する
256倍バグを出しても256倍早く潰したら
if( a == (b+1) || a == (b+2) )
>>433 256倍もバグ出すような奴と仕事したくない
>>435 先方も256倍遅い奴と仕事したくないと思うてはるで
じゃあ次は
勢いあまってこれも否定しちゃう
>>439 b==-1が成立することが有るのはウィンドーズのバグ
if (a = b+1 || a == b+2)
>>438 if(a != true){
return true;
} else {
return false;
}
みたいなコード見たときは流石に絶句したわw
>>441 それはまた別な話
ところで
>>374 は
if(a = b){
みたいなコードに対する警告も不要と言うんだろうか？
>>441 学習が足りてないだけ
括弧なんて要らん
理解できるレベルまで進化しろ原始人
>>440 で、 if (b) と書いちゃっても自分のバグじゃなくてWindowsのバグと主張する
>>445 C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。
なお、余計に混乱を招くだけかもしれないが、
数学的には、b == true とは、単なる数として完全一致であることを調べる演算子ではなく、集合的に、b ∈ {非0} であるかどうかを調べる演算子だとみなすことも出来る。
ところが、C/C++ では、== 演算子は単なる数としての一致を調べる演算子で、
かつ、TRUE は通常 1 にマクロ定義されているので、
b == true が、b が完全に 1 に一致しているかどうかを調べる演算子になっている。
なので、if (b) と書く方が正しく、if ( b == TRUE ) と書くのは間違い。
>C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。
回避して使うかどうかとは無関係にバグはバグじゃわ；
>>439 はジョークのつもりだったが、実際に勢い余った人が2人も現れるとはｗ
>>442 なにその想像を超えたキチガイ
>>449 アンタの親切心が何人かの明日を救ったねｗ
プログラミングはアートやからな
>>442 ,450
対話デバッグでaに応じて実行をブレークしたかった人が残したデバッグの痕跡だろうね。
ソースを他人に公開する際にはブレークポイントの情報はなくなるから、他人には意味不明だけど。
>>451 狂気じゃなくて修正の積み重ね。少しづつ修正していると大ポカに気づけない。
だからこそ親切なコンパイラの警告に従う謙虚さが大切になる。
>>452 そっち？
a != true
じゃなくて？
BOOL b に対して、正しくはこう :
graphvizは主要なLinuxの標準リポジトリに入ってるから助かる
>>403 浮動小数点数なら桁落ちとか気にしてんのかなーとか勘繰る
>>403 整数の場合だと、括弧を付けてある部分に何らかのまとまった意味があるのかも知れない。
数学や物理学では、計算を減らすために式変形していくが、最終的な式は元々の意味が分からなくなってしまうことがある。
その場合には括弧で囲ったくらいで意味が分かり易くなることは少ない。
しかし、そのケースの場合は、括弧で括ると何か意味が分かり易くなると考えた間ロウ製がある。
>>455 >if ( b == TRUE ) // 駄目
-1をTRUE扱いしたくないのであればこれが唯一正しい
MSDNの書き間違いかもしれないが、Win32 APIの一部にも「成功時はTRUEを返す」という
>>461 そもそも、-1 は TRUE 扱いすると言うのが C/C++ の伝統や文化。
-1 と TRUE を分けて扱うのは、特殊な独自仕様。
>>462 Win32 API の一部どころか、ハンドル値を返す以外のほとんど全ての関数が、
成功すれば TRUE を返す。
おいおい、#define TRUE 1のTRUEと真(true)の区別がぐちゃぐちゃだぞ。
C++にはtrueがあるので積極的に使っていこうと思います。
>>464 なるほど確かに Win32 の BOOL LineTo(HDC hdc, int nXEnd, int nYEnd)の 戻り値は、
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
のように、成功時には 1 や TRUE ではなく、「非0」を返すと書いてある。
キャッシュかキャッシュでないかで速度が変わる。
○ if(b) if(!b)
そういうのをみんなで共有しましょうって事で、たらこさんが2chを作ったんですよ。
>>470 常識というか思い込み。
大半のFALSE/FALSE以外を返す関数なら上で良いが、
>>462 のようにTRUEを返すなら当然
TRUEと比較しなきゃ正しくない。
本当にそんなのあるの？
>>446 ＞C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。
＞if ( b == TRUE ) と書くのは間違い。
それは b の型が int だったら、そのとおりだけれども、
>>438 をみるかぎり bool b なんでしょう？
はっ！これが老害というやつですか…
>>473 GetMessage という基本的な API からして変則的だから……
>>462 に書いたMSDNのは単にドキュメントの間違いという可能性もあるけどね。
それとは別に、TRUE/FALSe以外に-1を返すAPIがあるのは有名だろう。
いずれにしても仕様をちゃんと確認してそれに従った扱いをすべきで、思い込みは禁物ってこと。
>>475 GetMessage の返却値の場合は一応は TRUE の特殊な場合として -1 の状況もある
って感じだから TRUE とは別の場合を意味する第三の状況というわけではないな。
>>466 bool も式にまざるといつのまにか int に暗黙に型変換されちゃったりして、
やっぱりこう、あまりしっかり区別されてる気がしねぇなあと思うことも多いよ。
Windows API で使われている BOOL よりはかなりマシではあるけど。
GetMessage()が-1を返したときはエラーなんじゃわ；
「WM_QUITでない」という条件における真（0以外）の中の特殊な場合（エラー）に-1ってことなのね
今なら適当なフレームワークをかぶせて使うもんだと思う。
klocworkがboolメンバ変数にportingがどうのって言ってくるのがうざい
>>474 やっぱQZってとんでもなくバカだな
>>439 からの流れ読めよ。BOOLについて会話されてるぜ
正の型の値と負の型の値を比較する場合、ビット幅の大きいほうの型に変換されてから比較されるんですかね？
>>472 いや。TRUE は、必ず if 式で真と判定されるので、if (b == TRUE) としなくても
if (b) で絶対十分であることは補償されている。
むしろ、if (b == TRUE) と書くのはバグの原因になるので駄目だと言われている。
なんというか、TRUE は、処理系ごとに変化する値ではなく、C/C++ においては、標準的には必ず 1 に #define されている。
非常に古い時代に、TRUE を -1 と定義していた処理系もあったかもしれないが、
>>492-493 言語仕様にある true を避けているのだから、
その環境においては標準と異なる事情があるのだと察するべきじゃないの。
まあそういうことがあったらもっと別の名前を付けるべきだとは思うけど。
C/C++ はその性質上、様々なシステムの仲立ちをする機会があるし、
いろんな事情に左右される。
TRUE を 1 と定義する機会が多いのは確かだろうし、
そのときの習慣が確立されてもいるのもわかってるけど、
それが当たり前かっつーとそうとも言えんのじゃないかな。
趣味人だとかいってるがハチミツ餃子はたまに良い事いうから困る
>>494 TRUE が 1 以外に定義されていても、TRUE の値は、if 文では真と解釈されることだけは保障されているので、if (b) は問題ない。
逆に BOOL b の場合、b が非0であるが、TRUE のマクロ値とは異なった値になっている場合がないとは保障はされない。
なので、if ( b == TRUE ) だと、TRUE ではないが b に真とみなせる値が入っている場合にすり抜けてしまう恐れがあり、重大バグの原因となる。
>>495 ハチミツじゃなくてはちみつな。
>>496 それが真偽値だというのが思い込みで、
実際には様々な可能性が有り得るってことだよ。
普通はこうだからこうみたいな話じゃなくて、
少なくとも言語仕様に無いのはわかってるんだから、
その環境でどうなってるかくらい確認したれやという話。
>>497 私は
>>493 からあくまで現代の話だと読み取ったのでそのつもりで返答してるけど、
C/C++ のコードは長期的に使われやすいので現代という範囲の認識に齟齬はあるかもしれん。
WindowsAPIはC++限定じゃなくCを主軸に捉えてるだろ
>>462 > MSDNの書き間違いかもしれないが、Win32 APIの一部にも「成功時はTRUEを返す」という
> 仕様の関数があるんだよな。
具体的にどれ？
>>493 TRUEが-1というと昔のBASICにそういうのあったね
だがその時代すでにCも存在していた
>>496 何回ループしてるんだよ。
真(truthy)であることが要求されているなら if (b) だし、TRUEであることが要求されるなら
if (b == TRUE) だ。それを取り違えることがバグだ。
まあ失敗時はFALSE、とも書いてあるから、こう書くのが正解！
あと
>>461 は、
>>455 の三択で選ぶならif (b == TRUE)だが
正しくは↓こう書くべき
bRet = GetMessage(...);
if (b == -1) {
// エラー1が発生すた、
....
} else if (bRet == FALSE) {
// エラー2が発生すた、
....
} else if (bRet = TRUE) {
// 成功すた、
...
} else {
assert(0);
}
つまり出題者
>>455 の知識と想像力の欠如が諸悪の根源
訂正orz
誤: bRet
正: bRet32
>>509 訂正、
誤： {{
正： {
>>510 訂正
誤： bRet = TRUE
正： bRet32 == TRUE
C89にboolがないことに拒否反応を起こす頭の固い奴に迎合して作られたboolでないBOOL
先にWindowsがシステムコールとしての素朴な要請からbool型の実装型を定義して、
>>510 > } else if (bRet == FALSE) {
> // エラー2が発生すた、
> ....
エラーじゃないぞ
人の知識とか想像力とか言う前に自分の知識を見直せよw
といっても成功していないのだからエラー扱いで差し支えないなのでは…
>>510 GetMessageのマニュアルをちゃんと読めクソ雑魚
エラーの時は-1、WM_QUITの時はFALSE(0)を返すが、それ以外の時は「nonzeroを返す」としか言ってない
nonzeroというのはたくさんの値の集合であって、その判定をある特定の値と==で行うことはTRUEが1だろうと他の値だろうと完全な間違いだ
つまりお前のその糞プログラムは完全にバグっているし、お前がバカにしてる
>>455 らが言った通りの間違いをそのままやらかしてる
クソ雑魚>>510 はマニュアルを読まない可能性があるので、マニュアルの使用例貼っておきますね >>519 >TRUE以外ならassertで落としていいなんてどこに書いてある？
それはこちらが聞きたい；
何を見てそう思ったのか？
>>519 変数いらねーから
for(;;)
switch(GetMessage(&msg, hWnd, 0, 0))
{
default:
TranslateMessage(&msg);
DispatchMessage(&msg);
break;
case 0:
return int(msg.wParam);
case -1:
throw std::system_error(std::error_code(int(GetLastError()), std::system_category()), "GetMessage");
}
while(GetMessage( &msg, hWnd, 0, 0 ) >0)
とｵﾓﾀがわかった
GetMessage()は WM_QUIT以外を受け取ったとき非0を返す、としか書かれていないから
bRet32 == TRUEでは正しい判定にならないのねん
使ったのがｽｹﾞｰ昔なので忘れていたが、そのときは多分
>>519 式に書いたから安心してﾎｽｲ
しょうもない事で攻撃的になるやつなんなの
>>506 BASIC というか、古の言語にはビット演算と論理演算の区別がないものが結構あった。
全てのビットが立った状態 (-1) を真ということにしておけば
ビット演算用の AND, OR, NOT がそのまま論理演算のそれとして使える。
昔はこれが気の利いた方法だったんだろう。
#define FALSE 0 ← 正しい
>if(b != FALSE) ← 正しい
意味的にboolなら
if (a == TRUE)
もともと
>>438 と
>>439 を混同すんなという話なんだが、混同してる奴が次から次へと湧いて出てくるｗ
>>528 #define TRUE (!0) ← 正しい
C/C++ では、!0 は、必ず1 になることが仕様化されているので、仕様に準拠している
処理系ではこれは必ず、
#define TRUE 1
と書くのと同じになるので、敢えて (!0) と書く意味は無い。
boolだろうがBOOLだろうがYESNOだろうが
>>529 糞コードだが
> if(b == TRUE) ← 間違い くず! 0点!! 出入り禁止!!!
より１億倍マシ
>>528 1がイヤなら0もイヤだろう
#define FALSE (0!=0)
としないと
>>537 マシとか言う以前にそもそも動作が違うんだが。
bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？
普通はTRUEかFALSEしか入ってないんだよ
switch (b){
>>539 それは難しくいえば数学の集合論の話になる。
{0} と {非0} の二つの集合が有り、
if の条件式では、前者が偽、後者が真と評価される。
TRUEはどんな処理系であれ、必ず後者の集合の要素(元)になっていることだけは
保障されている。
なので、if ( b != 0 ) や、if (b) は正しいが、
if (b == TRUE) は絶対駄目、ということになる。
>>543 BOOLなのに
1と2を区別したい事があるんだってさ
if ( b == TRUE ) は、この条件式自体の動作は問題ないが、
TRUE/FALSE以外を想定するなら
昔VB6からWinAPI呼ぶときの注意点として本で読んだ気がする
>>545 じゃあ聞いてみよう。
bがTRUEと一致するかどうか判断する必要がある場合はどう書く？
>>546 排中律が成り立たないからFALSEでないことはTRUEを意味しない。
成功した場合にTRUE、失敗した場合にFALSEを返すという関数がある場合、成功したかどうかは
FALSEでないことではなくTRUEと一致するかどうかで判断しなければならない。
>>548 架空のケースについてのお答えは差し控える
つか糞コードかどうかはともかく
>>509 の方はMSDNの記述に準拠したコードという意味では
非の打ち所が無い（何かあってもMSDNのせいにできる
>>539 > bがTRUEと一致するかどうか判断する
それ自体がまずい（ことが多い）と指摘されてることにそろそろ気づこうよ…
>>552 >>514 見ているのにいまだにそんなこと言っているのはなんでだろう
intの取り得る値の集合に対し、TRUEの定義が-93でありかつそれ以外は偽と解釈をせよと仕様に書いてあったら
FALSEは定数
集合B={FALSE=0,TRUE=1} の場合 !FALSE=TRUE だが
数学関係ないのに数学ネタでひっぱってるヤツがいるな
>>553 >>514 の話なら>> 509だし、そうでないAPIもたくさんあるから
> それ自体がまずい（ことが多い）と指摘
されてるんだが、まじでわかってないのか？
引っ込みつかなくなってるだけだと思ってたが…
訂正
グローバル領域にインスタンスを作って、初期化はmain()の中でしたいとします。
>>561 逆に不思議だわ。
「成功時に0以外の値を返す」と「成功時にTRUEを返す」は違うということがなんで理解できないのか。
>>566 どこから違うことを理解してないと思った？
思い込み激しすぎw
GetGlyphOutline などで文字画像を取り出そうとすると、フォントが持ってない文字は代わりの文字を出力してくる。
>>571 違いを理解しているなら
>>566 の後者はまさに
>>539 だということも理解できそうなもんだが。
>>574 ここよりwindows apiのスレのがいいんじゃないかな
>>576 もしかして（ことが多い）っていう意味もわかってないのか？
win32は変な仕様多いからAPIの仕様確認しないと罠にはまる
多い方に合わせろって話でもないだろう。
>>568 の通りそれぞれの仕様に合わせて適切に扱えってこと。
GetModuleFileNameとか仕様作った奴のセンスを疑う
>>580 誰も多い方に合わせろなんて言ってないのに…
単にそういうケースが多いって言うだけの話であることも説明しないとわからんのかな？w
なら問題ないケースもあることを理解してるわけだ。だとすると
>>552 で指摘してたのはなんだろうと。
>>584 えっ？
まだ（ことが多い）ってわざわざ書いてる意味がわからんのか？
まともな奴と会話してる時ならいちいち書かないんだが、ネット掲示板なのでわけわからん奴に絡まれないようにわざわざ書いたのに想定外の低能さんなの？
>>585 つまり
>>552 は、まずい場合もあるしそうでない場合もあるという意味のない指摘なわけだ。
ようやく
>>539 に戻れたな。
>>537 マシとか言う以前にそもそも動作が違うんだが。
bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？
bがTRUEと一致する条件の話はしてなくて
余所でやれって、APIと言語仕様のズレの話だろ
APIの正しい理解ならAPIのドキュメントを見れば良いのでは？
>>586 > つまり
>>552 は、まずい場合もあるしそうでない場合もあるという意味のない指摘なわけだ。
お前には意味ないのかもな…
必死になりすぎw
>>533 に書いたが、boolじゃなくてBOOLの話をしているのになぜかboolと混同する人が
boolの話題でbool以外を語るのはこんな感じ
BOOLも同じ
>>590 意味のあるなしは主観だからいいとして、結局これ理解できたかな？
>>537 マシとか言う以前にそもそも動作が違うんだが。
bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？
>>594 >>552 低能は一度指摘されたことを何度も繰り返すw
boolができるまでは
>>576 を理解しているなら
>bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？
このような判断がが必要な場合があることも理解しているはずだろうが、
結局この質問には答えられない(答えたくない)ようだな。
goto、マクロ、BOOL
つか真理値の型であるbool型および
>>487 え？話の発端は
>>438 でしょう？
>>439 は
>>438 の bool を BOOL にすげ替えたミスリードでしょう？
>>491 もう一度いいますが、
＞if (b == TRUE) と書くのはバグの原因になる
のは b の型が int であれば、確かにそういえますが、b の型が bool ならばなんの問題もなにのでは？
https://ideone.com/aL3agg 前提条件を全然考慮せず、条件反射的に
＞if (b == TRUE) と書くのはバグの原因になる
と判断するのは老害的発想と私は断定しますね
一般論として、APIの呼び出しが成功しました、という情報にはそれ以上幅も糞も無い（成功した要因など知っても無駄
まあエラー要因を複数種類返したい、ということなら
if( b == TRUE ) って、結局 if( b ) ってことだろ。
>>555 ヘッダファイルの中で TRUE の値が -93 に #define で定義されていたとしても、C/C++ の仕様だと、0だけが偽で、0以外は真であることだけはANSI Cで決まっているので、それはない。
つまり、
>>548 その場合で、かつ、b が TRUE に一致するもの以外を除去したいなら
if ( b == TRUE ) と書く以外には無い。
しかし、Win32 API の仕様でも、そのようなことを判定する必要があることはない
ように通常、作られている。
何人かが指摘しているように、FALSE との判定は良いのだ。
TRUE との判定はまずい。
gotoといいBOOLといい、闇が深いな
【IT】不動の人気を誇る「Python」、評価が二分される「Java」「JavaScript」
http://2chb.net/r/bizplus/1581244420/ >JavaScript、Java、Python、「C++」「C」が特に多くの人に習得されたプログラミング言語だった
C++11規格でJavaやC#の優位性がかなり失われた気がするわ。
>>614 というか、JSやJavaは、ちゃんと学んだ人も多いだろうが、
Pythonを実際に使ったことのある人はかなり少数派だと思う。
>>617 Javaは、GUIも出来たしブラウザ上でも動いたし、他に代わるものがなかったので
それしか選択肢がなかったために実際に使った人は多かったはず。
JSも、HTMLを使おうとした際にそれしか動的言語は無かったから同様。
一方で、Pythonに関しては、似たようなものは他にたくさんあるし、
自分以外の人に使ってもらうにも実行環境のインストールが必要だし、
Javaと違って互換性にも問題あるので使いにくい。
>>618 つまり、Pythonの評価が高いのは、前評判だけで実際に使った人が少ないから。
ごちゃごちゃいうよりまずはいっぺんオッPythonで
自分で1000行も書かなくても、どこかの誰かが書いてくれたライブラリを呼び出せば
pythonで1000行くらいで根をあげてるようじゃ
インデントをきっちり合わせないといけないので、Cの適当なインデントにうんざりしてる人にはむしろ合うかもしれない
機械学習ならpythonほぼ必須なんだが
pythonがいいとは思わないけど、perlがクソすぎるので相対的にマシだから流行ってる
perlの代替っていつの時代の話だよ
Pythonは、スマホで動かすのは難しいらしい。
>>630 Pythonのせいではなく、Perlのようなスクリプト言語がそもそも使えないという
スマホの限界だとは思う。
スマホでも使えることは使えても、IDEのような専用環境だけで使えるだけでは
本来のスクリプト言語としては使い物にならない。
このスマホの時代に Perl, Python, Ruby は合わないかも。
iOS, Android 共通にスクリプト的なことをやりたいなら、もう、スクリプト言語は諦めて、
>>625 - 括弧などに従って自動でインデントが付く
- 手動 (あるいは半自動) でインデントの位置を合わせる
これの二択だったら前者の方が「きっちり」してると思うわ。
まあインデントの付け方にいくつかの選択肢がある点はやりづらい面も
あるかもしれんが、自由度と統一性は両立できないもんだしな。
Python はいじったことないからよう知らんけど、 (インデントで構造を表す系統の文法である) Haskell を書くのはつらかった。
Haskell ではインデントと改行の替わりに波括弧とセミコロンも使えるけど、Python にそういうのないの？
pythonをswift, javaなんかと比較してる人は
>>633 ブロック開始終了記号とインデントを両方組み合わせたものが一番分かり易くて間違いにくい。
インデントだけでやると、個人的には見間違いそうで神経をすり減らすので辛い。
研究者が使うのにPythonは良い選択なんじゃないの。
今さらですが、そもそもWin32のFALSEって、0であることは保証されてるんですか？
>>639 まともな C/C++ では、FALSE はどんな処理系でも 0 であることが保障される。
>>639 規格書のようなレベルで規定されているかどうかは知らないけど、公式ドキュメントの至るところで
FALSEは0である前提で書かれているものが見つかるから、そこを疑う必要はないと思う。
>>640 FALSEはWindows SDKの定義であってC/C++とは直接関係ないんだが。
>>640 現実にはそうだってのならわかるが、質問は保証があるかどうかなんだから、根拠を添えろよ。
少なくとも現状の WinDef.h では FALSE は 0 、 TRUE は 1 と定義されているのはわかったし、
常識的に考えればこれが変更されることはないが、
私はマイクロソフトのドキュメントからこれを裏付けるような文言を見つけられなかった。
BOOL が int であることは発見できた。
https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types should be TRUE or FALSE って書いてあるのにこれに反するような API があるのはアレだよな……。
システムハンガリアンもそうだけど明白な違反が堂々と放置されているからなあ
>>642 >>643 [根拠]
数学的に以下の根拠となる：
1. FALSE は、if ( FALSE ) とすると、偽として処理されることは絶対に保障される。
2. if (x) で x が偽として評価されるのは、ANSI C も、古い C でも必ず 0 という1つの値のみであり、他の値はすべて真と評価される。
1, 2 を両方成り立たせるためには、FALSE は必ず 0 でなければならないことが
証明される。
数学が大事です。
昨日の奴かｗ
>>645 頭が悪いとか話が通じないってよく言われない？
言われる度に相手の方が間違ってると思ってるだろうけど、話が通じてないのはお前が自分の間違いを認識できてないからだぞw
このスレには、失礼ですが、はちみつさんも含め、数学に弱い人が多いようです。
>>649 いや、むしろ逆に現実では天才と呼ばれています。
仕様書にすべては書いてなくても、数学で考えれば絶対であることが証明できる事柄があるのです。
ああ、荒らしに来ただけか。
失礼ですが、はちみつ氏は、C++の仕様には詳しいですが、それ以外は結構間違っています。
>>656 ここでの君の書き込みだけで判断すると
君が間違ってる可能性が高い
>>1 私は、東大数学科の人とは意見が一致することが多いです。
よく考えてみてください。
もし分からないようなら、多分、あたなは東大数学科ではないか、レベルが落ちてしまったと思われます。
まとめるとこう。
ここは、学歴も実績も嘘を付けてしまうので参考になりません。
排中律君も数学君と同じ人かと思った
>>664 TRUE を持つ内では皆が共通に論じられるほど広く知られたもののひとつだからでしょ。
反例としてはひとつあれば充分。
ちなみに「TRUE と比較するべきではない」に対する反例ね。
true であれ TRUE であれ、それと == で比較するのが罠になりやすいっつーのは
罠になりやすい部分として有名すぎて逆によく知られている常識だが、
絶対不変の定理みたいに言い始めたやつがいたから変なことになってるんだよ。
現実はそんな綺麗なもんじゃねーよっていうのに Windows はうってつけだろ？
BOOLはWindows APIでしか使わないと思ってるから話が通じないんだな
>>664 >>639 からの流れで、あくまでWin32APIの中でのFALSEの話をしているからだろう
BOOLは非常に広い環境で使われていて
Wimdows APIに限定した話ならここですべきではない
つまり、Windowsで
>>439 のように書いていたのをWindowsのBOOLを知らずに否定しちゃう人、
というネタそのものを体現してくれたわけだな。
BOOLについて議論するならどのBOOLか限定しないと
>>671 何が｢つまり｣だか
Windows APIが色々と特殊なのは知ってるよ
Windows 2.0から組んでるし
特殊事情はあくまで特殊事情
そもそも、特殊じゃない「普通の環境」のBOOLって何ぞ？
https://ideone.com/T9gWWT こうなるので、負の型にキャストするのが良いんですかね？
標準にはboolと_Boolしかないんだからそれ以外はどこぞの馬の骨が好き勝手に決めただけの独自定義
>>675 そうなんだけど
C言語スレでやれ
じじくさい話ばっかりでうんざりするわ
じゃあboolに戻すけど
>>680 私には正常な書き方に思えますよ
その書き方のどこが異常なのでしょうか？
if (b) で済むのを
bool b;
>>685 C++スレでC++以外の言語という「つまんないこと」でイキってんのおまえだろ
おまえみたいの「いちびり」って言うんだけど意味わかる？ｗ
>>682 バグにならなければ問題ないのでは？
＞if (b == true == true)
とは私も書きませんが、だからといって異常だとは思わない
というか、あなたの「異常」の定義が異常なのでは？
>>688 いちびり、とは、あなた、関西人ですなぁ
>>689 正常と異常の境をおまえさんはどこだと思っている？
>>674 Windowsしか知らないの？
世界が狭い
非常に多くの環境でBOOLを使う
>>690 ああ、おまえほんまは関西人ちゃうなｗ
俺もほんまの関西人ちゃうけどなｗ
>>692 大文字のBOOLを使う「非常に多くの環境」とは？
>531や
>>682 が異常とは思えないって
まじかQZ
>>692 その定義を出してみなよ。
標準の仕様じゃないんだからその環境ごとの特殊な定義であることは変わらんだろ。
>>697 その返しは口喧嘩に負けた小学生みたいだから、ちゃんと相手の質問に答えなよ
もう自分で何を言っているのかわからなくなっているんだろうな。
俺の狭い経験だと
windef.hのFALSEが-1とかに変更されたら、既存のソースは崩壊だろうな
typedef unsigned BOOL:1;
>>705 それは BitField みたいだけど、構造体メンバ以外で使えるようになったんだっけ？
もしかしたら、Rubyが、0をtrueと解釈してしまうことから変なことを思ってる
あれ？
>>708 スマン：
誤：修正されない限り TRUE が 0 以外の値にマクロ定義されることは絶対に無い。
正：修正されない限り FALSE が 0 以外の値にマクロ定義されることは絶対に無い。
>>681 if(b)で十分なのにif(b==true)と書くのはif((a==b)==true)と書くのと同じで冗長なんだよ
これがすぐに理解できないなら論理を簡潔にする能力が欠如してるのでプログラミングの才能はないね
>>712 しかも、b は、少なくとも見かけ上は int 型ではなく、BOOL 型だし。
それに他の言語の場合、if の条件式に入れられるのは唯一 bool 型の
場合があり、一番 if の条件式に入れ易い型。
>>713 他の言語の場合、例えば x, y が整数型の場合、
x == y
とした結果の型が bool 型。
そして、if の条件式に入れられるのは bool 型のみだったりする。
だから、もともと b が bool 型なのに、敢えて b == true と判定して
また bool 型に「直して」しまうのはとても奇妙な感じになる。
その文化との兼ね合いから、C/C++ でも、b が BOOL 型の場合は、
if (b) とするのが美しく見える。
MISRA-C でも、if( 変数 )で、変数が実質的にブール型の場合は、これでOK
bool型が存在しない時代に何故bool型になるのか
>>695 異常を「コンパイラがコンパイルできない」と定義していますから
>>712 コンパイルが通るんだったら異常ではないのでは？
>>712 ＞論理を簡潔にする能力が欠如してる
簡潔すぎてわかりにくいのも困りますね、プログラミングはまず他人への分かりやすさを優先するべきでは？
簡潔過ぎて分かりにくいって何？
もしかして
そりゃ
カッコも付けないと見にくいよな
QZは変なこだわりに固執するやつだから、一般的な感覚とか常識とかについて議論しようとしてもそもそも議論が噛み合わないし、スレを無駄に汚すだけ
if (true == true == true == b == true)
ようちえんじがかんじをつかわないでってぐずってるのとおなじだね
異常とは、普通じゃないことだよ
boolやBOOLでない変数abcをif(a==b==c)と書きたい事はある。
if(b==true)
「rust が c++ を超えた！！ 神！！」みたいな記事をよく見ますけど、今後c++がrustから学んでもっと良くなることって期待して良いですよね？
>>731 片山はQZほど馬鹿ではない
まず国籍が違う
なぜ
冗長な書き方をする人の真意なんて測りようもないし理由が一つに決められるわけもないだろう。
>>715 そう書くべきだしそれが普通ってことはわかってんだって。
自分で書く分にはそう書くよ。
でも、他者が書いたコードを読むときや利用するときは
> 変数が実質的にブール型の場合は
っていう前提を確信できない場合がある。
整数型で真偽値の代用にすることがある C/C++ では
型で判断できないことがあるから罠だよねって話をしてるんだよ。
真っ当なデザインではない場合があるから思い込まずにちゃんと確認しようねってこと。
> この例はむしろboolを理解してるやつからしか出てこない発想
operator =(BOOL value){
>>596 あったあった
今はわざわざそれ使う理由忘れた
Cだとそれで必ず0か1になるからTRUEと比較しても大丈夫！っていうクソみたいなバッドノウハウ
operator ==(BOOL value){
>>743 そもそもTRUEと比較する必要はないしWindowsから出てきたイディオムでもないと思うが。
どちらかというとtruthyな値からtrueを得るイディオムとして使われているような。
よく見かけるのはJavaScriptとか。
リターン式から返却値の型を推定させる場合にはautoが必要だ
>>725 あなたのいう「一般的」というものが、実はそれほど一般的ではなかった、という可能性はありませんかね？
というか、まずあなたのいう「一般的」をあなたの言葉で定義するべきでしょう
あなたに定義できますか？
単語の意味は辞書引けよ
true と比較したけりゃすればいいじゃないの。
コード規約「if(bool)はif(bool==true)と書かなければならない」
explicit operator boolだとラムダとかの戻り値強制したいときそうなっちゃわない?
意味的にboolの型であればboolにキャスト
>>258 mmap を確かめています、なんだかすごく時間がかかってしまいました…
ideone はファイルを作らせてくれないみたいですね…
https://ideone.com/zXFtEY fd と fd に紐付いた mmap をつくっておいて、
①fd 側にデータを追加すれば mmap でも見えるのですが、
②mmap 側からデータを追加しても fd は増量しないようですね
今は cygwin で見てますが、ちゃんと linux をいれて確かめるつもりです…
I/Oの遅さの陰に隠れてたけど。
>>743 ああなるほど
if(TRUE == !!b) のことか
if(!!b) は javascript の方だろ
! は見づらいから私は not と書くことにしてる。
一応、alternative tokensに規定はあるが
Cにも_Boolがなきゃヤダジタしてたやつとか
C と C++ で解釈が違うのに結果として動作は同じみたいなのがたまにあってすげーなって思う。
>>770-771 if 文の条件式を見てて思い出した。
C だと条件式の評価結果を 0 と比較するというルール
C++ だとブールに変換するというルール。
まあ整数をブールに変換する規則は結局のところ 0 と等しいかどうかなんで
ちょっと回りくどくなってるだけなんだけど、
そういう違いがあっても互換性が維持されるというのがどこかで検証されてるんだろうと思うと、
手間かかってんなぁという感想が浮かんだ。
他にも列挙定数の型が C と C++ では違うとか……。
私が把握してるのはそんくらいだけど、
探せばもっとあるんじゃないかな。
>>766 >if(TRUE == !!b) のことか
さすがにこんな意味のない書き方が人の目につくほど蔓延りはしないだろう。おそらく
>>743 の妄想。
!!b は、bool型(と、しばしばオーバーロード)を備えた言語で非bool型の値bをbool型に変換するテクニックだろ。
そういうゴミみたいな自己満テクニック（）が積もり積もって誰も触れないスパゲティモンスターになっちまうんだよ
(bool)b
>>776 何で？
ISO/IEC 9899:2011 (E)
7.18 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.
typedef char bool;
Cに移植する可能性があるならC++の機能を使っちゃダメなのは当たり前だよなぁ
>>779 問題点はそこじゃない
移植時にコンパイラが問題点を見つけられないのが問題
コンパイラが問題点を見つけられない例は他に山ほどあるが
Cに移植する可能性が無いならどうでも良い
>>778 マクロとtypedefが被った場合どうなるか解ってる？
>>733 Rustを少し見てみたけど、書き方が全くC/C++とは違っていて、
全く異なる文化圏の言語になれた人が設計した臭がした。
これがC/C++の代替になるとは考えにくい。
はっきり行って、これを使えといわれると辛い。
個人的には Rust は好感触。
C++の配列は長さの情報を持ってないってことになってるけど
rustがかっちり保護してくれるとか低レイヤー向けとか馬鹿ほど信じてるよね。
>>792 実際、Rustは、Cを簡単にするのではなく、Cを難しくしてしまっていて、Cのポインタが理解できない or 難しく感じる人には、Rustの特徴の核心たる所有権、借用などの部分はちんぷんかんぷんだと思う。
>>793 Cの問題点を取り除いたと言うより、ほとんど全てのプログラミング言語が暗黙のうちに用いている代入の概念をなるべく使わないようにして変数束縛などの全く異なる独自概念を用いようとしている。
しかし、これは、手続き型言語と関数言語の違いに匹敵するくらいのプログラミングの概念の変更になってしまうため、手続き型言語の中で改良された次世代言語と言うものではなくなってしまっているとも言える。
RustはC++なら簡単にできることをものすごく回りくどく書かないとコンパイル通らない感じだからとてもつらい
>>790 RustがC++に取って代わることがあるか、というニュアンスの質問でした
今C++でやってる仕事がRustに置き換わる可能性が高いなら今から勉強しとこうか、と
>>797 断言してもいいが、RustはC++に取って代わることは無い。
なぜなら、普通の手続き型言語での枠組みにすら入ってない書き方を強要されるから。
手短に言えば、単にC/C++と書き方が大幅に違っているだけではなく、書き方が他のどんな減の範疇にも属していない。
>>796 C/C++ でのオブジェクトの寿命の管理の難しさってのは
理屈が理解しづらいというよりはわかってても間違うという難しさなんだよね。
そして間違っていてもコンパイラは黙って通すことも多い。
C/C++ を長く使っていればそれを感じることって結構あるでしょ。
そういう部分のプログラムが正しいことはプログラマが保証しなくてはならんわけだ。
でも Rust では言語処理系の側でやってくれる。
C/C++ で面倒な部分を Rust では自動でやってくれる。
まわりくどいのは確かだけど、それで楽できるのも確かなので、
どっちを取るかって話だな。
オブジェクトをどこで後始末するか。
管理の主導権はどのモジュールに持たせるか。
そういうのって C/C++ でも考えてるよね。
C/C++ ではプログラムに書いてないだけで本来はあるはずのものなんだよ。
(C++ だとスマートポインタの導入で少し楽にはなったけど。)
自分が何を考えていたのか、そして何を考えられていなかったのが
明らかになるのはそれはそれで楽しいと思う。
まあ、それは俺が趣味でやってるからかもしれんな。
>>800 そうだよ。
そんでもって大抵の人間は設計がヘタクソだし、
ヘタなところが検出されるなら検出されないより良い。
>>799 変数束縛やら所有権や借用の概念が複雑すぎて、そっちの方が C/C++の
メモリ管理よりミスし易い。
>>802 間違いなくミスし易いけどミスした箇所が検出できないということはあまりない。
設計がヘタクソなヤツが書いたソースのメンテやらされるのは最悪だけど自分で組み上げるならC++以外有り得ない
>>803 仮にあなたはちゃんと理解できても、一般のプログラマは変数束縛やら所有権や借用の概念を理解することが難しすぎるので、C/C++を置き換える言語にはならない。
それらの概念は学習コストが高すぎるどころか、一生理解できないプログラマが多いだろう。
>>805 誤解のないように補足しておくけど、俺は Rust が C++ を置き換えるという主張はしてないからね。
C++ の重大な欠点を (実行コストをあまり払わない形で) 改善しているのは確かってだけ。
そんでもってそれが必要な場面は間違いなくあるってことも。
>>807 new TYPE[] のようにしてヒープから配列として確保されたメモリは確かに
要素数の情報を持っている。
しかし、new TYPEのように配列ではない場合は、高速化のために情報を
持ってない処理系もある。そのために 前者では delete[] を、後者では
deleteを使うことになっており、間違った組み合わせを使った場合には
不具合を生じる。
また、ポインタは、ヒープから確保された配列ばかりをポイントしているとは
限らず、例えばスタック上のローカルオート変数や、グローバル変数をポイント
していることもあり、その場合には、要素数の情報は全く持っていない。
さらに、Cの場合、関数の引数に TYPE buf[] のように配列を書いても、
TYPE *buf に自動修正される仕様となっている。
そのため、配列を受け取るのは、必ずポインタということになる。
しかし、ポインタで受け取るということは、そこには、&a のように、
ローカルオート変数も実引数として指定して呼び出すことも出来る。
その場合には要素数が無いので、あなたの望みをかなえる高速な
一般的方法が存在しない。
望みをかなえるためには、言語の拡張が必要となる。
Rustっていろいろ清々しいよね
>>808 ヒープに確保した配列の要素数はやはりメモリ上にあるんですね
手段がないのは文法として一貫性をもたせられないからということでしょうか
なるほど、回答ありがとうございます
delete [] pと同じように
>>791 ＞C++の配列は長さの情報を持ってないってことになってるけど
＞長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？
new したときは、その領域サイズが実行時にユーザーのみえないところに保存される、というだけなのでは？
C/C++ の配列は長さ情報を（自分でそう書かないかぎり）持たないとおもいますよ
設計がダメな場合コンパイラにいくら指摘されようと根本的には治らんのだが、
>>808 new TYPE[]するとき内部的にサイズ情報を持つ保証ってあったっけ？
例えば自前でoperator new []を実装するとき、予め2^nバイトのブロックを所定の数用意しておいて、要求サイズに応じて必要十分な大きさのブロックを返すなら、割り当て時に要求されたバイト数または要素数の情報を保持しないという実装も可能かと思う。
デストラクタ呼ぶ必要ない型だと、size情報持ってないと言うことなんだろうね
>>820 デストラクタの実装も、返ってきたアドレスの値でどのサイズの領域か(割り当て要求されたサイズではなく、自分で区切ったブロックのサイズ)が分かるようにしておけば大丈夫でないかな？
>>822 すまん、勘違いでした。全部忘れてください
アドレスだけじゃなくて長さも受け渡しするインターフェースにしましょうとしか。
オブジェクトならCORBA、データ構造だけでいいならASN.1とか。
>>822 TYPEがデストラクタを持つclassの場合に、ptr = new TYPE[n] で確保されたメモリ
を delete[] ptr とすると、 正確に n 回デストラクタを呼び出す必要がある。
new が n * sizeof(TYPE) より大きめのブロックを確保した場合でも、
delete[] ptr 時に正確な n の値を割り出す方法が必要となる。
なので、n の値は ptr の値さえあれば知ることが出来ることが必要条件となる。
つまり、少なくともデストラクタを持つ TYPE の場合に TYPE の配列をヒープから
確保した場合には、配列の要素数を必ず配列の先頭のポインタの値から「知る」事が出来る。
>>827 もうちょっと簡単なのないですかね。
型情報要らないんで。
型情報が無けりゃデシリアライズしても使いようがあるまい。
双方向mapって何使うのがいいですか？boostのbimap？
型情報ないならそもそもデシリアライズできないし
型がわかっててもコンテナはそのままではバイナリで送れない
>>834 そのやり方教えて。
あめさんあげるから。
ちゃんとやるならPODに詰め替えてからchar配列へreinterpret_cast
>>826 シリアル化ってのにどういう要件を置くかだな。
同じ環境でデシリアライズ出来ればよいのであれば
>>837 で十分だろうし、
データ形式が決まってて (あるいはデータ形式の側を中心に策定したくて)
それのシリアライズとデシリアライズを (それぞれ別の環境で (ときには言語も違うかも)) やりたいということなら
protobuf などのツールを使うのはよい案だと思う。
boostにあるじゃないですか
>>791 >>807 実装依存だと思うけど hoge[-1] あたりに格納されてた
>>840 VC++の場合、ptr = new TYPE[n] で確保された場合は、確かに
ptr[0] == n
になっていた気がする。
「確かに」というのは言葉のあやで、厳密には覚えてないが、
VC++の new で使われる組み込み関数のライブラリのソースコードを見ると分かる。
>>841 すまん、
ptr[-1] == n
の間違い。
>>842 あ、すまん、正しくは、大体、
((DWORD *)ptr)[-1] == n
だ。
ptr[-1] だと、sizeof(TYPE)分、アドレスが戻ってしまうし、
結果の型も DWORD とかではなく、TYPE 型になってしまう。
>>843 言っておくが、new char[n] とかでは、駄目な可能性は有るよ。
話は、「TYPEがデストラクタを持つとき」のnew TYPE[n]に限定。
一時オブジェクトの寿命について、ご教示ください。
>>846 この場合はその行の終わり。
セミコロンのところだと思っていい。
すごくどうでもいい話なんだけど、
>>846-847 式の一部であるような式が部分式で、
そうでないような式が完結式って言う。
>>847-849 ご回答ありがとうございます。
大変勉強になりました。
newって意外と速いんだな。
>>854 速いよ。
高速なゲームでも普通に使える。
でもスタックは常にキャッシュに乗ってるから、そこらへんでどう変わるのかな。
キャッシュに乗るくらいの量だったらそもそもクリティカルな重さにはならんだろ。
>>857 VC++の場合、コンストラクタが無い場合、new が必要とする時間は 170クロック。
3.0GHz の CPUの場合、1.7 * 10^7 回(1,700万回)くらい new してやっと一秒
位。
だから、問題になるのは、1万回ループではなく、100～1000万回くらいのループ。
もちろん、スタック変数で済むならスタック変数の方がいい。
コレクションがソートの有無でだいぶ変わる。
trie_base_benchmark__random_words_1
挿入速度が変わるのは仕方ないとしても、検索速度が変わるのは、キャッシュじゃないかと思うんだけど。
std::sort: 306ms, (466551count).
>>854 速いといっても
単純な演算と比べれば劇遅
>>867 とにかく、足し算/引き算が1クロック程度、new が170クロック程度だからね。
使い方を間違えなければ劇遅とはいえまい。
auto hentai = SM(std::move(羞恥心));
>>871 回路はほぼ共有してるんじゃないの？
2の補数を使うのもそれが理由なんだろうし。
少なくとも Pentium 時代まではクロックは同じだったはず。
近頃の事情は知らんけど
GCC あたりで強い最適化をかけてみても引き算か足し算を特に避ける様子もないので、
まあだいたい同じなんでしょ。
>>870 C++の場合、+ひとつだけでも裏でどんなコードが動くか油断ならない。
>>871 + と - で速度が違うCPUは見たことがない
- は順番が関係あるので
処理によっては遅い事がある
b = 1 + b
b = 1 - b
整数だけの話じゃなくてってことか。
組み込み型じゃなけりゃそりゃね
>>870 new より + の方が 170 倍速いと言うことだ。
>>874 一度bをnegateしてから足す処理系があるかもな
>>874 確かに引き算には順序があるので、足し算より最適化に不利になることがある。
newが常に数百クロックで済むと思ったら
経験的にはnewが遅いと思ったことは無い。
new からしてmallocを呼んでる実装が多い気がする。
そりゃnew用とmalloc用でヒープ別けたら無駄だし
ヒープからの割り付けをする機会を減らすことで実行速度を上げる工夫はよく聞く話ではあるよな。
newは最悪値が読めないからなぁ
>>887 よっぽどでない限り、AAAゲームでも使われてるよ。
最近では小規模組み込みでもC++を使う事はあります
また馬鹿が無駄に一般化してできるワイ言ってんのか。。相変わらずだな。
>>891 そりゃそういう例もあるわな
だから何？w
スレで、do{}while()はダメっぽいこと書いてあったけど、なんでダメなの？
>>887 でもお前は組み込みにもゲーム開発にも携わってないじゃん
>>899 ごめんねー、俺はプリンタ屋さんなのw
ゲームは知り合いの話ね
>>901 俺は制御周り、上位インターフェースからのデータを描画ルーチンにに渡したり、下位インターフェースにデータ渡したり、パネルとかの制御をやってる
描画部分はまた別の人がやってる
プリンタってプロセッサはどんな感じのを使うんですか？
プリンタのヘッドについてる穴の数は決まっているんだから、あまりヒープが必要無さそうな気もする。
std::vectorの上にヒープを作っても速度的に大丈夫なことは確認した。
昔はSHシリーズとかR2000とか
メモ問題は結局ホワイトボード買ってきた。
ワンノートのアンドロイド版はカメラにホワイトボードのモードがあるんだけど、テカリ消してくれないし、ホワイトバランスも調整してくれない。
PostScript くらいならプリンタの側で処理することもあるし、
モーター動かしたりするのはnew使ったらダメなんだろな。
>>900 ゲームに関しては、かなりちゃんとした現場で昔から malloc は使われていたし、全社的に使っても問題ないとされていた。
>>919 で？
使われてる例も使われない例もあるよ
タイミングにシビアなゲームだと使い辛いと言うだけ
>>918 最大実行時間が読める専用のヒープを持ってたりするよ
選べるってことは、用途によって使い分けが必要って事なんだろな。
ループ内で可変長のvector使っているようなのは、外に出してループ始めにclearする方がいい
>>920 意見されたら喧嘩売りたくなる病気なの？
mallocは使い方が余程ひどく無ければ、性能上問題になることはない
>>927 リアルタイム系の仕事したことないならそう言う考え方でもいいと思うよ
そもそもリアルタイム系の処理で、実処理部分でmallocするってのは普通しないよね
>>929 はループの中で毎回malloc freeしてるからそりゃ性能が気になるよね
>>925 std::vector<TYPE> は、リンクリストではなく、「可変長配列」なので、std::list<TYPE> に比べて、TYPE のコンストラクタがデコボコした頻度で
多めに呼び出されてしまう傾向がある。TYPEのコンストラクタの中で何かをnew していると、new が呼び出される回数をグラフにした場合、
デコボコになるため、速度的に滑らかさがなくなってしまう可能性が考えられる。
それは、newの速度がデコボコなのではなく、std::vector が持つ悪い性質の一つ。
速度的に「滑らか」にしたいならば、std::list の方が適している。
そもそも、C言語がポインタを用意したのは、リンクリストを使いたかったからで、Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
Cの高速性とはリンクリストによるものと言っても過言ではない。
newも、mallocもコンストラクタも、リンクリストと最も相性が良い傾向がある。
cppreferenceなどでも、std::vectorが出てくることが多いが、Cの新かを発揮するにはstd::listの方が良い。
>>932 誤：Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
正：Cはデータ集合用のデータ構造として動的配列ではなくリンクリストを用いるのが伝統。
いやいや、速度がシビアならreserveしとけと
>>929 std::vector<TYPE>を使っていて、TYPEのコンストラクタの中でnewするのはリアルタイム処理には向きません。
その場合、std::list<TYPE>に変えれば劇的に速度が安定するはずです。
>>934 CのAPI呼び出しで集合を渡す場合、通常、集合の要素はコンストラクタを持ちません。
その場合は、std::vectorは適すでしょう。
ところが、要素がコンストラクタを持つ場合は、std::listが適します。
vectorで再配置する際にmoveされない前提なのね
>>936 補足すれば、APIは、リング0のシステムランドで実装されていることが多いため、
リンクリストの様な複雑な構造が用いられることが少ないのです。
しかし、それはAPIに限った話で、Cは誕生したときから、要素数が変化する
集合には、動的配列よりもリンクリストを用いるのが伝統でした。
伝統と言うよりも、リンクリストこそがCの核心・本質といっても過言では有りません。
>>937 C言語とはリンクリストのことです。
動的配列は、Cの文化ではありません。
アドレスで直にアクセスできる言語の強みはリンクリストで活きるからごもっとも
>>930 そう言う事
平均的には間に合っても確保や解放にかかる時間が読めなくなる
100万回に１回でもダメならダメっていう世界だしね
>>931 とかはそう言うことがわかってないので頓珍漢なレスになってるw
>>934 reserveしただけだとOSによっては実メモリ確保しなさそう…
で初回アクセスでおもむろにページが用意されれる
ﾖｶﾝ
それだとmalloc使うこと自体不味いだろ
>>937 moveを使いたい場合、要素の TYPE クラスに move 用の記述が必要となるため、手間がかかります。
is_pod_vで事前条件を確認してるけど、PODはなくなるんだってね。
>>935 まあお前がそう思うならそうなんだろうな
お前ん中ではな…
listで美味しいのはsplice使いたい時くらいだろ
>>947 POD = trivialかつstandard_layout
だから後者を使うようにすればいい
子スレッドを休眠状態で作る方法ない？
>>924 まあそりゃね
使えるようにしてもPCやスマホのように自由には使えないぞ
こまめに確保解放なんてことはしない
基本最初に確保して終わり
解放はしない
だから確保しか出来ないヒープも選べる
>>927 それはPCやスマホなどリッチな環境の場合
>>931 一見軽そうで重い関数があったりするから
同じ人が同じ時に作ってたらそんな処理にはしないだろうけど
白物家電のマイコンやら、pfcのマイコンやらもやったが、そんなのはそもそもmalloc使うような環境じゃなかったしなぁ
今は冷蔵庫や電子レンジもAI積んでネットワークに繋がるIoT時代だけど
まあそれは特に東南アジア向けだったし
いまだにチープな8bit CPUもたくさん使われている
cortex-m0とか載ってたらもう小躍りしちゃうくらいのリッチさだよね
リッチなCPUを使うって事は
でもCPU節約するために人件費かけて結局商品高いじゃん
趣味じゃないんだから
ゲーム業界の人だけど
といってもグローバルヒープを使わないわけじゃない
ここC++スレだよね、つかぬことだけど
>>968 typename Allocatorとかすげぇ初心者っぽい
キリってるのはお前だ
>>968 標準ライブラリでもallocatorが指定できないものもあるんだよ
もはや今のc++で標準ライブラリを全面的に使いつつ、ヒープを個別に差し替えるのはかなり非現実的だ
allocatorを差し替えられてもnewするタイミングや量はリバースエンジニアリングしないとわからない
それが問題になることもある
てか、静的確保したメモリブロック使うアロケータ書いてそれで標準コンテナ使うのが基本じゃね
>>971 > 標準ライブラリでもallocatorが指定できないもの
例えば？
newだってoperator newですぐカスタマイズできるし
placementで環境依存の細かい設定もできる
ライブラリはISO/IEC14882に固執する必要はなく
サードパーティでも内製でもより都合のよいほうを使えばいい
というだけの話
カスタマイズの話なら真っ先にnewの話をすべきなんだが順番おかしくね？
仕様通りに書けばいい感じにうごいてくれて、責任は俺にはないとか
>>890 からの流れでは直後からnewが出てきてたろ
C++が組み込みに向かないという主張の
理由がmallocじゃおかしいだろ
それしか使えんわけでもなし
>>968 に突っ込むと
>>890 に同意したことになるのか
>>973 > > 標準ライブラリでもallocatorが指定できないもの
> 例えば？
でしょ？
お前さんは人並み以上にc++知ってると思うけどこの事実知らない
どこで使われてるか知らなきゃ置き換えができないよね
答えはあえて教えない
標準ライブラリのヘッダーをnewでgrepすればallocatorを通さないものが見つかるさ
自分で確認してこりゃ置き換え無理だわと悟って欲しいw
もし見つからないなら後で書くよ
ちなみにグローバルにnewを置き換えるぐらいならmallocのバイナリを差し替えた方が早いし確実
>>979 横からだが、具体的に誰のどこを指してそう思ったのかよろしく
>>966 もちろん、むやみやたらと使って全く問題ないわけではない。
が、本当に必要な箇所で使う程度なら(多くの場合)余り問題ないという程度。
大体ゲームの場合のnewやmallocは、敵や弾やイフェクト、3Dオブジェクトなど
を1つずつ収めるために使うことが多いが、ゲームの1シーン内に登場する個数が
newやmallocが問題ない程度に元々なっている事がわりと多いと言うだけ。
3Dの雑草の葉っぱ一枚単位で new したりすると問題になってくるかもしれない。
>>981 なんとも感覚的な話だね
だいたい動けばOK！って感じ？
おれは仕事でそういうもの作りはしない
コンシューマかPCかでも違うだろうし
>>978 「後で」かｗ
もう1000間近だし期限切らないでおけば時効だろってか？
>>985 sgjaAMaLが、自分の話に傾聴してきた人の質問に答えなかった
つまり自分の考えを伝える努力を中止したということでしかない
何人も自らの意見を他人に伝えるには
その意見を説明するしかなく
説明をやめることは沈黙に等しい
黙って調べてくれば？
ちゃうねん。
>>984 条件は明示してるんだからおれが書くかはお前に委ねられている
1000が迫っているぞw
この手の人最後まで答えないか
arrayのどこに動的メモリ確保が出てくるんだよ
漏れはnewのときたまの遅さの可能性に警鐘を鳴らしたからｾﾌｾﾌ、
やっぱnew/deleteのレイテンシーを設計に乗せるには非ページプールメモリにアロケートするべきですよねー
なんかスレ止めてたら悪いから書いておくよ
std::functionを使わないと1 bitもプログラムが書けなくなった漏れｶﾞｲﾙ、
ID:jVWLSRwcのレス一覧： ソースコードチェック目的でプログラム読むとき、gotoが出てきたら
そんなに名前が無いと発狂するんならもうgoto使えば？って思うし
関数コールも問題のないコールかどうかチェックしないといけないから
それならもうポインタもグローバル変数もマルチスレッドも大量のチェックが必要だから使ってはいけないってことで
>>199 私と認識が似ていますね
>>137 ＞goto とか break とか continue とか、他の言語（javaとか）でもいろいろ小手先的に弄られているけれども、それに何の意味があるのかいつも不思議におもいますね
>>164 java にはラベル付き break が存在して、ほとんど goto です
https://www.sejuku.net/blog/20100 現行のC/C++にはgoto <label>がある一方、break <n>は無い
>>201 現実ありえないのは重々承知したうえで書くけど
100重ループを脱出するとき数を数えたくないだろうなって思うじゃん
ほかにも3重ループとかで2ndと3rdのループから共通の脱出先ラベルにもできるわけじゃん
文法を拡張する前提ならそこまで想定すべきだと思うね
粗野な即値の数字じゃなくて意味ごとに名前をつけられるようにしてきたのが
プログラミング言語の進化の歴史なのでおれは自然だと思うよ
というかそういう観点からラベル付きbreakというのは他の言語にはあるわけで
で今話してるのはもっと書きやすく読みやすくできないかというトピックでしょ
break Nは使えるだろうけど洗練されてない感じ
break [n] はラベル名を考えなくて良い利点がある
break n とか言ってる奴は何故か
>>150 をスルーしてて笑うわ
他の人は「マジックナンバー」だと思わなかったからでは。
foobarやhogeを超える人気なダミー文字列を考えたほうがよほど建設的だぞ、君たち。
break 5; //C
マジックナンバーがイヤなら
関数で置き換える
>>214 多重ループを単一関数に書くって前提だね
>引数がめんどうならラムダで置き換える ←New!
レス：1-200 201-400 401-600 601-800 801-1000 ALL
このスレへの固定リンク： http://5chb.net/r/tech/1580471646/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 一覧 )C++相談室 part144 スレ立てるまでもない質問はここで 149匹目 Pythonのお勉強 Part67 Visual Studio 2019 Part4 UNIXプログラミング質問すれ Part10 【超高速】C/C++に代わる低級言語を開発したい 8 Kotlin初心者質問スレ ★★Java質問･相談スレッド172★★ 「Cでプログラミングするには人生は短すぎる」か？ C#とC++を無理矢理戦わせたい人専用スレ 構成管理ツール Chef,Ansible,Puppet,Itamae,Packer Java入門・初心者質問スレ Part.９ Pythonのお勉強 Part62 【未来】マイニング工場は全てがスクラップに！ 【初心者歓迎】C/C++室 Ver.100【環境依存OK】 推薦図書/必読書のためのスレッド 83 ■暗号技術【ROUNDπ】■ Androidパターンロック解除 Lisp Scheme Part41 Ruby 初心者スレッド Part 63 Visual Studio .NET 2002 0からの、超初心者C#相談室 【GUI】Fletスレ【Python/Flutter】 C#, C♯, C＃相談室 Part91 Qiita ブロックチェーンプログラマ来てくれないか プログラミングのお題スレ Part16 proce55ing プログラミングアート全般 Ruby 初心者スレッド Part 66
23:54:53 up 10 days, 21:03, 1 user, load average: 145.10, 137.42, 147.35
in 0.95489406585693 sec
@0.03072190284729@0.1 on 092312
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
