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

>>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にチェックしてもらう機能入れたらそこそこクソ記事は減るんでないかな。

やれやれ。間違った理解でドヤ顔している馬鹿を
久しぶりに見た。

具体的なこと言ってないんで何のことかわけわからんけど「切れない刃物では教育出来ないだろ？(ｷﾘｯ」の人かな?

"あたたたた"含まず追記していったらbofするじゃんよ
それとrandのlsb取るの良くないのは常識だよな

『メモリの動的確保はなぜ嫌われるのか？』に付けられたコメント
＞メモリリークを心配するレベルならメモリを静的に確保しようが自前で動的管理しようがどのみちバグは混入するだろう。メモリ枯渇が（上書きによる）メモリ破壊やバッファーオーバーランになるだけ。
＞そういった徹底的な開発スタンスが無いからmallocについてわざわざ説明するはめになるのでは？
＞そもそも組み込みだとmallocなんぞライブラリになくてリンクすらされないこともある。
＞逆にmallocが使えるような環境なら、今どきならrustでも使ったほうが良いだろう。c++でも正しく使えば十分に安全だ。
　
メモリリークって記事で挙げられてる嫌われる理由3つの内のひとつでしかないのに浅い理解してんなあ、コイツ。しかもRust信者ｗ

嫌われ者はなぜ嫌われるのか？

>>572
浅い理解はおまえさんだ
3つとも解決することを知らないとはな

＞3つとも解決することを知らないとはな
　
代替手法まで記事で説明されてんのにホントに浅い理解してんなあｗ

C++もRustも使えずCのみの環境があるからね
Rustが使える環境ならRustを使うべきだけど

『【C言語】ファイル操作』
　
動作確認してるんだろうか?

>>577
動いちゃう環境はあるべぇ（確認はしない。やれデバッグモード（の類）だと動くが最適化掛けると死ぬとかになりそうなやつ）

普通動かすまでもなく動きわかるだろ…

『なぜ私はAtCoderが全くできないのか』
　
クソコードを素早く書く技術は実務では求められないのでそれはそう

>>580
>・計算量への感覚が鈍い
>という事実はある。

ここはダメだろ
実務でもそこが鈍いやつは下手が多い

>>580
リンクくらい貼れよ
https://qiita.com/Shiro_Shihi/items/31b9e50abda41e4c2b71

テストケースが通ればクソコードでもおｋでエッジケースは大抵の場合考慮しなくて良いことになってる競プロは無意味。クソコーダーが変な自信をつけるという点ではむしろ有害。

Qiitaでないけどこないだ見かけた記事
『【c++】二分探索より速いisqrtを実装する』
　
コメ欄で指摘されてるがエッジケースでバグるのは競プロ出身者の書いたコードあるあるｗ

>>583
ほんそれ
わかります

そういうソートを早くしたいみたいな最適化もできない大量の寄せ集めの書いたクソコードを纏めてテストし動けばokばかりなのですがね

>>579
わかってない奴だからあんなコードになってんだろ

>>581
その通り
>>582 はカス

>>588
？

『functionalプログラミングって組込みに適さないかも』という記事への例の先生のコメント
　
＞「関数型プログラミングでは変数を持てない」との主張ですが、ものすごく違和感を感じます。
＞言いたいこととしては、「関数型プログラミングでは内部状態を持てない」なのだろうと思うのですが、それでも違和感を感じます。
＞「純粋関数型プログラミングでは内部状態を持てない」ならば、少しは理解します。
＞ちなみにGenServerについては、ご存知でしょうか？ ElixirやErlangにおいて、内部状態を持たせるための仕組みなのですが。
　
「純粋関数型プログラミングではないElixirやErlangには内部状態を持たせるためのGenServerという仕組みがあります。調べられてはいかがでしょうか?」みたいな書き方できないのかな?
つかメモリ食いすぎでGCも前提の関数型プログラミングが組み込み用途に向かないのは自明なんだが何でもかんでもElixirでできると主張してる先生の精一杯の揚げ足と思えば微笑ましいかｗ

>>590
そこじゃないだろ
まず変数とは何かを理解できていない

✕変数を持てない
○mutableな変数を持てない
○immutableな変数は持てる

関数型プログラミングでは「変数」の意味が違うしどこ視点の話だからそれは問題にすべき点ではない。

>>592
変数の意味は同じだ
mutable変数とimmutable変数を区別してimmutable変数のみを用いるのが関数型プログラミング

関数型プログラミング説明するのにmutable変数持ち出す人がいて腹が痛いｗ

mutable変数を用いないことが関数型プログラミングの特性の根源だぞ
それがメリットを生み出している

関数型に詳しくないから疑問なんだけど、純粋な関数型言語だと配列なんかも全てイミュータブルにするの？
例えば画像の変換みたいなことをしようとするときは、出力先に1画素を書き込むごとに新たな配列を確保する必要があるという感じ？

>>596
各言語の概念や仕様と実行コードの生成コンパイルは別だ
配列でもオブジェクトでも元の値が他で使われていなければ最適化により元の値を更新してそのまま使う実行コードを生成できる

『祝・実験終了 🎉 Linux カーネルの Rust 採用が正式化！ C から Rust へ ─ AI コードエージェントが Linux カーネルコードを書き換えるとどうなるか？』
https://qiita.com/hisaho/items/09362b9efdc5f21ab1f2

LinuxがRustをサポートってモジュールやドライバをRustで書けるようなったってだけで、既存のCコードをRustで置き換えようってものではないんだけどなんか勘違いしてるのかなこの記事。

記事の趣旨は「AIを使えばCコードを容易にRustに移植できますよ」というものだけど、記事自体AIに生成させたためかおかしな個所あるし、AI使っても人力チェックは重要だし容易なことではない証明になってるのは皮肉だな。

>>597
コンパイラではそういう最適化は無理くない？
Haskellにも可変な配列型はあるし、パフォーマンスが必要ならそれを使うでしょ

youtubeもqiitaもAI記事だらけになるとつまらんな
時間の無駄

Brainf**kの命令を直接実行できるCPUを作った話
https://qiita.com/yamatya6/items/3c75020110a73762a53f

WASM となかよくなりたいから Brainfuck をコンパイルしよう
https://qiita.com/tmyt/items/09c473aac186b772128e

スタックベースでmincaml to brainfuckトランスコンパイラ
https://qiita.com/vi_24E/items/43cddb54ece8fc5aa603

なでしこさんで大石泉すき言語のインタプリタ
https://qiita.com/mikecat_mixc/items/2e714dfb9895ea16f147

わたしがプログラミング言語の処理系を作れるわけないじゃん、ムリムリ！（※ムリじゃなかった！？）
https://qiita.com/ssuzzukki/items/5d86d38cb331d55a8ae5

brainf*ckをC++へトランスコンパイルすることで擬似的にbrainf*ckのコンパイラを作成する
https://qiita.com/rotarymars/items/3876ff5ab8f6effdeb1b

今月になってBrainf*ckの記事がなんでか大量投稿されてるんだが、一番高度なことやってる感じの(主観)WASMの記事がバグだらけなのは残念だなｗ

『ElixirChipの鼓動�B 70年間続くノイマン型の闇を抜けて 〜君は高速分散データ処理とエッジコンピューティングの未来を見る』に付けられてたコメント
＞すみません、お願いがあるのですが、piacerexさんの技術で作り込むことで実際にどれくらい電力消費を抑えることができたという実績を、先日のQiitaカンファレンスでお話しされていたと思うのですが、その数字をあらためて教えていただくことは可能でしょうか。目的は、高校生や大学1年生に向けて、モデルに合わせてハードウェアを作り込むとこんなに計算が早くなる、だけではなくて、どれくらい現在の地球規模の問題解決に貢献できる可能性があるか、を、概念ではなく数字で伝えたいためです。
　
こんな与太記事信じちゃうんだなあ、情報リテラシー低いなこの人。名前ぐぐったら神奈川工科大学 工学部 教授だそうだが。

都内に鯖置くより北海道に置く方が圧倒的にコスト下がるのは事実
極地でどうなるかは知らん
カムチャツカやアイスランドあたりで地熱発電で電力を供給して
自然冷却するのが効率良さそう

>>602
わかったうえでいじって遊んでんだろうよ

いじって遊ぶんなら
「36ページの表の2021年第3四半期発売 8コア16スレッドのIntel Xeon Silver 4309Yの性能(MOps/Sec)が58121で同年第4四半期発売16コア32スレッドのIntel Xeon Gold 6326の性能が69219っておかしくないですか? つかこれどういうベンチで測った値?」
とか
「ElixirFPGAの性能(MOps/Sec)が124890でx4機とx8機の場合は 124890x機数x0.7 にぴったり一致しているのは理論値ということですか?」
とか
「ElixirFPGAの性能(MOps/Sec)が理論値ということは実はまだ動いてないの?」
とか
「Mシリーズ搭載したMacやARMプロセッサ搭載の省電力サーバと比較してないのは何でですか?」
とかいろいろ訊くだろｗ

『【Docker】イメージは「PCのクローン」？ソースコードを内包する仕組みとメリットを解説』
https://qiita.com/ktdatascience/items/d4de099571a1d7d216f6
> (1) どこでも動く（箱そのものが動く）
> イメージの中に、OSの設定、ライブラリのバージョン、そしてソースコードの全てが入っています。
> つまり、この「箱」さえあれば、世界中のどこでも全く同じ動きをします。
>
> 自分の開発用Mac
> 同僚のWindowsマシン
> 本番環境のCloud Run

能天気すぎ。今はMacとWindowsで同じDockerイメージ使うにはかなり条件あるぞ。

> これにより、開発現場で最も恐れられる言葉**「私の環境では動いたのに（It works on my machine）」**を撲滅できるのです。

> Dockerイメージは、単なるアプリケーションの配布形式ではありません。
> 「動くことが保証された環境一式」をパッケージングしたものです。

使えるメモリ量やコア数の違いも動作に影響すんのになあ。あとAVX-512とか。
「Docker便利!万歳!」ってのじゃなくて、もっとはまりポイントについて議論を広げるべき。

エリクサーアドベントカレンダー２０２５シリーズ３の２４日に予定されてた『ElixirChipでGPUと生成AIの限界を超える』という記事きょうになっても投稿されてないなあ。
今度はどんな馬鹿なこと書くかワクテカしてたのに残念。

＞ElixirChip
ポエムばっかじゃん

『ElixirChipの鼓動�C AIとWebの電力問題と性能問題は同時に解決できる 〜君は高速分散データ処理とエッジコンピューティングの未来を見る』
　
過去に公開してるスライドを紹介してるだけのしょうもない記事でガッカリ。
相変わらず根拠も示さずに性能が何倍とか言ってんなあ、なんも動いてないだろｗ

ガノタ臭さがきっしょいなあ

＞4.2年、充電が不要なスマホとか、100日以上、飛び続けられるドローンのような「異次元級デバイス」が実装可能となります
　
仮にプロセッサの電力消費を0にできたとしても、液晶のバックライトやOLED、プロペラ回すモーターは相変わらずだからそんなもん不可能なんだよなあ。
これ本気で書いてるとしたら知能疑うレベルだが、「あれ?」と思わない読者向けの記事ということかな。

＞ここまで述べたノイマン型の課題を解決すべく、非ノイマン型が研究されていますが、実用になっているものは少なく、Google TPU、Perfered Network MN-Core、Graphcoreなど特殊目的向けの僅かのみです
　
Google TPUを知らない人が読むと「ふーん実験室レベルかな」と思うかも知れんけどTPUってもう何世代も改良が続けられて大規模に活用されてるもんなんだよなあ。印象操作が酷いｗ

構想を語ってるのか何ができてるのかサッパリ分からん記事だな。「２０２５年１２月リリース、某データセンターにテスト配備予定」なんて書かれてるスライドも貼られてるがどう考えても現実の話じゃないだろう。

>>611
QiitaもYoutubeもAI記事が増え過ぎでつまらんくなってしまった

>>614
あれもうダメだな

>>612
TPUが非ノイマン意味不明だな

ノイマン言いたかったんだろうな

フォン・ノイマン・ボトルネックの説明で

> 1命令毎のメモリアクセスがあり、

とか言ってるけど現代のCPUの行ってるメモリアクセス単位やアウトオブオーダー実行、スーパースケーラ、キャッシュメモリも無視してるよなあ。80386辺りの知識で何か言ってる感じ。

> アイドル状態でも40%近い電力をムダに食う

とも言ってるが現代のプロセッサは動作周波数動的に変えるしアイドル状態で40%とかってありえんわ。何言ってるのってレベル。

> ノイマン型のままでも、ASIC／SoC／FPGAはソフトウェア処理をHW化でき有望ですが、

SoC(System-on-a-chip)を何だと思ってるんだ? いまではSoCでないプロセッサを探す方が困難なくらいだが。「(FPGAのような再構成可能な周辺回路を伴った)SoC」は存在するが製品としてはあくまで特殊な存在で一般に言うSoCはそのようなものではない。

FPGA版ElixirChipというものが実際に完成して動作している雰囲気は全くないんだけど性能の数値挙げてXeon Silver 4309Yと比べて何倍速いと言ってるのも謎。
どうみてもCGの画像挙げて

> ElixirChipを気軽に「現場」に置ける、通信断でも止まらない「GENBAサーバー」と言うものを作ってみました

と言ってるのもわけわからん。

『ElixirChipの鼓動�D 「AIとコンピューティングの7つの課題」を解決した後に訪れる世界 〜君は高速分散データ処理とエッジコンピューティングの未来を見る』
https://qiita.com/piacerex/items/99ce566393e6aae67286

何が違うのか分からんが続きが投稿されてて草ｗ

前回の記事の後半を削って別記事にしたのか。無意味なことするなあ。
https://qiita.com/piacerex/items/27ec5b25ed15385598cd/revisions?id=BAhJIh1BcnRpY2xlU25hcHNob3QtMTU4OTQ3NDYGOgZFRg%3D%3D--93cf3b8c50bccfbff15dcdad6827713c8717bf17901be710cee7c1aabad87e72

『ElixirChipとElixirChip Liteで超低消費電力・高性能の世界へ』
https://qiita.com/zacky1972/items/960f67189705c388b3a7

ElixirChipってあの先生も関わってんだなあ。

> ElixirChipについては，Interface 2024年10月号別冊付録のFPGAマガジン特別版No.3のコラムに書かせていただきました．Kria KR260を用いて，積和演算について，理論上，最高速クロック周波数で駆動することに成功し，高い電力あたり性能を達成しました．その後の検証で，消費電力を実測し，実証した電力あたり性能としては254GOPs/Wを達成しました．これは同程度のプロセスルールであるIntel Xeon E3-1285 v6に対して，24.2倍の電力あたり性能です．
> さて，従来CPUでも，Elixirを導入することで，30倍の電力あたり性能を達成できます．下記事例では，300基の従来CPUを必要とするウェブ・アプリケーションを従来CPU10基に抑えることができたという報告です．
> これらを合わせると，726倍の電力あたり性能を達成できそうな計算になります！

FPGA上で積和演算やらせたら電力消費がどうだったという話と従来CPUより圧倒的に小さい電力消費でElixirが動作できるElixirChipができましたって話にはだいぶ開きがあるからこんな計算成り立たないんだがなあ、大丈夫かこの先生。

ElixirのVMであるBEAMを置き換えて爆速にするって大騒ぎしてたのはどうなったん?

https://qiita.com/search?q=ZEAM

なんか全然話聞かなくなったな。ElixirChipも完成も見ずに尻すぼみになる予感。

『ZEAM開発ログ2018年総集編その1: Elixir 研究構想についてふりかえる(前編)』
https://qiita.com/zacky1972/items/c9865f59259303d5f53e
> ZEAM はその名の通り，Erlang VM に代わる Elixir ネイティブな処理系として構想されました。当初構想では BEAM バイトコードと互換性を持たせるつもりでいたのですが，BEAMバイトコードの解析に難儀したことと，その後の議論で，バイトコードレベルの互換性は不要で，Elixir のソースコードレベルの互換性があれば良いという結論に至り，当初構想から大きく方向転換することとなりました。

あれ? 想像以上に技術低いなｗ
よくこれでFPGAに実装しようとか思ったなｗ

ここ最近はxの方に園児ニアが湧きすぎて
それまで最下層に見えてたqiitaが相対的に多少マシに見えてきた

>>625
下見るとほんと地獄みたいな知的障害者だらけ
自己啓発の餌って尽きないんだな

こんな糞スレでもム板で勢い2位なんだな
5ch終わってる😨

わざわざ見に来てなんか言ってるってｗ

>>627
今更w
5チョンなんてもう人いねーよ
なんだと思ってんの
知恵遅れてんの？
これまでどう生きてたの？

人がいない所に順位を上に上げるまでがんばって書き込んで
「わざわざ見に来るとは」とか
どういう人生をおくればこういう知恵遅れになれるのだろ

>>630
誰あてのレス？
今のところこのスレで知恵遅れと確定してるのは627だけど

知恵遅れは知恵遅れに気づかない

>>632
こいつは駄目だな
独自の世界が見えてそう

順位なんて気にして何になるんだよw

順位って何かと思ったから勢いのことか
普通は専ブラで見るから新規スレか閲覧済みスレの新着レスしか気にしないよ

クソレスで勢いだけ上げて気にしてないからいいよ
とか世界線が違うからそれが普通なんだろうね

そもそも観てるものが違う
youtubeのおすすめ動画も
そいつの知能にあわせて
観える世界が違う

『性能が微妙な中古PCを販売するくらいなら中高生にくれてやれ』
　
他人の資産を「くれてやれ」ってアホかｗ

『【プログラミング】C言語で使ってアセンブリ言語の勉強する方法』
　
いまどき珍しい感じのアセンブラ言語の記事。
「簡単ですよね？」「これでも未だ簡単ですよね？」「全体として、それ程難しくありません。」等と言ってる割に所々間違ってるなｗ
近頃はこういう記事の粗探ししてくれる人Qiitaにはいなくなったね。
　
同じ人の
『【プログラミング】ビット演算の解説』
　
こっちはコメ欄盛り上がってる感じ。

みんなそんなに暇じゃないしな

『C言語 string.hの自作実装 (順次実装)』
https://qiita.com/Pomme-libre/items/27e55ad98817ba9855b7

・mystrlen.cとmystrlen.hで関数の引数型が一致していない
・mystrlen.hでsize_t を使ってるがstddef.hをインクルードしていない
・printf()でsize_tの値を出力するのに%lldを使ってる

「雑なコードだなあ。こんな記事に「いいね」する人いるんだ」と思ったら例の先生ｗ

kaizen nagoya最近おとなしいね
クソ記事量産して運営から制限かけられたのかな

昔のCPUのC言語は引数スタックに積むから判り易かったんだが
最近のはレジスタ渡しで追い掛けるのがちと面倒(判らん訳じゃないが)

>>641
printf()でtime_tや_time64_tの値を出力するときは%lldで良いの？他にもっと良いのある？

出力したい値が符号付きなら出力フォーマットは%jdを使い、出力したい値はintmax_tにキャストすればおｋ

>>642
あいつChatGPTの出力貼り付けるだけになってたし力尽きたんじゃないかな

Qiitaから消えたと思ったらZennで暴れてたわw

>647
どうぞ
https://mevius.5ch.net/test/read.cgi/tech/1657839892/

キータももうオワコンだね

https://mevius.5ch.net/test/read.cgi/tech/1657839892/29
> 29デフォルトの名無しさん
> 垢版 | 大砲
> 2024/12/29(日) 01:55:29.01ID:hB4L1r8r
> Zenn記事で権威ある有名企業の記事にマサカリ投げられない
> って思って気づいたがそういう企業ってマサカリ多いQiitaでなくZennに行く
> Zennはマサカリの怖さがない
> 心理的に安全

たった1年前だがQiitaってそんなマサカリ恐れるようなとこだったっけ?

『「0.1+0.2≠0.3」を説明できないエンジニアがいるらしい』
https://qiita.com/higashi_nc/items/9a5ea00415a008f06843

↑は2年前の記事で盛大にマサカリ投げられているが1年前にはもうだいぶQiitaも衰退しててマサカリ投げるモヒカンも減ってた気がするが。

どれこれ関係ない
Stack Overflow をも壊滅させるビッグウェーブだから全滅もある
https://data.stackexchange.com/stackoverflow/query/1926661#graph

>>650
QiitaとZennを比較したレスをもとにQiitaを時で比較するのは公正でない

『Hello World あたたたた LuaJIT編』
　
バッファオーバーフローする可能性のあるコードをなぜ広めようとするのか?

元の記事『Hello World あたたたた 11日目 C編』がクソだと可視化されないと派生が生まれるというのは本当に不幸よなあ。

5chもゴミだらけだけどQiitaもそれ以上に酷い

『Hello World あたたたた C編 その2』
　
『Hello World あたたたた 11日目 C編』のstrcatでバッファオーバーフロー起こす可能性について対処してるのは良いが「コーディング例」として挙げられてるコードも微妙だなー。
hako_capを4倍する処理でオーバーフローが考慮されてないしoffsetの計算もsize_とintの値ちゃんぽんに計算してintに代入してる。「“規定のロジック”を逸脱してもよいならこう書くべきでしょう。」として掲載されてるコードも"た"が最初っから延々続いた場合 ta_count + 1 がオーバーフロー起こすロジックバグがある。
どうしてこんな記事を公開してしまうのか。

そんな欠陥言語Cに拘る人たち

ロジックバグは言語関係ないんだよなあ

『【アセンブリ言語】x86-64 vs AArch64 vs RISC-V vs Power ISA』
＞又、RISC系の3つでは.asciz（NULL終端ASCII文字列）を使っているのに対し、x86-64では最後に, 0を付けてNULL終端にしている点も注目して下さい。
　
writeで出力する文字列の終端に'\0'置くのは余計なんだがよく分かってない人みたいね。

write呼んでexit呼んでアセンブリ言語でハローワールド書けましたってこの手のQiitaの記事で、writeのシステムコールが返す可能性のあるエラーに正しく対処してるの見たことないな。

どうせおまいらprintfの戻り値確認してないだろ

printfが返すのは出力する想定の文字数であり出力が中断されることも想定の内のwriteシステムコールとは事情が違うんだゾｗ

出力したからと言ってすべてを表示するとも限らんだろうに

昔はよくQiitaを参考にしてたけど最近「～みた」「～話」系のゴミ記事が増えてSTACKOVERFLOWレベルの使えないサイトに成り下がった

比べるならcode projectじゃねえかなあ
もうない

stackoverflow日本語のは糞だけど英語のはマシだった記憶があるが今は違うのか

『Qiitaのはじめかた』
＞Qiitaにアカウントを作成すると、つぎの機能を利用できます。
＞記事を投稿する
＞記事に「いいね」する
＞記事を「ストック」する
＞ユーザーやタグ、Organizationをフォローする
＞編集リクエストを送る
　
コメントが挙げられないのは非推奨機能だからかな？

技術的な指摘や議論の場としてコメント欄が使われるため、感情的・攻撃的になりやすく、その結果として利用規約やコミュニティガイドライン違反になりやすい
意見が割れるテーマの記事には多くのコメントが付き、口論や誹謗中傷に発展しやすい

編集リクエストって「お前のバカ記事直してあげたからこれに更新しなさい」って機能だしコメ欄よりよほど攻撃的な使い方できるけどね。
まあ記事主側が一方的に拒絶できるし送る側も徒労に終わる可能性理解してるから大幅に書き換える編集リクエストを送る奴もおらんから誤字やタグ修正くらいにしか使われてはいないけど。

Qiita Woman Summit supported by パナソニック コネクト
https://increments.connpass.com/event/375321/
> 【基調講演：ちょまどさん登壇】性別・職業区分問わず、どなたでもご参加いただけます！

目玉がオタサーの姫だった人かあ。

そんなこと気にしてるのはお前だけじゃないかな

Xamarinを使うなら人脈が重要と君臨しておられた偉い方ですよ

まだそれ擦ってるんだ
お大事に

何開発したでもない万年初心者みたいな人だけどいまだに有難がってる人がいんだねｗ

>>671
妊娠中の大きいお腹をインスタに挙げてた人かな

Xamarinのインストールだかビルドが難しいとかで
知ってる人に教えてもらわないとどうにもならんのを
「Xamarinするには、まず人脈♪」と揶揄されたのを
俺の発言みたいに広めるな！と件の人が騒いで
騎士団も同調したんだっけか?
製品の不評なところは社内でフィードバックして
改善に努めるとかそんなんじゃないのね。

>俺の発言みたいに広めるな！と件の人が騒いで
>騎士団も同調したんだっけか?

君認知歪みすぎじゃないか

＞正直言えばXamarinと人脈については全く関連はないと思ってるのが正しい技術者なのでいいと思う。ただちょまど氏が神なのは否定しませんけどね。
　
騎士団の中ではコイツが一番キモいかな。

＞私の不在中、そのような内容のスライドに私の名前が使われたらしいのですが、
＞私はそんなことは言っていません。
＞
＞この話はこれでおしまい！
　
おしまい！って、製品の改善に言及してなくてﾜﾛﾀｗ
MSのエヴァンゲリオンやっててこれｗ

何号機よ？

>>680
これは恥ずかしい変換ミス
やっぱ憂さ晴らしで人を叩く奴って知能が…

囲んでおめでたうゆってやろう

>>683
？

徳弘の元ネタも知らんくせに炎上させんなのやつ

何言ってんだこいつ

もしかしてエヴァンゲロリスト

『大学生エンジニア Rustの勉強を始める 🦀』
https://qiita.com/kohta9521/items/082317eae9d2a9d3bd6a
> 1. 非CS専攻（法学部）としての「低レイヤー知識」への渇望

> 🎓 法学部としてのコンプレックスと渇望

> 私は法学部法学科に所属しており、大学でCS（コンピュータサイエンス）を体系的に学んでいません。

> 法学部出身の私にとって、低レイヤーの専門用語（スタック、ヒープ、ポインタなど）は高い壁です。

> 法学部出身の私が、ポインタやメモリ管理といった低レイヤーの概念と格闘している「ありのままのログ」です。

> 「法学部卒で普通のフロントエンドエンジニアにRustなんて無謀だ」と思われるかもしれません。

法学部アピール多すぎない?
まだ卒業してない身で「法学部出身」「法学部卒」って頭良くはなさそうだけど。

> 私は法学部法学科に所属しており、大学でCS（コンピュータサイエンス）を体系的に学んでいません。
> プログラミングにのめり込めばのめり込むほど、CS専攻の方々が持つ「メモリ管理」や「DBの内部構造」といった基礎体力の差に悔しさを感じてきました。
>
> フロントエンド（TypeScript/Next.js）だけでは見えにくい、 「裏側で何が起きているか」 を理解したい。そのためには、ガベージコレクションがなく、メモリを意識せざるを得ないRustこそが、今の私に最も必要な「矯正ギプス」だと確信しました。

Rustの勉強が低レイヤの学習になると思ってるみたいだけど言語の学習以前にコンピュータサイエンスの学習を意識された方が良いと思うね。

これが今のQiitaのレベルなんだよ
もはや読むに値しない

同じ人の記事
　
『[ Rust学習 ]大学生エンジニアによるマクロとはなんぞや？』
　
よく調べず憶測で分かった気になってる感ハンパないんだがｗ

aiが書いた文章の肥溜め

内容USO800で
｢法学だからCSやらなくていい｣は傲慢だな
言い訳に聴こえる

AIルシファ

直接言ってこい

『プログラマはドメインの実装に集中すべき』
　
記事主はコミュニケーション能力に難ありそうなのに主張が強いのはまあ荒れるかな。

>>696
その人が理解してる狭い範囲で書いてるから間違いが多くなってるね
例えばオブジェクトを返すために「ポインタが必要になります」という件
Rubyなどでは常にGC領域に確保したエリアを指すポインタやfatポインタになってることを知らない
むしろポインタを返すか値を返すかの選択指定ができないRubyなどの言語こそ「ポインタが必要になります」なのにね

>>696
クラスが良いものとされていた過去の言語と、
クラスは良くないとされている現代の言語を比べてるんだな。
そのケースは共通メソッドPay()を呼べれば良いだけのようだから、
クラス継承関係の必要はないためクラスは不要だが、
そこも理解せずになぜかクラスを絶賛していて草。

『なぜあの人と話すと仕事が止まるのか。』
　
責任を避けたいのか指示や説明に曖昧な表現をする人は実際いて、記事では良いこと言ってると思うんだけどもコメ欄見ると曖昧支持派が案外いるようで意外な感じ。そんなんで仕事効率よく回るのかな?

そもそもの話として指示してる側がよく分かってない場合まであるかな。

ネットwatch板に行けや板違いのクソジジイども

会話・チャットでやり取りをしていて、「なんか、このひと面倒くさいなー」とイライラすることがある。
イライラするだけなら、まだ我慢できる。けれど、それが仕事に支障をきたすのであれば話は別だ。
─── で、そういう場面は珍しくない。
そういうひとのことばを観察していると、あいまいな表現が多いことに気が付く。
それで、会話の回数が多くなって生産性が落ちたり、認識の齟齬が生まれて作業のやり直しが発生したりしている。
結論：
コミュニケーションコストは低い方がよい。
仕事の文書は多義性をもってはいけない。
「あいまい」な表現は避けるべき。
今日はこういう話をする。
「あいまい」なひとたち
日々の仕事のなかで、あいまいな表現（意味がひとつに定まらない状態）を意識して探すと、その多さに驚く。
例えばこんな具合だ。
↑
抽象的な会話が出来ない人かなー

本田勝一
外山滋比古
ああそういうことか

コミュニケーション能力の低そうな奴ｷﾀｰ(AA略

noteに投稿すれば利益でるかもしれない情報を
なんでわざわざQiitaに無償提供しないといけないんだよ

>>702
本文読んでないけど「その多さに驚く」「たとえばこんな具合だ」とかはGPT構文

>>702
主張の甘さはともかくすごく読みやすいよく出来た文章
現時点のプログラミング能力が低くてもよほど高い技術力を求める職種じゃなければ書類選考は通すかな

『TRONはマイクロソフトのOSよりも開発が遅かった』
　
> TRON をリアルタイム OS というのであれば、Windows もリアルタイム OS です。
　
とか言ってて草ｗ

Windows CEは現行品じゃねえからなあ…

『アセンブリ言語を学ぶことで得られるメリット【アセンブリ言語さくっと入門】』
　
雑な記事で間違いも散見されるけどこんな記事がいいね多く貰えるのかｗ

サルでも判る
猫でも判る
こんなのがベストセラーですし

QiitaってCSS/HTMLの埋め込み出来んのね
なんつー不便な
外部サイトをEmbedで埋め込めばいいんだけど
自前で提供してほしいなあ

CSS埋め込むとCSSに攻撃されます

>>712
Qiita Discussions へようこそ
://github.com/increments/qiita-discussions/discussions

投稿したら運営が必ず返信してくる有用サイトを教えてあげる

>>714
リンクもまともに貼れないのか…

>>715
バカで草
5chは初めてか？

>>716
直リンクなんて今は誰も気にしないよ
おじいちゃん

>>717
横だが
ほんとに何を間違えたか分かってないのか、
分かってとぼける為に編み出した言い訳なのかどっちだ？

Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない

https://youtube.com//shorts/Z8y4gXpQbKw

>>718
ジジイ乙

>>720
みいちゃん…

最後に出てくる「みいちゃん」は、過去に5ch（旧2ch）で起きた有名なコピペや「知ったかぶりをする初心者」を揶揄する文脈で使われるネットスラングです。
「君は何も分かってない初心者（あるいは痛い人）だね」という強烈な皮肉を投げ、議論を打ち切っています。

直リン派の認識
利便性と現代基準 今のブラウザやアプリはセキュリティが強く、多くの掲示板アプリ（専ブラ）は `ttp` でも自動で補完してリンク化します。
「h抜き」はもはや二度手間を強いるだけの無意味な儀式に見えています。

h抜き派のに認識
5chには「リンクの先頭の `h` を抜く」という古い慣習があります。
これはかつて、不用意なクリックによるブラウザクラッシュ（ブラクラ）やウイルス感染を防ぐための自衛手段でした。

この状況をAIに解説させて思ったがなぜhttp抜いたか分かってないんじゃない？
ブラクラやウイルス感染を防ぐためじゃなく5chでURL規制で貼れないことが多くIP規制になることもあってhttp削除
714以外は他人の投稿でこのスレをあまり見ないからここでhttp削除の必要がなかったとしても気にするつもりはない
リンクを貼りたいなら貼りたい人が貼り直せ
そこまでリンクにこだわるならなぜおまえが貼り直さない？
おまえがQiita Discussionsに投稿するかは気になるがリンクのことはどうでもいい
小さいことにこだわるやつだな

規制とかどうでもいいわなURL貼れないならそもそも書き込みを諦めればいいだけだし

http削ると貼れたりするから諦めなくても大丈夫

リンク貼ったら一発退場が懐かしい

『C言語とアセンブリ言語の実行速度を比較する』
　
printfで整数値を10万個出力するのに
・アセンブリ言語からprintf呼び出し→約7秒
・C言語からprintf呼び出し→約40秒
　
ちょっとあり得ん結果になってるんだけど考察もなく終了という気持ち悪い記事。

Cでcountをレジスタに割り当てたら速くなるんかな
最適化するだけでもっと速くなるかな

実行環境が違っててconsoleの性能差だったら笑う

__stdcall と __cdecl か

>>726
Cコンパイラで*.asm吐いて比べてほしい記事やなあ

consoleの差に一票

『C言語にも配列のlengthプロパティをください ― 配列ポインタ型でサイズ安全な関数引数を実現する』
　
フツー構造体を定義するところを一見便利そうでその実不便な方法を提案する人

>>732
どんな構造体を定義して何をするつもり？

分かんない人は黙ってれば良いのにｗ

>>732
その記事のやり方が正しい
それが静的な型チェックも実行効率も共に満たす方法

chatgpt様に訊いてみた
　
＞技術的な評価（ざっくり）
＞この記事の主張は Cの仕様としては正しいです。
＞ただし実務では多くの場合：
＞・void f(uint8_t *buf, size_t len)
＞・sizeof(array)/sizeof(array[0])
＞・マクロ
＞・_Static_assert
＞などで処理するケースが多いです。
＞理由は単純で
＞・uint8_t (*buf)[N] は APIとしてかなり使いにくい
＞・可変長配列や動的メモリと相性が悪い
＞からです。
　
「uint8_t buf[BUF_SIZE]が意味あるデータ構造なら要素数で区別するのではなく構造体に定義した方がまとまり良いし保守性も向上する」とか言わなかったのは意外な感じ。

#define _countof(array) (sizeof((array))/sizeof((array)[0]))

>>732
あほやん
これでも良いけどさ→(*buf)[i] = (uint8_t)0x00U; /* ポインタを一段デリファレンスしてからアクセス */
これと等価やで→buf[0][i] = (uint8_t)0x00U;
蛇足→0[buf][i] = (uint8_t)0x00U;
しかも結局buf[1][i]とかにもアクセス出来るので根本的な解決になってない

実行効率も落ちるんじゃね

>>736
それは悪手

>>732 が本気で便利なら40年50年あるCの歴史でそのやり方が主流にならないはずがない
「フツー構造体」は違うかも試練が「不便な方法」は同意

記事主がコメント欄で
　
＞＞特定の要素数を前提とする場面なら struct が手っ取り早いような気がしますが，どうなんでしょう？
＞
＞ご指摘の通り、自分の触っているコードベース上でも struct でサイズと buf をセットで持たせる設計が一般的で、筆者自身もそちらを採用することがほとんどです。本記事は「素の配列をそのまま渡す設計を採用した場面で、型にサイズ情報を持たせる手段がある」という紹介にとどまるものでした。ちょっと自分の書き方が一般的と誤解させるような内容になってしまいました。気をつけます。mm
　
と書いてる通り一般的方法ではないんだけど>>735みたいのもいるのは世の中広いなｗ

配列の配列
配列のポインタ
であればどちらも一般的な訳で

>>742
それは二つの違いをわかっていない
その「struct でサイズと buf をセットで持たせる設計」はファットポインタ
つまりアドレスと長さの両方を持つことで可変長のものを受け渡しする方法

一方で今回は固定長の配列
長さを関数呼び出しなどで受け渡しする必要がない
structでサイズを持って受け渡しすることは無意味で無駄で非効率になる
この違いがわからない初心者なのだろう

おっプログラミングの経験ない人か。本当に居るんだねｗ

uint8_tの要素数が3のRGBもYUVも区別できなくて問題ないって人かあ。

ラッピングは型安全性やカプセル化のためプログラミングの常識だが
今回の問題では一切関係がない
ラッピングすることなくそのまま成立する

無関係なラッピングを持ち出しそれに固執していることからも本質を理解できていないとみえる

「そんなクソな書き方しねぇよ」という話が理解できない人いんのねｗ

今回ラッピングなんかはどうでもよくて根本の話は>>742だよね
可変長ならば先頭アドレスと長さをセットで持たなければならない
固定長ならば先頭アドレスのみ持てばよくて長さは型情報として持つべきである

ID:IinJ/Cgwはashworthかな

そこは各型のデータが持つ情報により3つに分かれる
①アドレスのみ
②アドレスと有効長
③アドレスと有効長と容量

①は単体もしくは固定長の連続体
②は可変長の連続体
③は可変長の連続体で伸縮可

①の連続体の場合はその固定長の情報は型に含まれるため受け渡しする必要がない
記事『配列ポインタ型でサイズ安全な関数引数を実現する』が述べているのはそういうことで正しいが説明不足だな

『C言語の標準ライブラリを自作して学ぶ、安全なメモリ管理と文字列操作の真髄』
https://qiita.com/toranoko/items/f3f01e99f0132558a128

オーバーフローチェックは重要、みたいなこと書いてるのに

> // 実データの前に size_t 分のヘッダ領域を確保
> block = malloc(sizeof(size_t) + size);

冒頭のコードでオーバーフロー無視してるのはなあ、無能すぎね? つか42tokyoかあ。

>>756
これで満足か？

#include <stdckdint.h>
size_t total_size{};
if (!ckd_add(&total_size, sizeof(size_t), size)) {
　block = malloc(total_size);
}

>>757
？

C23でようやく標準化されたオーバーフローチェックなんて99%のプログラマーが今後も知らないままだろう
標準化があまりにも遅すぎた
C++23の新機能も同じだ
みんな知らない学習する気もない使う気もない広まらない

>>757
> これで満足か？
　
その記事のおかしいとこそこだけだと思った?

>>759 expectedが追加されてるけど、例外使いまってる既存資産から置き換えも考えずらいし、新規で使うにも別にC++じゃなくても良くね？な型。

CとC++の標準拡張が連携とれてないよな
この言語はもうダメだ

>>762
言語は思考を規定する

>>756
> C言語を学び始めると、標準ライブラリ（stdio.h, stdlib.h, string.hなど）の便利さに気づきます。しかし、その内部で何が起きているのかを意識することは少ないかもしれません。
>
> そこで私は、C言語の標準関数のゼロから再実装に取り組みました。

とか言っててft_mallocの実装mallocのラッパーになっててｸｿﾜﾛﾀｗ

> 1. メモリブロックへの「メタデータ」埋め込みによる ft_realloc の実装

glibcならmalloc_usable_sizeでメモリーブロックのサイズ取得できるのに車輪の再発明だなあ。将来的にmalloc部分も自作するとしてメモリーブロックのサイズはどっかに格納すんだしmalloc使ってるならmalloc_usable_size使うで良かろう。
ft_reallocもメモリーブロック再割り当て必要ない場合も常に新しいメモリーブロック割り当てるし第1引数にNULL渡された場合も考慮されてないなあ。
よくこんな記事スクール名誇らしげに明記しながら公開するもんだわｗ

> これで満足か？
>
> #include <stdckdint.h>
> size_t total_size{};
> if (!ckd_add(&total_size, sizeof(size_t), size)) {
> 　block = malloc(total_size);
> }

記事主のレベルに合わせて
if (size > SIZE_MAX - sizeof(size_t)) return NULL;
で良くね?

>>757
> 2. 線形リストの動的管理と「ポインタのポインタ」の威力

> ポイント：
> なぜ t_list ** なのか？

なんて書いてるけど、理解がハンパだからft_lstadd_backの実装クソダサいことになってるなｗ

>>766
レス先が間違ってるのか何の話やらさっぱりわからん

誤)>>757
正)>>756

文字種による組み合わせの数
ASCII文字列に限定して組み合わせの数を考えてみることにします。
アルファベット大文字: 26 アルファベット小文字: 26 数字: 10 記号(印字可能な記号類): 32 使える文字種は 94種類となります。
これらを使って 4桁のパスワードを作る場合の組み合わせの総数は*通りあります。
しかし「大文字・小文字・数字・記号を必ず1つずつ含む」という条件を課した場合には、
各文字から1文字ずつ抜き出した組み合わせの並び替えを考慮して*通りになります。
見た目は「複雑さが増した」ように思えても、実際には総当たりに必要な総数は15分の1に減少してしまいます。
NIST SP800-63の草稿を書いた ビル・バー(Bill Burr)氏6はウォール・ストリート・ジャーナルのインタビューに対して
「今では自分がしたことを後悔している」と述べ、英大文字・小文字・数字等の複雑な組み合わせを提言したことを悔いています。

2026/3/25 10:46 9回答 至急です！
中学校の先生をしている私の友人と食事に行った時に、友人が「業務が多くて大変…何か便利なパソコンのソフトというか、
痒いところに手が届くようなシステムを誰か作ってくれないかなぁ…」とボソッと呟いていました。
私はどんなシステムだといいの？と聞いたのですが、具体的には今思いつかないとのことでした。
私はExcelなどでシステム（？）を作ったりするのが好きなので、その友人の力になればと思いました。
そこで質問なのですが、先生方の日々の業務の中で、「こんなシステム、アプリがあればいい！」
「こんなシステムがあって便利だった！」というのがあれば教えていただきたいです。
※個人で作れる範囲でお願いします…
あくまで先生方の業務を助けるものなので、授業 を勝手にやってくれるアプリなどは違います。

https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11326593111
リンクくらい貼れよ無能

そのURL、まさに正解です！鋭いですね。

AIの上から目線ωωω=2πf

しょうもない記事量産して組織票してそうな会社あるけどqiitaはbanしないのかね

ゆめみ？児相？

AIに生成させて自分は見返してもないようなのポストするだけのゴミ山で
しょうもなくないものなんてあるのか？

ゆめみだと10歳娘とかいうきっしょいSSと猛虎弁で記事を連想してるやつの悪印象がつよいな

youtubeもだいぶAI汚染されて来た

『C言語で学ぶ低レイヤーメモリ管理！！(憧れの低レイヤー)』
https://qiita.com/kmtech/items/6e601c74577e6060dd63

GoやTypeScript使ってる人からするとスタックやヒープの話が低レイヤー扱いになるというのは文化の違いなのか? コイツがアホなのか?
いろいろ間違ってるけど

> ローカル変数の寿命が関数の終了とともに尽きる理由は、関数からリターンする際にスタックポインタが戻り、フレームが論理的に消滅するためです。

が一番酷い。言語仕様的にはローカル変数の寿命はブロック内と決まってるのに実装で理解しようとしてる。

どうみてもアホい

> 1. メモリレイアウトの構造（セグメント）
> プログラムが実行される際、メモリは大きく分けて以下の5つのセグメントに分割されます。

ROのデータ領域もあったら良かったね

> 3. ポインタの本質：メモリアドレスの操作
> ポインタは単なる「メモリアドレスという数値」です。

C言語はポインタ型により構造が違うことも認めてる言語なんだけど

> 5. データ構造のレイアウトとアライメント
> CPUが効率よくデータにアクセスするため、構造体のメンバ間には「パディング（隙間）」が自動的に挿入されます。

環境依存の話を世の中の理みたいに説明されてもどうなんだか

> 7. デバッグと解析ツール
> 低レイヤーのバグは人間が見つけるのは困難ですが、AddressSanitizerなどのツールを活用することで自動検知が可能になります。

サニタイザで不具合が見つかるかは希望的な話でしかないんだが

規格を確認したりしないで見えてるものが世界のすべてと考える人っぽいな

偏見だらけでやばいなこいつ
https://www.youtube.com/@nandemo-soken

Qiitaにおいて「個人開発」タグとAI関連タグの両方を紐づけた記事数は、2025年を境に急激な伸びを記録しました
「AI自らが論理的に思考し、複雑な工程を完遂する力」の社会実装が進んだことが、開発現場におけるAIの役割を決定的に変えたと考えられます
エンジニア個人が「コードを書く」のではなく、「AIに指示を出してレビューする」スタイルが定着しました
://corp.qiita.com/releases/2026/04/trend-announcement/

そうは思わんが

>>783
URLもまともに貼れないのか

有料AIはまともなコードはくのか？
無料のはレビューしないと使えんもの多い感じ

レビューしてるかは相当怪しい
レビュー以前に生成物を自分で読み返しもしてない

新語の布教
AIスロップ（AI Slop）とは、生成AIを用いて思考停止状態で大量生産された、低品質で無個性な文章、画像、動画などのコンテンツを指す俗語です
英語で「残飯」や「汚水」を意味するslopに由来し、ネット空間にゴミを撒き散らすようなスパム的投稿が、SNSやブログで急増している問題を指します
QiitaはAI slop？

よわよわ初学者を囲い込みたい人の数だけ利益増える系企業がくだらない記事量産して組織評するだけのサイトと化してる

最初からそうだった

素人が聞きかじりと独自解釈で記事書いて
それを別の素人に読ませるんだから悲惨の再生産でしかない

マサカリ投げる人を見なくなったのは運営が排除したんだろうなあ

AI記事にマサカリ投げるAI作らねえとなあ…

誤情報を別の誤情報で上書きしてやる！

知らないのは知らないと言った方が良い
AI:
まったくその通りですね。無理に知ったかぶりをするよりも、
「知らない」と正直に伝えた方がお互いに誠実でいられます。
今後は、不確かなことや把握していない情報については、
ご指摘の通り素直に「わかりません」とお伝えするようにいたします。
いつでも遠慮なくご質問ください。

QiitaはAIチャットの進化で完全終了

どっちもアホならAIのがマシだな

健忘症AI

毎回bingでググってんだけど、なんやねんこの鶴
https://i.imgur.com/A2YFdhp.jpeg

>>799 POSIX関連を多く投稿してる人のアイコンっぽい

>>800
ほえー
長年の疑問が解けた

>>799
マイクロソフトの検索エンジンはかなりのポンコツだぞ？

書籍の内容のまとめとか、就活生の自己アピールみたいなのは読み物としてはゴミでつまらん。他で扱わないネタやオリジナリティのあるもので勝負しないとサイト丸ごとゴミの山になって終わるな

bingで検索すると出やすいよなqiita

bingでアマギフ乞食しとる
楽天ポイントも出てるが品切れだとよ

プログラミングを楽しんで書いた人の記事がなくなった

bingが糞なのは完全に同意だけどyahooよりはマシかも知れない

てかここqiitaのスレだった

>>807
ヤフー検索は少し仕様を変えただけのGoogle検索

なら、duckduckはbing

最近はQiitaよりredditの外人のスレのほうが引っ掛かる感じ

2025年のLikeの中央値は0だぞ！！！
遷移は明確に右肩下がりソースzenn.dev/mima_ita/articles/f78dcbef2a81d3

他人の記事にいいねなんてしないんだよ
お前らは仲間いいねをつけた工作記事宣伝記事を見せられてるだけ

一応QiitaはRSSで気になる単語をピックアップしてみてたけど、本当AI生成記事しかないからやめちゃった
他なんかないかな

>>813
企業研修の担当者が仕事の心掛けを就活生に語るのとかあるぞ。一般人にとってはゴミ記事だけどw

>>813
Qiitaしょうもない日はspeaker deckとかdocswellはたまに見る

Qiita見るくらいならRedditでも観たほうがマシ

広告の少ない無料techブログとしての利用価値は高い

まともな人間はアドブロック入れてるんだよ

スライド共有サイトは、まだQiitaとかZennに比べたらAIスロップはマシそうだな
とはいえ、もうAIでスライドも作れる以上はあんまり無事なのも長くないかもしれないが
自分もこのへん見るか

株式会社アイ・エス・ビー
https://kizuna.5ch.io/test/read.cgi/infosys/1756826944/

https://special.nikkeibp.co.jp/atclh/ONB/24/isb0809/

>>820
マルチポストか？
首吊って死ね

kaizen nagoyaようやく静かになったな

とはいえQiitaはもうゴミ溜めになっていた

kaizen nagoyaはzennに住処を移したんだっけ？

飽きたらおしまい

会社説明会での欲しい人材だの研修での仕事への取り組み方だのは自社内でやれよクソが、公共の場所でしかもトレンドがついてトップページに出て来て目障りなんだよ馬鹿

ActiveX なんて単語久しぶりに観たわ

>>826
誤爆か？

>>826
VSCodeスレから来たんかな？