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/13(水) 09:47:20.04

>>810
そういうときこそAIを使うべき。
AIに「CHARが文字列型の言語って何かある? SQLはどう?」とか訊くと優しく教えてくれる。

**デフォルトの名無しさん** · 2025/08/13(水) 09:52:49.55

>>811
>>809に訊くことが目的だからAIじゃ代替にならない

**デフォルトの名無しさん** · 2025/08/13(水) 10:00:35.99

QiitaもZennも、もうAIで生成したのをペタっと貼った箇条書き記事ばっかだし
質問もAIのほうが親切でわかりやすい解答くれるし、マジでコミュニティにおける人間の役目なんて、もうレスバのサンドバッグだけだな

**デフォルトの名無しさん** · 2025/08/13(水) 12:31:40.16

Rustだとchar型はユニコードの値そのまま
つまりchar型は21bitただし最小0～最大0x10ffff
メモリサイズとしては32bitを占有
つまり符号なし32bitのu32型と占有サイズは同じだが別の扱い
数値として見た時の値は必ず0x10ffff以下でユニコード値が保証される

Rustの文字列型はユニコードのUTF8そのまま
必ず正しいUTF8形式であることが保証される

ちなみに8bitの型を使いたかったら
符号ありi8型か符号なしu8型

**デフォルトの名無しさん** · 2025/08/13(水) 15:03:41.82

>>813
8割型AIコピペだな
俺はちゃんと書いてるけど
まあ単なる手順書しか書いてないけど

**デフォルトの名無しさん** · 2025/08/13(水) 20:06:00.97

C言語のchar型が1バイトというのが時代に合わないからなあ

**デフォルトの名無しさん** · 2025/08/13(水) 20:13:02.71

>>816
さっきから的外れなこと言ってるな
はやく>>810答えてくれよ

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

>>817
Fortran

**デフォルトの名無しさん** · 2025/08/13(水) 22:11:25.31

ちゃんとした記事にはあまりいいねがつかずに
AIコピペした自己啓発っぽいやつはいいねが多いな

**デフォルトの名無しさん** · 2025/08/13(水) 23:58:03.89

>>818
答えるべきでない
非匿名ならgiveに返礼を期待できるから答えるべき
匿名ならgiveに返礼が期待できない
takerが跋扈したら匿名掲示板が終わる
匿名掲示板はgiveし合う場所
takerを無視すべき

**デフォルトの名無しさん** · 2025/08/14(木) 00:36:59.69

>>818
Fortranのcharacter型とCのchar型を同一視してそもそも～ってのは無理がないか？

**デフォルトの名無しさん** · 2025/08/14(木) 16:44:08.51

>>821
古い時代ほど、1文字を格納する変数を用意するのは変ではなかった。
しかし、同時に文字列を格納する変数も用意した。

C言語はUNIXの一部のコマンドを作るために用意したものだから、文字列はメモリをあちこちに確保してしまうから用意しなかったと思われる。

**デフォルトの名無しさん** · 2025/08/14(木) 19:12:33.15

>>822
文字列処理のための言語じゃねーからだよ

**デフォルトの名無しさん** · 2025/08/14(木) 19:45:42.82

>>823
CUIのOSなのに？

**デフォルトの名無しさん** · 2025/08/14(木) 20:42:01.45

>>822が>>821へのレスのつもりなのマジ意味わからん

**デフォルトの名無しさん** · 2025/08/15(金) 01:10:13.48

キャラクター型の表記がcharacterとcharで別だと思っているのも新種。
英語圏で別だと発言したら何を言っているのかと思われてしまう。

**デフォルトの名無しさん** · 2025/08/15(金) 16:44:22.49

英語圏ではキャラクター型の表記がcharacterとcharでは別だと発言したら何を言っているのかと思われてしまいますか? ＞AI

**デフォルトの名無しさん** · 2025/08/15(金) 18:55:46.56

>>826
K&RによればCのcharはcharactorだぞ

**デフォルトの名無しさん** · 2025/08/15(金) 18:57:54.76

ついでに他の言語の文字列型はstring型だな
c++の標準クラスでもstringの名が採用されてる
characterで文字列って方が異端

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

>>818
「そもそもCHAR型というのは文字列型だからな。」の例としてC言語より後のFORTRAN77以降の機能挙げてて草ｗ

**デフォルトの名無しさん** · 2025/08/18(月) 09:12:00.97

このスレタイやばいだろう
完全に精神疾患朝鮮人って感じ

**デフォルトの名無しさん** · 2025/08/18(月) 12:40:27.49

Ｑｉｉｔａの記事ではないが
『ElixirがHW化され、最新CPU／GPU／NWを過去のものとする数万倍、高速＋超省電力化されたWeb／動画配信／AIが動く日』
Ｑｉｉｔａのアドベントカレンダーが箔付けに使われてたのでやはりＱｉｉｔａは悪と確信した。

**デフォルトの名無しさん** · 2025/08/18(月) 16:51:25.96

アラレちゃんの歌を知らないってもしかして5chじゃレアな世代なのでは

**デフォルトの名無しさん** · 2025/08/18(月) 20:21:33.16

>>832
またあいつか
なんか知識不足げな奴なんだよなあ

**デフォルトの名無しさん** · 2025/08/18(月) 21:01:27.49

>>833
キータをまともな情報源にしている世代は知らないと思う

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

別の奴やったわ
しっかしあの界隈はなんかなあ

**デフォルトの名無しさん** · 2025/08/19(火) 00:12:45.99

凄く重いElixerをHW化したら速くなったらしい
しかし普通にElixerを使わずに速い言語で書いた時との速さ比較ではないところが

**デフォルトの名無しさん** · 2025/08/19(火) 01:28:02.53

>>832
スライド1枚目の「北九州市立大学「プログラミング論」教授級非常勤講師」って何だ?ｗ
准教授より偉いのか? 下か? サッパリ分からんｗ
「ElixirChipとElixirChip Liteで超低消費電力・高性能の世界へ」と被ってるところもあるし例の准教授と一緒にやってんだろうなあｗ
つかスライドにある最新CPUの1000～10万倍の性能ってのが本当なら量子コンピュータに匹敵するインパクトだと思うが比較してんのがIntel Xeon E3-1285 v6って7年前のCPUなの何なのｗ

**838** · 2025/08/19(火) 01:59:11.90

教授級非常勤講師って存在する職階なのね。面白がったのは失礼だったわ。すまなんだ。
https://www.google.com/search?q=%22%E6%95%99%E6%8E%88%E7%B4%9A%E9%9D%9E%E5%B8%B8%E5%8B%A4%E8%AC%9B%E5%B8%AB%22&ie=UTF-8

**デフォルトの名無しさん** · 2025/08/19(火) 08:57:31.19

>>835
Qiitaをまともな情報源にしてるやつと5chやってる奴は概ね別の集団だと思う

**デフォルトの名無しさん** · 2025/08/19(火) 09:31:32.64

>>832
『ElixirChipとは』のページに「従来のサーバーCPU/GPUに換装できる独自アーキテクチャを採用したFPGAボード」とあるけど掲載されてる基板、電源回路かなんかじゃね?

**デフォルトの名無しさん** · 2025/08/20(水) 07:38:50.19

なんかどうでも良い感じの記事が沢山トレンドに挙がってるなあと思ったら株式会社PRUMというのが身内でいいね付け合ってるのか。

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

エリクサーチップの初お目見え会というのが９月に開催予定で６月から参加募集しててまだ３０席埋まってないのかあ。
最新ＣＰＵの千から十万倍の性能という画期的なものに対して世間の反応は冷静で安心した。

**デフォルトの名無しさん** · 2025/08/20(水) 10:12:32.25

HWの能書きに対して記事の質が低くてなあ
おめーなんもわかっとらんやろって

**デフォルトの名無しさん** · 2025/08/20(水) 10:46:10.51

>>842
PRUM, JISOU, Nucoは悪目立ちしてるよなぁ

**デフォルトの名無しさん** · 2025/08/20(水) 23:01:08.17

前スレからコピペ
＞職場がインターフェース誌購読してたんで今更ながら読んでみた。FPGA内蔵SoCみたいなの(SoMとか言うらしい)に8bitの積和演算器64個並列に実装して上限の動作速度の500MHzちょっとで動作できましたって内容だった。
＞
＞500なんとかメガ(動作周波数)×2(積和だから乗算+加算なので2)×64(積和演算器の数)×32(積和演算器のパイプラインステージ数)=2.1TOPs
＞
＞って変な計算してて、それとXeon比べて消費電力(但しTDP)あたりの性能でXeonの何十倍効率が良いって主張だったけど、おいおいパイプラインステージ数は積和演算器の性能に直結しないだろ。なぜそれ掛けてXeonと比べる? って思ったわ。
＞
＞一番気になったのは先生が使ったKria KR260ってAMDの製品、8bitの積和演算が16個同時にできるCortex-A53が4コア載ってて1.3GHzで動作すんだよね。500MHzちょっとで積和演算器64個動かして何なん? 比べるとしてもXeonとじゃなくてそっちとじゃね? とかって素人ながら思ったわ。

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

＞×2(積和だから乗算+加算なので2)
と
＞×32(積和演算器のパイプラインステージ数)
がスゴいなｗ
大学の先生がこんな記事書いてるのｗ

**デフォルトの名無しさん** · 2025/08/20(水) 23:12:03.79

ElixirChip＋Elixir＜＜＜普通のCPU＋普通の速い言語

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

>×2(積和だから乗算+加算なので2)
こういう宗派もありそうではあるんだよな

>×32(積和演算器のパイプラインステージ数)
だがこれはねーわｗｗｗｗ

**デフォルトの名無しさん** · 2025/08/21(木) 13:43:36.26

いろいろ突っ込みどころあるけど、そういう単純な計算だけだったら比較対象はCPUじゃなくてGPUでは。ちなみに整数じゃないけど3060で100tflops

**デフォルトの名無しさん** · 2025/08/21(木) 17:52:50.55

>>832のスライド、現在が２０３０年だったりＰＦＬＯＰＳって単位が普通に出てきたり酷いなｗ
Ｘｅｏｎに対してＦＰＧＡで２．５倍の性能出せたという次のページで１０倍規模、２０倍規模のＦＰＧＡを使えば２６０倍、５２０倍の性能が実現可という主張も酷いｗ２６倍は電力あたりの性能という話だった筈だがもはやこれスライド書いてる人物が主張内容理解してないだろｗ
　
「ＥｌｉｘｉｒＣｈｉｐ導入パートナー募集スライドより」とところどころあるけどこんな酷い資料で開発資金募ったりしてるんだろうか?

**デフォルトの名無しさん** · 2025/08/21(木) 18:51:17.34

訂正：
＞Ｘｅｏｎに対してＦＰＧＡで２．５倍の性能出せたという次のページで１０倍規模、２０倍規模のＦＰＧＡを使えば２６０倍、５２０倍の性能が実現可という主張も酷いｗ
　
ＫＲ２６０に対してＡｌｖｅｏ　U５０とU１００のスペック比べてみたが別にこれＦＰＧＡの規模が１０倍、２０倍ってのはなかったわｗ
つか２６０倍、５２０倍の根拠がまるで分からんｗ

**デフォルトの名無しさん** · 2025/08/21(木) 18:54:21.82

コードを動かしてみたら記事の説明と実際の挙動が違うとか
手順おかしいとか
こいつ何もわかってねえなみたいなのの方がいいね多いな

**デフォルトの名無しさん** · 2025/08/21(木) 19:39:29.30

いまのQiitaの「いいね」はなんも知らん初心者が「なんかわからんけどいいこと書いてそう」くらいでポンポン押されてるから記事の質を担保してくれたりはしないんだよなあ。
Qiitaは一時期「いいね」じゃなくて「LGTM」を使ってたが、あれは「自分が見た感じでは良いと思いますよ」くらいの意味で、軽くても保証の意味を含むのだけど、あれが正確に理解されてて運用されてたら今の惨状はなかったかもしれないと思うと、「LGTM」導入は運営の問題意識の現れだったのかもしれない気がしてきた。まあ失敗だったわけだが。

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

正しい新たな知見を書く場だと儲からない
正しくない記事でも既出事項をAIにまとめてももらった記事でも多くを受け入れることが広告利益に繋がる

**デフォルトの名無しさん** · 2025/08/22(金) 03:19:38.65

わかんねえけど調べながらとりあえず一回書き切るのもまあ勉強にはいいけど
それで生み出された記事はやばいよな

**デフォルトの名無しさん** · 2025/08/22(金) 09:58:32.66

『無限リストによるエラトステネスのふるい』
　
エラトステネスのふるいと称して剰余計算を使った間違った実装がエリクサーのタグ付いた記事に複数あるのはこの記事が元凶かな？
記事が公開されて１０年間間違いを指摘するコメントがひとっつも付いてないのは驚きすらあるな。

**デフォルトの名無しさん** · 2025/08/23(土) 02:32:36.04

トップページより

『海外ドキュメントを読めない英弱集まれ～！読み方のイロハを教えよう』
『君たちは本当のマウスホイールを知らない』[株式会社Works Human Intelligence]
『エンジニア「ファシリって苦手…」←3つの心得授けたる』
『【TCP/IP】重要な技術すぎる』[株式会社Works Human Intelligence]
『AgentCoreッ！よくもクオータをッ！ ◯してやるぞ、◯してやるーッ！！』
『【推しAIエージェント】v0とフォーリンラブ』[株式会社Works Human Intelligence]

こういうタイトルをつけるとトップページに載る

**デフォルトの名無しさん** · 2025/08/23(土) 14:46:25.99

タイトルじゃなくて本文の質に凝ってもらいたいんだけどな

**デフォルトの名無しさん** · 2025/08/23(土) 15:00:47.14

本文はAIが生成するだけだし、何書いてるか投稿者もわかってないから凝れない

**デフォルトの名無しさん** · 2025/08/24(日) 02:58:43.26

福岡Elixirコミュニティのデタラメっぷりが凄まじいけど、今の九州って詐欺まがいなことしなきゃ生きていけないくらいの惨状なの?

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

プログラミング言語クリトリス
https://mevius.5ch.net/test/read.cgi/tech/1755991901/

**デフォルトの名無しさん** · 2025/08/24(日) 13:20:07.19

日経クロステックで『イスラエル新興「エヌビディアのＧＰＵより１０００倍高速」、光活用のＡＩ計算機』という記事を見たが、たかだか１０００倍程度では「最新ＣＰＵ／ＧＰＵ／ＮＷを過去のものとする数万倍、高速＋超省電力化」というＥｌｉｘｉｒＣｈｉｐの敵ではないなｗ

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

「値を変数に束縛」って記述を見るとモヤっとするな

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

>>863
全角オジサン

**デフォルトの名無しさん** · 2025/08/24(日) 18:15:55.93

＞全角オジサン
　
プロバイダによるんだろうが一バイト文字入ってると「もう余所でやってください。」出て投稿できないのの対策だぞ

**デフォルトの名無しさん** · 2025/08/24(日) 19:26:06.29

『C++のHello World、23年越しの進化』
　
puts知らない人かな。

**デフォルトの名無しさん** · 2025/08/24(日) 21:03:09.13

鍋谷臭

**デフォルトの名無しさん** · 2025/08/24(日) 22:55:04.42

鍋谷だったら本人がコメントしてるであろう

**デフォルトの名無しさん** · 2025/08/25(月) 01:00:01.07

自意識過剰な鍋谷がコメント返してきてる時点で満足できたよ！おやすみ〜！

**デフォルトの名無しさん** · 2025/08/25(月) 02:48:14.61

欧米はジャッジしない文化が浸透してる
日本語は「いいね」「良いね」ボタンで価値観を善悪で分ける
英語は「like(好き)」ボタンでジャッジせず個人の感想に留める

**デフォルトの名無しさん** · 2025/08/25(月) 03:48:29.07

>>864
束縛という日本語をコンピュータ用語として転用してるのに元の日本語での使われ方にひきずられて主客が逆だのいってるのがそもそも間違い

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

>>872
「値を変数に束縛」で合ってるだろ
どこが逆なんだ？

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

>>867
欲しけりゃ作れる言語なんだから欲しけりゃ作れとしか

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

本人が別の記事で
> ストラウストラップ先生からのアドバイス
> あわてるな！　時とともにすべてが明らかになるのだから。
> よいプログラムを書くのに、C++のすべての詳細を知る必要はない。
> 言語機能ではなく、プログラミング技法に集中しよう。
と書いた上での記事というのも笑いどころ

**デフォルトの名無しさん** · 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
それについてはおまえがおかしい
その仕様が最も正しい
おまえの間違った仕様を書いてみろ