[過去ﾛｸﾞ] 【Bash】Windows Subsystem for Linux【WSL】4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
903(1): 2019/03/03(日)13:34 ID:1pyMh31m(1) AAS
UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった
結果的にマクロで切り替えは無駄に複雑にしただけだった
904(1): 2019/03/03(日)13:42 ID:F/LPV+rw(1/4) AAS
Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。
905(1): 2019/03/03(日)13:48 ID:FmObGCcg(4/4) AAS
関数名はAもWも書いてない
UNICODEを定義せずに
文字型はchar
これはA決め打ちと言ってもいい
906: 2019/03/03(日)13:55 ID:UGPBP+FA(2/6) AAS
>>903
> UNICODEの定義で切り替わるけどANSIバージョンとUNICODEバージョンの両方に
> きちんと対応したコードは少なくて大抵はどちらかに決め打ちだった
なんで両方に対応しなきゃいけなんだ？
Unicodeバージョンだけ作ればいいんだよ。
907: 2019/03/03(日)13:56 ID:UGPBP+FA(3/6) AAS
>>904
> Wしか使わないように実装したつもりでもランタイム組み込むとAが混ざる。
標準的なライブラリはすべてUnicode対応
サードパーティの古いライブラリなんか知らんわｗ
そのライブラリの問題だろ。
908: 2019/03/03(日)13:57 ID:UGPBP+FA(4/6) AAS
>>905
シンボルUNICODEを定義していなければ、A決め打ち
シンボルUNICODEを定義していれば、W決め打ち
通常はシンボルUNICODEを定義するので、W決め打ち
わかった？
909: 2019/03/03(日)15:43 ID:QnjPbk4c(1/4) AAS
linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。
なぜかというとVisual StudioでUTF-16に相当するwchar_tの型サイズや使い道が、他のコンパイラでは異なるから。
多くの人が使っている64bit版WSLのgccは既定でwchar_tがUTF-32なのは周知の事実でしょうに。
試しにWSLのgccでsizeof(wchar_t)を出力するプログラムを書いてみればすぐわかる。
910: 2019/03/03(日)16:11 ID:9h6OtHDD(1/2) AAS
まあ全部TCHAR系にしてun*x側で標準の(ワイドじゃない)文字列関数に展開するマクロを用意しとけば一応可能だけど
全体的にコードがキモくなるからやってるのはあんま見ないね
だいたいwmain用意しといて引数はさっさとUTF-8に変換して内部はchar*オンリーで
Windows依存のところでwchar*に戻すみたいなコードを入れてる気がする
ただそれもCJK圏の人が気を利かせてパッチ投げて追加されるなんて場合が多い感じだけど
911: 2019/03/03(日)16:21 ID:UGPBP+FA(5/6) AAS
> linuxと互換性のあるプログラムを書こうと思ったらA決め打ちにせざるを得ない。
だからマクロがあるんだろ。何を言ってるんだろうか？
もしかしてマクロの意味わかってない？
シンボルUNICODEで簡単に切り替えられるんだよ？
912: 2019/03/03(日)16:26 ID:UGPBP+FA(6/6) AAS
というか、そもそも言ってることがめちゃくちゃで、
AとかWというのはAPI呼び出しの話であって、
wchar_tとかには関係ない話。
> wchar_tがUTF-32なのは周知の事実でしょうに。
とかいうが、普通はLinuxではUTF-8を使うだろ？
おかしいよな？ちゃんと理由を説明できるかい？ｗ
UTF-8に変換して内部charというのなら、Windowsでも内部charで扱えばいいだけだし、
API呼び出しは話が別で、内部をUTF-8（char型）にしてるならAを使うのは間違っている。（実体はUTF-8だから）
この場合はUTF-8をUTF-16に変換してWを使うのが正しい。
な？言ってることメチャクチャだろ？
省1
913: 2019/03/03(日)16:45 ID:F/LPV+rw(2/4) AAS
やっぱり、日本が悪いニダ！
914(1): 2019/03/03(日)17:21 ID:QnjPbk4c(2/4) AAS
文字列に対する処理は、UTF8よりもUTF-16/32の方がコードを簡潔に書ける利点があるよ。
メモリ上はUTF-16/32、プロセス間のデータやりとりはUTF-8、という使い分けがさらに進んでいく気がする。
915: 2019/03/03(日)17:31 ID:9h6OtHDD(2/2) AAS
サロゲートペアとか考えるともうUTF-16はいらない子だと思うんですけど！
916: 2019/03/03(日)18:29 ID:pYe6Luxl(1) AAS
いつまで脱線続けるんだ？
917(1): 2019/03/03(日)19:51 ID:NJPd5Ggk(1/2) AAS
>>914
文字に対する処理はライブラリを使わないとやってられないんだから
もうそんなレベルじゃない。逆にライブラリ使えばどっちでもいい。
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
外部ﾘﾝｸ:tech.nikkeibp.co.jp
> 最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、
> 漢字1文字は必ずしも4バイト以内に収まらない。UTF-8でもUTF-16でも、
> 最悪8バイトは必要になると考えられる。
918: 2019/03/03(日)20:42 ID:QnjPbk4c(3/4) AAS
>>917
確かにそのとおり。一文字を固定長と決めつけたコードを書くこと自体が良くない。
将来、人類は知能の高い地球外生命体と遭遇してさらに文字が増える可能性もある。
919: 2019/03/03(日)20:55 ID:NJPd5Ggk(2/2) AAS
知能の高い地球外生命体と遭遇したら、
その知能の高い地球外生命体が使ってる文字コードを使えばいい。
宇宙コード、universe code、通称 unicode
920: 2019/03/03(日)21:10 ID:QnjPbk4c(4/4) AAS
知能の高い地球外生命体が使ってる文字コードがしれっとロケールのひとつとしてとりこまれる悪夢に10000ペリカ
921: 2019/03/03(日)22:01 ID:6s9AlSZU(1/2) AAS
知能の高い地球外生命体はchar=int=256bitとか使ってそうだがなあ
922: 872 2019/03/03(日)22:36 ID:ePOPdei3(1/2) AAS
>>901
まさにこれ！
Unicode は多国間で共通だけど、ANSI は各国で異なる。
ANSI は日本では、sjis になる
外人は、sjis を知らないし、
逆に日本人は、sjis 以外の他国の文字コードを知らない
外人は半角英数字で考えるから、char 配列で、1バイトずついじってくるから、
複数バイトで構成される文字で、バグる
上下前次1-新書関写板覧索設栞歴
あと 80 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s