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

**デフォルトの名無しさん** · 2025/02/14(金) 19:00:46.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/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/

**デフォルトの名無しさん** · 2025/08/25(月) 09:20:09.08

要するに名前とその指示対象との対応関係のことなんだからどちらがどちらに束縛されるという表現でもいいじゃないかという考え方もあるし、名前というのは高級言語によって導入された抽象化であってその指示対象に対して二次的な概念に過ぎないから「名前が～に束縛される」という表現の方が本来の表現ではないかという考え方もある。自分は一応後者の考え方に従っているけど、そんなに強いこだわりはないかな。
これについてはOCamlの五十嵐先生の本にもちょっとだけ言及があって、その本では「名前が～に束縛される」という方の表現が採用されているみたいだった。関数型言語の界隈で一般的にそちらの表現の方がメジャーかどうかまでは知らないが。

**デフォルトの名無しさん** · 2025/08/25(月) 09:56:33.15

単純代入や単純束縛だと変数名が確定しているから変数名が先に来るのもわかる
しかしパターンマッチングが主流の現代だと値はマッチング前に既に確定しているが
複数のパターンが並んでいてその中に変数が0個～複数個と各々で存在しどの変数がマッチするか実行まで決まらない
すると順に「値を」「(各々の)変数に」「束縛(成功または失敗)」というイメージが正解っぽくみえる

**デフォルトの名無しさん** · 2025/08/25(月) 12:36:43.40

パターンマッチングのマッチ試行というのは、あくまでもパターンとのマッチングであって、変数とのマッチング（？）ではないような気がするけど。そもそもマッチ試行と名前束縛は区別されるべき別々のフェイズであって、名前束縛は特定のパターンにマッチした後のフェイズなのでは？
また、仮にそれは措くとしても、「特定の対象に対応する変数が0 ～複数個あり得てどれが対応するのか実行時まで決まらない → 値が変数に束縛されるというイメージの方が正解っぽく見える」の論理的繋がりがあまり明確でないような……。むしろ逆なのではという感じもするし、特に関係ないようにも感じるし。

**デフォルトの名無しさん** · 2025/08/25(月) 12:56:33.15

普通の代入がなくて全てパターンマッチングな言語も増えているからな
従来の代入はたまたま変数が一つのパターンと見るのが自然

>>878
両者を区別するのは頭の硬い古い考え

**デフォルトの名無しさん** · 2025/08/25(月) 14:11:40.25

パターンマッチは、マッチ試行と名前束縛（およびその名前を用いた何らかの処理）という複数のプロセスに分解して理解できるという話と、特定の言語の言語仕様上、それをまとめてパターマッチと呼ぶことがあるという話は普通に両立する話だと思うんだが。
代入をいわゆる変数パターン・キャプチャパターンとのマッチとして整理するという考え方は十分ありうるところだけど、その場合でもマッチ試行と名前束縛というフェイズ分けはできるわけで。

**デフォルトの名無しさん** · 2025/08/25(月) 14:31:34.25

>>880
パターンマッチは型が決まれば任意の値に対して必ず成功するパターンと
値次第で成功も失敗もありうるパターンの二つに明確に二分される
前者にはマッチ試行なんて概念は出てこない
いきなり名前束縛のみが起きる
通常の束縛や代入文で現れるパターンマッチングはこれ
マッチ試行なんてフェーズはない

**デフォルトの名無しさん** · 2025/08/25(月) 14:39:30.63

上でマッチ試行といっているのは、複数（1個の場合もありうる）のパターンのどれがマッチするかを決定するプロセスのことね。この意味のマッチ試行はパターンマッチには必ず存在すると思うけど？
一般的な代入をパターンマッチと見るなら、マッチ対象としてのパターン（変数パターン・キャプチャパターン）は1つしか与えられておらず、かつ変数パターン・キャプチャパターンは常にマッチが成功するというだけ。OK?

**デフォルトの名無しさん** · 2025/08/25(月) 14:59:16.48

対象となる型とパターンによって、静的にrefutableか否かが確定する。
irrefutableなパターンには、マッチ試行という行為どころかその概念すら存在しない。

**デフォルトの名無しさん** · 2025/08/25(月) 15:21:06.37

そんなに難しいことを言っているつもりはないんだけどな。
たとえばPythonのmatch文なら、各caseブロックに掲げられているパターンのいずれかにマッチしてそのcaseブロックのコードが実行されるのか、あるいはどのパターンにもマッチしないのかということが決定されるプロセスのことを便宜上「マッチ試行」と呼んでいるだけなんだが。
用語法が気に入らないというなら別に他の用語でもいいけれど、どこに引っ掛かっているのか、元の>>877との関係で何を主張したいのかがよく分からないな。

**デフォルトの名無しさん** · 2025/08/25(月) 15:31:47.26

irrefutableなパターンは必ずマッチし必ず束縛が起きる。
match文のような試行による場合分けを必要としない。
irrefutableか否かは実行前に静的に判明する。

**デフォルトの名無しさん** · 2025/08/25(月) 15:51:21.92

常にマッチに成功するパターンであることが実行前に判明しているからといって、それがマッチ試行（別の名前でも構わないが）をというフェイズを観念すること、特に名前束縛と区別されるフェイズとして観念することの障害になるとは思わないが。
常にマッチに成功するパターンであることが実行前に判明しているパターンであれば、実行時のコストがないので良かったねというだけの話だと思うんだがな。

**デフォルトの名無しさん** · 2025/08/25(月) 18:23:24.53

うざい

**デフォルトの名無しさん** · 2025/08/27(水) 21:45:27.82

重盛雅人さん、６月上旬から７月上旬にＡＩに吐かせたデタラメ記事投稿しまくってたけどピッタリ止まったなｗ

**デフォルトの名無しさん** · 2025/08/27(水) 22:17:44.63

転職先みつかったんじゃないの？自分の周りにいるかもしれないと思うと怖いけどw
（もちろん、思想や技術力、意識高すぎで怖いなー！って意味です。）

**525** · 2025/08/28(木) 01:43:28.31

> プロフィールの自画像らしき画像みるといい年したオッサンのようなのだけど、経験や知識が乏しい若造が見栄張りたいんだかなんかでしそうなことなんでこんなオッサンがするかなあ? と思ったのだけど、自画像も生成画像の可能性もあるか。

に

> 身元がはっきりしている人が身元を保証するようなコメント・会話したら本人の可能性が高まる

とコメントしたらいなくなった
プロフィール画像も記事もAIというネタ

**デフォルトの名無しさん** · 2025/08/28(木) 07:50:45.18

ツイッタで先月末に
＞この度、Qiita Tech Festaにて最優秀賞を受賞いたしました。業務の都合で当日参加できなかったことは残念でしたが、このような素晴らしい賞をいただけたことを大変光栄に思います。関係者の皆様、そして応援してくださった皆様に心より感謝申し上げます。
　
と呟いたあとは今月一回呟いただけかあ。

**デフォルトの名無しさん** · 2025/08/28(木) 20:50:59.02

Claude Code UIレビュー：スマホからでもAIコーディングが可能に！開発効率が劇的向上

---
そして、ブラウザで以下のURLにアクセスします：

ローカル：http://localhost:5173/
ネットワーク：http://192.168.10.79:5173
---

バ〇丸出しで爆笑したんだがw
一歩間違えればセキュリティ事故

ちなみにこんなんでハートが100超えてる。

**デフォルトの名無しさん** · 2025/08/28(木) 21:12:41.99

プライベートIPアドレス帯をグローバル公開でもしてんの?

**デフォルトの名無しさん** · 2025/08/28(木) 21:46:33.48

うん、誰かコメントしてあげるのがいいんじゃないかな（めんどくさいからもちろんボクはしませんw）

> 公開されている 192.168.10.79 はプライベートネットワークのアドレスなので、他の読者はアクセスできません。単なる、記事執筆時点でのあなたのPCのプライベートIPアドレスでしかない可能性もなくはありません。記事では <your-ip> のように置き換えておくとより親切かもしれません 👍

ついでに 192.168 の意味とかRFCとかも引用してあげると好感度upじゃないかな。

**デフォルトの名無しさん** · 2025/08/28(木) 22:49:45.05

>>892
> 初回アクセス時には、ユーザー名とパスワードを設定するだけで、すぐに使い始められます。

パスワードが破られなければセキュリティ事故にならなくない？

**デフォルトの名無しさん** · 2025/08/28(木) 23:20:26.39

おいおい、なんでここでSC試験の問いに出てくるアホ設定の若者の相手しなきゃいけないんだよw

**デフォルトの名無しさん** · 2025/08/28(木) 23:38:03.08

それはおまえの発言がインターネット（不特定多数）に公開されてるからだろ
自分しか参照できない場所に書けばいいんじゃない？（二度と５ｃｈに投稿するな）

**デフォルトの名無しさん** · 2025/08/28(木) 23:46:50.90

いくらでも投稿するよ〜ん（笑）

**デフォルトの名無しさん** · 2025/08/29(金) 10:06:25.14

>> 897
本人にしか言えないキレ論理だな

**デフォルトの名無しさん** · 2025/08/29(金) 22:40:43.95

『バブルソートでわかるRISC-Vのきれいさ』
　
クソコードできれいさを語るのは何故なのか?

**デフォルトの名無しさん** · 2025/08/30(土) 02:55:22.61

>>900
そいつはCPUとメモリとのやりとりが遅いことがわかってないな

8086のアセンブラを知らないから、高水準言語のようなやり方をしている。

しかもコメントもわかりにくいし、ジャンプ命令の行はコメントがない。

コメントにコード比較を書いてみたり、日本語を書いてみたりと他人に見せるもんじゃねえな。

**デフォルトの名無しさん** · 2025/08/30(土) 06:59:58.86

CISCと比べてRISCきれいつっても、みんな知っとることを今更何？なんだよなあ

**デフォルトの名無しさん** · 2025/08/30(土) 07:16:23.33

あとはまあ、知っている奴にはわかるが知っていない奴にはわからない無意味記事だよなこれ

**デフォルトの名無しさん** · 2025/08/30(土) 11:01:18.74

0.知っている奴にはわかるが知っていない奴にはわからない
1.知っている奴でもわからない知っていない奴にもわからない
2.知っている奴にはわからないが知っていない奴にはわかる
3.知っている奴にはわかる知っていない奴にもわかる
たぶん3が意味があるんだろうけど天才肌は1か2だろうな

**デフォルトの名無しさん** · 2025/08/30(土) 12:47:41.71

CPUの仕組みの変化の話をアセンブラのコード量で語るのはおかしいし、半導体としてのCPUの進化を無視しているのも謎。

AIチップなどの特定のロジックを半導体化することを否定する記事。

**デフォルトの名無しさん** · 2025/08/30(土) 14:42:08.38

> 比較したいいところ
> 1. 命令フォーマットが規則的で読みやすい
> x86版では
>
> cmp al, [si+1]
> jl common
> xchg al, [si+1]
> mov [si], al
> のように「レジスタ＋メモリ」「メモリ＋メモリ」が混ざっていて、例外的なルール (xchg は直接使えないから mov に分ける) があります。

と解説してて、記事中のコードの該当部分は

> cmp eax, ebx
> jle no_swap
> mov [array + esi*4], ebx
> mov [array + esi*4 + 4], eax

となってるのが味わい深い。
投稿者がコードと記事の両方を理解して書いてたらこうはならないと思うのでAIにやらせてんだろうなあ。

**デフォルトの名無しさん** · 2025/08/30(土) 14:47:19.38

他にも

> print_int:
> push ebp
> mov ebp, esp
> push ebx
> push ecx
> push edx
> push esi
> push edi
>
> jmp .convert_digits
>
> .convert_digits:

フレームポインタ使ってないのにebpにespコピーしたりすぐ下のラベルに無意味なjmpしたり、正確な理解のもとで書かれたコードである気がしない。

**デフォルトの名無しさん** · 2025/08/30(土) 18:02:51.32

よく見てはいないが、全体的にx86のアセンブラっぽくないんだよなあ。

**デフォルトの名無しさん** · 2025/08/30(土) 18:12:37.02

他人のC言語のコードを引用しているが、関数の戻り値がvoidなのもプロっぽくない。
int型の配列に値を入れて関数に渡すという仕様も、わざわざ配列にいったん格納して、同じメモリ領域を上書きしてしまうというのも実務では考えられない。

**デフォルトの名無しさん** · 2025/08/30(土) 18:41:49.73

>>909
それについてはおまえがおかしい
その仕様が最も正しい
おまえの間違った仕様を書いてみろ

**デフォルトの名無しさん** · 2025/08/30(土) 19:45:23.92

＞関数の戻り値がvoidなのもプロっぽくない。
＞int型の配列に値を入れて関数に渡すという仕様も、わざわざ配列にいったん格納して、同じメモリ領域を上書きしてしまうというのも実務では考えられない。
　
標準関数のqsort知らない人かな

**デフォルトの名無しさん** · 2025/08/31(日) 02:12:00.94

アセンブラのおかしな記事が挙がるとよくわかってないわかったつもりの奴が叩きに参戦してくんの面白れぇなｗ

**デフォルトの名無しさん** · 2025/08/31(日) 10:55:35.99

知らないならレスしないでください
うざいだけです

**デフォルトの名無しさん** · 2025/08/31(日) 11:24:45.92

>>913
>>913

**デフォルトの名無しさん** · 2025/08/31(日) 12:41:28.48

cコンパイラにアセンブリコード吐かせてからいじったんやろ察してやれ

**デフォルトの名無しさん** · 2025/08/31(日) 14:05:56.57

記事のコードをNASMでアセンブルして実行できるんだが
https://godbolt.org/z/jKvsfccGM
同じロジックをCで再現してgccでコンパイル、実行しても
https://godbolt.org/z/csTv9qsnP
結構違うコード吐くし

> cコンパイラにアセンブリコード吐かせてからいじったんやろ察してやれ

こんな訳はないんだよなあ。
この記事について「よくわかってないわかったつもりの奴」が次から次へと湧いてくんの何なの。

**デフォルトの名無しさん** · 2025/08/31(日) 14:10:20.14

ちなみに記事のアセンブリコードの10進数出力であるprint_intルーチンは値0を出力する実装にバグがある。
https://godbolt.org/z/Trh3fxv1E

**デフォルトの名無しさん** · 2025/08/31(日) 14:14:00.36

自己レス:

> ちなみに記事のアセンブリコードの10進数出力であるprint_intルーチンは値0を出力する実装にバグがある。

修正案1
https://godbolt.org/z/d6bacfKze

修正案2
https://godbolt.org/z/4ThevPsj4

**デフォルトの名無しさん** · 2025/08/31(日) 14:16:59.26

アセンブラのコード量が減っても、それが速く動かなければ意味がない。

**デフォルトの名無しさん** · 2025/08/31(日) 14:26:51.20

アセンブラを使う理由は場合によりけりで
・アーキテクチャの学習を行いたい場合
・ブートローダーなど、使用できるコードサイズが限られる場合
・コンパイラが吐いてくれない命令を使用したい場合
・コンパイラで吐いてくれるコード以上に最適化したい場合

> それが速く動かなければ意味がない。

てのはひとつの視点でしかない。

**デフォルトの名無しさん** · 2025/08/31(日) 14:32:35.32

修正案3
https://godbolt.org/z/j7zn7591r

記事のコードは無駄が多すぎる。AI出力によるツギハギ臭が酷い。

**デフォルトの名無しさん** · 2025/08/31(日) 14:40:17.45

>>920
その記事を書いた人間はアセンブラのコード量が少なくなるという記事を書きたかったかったんだぞ？

**デフォルトの名無しさん** · 2025/08/31(日) 14:42:00.04

いまどきメモリが少なすぎてマシン語がまともに入らない機器なんてごくわずか

**デフォルトの名無しさん** · 2025/08/31(日) 14:50:52.80

> その記事を書いた人間はアセンブラのコード量が少なくなるという記事を書きたかったかったんだぞ？

あなた:
この記事（https://qiita.com/misohagi/items/029222e579f43fdfc93f）の内容に「アセンブラのコード量が少なくなる」という要素はありますか?
ChatGPT:
ご提供いただいたQiita記事「バブルソートでわかるRISC‑Vのきれいさ」（2025年8月28日投稿）について確認しました。

結論から言うと、この記事内に「アセンブラのコード量が少なくなる」という記述はありません。以下、内容のポイントを整理します：

記事内容の要約
C言語版・x86アセンブリ版・RISC‑Vアセンブリ版のバブルソート実装を比較しています。
Qiita

比較されている観点は以下の通りです：

命令フォーマットの規則性・読みやすさ
→ x86はレジスタ＋メモリ、メモリ＋メモリなど混在し、例外的なルールも多いのに対し、RISC‑Vでは一貫性ある命令構成（ロード→比較→ストア）で構成されており、可読性に優れている。
Qiita

メモリ演算の明確な分離
→ x86では複雑な複合命令（例：cmp al, [si+1]）がある一方、RISC‑Vでは命令が分割されている（ロード → 比較 → 分岐）ため、理解しやすい。
Qiita

拡張性と移植性
→ x86は歴史的に多くの拡張を抱えているのに対し、RISC‑Vはシンプルで必要な機能を拡張指令として付与できる設計になっており、将来的な拡張にも対応しやすい。
Qiita

「コード量が少なくなる」という記述はあるか？
いいえ。記事では「命令の規則性」や「構造の分かりやすさ」などが強調されている一方、「アセンブラのコード量が少なくなる」といった記述は一切ありません。

ご質問の「アセンブラのコード量が少なくなる」という要素は、この記事の中には含まれていないことをお伝えします。他に気になる点や別の記事についての確認も可能ですので、どうぞ気軽にお知らせください！

**デフォルトの名無しさん** · 2025/08/31(日) 16:42:35.64

>>924
「バブルソートでわかるRISC-Vのきれいさ」

きれいになると彼は言っている
実際に示しているコードはきれいになっているのではなく、コード量が減っているだけ

**デフォルトの名無しさん** · 2025/08/31(日) 17:20:05.97

＞「バブルソートでわかるRISC-Vのきれいさ」
＞実際に示しているコードはきれいになっているのではなく、コード量が減っているだけ
　
記事のバブルソートのコードはx86では14命令なのに対してRISC-Vでは16命令なのでRISC-Vでコード量が減ってるということは全くない。

**デフォルトの名無しさん** · 2025/08/31(日) 17:31:25.81

>>926
CISCとRISCのCPUの違いがわからないのか？

1クロックでやることが多いCISCは命令が少なくなるのはあたりまえ。

彼の問題はRISCだときれいになるとの主張。

それにC言語のint型が64ビットという前提で説明しているのもおかしい。

**デフォルトの名無しさん** · 2025/08/31(日) 17:36:07.00

記事のRISC-Vのコード見るとコメントになんでかx86のレジスタ書いてんだよなあ。
x86からRISC-Vに移植したか、x86との対応わかるようAIに指示したかどっちかか。
こんなクソコードクソ記事からなんか有意なこと読み取ろうとしても無駄だぞ。

**デフォルトの名無しさん** · 2025/08/31(日) 17:39:14.61

＞1クロックでやることが多いCISCは命令が少なくなるのはあたりまえ。
　
スーパースカラーも知らない人は黙ってた方良いよ。

**デフォルトの名無しさん** · 2025/08/31(日) 17:52:22.50

>>929
CPUの性能の進化でそれをやる必要がなくなってRISCの方がよいということになってあの記事があるんだぜ？

**デフォルトの名無しさん** · 2025/08/31(日) 17:53:36.95

＞それにC言語のint型が64ビットという前提で説明しているのもおかしい。
　
どこ見てそう思ったか知らんけどx86のコードではe?xの32ビットレジスタ使ってるしRISC-Vはlw/swで読み書きしてるから32ビットだね。
何いってんのという感じ。

**デフォルトの名無しさん** · 2025/08/31(日) 17:55:54.89

x86は16ビットか32ビットだよ？

x64と書いてあれば64ビット

**デフォルトの名無しさん** · 2025/08/31(日) 17:56:34.83

キータのレベルは理解不能

**デフォルトの名無しさん** · 2025/08/31(日) 18:02:43.60

>>930
「バブルソートでわかるRISC-Vのきれいさ」と題して十分に最適化されてないコードで「きれい」なんて主観を語ってる記事はナンセンス。
「シンプル」や「簡潔」と言ってるならまだ擁護の余地はあった。

**デフォルトの名無しさん** · 2025/08/31(日) 18:54:27.77

彼はアセンブリでマクロ機能も使ってないしな

**デフォルトの名無しさん** · 2025/08/31(日) 21:20:53.75

これくらいの規模のコードでマクロの有無はなんも関係ないけどな

**デフォルトの名無しさん** · 2025/08/31(日) 21:36:29.37

彼は繰り返しでも前に戻るジャンプしか書かない
これが「きれい」というのは意味がわからない

**デフォルトの名無しさん** · 2025/08/31(日) 22:59:08.87

＞彼は繰り返しでも前に戻るジャンプしか書かない
えっ意味わからん
　
＞ jz sorting_done
　
＞ jle no_swap
　
＞no_swap:
　
＞sorting_done:
　
＞ jmp .convert_digits
　
＞.convert_digits:
＞ jne .convert_loop
　
＞ jmp .print_number
　
＞.convert_loop:
　
＞.print_number:

**デフォルトの名無しさん** · 2025/09/01(月) 00:06:03.46

>>938
意味がわからない領域に深く入っていて
意味がわかるもわからないもない
この状況で「意味がわからない」と言うべきでない
意味がわかることだけを投稿しろ

**デフォルトの名無しさん** · 2025/09/01(月) 00:36:19.45

お前の言ってることわけわからんと言われて逆ギレかあ

**デフォルトの名無しさん** · 2025/09/01(月) 01:04:00.29

>>938
それは条件分岐と変な入れ子

**デフォルトの名無しさん** · 2025/09/01(月) 01:04:34.94

よく見ると入れ子になっているな
めちゃくちゃだ

**デフォルトの名無しさん** · 2025/09/01(月) 01:06:18.90

逆にアセンブラを見せてC言語化させたら、本人はgoto文だらけのコードを書きそうw

**デフォルトの名無しさん** · 2025/09/01(月) 08:10:56.78

知識がないニワカが語ってるの面白いｗ

**デフォルトの名無しさん** · 2025/09/01(月) 11:57:14.54

＞彼は繰り返しでも前に戻るジャンプしか書かない
　
記事のバブルソートのアセンブリ言語のコードは外側のループは終了判定を最初にやる仕組みになってて、内側のループは継続する判定をループの最後にやる仕組みになってるのに何を言っているのか?

**デフォルトの名無しさん** · 2025/09/01(月) 16:21:07.54

順次実行、条件分岐、繰り返しを書くんだったら、上から下という方向に書かないと

**デフォルトの名無しさん** · 2025/09/01(月) 22:32:14.44

彼は構造化プログラミングを理解していない

**デフォルトの名無しさん** · 2025/09/01(月) 22:33:58.08

IDが変わるな

**デフォルトの名無しさん** · 2025/09/01(月) 22:34:34.55

モバイルデータ通信で書き込むとコロコロIDが変わるな

**デフォルトの名無しさん** · 2025/09/01(月) 22:34:48.69

てすと

**デフォルトの名無しさん** · 2025/09/01(月) 22:54:33.67

コード改善案のひとつも示せない奴がなんか言ってても意味ないんだよなあ。

改善案1(サイズ優先)
https://godbolt.org/z/4E6xb3qeP

改善案2(実行効率優先)
https://godbolt.org/z/nndGsqv51

**デフォルトの名無しさん** · 2025/09/02(火) 02:05:54.97

『古いC++コードをモダンC++に修正(問題編)』
『古いC++コードをモダンC++に直す練習(解答編)』

メリットデメリット評価しないで新しい機能使うのが正しいという記事。
「7：構造体のコピーと参照」は記事書いてる当人がわけわかんなくなってるなｗ

**デフォルトの名無しさん** · 2025/09/02(火) 19:51:11.47

(わかってないのに)アセンブラいっちょかみする奴なんなの

**デフォルトの名無しさん** · 2025/09/02(火) 23:00:40.84

>>952
見たけど大雑把にCから古いC++コードに修正だな
10年前の記事ならそれでもいいが
モダンなC++コードと言いながらstd::rangesすら出て来ない

**デフォルトの名無しさん** · 2025/09/03(水) 07:43:05.57

>>0040
38のいうとおり、日本人気質はある。qiitaはもともとstackoverflowの日本版という雰囲気でスタートしたが、途中でSO風というのをやめて日本人にアジャストした。
qiitaができたあとに日本版SOができたが閑古鳥なのはご存知のとおり。
日本人気質と議論の比較ということなら、redditとはてブの違いも顕著。
日本人はほぼ匿名のハンドルだとしても個人として議論するのが極端に苦手、もしくは嫌い。
確立した個人の集団としてコミュニティを自治するみたいなこともやりたくない。
ここみたいにqiita外で完全匿名の集団でチクチク書くのも日本人気質だろう。

**デフォルトの名無しさん** · 2025/09/03(水) 18:17:22.50

それは違うだろ
nntpとか社名出してクネクネすんのが得意で
qiitaと同じじゃんw

**デフォルトの名無しさん** · 2025/09/03(水) 19:20:53.40

はてぶは日本人っていうか氷河期世代のろくに職歴も学歴もない連中がルサンチマンを垂れ流してるだけなので…
あれを日本人の気質だとは思わないでほしいな
クズの掃き溜めだよ、あそこは

**デフォルトの名無しさん** · 2025/09/03(水) 19:35:53.18

日本版SO見に行ったが和やかな雰囲気で質問回答サービスとしては上手くいってんじゃないの?
Qiitaみたいな害悪垂れ流す悪質サービスとは同列に語るべきではないだろ。

**デフォルトの名無しさん** · 2025/09/03(水) 20:20:41.86

例の先生

『色々な言語でたらい回し関数の速度を比較してみたその２』
https://qiita.com/Freezer/items/1badfbba34c13995eed4#comment-b75826cee2cef0f4d34a
> 多分あまり速度変わらないと思うのですが、Elixirだと下記のように関数パターンマッチを使う方が一般的かなと思います。

各言語で条件合わせてるって考え及ばないのかなあ?
つか先生の書き方だと
> def tarai(x, y, z) when x <= y, do: y
参照してない引数zで警告出る。

**デフォルトの名無しさん** · 2025/09/03(水) 21:15:43.80

>>954
世の中的にはいまだにC++11くらいが「モダン」なんじゃない？
C++17とか20, 23 をちゃんとキャッチアップしてる人は、たぶんC++開発者全体から見てそう多くない

**デフォルトの名無しさん** · 2025/09/03(水) 21:16:36.02

議論より根回し、
出る杭は打つってのは日本の文化であり日本人の気質だよ

**デフォルトの名無しさん** · 2025/09/03(水) 21:28:57.60

>>960
C++17以降へ進むはずだった人たちはRustへ行ってしまったからね
セキュリティ要件が益々高まっていく状況でC++人口は減っていきC++17以降は普及せずに終わると思う

**デフォルトの名無しさん** · 2025/09/04(木) 03:28:34.77

全プロンプトが書いてある衝撃記事があって質問して誘導してから「Qiita記事書いて」と指示したらしい
10分でAI記事書けるｗ

**デフォルトの名無しさん** · 2025/09/04(木) 04:25:11.55

バイラルマーケティングの格言「コンテンツは王様かもしれないが配信は女王様であり主導権を握るのは彼女」
どんなに優れた作品でも人に届かなければ存在しないのと同じ
QiitaはSNSで共有される記事に最大の価値を置く

**デフォルトの名無しさん** · 2025/09/04(木) 07:34:27.12

>>963みたいなわかってない奴の書く日本語より、
生成AIが出力する言語の方が遥かに読みやすいもんな

**デフォルトの名無しさん** · 2025/09/04(木) 09:37:47.21

>>962
残念だが認めざるを得ない

**デフォルトの名無しさん** · 2025/09/04(木) 18:48:42.24

『クローン面接体験記』
　
株式会社オルツ？どういう会社か気になるな。

**デフォルトの名無しさん** · 2025/09/04(木) 19:32:45.40

去年の６月か
ある意味、貴重な記録だ

**デフォルトの名無しさん** · 2025/09/04(木) 23:01:20.46

Content Is King, Distribution Is Queen
いくら質の高いコンテンツがあっても、それが適切なターゲットに、適切な方法で配信されなければ価値が最大化されないということを強調しています

「コンテンツは王様配信は女王」の日本語で検索しても「コンテンツイズキング」の意味の記事しか出てこない

日本人やばいなｗ

**デフォルトの名無しさん** · 2025/09/05(金) 14:39:28.61

>>717
＞『圧縮しないアーカイブ形式「PAF」をC＋Pythonで作った理由と実装メモ』の記事にあらたに作る必要ある? tarで良くね?というコメントがおかしく記事を読んでないがあらたに作る理由を記事に書くとタイトルにある
　
記事書いた本人がアンサー記事書いてるのに何言ってんの？
『tarがあるのにPAFを作った理由』

**デフォルトの名無しさん** · 2025/09/05(金) 15:04:43.61

>>970
最初の記事を読んでみろ
tarについて一言も言及されていない
もしtarを知っていればtarについて必ず言及があるはずだがtarの3文字すら記事に登場しない
そいつはtarの存在すら知らなかったんだよ

**デフォルトの名無しさん** · 2025/09/05(金) 17:14:23.30

このスレのツッコミもちっちゃいなw
その程度の奴らか

といか量子でほら吹いてるキチガイ記事の排除とかした方がいいだろ
あと自己啓発

**デフォルトの名無しさん** · 2025/09/05(金) 17:25:40.54

>>717が反応してんの(量子?)面白れぇなｗ

**デフォルトの名無しさん** · 2025/09/05(金) 20:44:11.54

俺はほぼ書いてないぞ
妄想で噛みついてるのかも知らんが

**デフォルトの名無しさん** · 2025/09/05(金) 21:31:19.77

モデレータが居ないと破綻すると思ってたが
破綻したのはむしろQitaの方で
5chがまだ威嚇的正気を保ってるのが興味深い
どっちもオワコンだが

**デフォルトの名無しさん** · 2025/09/05(金) 23:27:31.79

>>974
なんか言い訳してて草ｗ