C++相談室 part134
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part133
http://mevius.5ch.net/test/read.cgi/tech/1511509970/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>548
なんでそんなめんどくさくてミスしそうな方法をチョイスするんだよ >>548
計算＆書き換え手順をマニュアル化して、何十種類の仕向け別にバージョンアップの度に人海戦術で計算＆書き換え＆コードレビュー＆テストするんですね、わかります min_factorialable() は、階乗を正しく計算できる最大の値を返す
constexprな関数(コンパイル時にint定数に置き換えられることを期待)、
と読み取ったんだけど、なぜにmin_なの? 上限を求めるときに使うのはminだから、かな
知らんけど 最初min_nonfactorialableでnon取った時に直し忘れました 一日の秒数を86400と書いてたらマジックナンバーやめろと言われたんだけど、
プログラムを少しでも書く人間にとってその数字は常識でいいよね？
60*60*24 と書いて「その60とか24は何だ？」と言われないでしょ？
それと同じレベルだと思ってるんだけど。 うるう秒でクラッシュするクソソフトウェアの出来あがり
ニュートン力学と天文学と暦学からやりなおした方がいい >>555
言われないとわからない奴は言ってもわからないだろうから
お前は一生マジックナンバー使いまくりでいいぞ >>558
欲しいね
chronoが中途半端でイラつく >>556
それだと 60*60*24 と書いても同じだよね。
うるう秒とかは関係ない定数管理してる場合の話ですよもちろん。 >>557
86400がプログラマの常識的にマジックナンバーなのかどうか、って話ですよ 所で皆さんmakefileはどう編集してます
あまり触れていないようなので気になります >>562
趣味では汎用のmakefile作ってそれを使い回してる
仕事ではautotools 他人と共有するコードならなるべく要素を分解して分かりやすく書いた方が好ましい
2の倍数も直接記述するのではなくシフト演算使った方が綺麗 くくるんじゃなくて…
クラス宣言
int main()
{....}
あとは c++ スレで 常識なんて集団が変われば変わる
そのコードを見せる事を想定した集団の常識かどうかを考えろ 2進数8進数10進数16進数のみではないということ
60進数や24進数の話でしょ時計を語るときは必須の常識 集団の常識ってことなら、'86400' をマジックナンバーと思ってる人間は少数派っぽいので、
文句はやんわりと無視する方向で行きますわ というかマジックナンバー言われるのって数字の意味とか集団の常識とかじゃなく書式の問題だよね
計算式の中に定数ポン置きしてる書き方してる奴がチームにいたらそりゃマズいよ、変数とか定数に置き換えろって俺も言う 定数を定数に置き換えるってなんだよ
リテラルは定数なり変数なりにって感じで読み替えといて >>572
しかしこうはしないだろ？
const int int8_bits = 8;
uint16_t word = (hi << int8_bits) | lo;
こうもしない
const int sec_per_min = 60;
int sec = m * sec_per_min + s;
数値リテラルで書くのが許容される数値というものがある
sec = day * 86400 はどうかというのが>>561
個人的には知らない人でも暗算もせずに初見で合ってるかどうかわかるか、
を基本にすべきだと思う (小さな2の冪乗は除く。2の冪乗知らん奴はシネ) uint16_t word = (hi << CHAR_BIT) | lo;
これCHAR_BIT != 8な環境を意識するんなら、16って書いてあるのも問題だね
const int micro_per_sec = 1000000;
int us = sec * micro_per_sec;
こう書けって言われたら俺はお断りする >>575
bit_per_char や shortでもintでもなく int8、uint16_t と明記したのは所与の仕様のつもり。
最近のapiはよくナノ秒返してくるから1000000000 倍
1000.0*1000*1000と分かち書きしたくなる 時刻を自動的に合わせますというコマンドボタンを作って
押すだけで済むのに >>577
それを言うなら1'000'000'000だろjk 86400って書くと、ideで定義の参照も使えんし
86400で検索したときに
１日の秒数なのか、適当に決めたタイムアウトとかの秒数なのか、ただのIDなのか、連番で出てきただけの数値なのかとか、無意味な数列なのかまざってわからんくなるやろ #define SEC_PER_DAY (60*60*24)
なんてやる人いないのかな >>581
#define は基本使わない、int const ABC = 12345; なら時々使う さっさとこう書けるようにしてくれ
今の<chrono>クソすぎんよ
int sec_par_day = static_cast<int>(std::chrono::second{std::chrono::day{{1}}); 86400とか1440でわかるけど
24*60*60とか24*60って書けばいいだけだと思う 21世紀も5分の1が過ぎようかっていうこの時代に
何が悲しゅうてたかが時刻を扱うだけでtime_pointの他にtmやらtime_tやらをガチャガチャさせられにゃならんのだよまったく 86400って何のために使うんだろう
うるう日とかうるう秒とか考慮しなきゃ気持ち悪くね？ 考慮する必要性があるものかどうかが分からないからなんとも
例えば時系列データをその時点から1日分の数を使うというものなら閏秒を考える必要がないし int t = 86400; // 24*60*60
これで解決 閏秒の有無等で可変のものなら可変のものなりの書き方するでしょ
計算して変数に入れるとか
問題は不変の数値定数をどう正規化して書くか、正規化する必要はあるか。
24*60*60 派の人と 60*60*24 派の人が両方プロジェクト内にいたらなんか嫌だな プロジェクトで誰かが決めたらそれに従うよ
派閥作るほどの問題じゃないでしょ 絡むわけじゃないけど
決めたら従うのは当たり前で、それが「決める」ってことだろ。
派閥の話じゃなく混ざってたら気持ち悪いってことが言いたかったんだよ。 あっちこっちに書き散らすものじゃないから混ざってるとかあり得ない
1カ所になるまでリファクタリングしろ 気持ち悪いと思うかどうかは感性の問題だからなあ
例えばある日地球の回転速度が変わって１分が６１秒になった
プログラムを修正しろと言われて、
場所によって書き方が違っていると大変だね
と言う話なら理解出来るけど constexpr int min = 60;
constexpr int hour = min * 60;
constexpr int day = hour * 24; hoursは<chrono>にあるだろ
それとoperator""h operator""dayがねえんだよな<chrono>って chronoのhoursはstd::chrono::duration<int, std::ratio<3600>>のエイリアスなので
daysはこうすればよい
using days = std::chrono::duration<int, std::ratio<86400>> >>602
> daysはこうすればよい
> using days = std::chrono::duration<int, std::ratio<86400>>
>>555へ戻る w 閏秒を考慮するのと1日を86400秒とするのは全く関係ないのに閏秒がどうとか言い出した奴が悪いのでは
丁寧に書くなら計算の根拠として60*60*24を見えるところに書いておけばいい 知ってる知識を披露したかっただけだろうから罪は軽い ほぼ関係ないな、難癖もいいとこ
実用上は全く関係ない うるう秒がどうのこうのと言う、問題じゃなく86400秒をそこでしか使わないって根拠が無いんだよね
後でまたその数値が出てくるとしてその度に86400と書くのか、もしその数値を修正する事になったら全部書き直すのか、2回3回使うようになって始めて変数なり定数なりに入れるのか
それなら最初から式中に出てくる数値は変数に格納してから使えって統一した方が話が早い 今時マジックナンバーとか昭和からタイムスリップしてきたのかよ プログラムにおけるマジックナンバー（英: magic number、魔法の数字）とは、何らかの識別子もしくは定数として用いられる、プログラムのソースコード中に書かれた具体的な数値である。
そのプログラムを書いた時点では製作者は数値の意図を把握しているが、他のプログラマーまたは製作者本人がマジックナンバーの意図を忘れたときに閲覧すると「この数字の意味はわからないが、とにかくプログラムは正しく動く。
まるで魔法の数字だ」という皮肉を含む。
by Wikipedia 「1日の秒数」って定数を86400って書いて怒られたって話じゃないんだ？ >>609
じゃあオマエ、構造化もしてないのか？
昭和時代ほど耳にしなくなっても廃れたのではない話は結構あるぞ >>611
怒られたという程じゃなくて、
一日の秒数 = 86400;
と書いたら「マジックナンバーやめろ」と言われたってことさ >>615
そうじゃなくて
60*60*24 て書いて欲しいんだってさー
謎 >>616
まぁ可読性高くて損する事は無いし、なるべく要素は分解して書いた方がいいんじゃないの
何かどうしても86400じゃなきゃ困る理由とかあるなら話は別だろうけど、無いだろ？ ITのエンジニアって
こういうくだらないことで
給料貰ってるんだろうなあ こういうクソみたいなことでもウンチク垂れてテコ入れしろと提案することにより仕事してます感かもし出す為だろうな >>619
結果のわからない投機的な模索をしているときは
逆にマジックナンバー地獄なコードだよ
他人に渡すコードを清書するときの書き方・考え方とは真逆 俺がわかるからみんなわかるだろうというコードはすげー困るな
例えその場の全員がわかったとしても今後わからない奴が出てきた時の事を考えて
できうるかぎりわかりやすいコードを書くべきだな そのためのコストにもよる
空想論じみた「わかりやすさ」にまで付き合ってらんないこともある
特に最低限のプロとしてのスキルを欠く者を想定することはしない
ちょっと飛躍するがプログラム言語だってそうなっている
マシンの性能を使いやすさに振るということを無限にはやらない
どのくらいのアホまで付き合ってやるのか性能とのトレードオフで
色んなバランスで棲み分けになっている まぁ別に自分だけが使う分にはいくら分かりづらく書いてくれても構わんけどな 86400を60*60*24と書くことにはなんのコストも支払ってないから書けばいいな
いちいち話を飛躍させる奴はなんなんだ 人によっては>>599みたいにしろって言うだろうし
結局は人それぞれってことじゃないの
16を2*2*2*2っていちいち書く人はいないでしょ
まぁ1<<4って書けと言われるかもしれんが 学校の試験問題で一日の秒数としてソースに86400を書いたら
マジックナンバーだからと減点された、納得いかない。
みたいな発端じゃないのかなぁ。 それをfindとsedでやる勇気あるか？
たとえば俺なんかは１箇所ずつよく見て有機的に判断しないと怖いし
それの残業代は貰えるのか心配だ 当然その程度のリファクタリングはするべきだしそもそもマジックナンバーをどうにかするべきだし
お前の残業代とかいう飛躍した話はどうでもいい 飛躍じゃねえ実話だよ
ずいぶん昔、社内BBSでそれ系のことを言い出したやつが
偉い人から突っ込まれてた プロとか言い出してる人がいるけど、それこそ飛躍では？ プログラムの話題から外れてきていると思いませんか？ >>614
だからわかりきってるかどうかは人によって違うって話
プログラムの前に日本語の勉強しろよ w まぁコスト次第で可読性を犠牲にするケースもあるだろうけど
この場合はメモリ食う訳でも処理遅くなる訳でもソースの構造が変わる訳でもない
86400でも十分分かりやすいかも知れんが60*60*24なら更に分かりやすくなる
どっちが良いかなんて議論の余地無いよね >>631
別にプロでなくてもいいんだけどさ
おまえさんなりに、同じプロジェクトにいて欲しくない足手まといが
どのくらいから下というのはあるだろ >>626
> 16を2*2*2*2っていちいち書く人はいないでしょ
> まぁ1<<4って書けと言われるかもしれんが
状況次第だろ
場合分けの条件が４個あって各々２状態をとるとかなら2*2*2*2って書くかもしれない
下から４ビット目のマスクが欲しいなら1<<4って書くこともある シフト使うな、ビットフィールドで書け
なんて言われると、俺は相手にもよるが逆らいそう >>637
ビットフィールドは割り付け順序が処理系定義だったりしたからあまり使ったことがない たまには2進リテラルちゃんのことも思い出してあげてください 議論の本筋(1日の秒数として即値で86400と書くことの是非)とはさらに離れるけど、
ビットシフトを使う定数は常にカッコで囲んでくれ。
res = a + 1<<4 + b;
res = a +(1<<4)+ b; >>641
3つ以上の項があると静的解析ツールで怒られるから
res = (a +(1<<4))+ b;
と書く >>641
下のつもりで上書いたらただのバグじゃん 算術と混用するときは結合順位に注意せよ、というだけのことを
いちいち必ずだ！ルールだ！と金切り声で吠えついてくるやつはウザい >>642
可読性悪くしてかえって品質低下招きそうな指摘だな vectorをつなげる際、copyが良いとか、insertを使えとか色々書いてあるのですが、どれが良いのでしょうか？ あらかじめ領域を広げておく必要があるけどinsertの方がチェックが入らない分速い insertの直前にreserveって意味あるのか？ reserveは終端のポインタが更新されないからresizeじゃないとだめ ■ このスレッドは過去ログ倉庫に格納されています
