C言語なら俺に聞け 163

2024/07/16(火) 22:43:54.18

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 162
https://mevius.5ch.net/test/read.cgi/tech/1698653580/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/06/30(月) 11:37:57.93

外食に飽きると自炊を始めるものだよ

2025/06/30(月) 12:00:43.86

そろそろc談義したいぞ…

2025/06/30(月) 13:32:07.78

C/C++は、(レンタル)サーバーサイドでも、ソースコードを盗まれないというメリットがある。

2025/06/30(月) 13:49:28.37

PHPは一見便利なように見えても、何をやっているのか不安が残る部分がある :
・文字コードの扱い。勝手に変換される可能性。それが脆弱性の原因になる可能性がある。
・SessionID の管理のされ方。それがブラックボックスで余り説明が無いので危険。
・文字列が「長さ指定文字列」と「0終端文字列」との二種類あり、デフォルトは前者だが、
正規表現系は後者である場合があり、それを知らないと脆弱性の原因になる。

2025/06/30(月) 18:59:51.22

最近はFPGAでコンピュータ作ってるけどメモリが4kbytesとかしかないのでC言語があると助かります。

2025/06/30(月) 20:50:19.20

アセンブラ使え

2025/06/30(月) 20:56:51.68

そこまでのキツい環境ならC使わずにアセンブラ使えって思う

2025/06/30(月) 20:57:51.84

その規模なら C で書くにしても配慮すべき低レイヤの事情がありすぎてあまり C の甲斐がなさそうだと私も思う。

2025/07/01(火) 02:30:13.65

PHPの文字列は、1つの文字列の中でも、文字によってバイト数が異なるそうだ。
だから、$str[$k] の $k は、文字単位ではなくバイト単位。
文字単位で指定したい場合には、
mb_substr($str, $k, 1, "UTF-8")
とするとのこと。
文字列の終端には一応 0x00 が入っているが、文字の長さはバイト数で管理されており、0を
終端とはみなしていない。だから、文字コードが 0x00 の文字も文字列の中に含めることが可能。
$str = "こんにちは";
echo strlen($str); // バイト数（UTF-8なら15）
echo mb_strlen($str); // 文字数（5文字）

ところが、正規表現を扱う場合には、0x00 のバイトが含まれていると、文字列の終端と
みなされることがある。だから、ユーザーによって入力された文字列を正規表現で
安全チェックをしたつもりでも、文字列の途中に 0x00 のバイトが含まれていて、
それ以後に危険なコードをが含まれている倍がある。

C言語で作っていれば子の様な齟齬は起きない。

2025/07/01(火) 05:48:42.66

>>859
× > PHPの文字列は
○ unicodeは

× > C言語で作っていれば
○ asciiに限定すれば

お前は基本的なところがまるで理解出来てない
そもそも文字コードの話なのだから、どの言語でも同じ
特定の言語を使用すると回避出来るとかいう話にはなり得ない

2025/07/01(火) 06:18:52.12

と思ったが、もしかして最近の言語はutf-8をネイティブサポートしていて、(＝内部文字列がutf-8)
この辺を全部自動的に回避出来るのか？（＝プログラマに文字コードの知識が全く必要ない)

Cはutf以前だから勿論サポート無し
PHPはWeb言語だから文字列＝バイトストリーム扱いで、共用体が駆使されるネット向けになってるだけ
JSはutf-16だったがサロゲートペア導入でAPIが2つある(サロゲートペア対応版と非対応版)
Rustは知らんが、さらっと調べた限りutf-8で、逆にインデックスアクセスが出来ないらしい(3文字目を[3]で取得出来ない)
ただこれだと遅くなるだけなので、Cを駆逐したいと言いながら便利さを追求してるRustは迷走してる

Pythonは、どうやら全自動で出来るみたいね…

2025/07/01(火) 08:38:13.77

>>860
859は別に間違ったこと言ってないでしょ
そこまで上から目線で言いたいならunicodeは書記素クラスタで考えないといけないので可変、ぐらい言わないとね
コードポイントならUTF-32は4バイト固定だし
むしろc言語はasciiという言い方は複数の意味でおかしい

2025/07/01(火) 09:47:54.97

>>862
俺は859は根本的に勘違いしてる(≒間違っている)という見方を今も変えてないが、
少なくとも862の方が詳しいようだから(859の相手は)お前に任せるわ。

俺より詳しい奴が居る場所で俺が説法する意味もなく、
馬鹿と初心者が無限に沸くネットで間違いを全部指摘して回るのは無理だし。
下から目線のゆとりZ様同士でよろしくやってくれ。
どのみち俺とお前らではどうやっても合わないのはこれまでも散々経験してきた事だ。

2025/07/01(火) 09:48:28.12

とはいえ一応内容について触れておくと、
> 書記素クラスタ
重ね文字等の事は知ってるぞ。ただ俺はこれは仕様が決まってないかと思っていたのだが、一応あるんだな。
http://unicode.org/reports/tr29/
ただこれ、問題は"Unicode 16.0.0"と、バージョンがやたら高い事にあると思う。
自然言語が既に16回も改訂してるわけはないので、中途半端な仕様を決め、改訂しまくってるという事だから。
今の仕様で実装しても、出来上がる頃には仕様が改訂されている事もあり得る。

> コードポイントならUTF-32は4バイト固定だし
当然これも知ってるが、現実的にutf-32を使う事はほぼあり得ないだろ。
文字列処理は結局の所速度/メモリ重視だから、utf-32ではコードは書きやすいかもだが使い物にならない。

つかこの辺859に言ったところで通じるわけもなく、マウントが目的になってるのはお前の方だ。
だからこそ「上から目線」に過度に敏感なのがゆとりZの傾向でもあるが。

> むしろc言語はasciiという言い方は複数の意味でおかしい
話を続ける気があるなら、何の事なのかもう少し具体的に言え。

まあ一言ずつに纏めると、

859: PHPは文字の扱いに色々問題があるが、C言語にはない
860: お前は根本的に間違ってるから、文字コードについて勉強し直せ ← 859に通じる範囲で返事してる
862: 俺の方が詳しいのに上から目線ウゼエ ← マウントを取り返しただけで、859に通じるようには書いてない

ここら辺がゆとりZがコミュ障な所だ。
まあそれでもお互いにやるのは自由、よろしくやってくれ。
俺は降りる。

2025/07/01(火) 10:03:19.08

普通に何も考えずに使ってて問題起きないならstrlen以外にもmbslenとかwcslenみたいなのを用意されることはないんだよな

2025/07/01(火) 10:07:53.62

ああついでに言っておくと、

ゆとり以前(＝俺)：内容が正しければ態度なんてどうでもいい

ゆとりZ：ボクがどんなにマヌケな間違いをしていたとしても、
　優しく丁寧に教えてくれる事が絶対条件で、
　優しければ内容が多少間違っていても許容される（←いやこれは俺は許容出来ねえ)

という違いだな。まあゆとりZ同士でよろしくやってくれ。
ただまあ、Qiitaのスレとかチラ見してるが、
発言の自由がある＝どんな馬鹿でも発言出来る＝間違った情報も当然発信される、なのだから、
Qiitaに正確性を求めるのは仕様的に無理なので、連中も間違ってて、
Qiitaは玉石混淆な上で、石が大量生産されるのは仕様として甘受し、玉を探すべきだとは思うがな。
とはいえQiitaが石→玉化する機構を持ち合わせられない(＝間違いを指摘する事すら出来ない)
のは上記ゆとりZ価値観の賜だから、詰んではいるが、それでも(Qiitaというサイトが)無いよりは断然いいし。

つまりだな、お前らゆとりZは「上から目線ガー」とか一々やってるから駄目なのであって、
「相手」(今回は859)に向き合う気がないから、
Qiita等の「一方的に発信するだけ」のツールは断然相性がいいが、
そこで「双方向な議論」とかはまるで出来ないんだと思うぜ。
859にとって困るのは、「上から目線」ではなく、「間違いを指摘してもらえない」事だろ。
(ただこれがゆとりZに取っては違うらしいので俺にはどうにも合わないが)

2025/07/01(火) 10:57:25.82

リンクは以下の方がよかったかも
https://hydrocul.github.io/wiki/blog/2015/1025-unicode-grapheme-clusters.html

> Grapheme cluster の境界定義
> CR の次に LF が続く箇所は境界にならない
これだとCRLFは一文字扱いだから、utf-8の0x7f以下だけ使っても(厳密には)asciiとは違うって事か？
なんで一々仕様を無駄に変更するのだ？という気はするが、
見てる限りunicodeって自然言語学者が策定してる仕様で、プログラミングのし易さなんてまるで考慮して無いな

2025/07/01(火) 16:58:38.98

PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
C言語は指示しない限りは何もしないから、むしろ安全。
860は、馬鹿だから理解できない。

2025/07/01(火) 17:04:55.37

中途半端に自動化しようとしていることが脆弱性の温床になる。
詳細な仕様を書かないで「こういう場合にはこうすれば安全ですよ」
みたいなのが結構危ない。
なぜ、そうするのか。その関数は厳密に何を行っているのか。
「簡易言語」には、そういう情報が欠落していることが多い。

2025/07/01(火) 17:07:29.61

フレームワークも危険だ。
「完成品」として何もカスタマイズしないで使っているなら、安全かもしれない。
ところが、「プラグイン」と呼ばれているものを組み合わせたり、
独自にカスタマイズしようとすると、とたんに危険になる。
なぜなら、仕組みが分かりにくく、ソースが巨大で解読しにくいことが多いからだ。
特に問題なのはオープンソースのフレームワークだ。
ソースが汚いものが多いから、それが原因で理解が難しくなり、脆弱性が入り込む。

2025/07/01(火) 17:10:17.61

860は、物事の理解が甘い。
自分が馬鹿なことに気付いてない。
5chだけで偉そうにしている馬鹿。

2025/07/01(火) 17:12:20.54

自己紹介ですか？

2025/07/01(火) 17:15:03.47

>>872
おまえは、自覚が無い馬鹿だ。

2025/07/01(火) 17:41:41.27

全然違う話になったぞ？？？

2025/07/01(火) 19:57:14.17

けどさ
今のWindowsって内部的にはUTF16LEなんだよな
それをアプリ側に合わせてマルチバイトに変換したりしてるわけで

2025/07/01(火) 20:03:31.00

>>874
まあ859もゆとりZだったというオチだよ。
見えてた展開ではあったが、放置するのも問題かと思って最低限のツッコミを860でしたつもりだったが、
ゆとりZが釣れまくってどうにもならねえ。脱線しすぎ。

5chにはコミュ障が多いのでついでに解説しとくと、
859のテイ、何だかよく分からん独り言は、ゆとりZ特有のムーブで、
・質問して答えてもらえないと傷つくし、
・議論提起してボコられたら嫌だし、
・何だかよく分からん独り言にしとけば、どういう展開になっても逃げられるし！！！
って事で、傷つかない為に予防線張りまくりの戦術、連中なりの「コミュ上手」な手法らしい。
いやいや、お前ら一々メンドクセエわ。

2025/07/01(火) 20:04:09.01

>>868
> 860は、馬鹿だから理解できない。
お前がどう思おうと自由だが、さすがに俺よりお前の方が賢いと思う奴は居ないと思うぞ。
まあこれも862と同様のゆとりZ特有ムーブで、「ばかにされた！！！」事が内容に勝ってる。
いやいや、お前がそもそもマヌケな事を言わなければ防げた展開だろ、とはならない。

> PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
> 特に問題なのはオープンソースのフレームワークだ
少なくとも今のお前より理解してる連中が作ってるから、
今のお前の知識と知能で作った物よりは安全だろうよ。

ついでに言うとこれもゆとりZの特徴で、
心根で他人を見下してるからこんな発言になるし、また、
心根で他人に対してマウントを取りたい、上から目線で話したい、と思ってて、でも我慢してるからこそ、「上から目線」に過敏になる。
オープンソースにゴミが多いのも事実としても、
同じ物を作るのはかなり大変なのも、結果的に生き残ってる物はそれなりに鍛えられた品質なのも事実。
各言語処理系なんて相当の人数が関わって改善された結果だから、同等以上の品質の物を作るのは事実上無理だと思うけど。
ゆとりZは「謎の心根の『上から目線』」がありすぎ。
それでいて「表面的な『上から目線』」にゼロトレランスなのはちゃんちゃらおかしいのだが、まあ連中はここら辺を矛盾に感じないらしい。
連中は表面的なコミュニケーションしか出来てないってのがこの辺から分かる。

2025/07/01(火) 20:14:50.32

>>875
それは正しいよ。
サロゲートペア以前はutf-16が各国文字を固定長で扱える(多分)唯一のエンコードだったから、
ローカライズ前提のwindowsの内部コードをutf-16で作るのは正しい。

逆に言えば、サロゲートペア以前はutf-32なんて使う意味なく、実際使われてもなかったはず。
今固定長に拘るならutf-32しかないけど、Rustがutf-8を選択したのは、utf-32は使い物にならないという判断のはず。
(まあゆとりZなら「俺の判断の方が正しい」となるのだろうが、
俺の心根はそこまで「上から目線」ではないので、Rust陣営の判断はそれなりに尊重する。
なおRust信者は死ねと常々思っているが、それとこれとは別の話)

2025/07/01(火) 20:20:08.26

そうではなく
OSレベルで自動変換が行われているのに
言語レベルの自動変換に文句言うのもなんだなぁと
そういう話

2025/07/01(火) 20:35:01.95

>>879
その意味なら、OSレベルの自動変換はされてないぞ。

例えば、SJISファイルはSJISファイルとして保存されてるだろ。
Windowsに保存する限りあらゆるファイルが自動的にutf-16にされ、
もう二度と各ファイルのエンコードを気にする必要がないのなら、大半の人はこの方が助かるとは思うが。(俺もこれでいい)
同様に、.NETでファイルストリームを開いたら、あらゆるエンコードが自動的にutf-16になって見える、って事もないだろ。
(APIチラ見する限り、Text.Encodingがあるから手動で切り換えのはず)

ただこれを目指した物がBOMなのだろうけど、上手く機能してるとは思えないね。

2025/07/01(火) 20:40:05.31

sjisファイルを読み込んでメモ帳で表示させる場合、内部のレンダリングエンジンとかはutf16に変換されたものじゃねえの？
それをまたsjisで保存する際には変換されてる

2025/07/01(火) 20:41:51.49

winapiのA系もutf16に変換されてる表示されているんじゃないの？

2025/07/01(火) 20:42:58.47

>>880
A 付きの API は OS が変換するよ。
ファイルの読み書きもロケールの設定によっては変換する。
わかりやすく観測しやすい例としてはファイル名は変換してる。
そもそも NTFS の規格からしてファイル名は Unicode が前提だし。

2025/07/01(火) 20:43:09.72

>>879
あ、ちなみにコピペなら、あれはアプリ側がやってるらしいぞ。

例えばメモ帳でSJISファイル開いて、Ctrl-C、その後utf-8の別アプリ(メモ帳でもいい)でCtrl-Vしたとき、
正しくコピペされる(＝文字化けしない)が、これはアプリが対応してるかららしい。
ソースは、以前、対応してないアプリがあって、コピペが上手く機能しなかったとき、
「Windowsのメモ帳ですら対応してるのに、なんだこの糞アプリはッ!!!とブチ切れてた奴を見たから。
OSがやってくれてるのならこうはならない。

2025/07/01(火) 20:56:30.50

>>882-883
確認した。
AとWがあり、Aは自動変換してくれるようね。
Win32APIだから、「OSが自動変換してくれる」と表現するのも正しいね。

>>879
上記で了解した。

2025/07/01(火) 22:22:40.31

>>877
的外れなことばかり言ってんじゃないぞ、大馬鹿ものめ！
馬鹿はC言語スレに来るな！

2025/07/02(水) 04:17:04.40

phpやアプリで入力された文字をwebアプリで扱う話
なのか
メモ帳みたいにwindows固有のShift_Sisでの文字の処理の話
なのか

2025/07/02(水) 05:01:21.76

文字コードとプログラミング言語の区別が付いてないゆとりZが、
「ぼくのさいこうのせきゅりてぃ！！！」を語って馬鹿にされただけの話

ついでに考えてみたが、Windowsの場合はファイル読み込み時に変換かけ、
CLR上のStringも、C#のStringも、またWindows上のStringも、全てutf-16、という美しい世界なのだろうが、
これだと同様にクリップボード上のテキストもutf-16だと思われ、文字化けする理由が分からん
(俺が遭遇した物はエンコーディングによってコピペが出来たり出来なかったりしてた《ように見えた》)

なおWin10以降はutf-8を目指しているのかも？
https://www.momopoem.com/?p=919

とはいえ、Cの話ではないな
unicodeスレでやれってこった
(あるのかは知らんが、スレがあってもおかしくない程度にはunicodeは複雑)

**デフォルトの名無しさん** · 2025/07/02(水) 06:16:59.91

内部表現がUTF16LEであって、表面上はシステムで設定した文字コードってだけの話だよ
日本語環境だとデフォルトS-JISだったのをWindows10の途中からutf-8にした（ユーザ側で変更は可能）
メモ帳もデフォルトがutf-8になった

クリップボード上のテキストはアプリケーションがクリップボードにデータを預ける
その預けるデータ形式に読み取り側が対応していないと機能しないと言うだけ
シンプルなテキスト形式ならCF_TEXTがANSIでCF_UNICODETEXTがUTF16LEになる
CF_TEXTにしか対応していないか、両方対応しているけどANSI優先させてしまっている場合（ないと思うが）になら環境依存文字が文字化けすることもある

2025/07/02(水) 08:07:25.64

わからんことはもうAIに聞いたら教えてくれるのに

2025/07/02(水) 08:13:07.97

>>889
了解した。

API見る限り、一つのクリップボードに複数のデータ形式を登録でき、しかも自動変換まで行ってくれるのだから、
CF_UNICODETEXTだけ対応しておけば文字化けはほぼ無くなるので、彼が糞アプリ具合にキレたのも分かった。
> システムは、特定のクリップボード形式間でデータを暗黙的に変換します。
> ウィンドウがクリップボードにない形式でデータを要求した場合、システムは使用可能な形式を要求された形式に変換します。
> https://learn.microsoft.com/ja-jp/windows/win32/dataxchg/clipboard-formats
> クリップボードの形式変換形式
> (中略)
> CF_TEXT CF_UNICODETEXT
> (中略)
> CF_UNICODETEXT CF_TEXT

2025/07/02(水) 09:02:06.13

ちな、unicodeスレ

文字コード総合スレ part15
https://mevius.5ch.net/test/read.cgi/tech/1723861080/

2025/07/06(日) 09:24:52.33

>>861
python(リファレンス実装、すなわちcpython)の文字列内部表現は全部UTF-32だよ
やはり(概ね)固定長がプログラムで処理しやすい
外部的にはutf-8を吐くけど

2025/07/06(日) 11:52:20.38

英語圏から見たら一文字に32bitも使うなんて勿体無いと思う

2025/07/06(日) 12:26:15.50

emoji全盛なので英語圏は～という見方は時代遅れ

2025/07/06(日) 13:29:05.42

アスキーコードは0の¥0から127のDELまでしか使ってないのだから絵文字も1バイト内に収められそう

2025/07/06(日) 13:49:41.25

128からは北欧やロシア特有の文字で埋められているからなぁ

2025/07/06(日) 14:21:04.82

>>893
おお、utf-32の実装例が有ったか
しかしcpython(1991)に対しサロゲートペア導入(1996)なので、
utf-16ではなくutf-32にしたのは謎だな
先見の明があったのか、(その頃既にunicodeが枯渇気味なのを知っていたとか？)
或いはサロゲートペア対応時にutf-16→utf-32に書き換えたのか？

2025/07/06(日) 14:23:19.54

iモードの絵文字：271文字

Unicodeの絵文字：約4000文字
合字を含めると10万文字以上
（英字2字から国旗を生成する、
人物の肌の色や髪型を指定する、
「カップル」や最大4人の「家族」を1人ごとに
大人・子供、男女、肌の色、髪型を指定する等）

Appleの絵文字：
自由な文章や顔写真などからAIが生成するため
組み合わせは無限大
（例：自撮り画像を用意して
「サーフィンをする俺」
と指定すれば、写真の数だけ絵文字ができる）

2025/07/06(日) 19:24:09.13

>>898
2.7までは文字列とユニコード文字列があった
確かu"unicode"的な記法で（おぼろげ）
3にメジャーアップデートして文字列はユニコのみになった

2025/07/06(日) 20:24:06.04

Qiitaの『[入門] C/C++ 知っておくべきポインタの由来 ISO標準のメモリモデル徹底解説』

この記事のおかしいとこ適切に指摘できる程度の知識ある人がなんか言うべき。

2025/07/06(日) 20:42:05.76

最初にコメントした人も言ってる通り、内容を精査せずにポストしてる AI 生成記事のようであり、
細部のコメントを受けての修正も根本的なところ（そもそもサンプルコードを含む記事の大部分が
provenance と関係ない）を放置して指摘点だけをどうにか直すにとどまっていて、
これもおそらく AI にやらせていそうで、真面目に付き合う気にならない。

2025/07/06(日) 21:06:32.37

最初のコメントの方がずれたこと言ってると思ったわ

2025/07/06(日) 23:42:52.85

>>900
となると単純化する方向で斬り捨て、
2.7まではascii+utf-16だったかもだが3でutf-32に一本化、の可能性が高いか
リファレンス実装(速度よりも正確性重視)だからこれが正しい選択かもね

>>901
読む気もないが、866の通り、Qiitaではゴミは大量生産される物だと割り切り、
「悪い記事」ではなく「良い記事」を探す事に徹するべきだと思うよ
無限に生産される「ゴミ」に対して「有識者」の時間を要求するのは悪だと思うし(＝ただの時間泥棒)

2025/07/06(日) 23:58:42.87

>>897
ひらがなとカタカナ、あとはトランプのマークとかだよ

2025/07/07(月) 00:57:35.46

>>905
はいはい、日本向けはな

2025/07/07(月) 02:30:49.89

>>906
念のために言っておくと、ISO 8859 はうんこ規格やぞ

2025/07/07(月) 04:46:06.48

>>901
ついでに言っておくとな、

> この記事のおかしいとこ適切に指摘できる程度の知識ある人がなんか言うべき。
＝「ばかなゆとりＺのためにゆうしきしゃはどりょくすべき」と言っているのであって、
一体何様のつもりだ？であり、こんな事言える時点で相手に対するHRTの欠片もない。

Qiitaの連中はHRTを「『ぼくに』ひどいこといわないこと」と捉えてるようだが、
正しくは「『相手に』対する」姿勢であって、
相手に対してHRTがあるのなら、わざわざしょうもない事で手間をかけさせる事は恐縮なはずだから、
有識者は、堂々と馬鹿を無視して見殺しにするのが、HRTの趣旨に則ってる。
(現実的に、無限に沸く馬鹿全員に構うのは無理だし)

そもそもQiitaは「正しい情報が発信される」プラットフォームではなくて、
「各々が自由に発信出来る場所」であり、「正しいかどうかは読者の判断に委ねられる」(＝民主主義)
だから、

×　間違いを正す努力をする
○　正しい情報を自己で発信し直して、間違ってる情報を上書きする
○　何らかのレーティング機構をつくり、正しい情報に辿り着きやすくする

方向で努力すべき場所だと思うよ。
(だから「悪い記事」ではなく「良い記事」を探せ、となるわけでね)

2025/07/07(月) 08:30:34.74

>>908
レーティングとかやったとしても、正しい記事はそれほどレート上がらず、きちんと見ると少しおかしいけど初心者受けする記事に高レート集まるから無駄

2025/07/07(月) 08:46:23.49

>>909
「初心者」を含む「人気投票」ベースのレーティングをやったらそうなる
だから例えば、正しい記事を正確に判断出来る「有識者」だけでレーティングすれば、少なくともゴミ記事はすぐ除外出来るだろ
(ただこれはQiitaの連中には出来ない事なのだろうけど、
少なくともStackOverflowは上手くやってるんだから、何かしらやり方はあるのだろうよ)

2025/07/07(月) 10:11:19.66

全ての暗号化一瞬で解読される
京大、マクロな世界で時間が過去から未来へと一方向に流れる謎に迫る発見
掲載日
2025/07/07 09:33
https://news.mynavi.jp/techplus/article/20250707-3373082/

これが成功したら一瞬で計算できるでしょう
１　計算を始めた段階から未来では完了している結果が表示される
２　結果が表示された結果を現在に戻せば計算結果のみが表示される
３結果的に一瞬で計算できているように観測される

2025/07/07(月) 10:15:31.37

人間と同じように考え、次にとる行動を再現する最新AIモデル「ケンタウロス」
公開： 2025-07-06 20:00
http://karapaia.com/archives/523201.html
　>>ドイツのヘルムホルツ・ミュンヘン研究所のチームが開発した
　>>新しいAI言語モデル「ケンタウロス（Centaur）」は、
★>> 160の心理学実験に参加した6万人以上の人々が行った1000万件を超える意思決定データを学習している。
　>>『Nature』（2025年7月2日付）に掲載された。
★>>　AIケンタウロスの力があれば、たとえば不安症やうつ病など、精神疾患のある人の意思決定プロセスをシミュレーションすることで、その行動や心の動きを深めることができるという
　>>　研究チームは今後、年齢や性格などの心理的・人口統計的特性もデータセットに組み込んでいく予定だそうだ。
★　>>医療・政策設計・社会科学など、人間の意思決定が重要になる幅広い分野で活用できると期待されている。

2025/07/07(月) 10:52:50.66

900
旧
unicodestring=u'hogehoge'
(bytes)string='hogehoge'
現
string='hogehoge'(旧unicodestring)
bytes=b'hogehoge'(旧string)

2025/07/07(月) 11:00:30.19

911
面白い記事thx

2025/07/07(月) 13:14:06.42

>>910
StackOverflow は信用度に応じて特権が解放される仕組みになってる。
特権の中には (良し悪しの投票とは別に) 削除すべきかどうか投票する権限が含まれるよ。
これは攻撃や露骨な異常に対処するための権限であってレーティングではないけど。

削除票権限を得られる信用度 2000 というのがどれくらいかよくわからんけど、たぶんまともな投稿が百個分くらいだと思う。
そんなに高いハードルではない。

2025/07/08(火) 07:51:29.50

>>915
いや俺が言ってる「レーティング」は、StackOverflowのそもそもの仕組み、
一つの質問に対して複数の回答がup/downvoteで競う、というシステムの事だ。

ただup/downvote方式は他、例えばYouTube、FaceBook、Reddit等でも使われていた、
かなりありふれた仕組みだが、大体常に不正投票で荒らされる。
その「削除票」はおそらく「不正投票で上位に持ってこられたゴミ」の削除を諮るもので、
仕組み上、up/downvote権は削除票権よりも低い。(はず)

事実として、StackOverflowのレーティングは完全に機能してる。
対して、他サイトのレーティング機能は大体おかしな事になっており、vote自体を止める/見えなくしてるのが大半だ。
他サイトは「誰でも投票出来る」から機能してないのはまあ自明で、
StackOverflowは「投票権」の管理が上手いのだろう。

Qiitaは「誰でも発信出来る」仕組み上、ほぼ全部がゴミになるのは仕様だ。
これは「有識者のみに発信権を絞り、質を上げる」と対極の、
「ゴミにも発信させる事により、裾野を著しく拡大させ、結果的に山頂も高くなる」であり、
典型的な「数撃ちゃ当たる」戦略なので、Qiitaの意思を尊重するなら、「割合」なんて無視すべきで、
「山頂の高さ」「(一定の質以上の)使える記事の『絶対数』」(重ねていうが「使える記事の『割合』」ではない)
だけを問題にすべきだ。

ただ実際の所は「高さ」も「使える数」もゴミだから悪く言われてるのだとも思う。
とはいえ、ゴミ含めた「数」だけは有るのだから、StackOverflowモドキも出来るはずだ。

2025/07/08(火) 07:52:15.52

例えば、"How to deal with utf-8 in C"でググると以下が先頭に来るわけだが、
> C programming: How can I program for Unicode?
> https://stackoverflow.com/questions/526430/c-programming-how-can-i-program-for-unicode
これと同様に、Qiitaでも"utfをCで扱う記事"を探してきて、良い順にリスト化して表示する事は出来るはず。
まあ単なるSearch機能だが、公式には新着順/関連順/ストック数順/いいね数順しかない。
ここに「評価順」を入れられればいいだけだが、『みんな一等賞』なゆとり価値観では拒絶されるので存在出来ない。
だから外部から補うとしたらここなのだ。

ゴミを列挙したところで、或いはチマチマとゴミの訂正をしたところで、さらに無限に沸いてくるゴミに押し流されるだけだ。
人数は圧倒的に初心者>>>有識者なのだから、手数で勝負したらどうにもならない。
Qiitaのことを思うなら、或いはQiitaの戦略を尊重するなら、
指摘なんて無意味な事はせず、
ただ淡々と、「△△記事より○○記事の方が『上』『下』」と、レーティングのみに徹すればいいのだ。
そしてその理由付け、「○○だからこの記事の方がいい」なんて説明も時間の無駄でしかないからやらなくていい。
実際、書いてる奴はそれで最高と思ってるからその記事になってるわけであり、何を言ったところで通じないし、
また実際、StackOverflowでも単純な「最終スコア」だけで完全に機能してるだろ。
(だからQiitaスレの連中も、やってる事は大幅に勘違いしてる)

2025/07/08(火) 08:08:11.05

なげーよ読むかよこんなの
AIで要約して貼れ

2025/07/08(火) 08:18:34.49

Gitスレに居た長文君でしょ。相変わらずのスタイルでスレ違いの話をつづけるなら個人スレッドに帰ってくれ。
ついでにWitBucketの進捗報告してくれてもいいぞ。
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

2025/07/08(火) 10:09:50.64

＞(だからQiitaスレの連中も、やってる事は大幅に勘違いしてる)

勘違いしてるのはお前ｗ
Qiitaスレはクソ記事を面白がってるだけｗｗ

2025/07/08(火) 10:43:13.18

もうそういう外の事はいいから、外でやれよ

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-zcFv) · 2025/07/08(火) 10:58:14.52

ゴミにも発信させる事により、裾野を著しく拡大させ、結果的に山頂は低くなる

2025/07/08(火) 12:03:22.01

>>919
>>833としか同定してなかったけど、いたなあこんなの
かっこの使い方とか、急にレッテル貼って攻撃的になるところとか、確かによく似てるわ

2025/07/09(水) 07:17:02.60

>>920
お前にはそう見えると理解した。

>>922
現状のQiitaはその通り。
ただ、OSS、Pixiv、なろう、YouTube、Webサイト、アプリ、等々、(多分5chの書き込みも、)
「どんなゴミでも公開するのは自由」という戦略で成功してる例は多々ある。
Qiitaで上手く行かない理由はよく分からん。

それはさておき、以下とか見てみたが、
> https://stackoverflow.com/questions/21737906/how-to-read-write-utf8-text-files-in-c
> https://src.nafod.net/glibc-2.35/glibc/libio/getwc.c.html
setlocaleすればwc関数が使えて、おそらくlocale毎に切り替えられてる関数群を呼ぶ、といったところか？
ならutf-8に決め打ちして高速化するRustの戦略の方が妥当なのかもしれんな。

2025/07/09(水) 19:10:52.61

> Qiitaで上手く行かない理由はよく分からん。

Qiitaはマサカリを通報できるシステムと苦情は悪と捉える運営との相乗効果でいまの惨状だろｗ

2025/07/09(水) 20:25:09.49

qiitaスレでやれ

2025/07/09(水) 22:19:48.88

>>925
Qiitaスレに落とした
https://mevius.5ch.net/test/read.cgi/tech/1739527246/529-

2025/07/10(木) 05:42:35.42

・事件を起こしたオウムしんりきょう幹部反社会のソシオパスではないか？！
知能が高い人ほど、道徳心のスコアが低くなっていた
2025.07.09 07:00:09 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/181131
>>英国エディンバラ大学（The University of Edinburgh）の最新研究によると、認知能力が高い人ほど、道徳的価値観を全体的に弱く支持する傾向があることを明らかになったのです。
>>道徳心には「6つの基盤」がある
>>① 思いやり／危害（Care / Harm）
>>② 公平さ／不正（Fairness / Cheating）
>>③ 忠誠／裏切り（Loyalty / Betrayal）
>>④ 権威／転覆（Authority / Subversion）
>>⑤ 純潔／堕落（Sanctity / Degradation）
>>⑥ 自由／抑圧（Liberty / Oppression）
>>これらは「道徳心のセンサー」のようなものであり、文化や時代を超えて人類に共通する心理的傾向です。
>>政治的立場によっても傾向が分かれ、リベラルな人は「思いやり」や「公平さ」を強く支持し、保守的な人は6つすべてを重視する傾向があると指摘されています。
>>結果、興味深いことに、知能が高い人ほど、6つすべての道徳基盤のスコアが一様に低くなるという驚きの結果が得られたのです。
>>とくに顕著だったのは、「純潔」基盤との関係で、言語的知能が高い人ほど、「心や体は神聖なものだ」といった伝統的な価値観に共感しにくい傾向が見られました。
>>道徳的判断を“直感”ではなく“分析”でとらえる傾向がある」と指摘します。
>>たとえば「これは悪いことだ」と即断する代わりに、「それは誰にどんな影響があるのか？」「文脈によっては正当化されるのでは？」と一歩引いて考えてしまうのです。

2025/07/10(木) 17:19:45.48

AMDが画像生成AI「Nitro-T」をリリース、32基のInstinct MI300Xでゼロから1日未満でトレーニング可能
https://gigazine.net/news/20250710-amd-nitro-t-text-to-image-diffusion-model/

2025/07/11(金) 09:57:27.27

買収したXilinx社の技術だよな？

2025/07/15(火) 00:15:52.37

C言語で普段使いに便利な文字列操作ライブラリってある？
文字列をどんどん連結したりとか削ったりとか

2025/07/15(火) 08:57:02.20

文字列操作も含めて高度な機能を提供するライブラリとしては cello が面白いかな。
https://libcello.org/
ここまでくるともはや別言語という感じだけど。

2025/07/15(火) 10:49:36.01

libcかglib

2025/07/15(火) 14:58:33.62

>>932
cello
ありがとうはみちつ

2025/07/15(火) 19:32:43.03

電子は動かず『電子のスピンだけ』が流れて情報伝達できる微小チップを開発
2025.07.15 TUE
https://nazology.kusuguru.co.jp/archives/181574
蘭デルフト工科大は電子自身ではなく電子のスピン状態のみが流れて情報を運ぶ『スピン流』を起こせる微小チップを開発したと発表。チップは電子があっても電子が流れないため熱のロスが大幅に減少します

2025/07/16(水) 05:03:32.70

宇宙誕生直後の数兆度の「宇宙のスープ」を再現――濃厚な後味を探る
2025.07.15 TUE
https://nazology.kusuguru.co.jp/archives/181596

↓昔はよく見えた人魂が見えたので幽霊と勘違いし↓

雷の玉⁈ 謎の自然現象「ボールライトニング」をカナダで観測
2025.07.14 MON
https://nazology.kusuguru.co.jp/archives/181422

臨死体験の正体は死ぬ間際の「爆発的な脳活動」だった
2025.05.03 SAT
https://nazology.kusuguru.co.jp/archives/125749
>>患者たちの脳の意識や思考、記憶にかかわる脳領域において、死ぬ直前に主にガンマ波からなる「爆発的な脳活動」が起きていることが判明しました。
>>同様の脳活動パターンは夢や幻覚を見ているときや、幽体離脱を経験している患者たちで観察されるものと酷似していたとのこと。
※天国や地獄は無い！

2025/07/16(水) 06:46:01.56

>>935
板違い
電気電子板へgo

2025/07/17(木) 08:01:19.44

>>859
PHPじゃなくてUTF-8やSJISを使っているならみんな同じだぞw

2025/07/17(木) 08:03:30.58

C言語そのもこは文字、文字列はキャラクタセットの概念がないから、常に1バイト単位で判断して組み立てる。

2025/07/17(木) 08:04:01.09

>>931
こんなところで聞くなよ

2025/07/17(木) 17:40:35.28

Fat Pointer か。15秒だけ読んだ

ついでに、Rust程度のボローチェッカもやればいいんじゃないかな
嫌味じゃないよ、似たようなこと最近ぼんやり考えてたのであるいはできるのかなもう

2025/07/17(木) 19:23:50.10

今あなたがPC画面に表示している内容すべてをAIが理解--WindowsのCopilotが新機能
2025年07月17日 09時40分
https://japan.cnet.com/article/35235611/
>>新機能では、AIがあなたの画面を丸ごと把握し、プレイ中のゲームの操作もサポートするなど、あなたのPC操作をリアルタイムで支援してくれるようになる。

・カメラ映像を読み込みながらの・スタンドアローンAIによるPC操作が可能になる
・優先LANでPC同士を接続した環境でAIに攻撃と望郷を２４時間３６５日繰り返させてハッキング不可能な本体プログラムなので犯罪者のテクニックがさらに向上する
・AIにプログラムコードもその場て書き換えれるように双方に搭載させてさらに進化速度を早くすている
◇
・宇宙人はUFOを作成できる技術があるので上記のプログラムはすでに完成している！

2025/07/18(金) 14:18:59.35

・下記の条件を整えない限り量子テレポーテーションによるワイヤレス通信は不可能
量子コンピューターの真価を、実機で証明することに初めて成功。理論から現実への一歩となるか
2025.07.18
https://wired.jp/article/quantum-computer-exponential-speedup/
>>量子コンピューターは、古典的な計算機では手が届かない問題を解く可能性を秘めている。だが、その潜在能力を発揮するためには、実機で機能するアルゴリズムが欠かせない。また、問題の規模が大きくなるほど古典的なコンピューターよりもはるかに早く答えにたどり着けるという優位性を証明しなければならない。これまでのところ、その証拠は得られていなかった。
>>こうしたなか、南カリフォルニア大学（USC）の研究チームが、状況を一変させる成果を発表した。IBMの127量子ビットのプロセッサー「Eagle」を用いて、従来のコンピューターで解を導くことが極めて困難だった「サイモン問題」に取り組み、圧倒的に高速な解法を実現したのだ。
>>サイモン問題へのアプローチは、素因数分解の問題を高速で解くショアのアルゴリズムに先立つ、初期の量子アルゴリズムのひとつとして知られている。実際、サイモン問題を解けるならば、暗号解読の基礎技術にも応用できる可能性がある。理論上は指数関数的に速く解けるとされていたが、それを実機で確かめた事例はこれまでなかった。
>>この課題に取り組むにあたって、ライダーらの研究チームはサイモン問題の特定バージョンに焦点を絞った。オラクルに隠されたビット列に含まれる「1」の数（ハミング重み）を制限することで、回路の複雑さとエラーの蓄積を抑えるとともに、現実的な量子デバイスでも検証可能なかたちに問題を再定式化したのだ。
★>>ダイナミカルデカップリングとは、精密なタイミングでキュービットにパルスを与えて、外部環境との不要な干渉を打ち消す技術だ。これにより量子状態の持続時間が飛躍的に延び、
>>今後の課題は、オラクルなしで定式化された実問題に対しても同様のスピードアップが実現できるかどうかだ。また、より大型の量子コンピューターを安定して動かすためには、外からのわずかな揺らぎや、計算途中で量子状態が壊れてしまう問題にも対処しなければならない。

2025/07/22(火) 13:08:22.41

Googleの強化版Geminiが数学オリンピックで金メダルを取る性能に到達、自然言語で動作し人間と同じ制限時間で解答を導き出す
2025年07月22日 11時04分
https://gigazine.net/news/20250722-google-gemini-mathematical-olympiad-gold-medal/

OpenAIの「実験的推論モデル」が数学オリンピックで金メダル相当のスコアを達成、GPT-5は近日中にリリース予定で「実験的推論モデル」はまだ先
2025年07月22日 11時03分
https://gigazine.net/news/20250722-openai-mathematical-olympiad-gold-medal/

2025/07/22(火) 16:23:37.10

スレチ

2025/07/23(水) 07:32:26.79

・自然界の光が強いから特別な屋の中でしか思考を読み取れない

脳が放つ“秘密の光”の検出に初成功：思考を読み解く新技術への扉が開く
2025年6月18日1:25PM
https://xenospectrum.com/first-successful-detection-of-the-secret-light-emitted-by-the-brain/
★>>極めて精密な実験環境を構築
>>実験は、外部の光を完全に遮断した暗室で行われた。20人の被験者は快適な椅子に座り、頭部には脳波（EEG）を測定するためのキャップを装着。そして、脳の光を捉えるため、超高感度の光センサーである「光電子増倍管（PMT）」が頭の周りに配置された。PMTは、光子1個という究極の光量さえも検出できる驚異的なデバイスだ。研究チームはPMTを、視覚情報を処理する「左後頭部」と、聴覚や記憶に関わる「右側頭部」の2箇所に設置。さらに、
>>部屋の背景光（ノイズ）を測定するためのPMTも別に用意し、脳からの信号と明確に区別できるようにした。

・上記は特別な部屋の中で下記は実際に観測しての発表

はやぶさ2、科学観測でも活躍　銀河拡散光と星間塵の関係を新たに発見
2025/07/22 20:00
https://news.mynavi.jp/techplus/article/20250722-3386181/
>>光学航法望遠カメラ「ONC-T」を用いて撮影した天の川銀河中心の星間塵が多い領域の画像を解析。その結果、星間塵が多いほど、星間塵が星の光を散乱して作る淡い光である「銀河拡散光」の明るさが弱まることが判明

2025/07/23(水) 10:58:10.25

3行以上コメするな
ニュースなんて本文見れば判るんだからURLだけ貼れ

2025/07/23(水) 13:06:07.59

あの・・・スクリプトなんですそれ
いろんなスレで貼られてますｗ

2025/07/23(水) 13:21:32.08

Claude Sonnet 4に匹敵するコーディング特化のオープンモデル「Qwen3-Coder」をAlibabaが発表
2025年07月23日 10時45分
>>Qwen3-Coderの大きな特徴は、ネイティブで256Kトークンという広大なコンテキスト長をサポートするだけでなく、
>>「YaRN(Yet another RoPE-based scaling method)」という拡張技術を用いることで最大100万トークンまで対応可能である点です。これにより、リポジトリ全体を理解するような大規模なタスクにも対応できます。
>>C++、Java、Python、Ruby、Swift、ABAPなどを含む358もの多様なプログラミング言語をサポート。加えて、ベースモデルから一般的な能力と数学的能力を維持しつつ、コーディングに特化しているとのこと。
>>さらに、その能力を最大限に引き出すため、エージェントコーディング用のコマンドラインツール「Qwen Code」も同時にオープンソース化されています。このQwen CodeはGemini Codeをフォークして開発
>>するSWE-Bench Verifiedにおいて、Qwen3-CoderはCloud Sonnet 4よりも小さいモデルサイズでほぼ同等のスコア

ブラックホールに捕食されても生還した「奇跡の星」を確認
2025.07.23 WED
https://nazology.kusuguru.co.jp/archives/181937

2025/07/23(水) 13:36:36.54

何が目的でC言語スレにこんなの貼り付けてるんだろうな

2025/07/23(水) 13:52:34.35

そんなことより次スレ立てろ