5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C/C++で多言語対応でクロスプラットフォーム!

1 :デフォルトの名無しさん:2009/09/21(月) 12:26:51
JavaとかUNICODE化されている言語もあるけど
やっぱり基本はC/C++!

C/C++で多言語を使えて
しかもクロスプラットフォームな
アプリを作るノウハウを集めましょう。

2 :デフォルトの名無しさん:2009/09/21(月) 12:32:07
その前にお前は多言語対応なのかと問いたい

3 :デフォルトの名無しさん:2009/09/21(月) 12:33:07
ノウハウもなんも、wchar_tで一応Java程度のUnicode化(笑)は十分やれるし、
BoostでMTなんかも片付くし、あと何か困ることある? GUIとか?
GUIはクロスプラットフォームにしてもしょぼくなりがちだしなぁ…

4 :デフォルトの名無しさん:2009/09/21(月) 12:34:22
だらだら書いていきます。
間違っていたら訂正よろ


多言語対応にするには、内部をUNICODEで扱うのが一番。

一つの方法として、多言語対応の文字列クラスを提供している
クロスプラットフォームライブラリを使う方法がある。
(たとえば内部がUnicode化されているQtのQString)

が、既存の英語版アプリを日本語(多言語)対応にする場合、
そこにライブラリを導入して、文字列を全て変更するのは大変。


5 :デフォルトの名無しさん:2009/09/21(月) 12:40:39
>>3
wchar_tっていうだけじゃエンコード(UTF-8なのかUTF-16なのか)がわからない。


それから、たとえばフォルダの中のファイルを全部テキストファイルに出力するとして、
ファイル名にUNICODE文字列(日本語以外)が含まれている場合、
どういう方法をとれば、クロスプラットフォームにできるか。という話。

6 :デフォルトの名無しさん:2009/09/21(月) 12:40:42
皆空気扱いしてるlocaleとかfacetとか詳しい人いないのかな


7 :デフォルトの名無しさん:2009/09/21(月) 12:41:10
基本的には文字列を外部リソースにして作るだけ。

8 :デフォルトの名無しさん:2009/09/21(月) 12:44:39
Windowsだけに限れば、TCHARと_tcs系関数を使えば
UNICODEが定義してあるかどうかで、
_tcs〜関数が、str〜とwcs〜に置き換わる。 

9 :デフォルトの名無しさん:2009/09/21(月) 12:48:09
あぁi18nじゃなくて多言語対応か
ICUでも使えば

10 :デフォルトの名無しさん:2009/09/21(月) 12:55:31
>>7
その文字列はUTF-8?

UTF-8であれば、文字列型はcharのままで良いし、
printfで出力できる。なぜならUTF-8はANSIの
ように見えるように作られているから。

しかし、これがUTF-16であれば話が違ってくる。
UTF-16ならcharではなくwchar_tを使う必要がある。
wchar_tを使うと、printfではなくwprintfを使わないといけなくなる。

既存のアプリを修正する場合、変更の労力と影響範囲が違ってくる。

Windows API・・・たとえばMessageBoxは
ANSI版のMessageBoxAとUNICODE版のMessageBoxWがある。

WindowsにおけるUNICODEとはUTF-16LE。
文字列をUTF-8にすると、UTF-16LEに変換してからAPIに渡す必要がある。

クロスプラットフォームまで考えるといろいろと大変。
クロスプラットフォームライブラリを使いたいところだが、
既存のアプリの修正などで、そう簡単にいかない場合もある。

11 :デフォルトの名無しさん:2009/09/21(月) 13:03:36
そんな事は皆知ってるから

12 :デフォルトの名無しさん:2009/09/21(月) 13:08:43
さっき試した事例。

MinGWを使ってWindowsアプリを作った。(NTの話。9xはもうしらねw)
指定されたディレクトリのファイル名一覧を取得。
ファイル名には日本語文字にはないUNICODEが含まれている。

MinGWを使う→Linuxなどでもコンパイルできるソースが目的
なのでWindows APIを直接使うことははばかられた。

まずPOSIX準拠のopendir&readdirを使った。ファイル名を取得した段階ですでに文字化け。
日本語文字以外が ? に変換されてしまった。当たり前のことだろう。
そこで、_wopendir&_wreaddirを使ったらUTF-16LEとしてファイル名を取得できた。

プログラムを全てワイド系関数で書けるのなら、wchar_tとそれ系の関数を使えば解決?
しかし、charを使って書かれているアプリでは大変なことになるかもしれない。

それにwchar_tは扱いが難しそう。
wchar_tを使うときの罠
http://hw001.gate01.com/eggplant/tcf/cpp/wchar_t_trap.html
頼りなさげな wchar_t
http://blog.harapeko.jp/2009/07/25/wchar_t-suck/l

13 :デフォルトの名無しさん:2009/09/21(月) 13:09:29
>>11
じゃあ、あなたはどうやって解決しているんですか?

14 :デフォルトの名無しさん:2009/09/21(月) 13:14:58
ちなみに、std::string は UNICODE対応ではなく
std::wstringが別にある。

海外アプリはchar & std::string 使っているのばっかり。
日本のアプリでも同じような状況か?

なんでだろうか?

15 :デフォルトの名無しさん:2009/09/21(月) 13:28:00
Qt

16 :デフォルトの名無しさん:2009/09/21(月) 13:34:44
UNICODEの使用可能文字数は111万2,064文字

つまり、20bitでは104万8576文字分で足りず
21bit必要になる。

wchar_t型だが、VCでは符号無し16bit整数
Linux(GCC)では符号無し32bit整数

つまりVCでは明らかに足りないということになる。
VCではUTF-16LEで格納されるが、UTF-16にはサロゲートペアという
二つあわせて一文字分という機能があり、これで対応している。

つまりWindowsでは、wchar_t一つが一文字とは限らない・・・
Linuxでは楽なのだが。

17 :デフォルトの名無しさん:2009/09/21(月) 13:36:15
>>15
Qtいいよね。Qt Creator(RAD対応IDE)がでてから
格段に作りやすくなった。
最初、てっきりGUI作るだけのツールかと思っていたw

個人で0から作る場合はQt使うと思う。

18 :デフォルトの名無しさん:2009/09/21(月) 13:52:01
Qtの話がでたから、QStringについてちょっと調べてみたら
昔の話は置いといて、今の仕様は
UTF-16、エンディアンはシステム依存、サロゲートペア対応らしい。

オライリーの本にはUCS2と書いてあるみたいだけど
サロゲートペア対応ならUTF-16じゃね?

19 :デフォルトの名無しさん:2009/09/21(月) 13:55:51
wchar_tがUTF-8になることはあり得ないっつーの
つーかUnicodeとUTF-8とUTF-16とUTF-32の違いくらいは最低限知っとけよ…

20 :デフォルトの名無しさん:2009/09/21(月) 13:59:36
wchar_tがUTF-8になるって誰か言った?

処理系依存だから、UTF-8という実装も
ありかもしれないけど。

21 :デフォルトの名無しさん:2009/09/21(月) 14:01:32
>>5が言ってるな

22 :デフォルトの名無しさん:2009/09/21(月) 14:01:37
あぁ、>>5
> wchar_tっていうだけじゃエンコード(UTF-8なのかUTF-16なのか)がわからない。
のこれのことか

wchar_tっていうだけじゃエンコード(UTF-16LEなのかUTF-32なのか)がわからない。 に
訂正するよ。こまかいことは(ry

23 :デフォルトの名無しさん:2009/09/21(月) 14:02:51
>>21
ぶほっ

24 :デフォルトの名無しさん:2009/09/21(月) 14:02:59
何でLE限定なんだよw

25 :デフォルトの名無しさん:2009/09/21(月) 14:04:01
処理系依存でもUTF-8は無理だろJK
いきなりものすげーgdgdだなこのスレw

26 :デフォルトの名無しさん:2009/09/21(月) 14:05:59
>>24
じゃあ、好きなのに変えろよw

本質・・・ wchar_tっていうだけじゃエンコードがわからない。ってのに
変わりは無いだろw


サロゲートペア考慮しないといけない環境と
そうでない環境があるのwchar_tを使うのは
クロスプラットフォームなアプリ作成に置いて、
どうよ?って話をしろ。

27 :デフォルトの名無しさん:2009/09/21(月) 14:07:26
逆ギレ気味か

28 :デフォルトの名無しさん:2009/09/21(月) 14:10:41
どうせクロスプラットフォームなコードなんて、入出力はストリーム単位でコード変換
しなきゃならないんだから、変換関数で吸収する設計になるんじゃね?
入出力以外は普通にwchar_tでおk

29 :デフォルトの名無しさん:2009/09/21(月) 14:16:21
>>12
どっちの記事もwchar_tに過大な期待をしてるようにしか見えないけど
(特に二番目はUnicodeそのものの理解もかなり怪しげ)、世間的には
このくらい過大な期待をされてるのかもしれんね。
というより、Unicodeそのものが過大な期待をされてる気もするが。

30 :デフォルトの名無しさん:2009/09/21(月) 14:19:31
>28
wchar_tを使うとして、エンコードは?

31 :デフォルトの名無しさん:2009/09/21(月) 14:21:12
#ifdefで分岐

32 :デフォルトの名無しさん:2009/09/21(月) 14:21:46
>>28
ファイル名に関してどうすんの?

33 :デフォルトの名無しさん:2009/09/21(月) 14:22:29
>>30>>32
>>31

34 :デフォルトの名無しさん:2009/09/21(月) 14:25:12
>>33
いや、そうじゃなくてだねw
聞きたいのは、

#ifdef 何のとき?
 どんなデータ型でどんな関数を使う?
#else
 どんなデータ型でどんな関数を使う?
#endif

って話だよw

35 :デフォルトの名無しさん:2009/09/21(月) 14:25:35
>>1-1000
>>31

36 :デフォルトの名無しさん:2009/09/21(月) 14:25:59
訂正

#ifdef 何のとき?
 どんなデータ型でどんな関数を使う?
#else
 どんなデータ型でどんな関数を使う?
#endif

(共通部分では)どんなデータ型でどんな関数を使う?


37 :デフォルトの名無しさん:2009/09/21(月) 14:27:31
こまけぇことはいいんだよ
UCS-4をそのままぶっこめ
basic_string<uint32_t>
gccならwchar_tにそのまま入るだろ

38 :デフォルトの名無しさん:2009/09/21(月) 14:28:27
対象プラットフォームごとに定義されてるマクロを見て、wchar_tが示す型を調べて、
あとはどうにでもなるだろ
wchar_tを使わなくてもできることだが、使ってもできることだし、使わなくても
結局は似たようなことをやる

39 :デフォルトの名無しさん:2009/09/21(月) 14:30:00
いや、どうにでもなるのはわかるよw

実際どうやっているの?
ってか、やったことあるの?

40 :デフォルトの名無しさん:2009/09/21(月) 14:32:20
>>1
多言語対応でクロスプラットフォームなコードなんてどこで必要なの?

41 :デフォルトの名無しさん:2009/09/21(月) 14:38:09
>>40
あなたに関係の無い世界で必要

42 :デフォルトの名無しさん:2009/09/21(月) 14:38:41
さっきから取っ組み合ってる片方が>>12の二番目のURLの芸風に似てるな

43 :デフォルトの名無しさん:2009/09/21(月) 14:40:37
世の中狭いから本人かもね
読んでないけど

44 :デフォルトの名無しさん:2009/09/21(月) 14:44:22
>>41
お前にも関係ないなw

45 :デフォルトの名無しさん:2009/09/21(月) 14:48:11
URLコピペミスしてる辺り怪しいなw>>12

46 :デフォルトの名無しさん:2009/09/21(月) 18:13:08
wchar_t使うって言っている人はクロスプラットフォームで作ったことあるのかな?

今風呂掃除をしてついでに風呂に入って、いろいろやってみたら
Linuxではwfopen(_wfopen)が無いらしい。

多言語で問題なのはファイルの中身よりもファイル名の方なんだよね。
中身の処理はアプリ内で完結するけど、ファイル名はOS(ライブラリ)から
渡されたり逆に渡したりしないといけないから

UNICODEが含まれた名前のファイルを開くとき、
Linuxではchar型にUTF-8を入れて、fopenで呼び出す。
Windowsではwchar_t型にUTF-16LEを入れて、wfopenで呼び出す。
いろいろ面倒だなw どちらにしろコード変換処理をなくすことはできないと。

VLCのソースコード見てみたら、utf8_open(utf8_fopen)という関数を作ってあって、
名前のとおり、char型UTF-8をファイル名に指定して、そこでWINなら
パスをUTF-16LEかな?に変換して_wopenを呼び出していたよ。
wchar_tはその変換部分ぐらいにしか使っていなかった。
ちなみに、utf8_opendirなんかもあった。

47 :デフォルトの名無しさん:2009/09/21(月) 22:31:14
内部でどういう形式で保持するのかという事と
プラットフォーム依存部分で変換することの違いをわかってるのかね

48 :デフォルトの名無しさん:2009/09/21(月) 22:40:42
>>47
君は内部でどう持っているの?

49 :デフォルトの名無しさん:2009/09/21(月) 22:47:04
UTF-32に決まってるじゃないか!

50 :デフォルトの名無しさん:2009/09/21(月) 22:49:06
>>49
ということは、Windowsのファイル名(UTF-16LE)
Linuxのファイル名(UTF-8 or EUC)は
UTF-32に変換して保持しているの?

変換には何を使ってる?

51 :デフォルトの名無しさん:2009/09/21(月) 22:50:55
あとWindows版のwchar_tは16bitなんだけど、
何型使って、UTF-32を保持しているの?

52 :デフォルトの名無しさん:2009/09/21(月) 22:52:21
http://www.ibm.com/developerworks/jp/java/library/j-u-encode.html
頑張ってね!

53 :デフォルトの名無しさん:2009/09/21(月) 22:55:55
>>52
それぐらいの内容は知っているが、
問題は、C/C++でどのようにして使うかという
実践的なところなんだよな。

54 :デフォルトの名無しさん:2009/09/22(火) 14:28:26
Qt 使おっと……

55 :デフォルトの名無しさん:2009/09/25(金) 18:06:31
wchar_t が UNICODE だなんて決まってないんじゃないの?
EUCの2バイトをwchar_tにつっこむシステムは死滅したの?

56 :デフォルトの名無しさん:2009/09/25(金) 19:08:49
>>55
誰に言ってんの?

57 :デフォルトの名無しさん:2009/09/26(土) 04:05:14
wchar_tとか中途半端なものを作ったよな。
Windowsでは2バイト
Linuxでは4バイト、
しかもUTF-8なんか、1バイト〜4バイトだよ。
どうやって入れれば良いんだよw


58 :デフォルトの名無しさん:2009/09/26(土) 13:03:28
UTF-8を「ワイドキャラクタ」として扱うのは無理があるような

59 :デフォルトの名無しさん:2009/09/26(土) 13:49:50
UTF-8はcharでいいんじゃ。

60 :デフォルトの名無しさん:2009/09/26(土) 13:53:40
charでいいのなら、なんでwchar_tなんてもの作ったの?って感じだよなw

61 :デフォルトの名無しさん:2009/09/26(土) 14:23:17
wchar_tなんて使ったこと無いんだけど

62 :デフォルトの名無しさん:2009/09/26(土) 17:00:04
wchar_t ができた頃には、まだUNICODEなんて存在していなかった。

63 :デフォルトの名無しさん:2009/09/29(火) 22:06:02
C/C++ ってなんか歴史的経緯のゴミとか問題ががたくさん残ってるんだけど
枯れ枯れ性を偏重して進化が遅いっていめーじ。
標準関数に脆弱性があって使わないほうがいいものがあるとか、もうアボガドかと。


64 :デフォルトの名無しさん:2009/09/29(火) 23:42:47
クロスプラットフォームって響きはいいけど実利無さそ

65 :デフォルトの名無しさん:2009/09/30(水) 19:33:41
オープンソースのフリーソフトウェアとして名を上げるつもりがないんだったら、
あまり実利はないかもね。

66 :デフォルトの名無しさん:2009/10/01(木) 13:38:51
かもね。

67 :デフォルトの名無しさん:2009/10/01(木) 13:45:21
名を上げて金と女を手に入れたいです

68 :デフォルトの名無しさん:2009/11/30(月) 18:06:18
>>12>>46
ファイル一覧はwchar_tで取って、ファイルのopenはcharにするのか。
wchar_t -> charはキャストするだけでは駄目だよね。
その部分のコードわかりますか

69 :デフォルトの名無しさん:2009/11/30(月) 18:19:16
すべてのlinuxでopendirを使ったプログラムは
確実に動作しますか。wopendirしないにと駄目な場合がありますか。
windowsでは長いファイル名がとれないとかありますが。
opendirで確実に動くなら、windows側では内部で
wchar_tで動作させて返却すれば善さげですが。

70 :デフォルトの名無しさん:2009/11/30(月) 18:25:24
linux windowsで共通して長いファイル名にアクセスする方法ありますか。
wchar_tで\\?\を付けるのはwindowsのみですよね。

71 :デフォルトの名無しさん:2009/11/30(月) 18:38:21
そもそもディレクトリの区切り文字が \ と / で違うわけだが

72 :デフォルトの名無しさん:2009/11/30(月) 19:13:33
windowsで / = 0x2F 使えばいいだけですね。こっちでも動作するので。

73 :デフォルトの名無しさん:2009/11/30(月) 19:15:51
疑問点があるのですが。
windowsは、パス名に\を含む文字があっても動作するのはなんででしょうか。
char読んだ時点では、区切りか漢字か判別できないはずですが

74 :デフォルトの名無しさん:2009/12/01(火) 01:15:51
内部ではUnicodeに変換してUnicodeで扱ってるから

17 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)