[過去ﾛｸﾞ] C言語なら俺に聞け 163 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
839: (ﾜｯﾁｮｲ 0bec-qYXw) 05/28(水)20:10 ID:EIair+pr0(1) AAS
【兵庫】「知事・元副知事の指示に基づき正当業務を…」斎藤知事の“側近”井ノ本氏の弁明書 知事は改めて否定 [ぐれ★]
2025/05/28(水) 17:08:14.82
2chｽﾚ:newsplus
※追い詰められてないか？
840: (ﾜｯﾁｮｲ 7b5f-DKvR) 05/28(水)21:43 ID:PBslL45A0(1) AAS
スレに関係無いもん貼るなよ
841: (ｱｳｱｳｳｰ Sa8f-q7Ty) 05/30(金)13:31 ID:XWQpoVmBa(1) AAS
もうプログラマー寄り付かなくなってるんじゃまいか
842: (ﾜｯﾁｮｲ 23ad-hhgN) 06/23(月)13:59 ID:gexPgDcc0(1) AAS
C言語の終焉か
843: (ﾜｯﾁｮｲ 8dc1-m8Iy) 06/23(月)14:32 ID:gJ1K/dLq0(1) AAS
プログラマーの終焉
844: (ﾜｯﾁｮｲ 4b10-sIdA) 06/23(月)15:24 ID:Le9JOtTU0(1) AAS
C は終焉の C
845: (ｱｳｱｳｳｰ Sa69-G7Nc) 06/24(火)09:50 ID:17zM306Da(1) AAS
文部科学省が標準のローマ字表記を改めるんだってよ
846: (ﾌﾞｰｲﾓ MM43-1F4K) 06/28(土)16:40 ID:uH6ba5rfM(1) AAS
しょぼい機器でも物凄い性能だから、C言語を使う必要もなくなっている。
847: (ｻｻｸｯﾃﾛ Sp81-AU/s) 06/28(土)16:47 ID:WGUfZy3xp(1) AAS
もはやjavascriptすら動くからなぁw
848: (ｵｲｺﾗﾐﾈｵ MM89-Hs71) 06/28(土)21:00 ID:HZiRGN/SM(1/2) AAS
ただまあ、バイト単位で処理したい時には JS や Python や Java や Ruby
より便利だけどな。
849: (ｵｲｺﾗﾐﾈｵ MM89-Hs71) 06/28(土)21:01 ID:HZiRGN/SM(2/2) AAS
あと、文字コードだとかを勝手に変換しないというのも便利だな。
850: (ﾜｯﾁｮｲ 4201-V852) 06/30(月)06:22 ID:m9Iz5ero0(1) AAS
結局、自作したいだけかよw
851: (ﾜｯﾁｮｲ fbf9-1Wc0) 06/30(月)11:37 ID:YZeS8CxH0(1/2) AAS
外食に飽きると自炊を始めるものだよ
852: (ﾜｯﾁｮｲ c602-1ra/) 06/30(月)12:00 ID:rn9gnazy0(1) AAS
そろそろc談義したいぞ…
853: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 06/30(月)13:32 ID:Bi14XNYeM(1/2) AAS
C/C++は、(レンタル)サーバーサイドでも、ソースコードを盗まれないというメリットがある。
854: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 06/30(月)13:49 ID:Bi14XNYeM(2/2) AAS
PHPは一見便利なように見えても、何をやっているのか不安が残る部分がある :
・文字コードの扱い。勝手に変換される可能性。それが脆弱性の原因になる可能性がある。
・SessionID の管理のされ方。それがブラックボックスで余り説明が無いので危険。
・文字列が「長さ指定文字列」と「0終端文字列」との二種類あり、デフォルトは前者だが、
正規表現系は後者である場合があり、それを知らないと脆弱性の原因になる。
855: (ﾜｯﾁｮｲ 62f6-vcS6) 06/30(月)18:59 ID:YQWckD/50(1) AAS
最近はFPGAでコンピュータ作ってるけどメモリが4kbytesとかしかないのでC言語があると助かります。
856: (ﾜｯﾁｮｲ fb06-1Wc0) 06/30(月)20:50 ID:YZeS8CxH0(2/2) AAS
アセンブラ使え
857: (ﾜｯﾁｮｲ c379-SOZQ) 06/30(月)20:56 ID:i+8hTHYI0(1) AAS
そこまでのキツい環境ならC使わずにアセンブラ使えって思う
858: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7b32-T+w5) 06/30(月)20:57 ID:bv4WQiut0(1) AAS
その規模なら C で書くにしても配慮すべき低レイヤの事情がありすぎてあまり C の甲斐がなさそうだと私も思う。
859(2): (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)02:30 ID:LkiphQyhM(1) AAS
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言語で作っていれば子の様な齟齬は起きない。
860(1): (ﾜｯﾁｮｲ 5f98-4xcB) 07/01(火)05:48 ID:M5z4vIa80(1/10) AAS
>>859
× > PHPの文字列は
○ unicodeは
× > C言語で作っていれば
○ asciiに限定すれば
お前は基本的なところがまるで理解出来てない
そもそも文字コードの話なのだから、どの言語でも同じ
特定の言語を使用すると回避出来るとかいう話にはなり得ない
861(1): (ﾜｯﾁｮｲ 5f98-4xcB) 07/01(火)06:18 ID:M5z4vIa80(2/10) AAS
と思ったが、もしかして最近の言語はutf-8をネイティブサポートしていて、(＝内部文字列がutf-8)
この辺を全部自動的に回避出来るのか？（＝プログラマに文字コードの知識が全く必要ない)
Cはutf以前だから勿論サポート無し
PHPはWeb言語だから文字列＝バイトストリーム扱いで、共用体が駆使されるネット向けになってるだけ
JSはutf-16だったがサロゲートペア導入でAPIが2つある(サロゲートペア対応版と非対応版)
Rustは知らんが、さらっと調べた限りutf-8で、逆にインデックスアクセスが出来ないらしい(3文字目を[3]で取得出来ない)
ただこれだと遅くなるだけなので、Cを駆逐したいと言いながら便利さを追求してるRustは迷走してる
Pythonは、どうやら全自動で出来るみたいね…
862(1): (ﾌﾞｰｲﾓ MM02-nkZs) 07/01(火)08:38 ID:WjfKubzqM(1) AAS
>>860
859は別に間違ったこと言ってないでしょ
そこまで上から目線で言いたいならunicodeは書記素クラスタで考えないといけないので可変、ぐらい言わないとね
コードポイントならUTF-32は4バイト固定だし
むしろc言語はasciiという言い方は複数の意味でおかしい
863: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)09:47 ID:M5z4vIa80(3/10) AAS
>>862
俺は859は根本的に勘違いしてる(≒間違っている)という見方を今も変えてないが、
少なくとも862の方が詳しいようだから(859の相手は)お前に任せるわ。
俺より詳しい奴が居る場所で俺が説法する意味もなく、
馬鹿と初心者が無限に沸くネットで間違いを全部指摘して回るのは無理だし。
下から目線のゆとりZ様同士でよろしくやってくれ。
どのみち俺とお前らではどうやっても合わないのはこれまでも散々経験してきた事だ。
864: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)09:48 ID:M5z4vIa80(4/10) AAS
とはいえ一応内容について触れておくと、
> 書記素クラスタ
重ね文字等の事は知ってるぞ。ただ俺はこれは仕様が決まってないかと思っていたのだが、一応あるんだな。
外部ﾘﾝｸ:unicode.org
ただこれ、問題は"Unicode 16.0.0"と、バージョンがやたら高い事にあると思う。
自然言語が既に16回も改訂してるわけはないので、中途半端な仕様を決め、改訂しまくってるという事だから。
今の仕様で実装しても、出来上がる頃には仕様が改訂されている事もあり得る。
> コードポイントならUTF-32は4バイト固定だし
当然これも知ってるが、現実的にutf-32を使う事はほぼあり得ないだろ。
文字列処理は結局の所速度/メモリ重視だから、utf-32ではコードは書きやすいかもだが使い物にならない。
つかこの辺859に言ったところで通じるわけもなく、マウントが目的になってるのはお前の方だ。
だからこそ「上から目線」に過度に敏感なのがゆとりZの傾向でもあるが。
> むしろc言語はasciiという言い方は複数の意味でおかしい
話を続ける気があるなら、何の事なのかもう少し具体的に言え。
まあ一言ずつに纏めると、
859: PHPは文字の扱いに色々問題があるが、C言語にはない
860: お前は根本的に間違ってるから、文字コードについて勉強し直せ ← 859に通じる範囲で返事してる
862: 俺の方が詳しいのに上から目線ウゼエ ← マウントを取り返しただけで、859に通じるようには書いてない
ここら辺がゆとりZがコミュ障な所だ。
まあそれでもお互いにやるのは自由、よろしくやってくれ。
俺は降りる。
865: (ﾜｯﾁｮｲ c379-SOZQ) 07/01(火)10:03 ID:0aieN+8C0(1/2) AAS
普通に何も考えずに使ってて問題起きないならstrlen以外にもmbslenとかwcslenみたいなのを用意されることはないんだよな
866: (ﾜｯﾁｮｲ 7f7b-4xcB) 07/01(火)10:07 ID:O7C1rCRT0(1/2) AAS
ああついでに言っておくと、
ゆとり以前(＝俺)：内容が正しければ態度なんてどうでもいい
ゆとりZ：ボクがどんなにマヌケな間違いをしていたとしても、
優しく丁寧に教えてくれる事が絶対条件で、
優しければ内容が多少間違っていても許容される（←いやこれは俺は許容出来ねえ)
という違いだな。まあゆとりZ同士でよろしくやってくれ。
ただまあ、Qiitaのスレとかチラ見してるが、
発言の自由がある＝どんな馬鹿でも発言出来る＝間違った情報も当然発信される、なのだから、
Qiitaに正確性を求めるのは仕様的に無理なので、連中も間違ってて、
Qiitaは玉石混淆な上で、石が大量生産されるのは仕様として甘受し、玉を探すべきだとは思うがな。
とはいえQiitaが石→玉化する機構を持ち合わせられない(＝間違いを指摘する事すら出来ない)
のは上記ゆとりZ価値観の賜だから、詰んではいるが、それでも(Qiitaというサイトが)無いよりは断然いいし。
つまりだな、お前らゆとりZは「上から目線ガー」とか一々やってるから駄目なのであって、
「相手」(今回は859)に向き合う気がないから、
Qiita等の「一方的に発信するだけ」のツールは断然相性がいいが、
そこで「双方向な議論」とかはまるで出来ないんだと思うぜ。
859にとって困るのは、「上から目線」ではなく、「間違いを指摘してもらえない」事だろ。
(ただこれがゆとりZに取っては違うらしいので俺にはどうにも合わないが)
867: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)10:57 ID:M5z4vIa80(5/10) AAS
リンクは以下の方がよかったかも
外部ﾘﾝｸ[html]:hydrocul.github.io
> Grapheme cluster の境界定義
> CR の次に LF が続く箇所は境界にならない
これだとCRLFは一文字扱いだから、utf-8の0x7f以下だけ使っても(厳密には)asciiとは違うって事か？
なんで一々仕様を無駄に変更するのだ？という気はするが、
見てる限りunicodeって自然言語学者が策定してる仕様で、プログラミングのし易さなんてまるで考慮して無いな
868(1): (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)16:58 ID:W1sziXWKM(1/5) AAS
PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
C言語は指示しない限りは何もしないから、むしろ安全。
860は、馬鹿だから理解できない。
上下前次1-新書関写板覧索設栞歴
あと 134 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s