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

以下の性質の良さの違いのため
プログラミングでは半開区間が多用されている

半開区間　(性質が良い)
・start～endの長さはend-start
・startから始まる長さlenの区間はstart～(start+len)
・startから始まる長さ0の区間はstart～startと表せてそのまま自然に扱える
・途中middleでstart～middleとmiddle～endの二つに分割できる

閉区間　(性質が悪い)
・start～endの長さはend-start+1
・startから始まる長さlenの区間はstart～(start+len-1)
・startから始まる長さ0の区間はstart～(start-1)になって破綻
・途中middleでstart～middleとmiddle～endの二つに分割できない
start～middleと(middle+1)～endか
start～(middle-1)とmiddle～endになる

>>173
カルト教団のむきになった反論そのものw　教祖様のお言葉がソースか?　

自然言語と高校までの数学表記が一般に広く受け入れられていること、それで根拠として十分。

>>177

>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう

区間指定の文法を持つ最近のメジャーなプログラミング言語では半開区間を簡単に表記できるようになっている
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している

>>178
定義なんて所詮は教祖様がお作りになった教義に過ぎない。それを絶対視して変だと考えず、
変だと指摘する人にむきになって壊れたレコードのようにワンパターンな反応を繰り返す
カルト信者。

>>180
定義はコンパイラの仕様
バカすぎる無職

>>180
変なのはお前
だから無職なんだろ中卒

>>176,179
これを入社試験の面接で説明できなきゃ不採用でいいわ
これ分からん奴はセンスが無さすぎる

>>181
コンパイラは教祖様がお作りになった言語仕様に沿って作られたものだろ。

>>182
無限ループ、またの名を暴走と言うw

>>184
これが無職

>>183
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う

ここプログラム技術板で閉区間が自然だと主張して暴れてるやつはどこから来たお客さんなんだろう

>>187
閉区間が自然だとは全く主張していないぞ。

・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
　提供するのが良い（勿論、前者の場合には閉区間が自然ということになるが）

・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
　生みにくい

と主張しているだけ。

現実のメジャーなプログラミング言語では>>179のように半開区間を簡潔に記述できることを重視している

>>188
根拠0
証拠0
ソース0

バカすぎて論外

>>188
こういうバカは無職なのが自然

>>188
func main(){
　var a = [5]string{"a","b","c","d","e"}
　fmt.Println(a[0]) // a
　fmt.Println(a[1]) // b
　fmt.Println(a[1:3]) // [b c]
}
Go言語は半開区間のみ

> 両方の書き方を提供するのが良い

半開区間のみを提供するのが良い
２つの書き方を提供するのはバグを生みやすい

あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名

>>192
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない

>>192
＞あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
　
TypeScriptコンパイラのことなら
　
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
　
という記事にまとめられているが
　
＞半開区間のみを提供するのが良い
＞２つの書き方を提供するのはバグを生みやすい
　
なんて理由は挙げられてないね。

現実は>>179
理由は>>176
ということでいいのかな

閉区間と半開区間のどちらが優れているということは誰も言ってないのに一人発狂してる人がいる感じ

閉区間より半開区間が優れている
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ

無職の妄想に価値はない

グレゴリオ暦のうるう年判定に延々とおかしなイチャモンつけてたashworthまんまだなｗ

そもそも自転はずれるからな

いまはこのルールでやりましょうというグレゴリオ暦を分かってないｗ

グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする

低学歴がなぜ低学歴なのかよくわかる

>>201
バカすぎてルールを理解できないことを正当化するためにルールがおかしいと吠えたまま死ぬ
これが低学歴の人生

そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み

>>188
閉区間ではなく半開区間をサポートするプログラミング言語が多い理由を考えてみよう
それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう

算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は

> そもそも自転はずれるからな

地球の自転周期が変わったとして影響があるのは1日の長さなんだがｗ

>>207
多用する半開区間に短い記号を充てるのが正解だと思う
しかしPythonやGoの start:end はあまりにも短すぎて用いる場所によっては文法的に曖昧になる可能性があるためなのか
現状はスライスのインデックス部分 a[start:end] でしか用いることができない
例えばmatch文のcaseでは指定できないため case x if start <= x < end と書く必要がある
イテレータとしても指定できないため for i in range(start, end) と書く必要がある
これら全て同じ記法で書けると好ましい

Rustは同じ扱い
buf[100..200]
for i in 100..200 { … }
match x {
100..200 => …,
…
}

>>207
圧縮ファイルを直読みできる超人さんですか?w

短さを馬鹿の一つ覚えみたいに持ち出しているが、間違えにくさを犠牲にしてまで達成すべきものではない。
人間は機械ではないのでうっかり間違えやすい記号を宛てないのが賢明で、たった1文字をケチるのは愚行。

正確に言えば機械も生の状態では間違えるから、エラー訂正符号を付加して無謬に見せかけているだけなので、
人間にも機械にも最短ではなくそれぞれの間違え方を防ぐような追加の情報も必要だという訓戒に纏められるな。
そこを疎かにするのは欠陥設計。

>>211

算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は

>>212
え？圧縮ファイル？
何言ってんのこの中卒無職脳障害
そんなの関係ねえよ猿が

情報理論的な効率性の話しかしてないのに中卒だからわかんねえのか自殺しとけ猿が

>>212
お前が低学歴で人間じゃないだけ
お前は無職で人間の世界から排除されてるから人間の世界に口出しする権利ないよ
参加お断り

>>214
馬鹿には皮肉の解説が必要だったか。情報理論的な効率性を徹底的に追求したのが圧縮ファイルだろ。
それは人間には勿論読めないが、もう少し緩く追求した半開区間に..を使う表記も人間にはやっぱり
間違いやすい。お前がそんなことはないと言い張るなら、さぞかし凄い超人なんだろうねーという皮肉。

たった1文字追加するだけで効率性と間違えにくさのバランスが取れた表記になるのに、ムキになって
否定するのは愚か。

>>216
圧縮ファイルなんて使ってない
人間の世界では最短符号を使って人間は読んでる
無職はそれが読めないから誰も雇わない

>>216
お前が間違えてもどうでもいい
だってお前は人間じゃないし人間の社会に参加出来ないから

>>216
人間は間違えない
猿は間違える
だから猿を雇わない
よってお前は無職
猿だからな

>>216
C#の半開区間指定start..end読みやすくて良いと思うよ
閉区間だと間違える人はいない

人間は間違えない
猿は間違える
だから猿を雇わなきゃいいだけ

猿に合わせて人間のルールを変えるわけねえだろ
猿を排除するのが最善

>>211
それら閉区間しかないプログラミング言語は現代のメジャーな言語ではないな
センスが悪いとメジャーな言語になれないことがわかった

>>202
『あなたは本当に「プログラミングができない、向いてない」のか？ 〜うるう年判定プログラムで考える〜』
https://qiita.com/kjm_nuco/items/fd16c2af6b089c4849cd

という記事のコメ欄でashworthが他のコメントに絡んでたけど(垢BAN済み)、記事のコード見ると

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

400は100の倍数、100は4の倍数を利用したグレゴリオ暦の説明の逆順で判定するけったいなコード書いてんなあナンダコレ?
まあ記事はNucoなんでセンスなくて当たり前なんだけど、ashworthがこれに絡んでなかった辺りやっぱセンスないわなｗ

まともな言語がいずれも半開区間をサポートしているのは偶然ではなくて、
配列やリストやベクタあるいは文字列などの連続領域の一部分いわゆるスライスを言語で扱おうとすると、
その区間を指定する必要がでてくる。

まともな汎用言語ならそのスライスと区間指定をサポートするのは必然で、
しかも閉区間は扱いにくいことが判明しているわけだから、
結果的に半開区間をサポートしているか否かでまともな言語か否かが判明することになっている。

>>224のコードってそんなに変かな？　自分もこんな感じに書くと思うが。

>>226
動くコードは無数に考えられる。
しかし保守性を考慮すると、
元の文章に対応したコードのみが正解。
元の文章と逆順に書いた場合、
何か理由が添えてない限り失格でクビだろうね。

ソース読めよ

Check out this DeepWiki page https://deepwiki.com/search/calendarisleap_6015837d-0d22-4326-870d-fd0623c9acd7

なるほど、if文のネストみたいな感じで書くのだとしたらそれはかえって分かりにくいのではと思ったけど、and or で1行で書いちゃうならスッキリしているね。

if文使った時点で不採用
print文使った時点で不採用

正解は
・数式・比較演算子と論理演算子で書く
・デバッガで各論理式の評価を確認してprint文を使わない

deepwikiでソースコードに聞け
低スキルの「エンジニア」同士で低スキルを伝播しても害しかない

print関数はさすがに説明の便宜のためでしょ。

知りたいgithubのアドレスを取得
https://github.com/python/cpython

アドレスのgithubをdeepwikiに置換
https://deepwiki.com/python/cpython

最下部のフォームに質問すればソースコードをソースにして回答する

で
このdeepwikiもMCPでアクセスできるので
AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る

低スキルエンジニア同士の会話など害しかない

速さ優先ならこれとはまた異なってくるのだろう
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

return False

> それ、問題文の条件のまま書いちゃダメなんですよね。
> 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
> だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。
　
ashworthさん、何言ってんの?

>>219
これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて
間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか?

C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで
if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を
できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに
数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw

仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。

Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では
危うさを放置するのはチグハグだな。

あと、ここはプログラマー板じゃなくてプログラム板だから、別に職業プログラマ向けというわけではなく、
プログラムに関する見識は職を得ることに結びつかない。職業プログラマなんてIT土方とも揶揄されて
威張れるもんじゃないし、まして特定の言語と一蓮托生で必死になってるようではなー。お前の煽り文句は
明後日の方を向いているw

>>223
ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。
Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは
繁文縟礼の塊なのであまり普及せず実害は少ない。

C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが
..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を
許してしまったの解せない。

>>238
いやRustなんか興味ないし知らん
どうでもいい
脳障害は日本語すら読めないだけ
人間は間違えないので猿を雇わなければ良いだけ
猿のために人間のルールを変えるわけない

半開区間に左右非対称を採用してる言語はSwiftだけじゃね？

半開区間の記法
【start:end】 Go Python
【start..end】C# Rust Zig
【start...end】Ruby
【start..<end】Swift

この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと

1991 Python
1995 Ruby
2000 C#
2009 Go
2010 Rust
2014 Swift
2015 Zig

後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな

C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0

『Cなら知ってるんですけど、C++ってできますか？』
　
Cた間違い

CやC++初心者は間違い探し的に読むと良い記事。

>>244
モダンC++と言いつつ大昔の古臭いC++11で草
さらにC++11と言いつつ中核のスマートポインタを割愛で草

長文おぢウザい

>>241
>>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、
つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している（Kotlin, Nim, Swiftは
..<で、Rakuは...^）。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。
これらに含まれる...は…と1文字で書いても良い。

Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには
反しているな。

>>238
> 変数宣言でmutをいちいち書かせるなど

これはプログラマーに
mutable宣言を意味するmutなどを書かせるべきか
immutable宣言を意味するconstなどを書かせるべきか
どちらをデフォルトにすべきかという問題だね

これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる
プログラマーの手間もその方が少ない

Qiita Conference 2025 Autumn というので
https://qiita.com/official-campaigns/conference/2025-autumn

> 今のコンピュータはAIにもWebにも向いていないので作り直そう
> 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか？
> 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット／レイテンシ／電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用／データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。
> こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方／イノベーションを共有し、実際の解決実装例をご紹介します。

コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう?

>>250
課題を生み出すwwww
省電力を引き上げるwwwww

これだけで価値がないとわかる

>>250
山崎かなと思ったら福岡Elixirって書いてあったから同族か

>immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
マイナーな言語しかなくね？
「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ

Elixirの軽量スレッドで並列処理が効率化できてスパコン的用途にも使えると思ってる人たちだからなあ、つける薬がない。

>>253
immutableだけだと不便で制限が生じる
その一方でプログラムはなるべくimmutableを中心にしてmutableは補助的に使うと良いコードになる

Elixirでフィボナッチ数列をいろいろ書いてみた Part. 5
https://qiita.com/zacky1972/items/1d2dd390454e80f39d3f
> Fibonacci with Matrix は素晴らしく速いですね！

Elixirで順に指定個数の素数を列挙する関数をEnum, Stream, Flowで作ってみた
https://qiita.com/zacky1972/items/2cdc68f56c2b42b803e1
> 1000,10000個の時にはFlowが最速でした．

1000番目のフィボナッチ数計算すんのに 1.33m秒とか、ベンチマーク結果なんでか編集で消えてるんだけど

> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms

20000未満の素数算出すんのに 84m秒って遅すぎね?

福岡Elixirってこんな記事ばっかりだな。んで、身内でいいね付けあってる。

スキルがあるのに福岡なんかにある仕事の給料で耐えられるわけない

>>256
> 20000未満の素数算出すんのに 84m秒って遅すぎね?

ベンチマーク出すのに84m秒って速すぎね?
84m秒のベンチマークを100回やるのがいいのか8.4秒のベンチマークを1回やるのがいいのかで遅いほうがいいと思うんだが

フィボナッチ数は行列累乗を理解してないから乗数の数だけ掛け算やってるし、素数の方は「エラトステネスのふるいを純朴に利用して」と書いてる割に剰余計算で余りがでたものを倍数としてフィルタする処理になってて全然エラトステネスのふるいじゃないなあ、ダメだこりゃ。

どちらの記事もアルゴリズムへの理解がなくて効率悪いことやってるんだが、こういう記事平気で公開してる人が

地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は
決して無縁ではない」(2022年版)
https://qiita.com/zacky1972/items/a67459bf36f7b369b946

なんて記事書いてて頭が痛い。
これで大学の先生ってなあ、冗談なら良いのに。

>>258
84m秒は100回実行した中央値らしいしそこは問題ないと思う。

> ##### With input 10000 #####
> Name ips average deviation median 99th %
> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms
> prime_stream 1.14 874.15 ms ±21.02% 787.90 ms 1243.42 ms
> prime_enum 0.81 1233.13 ms ±0.51% 1235.09 ms 1241.00 ms

>>259
エラトステネスのふるいは、
作業メモリをその数だけ必要とすることと引き換えに、
足し算だけで素数を求めることができるアルゴリズムだから、
遅い剰余算を用いた時点で失格となりますね。
エラトステネスのふるいの場合をベンチマークとして比較しているわけでもないようてすね。

この先生はElixirみたいなニッチな言語研究するより先にアルゴリズムの勉強したほうが良いと思う。
現状では学部の学生並みの知識もある気がしない。

『【C言語】char型の落とし穴~オーバーフロー~』
　
charの変数の値はintに昇格されてから加算されるのでこの場合オーバーフローしないし、intからcharに型変換する際にビットが捨てられるのもオーバーフローじゃないけど、この記事は何をオーバーフローと呼んでいるのか?

Cしか使えない特殊な環境ならともかく
勝手に異なる型へ自動変換されて困ったことになる弱い型付け言語のCを使ってる情弱の知識はそんなもんだ

https://qiita.com/GonT38847064/items/0770153fd0fb05abaa8a#comment-b7ef583e34653899a04a
> ご指摘ありがとうございます。数値を修正しました...

コンパイルエラーが出るよう修正するとかｗ
https://gcc.godbolt.org/z/565sb5PEh

今となっては未定義動作だらけの欠陥言語Cにこだわる人はほぼ異常者だな
残りは特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ

組み込みの世界知らない人かな

C以外は特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人って事?

>>267
それはコレやね

>>特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ

>>268
C以外に未定義動作だらけなクソ言語あるの？

> C以外に未定義動作だらけなクソ言語あるの？
　
C++も聞いたことない人かあ

C/C++は同罪だね
C++が失敗した理由はいくつも挙げられてきたけど
拡張方法の失敗に加えてCの未定義動作を埋めきれなかったことが響いてる

Javaでもメソッド無いの初期化されていない変数とかで失敗するけど
未定義動作になるのを言語のせいとか言ってるけど自分が必用な値が自動でセットされるわけじゃないのだからそういう奴ってバグを作り出す

>>273
Javaでは未定義動作にならないため問題は起きません
ローカル変数は初期化しないとエラー
インスタンス変数はデフォルト値で自動的に初期化されます
デフォルト値は各型により0やfalseやnullなど定まっています
Cの実行するたびに値が変わる問題はJavaでは起きません

その辺見越して大きい値扱える変数使って明示的にうまいことやるからどうでもいいんだよなあ

>>275
debug modeとrelease modeの違い
標準状態ではdebug modeで動作
実行時コストをかけて様々な検出をしてくれる
release modeでは明示的な実行時コスト指定ex. checked_add()などがある時のみ

x86やARMでオーバーフローチェックのコストなんて大したものではないので、最適化有効の場合でもオーバーフローチェックは行うのがフェイルセーフ的に正しいな。
オーバーフローチェックのコストが問題になるレアケースでは記述を変える対応が良い。
そういう判断できなかった辺りが残念言語なんだよなあ。

>>278
オーバーフローチェックのコストはとんでもなく高いんだよ。
演算命令1つ行なう毎に、そこで立った条件フラグによる条件分岐を毎回行なう必要がある。
これはコンパイラが行なうコードの並べ替えやループの展開やベクトル化などを全て阻止してしまう。
劇的に遅くなることが判っているよ。

さらにアセンブリ言語を書いたりコンパイル結果を見たりしたことがあれば理解しやすいけど、
条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
常にオーバーフローフラグを必要とするならそれもできなくなってしまう。
条件フラグをレジスタやメモリに一時退避させるコストもかかってくるんだよ。

いまどきのプロセッサは分岐予測も優秀だし分岐しない条件分岐命令は大してペナルティならねぇよアホか。

＞条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
＞そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
　
知らないこと想像で書いてて大変宜しいｗ

>>280
理解できていないようだけど、
演算命令の順序が固定かつシリアル化されてしまうことが大きいんだよ。
命令順序の入れ替えは最適化の基幹であるとともに、並列展開もできなくなってしまう。
さらに条件フラグの保存コスト問題も生じてしまう。

>>281
x86など使ったことある人には常識だけど、
条件フラグの更新を伴う加算と伴わない加算としてADD命令とLEA命令の使い分けをコンパイラも多用しているよ。
それ以前の演算で反映された条件フラグを変化させないまま、
LEA命令によって加算や一部の乗算及びその組み合わせ演算をできる利点があるためだよ。

実例挙げられない辺りが限界なんだろうなあｗ

>>284
実例を既に>>283で挙げたよ。
もしかしてアセンブラ使ったことすらなくて理解すらできなかった？

どのコンパイラがどういうコード吐いてるかも示せないで実例とか言ってるのはたまげたなｗ

ADDではなくLEAでフラグ変化させずに加算演算するのは手動でもコンパイラでも基本
この常識を理解できない低レベルな人はコード書いたりコンパイラ生成コードを見たことすらない人

コンパイラが出力した「条件フラグを変更せず保持したまま演算を行なう」コードの実例から逃げてるとこ見ると「LEAで加算ができる」が知識の限界の人かな

> コンパイラ生成コードを見たことすらない人
　
このスレでCompiler Explorerのアドレス貼ってる人は珍しくないので（>>150とか）同様にして見せてやれば良い。

Rust信者ってこんなもんだなあとういうのはまあ納得

Rust？
関係ないだろ

マシン語にするプログラミング言語は最適化によって意図と違うコードになることがあるという話をしたいんだろ。

> Rust？
> 関係ないだろ

>>275からの話の流れが理解できない人かな

>>275
このRustプログラムが最適化あり（リリースビルド）／最適化なし（デバッグビルド）で挙動が変わる理由は、i8型の符号付き整数オーバーフローの扱い方が状況によって異なるためです

最適化なし（デバッグビルド）
sum += numで加算の結果がi8の範囲（-128～127）を超えてしまうと、panicになるため意図した出力が得られず、エラーが発生します

最適化あり（リリースビルド）
オーバーフローのチェックが省略されて二の補数によるラップアラウンド（桁あふれの結果として範囲内に収める計算）が行われます

リリースビルド（最適化あり）でもオーバーフローを検出し、デバッグビルド（最適化なし）と同じ挙動にする方法があります

Cargo.tomlに以下を追記します：
[profile.release]
overflow-checks = true

リリースビルドでも整数オーバーフローが発生するとpanic（異常終了）になります

デフォで安全側に倒してない時点で残念言語だな

オーバーフローでプログラムを中断したいのか
オーバーフローをエラーとして返したいのか
オーバーフローを値として受けて活用したいのか
オーバーフローは影響しない処理なのか
一般的に様々な状況が考えられる
これは安全性の問題とは関係がない

> オーバーフローでプログラムを中断したいのか
> オーバーフローをエラーとして返したいのか
> オーバーフローを値として受けて活用したいのか
> オーバーフローは影響しない処理なのか
> 一般的に様々な状況が考えられる
　
話についてこれない人かな

>>298
オーバーフローをどう処理したいかはプログラミングの内容に依って変わる
これは安全性の問題ではない

オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ
何言ってんのこの人ｗ

オーバーフローは無視できる処理もあるし、オーバーフローが起きない場合もあるわけだから、そこはケースバイケースやろ。
状況次第としか。

生成コードで考えると
オーバーフローフラグが立つ演算命令1つ毎に直後にオーバーフローの有無で判断する分岐命令を必ず入れることになるがそれは効率が悪すぎる
しかも命令順序の固定化と直列化を招いてしまう
現在のCPUは命令順序の入れ替えと並列化で最適化をするからそれができないと劇的に遅くなる
不要なオーバーフローチェックは可能な限り避けるべき

>>290
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ

最適化のなしかありかで挙動の変わると言ったのが間違い
最適化でなくオーバーフローチェックのなしかありかで挙動の変わる
デフォで安全側に倒してないと言ったのも間違いでデフォでデバッグビルドを作って安全側に倒してオーバーフローチェックがある
劇的に遅くなるからリリースビルドのデフォでオーバーフローチェックがないのは妥当

配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ｶﾞｰ」と発狂してるのｵﾓﾛｲｗ
お前らRustも実行効率もなんも分かってないなｗ

配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能
さらにRustなどではシーケンシャルアクセスの場合にインデックスアクセスが使われないため安全性と実行効率を両立させている

> 配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項

オーバーフローチェックをやんなくて良い理由なんてないし。

> コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能

それはオーバーフローチェックも同様。>>275のコードなんてコンパイル時にオーバーフローするか判定できるわけだし。

＞配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
　
プログラムが完璧に作られてれば範囲チェックなんて要らんぞ？何言ってんの？？

>>308
本気で言ってるのかね？
範囲外アクセスでどれだけ多くのセキュリティホールを招いてきているか

配列などのメモリ範囲外アクセスチェックは必ずしなければならない。
その上でコンパイラが範囲内だと保証できれば最適化により範囲内チェックを省略する。
ミスを起こし得る人間がそれを判断してはいけない。

Cで配列などのメモリ範囲外アクセスチェックは必ずするかと言ったらしないよね？
「必ず」というのはそれを必ずするライブラリを使うということで
フリーの配列ライブラリなんてないよね？
配列ライブラリを使うならRustでいいと

>>311
そのためにC/C++は大量のセキュリティホールを生み出してきた
そんなことは許されない時代になった
C/C++はそれ以外にも多くの未定義動作など問題が多すぎるため使うべきではない

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国ホワイトハウスが開発者に対しC++やC言語からRustやJavaなどのメモリ安全性に優れたプログラミング言語への移行を勧める
https://gigazine.net/news/20240229-whitehouse-urges-use-rust-java/

配列アクセスでの範囲チェックは絶対必要だけどオーバーフローチェックはやんなくていいって言ってる人の頭の中ってどうなってるのかな?
オーバーフローに関してだけはプログラムが完璧に作られてるからありえないって思想?

実際の利用で最も多いシーケンシャルアクセスはインデックスの範囲チェックを消すことができる

for (i=start; i<end; i++) { a[i]利用 }
これはループ内でiの終端チェックとa[i]の範囲チェックの2回起きる

for (p=&a[start]; p<&a[end]; p++) { *p利用 }
このように書くかもしくはコンパイラが取り扱うと
ループ内でpの終端チェックのみになる
しかし人間が行なうとミスが入り込む余地があるため好ましくない

Rustなどはこれを抽象的なイテレータとして提供していて抽象化とメモリ安全性と実行効率の三つを両立させている

配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w

>>316
言語によって細かい区別や呼び方から実装方法まで様々に異なるため
こういう時に皆は抽象的に代表名として配列と呼んでいるだけだよ

その意味での配列を静的メモリ領域に置くこともあればスタック領域に動的に置くこともあればビープ領域に動的に置くこともある
そして静的であろうと動的であろうと場所がどこであろうと範囲チェックは必要

>>316
配列を必ず静的に確保する言語はレア
多くの言語は配列を宣言する位置によって動的確保がある

例えばC言語は関数内で配列を宣言すると関数呼び出しするたびに動的に配列を含めたローカル変数の領域がスタック上に自動的に確保される
静的確保ではなく動的確保であるからこそ関数の再帰呼び出しが可能になっている

くっだらねえ

>>316
静的メモリ確保の意味を理解できてないだろ
Cならグローバル変数とstatic変数が静的メモリ領域に確保される
配列もグローバル変数かstatic変数にした時のみ静的メモリ確保
そうでない普通の関数内の配列は動的メモリ確保

>>320
CやRustだと「普通の関数内の配列」にはスタックに置かれるものもあるんですが
要素数はコンパイル時に決まってる必要はあるけど

>>321
違いは簡単
静的メモリ配置　←アドレス固定
動的メモリ配置　←アドレス変動

static宣言すると静的にメモリ領域が確保されてアドレスが固定になる
実例コード

void foo() {
static int a1[] = {1, 2, 3};
int a2[] = {1, 2, 3};
printf("アドレス固定 a1: %p\n", &a1);
printf("アドレス変動 a2: %p\n", &a2);
}

void sub() {
foo();
}

int main() {
foo();
sub();
return 0;
}

>>316
>>321
staticの意味は「静的な」
staticを付けないと動的に毎回確保されることくらい分かりそうなものだが

なんてことだstatic宣言した変数が共有ライブラリの中だとアドレスが変わることがあるゾ！

>>324
リンク時に変わることはあっても
実行中にアドレスが変わることはない

cの静的動的はサイズが実行時に定まるか否かってことじゃないん？
staticかどうかはcプログラマにとっては別の感心事で
メモリの動静を語るときはそうだったと思うけど
俺の知ってる限り
staticつけてないローカルな配列のことを動的な確保って言ってる人見たこと無いわ

Grokに訊いたら非標準のallocaやC99のVLAは動的確保に含まれる場合があるそうだ。

配列やベクタやリストやスライスなど、言語によって様々な呼び方や実装が異なるもの、全てに共通の必須な仕組みとして、
総称としての配列の範囲チェックの話をしていて、そのまま特定の言語に関係なくこの話の流れでいいんだよな

>>316
>>配列は静的メモリ確保なのに動的メモリ確保とごっちゃになっている素人w

静的と動的は様々な対象に用いられるが、今回は静的メモリ確保
これをアドレスが変わらないという解釈でも、いわゆるセグメントのうち静的領域に確保するという意味でも同じ
特定の言語の話ではないが、例えばC言語なら静的宣言(static宣言)をする変数がこれに該当する

動的メモリ領域は毎回アドレスが変わるという意味でも、何かをするたびにメモリ空間から領域を確保する意味でも同じ
ただし二つに分かれて、関数呼び出しのたびに領域が確保されて関数から去ると無効になるものと、関数呼び出しのタイミングと関係なく確保することで関数を去っても有効になるもの、それら二つの異なる性質のものに分かれる
いわゆるセグメント領域としては、前者はスタック領域に確保されて後者はヒープ領域に確保される
前述の静的領域の変数とは異なり、スタック領域やヒープ領域に動的に確保することが共通の特徴であり、タイミングによってアドレスも変化する

>>317
コレクションという言葉を知らないのか？
配列は連続したメモリ領域だぞ？

>>320
あのさ、関数でも関数を呼び出す方でも実行時にメモリを確保するんだよ？

実行中にメモリを確保することは、また別の話。

>>328
CPUとOSレベルで別のプロセスが使っているメモリ領域にアクセスできないようになっていることを知らない高齢者か？

進化を知らずに大昔の仕様で語るのはやめろ。

連投が全て的外れでワロタ

>>329
元レスはコレクションとも連続領域とも全く無関係な話だな

>>330
区別ついてないのかよ
静的な変数が置かれる静的領域は関数呼び出しと無関係に最初から存在するため遅くとも実行開始時点でアドレスが確定する

>>331
元レスに別プロセスの話もアクセス権もどこにも書かれてなく無関係
そもそもプロセス間の共有メモリがある

>>332
元はメモリのアドレスをなめる行為の話だぞ？

飛び飛びのメモリ領域のことを一般的には配列とは呼ばない。コレクションの実装は飛び飛びのこともある。

このスレはキータだったなw
変なやつしかいない

>>333
コレクションの話なんかどこにも出てきていないのに妄想で幻で見えてるのか？

>>333
飛び飛びのメモリ領域の話をしてる人はいないと思いますよ
どうして突然そんなことを言い出すのですか？

『浮動小数点数に非常に小さい値を加えるとどうなるか？float型の精度限界を調べた』
　
知識がないところでFLT_EPSILONに近い概念を独自に発見しようとしてるのは偉いのだが、deltafの初期値を0.1fで始めてるのが惜しい。1.0fにしてればFLT_EPSILONの1/2が求まる筈。

>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。

簡単なコードで確認してみた。
https://wandbox.org/permlink/L8hZILgJIhDYqDkB

>>338 は32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない

unsigned charの8bit演算でoverflowしたら255にして
何回か毎に大きな値を引く(underflowは0)にする処理もあわせると分岐予測がある程度阻害されるのでは
(>>279 の具体的根拠は知らないけど)

＞32bitと大き目で更にoverflowしたらループを抜けるだけで代わりの値を代入したりしてない
　
1から4を1億回足してるだけだからオーバーフローは発生しない。>>279が問題にしてるのはオーバーフローチェックのコストでありオーバーフローするかどうかは関係がない。

実際のプログラムには足し算など無数にあるから分岐が無数に増えて分岐予測テーブルが溢れそう

Qiitaの話を全くしてないのは草

現実的には関数呼出になるから遅い…が、使いどころなんてたかが知れてるよな

結局こういうことだろね
現実と対応

303 デフォルトの名無しさん sage 2025/10/13(月) 02:39:47.42 ID:5mcGe2/B
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ

> そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ

危険を承知で`-Ounchecked`を指定しない限りオーバーフローチェックを行うSwiftが安全性については唯一まともな判断してるってことだよなあ。
https://godbolt.org/z/fMc6KdPb1

半開区間を長い左右非対称な記号で表わす話もSwiftが異端だったな
そこまでの行き過ぎた過剰を他の言語は求めていないのだと思われる

最適化指示でオーバーフロー検出が働くなるRustの仕様が適当かはRustの開発コミュでもたびたび議論になってることなのに「現行がこうなってる」で納得してるのは思考停止なんだよなあ。

Rustはプロジェクトを作る時にオーバーフローのチェックを強制したい方針ならばこの指定機能が何年も前に入ったため今は大丈夫だよ
overflow-checks = true

>>348
そういうの気にしない馬鹿のためにデフォルトの挙動はどうであるべきかって話が理解できない奴は安全性について語らない方が良いよ。

RustがIT各社に次々と採用されていってる理由は企業から見ても安全性が最も良い言語であると支持されたため

『🏆最小自由数で競う！C++, Lisp, Rust, Mojoによる速度対決🔥 / Competing on the Minimum Free Number! Speed Battle with C++, Lisp, Rust, and Mojo 🔥』
https://qiita.com/tj9999/items/4131016df5f1c5730584

「そのコードは良くない。こう書くべき」みたいな具体的なコメントができない辺りがRust信者の限界なのかな

このスレ見る限りRust信者はコード書けないみたいだしなあ

> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
> 劇的に遅くなることが判っているよ。
　
安全性よりパフォーマンスが重要と思ってる人は根本的なところから分かってない。

安全重視のJavaもオーバーフローチェックしないよ

もはや誰もQiitaの話をしていないのである

30年前の設計のJavaを安全重視と信じてる人がいるとはたまげたなあ

最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド

> 最近の言語Go Nim RustなどもCやJavaと同様にデフォルトではオーバーフロー時にラップアラウンド
　
C言語では符号付き整数のオーバーフローは未定義動作なんだがそんなことも知らない輩がなんか言ってなんだなあ。

デフォルトでオーバーフローチェックしなくて問題になった話を聞いたことがないな
世の中のシステムは問題なく動いているもんな
チェックしたければオーバーフローチェックできるから何が問題なのかわからん

255からエクステンドでゲームオーバーなんてザラにあるのにな

>>43
『VRでもリアル空間でもスマホでも！「sonoXR」での音楽体験を実現する先端技術・FPGA独自チップ』
https://note.com/mimylovesmusic/n/n0982c3323b50

↑の記事で当日の様子が紹介されてる。

> そのElixirChipですが、2025年9月17日、Elixir関連コミュニティのオンラインLT会で初お披露目されました！

> LT会のデモンストレーションでは、macの画面共有でElixirChipがターミナルから実行されている処理が映し出されて、その解説がメインのお話だったのですよね。
> それもそのはず。
> FPGA（Field Programmable Gate Array）とは「内部の論理回路をソフトウェアのように後から自由に組み替えられるチップ」のことだというのを、このLT会で今更ながら理解しました。（お恥ずかしい・・・）

> 私はElixirChipの開発を行う株式会社Digidock Consultingにてセールスエグゼクティブも担当しています。

FPGAがどういうもんだか知らなかった人がセールス担当で「先端技術・FPGA独自チップ」とか言ってんのスゲエな。

64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

2**64/(365.25*24*3600*10000000000) = 58.4542046091 だから59年目でオーバーフローするだろ。

8bit時代は一瞬で溢れたのに
64bit時代は凄いな

５９年に1回だけ出現するバグがすごい
毎年再起動で対応すべき

最新のCPUでも10GHz行かないので1秒間に100億回のカウントが無理だよな
オーバーフローするまでもっとかかる

フィボナッチはオーバーフローする

オーバーフローチェック関数を呼び出せばいい

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こういうマヌケが今後もいなくなることはないからオーバーフローチェックは常に行うのが安全。

溢れないんだからチェックは無駄じゃん
だから昔からチェックしない言語が使われてるんだろ
文句があるならここで暴れずに各言語に公式に言えばいい

Rustは多段階に対応しているよ
デフォルトはデバックモードになりオーバーフロー含めた様々なチェックが充実
プロジェクト毎に常にオーバーフローチェックをする指定が可能
オーバーフローを扱う関数も多数あり

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こういうマヌケはプロジェクトにオーバーフローチェックを行う指定なんてしないしオーバーフローを扱う関数を呼ぶこともないんだよなあ。

安全性の対策ができるかどうかが重視されている
安全性の対策のためにRustは次々と採用されている
対抗できるプログラミング言語が他にないからね

Rustを使えば安全という勘違い

Rustに勝てるプログラミング言語がないんだよ
だからこそIT大手がこぞってRustを採用した

○bitまで演算できるから大丈夫
だったのが、整数型をオーバーする●年問題とか起きたんだよ
そして今度は◯bitまで使えるから安心と結局は同じ事を繰り返してるだけ
なのに「ずっと使い続けても大丈夫」とか言えるものなんだな

それプログラム言語で勝ちとか
何が言いたいのだか

>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。

> 劇的に遅くなることが判っているよ。

このスレのRust信者はコードが書けない馬鹿しかいないのでオーバーフローチェックのコストとやらがとんでもなく高いことの例示すらできないんだよなあ。俺が代わりに確認してやったぞ。

最適化レベル3 オーバーフローチェックなし(-Copt-level=3)
https://wandbox.org/permlink/Lqo6PEO1lj23qeVx

最適化レベル3 オーバーフローチェックあり(-Copt-level=3 -Coverflow-checks=yes)
https://wandbox.org/permlink/U5IYMurSn4jMq9rP

>>378
コードを書けないのはおまえだろ
その出力結果を見ろよ

999999999 0.000000 sec.

> コードを書けないのはおまえだろ
> その出力結果を見ろよ

何が起こってるか分からんとこういう反応ｗ

実行時間0秒ということはコンパイル時の定数化だろうね
コードを正しく書けない人が定数データをそのまま使って正しくベンチマーク計測できていない典型的な失敗例

>>379
>>381
「とんでもなく高い」と>>279が言ってるオーバーフローチェックをコンパイル時にやれてることが理解できない低能ｗ

比較ベンチを測るプログラムでコンパイル時に定数になってしまってるのは初心者あるあるでちよっと恥ずかしい
さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ

> さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ

コスト0でできるオーバーフローチェックの例を挙げただけだけど馬鹿だとこういう理解になんのなｗ

連投クンは3つの過ちを犯している
①実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
②その結果をもってコスト0だと主張
③その事例をもってオーバーフローチェックは重くないと主張

> �@実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった

オーバーフローチェックのコストの話だからコンパイル時にできるんなら御の字なんだよなあ。

> �Aその結果をもってコスト0だと主張

俺が挙げた例ではその通り。

> �Bその事例をもってオーバーフローチェックは重くないと主張

オーバーフローチェックの重い例はIDコロコロ君が挙げりゃ良いのにｗ

馬鹿って本気で馬鹿なんだなあという感想しかないわｗ

定数の同士の計算をコンパイル時にできるだけでしょ
普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ

> 定数の同士の計算をコンパイル時にできるだけでしょ
　
同じコードで「最適化レベル3 オーバーフローチェックなし」では定数の同士の計算をコンパイル時にできていないので場合による。rustcは最適化が控えめなのでオーバーフローチェックを行ったほうがデータフロー解析を深いレベルで行なって効率良いコードを吐いてくれる可能性まである。
　
> 普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
　
できる場合もあればできない場合もある。
安全性を蔑ろにして良いわけはないのでコンパイル時にできないのであれば実行時のオーバーフローチェックは行うべき。そのコストが問題になるのであればプログラマがオーバーフローしないことを保証してやれば良い。

言い訳ばかりだな
オーバーヘッドを比較するための実行時間ベンチマークで
まともなプログラマーならばコンパイル時定数になるコードを書かない

コンパイル時にオーバーフローチェックされた例が余程悔しかったと見えるｗ

つか何で
　
> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
という具体的を提示しないんだろうか?

>>379
実行時間を比較しようとして定数計算で実行時間0.000秒は草
それをそのまま貼るのは慌てん坊

最適化レベル3 オーバーフローチェックなし
https://wandbox.org/permlink/LOcWoipF2aESW8HO
> 999999999 0.000000 sec.

最適化レベル3 オーバーフローチェックなし
https://wandbox.org/permlink/BcHSm4UljxoF26fp
> 999999999 0.192019 sec.

なるほど、確かに最適化控えめだなｗ

> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
clangより遅いRustがますます遅くなっちゃうってことか。
でもそれで安全性と天秤に掛けて安全性捨てて良いって理屈にはならんと思うが。

Rustはオーバーフローに関しても最も充実している言語
まずデフォルトではデバッグモードとなりオーバーフローを含めた様々な問題をチェックして指摘してくれる
次にオーバーフローを取り扱う関数が30個以上と充実しておりオーバーフロー時に様々な対処ができるようになっている
さらにオーバーフローチェック強制モードを指定することもできる

肝心のユーザーが
　
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こんなこと言ってるようじゃせっかくの機能も台無し。
こういうユーザーはオーバーフローを軽視しているので、それを扱う関数を呼んだりオーバーフローチェック強制モードを指定することもしない。

Rustより優れているプログラミング言語がなく出現しそうにない
IT大手をはじめとして各社が次々とRust採用に踏み切った理由

何をもって優れてるというのか知らんけど
採用される率だったら圧倒的に Python や JavaScript じゃないの？

普及している言語を採用するのは当たり前
普及してない言語をわざわざ採用するのは他の言語では代わりにならないほどメリットがある時

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

この程度の実行時検出もできなくて「メリットがある」と言い張ってて草ｗ

見ていてなんとなくわかってきた
プログラミング言語として敵わないからよくわからない言いがかりをつけてずっと粘着しているだけのような

言語の優劣（笑）にこだわってる子が一人だけおるっていう状況かな
自己のアイデンティティを借り物で満たそうとしちゃってるね
自分がRustの作者ってんならともかく、単なるユーザでしかないのにね

>>395
オーバーフローに関してそこまで充実していない言語も多いけど、なぜか充実している言語の方をしつこく叩いてるコンプレックス持ちがおるから面白い。

安全性分かってない奴がRust盲信してて笑われてるだけｗ

>>52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ
　
IDコロコロ君安全性は屁のように考えてるみたいだけど、だったら配列アクセスのたびに範囲チェックで無駄なコスト払ってるRustは良い言語ではないんじゃね? それかunsafeでポインタアクセスするのが正義?

安全性のためにRustを採用するところが世界的にどんどん増えているのはなぜだろう？

Rustの普及と
　
> 安全性などはついでのオマケ
　
とか言っちゃう馬鹿が笑われてるのは別の話だゾｗ

>>405
Rustは配列などのアクセスもゼロコスト抽象化で速さと安全性を両立してるよん

>>408はrustcの出力見たことない人かな?
配列の範囲チェックって

https://godbolt.org/z/6johWYEce
> cmpq %rsi, %rdx
> jae .LBB0_7

↑がそれ。

ちなみにCだとこんなだ。
https://godbolt.org/z/3q4rv8P3M

rustcが最適化控えめという話は既出か。

rustc
https://godbolt.org/z/4T5Wha7M3

clang
https://godbolt.org/z/j9r59Pv9q

C言語は、ポインタが、ヤバイくて、危ないよね。
RUST言語は、ポインタが、無いのなら、安全ぢゃねえ?

>>402
マジでこれ
関数型言語あたりに多いけど、自分が好きな言語をアイデンティティにしてる奴にまともなのはいない
自分は何を作れるか・何を作ったかの方がプログラマにとっての価値だろ

個人開発ならともかく、仕事で使う言語は自分の好みじゃなくて組織によって決まるものだよね
Rustが好きでも、Goのプロジェクトに入ったらGoを書く、Javaのプロジェクトに入ったらJavaを書くのがプロ
宣言的なコードが好きだからといって、OOPの言語や、for文 と if文 をひたすら書かされる言語では仕事したくないです、なんてのは社会人としてだめでしょ
(Rustを使える企業に転職する、という選択ができる人は別だけど)

企業や立場によってピンキリだよ
そういう歯車として使われる人もいればそうでない人もいる

どの分野でもAとBの比較の話をしている時に同じことが起きてるな
純粋にそれぞれの特徴やメリットで優劣を比較すればいい
ところが不利になった側はどの話でもこう言い出す
Aを使うやつはXXXだ！Aの価値よりおまえの価値はどうなんだ！
AとBの比較から逃避して人間の攻撃を始める

なんか話がズレまくってるなここ

> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
　
とか
　
> 安全性などはついでのオマケ
　
とか言ってる人は根本的なところがわかってないので言語を選定したりプロジェクトを先導する立場に立たせてはダメ。

安全性と速さの両立が最重要だもんな
利害対立し合うIT大手企業が珍しく揃ってそのために選択したRustを用いるのが正しい

> 安全性と速さの両立が最重要だもんな
　
↑馬鹿発見ｗ

安全性と速さだけではダメ
高い抽象度で読み書きしやすいことが大切
Rustはそこを満たしたからこそ新たな移行先になった

>>411
Rustもポインタが使えるし場合によっては危険。
https://godbolt.org/z/7TPGs1xsr

>>421
生ポインタの指す先を読み書きできるのはunsafe Rust
unsafe RustではC言語と同じ状態という点で危険だが普通のプログラミングでunsafeを使うことはない

言語の良し悪しを語ってる時点で草なんよね
だって俺らは与えられた言語で仕事するだけだから
C++でもPerlでもPHPでも書くだけだから
You play with the cards you're dealt.

>>423
IT土方は仕事を選べないもんな

はい（真顔）

土方が無理に言語の優劣の話にクビを突っ込まなくてもいいけど
新たな優秀な言語が出現したチャンスと捉えて習得して土方を脱出する手もある

> 普通のプログラミングでunsafeを使うことはない
　
と言ってる人はunsafeが使われてる標準ライブラリも使わないのかな?

>>427
それは真逆だよ
Rustでunsafeが使われるのは標準ライブラリの内部やそれに準じる基盤クレートの内部
普通のRustプログラミングでunsafeは使われない

> 普通のRustプログラミングでunsafeは使われない
　
ああ低レイヤに縁のない人か

低レイヤの意味は複数あるけど
いずれも可能な限りunsafeは使われないね
効率面でunsafe必要になるパターン一般化されてプログラムの外部へ切り出されてライブラリ化されるよ
そうしてできたのがRustの標準ライブラリ

画像処理でピクセルを走査するようなケースだと unsafe なポインタ操作は必須じゃないの？
インデックスアクセスだと範囲チェックのコストがかかるし
単に1画素を1画素にマップするだけならほぼノーコストでイテレーターを使えるだろうけど、周辺画素を参照する操作もよくあるから単純なイテレーターは使えないし

あとはCとのFFI
過去に書かれたC/C++資産の利用はRustでやりたいことの一つだろうし、これは流石に標準ライブラリのような「一般的なユーザーは使わない」ものでは無いと思う

Rustのunsafeは他の言語と同じ様の状況になりますよという意味で、コンパイルが通っても安全性を保証しませんという意味。
つまり他の言語と同様に、unsafeな部分の安全性は人間が保証してください、がRustのunsafe。

したがって他の言語とリンクする場合にその境界部分がunsafeになるのは当たり前でこれを避けることはできない。
しかしパターン化できる場合はunsafe使用部分をライブラリの中に閉じ込めてそれを安全に用いることもできる。
例えばPythonのライブラリをRustのPyO3クレートで作成する場合など。

低レイヤに縁がない人がオーバーフローチェックを否定してるのがわけわからんのよねｗ
低レイヤ担当は色々手段を尽くして実行効率が良くて安全なものを提供してると思うんだけどそれに乗っかってる側は自分が書いてるコードの実行効率を気にするよりは安全性を重視するべきではないの?

また言語の話で不利になったため逃げて、
妄想上の人の話へとすり替えようとしてる

もうQiita関係ないな

IDコロコロくんは面白いなｗ

せやな

『Cから学ぶRustの良さ』
　
3年前に書かれた記事だがトレンドに挙がってたので初めて見た。
酷い記事だなあ。なんで90人もいいねしてんの?

>>439
C/C++は弱い型付け言語なのでサイズの異なる型への自動変換が起きることに加えて8bit環境以外では
Cでは sizeof('a') == sizeof(123)
C++では sizeof('a') != sizeof(123)
などの無茶苦茶な仕様が混乱に拍車をかけているよな

AIに聞いたら聞き返された
もしよろしければ、あなたが特に「酷い」と感じた記事の具体的な内容や論点について教えていただけますか？
それについて、Rustの技術的な視点から掘り下げて解説することもできます。

ChatGPTに

> この記事読めますか? https://qiita.com/uv_ussy/items/71248bdd081089b7ba09

> 前述の記事には誤りと思われる個所が複数あると思います。気が付いた点があれば挙げてみてください。

と訊いたら

> 確認できた範囲で、記事「Rust と C の比較（著：ushijima ryosuke／uv_ussy）に 誤りまたは誤解を招きやすい記述 がいくつかあります。いくつか挙げますので、もしよければさらに掘り下げましょう。

と言って気になった点というのを 5点挙げてくれたけどな? >>441はどういう聞き方したんだろう?

>>442
レスの全文を正確にコピペしただけ
AIに聞いた質問は誤りと思われる個所を探すことでない
レスをよく読んでみてね

>>443
俺はお前が「AIに聞いたら聞き返された」って馬鹿なこと言ってるから面白がってるだけよ?

> レスの全文を正確にコピペしただけ

アドレスも貼らんでAIが理解してくれるって認識かｗ

>>440
CとC++で色々と違っているのを知らずに誤解する人多いよね

>>442
Rustの問題ではなくて
Cの問題点と不備な点と間違えやすい点に加えて誤解してる点と間違ってる点のフルコースの記事だね

> C/C++は弱い型付け言語なので
　
それはそう。
　
> サイズの異なる型への自動変換が起きることに加えて
　
サイズの同じ異なる型への自動変換もあるからサイズ関係ないぞ。件の記事はなんでかサイズで説明してるが。
　
> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
> C++では sizeof('a') != sizeof(123)
> などの無茶苦茶な仕様が混乱に拍車をかけているよな
　
件の記事ではCとC++の仕様の違いについて言及してないね。「8bit環境以外では」も意味不明。結論的には>>440はバカ。

Cの時点でぐちゃぐちゃなのにC++が互換性を持たせずに変えてしまった部分だからめちゃくちゃになってるところ

>>439の記事の筆者名検索するとFaceBookのページ出てくるけど国立大学で情報工学専攻でこれというのはいろいろ考えてしまうな。

IDコロコロ君はRustスレにも迷惑掛けてるのかｗ
もう自分を迷惑な人材として認識しておとなしくすりゃ良いのにねｗ

12月1日から25日まで、みんなで技術記事を投稿して、カレンダーを埋め尽くそう
qiita.com/advent-calendar/2025
完走チャレンジ賞の達成条件は以下です。
・1人で15～24記事投稿した方を表彰します。
プレゼントカレンダーは2025/10/31～2025/12/31に記事を投稿
期間が2つある

>>447
それが意味不明で分からないなら馬鹿はお前の方では？

『stdio.hやiostream.hの中身を見る方法』
　
/usr/include/ かINCLUDEが指してる先見に行った方が早くね?

> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
> C++では sizeof('a') != sizeof(123)

8bit環境に限っては↑のようにならないとでも言いたげだがC言語では'a'の型はintなので
sizeof('a') == sizeof(123)
は常に1となる。
C++では'a'の型はcharなのでcharのサイズがintと同一な環境でもない限りは
sizeof('a') != sizeof(123)
は常にtrueとなる。C++は規格としてintのサイズは最小でも16bitあるから仮にcharのサイズがintと同一の環境であれば
sizeof('a') != sizeof(123)
はfalseとなるが>>440が言ってる8bit環境とやらはcharのサイズが16bitあるのかな?
結論的には>>452もバカ。

そういう基本的な部分でCとC++の扱いが違うなんて失敗言語だよなあ

C++では'a'の型はchar
知らんまま書いとったわｗ

『データ構造入門(1) - ポインタ・配列・構造体』
https://qiita.com/juna1013/items/406723a90ceeff3b04a9#comment-336c986ee3daed589a0f
> 学習のためなら、一度はコンパイルして実行した方がよいと思います。
> C++ならコンパイルエラーになってくれます。

コンパイル確認しろはその通りだがCのタグついててC++のタグはない記事のコードになんでC++でコンパイルなんて言うかなあ?
>>455 同様CとC++が違う言語と認識できてない人かな。

>>457
int genderに"man" や"woman"を入れようとしてるんだぞ
エラーにする言語が正しい

CとC++が違う言語と認識できてない人が早速現れたｗ

>>459は誰に対して言ってるんだ？

CでもC++でもint genderに"man" や"woman"を入れるべきではない
エラーにできない言語を使うべきではない

C言語でポインタ値をintのオブジェクトに代入するべきでないという話はCの規格やコンパイラの吐いた警告で説明できるのだしルールも異なる他の言語引き合いに出す意味はないんだよなあ。
また、C言語は使うべきでないという個人の主張はC言語を学ぼうとしてるQiitaの記事とは関係ないから他所でやるべき。

Cコンパイラしかない組み込み用CPUを使う場合しかCを使う機会ないよな
ほとんどの人にCは不要という現実を教えてあげたほうがよい

>>463は主要な部分をCで組まれたLinuxも使わないで済む世界の住人かな

現在LinuxのカーネルモジュールはRustで書くのがメインとなってるよ
カーネルコアはCのままだけど我々がコードを書く部分はカーネルモジュール

> 現在LinuxのカーネルモジュールはRustで書くのがメインとなってるよ
> カーネルコアはCのままだけど我々がコードを書く部分はカーネルモジュール

馬鹿なこと投稿する前にAIに「LinuxのRustの導入ってどれくらい進んでるの? 」とか訊いたら良いのにねｗ

Linuxの新たなカーネルモジュールはRustで書かれるようになったな
カーネルモジュールのせいで落ちたりセキュリティホールになることを嫌って新たなものから安全性の高いRustで書くことになった
カーネルモジュールの一つであるデバイスドライバもRust製へ

rustきっしょいライブラリやめてC++みてえなのに置き換えりゃいいのに

Rustはgithubにある面白そうなリポジトリでgit cloneしてビルドしてみると外部クレートでビルドが失敗するパターンが多くて損してる希ガス。
Rust開発チームの方針なのだろうけどよく使われるライブラリは保守まで組織的に面倒見る体制は必要だと思う。

>>469
Rustはバージョン管理がしっかりしてるからビルド失敗に滅多に出逢わないよ
バージョン指定していない古いexampleでコンパイルできなかったことがあるくらいかな
具体的に何が失敗したの？

>>470
chatgptに訊いてやったからあとは自分で調べてね。
　
> あなた:
> githubにあるRustで書かれたリポジトリで外部クレートが原因でビルドが通らない問題ってstackoverflowとかで質問に上がることってありますか?
> ChatGPT:
> はい、かなり頻繁にあります。
> Rustのプロジェクト（特にGitHubで公開されているオープンソースのもの）では、外部クレート（依存クレート）に起因するビルドエラーは非常に一般的で、Stack OverflowやGitHub Issuesなどでよく質問・報告されています。
(以下略)

RustはCargo.tomlでversionなど指定していれば古い昔のものでもコンパイルが通る。
指定してなければ最新のversionのものを使おうとするからコンパイルの通らないことが起きる。
ここまでは外部クレートのせいではなくそれ自身の問題。

ChatGPTは依存クレートに起因するビルドエラーの原因を複数挙げるけどこれで論破したつもりかな？

>>469の質問の後、>>471の「Rust開発チームの方針なのだろうけどよく使われるライブラリは保守まで組織的に面倒見る体制は必要だと思う。」も入力すると今のRustの抱えてる問題詳細に語ってくれるなｗ
「Rustはバージョン管理がしっかりしてるからビルド失敗に滅多に出逢わないよ」とは何だったのかｗ

> >>469の質問の後、>>471の
　
>>469と>>471逆だったわｗ

Rustのよく使われてるライブラリなら現実に問題が起きていないから妄想を語っても意味ないかと。

IDコロコロ君Rustスレでは複おじと呼ばれてて「もはや一周回ってRustアンチまである」とまで言われてるのは草ｗ

相当昔だけどいくつかのproc_macroが意図せず公開されていたsynのプライベートアイテムに依存してて
synがしれっとバージョンアップでパスを消して以降ビルド通らなくなるみたいなことはあった
https://github.com/nushell/nushell/issues/2867

>>478
synが内部でproc_macro2のTokenStreamをTokenStream2として用いていたものなどが外にも見えてしまっていて、正常に見えなくしたら、それを使ってしまっていたところが影響だね。
docには公開していなかったから、たとえ偶然見えてるものでもdocになければ使わない、が教訓だろうか。

> Rustのよく使われてるライブラリなら現実に問題が起きていないから妄想を語っても意味ないかと。

chatgptに訊いてみた。
「githubにあるRustで書かれたリポジトリで外部クレートが原因でビルドが通らない問題ってstackoverflowとかで質問に上がることってありますか? よく使われてるライブラリなら現実に問題が起きていないとも聞きますが本当?」
「現実に問題が起きていないと問題が少ないは違う話だと思いますがよく使われてるライブラリなら現実に問題が起きていないというのは本当?」

> 結論から言うと：
> 「よく使われているライブラリなら現実にまったく問題が起きていない」――これは厳密には“本当ではありません”。

事例を出せないで言いがかりはよくないと思うよ。

> 事例を出せないで言いがかりはよくないと思うよ。

ChatGPTに訊くと具体例ずらずら挙げてくれるのは無視ｗ

出せば一番話が早いのに具体例を挙げられないままグダグダしてる場合は具体例が無い時
経験則からほぼ間違いない

経験則から言えばﾜｯﾁｮｲ付いてるとほぼ寄り付かなくなるのでおすすめ

『Rustの並行処理』
並行処理と並列処理の違いも理解してない感じの記事。
複雑な処理というのをsleepにしてるせいで更にわけわからんことになってるなｗ
Rust信者が程度低いのはデフォなのでまあこんなもんかｗ

見てないけど並行処理は通信待ちなど待ちがある時に有用
計測などでその待ちを並行処理のsleepで代替することは一般的に行われている

見ないでトンチンカンな投稿はしないでいいんだゾｗ

>>485
はじめに　だけ見てゲンナリしたわ

ひとつの記事に「並行処理」と「並列化」が並んでて、違いを説明してるわけでもないのは本気で分かってない感じ。
コメ欄での指摘の一つもないのはQiitaでのRust勢の程度を顕しているな。

Qiita Conference 2025 Autumnって聴いた奴おる?
ツイッタみても反応らしいのないんだよなｗ

タイトルが並行処理
しかし並行処理のコードはない
この時点で誰も相手にしないのだろう

並列処理で効率を上げたいならこの例とは逆に可能な限り可変データの共有を避ける
例えばエリア分割が可能な場合はその分割や並列化を自動的にしてくれるrayonクレートが便利だ

Qiita Conference 2025 Autumnゲスト講演の人

『今のコンピュータ、AI にも Web にも 向いていないので 作り直そう!!』
https://speakerdeck.com/piacerex/jin-nokonpiyuta-ai-nimo-web-nimo-xiang-iteinainode-zuo-rizhi-sou

相変わらずデッタラメなこと言ってんなあｗ
素人に「なんかすごそう」と思わせれば勝ちって商売かな?
Qiitaも技術的正確性問わない方針は良いんだけどさ(良くないけど)、こんなのに発表の場与えてると詐欺の片棒担ぐことにな

>>492
マクドナルド理論かな？
乗ってやるのめんどいからスルーや

重くて遅く効率の悪いElixirを捨ててRustを使えばいいのに

フォンノイマンボトルネックが諸悪の根源みたいな説明してるけど３８６辺りの時代から知識のアップデートしてない感じだなあ。アイドル状態でも４０％近い電力消費ってのもいつの話してるのって感じだ。
「ノイマン型でも」「ＡＳＩＣ／ＳｏＣ／ＦＰＧＡ化は有望」って、ＳｏＣがどういうものだか分かってないなｗ

現役ＣＰＵを上回るＦＰＧＡ版ＥｌｉｘｉｒＣｈｉｐってページ（３６ページ）が一番酷い感じ。
Ｗｉｎｄｏｗｓが動くと思えないＥｌｉｘｉｒＣｈｉｐでｐａｓｓｍａｒｋスコアをどうやって計測したのか謎だし、x４でスコアが６倍近くなってるのわけわからん。
Ｘｅｏｎ Ｓｉｌｖｅｒ ４３０９Y比較で電力９９．９２%削減てあるけど１０５W→３．７Wだから９６．５％が妥当だなあ。どういう計算してんの？
つか省電力アピールしたいんだったら比べるべきはx８６じゃなくてＡＲＭじゃね？
このスライドはデタラメですよを精一杯アピールしてるなｗ

桁違いにクソ遅いElixir言語を利用前提の比較だからな
既存のCPUでElixir使用よりElixirチップが速くなったと主張しても意味がない
普通の速い言語との比較がいつも見当たらない

Elixirを高速に動かすチップを作るんじゃなくて、BEAMのバイトコードをHDLに変換してFPGAで動作させるようなこと考えてんだと思うけどね、まあうまくいかんだろうな。

ElixirはErlangと同じく遅くてメモリ消費も多くメリットがないため採用されない運命

全角おぢ現わる！

> 全角おぢ現わる！
　
Rustスレでは複おじと呼ばれてるIDコロコロ君は面白いなｗ

>>492
その人のqiitaの過去の記事でElixirが他の言語より有利な点をいくつも挙げているけど、興味深いことにRustと重なる点が多いんだよね。
そして後発のRustがGAFAMなどIT企業に採用されていったから、挙げられていた有利な点自体は正しいのだと思う。
両者の違いのうち最も大きな相違点が実効速度だから、FPGA利用で速くするという方向性もElixirに拘るなら正しいのだと思う。
実際にRustより速くなるのかどうかはデータがないのでわからないけど。

ElixirとRustとGAFAMを同時にディスるとはさすが

ElixirはGC言語かつ値がimmutableで書き換え不可
どうしてもゴミを撒き散らして遅くなりメモリも喰う点で致命的な差がある

まだエリクサーにこだわる奴がおるんやな

100人中99人に相手にされなくても残りのパイで商売できると思えばそりゃいるわｗ

>>502
> そして後発のRustがGAFAMなどIT企業に採用されていったから、挙げられていた有利な点自体は正しいのだと思う。

Rust:
2006年 Mozillaの開発者Graydon Hoareが個人プロジェクトとして開発を開始
2009年 Mozillaが公式に支援開始
2010年 Rust発表
2015年 バージョン1.0リリース

Elixir:
2011年 José Valimによって開発開始
2012年 バージョン1.0リリース

RustとElixirの特徴が被ってて後発の方が優れているという主張であるならGAFAMが採用すべきはElixirということになるが実際は違うので>>502の言ってることはデタラメ。

Elixirの最大の長所は軽量プロセスによる高い並行処理能力
Rustでこれに対応するのは非同期タスクによる高い並行処理能力

2015年のRust 1.0以前は非同期タスクは存在しなかった
2016年からFutureによる非同期タスクが標準ライブラリの外で始まるが2018年に互換性なしの変更など良いものへ洗練されていった
2019年にFutureが標準ライブラリに入り安定化しasync/await構文も導入

>>507
その比較で重要なことが抜けている
「2019年 Rustが非同期のためのFuture安定化とasync/awaitを導入」
そこから非同期を必要とするWebなどの分野でRustが他言語より優位に立ち採用が広まっていった

自分でどんな理由でどう使ってみてどうだった
とかじゃなく宣伝文句とドコが採用したからすごい
ばかりでバカバカしい

『Elixir(エリクサー)で数値計算すると幸せになれる』
https://qiita.com/zacky1972/items/c13706fa3f7bbf2b791b

記事中に引用されてる『Hastega: Elixir プログラミングにおける超並列化を実現するための GPGPU 活用手法』というpdfで、提案してるElixir+Rust+GPUの方法に対してRust+GPUと比較して、

> 提案手法は GPU を使用するネイティブコードと
> 比べ，1.48〜1.54 倍遅くなっただけである

とか言ってて草ｗ
Elixir使って不幸になってる例じゃねぇかｗ

sho_fcafeが痛すぎる

>>492
めっちゃ文系やな

>>509
ほんそれ

>>509
rust信者は技術者じゃなくて
rust応援団だからｗ

使い方間違えなければ良い言語なんだろうけど、狂信的信者が何にでも使える万能であるとか言ってるのがRustもElixirも残念な感じ。

言語なんてのは用途に応じて使い分ける道具のようなもの
それが分かってる人は場面に応じてフォークとナイフを使い分ける
それすら分かってない子はフォークとナイフの優劣を熱弁する
〇〇応援団になって
〇〇の万能性を説くことになる

ElixirChipの人の会社の会社概要にある住所ぐぐるとコワーキングスペースみたいの出てくんのちょっと面白いなｗ

ゼロから始めるマイコン�E-1
　
puts(sum); ﾜﾛﾀｗ
何を伝えたいんだこの記事は。

>>518
職安の訓練でやり始めた爺が投稿してる雰囲気やなあ…

これに限らずコンパイルすらしてねえやろって記事を
平気で出してくるメンタルおかしくない？
コンパイルとか
実行とか
プログラミングとか
そこすら理解してないような怖さを感じる

>>518
リンクぐらい貼れ
https://qiita.com/FOURTEC-LABO/items/cf37aef13720b6941e36

『“見えてるけど見えてない”メモリリークの実体と 5 分で防ぐテクニック』
https://qiita.com/K3n_to_n17/items/cbd8f1022c37371d6e52

GCのない言語とある言語ではメモリリークの原因や対処方法も違うしひとつの記事で説明しようとするのは人間の発想ではないよなあ、AI生成かあ?
と思ったらNucoかあ。まだこんなことやってんのね。

Nucoの記事は基本的にAI生成
ひどいものだと前年にインターンが書いた記事を丸コピなんてものもある

Elixir大先生の『2024年1〜3月の研究目標の達成状況ふりかえり』（https://zacky1972.github.io/blog/2024/03/29/refrecfion.html）とやらに

> ・Elixir DSA (Elixir Chip) の基本原理を特許出願しました(特願2024-020268「情報処理装置、命令並列実行方法及びプログラム」2024年2月14日出願)．

とあったので特許情報プラットホーム（https://www.j-platpat.inpit.go.jp/）で検索してみたら特開2025-124310として公開されてたわｗ
Elixirの軽量プロセスに影響されたのか実行装置の数より多くのプログラムカウンタを用意して動作できるものを動作させてなるたけ実行装置の待ちを作らない発明なのかな。
正直これで性能出すのは大変だと思うけど面白いので頑張ってほしいわｗ

要はハイパースレッディングだろ

えーとつまり特許出願で箔を付けたいわけだな
使い物になるモノを作ってから出直しな

『C/C++でAPIを設計する際に避けて通れないABI互換性の問題』
　
C++でextern "C"しないで引数型の違う関数が呼び出せる理屈が分からんのだけど俺なんか勘違いしてる?

名前マングリングに触れるべき記事ではあるな

uint64_tの引数をスタックや32bitレジスタ2個で渡すABIは普通に存在するし記事のコードが動くかは環境次第よな。この記事書いた奴uint64_tもuint32_tもレジスタ1個で渡す想定をしてるみたいだが。
つかコイツABIの意味分かってないわ。

たまたま
きんきん
うごいただけ

> ABI（Application Binary Interface）互換性は常に気を配るべき重要なテーマです。

とか

> FFI(Foreign Function Interface)の観点からは、

とか言ってるけど理解して言ってる気がしない。

こういうクソ記事に諭してくれる人もいなくなった辺り、サービスの衰退を感じる

ULARGE_INTEGER とか LARGE_INTEGER とか FILETIME とか
union で QuadPart にアクセスしてる造りですが
endian は気にしなくても大丈夫なんでしょうか

『レベル1の遊び人が、好奇心だけ持って42Tokyoダンジョンに一年こもったら「仲間と学ぶ」というつよつよスキルを少し覚えた話』
https://qiita.com/ijoja/items/ab3070490d0db3fc2ecd
> 独学限界組に届けたい。質問できる環境があるだけで、人はとんでもなく伸びる（42Tokyoでの1年）

> 再帰関数で感じた“理解のブレイクスルー”

「つよつよスキル」「とんでもなく伸びる」とか言ってて再帰関数の理解がそれかあ(ｽﾞｺｰ

少し

一年こもって少しかあ(ｽﾞｺｰ

一週間に一度見れば十分なスレ

『IT業界に携わる皆さんへのアンケート（卒業論文用）』
　
アンケートの告知ってガイドライン的におｋなのかな?

https://qiita.com/risarisa0209a/items/08ad2900f10995e3642c
これか
タグがデタラメだからその線で通報するとよさそう

>>534
大海を知らずw

42tokyoってスクール、学費タダで入学試験が難しいのをウリにしてるからか入った人は変な選民意識があるみたいね。

ものの見事に選ばれた賎民であることは間違いない

死に東京

『C言語のメモリ周りの話がいかに簡単かという話』
　
CもPythonもよく分かってない人の書いた感じの記事。
記事中に頻出する「仮想記憶」が分かってない感MAXでジワる。

>>544
リンクくらい貼っとけ
https://qiita.com/IMattheZOO/items/a1658c2fefec15e565a8

基本情報は役に立たないが合格すらできねえやつも役に立たねえってあれだな仮想記憶云々

記事の文章ではintは8バイトと説明しているのに図では4バイトで説明してるのわけわからんな。
図はどっかからの借用か?

「こんな書き方をすると最悪プログラムが落ちます。」と言ってる例、コンパイル通るわけないので落ちることもないなあ。どうしてこう自信満々なんだ?
main()の型voidにしてるコード他にもあるけどコンパイラの警告も見てないのかな?

> 冒頭でも少し触れましたが、python等の真新しい言語の多くは仮想記憶自体をプログラマに意識させないような設計思想を持っています。その結果、言語仕様をどう理解すればいいのか路頭に迷ってしまうことがあります。
> 例を挙げます。
>
> array.py
> arr=[1,2,3]
> arr_copied=arr
> arr_copied[0]=4
> print(arr) #[4,2,3]
> この動作は、仮想記憶というデータモデルを知らないと異様に見えるのではないでしょうか。

誕生して30年以上経つPythonが真新しい言語かは兎も角として仮想記憶関係なくね?
https://wandbox.org/permlink/WSHSwOFRjc73EcXg
#include <stdio.h>
int main(void)
{
int* arr = (int[]){1, 2, 3};
int* arr_copied = arr;
arr_copied[0] = 4;
printf("[%d, %d, %d]\n", arr[0], arr[1], arr[2]); //[4, 2, 3]
}

あくまで個人の感想だからいいんじゃね

qiitaは最早AI量産のゴミの溜まり場

真新しい言語わろた

『Brainf**kの命令を直接実行できるCPUを作ってみる』
　
直接実行とは?

>>544-549
https://www.youtube.com/watch?v=A9WLYbE0p-I
https://www.youtube.com/watch?v=Ylqa3e_X30A#t=5m

安価の付け方も知らない雑魚か？

>>553
Brainf**kの仕様そのものがCPUのモデリングっぽいけどね

Brainf**k
仕様がいいかげんだから無理

brainfuckからバイナリ形式に変換してるクセに直接実行と言い張ってて草ｗ

『Hello World あたたたた 11日目 C編』
＞ // hako に追記（strcat は安全でないが教育用途として採用）
＞ strcat(hako, ch);
　
安全でないが教育用途として採用ｗ

>>558
ではどういう状態をお望みですか？
>>559
切れない刃物では教育出来ないだろ？

ひょっとしておこちゃまなのか？

＞ではどういう状態をお望みですか？
　
記事の表題と内容の食い違いを解消すりゃ良くね？
　
＞切れない刃物では教育出来ないだろ？
　
安全な方法を教えたり学んだりするのが教育では？
　
＞ひょっとしておこちゃまなのか？
　
馬鹿なこと言うと笑われることも知らない人かな？

>>560
https://ideone.com/WZIWTH
> *** buffer overflow detected ***: ./prog terminated

切れない刃物では教育出来ないだろ？(ｷﾘｯ
　
カッコイイこと言ってるけどバッファオーバーフローする書き方を肯定するのはなんで??

Hello World あたたたた 11日目 C編の記事主、プロフィールに「プロダクトマネージャ。前職は銀行システム開発」なんて書いてるけど、バッファオーバーフローの他にもループの繰り返しフラグで管理してるのダサいし、utf-8の文字列の部分一致の判定にマルチバイト文字に対応してないstrstr()使ってるしどう見ても素人以下だなあ。

素人が素人に教える地獄
AIによる嘘記事による検索汚染とか
キータなんてそれをわざわざ自前で手動でやってんだから恐れ入る
人類の知性を必死で下げてるわけだよこれって

ちょっと前のQiitaだったら間違えてるとこ指摘してくれる人普通にいた気がするけど運営が排除しちゃったのかな

chatgptに件の記事読ませておかしいとこ指摘してと入力したら
　
strcat() の使用 バッファオーバーフローの危険あり
末尾判定の実装 条件が「含んでいる」だけで末尾確定ではない
解説の不十分さ 安全性や UTF-8 の正しい扱いについて言及が弱い
乱数処理 初期化はしてるが仕組み説明が浅い
バイト/文字数の区別 UTF-8 の扱い解説が不足
　
そこそこ具体的に指摘してくれたけど、Qiitaも記事公開前にAIにチェックしてもらう機能入れたらそこそこクソ記事は減るんでないかな。