[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
496(1): 2021/06/24(木)21:10 ID:3QBHDC7A(1) AAS
>>495
メモリ確保するようなクラスの場合、メモリ確保の手間省ける。
それ以外でムーブにコピー以上の利点知らない
497: 2021/06/25(金)00:44 ID:+R97TjGx(1/2) AAS
んまー（通常の関数呼び出しと違って）コピコンは放っといても勝手に呼び出しが削減される（副作用がある可能性ガン無視で）からな
昔から
498(1): 2021/06/25(金)00:55 ID:+R97TjGx(2/2) AAS
コピコン呼び出し最適化に頼らねばにっちもさっちも行かないシチュエーションは多々あるから
右辺値参照はﾏｼﾞ不完全
例えば
Foo operator+(const Foo& lhs, const Foo& rhs) {
Foo x(lhs); // 馬鹿正直にやったらコピー1回
x += rhs; // Foo& Foo::operator+=()が定義済みとする
return x; // 馬鹿正直にやったらコピーがもう一回
}
みたいな、
とこの前思いました
省1
499(2): ◆QZaw55cn4c 2021/06/25(金)01:03 ID:pWufOIHg(1) AAS
>>496
要はクラスC のオブジェクトA の中にポインタがあった場合、オブジェクトA を今後一切つかわない前提でオブジェクトA の持つポインタの値をオブジェクトB にコピーするやりかた、ということですよね
言われるほど凄い機能にも革新的な機能にも思えないので来ているのですが、クラスを返すときには、もしかしたら使えるかもしれませんね
でも、すでに RVO があるのでしょう？
500: 2021/06/25(金)01:11 ID:xLwe8284(1) AAS
>>498
それは左辺値参照だよ。
501: はちみつ餃子 ◆8X2XSCHEME 2021/06/25(金)01:12 ID:/YhIejlL(1/2) AAS
>>499
それが出来るということは重要じゃなくて文脈によって勝手に使い分けられるということに意味があるんだよ。
502: 2021/06/25(金)04:23 ID:2CfGrUVh(1) AAS
move対応してないデカいクラスはマジ迷惑だろ
503: 2021/06/25(金)06:23 ID:+QaNJXlp(1/4) AAS
ポインタ、参照、this、スマポ、[&]
いくらでもどうにでもなる
504: 2021/06/25(金)06:38 ID:byKvXpEn(1) AAS
えっ老害？？
505: 2021/06/25(金)06:40 ID:FhN3idtW(1) AAS
>>499
RVOはC++17で保証されたけどNRVOは保証されてない
506(1): 2021/06/25(金)07:44 ID:+QaNJXlp(2/4) AAS
C++03時代を生きてないやつからはそう見えるのか
507: 2021/06/25(金)08:48 ID:z3/X9CIt(1/2) AAS
{a, b, c,...} が a, b, c,... という要素からなるリストを表すとき、
{a, {b, {c, d}, e}, f, g, {h, i},...}
みたいな構造は a, b, c,... が全部同じ型だとしても tuple としてしか表せませんよね？
508(1): 2021/06/25(金)10:23 ID:Wd+wOk9Z(1) AAS
json
yaml
listのtree
なんでも
509: 2021/06/25(金)10:45 ID:z3/X9CIt(2/2) AAS
>>508
ありがとうございます
そうですね。STLとかboostのコンテナに囚われ過ぎてました
510: 2021/06/25(金)10:52 ID:tyTj/nU0(1) AAS
老害はC++スレに書き込むなよ
昔の話ばっかだよおじいちゃん
511: 2021/06/25(金)13:12 ID:+QaNJXlp(3/4) AAS
後から入ってきたくせに図々しいやつだな
先住権てやつでこっちが偉いんだよ
気に入らねえんなら他当たるか自分でサーバー立てな
512: 2021/06/25(金)13:16 ID:cHfQsTpJ(1) AAS
C++03の話なんてもうすんなよ
C++11からはもう別言語やんか
513: 2021/06/25(金)13:27 ID:+QaNJXlp(4/4) AAS
おまえの主観は関係ない
514(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/25(金)13:41 ID:/YhIejlL(2/2) AAS
>>506
C++03 時代を知ってるからそれが (少なくとも C++11 に比べれば) クソだってこともよく知ってるよ。
515: 2021/06/25(金)13:43 ID:ALny3hkX(1/2) AAS
本気で別言語だと思ってるやつって大抵何も作ってないゴミガキだと思うけどなぁ・・
STL的なアルゴリズムや新要素と親和性が高いのは、基本的に標準ライブラリだけなんだが
最近各種コンストラクタ(ムーブ込み)、代入等だけ長々と書いて「実質ほぼ何もしないクラス」を書いてドヤってるアホとかよく見かける
便利になってるのは確かだけどね・・
516: 2021/06/25(金)13:45 ID:ALny3hkX(2/2) AAS
>>514
俺も必要もなく03以前で書きたいとはまず思わんが、クソとか貶すのはやめた方がいいと思うよ
517: 2021/06/25(金)18:07 ID:aibvvCTW(1) AAS
gets()とか好きそう
518: 2021/06/25(金)18:33 ID:xqBptTy/(1) AAS
(σ・∀・)σｹﾞｯﾂ!!
519: 2021/06/26(土)00:08 ID:O9GH5wVp(1) AAS
ゲッツって初めて聞いた
ゲットエスって読んでたんだが
520: 2021/06/26(土)07:06 ID:MV3qzcHy(1) AAS
こことCスレでは古くからあるネッスラだよ
521: 2021/06/26(土)07:21 ID:+MI3rh96(1) AAS
scanf()をスキャンフと呼ぶけどprintf()をプリントエフと呼ぶ感じ
522: 2021/06/26(土)08:05 ID:vR4ZYNRj(1) AAS
プリンテフ
523: 2021/06/26(土)08:08 ID:EcYCTODA(1) AAS
ifndef イフンデフ
524: 2021/06/26(土)11:51 ID:7nyRjnb4(1) AAS
アとイ
525: 2021/06/26(土)13:16 ID:l0P5IISj(1) AAS
C++20でもバイナリファイルからdoubleとかの値を読み出す時って未だにreinterpret_cast使う感じ？
526: 2021/06/26(土)16:37 ID:qjgQHw2b(1) AAS
HTML★ふとまる
527: 2021/06/27(日)10:16 ID:0fbyaJPK(1) AAS
basic_istream::readの引数がvoid*なら何も悩まずに済むのにな
528: 2021/06/27(日)11:20 ID:hddKqCef(1) AAS
ファイルに書いている時点でアラインメントの保証が難しいから結局memcpyになる気がする
529: 2021/06/27(日)12:53 ID:CJK40NDs(1/3) AAS
アライメントの問題はファイル関係なくね↑？
530(2): 2021/06/27(日)13:14 ID:CJK40NDs(2/3) AAS
エンディアン変換が関係しない場合
C++20でもバイナリファイルからdoubleとかの値を読み出す時はfread()
書き込むときはfwrite()
何の問題も無いし速い……
531: 2021/06/27(日)13:16 ID:CJK40NDs(3/3) AAS
ていうかエンディアン変換が関係する場合でも
fread()してからメモリ上でエンディアン変換しても良いし
メモリ上でエンディアン変換してからfwrite()したら良い
特にファイル内容全体がメモリ上に収まるケースとかは上記だけでほとんど何も考えなくてもよい
532: 2021/06/27(日)13:48 ID:NNV++T6E(1/2) AAS
P言語、Ruby、Java、C#などでファイルを読んだり書いたりしなければならなくなることを想定したファイル仕様にしたほうがいいと思うけどどうかな
533: はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)13:55 ID:+5rTVQj/(1/7) AAS
スタンダードレイアウトな型はバイナリレベルでコピーしてかまわないし
結果的に fwrite して fread できることは保証されるが、
具体的なレイアウトについての保証はない (他の処理系では同じレイアウトにならないかもしれない)
ということも合わせて考えると適当なシリアライザは挟んだほうが良いな。
多言語を意識しつつ高速なバイナリフォーマットというと MessagePack あたりかな？
534(1): 2021/06/27(日)13:57 ID:mY5L/v8k(1/4) AAS
PerlやPythonでバイナリ読み書きするのに何の支障もないだろ。
535(2): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)14:00 ID:+5rTVQj/(2/7) AAS
>>534
読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。
536: 2021/06/27(日)14:16 ID:U1pSP8r9(1) AAS
バイナリなんだからどう扱おうが自由だろ
言語のせいにするのは本人の技術が無いから
言い訳するな
537(2): ◆QZaw55cn4c 2021/06/27(日)14:25 ID:I46qTe+f(1/3) AAS
今時数値をバイナリで読み書きするとか、あり得ないのでは？
538(1): 2021/06/27(日)14:30 ID:NNV++T6E(2/2) AAS
Comparison of data-serialization formats - Wikipedia
外部ﾘﾝｸ:en.wikipedia.org
539(1): 2021/06/27(日)15:19 ID:o9peEwic(1) AAS
>>537
バイナリでないと実用的でないデータなんていくらでもあるし。画像、動画、アーカイブ、db、ip...
qzはもうエロ画像見るなよ。
540: ◆QZaw55cn4c 2021/06/27(日)15:44 ID:I46qTe+f(2/3) AAS
>>539
ごめんなさい誤りましたので謝りますからその刑だけは平にご容赦を‥‥
541(1): 2021/06/27(日)15:47 ID:mY5L/v8k(2/4) AAS
>>535
保証されてるから支障はない。エンディアンが違うデータだって読み書きできる。
542(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)15:54 ID:+5rTVQj/(3/7) AAS
>>541
データがリトルエンディアンなのかビッグエンディアンなのかわかっていればね。
C++ が単にメモリ上のデータを書き出したときに、それがどっちなのか、
(言語としては) 保証してないって話をしてるんだよ。
543: 2021/06/27(日)16:14 ID:jKhjPg/S(1) AAS
C++20でstd::endianが使えるようになるけど
544(1): ◆QZaw55cn4c 2021/06/27(日)16:39 ID:I46qTe+f(3/3) AAS
シェアの高かった 68 系かインテルザイログ系か、の二分図がここにも残っているのですか
もう UTF-8 のようなエンディアンに依存しないバイナリが優秀だ、という価値観にするべきかと
545: 2021/06/27(日)17:01 ID:CxF0bT8t(1) AAS
インターネットのプロトコルはビックエンディアン
USB等のPC系発祥のデバイスはリトルエンディアン
この辺はもう変更しようが無いだろ
546(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)18:13 ID:+5rTVQj/(4/7) AAS
>>544
ここでのトピックは >>530 に対しての反論。
メモリ上にあるバイト列には保証がないからなんらかの明確な
データ交換用フォーマットに変換する処理が必要という話で、
出力先のデータ交換用フォーマットが BE か LE かなんていう以前の段階。
547: はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)18:17 ID:+5rTVQj/(5/7) AAS
ファイルに書き出すにあたって「エンディアンの変換が不要なら」という前提を置きたくねぇなぁという話だな。
パディングとかも入るかもわからんし。
548(2): ◆QZaw55cn4c 2021/06/27(日)19:47 ID:igNiq52h(1) AAS
>>546
であれば、私はどちらかというと >>530 の味方側ですね、>>530 がそう意図しているかどうかは不明ですが、処理系のエンディアンを仮定することなくコードを書くことは可能だったと記憶しています。‥‥?
ただ同時に、確かにパフォーマンスの点で過剰な不利を承知で >>537 を再提示するべきかな
つまり、>>537 みたいな画像フォーマットはありました PPM/PGM/PBM
2chｽﾚ:tech
このコードは?を検証したものだったかと遠い記憶に残っていますね
あ、罰ゲームは勘弁ね、私だってエロ画像は見たい‥‥動画ﾘﾝｸ[YouTube]
549(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)20:29 ID:+5rTVQj/(6/7) AAS
>>548
だからそういうコードが書けるかどうかという話じゃなくて
書かなきゃなんない (書くべき) ねという話なんだってば。
550: ◆QZaw55cn4c 2021/06/27(日)20:58 ID:2wFMzLzL(1) AAS
>>549
それは失礼しました
551(1): 2021/06/27(日)22:44 ID:mY5L/v8k(3/4) AAS
>>542
C++だって読もうとするバイナリデータのエンディアンを事前に知らなきゃならんのは変わらんだろ。
自分で書いたものを読むならエンディアンが一致するのはあたりまえ。
552(2): はちみつ餃子 ◆8X2XSCHEME 2021/06/27(日)23:46 ID:+5rTVQj/(7/7) AAS
>>551
> エンディアンを事前に知らなきゃならんのは
知らなきゃならないがわからん (保証されてない) のだという話をしている。
C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。
言語が何であれデータフォーマットが固定されてないとどうにもならん。
553(1): 2021/06/27(日)23:53 ID:mY5L/v8k(4/4) AAS
>>552
それは言語関係ない話だろ。
554(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/28(月)00:31 ID:nxXyAxnK(1) AAS
>>553
言語に関係あるという話はしてないよ。
555: 2021/06/28(月)00:34 ID:AdoNh79c(1) AAS
Javaはメモリモデルも明確に決まってたんじゃないかな
556(1): 2021/06/28(月)02:47 ID:DsF+RsPk(1/2) AAS
多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ！
557: 2021/06/28(月)03:12 ID:DsF+RsPk(2/2) AAS
どうしてもバイナリファイルが良いという向きは、
パディングとかもfwrite()とfread()で取り扱い得る
といっても単に適当なサイズのバイトの配列として読み書きして
メモリ上でご使用のアーキテクチャーに合わせることになるが
fwrite()とfread()を使わなければもっとﾏｼになるという類の話ではない
558(1): 2021/06/28(月)03:44 ID:QdlxBFRk(1) AAS
別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか
559(1): ◆QZaw55cn4c 2021/06/28(月)07:17 ID:oYDZ1nWa(1) AAS
>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします
560(2): 2021/06/28(月)07:48 ID:cZa6zFVz(1) AAS
>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。
561: 2021/06/28(月)08:30 ID:RYml5aTx(1) AAS
これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい
562: 2021/06/28(月)09:09 ID:XSoi24Ug(1) AAS
僕はノンバイナリーだから読みたくないです
563: 2021/06/28(月)09:56 ID:SQEqm/bz(1) AAS
こんどはバイナリに噛み付いてるキチガイがいるな
564: 2021/06/28(月)11:09 ID:bLKGwGq9(1) AAS
標準ライブラリのみであれば車輪の再発明しか手段がない？
565: 2021/06/28(月)12:52 ID:bIZ7S0Sd(1/2) AAS
MsgPack は json と同じで無駄が多い
566: 2021/06/28(月)12:59 ID:bIZ7S0Sd(2/2) AAS
>>558
温暖化詐欺SDG詐欺と手口が一緒だな
567: 2021/06/28(月)13:35 ID:quG4wdoj(1) AAS
>>559
WSL2, Ubuntu 18.04 では、
apt list --installed libxml2
libxml2/bionic-updates,bionic-security,bionic-updates,bionic-security,
now 2.9.4+dfsg1-6.1ubuntu1.4 amd64 [インストール済み、自動]
568(1): 2021/06/28(月)13:52 ID:5OdlGlMi(1) AAS
Comparisonて何て読むの？
コンパリソン？
569(1): 2021/06/28(月)14:55 ID:qFu4iqR6(1) AAS
msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット
570: 2021/06/28(月)14:56 ID:R7ScYjSP(1) AAS
>>568 こんｐぇぁりｚん 外部ﾘﾝｸ:www.google.com
571: 2021/06/28(月)15:26 ID:JcAv6JCW(1/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合
この表現すき💛
572: 2021/06/28(月)15:26 ID:JcAv6JCW(2/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合
この表現すき💛
573(1): 2021/06/28(月)16:13 ID:dKXkMhte(1) AAS
>>569のお勧めは何？
理由もセットで教えて頂戴。
574: 2021/06/28(月)16:32 ID:uBCftstC(1) AAS
「モジュール」はC++で作られたパッケージを配布しやすくしますか？
575(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:03 ID:OP5z1lEO(1/2) AAS
>>560
そうだよ。 その当たり前の話をしてるんだよ……。
互換性の問題というのは内部的なものなら問題が起きたときに修正すればいいが、
外部に出ているデータはそれに皆が合わせなければならない仕様と化すので
特定の C++ 処理系 (実行環境) でなら処理できるけど
出力されたデータフォーマットの詳細はわからんし処理系のバージョンがちょっと変わったら変わるかもしれん
というのでは困るやんというごく普通の話。
(もちろん普通の処理系はちょっとバージョンが更新されたくらいでは
バイナリ互換性をあまり壊さないように配慮するのが普通ではあるけど。)
576(1): 2021/06/29(火)00:15 ID:MxyOwUyS(1/5) AAS
>>575
いつのまにか話ずらしてんな。
>>535
>読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。
言語上の型とバイナリの対応付けはPerlでもPythonでも保証されてるんだよ。
577: はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:20 ID:OP5z1lEO(2/2) AAS
>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。
578(1): 2021/06/29(火)08:12 ID:MxyOwUyS(2/5) AAS
>BE か LE かわかっていない状況
これの意味だが
・全く何の情報もない状況
→どんな言語を使おうが正しく読める保証がないし論ずるだけ無駄。
・>>552の「C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。」状況
→「自環境のエンディアン」で読めるのはC++でもPerlでもPythonでも同じ。
579(1): 2021/06/29(火)08:29 ID:qbDSHPwG(1) AAS
>>573
方法はともかく、普通にビット列かバイト列のレベルで仕様を決めてその通りに読み書きすりゃいいんじゃない
C++プログラマなら生データの扱いは得意でしょ
とはいえ手間がかかるしミスを生じやすいのも事実なので、めんどくせえ今すぐ読み書きしたいってだけならprotobufとかavroとか他にも色々あるよ
msgpackとの大きな違いはスキーマの有無で、スクリプト言語じゃなきゃスキーマはあったほうが便利だし、一般に実装が高速になりやすくデータサイズも小さくできる
580(1): 2021/06/29(火)08:38 ID:zFDqDEto(1) AAS
>>579
「他人含めた仕様の強要」という観点が抜けてない？
それに、何回車輪の再開発させるつもりだよ。
581: 2021/06/29(火)08:57 ID:bpKPj1F0(1) AAS
>>580
強要したいならちゃんと仕様書書いて押し付けるだけの話
実装が面倒ってんならそれこそprotobufのようなスキーマのある汎用フォーマットならスキーマさえ書いとけば大抵の言語でserde用の型の自動生成までやってくれるよ
その点で言えばmsgpackは所詮mapなんで、仕様を強要したいなら別途仕様書が必要になるよ
582: 2021/06/29(火)10:54 ID:c9Dh6S0q(1) AAS
実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない
583: 2021/06/29(火)12:00 ID:gO51uzZW(1) AAS
他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない
584(1): 2021/06/29(火)13:20 ID:IWxlvq96(1/4) AAS
>>560
Perlでバイナリを扱うのは物凄く大変だった。
さまざまな自動変換がかかってしまうので、結局どうなるのかが分からない事が
多かったから。
例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
なってしまったり、物凄く難しかった。
ASCIIコードの数値番号を取得したいと思っても、結果が数値の入った文字列に
なったりとか、よく分からない事が多かった。
何を何に変換しているのか、めちゃくちゃ難しかった。
省1
585: 2021/06/29(火)13:23 ID:IWxlvq96(2/4) AAS
>>584
16進数も複雑だった。
単に表示したいために16進数の文字列に直したら、どこかで勝手に数値として
解釈されていつの間にか思いもよらぬ「もの」に変化したりとか。
それで、バイナリや文字を細かく扱い際には、如何にCが楽であるかを思い知った。
586(1): 2021/06/29(火)14:44 ID:UyxOx+sC(1) AAS
Cというか、それは最早動的型付けか静的型付けかとかの話では
587: 2021/06/29(火)15:11 ID:IWxlvq96(3/4) AAS
>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。
588(1): 2021/06/29(火)15:25 ID:MxyOwUyS(3/5) AAS
pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。
589(1): 2021/06/29(火)15:37 ID:IWxlvq96(4/4) AAS
>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。
590: 2021/06/29(火)18:21 ID:7i3kfcoq(1) AAS
強気なこと書き込む人はだいたい経験浅い
591: 2021/06/29(火)18:35 ID:tM55IFN7(1) AAS
ボカァもうOOPは捨てた！ｗ
592(1): ◆QZaw55cn4c 2021/06/29(火)18:54 ID:qfvhyFdx(1) AAS
>>578
あなたはちょっと残念な人ですね
実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥?
?の証拠は >>548
ことほど左様に、処理系に独立して LE/BE を書き分けることができるのなら「〜するべき」とかいう「べき論」は無意味でしょう
多分、はちみつ氏は?を失念していたのでしょう、べき論なんて振り回しても無駄なのに、あいかわらずべき論に拘泥するところなどは「ダメリカ様が守ってくださる！」的な馬鹿左翼並の振る舞いですから、そろそろあきらめるべきでしょうね
593: 2021/06/29(火)21:05 ID:MxyOwUyS(4/5) AAS
>>592
？
なにか別の話とごっちゃにしてないか？べき論って？？？
>実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥?
C/C++じゃなくてもPerlやPythonだってLE/BE書き分けられる手段は用意されているって話をしていただけなんだがな。
594: 2021/06/29(火)21:08 ID:MxyOwUyS(5/5) AAS
>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。
>例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
>文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
>なってしまったり、物凄く難しかった。
これなんかまさにそうだな。
595: 2021/06/29(火)23:39 ID:uMLxaJ5z(1) AAS
この話のゴールどこ？
上下前次1-新書関写板覧索設栞歴
あと 407 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.224s*