Qiita 4 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2024/01/17(水) 19:20:36.09

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/

**デフォルトの名無しさん** · 2024/03/01(金) 15:31:32.19

>>218
> そりゃEの判定が不要になるコードを書いてるからだよね

Eの判定が不要なアホな仕様のせいだぞ

> A: 4の倍数の年は、うるう年
：
> D: ただし30の倍数の年は、うるう年
> E: ただし、30と4の倍数の年はうるう年ではない

**デフォルトの名無しさん** · 2024/03/01(金) 17:51:14.14

>>281
>Eの判定が不要なアホな仕様のせいだぞ
Eの判定が不要だと判断したのはEよりDのルールが優先されるべき考えだからだよね？
であればどういう理由もしくはどういう解釈によってEよりDが優先されると考えたのかを説明してよ

**デフォルトの名無しさん** · 2024/03/01(金) 20:46:32.11

> Eの判定が不要だと判断したのはEよりDのルールが優先されるべき考えだからだよね？

違うぞ。
DよりEのほうが条件として先に書かれているので判定が先に行われるってだけ。
Dの後の

> E: ただし、30と4の倍数の年はうるう年ではない

の条件判定はAとDで既に行われている内容なので削除可能。
結果、

> D: ただし30の倍数の年は、うるう年
> E: ただし、30と4の倍数の年はうるう年ではない

↑の条件判定と結果は

ただし30の倍数の年は、うるう年ではない

にまとめられる。

**デフォルトの名無しさん** · 2024/03/01(金) 21:21:21.20

>> A: 4の倍数の年は、うるう年
>> D: ただし30の倍数の年は、うるう年

こんな書き方は普通しない
AもDも同じ「うるう年(である)」とあるのに、逆接の接続詞である「ただし」で結んでるのは日本語としておかしい

> D’: 30の倍数の年も、うるう年
とするか、AとDの間に
> X: 4の倍数でない年は、うるう年ではない
を入れるべきだろう

**デフォルトの名無しさん** · 2024/03/01(金) 22:07:34.93

>>283
「ただし」という日本語知らない人かな？

**デフォルトの名無しさん** · 2024/03/01(金) 22:20:09.43

>の条件判定はAとDで既に行われている内容なので削除可能。

たしかに「30と4の倍数」という日本語の書き方がandなのかorなのか判別しにくいが
わざわざ意味のない方の解釈をして「それは意味がない」という指摘するのはアホっぽい

**デフォルトの名無しさん** · 2024/03/01(金) 22:37:47.13

　神奈川、新潟、岡山、愛媛の4県で先月29日、運転免許証を発行する機械にシステム障害が起き、一時、免許証を発行できない事態となりました。

　警察庁によりますと、免許証を作る機械に「うるう年」の設定がされていなかったことが原因だということです。

　「うるう年」が原因のトラブルは、他でも発生していました。

　大手ドラッグストアのスギ薬局でも管理システムに障害が起き、全国の店舗で一時、処方薬の会計ができなくなりました。

　スギ薬局によりますと、3年前に現在の会計システムを導入。初めて2月29日を迎え、過去の記録がなく障害を起こしてしまったということです。

　薬の処方に問題はなく、会計ができなかった客には後日、代金を支払ってもらうとしています。

（「グッド！モーニング」2024年3月1日放送分より）

**デフォルトの名無しさん** · 2024/03/01(金) 23:34:09.01

>>283
すまんけど言ってることがよく理解できなかったわ
生産的じゃなさそうなのでこの話はもうやめとく

**デフォルトの名無しさん** · 2024/03/02(土) 11:50:59.70

ashworth、自分から言い出した仕様に完敗ｗ

**デフォルトの名無しさん** · 2024/03/02(土) 13:58:32.22

都合が悪いレスは全てashworth認定しないと自我が保てなくなってるんだな
ここまでいくと病気だから早めに病院行けよな

**デフォルトの名無しさん** · 2024/03/02(土) 15:28:11.69

馬鹿言ってる投稿を「都合が悪いレス」と曲解する辺りashworth丸出しで草ｗ

**デフォルトの名無しさん** · 2024/03/02(土) 15:47:12.16

> E: ただし、30と4の倍数の年はうるう年ではない

これって

E: ただし、30の倍数または4の倍数である年はうるう年ではない
E: ただし、30の倍数であり4の倍数である年はうるう年ではない
E: ただし、30年または4の倍数の年はうるう年ではない

いろんな解釈可能だけど、こんな仕様書く奴は素人よな。

**デフォルトの名無しさん** · 2024/03/02(土) 17:25:47.49

>>286
https://godbolt.org/z/coTEYncxr
https://godbolt.org/z/Kd9WW1xEc

andでもorでもEの条件判定は削除されるんだがアホはお前だろｗ

**デフォルトの名無しさん** · 2024/03/02(土) 17:38:03.69

>>284
>逆接の接続詞である「ただし」で結んでるのは日本語としておかしい
「ただし」は逆接の接続詞ではないぞ
誤った思い込みが根本原因だったか

**デフォルトの名無しさん** · 2024/03/02(土) 19:13:35.61

ashworth曰く

https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd#comment-8eb8979a5b3ed36b80fc
> 「ただし」がある場合は前出の条件を否定してくる

だそうだから辞書になんて書かれていようが奴の言ってる「ただし」については
逆接の接続詞という理解で合ってる。

**デフォルトの名無しさん** · 2024/03/02(土) 19:49:38.94

>>294
ほい
https://thesaurus.weblio.jp/content/%E3%81%9F%E3%81%A0%E3%81%97

> 条件付け・逆接の補足
> 但ししかしとはいえとは言ってもそれでもなおだけどけれどもですがかと言ってさりとてそうはいっても

**デフォルトの名無しさん** · 2024/03/02(土) 19:51:21.69

>>294もそうなんだけど「ただし」を誤解してるのが誤りの原因であるという主張、全部ashworthよねｗ

**デフォルトの名無しさん** · 2024/03/02(土) 22:38:28.08

>>293
笑ってしまうほど糞コード。
最初に4の倍数じゃないとスキップされてしまう時点でおかしいと思わんのか。

**デフォルトの名無しさん** · 2024/03/02(土) 23:12:36.56

「最初に4の倍数じゃないとスキップされてしまう」のがおかしい理由を説明しない辺りでashworthって丸わかりなんだよなあｗ

そんなに悔しかったかｗｗ

**デフォルトの名無しさん** · 2024/03/02(土) 23:20:14.73

うるう日にしか発生しないバグ
zenn.dev/razokulover/articles/7001ed233137e5
ちなみにChatGPTに先の要件を伝えて生成してもらったコードもうるう年が考慮されておらず手直しが必要だった。
AIで生成されたコードが要件に合うかどうかを読み解ける程度の力はまだ我々には必要そう。

**デフォルトの名無しさん** · 2024/03/02(土) 23:33:08.53

>>296
さすが低リテラシー
辞書すらまともに持ってない上に低品質の情報ソースしか見ない
そりゃクソコード量産するわw

**デフォルトの名無しさん** · 2024/03/02(土) 23:41:41.36

>>301
一目でashworthってわかるコメントすげえな

**デフォルトの名無しさん** · 2024/03/02(土) 23:47:27.34

https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd

のコメントで

> 条件分岐が商業的な理由でどんどん仕様変更されていく事があるのは、仕事でプログラミングをした事があれば分かりませんか？

とか

> 多分、これが仕様書か基本設計書に書かれるんですよね。
>
> A: 4の倍数ならばうるう年
> B: 100の倍数ならば平年
> C: 400の倍数ならばうるう年
> そうしたら、この仕様に沿った形でコード書かないと。

とか、主張としては一理あること言ってるのに400の倍数は100の倍数に含まれるとか利用した記事主のコード支持してんのわけわからんなあ。
結局気に入らない相手にケチつけたいだけなんだよなあ。

**デフォルトの名無しさん** · 2024/03/03(日) 00:28:36.24

>>301
weblio知らないなんてインターネットリテラシー低すぎますよw

**デフォルトの名無しさん** · 2024/03/03(日) 13:38:29.39

> 多分、これが仕様書か基本設計書に書かれるんですよね。
>
> A: 4の倍数ならばうるう年
> B: 100の倍数ならば平年
> C: 400の倍数ならばうるう年
> そうしたら、この仕様に沿った形でコード書かないと。

仕様に沿った形というとこういうコードだよなあ。

def is_leap_year(year):
　leap_year = False
　# A: 4の倍数ならばうるう年
　if year % 4 == 0:
　　leap_year = True
　　# B: 100の倍数ならば平年
　　if year % 100 == 0:
　　　leap_year = False
　　　# C: 400の倍数ならばうるう年
　　　if year % 400 == 0:
　　　　leap_year = True
　return leap_year

仕様変更に対応し易いという点では優れてるかな。うるう年判定にそれが必要かは疑問ではあるが。

**デフォルトの名無しさん** · 2024/03/03(日) 13:40:04.83

『リーダブルコード』に洗脳されたのかナントカの一つ覚えよろしく早期リターンを勧める人Qiitaでは見掛けるけど仕様からは逸脱しちゃうんで「仕様に沿った形でコード書かないと」という主張的にはナシだろうな。

def is_leap_year(year):
　# 4の倍数でないなら平年
　if year % 4 != 0:
　　return False
　# 4の倍数で100の倍数でないならうるう年
　if year % 100 != 0:
　　return True
　# 4の倍数で100の倍数で400の倍数でないなら平年
　if year % 400 != 0:
　　return False
　# 4の倍数で100の倍数で400の倍数ならうるう年
　return True

**デフォルトの名無しさん** · 2024/03/03(日) 14:21:08.84

https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd#comment-1dd48f5238d4a2c96c3c
> 多分、これが仕様書か基本設計書に書かれるんですよね。
>
> A: 4の倍数ならばうるう年
> B: 100の倍数ならば平年
> C: 400の倍数ならばうるう年
> そうしたら、この仕様に沿った形でコード書かないと。

おいおいashworth、「ただし」どこやった?
「仕様に沿った形でコード書かないと」ってどの口で言ってる?

https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd
> うるう年と判定する条件は、以下のとおりである。
> A: 4の倍数の年は、うるう年
> B: ただし、100の倍数の年は、うるう年ではない（平年）
> C: ただし、400の倍数の年は、うるう年

**デフォルトの名無しさん** · 2024/03/03(日) 14:31:47.57

「ただし」がないとインデントは浅くできる。

def is_leap_year(year):
　leap_year = False
　# A: 4の倍数ならばうるう年
　if year % 4 == 0:
　　leap_year = True
　# B: 100の倍数ならば平年
　if year % 100 == 0:
　　leap_year = False
　# C: 400の倍数ならばうるう年
　if year % 400 == 0:
　　leap_year = True
　return leap_year

「ただし」のありなしは仕様にある「4」「100」「400」の値が変われば結果に影響するのでこの点は重要。

**デフォルトの名無しさん** · 2024/03/03(日) 14:49:33.76

コードもクソだけどコメントもまたクソなんだよなぁ
クソコード書くやつ特有のコメントの書き方

**デフォルトの名無しさん** · 2024/03/03(日) 16:04:43.33

ashworthの投稿はわかりやすいなあｗ

**デフォルトの名無しさん** · 2024/03/03(日) 16:22:53.63

>>309
じゃあashworthが称賛してる記事主のコードを見てみよう。

> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> 　　print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> 　　print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
> 　　print("うるう年です。")
> else: # どれにも当てはまらなければ、「うるう年ではありません。」
> 　　print("うるう年ではありません。")

んー大差なくね?
つか出力するメッセージとコメントが被ってる分どうかという気がするわ。

**デフォルトの名無しさん** · 2024/03/03(日) 17:17:37.89

> A: 4の倍数ならばうるう年
> B: 100の倍数ならば平年
> C: 400の倍数ならばうるう年
> になります。
>
> ここで、AとBの条件に注目して、
>
> 100の倍数ならば、4の倍数である
> ことに気づくと、
>
> 100の倍数は平年。そして100の倍数でない4の倍数はうるう年。
> という形で、AとBの関係を整理することができます。
>
> 同様に、BとCについても、
>
> 400の倍数ならば、100の倍数である
> ので、
>
> 400の倍数ならばうるう年。そして400の倍数でない100の倍数は平年。
> という形で、BとCの関係を整理することができます。
>
> まとめると、ある西暦に対して、
>
> 400の倍数ならば、うるう年
> 400の倍数でない、100の倍数ならば、平年
> 100の倍数でない、4の倍数ならば、うるう年
> 4の倍数でないならば、平年
> ということになります。

これコメントに書かなくて良い理由がわからん

つか記事主も「ただし」勝手に削除しとるのなｗ

**デフォルトの名無しさん** · 2024/03/03(日) 20:00:32.81

初めて聞いた「カルノー図」に発狂してるashworthオモロｗ

**デフォルトの名無しさん** · 2024/03/03(日) 21:02:10.90

・if は個人的に「もし～なら」で言ってほしい
・「ただし」はプログラミング的な英単語がない気がするので(however的な？)、仕様書とかでも多用しないで欲しい
・else、elseifも「ただし」じゃないと思うので相応の日本語にしてほしい
・早期リターンしてほしい

400から順番にreturnしてもらえれば、ワイ的にはおけ
仕様変更の可能性に対してはとりあえず関数にしてればいい
マジックナンバーじゃねとかライブラリ使えとか色々あると思うけど、この関数が必要なんだろうからテスト通れば許容すると思う

**デフォルトの名無しさん** · 2024/03/03(日) 21:47:18.39

閏年の仕様が変わったら判定関数だけ置き換えればいいのだから
判定関数の中身なんて何でもいいのよ
割り算(剰余算)と分岐はCPUにとって非常に遅いから避けるとするならば例えばこんな感じ

fn is_leap_year(year: u64) -> bool {
　let q100 = (year * 42949673) >> 32;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}

**デフォルトの名無しさん** · 2024/03/03(日) 22:44:59.76

>>315
107374182500年は平年? 閏年?

**デフォルトの名無しさん** · 2024/03/03(日) 23:02:43.19

Rust推しは意識高い良く分かって馬鹿が多い印象

**デフォルトの名無しさん** · 2024/03/04(月) 00:48:03.64

>>315
素直に100で割らない意味がわからん。
要らんことやって仕事増やすタイプだろお前。

pub fn is_leap_year(year: u64) -> bool {
　let q100 = year / 100;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}
https://godbolt.org/z/YKPWx7ecW

**デフォルトの名無しさん** · 2024/03/04(月) 08:16:08.85

>>315
> 閏年の仕様が変わったら判定関数だけ置き換えればいいのだから
> 判定関数の中身なんて何でもいいのよ

仕様通りに動作するコーディングできるようなってからカッコイイこと言おうなｗ

**デフォルトの名無しさん** · 2024/03/04(月) 08:38:24.53

>>308
あまり見かけねえ書き方で新鮮だな

**デフォルトの名無しさん** · 2024/03/04(月) 09:02:08.19

>>315
Rustって使ったことないんだけど動確してみた。書き方合ってる?

fn is_leap_year(year: u64) -> bool {
　let q100 = (year * 42949673) >> 32;
　((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)
}

fn main()
{
　let year = 107374182500;
　println!("is_leap_year({}) -> {}", year, is_leap_year(year));
}

実行結果:
is_leap_year(107374182500) -> true

https://wandbox.org/permlink/QpmojpixtLrxk9CW

**デフォルトの名無しさん** · 2024/03/04(月) 09:41:48.67

>>316 >>321
1000億年後の閏年とか低能丸出し
地球も存在しないぞ
それ以前に60万年後には誤差が半年となり夏冬逆転し無意味となる
それ以前にルールが変わるため大きな数に対応する意味がない

**デフォルトの名無しさん** · 2024/03/04(月) 09:52:37.00

日本語に弱いやつしかいないのに互いに馬鹿にしあってるの草

**デフォルトの名無しさん** · 2024/03/04(月) 10:05:22.74

年を表す引数の型にu64使うのが頭悪い。引数型で表せる値について動作保証できないロジックも同様。
引数に4300億とか与えるとオーバーフローするし場合により異常停止するだろこのコード。実際にそういう引数は与えないと強弁したところで潜在的不具合であることに変わりない。

**デフォルトの名無しさん** · 2024/03/04(月) 10:07:06.25

話題に加われない>>323がashworthなの一目瞭然で草ｗｗ

**デフォルトの名無しさん** · 2024/03/04(月) 10:17:08.86

https://wandbox.org/permlink/V9X44saMMVMpQVoi
> thread 'main' panicked at 'attempt to multiply with overflow', prog.rs:2:14
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

あっこれはカッコ悪いなｗ

>>315
> 割り算(剰余算)と分岐はCPUにとって非常に遅いから避けるとするならば例えばこんな感じ

素直に100で割ってればオーバーフローしないんだし優先順位間違ってるよ。

**デフォルトの名無しさん** · 2024/03/04(月) 10:23:15.83

Rust使いでニワカかあ。
自己評価と実力が合ってない雰囲気で質悪そう。

**デフォルトの名無しさん** · 2024/03/04(月) 10:29:55.63

え、今更入力値が何でもアリになるの？w

**デフォルトの名無しさん** · 2024/03/04(月) 10:55:00.92

仕様に入力値の範囲が決められてないのに実装者の都合で制限設けて良いって判断は流石に草

**デフォルトの名無しさん** · 2024/03/04(月) 11:23:54.90

じゃあバリデーションが必要だなww

**デフォルトの名無しさん** · 2024/03/04(月) 13:14:12.60

要件定義の際にクライアントに「1億年後も検証出来る仕様にした方がいいっすか？w」と聞かなかった上流の責任笑

**デフォルトの名無しさん** · 2024/03/04(月) 13:53:50.23

Rust支持の人達って安全について意識が高く技術的レヴェルが高い層だと思っていたので自ら率先して不具合を作り込もうとする>>315の存在には驚いたんだけど、よく考えてみると

「えっ今どきEmacsなんて使ってるの？今はVSCode一択でしょ」
「えっ今どきSVNなんて使ってるの？今はgit一択でしょ」
「えっ今どきJavaなんて使ってるの？今はKotlin一択でしょ」
「えっ今どきC++なんて使ってるの？今はRust一択でしょ」

使ってる道具でマウント取ろうとする奴なんて昔からいるし使ってる道具が新しく洗練されてたとしてそれ使ってる奴の技術的高さを証明するものではないしなあ、変な先入観持ってたわと反省。

**デフォルトの名無しさん** · 2024/03/04(月) 14:34:57.46

>上流の責任笑
これが末端コーダーの考え方

**デフォルトの名無しさん** · 2024/03/04(月) 15:14:26.33

>333
ヒント:冗談

**デフォルトの名無しさん** · 2024/03/04(月) 16:34:00.40

入力値に制限がないなら、
文字列とか小数とかそれ以外のパラメータなときを考慮してない
今までのコードは軒並み全部ダメってことでw

**デフォルトの名無しさん** · 2024/03/04(月) 17:50:07.95

>>334
何をバカにされてるかわかってない辺りがまさに末端コーダー

**デフォルトの名無しさん** · 2024/03/04(月) 17:59:24.41

>判定関数の中身なんて何でもいいのよ
判定関数自体の保守性が論点にも関わらずそれを無視した独りよがりのオナニー汚コードを恥ずかしげもなく披露するメンタリティが怖い

**デフォルトの名無しさん** · 2024/03/04(月) 18:31:19.07

>>335
元記事に整数と書いてあるんだからそこまで考える必要はないでしょ

**デフォルトの名無しさん** · 2024/03/04(月) 19:15:00.88

>336
納期近いのか？イライラしても仕事は進まんぞ

**デフォルトの名無しさん** · 2024/03/04(月) 19:16:47.00

97/400の閏年は10万年で1ヶ月の誤差が出るため100万の入力すら対応する必要がない
そこへ億の入力をして騒ぐのはキチガイ

**デフォルトの名無しさん** · 2024/03/04(月) 20:12:58.89

整数、西暦なんて数値制限がないんだから、
型も限りなく無限にちかいbit、桁数まで対応しなきゃいけんのかw
こりゃ大変だなw

**デフォルトの名無しさん** · 2024/03/04(月) 20:22:40.17

現在のグレゴリオ暦を運用し続けたとして1兆年後どうなるか? みたいな計算をしたいとして、間違って良い理由はないんだよなあ。

**デフォルトの名無しさん** · 2024/03/04(月) 20:30:16.70

>>322
>>315のコードでおかしな結果を出す一番近い年が107374182500年だと思ってる??

**デフォルトの名無しさん** · 2024/03/04(月) 20:34:57.33

3320年で1日の誤差
10万年で1月の誤差
120万年で1年の誤差
季節が数か月ズレると役立たないから
多くても数十万年に対応してれば十分かな
それ以上の数値を持ち出す人は本質的に何が重要なのかを理解できていないバカ

**デフォルトの名無しさん** · 2024/03/04(月) 20:52:01.50

> 多くても数十万年に対応してれば十分かな

クソコードは数十万年に対応出来てることを証明するのにも無駄に労力要るんだよなあ。

**デフォルトの名無しさん** · 2024/03/04(月) 20:55:08.59

> それ以上の数値を持ち出す人は本質的に何が重要なのかを理解できていないバカ

↑入力値によってはプログラムが落ちる事の重大さを理解してないアホ

**デフォルトの名無しさん** · 2024/03/04(月) 20:59:22.65

入力値によってプログラムが落ちると思っているアホがいるのか

**デフォルトの名無しさん** · 2024/03/04(月) 21:07:19.90

>>315のコードは
・なぜ引数yearの型がu64なのか
・yearを100で割れば良いところを2**32/100倍して32ビット右シフトなんて馬鹿なことをしてるのか

謎なのよなあ、こんなコード業務で書いたら絶対レビューでなんか言われるやつじゃん。

説明すれや＞本人

**デフォルトの名無しさん** · 2024/03/04(月) 21:27:56.24

今どきのコンパイラは、定数割り算を定数掛け算とシフトでコード生成するから、それ自体を問題にするのは知識不足としか。

**デフォルトの名無しさん** · 2024/03/04(月) 21:30:45.48

>>347
>>326

**デフォルトの名無しさん** · 2024/03/04(月) 21:56:19.34

>>326
それDEBUGモードになってるね
RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ

**デフォルトの名無しさん** · 2024/03/05(火) 00:11:26.36

型でエラーになるのはダメやろw
有限な数値型を引数にする関数は全部ダメ

**デフォルトの名無しさん** · 2024/03/05(火) 00:19:04.31

それはあるな
少なくともbigintは必須

**デフォルトの名無しさん** · 2024/03/05(火) 00:24:51.84

>>337
平日の昼間から一日中5chに張り付いてるようなやつらに保守性を説いても時間の無駄
理由は言わなくてもわかるよね？

**デフォルトの名無しさん** · 2024/03/05(火) 00:40:04.95

関数内部の単なる数値演算に保守性もクソもないぜ
そんなところの保守性にこだわるやつは仕事できないやつ
それよりも複数のデータや複数の関数に関わるところの保守性をしっかりやればいい

**デフォルトの名無しさん** · 2024/03/05(火) 05:36:37.94

中身が何でもいいならわずかなパフォーマンス改善よりも楽に読み書きできるほうがいいわｗｗｗｗ

**デフォルトの名無しさん** · 2024/03/05(火) 06:40:09.05

非常に大きな値を扱える方がいい場合もあれば
実用の範囲だけを速く扱える方がいい場合もあれば
複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
それら様々な前提があるのだから
それぞれの前提でそれぞれのふさわしい別々のコードになるのは当たり前
各々の前提を無視して批判するのは愚か

**デフォルトの名無しさん** · 2024/03/05(火) 09:50:57.37

>>351
実行時にオーバーフローを検出する運用も普通に可能だけど安全の意味分かってる？

**デフォルトの名無しさん** · 2024/03/05(火) 10:58:46.36

>>351
> RustはC/C++と同じく整数演算はオーバーフローせずラッピングされるよ

CやC++でラッピングされるのは符号なし整数の場合だけ。
符号付き整数のオーバーフローは未定義動作になるので通常許されない。

**デフォルトの名無しさん** · 2024/03/05(火) 11:09:30.17

>>357
>非常に大きな値を扱える方がいい場合もあれば
>実用の範囲だけを速く扱える方がいい場合もあれば
>複雑になっても将来の拡張に備えた形にした方がいい場合もあれば
どの場合も保守性を無視したコードを書いていいわけじゃないんだぞ
ド素人さんw

**デフォルトの名無しさん** · 2024/03/05(火) 11:10:48.88

>>355
> 関数内部の単なる数値演算に保守性もクソもないぜ

>>315のクソコード見てから言え

**デフォルトの名無しさん** · 2024/03/05(火) 11:33:45.43

>>361
どう見ても同一人物だろw
アホか

**デフォルトの名無しさん** · 2024/03/05(火) 11:52:26.48

>>361
>>147のクソコード見てから言え！

**デフォルトの名無しさん** · 2024/03/05(火) 12:09:50.59

この狂人の会話についていけるやつが賢いと本気で思うやつおる？w

**デフォルトの名無しさん** · 2024/03/05(火) 12:30:39.80

>>363 ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/05(火) 18:44:35.96

>>318
「let q100 = year / 100;」の方が生成コードが長く遅くなってるな
あくまでも速さ優先ということならば>>315の
「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか
あとは状況による使い分けだろう

**デフォルトの名無しさん** · 2024/03/05(火) 19:35:33.31

>>366
> あくまでも速さ優先ということならば

https://godbolt.org/z/4sTMYGb9d

引数yearの型をu32にして普通に100で割るのが正解。

**デフォルトの名無しさん** · 2024/03/05(火) 20:42:06.70

> あくまでも速さ優先ということならば>>315の
> 「let q100 = (year * 42949673) >> 32;」が正解でいいんじゃないか

「自分は>>315じゃないけどこの人のコードが正解だと思いますよ」みたいな投稿よくできるなあ。

**デフォルトの名無しさん** · 2024/03/05(火) 20:50:34.98

周りが見てて赤面するような低レベル自演
それをいつも平気でするのが彼なんです

**デフォルトの名無しさん** · 2024/03/05(火) 21:13:56.87

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/05(火) 22:49:41.95

まだクソザコミジンコいるの？いい加減飽きたよ

**デフォルトの名無しさん** · 2024/03/05(火) 23:54:29.42

ashworthの投稿は一目でわかるなｗｗ

**デフォルトの名無しさん** · 2024/03/06(水) 10:25:59.29

C言語1からお教えします！
https://qiita.com/ToaruSWEng_Yopiro/items/0fa594857d72c68fe3f7

宣伝記事。
30日で5万円て微妙な線かな。本人の実力とかサッパリわからん人だけど。

**デフォルトの名無しさん** · 2024/03/06(水) 23:45:18.98

>>367
なるほど
コンパイラが
let q100 = year / 100;
を
let q100 = ((year as u64 * 1374389535) >> 37) as u32;
へと自動変換してくれてるんだ
これは割り算が遅いため？

**デフォルトの名無しさん** · 2024/03/07(木) 17:33:15.65

>>373
消えてんじゃん
それでちゃんと教えてもらえるなら安いが修了して嘘ばっか教えられたとか何も残らんとか独学と変わらんならただの銭ドブだな

**デフォルトの名無しさん** · 2024/03/07(木) 20:58:11.23

>>315と>>374を比べると微妙に違うんだな
q100 = (year * 42949673) >> 32
q100 = (year * 1374389535) >> 37

**デフォルトの名無しさん** · 2024/03/08(金) 01:22:49.50

ashworthの投稿は一目でわかるなｗ

**デフォルトの名無しさん** · 2024/03/08(金) 01:36:10.70

>>376
2^5＝32倍すれば同じ

**デフォルトの名無しさん** · 2024/03/08(金) 20:20:11.11

>>367
うるう年判定プログラムの最終的な正解はそれか
q100 = year / 100
return ((q100 & 3 == 0) | (q100 * 100 != year)) & (year & 3 == 0)

**デフォルトの名無しさん** · 2024/03/08(金) 21:23:51.45

うるう年の判定に速度なんて求められてないから可読性捨ててるコードが正解な訳ないんだよ