C++相談室 part163

2022/12/30(金) 23:16:31.37

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/02/16(木) 19:56:28.04

>>490
deferいいね
いわゆるfinallyみたいなもんかな
今でもやろうと思えば__cyg_profile_func_exitやdetourがあるけど環境依存で重くてめんどいね

2023/02/16(木) 20:41:32.26

数年前にawsの仕事したとき
g++のバージョンが古くて
unique_ptrを使ってたコードを泣きながら
生ポにしたことがある

2023/02/16(木) 20:57:10.46

バカかw
自分でクラスを作ればいいだろ
スマポなんてめちゃ簡単な仕組みだぞ

2023/02/16(木) 20:58:28.56

>>493
右辺値参照の仕組みがないと上手いこと表現できないよ。

2023/02/16(木) 21:02:17.61

そこはリファレンスカウンタを使ったトラディショナルな方法でやるのよ
速度は少し遅くなるけど

2023/02/16(木) 21:12:06.74

古いコンパイラで無理やり動かすなら#define unique_ptr auto_ptrという手も…

2023/02/16(木) 21:12:18.96

すでに std::unique_ptr で正しく動いているコードであるという前提があるなら
たしかにそれでも致命的な矛盾は起きなさそうに思えるな。

2023/02/16(木) 21:50:41.49

g++なんだから新しいバージョンのをビルドすれば良いじゃん?

2023/02/16(木) 23:12:23.80

>>461
消す為の変更で再評価
アホらし

何も見ずに？
そんなこと誰か書いたか？

2023/02/16(木) 23:27:28.78

warningだらけだとバグに繋がる重要なwarningを見逃す可能性があるから、可能な限り消した方が良いと思う
どうでもいいやつはコンパイルオプションで消しても良いし

2023/02/16(木) 23:46:07.27

>>499
元々は警告無しで移植で警告になったんだろ？
何千個あろうが見直すのは当たり前だし、いずれにせよ評価は必要
まさか警告出まくってるのに評価無しでOkとかしてるんか？

2023/02/16(木) 23:59:12.84

「C/C++ warning一万個全部消してみた」
てタイトルで動画アップして欲しい

2023/02/17(金) 00:31:24.08

ピコーン！全ての警告を無効にすれば良いニダ！

2023/02/17(金) 06:19:19.83

>>502
警告が１万種類あるなら大変だけどたいてい種類は限られるだろ
ほんとにコード書いてるのか？

2023/02/17(金) 06:22:34.59

「符号付きと符号なしの比較がされました」
分かっとるわ！

2023/02/17(金) 06:27:23.48

それはオーバーフロー起きないかちゃんと確認しないとダメだろ
C++使っててそこルーズなの信じられんわ

2023/02/17(金) 06:31:19.84

文字列の長さの比較がintの上限に達することはないし負になることもないのよ

2023/02/17(金) 06:47:57.06

だったら本当にそうであることを確認しないといけないし、そんなものにsignedの変数使ってるのがおかしいかもしれない
その値は本当に文字列の長さか？途中でエラーが起きたら-1とかが入ってる可能性はないのか？
そういう危険なバグの兆候を知らせるためにまともなコンパイラは警告するんだよ

2023/02/17(金) 06:49:33.54

一応言っとくと自分が言ってるのはプロダクトコードの話で
本人がその場でしか使わない書き捨てのオモチャなら勝手にすればいいと思う

2023/02/17(金) 06:55:47.58

>>505
わかってたら直せよw
そもそもそんな警告が大量に出るほうがおかしいし

2023/02/17(金) 07:09:21.56

delphiから移植された関数の殆どが文字数をintで返す仕様でな
それ一々符号なしに変換するのが面倒でな

2023/02/17(金) 07:13:48.65

使ってないパラメーターがあります
使ってない関数があります

警告が出ないようにわざわざ使う
ただのアホ

2023/02/17(金) 07:15:49.11

ほとんどなのね
「全部が必ず」正の値を返すことが保証されてるんじゃなければますますチェックコードが必要だな
実にバグが出やすそうな所に見えるね

2023/02/17(金) 07:17:50.92

>>512
使う必要がないなら消せよ
なんかの理由でどうしても残すなら[[maybe_unused]]付けろよ
アホはお前

2023/02/17(金) 07:27:16.44

新入り「使ってないから消しました
古株「ちょ・・・おま(汗

2023/02/17(金) 07:30:03.02

>>514
ド素人ですか？

2023/02/17(金) 07:32:46.94

え？コンパイラが警告出した変数や関数だろ？使ってないローカル変数や非公開関数なんだろ？
それを消して挙動が変わるってことは何か恐ろしいメモリ破壊系バグが顕在化したってことだ
新人君お手柄やね

2023/02/17(金) 07:50:26.17

ド素人丸出しwww
警告警察の中身はこんなレベルのアホ

2023/02/17(金) 07:53:51.79

そうか
お前みたいな自称ド玄人が人命やインフラに関わるコードを書いてないことを願うわ

2023/02/17(金) 08:01:10.11

ソフトの品質をコンパイラの警告に頼る方がヤバいと思うよ

2023/02/17(金) 08:14:39.58

カーエレって割とそんな感じよ

2023/02/17(金) 08:26:51.29

コンパイラの警告さえ対処しない奴が品質を語るな

2023/02/17(金) 08:36:18.04

コンパイラの警告の数でソフトの品質を語るアホ

2023/02/17(金) 09:18:35.55

シートベルトしてるだけで安全運転だと思ってる奴はヤバい←正しい
だからシートベルトしなくていい←絶対運転しちゃいけないアホ

2023/02/17(金) 09:52:37.27

>>477

一応の完成版を以下に貼りました。
https://wandbox.org/permlink/lXq19mN1URMQhyh5

生ポをスマポへ変えるのは一旦棚上げしています。
ありがとうございました。

2023/02/17(金) 10:11:56.50

何も変わってなくね？と思ったら>>426とリンク同じだった

wandboxは共有済みのソースを後から編集できないので
更新するにはもう一回共有して新しくpermalinkを生成する必要がありますよん

2023/02/17(金) 12:12:37.95

対処はしてるぞ
内容を読んだうえでの決定なんだから

2023/02/17(金) 12:16:56.46

>>524
シートベルトは法律で決まってる

警告を消すのがルールで決まってる職場なら
警告かルールいずれかを消せ
そうじゃないならどうでもいい

ソフトの品質を担保するなら
警告の中身を見ずに単に隠すのが一番悪い

また
全ての警告を無条件で検証しろというなら
全ての演算も無条件で検証しろ
C++の演算はオーバーフローする可能性があるんだから

無意味な警告は出す方が悪い
コンパイラの設定で無効にしろ
コードを変えて隠す物じゃない

2023/02/17(金) 12:17:47.03

コードの検証ならちゃんとした検証ツールを使え

2023/02/17(金) 14:00:35.55

>>526

申し訳ないです。正しくは以下のURLです。
https://wandbox.org/permlink/uHOVPDqphdPBAPQe

ご指摘、ありがとうございました。

2023/02/17(金) 18:18:23.14

>>530
流し読んだ感じだけど

1.
void roots( unsigned );
> // 自らがどのようにして生まれたかを調べるメソッド
> // 第 serialNo 番のインスタンスを探索する．

自分の親を探索するのか指定serialNoが子供にいるのかどっちだよ
あと検索なのでメンバを上書きしないはず。関数自体をconstにするべき

2.
engineは親のengineを参照すればいいのでわざわざ引数で受け取る必要はない
コンストラクタは親を受け取るのとengineを受け取る2種類用意したほうがいいんじゃない？

3.
numberフィールドはいらん(名前もchildCountに変えるべきだが)
childObj.size()を見ればいい
getter関数作ったほうがいい

4.
isLeafフィールドもchildObj().size()==0見れば判断できる

2023/02/17(金) 18:50:34.09

もう解決してんだからアドバイス気取りでがんばって蛇足を加えんでもいいよ

2023/02/17(金) 21:00:18.60

>>531

そこで図々しいお願いですが、そのように改造してくださると私にとって大いに勉強になります。
一肌脱いではいただけませんでしょうか？

生ポをスマポに直すのすら頭を抱えているヘタレなので、ここに棲まう先輩方のご鞭撻を是非に賜りたいです。

2023/02/17(金) 21:26:59.48

>>528
分かってんじゃん
C++の整数演算は無条件で全て検証が必要だよ
おっしゃる通りオーバーフローするかもしれないし、それが大きなセキュリティ問題につながった例もたくさんあるからね
特にナイーブにsigned/unsigned間比較や縮小変換をしてる所は危険だし、それを知らせてくれるコンパイラ警告は実に有用なものだ

もちろんプロダクトコードの話ね

2023/02/17(金) 22:01:30.31

縮小変換が警告されるかどうかと問題が起きないようにロジック組んであるかどうかは別問題だね

2023/02/17(金) 22:05:57.15

それはそう
コンパイラが知らせてくれるのは一番基本的な所だけだからな
逆に言えばそれすら対処してないようじゃ0点

2023/02/17(金) 22:14:14.63

>>533
丸投げすんな自分でやれ

2023/02/17(金) 22:17:56.86

>>536
何がそれはそうなの？

2023/02/17(金) 22:41:19.78

>>534
警告に惑わされずに全部見ろ

>>536
警告を隠すのと問題が無いことを確認するのをごちゃ混ぜにするアホ

2023/02/17(金) 22:44:01.98

>>512
> 警告が出ないようにわざわざ使う
えっ、そんなレベルなのw
そりゃそんな職場なら
> 警告を消す為にバグを仕込むヤツを何度も見てきた
とかもあるんだろうな...
なんか可哀想になってきたわ

2023/02/17(金) 22:46:57.97

>>467

＞ std::unordered_mapの同名関数はrehashingが起きてイテレータが無効になることがある

その場合でもvalue側のメモリは固定でしょうか？

**541** (ﾜｯﾁｮｲ 46ad-D0vN) · 2023/02/17(金) 22:48:24.15

失礼、↑は>>487の間違い

2023/02/17(金) 22:54:29.06

>>540
警告を消すためにわざわざ使うマクロを知らんのか

2023/02/17(金) 22:56:59.77

◯◯のコンパイラや◯◯のチェックツールで警告が出るから直しとけ
って言われたら何の疑問も持たずに直すの？
◯◯はバグの元だから直せって言われたら
何の疑問も持たずに直すの？
思考停止？

2023/02/17(金) 23:43:41.95

>>543
なんのマクロのことを言ってるのか知らんけどそんなの処理系によって違うだろ
最近の流れは>>514のような属性指定

2023/02/17(金) 23:45:03.57

ぶっちゃけテストしてるなら警告放置でもいいけど、
テストするような人は警告にも対処するからな

2023/02/17(金) 23:48:24.98

>>544
指摘されてるんだからなぜその指摘が出てるのか調べて直すなり警告抑止するなりするだろ
なぜなんの疑問も持たずにとか出てくるのか不思議だけど君の職場ではそうなんだろうねw

2023/02/17(金) 23:53:50.54

見も知らん第三者にwell-formedなコードにケチつけられたら
言いなりにしろと押しつけてくるやつ、自分の姿をビデオでも鏡でもいいから見てみたら？

2023/02/18(土) 00:40:30.23

多分「直す」を「何も考えずに警告抑止なりキャストなりで握り潰す」の意味で言ってるから噛み合ってないんだと思う
警告無視マンセー君以外はもちろんバグがないか確認した上で範囲チェックやクランプや（問題ないことを確認して）キャストなどを加えてプログラムを改良する意味で言ってる

2023/02/18(土) 02:15:58.71

>>541
value のアドレスは変更になるが、valueが構造多やクラスで、中にポインタが
有るような場合は、そのポインタの値は変更されない。

2023/02/18(土) 02:21:04.46

>>550
間違いました。unorderd_map の rehashingについて、こう有ります:
https://cplusplus.com/reference/unordered_map/unordered_map/rehash/
>Iterator validity
>If a rehash happens, all iterators are invalidated, but references and pointers to individual elements remain valid.
>If no actual rehash happens, no changes.

なので、iteratorは無効化されるが、個々の要素への参照やポインタは有効なまま残ります。

2023/02/18(土) 03:03:49.37

>>551
ソース読まないとはっきりしないけど、恐らく、イテレーターが指している
オブジェクトのポインタを取得すると以前と同じ値になっている。
しかし、イテレーターには ++ で直後の要素に移動する機能が有る。
恐らくその機能が正しく働かない場合があるということらしい。
ゴミレスでごめん。

2023/02/18(土) 06:19:29.80

>>549
いろんな方法で検証は当然行う
コードを変えてわざわざ警告を隠す作業はしない

2023/02/18(土) 06:45:26.64

キャストして警告を隠す事がプログラムの改良だと思ってるアホとは会話しても無駄だな

2023/02/18(土) 06:50:44.99

>>548
それだと多分うっとりしておしまいになるやつ

2023/02/18(土) 07:23:37.23

ナルシストか
そうだろうな

2023/02/18(土) 07:58:59.69

> キャストして警告を隠す事がプログラムの改良だと思ってるアホ
>>554 のことだなw

2023/02/18(土) 09:42:41.72

まだ直すと隠すの区別ついてないアホのためによくある例書いとくね

std::vector<Foo> foos = /* なんか入ってる */
for(int i = 0; i < GetLegacyLength(); ++i){
　Hoge* item = GetLegacyItem(i);
　if (i < foos.size())　// WARNING: signedとunsigned比較してんぞ
　{ hoge(foos[i], item); }
　else
　{ fuga(item); }
}
アホの隠し方(1)：脳死でif文のiかfoos.size()をキャストして隠蔽
アホの隠し方(2)：脳死でiの型をsize_tに変更、そしてi < GetLegacyLength()でまた同じ警告が出て激怒「コンパイラの警告なんて無意味だ！」

正しい直し方：
なぜ長さを返すのに戻り値型がintなのか、GetLegacyLength()のマニュアルを見て仕様を確認する。
するとある条件でエラー値として-1を返すことがあると判明したので、
forループの前にGetLegacyLength()を取得するようにして、負の場合のエラー処理を追加した。

/*略*/
int len = GetLegacyLength();
if (len < 0) { /* エラー処理 */ }
else {
　for(size_t i = 0; i < static_cast<size_t>(len); ++i) {　//lenは0以上と確認済みなので安全にキャストできる
/*略*/

2023/02/18(土) 09:55:17.94

>>558
そもそもforの条件判定の部分で関数を呼ぶのは間違いだ

2023/02/18(土) 10:01:12.90

そこは間違いコード例だから意図的にそうしたんだけど
元がfor(int i = 0, len = GetLegacyLength(); i < len; ++i)だとしても話の本旨には関係ないよね？
お前が警告無視する時みたいに脳死で食いつくからそうなる

2023/02/18(土) 10:30:22.39

警告を無視するのと握りつぶすのを混同しとるな

2023/02/18(土) 11:02:45.42

>>559
それこそ脳死だろw
ループ毎に異なる値を返すかも知れないぞ
（もちろんそんな設計する奴は漏れ無くアホだが）
ちゃんと仕様なりソースを確認しろ

**541** (ﾜｯﾁｮｲ 1bad-BTrK) · 2023/02/18(土) 12:30:58.62

>>551,552
いえいえ、わざわざ調べてもらってありがとうございます！
vectorのメモリ再配置によるアボート障害が発生したので、ハッシュのときも
同様のことがないか気になっていました。
とりあえずハッシュの場合はアボートすることはなさそうですね。

2023/02/18(土) 12:34:06.96

>>562
そういうおまえさん自身は
GetLegacyLengthとやらの仕様なりソースを確認しているのか？

**デフォルトの名無しさん** (ｽﾌｯ Sd43-1XUy) · 2023/02/18(土) 12:47:29.66

>>558
BOOL GetMessage のことですね判ります

2023/02/18(土) 12:49:33.03

>>564
自分が改修する立場ならな
当たり前だろ
もうそのレスがアホすぎる

2023/02/18(土) 13:05:02.97

>>566
確認してないんだな？
じゃあ一般論としてあんな変なコードをいつも書いているのか？
話の本旨に関係ないのにわざわざあんな書き方するのは日常の勢いか？

2023/02/18(土) 13:09:54.02

なんかおまえさんの話し方なのか口癖なのかわからんが鼻につくんだよ
well-formedなコードに対する警告をどうするかなんて
おまえさんが感情的に喚いたからって誰も考えは変えないぞ
技術的な議論で誰も分かったと言って来ない現実を
おまえさんはDQN口調でどうかしようとしているようだが恥を知れ

2023/02/18(土) 13:12:16.36

諭されて反論できなくなったから重箱の隅突き始めたよ
ダッサ

2023/02/18(土) 13:17:40.85

あのforに違和感を覚えないセンスのやつに
上から目線でご高説いただいても
自分はああはなりたくないと思うだけだからな

2023/02/18(土) 13:22:48.24

そうだな
悪い例として出されたコード例に向かって粗探ししてハイセンス気取るような恥ずかしいアホにはなりたくないものだ

2023/02/18(土) 13:24:53.20

ああいうダメコードを見つけ出すヒントとしてコンパイラ警告は使えるんだよっていう例を出したつもりだったんだけど難しかった？

2023/02/18(土) 13:28:32.75

たまーに実在するからな、ああいうfor書くやつ
そういう手合いの言い訳はどいつが言っても同じ雑音でしかない

2023/02/18(土) 13:38:53.64

>>567
> 確認してないんだな？
> じゃあ一般論としてあんな変なコードをいつも書いているのか？
たった２行でよくこんなアホさが滲み出る文章書けるもんだな...
１行目もアホだと思うが２行目は脈絡もないのに「じゃあ」とかアホすぎる
こういう奴があの手のクソコードを書くんだろうなw

2023/02/18(土) 13:40:46.05

警告警察アンチ君がfor文警察になってしまった

2023/02/18(土) 13:44:53.99

>>574
頭冷やせよ
特定の関数の仕様が理由でなくて
あんなコード書いたのかと言っている

おまえさんこそあの手のクソコードとやらはどれのことで
それをなぜ俺が書いていることになったのか説明できるか？

2023/02/18(土) 13:45:46.69

＞おまえさんの
ごめん無理

2023/02/18(土) 13:58:29.96

低能警察に糞コードで反駁しようとしたら
収集がつかなくなったでござるの巻

警告を回避するためのコード変更がそんなに嫌ならコンパイラのオプションで警告を出さなくしたら良い……

2023/02/18(土) 14:07:37.26

警告どころかコンパイラのバグを回避することだってある
むろん思い切り処理系に依存する内容となるが嫌とか好きとか言ってらんない
必要が出ればやるだけで感情の入る余地はない

どっかの思い上がった坊やの俺様節が五月蠅いだけ
黙ってくれれば俺にそれ以上の望みはない

2023/02/18(土) 14:12:09.71

警告をOFFにしたら警告を回避しようとしてバグを仕込んでしまう事故は確実に防げる
ていうか本質論としてはそもそも警告に頼らねばプログラミングもできない程度の低能はそもそもプログラミングをすべきではないという話、
これは反駁のしようが無い

2023/02/18(土) 14:13:36.72

>>576
> あんなコード書いたのかと言っている
そもそもあのコード書いたの俺じゃないことぐらい
>>562 > （もちろんそんな設計する奴は漏れ無くアホだが）
って書いてる見たらわかるだろ...

> それをなぜ俺が書いていることになったのか説明できるか？
誰もお前が書いたなんて書いてないけど頭大丈夫か？
脳死で
> for(int i = 0, len = GetLegacyLength(); i < len; ++i)
みたいな修正したらバグるかもよって話だぞ

2023/02/18(土) 14:15:48.28

はいはい「俺じゃない」のね
IDコロコロする人とは話にならないな

2023/02/18(土) 14:32:47.85

なんかすまんな
何気なく書いたダメコードのそれっぽいfor文がこんなにキチガイの琴線を刺激するとは思わなかった

2023/02/18(土) 14:35:25.61

559の指摘にあの返事だからな
うわー香ばしいと思ったのよ

2023/02/18(土) 14:36:45.33

黙れキチガイ

2023/02/18(土) 14:47:19.84

↑うんこ

2023/02/18(土) 14:52:57.45

>>583
すまんと思うならもうROMっててくれ
これに返信も不要だからな

2023/02/18(土) 15:00:31.81

forやwhileの条件でstring::sizeを呼んでるけどダメ？

2023/02/18(土) 15:01:44.62

>>588
意図したものならまぁいいけど、後々のことも考えると普通は禁止

2023/02/18(土) 15:12:52.01

ループ内で変更しないstd::stringのstd::string::size()なら
コンパイラが頑張ってｷﾞﾘ括り出し最適化をしてくれるかもしれんがコンパイラに優しくない……

ていうか以降値が変化しないことがわかっているメンバ変数やグローバル変数は
intやsize_tみたいな単純型ならさっさとローカル変数にコピーした方がメモリからのロード命令削減のために良い
実体（メンバ変数やグローバル変数）と同じ値を保持するローカル変数（エイリアス）があったら混乱するというのは
そんな関数が（担当者の脳のキャパに比べて）デカすぐる……