[表示 : 全て 最新50 1-99 101- 201- 2chのread.cgiへ]
Update time : 05/09 14:08 / Filesize : 51 KB / Number-of Response : 231
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++で新しい文字列クラスをつくろう 2



1 名前:デフォルトの名無しさん [2006/12/26(火) 20:24:15 ]
CString , string , wstringに負けないものをみんなで作ろうね。

前スレ: pc8.2ch.net/test/read.cgi/tech/1044098312/

2 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 20:25:17 ]
CFString

3 名前:デフォルトの名無しさん [2006/12/26(火) 20:25:17 ]
>>1
おお、いいスレが立ったな。乙!

4 名前:デフォルトの名無しさん [2006/12/26(火) 20:30:13 ]
こんなスレが欲しかった
>>1

5 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 20:30:50 ]
Stringでどうよ?

6 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 20:33:40 ]
でもそれ.NETがなきゃ動かんじゃん

7 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 20:34:47 ]
>>3
>>4
自演乙(藁
そして終了(禿藁

8 名前:デフォルトの名無しさん [2006/12/26(火) 20:36:20 ]
>>1はどうでもいいから前スレで挙がってたC2charうpきぼん

9 名前:デフォルトの名無しさん [2006/12/26(火) 20:41:06 ]
>>8 =>>1な罠(藁

10 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 20:45:25 ]
      ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′  ̄ ̄( ゚Д゚)< >>1は早急に逝ってよしだゴルァ!!
  UU ̄ ̄ U U  \_____________



11 名前:1 mailto:sage [2006/12/26(火) 20:58:01 ]
伸びないなぁ。
>>8も俺からもきぼん!

12 名前:1 mailto:sage [2006/12/26(火) 20:59:49 ]
仕方ない
俺が作った(まだ発展途上だけど)かなり便利な文字列クラスをあげるか
それをみんなで改造しよう!!11

13 名前:1 [2006/12/26(火) 21:07:07 ]
上げました。
tune.ache-bang.com/~vg/outitem/up/img/12431.txt

14 名前:1 mailto:sage [2006/12/26(火) 21:09:52 ]
>>13←なんとこれ作るのに丸一日かかりました!疲れた...

15 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:11:32 ]
String使えよ。

16 名前:1 [2006/12/26(火) 21:13:40 ]
アドレス間違えました
tune.ache-bang.com/~vg/outitem/up/img/12432.txt

17 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:14:01 ]
String使えよ。

18 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:15:16 ]
>>17
>>6

19 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:18:16 ]
>>18
.net使えばいいだろ。


20 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:20:47 ]
基本的にstd::stringとstd::stringstreamでできるなー。
それを交えて作り直してみたらコードかなり圧縮できるとおもう。

あと、>>1のクラスのformatメソッドがやばいと思う。



21 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:22:35 ]
NSStringをC++でラップしたら強いのが出来そうじゃね?

22 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:24:01 ]
>>16
丸一日掛かってこれかよ(プ

23 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:27:10 ]
前スレはdat逝きか
makimo.toにも無かった

24 名前:デフォルトの名無しさん [2006/12/26(火) 21:32:47 ]
vsprintfはwvsprintf使うべき

25 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:36:15 ]
STLのstringは、マルチバイト文字をまともに扱えるの?

26 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:37:59 ]
>>25
あれは基本的にコンテナなんだと思うけど。

27 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:40:37 ]
みんなwstring使えば解決
なんでみんなUNICODE使おうとしないのか

28 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:42:54 ]
wvsprintfってウインドウズ?


29 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:59:36 ]
さようなら>>1の人。

30 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 22:02:44 ]
D言語マンセー



31 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 22:13:42 ]
D言語もまともなstringがない。
main(char[ ][ ])だもんな。。。

32 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 22:53:25 ]
>>31
つ std.string/std.conv
"test".toupper()とか"12".toInt()とか可能。

33 名前:デフォルトの名無しさん mailto:sage [2006/12/27(水) 00:59:26 ]
つ ttp://tricklib.com/cxx/dagger/xstring.h

34 名前:デフォルトの名無しさん [2006/12/27(水) 01:21:32 ]
最強の文字列クラスを作るスレ
とかの方がよかったんじゃないか

35 名前:デフォルトの名無しさん mailto:sage [2006/12/27(水) 17:55:20 ]
>>21
CFString

36 名前:1 mailto:age [2007/01/31(水) 00:29:04 ]
まだあったんだコノスレ(

37 名前:デフォルトの名無しさん mailto:sage [2007/01/31(水) 04:24:08 ]
AnsiStringは放置ですか。そうですか。

38 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 01:01:54 ]
>>1
まずCString, string, wstringには現状どのような問題点があるのか?
それを明らかにして、そこをよりよくしたものにするという風にするのが手っ取り早いと思う。
真面目にやる気があるのなら。

39 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 02:10:19 ]
string: マルチバイト脂肪
wstring: サロゲートペア脂肪
CString: 脂肪の塊


40 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 00:36:49 ]
basic_string<uint64_t>使えば?



41 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 12:18:03 ]
万能ナイフを作るな!
というのは文字列クラスにも言えると思う。

自作の文字列クラスは、constな文字列用だけでも、いくつもあるよ。

42 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 21:12:23 ]
俺は逆だな
大体std::basic_string<>で済ませる

まあたまにATL::CStringT<>、ATL::CComBSTR、_bstr_tも使うが

43 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 21:49:05 ]
>>42
うしろ2つは文字列クラスというよりは、MSのCOMのためのものだろう。



44 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 16:53:32 ]
wchar_tとか、あとJavaも.NETもそうだけど、
UNICODEな文字列って内部では全部UTF-16じゃないですか。

なんでUTF-8にしないんだろう?

45 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 17:28:24 ]
最初にUnicodeを作ったときには16ビットで十分だとされてしまったから、
Unicodeにすれば16ビット固定長文字列でマルチバイト文字の処理とおさらばと思われていた。
それはまだUTF-8/16/32もサロゲートペアもなかった1990年代。

一応言っておくけど、C++のwchar_tは、別に標準規格でUTF-16と決まっているわけではない。
GCCは、sizeof (wchar_t) == 4が標準でUTF-32。

46 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 19:32:10 ]
>>45
ああ、その時代のことは知っていたんだが、
UTF-16と決まってるわけじゃないことは知らなかった。サンクス
GCCはUTF-32なのか・・・

でも後発の.NETまでcharが16ビットなのは、やっぱり内部でUTF-8をそのまま使うのは
あまり都合がよくないからなんだろうか・・・

47 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:13:22 ]
>>46
仮に、日本語しか考えない場合、
UTF-8は、マルチバイトと同じく、
扱いにくいのですよ。

.NETのUnicode文字列が16ビットなのは、
WindowsのCスタイルのAPIや、
COMのUnicode文字列が16ビットだから。

48 名前:デフォルトの名無しさん mailto:sage [2007/07/06(金) 05:47:29 ]
std::string って std::vector<char> を継承しているのかとか
勝手に思ってたけどそうじゃないんだね。

std::string って \0 (ヌル文字)を途中に挟んだような
文字列でも扱える?

49 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 18:04:46 ]
>>48
STLのリファレンス読めばわかることを、なぜ聞くのだ。

50 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 19:06:00 ]
読むより聞いた方が速いからじゃないの?
他に理由は浮かばないなあ



51 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 19:38:50 ]
>>48
途中にヌル文字があろうと扱えるはず。
また、std::basic_stringがstd::vectorを包含している実装は考えられる。

52 名前:デフォルトの名無しさん mailto:sage [2007/07/08(日) 12:29:41 ]
>>50
速いのかなぁ。

> 48 名前:デフォルトの名無しさん[sage] 投稿日:2007/07/06(金) 05:47:29
> 51 名前:デフォルトの名無しさん[sage] 投稿日:2007/07/07(土) 19:38:50

結果論だが、約38時間もかかる。
自分でリファレンス見れば5分でわかることなのに。

53 名前:デフォルトの名無しさん mailto:sage [2007/07/08(日) 12:40:37 ]
じゃあ、リファレンス見るより聞いた方が楽だからじゃないの?
さすがに他に理由は浮かばないなあ

54 名前:デフォルトの名無しさん mailto:sage [2007/07/08(日) 13:55:08 ]
>>52
聞いた時点では3分でわかる可能性もあったんだよ。

競馬場とかに行くと、そういう自分に都合の言い夢見てる人っていっぱいいるよ。

55 名前:デフォルトの名無しさん mailto:sage [2007/07/08(日) 14:15:19 ]
まあ3分で分かるかもしれない可能性を信じて質問する奴の将来なんてたかが知れてるわな

56 名前:デフォルトの名無しさん mailto:sage [2007/07/08(日) 14:41:16 ]
投機実行かもしれないけどね (w

57 名前:デフォルトの名無しさん mailto:sage [2007/07/30(月) 18:52:29 ]
#include <windows.h>
#include <stdio.h>
// simple string class
class TSTR {
private:
char* Memory;
int buff_len;
size_t CalcBuffSize(const char* s, const char* a=NULL) { size_t size = s? strlen(s)+1: 0; return a ? size+1 + strlen(a)+1: size; }
void Copy(const char* s, const size_t length) {
if (!s) return;
size_t new_size = CalcBuffSize(s);
if (length>0 && length < new_size) new_size = length + 1;
if (Memory!=NULL) free(Memory);
Memory = (char*)malloc(new_size);
if (length==0) strcpy(Memory, s);
else { strncpy(Memory, s, length); Memory[length+1] = 0; }
buff_len = strlen(Memory);
}
void Copy(const char* s){ Copy(s, 0); }
void Add(const char* s) {
if (!s) return;
size_t new_size = CalcBuffSize(Memory, s);
Memory = (char*)realloc(Memory, new_size);
strcat(Memory, s);
buff_len = strlen(Memory);
}
char* MakeBuff(size_t size) { if (Memory!=NULL) free(Memory); Memory = (char*)calloc(size, 1); return Memory; }


58 名前:デフォルトの名無しさん mailto:sage [2007/07/30(月) 18:53:59 ]
public:
__declspec(property(get=buff_len)) int len;
__declspec(property(get=Memory,put=Copy)) char* str;
TSTR() { buff_len = 0; Memory = NULL; }
TSTR(const TSTR &s) { buff_len = 0; Memory = NULL; Copy(s.Memory); }
TSTR(const char* s) { buff_len = 0; Memory = NULL; Copy(s); }
TSTR(const char* s, size_t length) { buff_len = 0; Memory = NULL; Copy(s, length); }
~TSTR() { if (Memory!=NULL) free(Memory); }
char* Sprintf(const char* fom, ...) { va_list ap; va_start(ap, fom); vsprintf(MakeBuff(strlen(fom)+1024), fom, ap); va_end(ap); return Memory; }
char operator [](const int idx) { return (char)(Memory ? Memory[idx]: 0); }
bool operator==(const char* s) const { return (strcmp(Memory, s)==0); }
bool operator >(const char* s) const { return (strcmp(Memory, s)>0); }
bool operator <(const char* s) const { return (strcmp(Memory, s)<0); }
bool operator >=(const char* s) const { return (strcmp(Memory, s)>=0); }
bool operator <=(const char* s) const { return (strcmp(Memory, s)<=0); }
bool operator !=(const char* s) const { return (strcmp(Memory, s)!=0); }


59 名前:デフォルトの名無しさん mailto:sage [2007/07/30(月) 18:54:15 ]
bool operator==(const TSTR &s) const { return (strcmp(Memory, s.Memory)==0); }
bool operator >(const TSTR &s) const { return (strcmp(Memory, s.Memory)>0); }
bool operator <(const TSTR &s) const { return (strcmp(Memory, s.Memory)<0); }
bool operator >=(const TSTR &s) const { return (strcmp(Memory, s.Memory)>=0); }
bool operator <=(const TSTR &s) const { return (strcmp(Memory, s.Memory)<=0); }
bool operator !=(const TSTR &s) const { return (strcmp(Memory, s.Memory)!=0); }
char* operator =(const char* s) { Copy(s); return this->Memory; }
TSTR& operator =(const TSTR& s) { Copy(s.Memory); return *this; }
TSTR& operator +=(const TSTR& s) { Add(s.Memory); return *this; }
TSTR& operator +=(const char* s) { Add(s); return *this; }
friend const TSTR operator + (const char* ls, const TSTR& rs) { TSTR l(ls); l.Add(rs.Memory); return l; }
friend const TSTR operator + (const TSTR& ls, const char* rs) { TSTR l(ls); l.Add(rs); return l; }
TSTR operator +(const TSTR& rs) const { TSTR a(Memory); a.Add(rs.Memory); return a; }
char* operator +(const char* rs) const { TSTR a(Memory); a.Add(rs); return a.Memory; }
};

60 名前:デフォルトの名無しさん mailto:sage [2007/07/30(月) 18:54:51 ]
スケルトンにつかってくだせぇ



61 名前:デフォルトの名無しさん mailto:sage [2007/07/31(火) 10:43:44 ]
んなBorlandローカルなものをどうしろと。

62 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 02:38:29 ]
俺にはVCローカルに見えるが・・・。



63 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 05:09:19 ]
>__declspec(property(get=Memory,put=Copy)) char* str;
これってどっち?

64 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 11:53:21 ]
少なくともVC++には存在する。
msdn2.microsoft.com/en-us/library/yhfk0thd(VS.80).aspx

COM対応の#importしたときにインタフェースのプロパティで使われている。

65 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 12:04:38 ]
>>57-59
必要がなければ、char型限定にしないでクラステンプレートにしろよ。
あと、CopyやAddはもっと例外安全に強くしろよ。ついでにC++ならswap必須。

operator +、=、Sprintfがchar*を返すなんて論外。
operator []はconst版を用意しろ。尤も、参照を返さない方針なら、const版だけでも十分だな。
free(NULL)は問題ないので、半分くらいのifは不要。
malloc類は<stdlib.h>だ。<stdio.h>も<windows.h>も不要。

66 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 16:09:33 ]
__declspec(property....
はBCCもVCも使えると思うんだが

67 名前:デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:52:57 ]
どっちもつかわないからどっちでもいいよ。

68 名前:デフォルトの名無しさん mailto:sage [2007/08/02(木) 18:38:07 ]
でっていう

69 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 06:13:48 ]
汎用的な文字列クラスを作るよりは、
用途別に文字列クラスを作ったほうがいいと思う。

大文字小文字を区別しないで比較する回数が多い文字列のためのクラス
constな文字列のためのクラス
とても短い長さの文字列のためのクラス
マルチバイト文字列とUnicode文字列の相互変換回数が多い文字列のためのクラス
非常に寿命が長い文字列のためのクラス
非常に寿命が短い文字列のためのクラス
同じ内容をたくさんの箇所で使うconstな文字列のためのクラス



70 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 07:35:38 ]
>>69
それのどこにどんなメリットが?



71 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 08:15:31 ]
>>70
わからない人には必要のないものです。


72 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 10:48:58 ]
>>71
必要の有無を聞いているのではないのでメリット(=利点)について宜しく。

73 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 11:12:39 ]
パフォーマンスだろうな。

74 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 11:16:22 ]
シンプルな文字列クラスを作って、それを用途別に派生させればいいような気がするのだが。

75 名前:デフォルトの名無しさん mailto:sage [2007/08/03(金) 11:27:30 ]
>>69は文字列のクラスというよりは、文字列を記憶するクラスという感じだな。


76 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 07:15:11 ]
>>69の文章は異様に圧縮が効きそうだな。

77 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 04:01:58 ]
文字列を、「文字」ごとに処理させるのはどうやってやります?
あと、文字数を数える処理とか。(こっちは簡単だけど

charだと(Shift_JISでもEUC-JPでもUTF-8でも)マルチバイトの処理が面倒だし、
wchar_tだと(UTF-16として)サロゲートが入ってたら2つで1文字なので…
UTF-32とかUCS-4な文字列クラス使ってる人いますか?

78 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 09:32:08 ]
パフォーマンスを求めなければ、
マルチバイト→先人がやってきたようにやる
Unicode→32ビットでやる

自分はサロゲートなんてシラネーヨと高をくくって1文字16ビット固定でやってる。

79 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 12:16:11 ]
>>77
> UTF-32とかUCS-4な文字列クラス使ってる人いますか?

ノシ 自作 UCS4+UTF8+SJIS+EUCJ
32ビットつってもフルカラー1ピクセルも32ビットだしな

80 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 12:53:19 ]
32ビットカラーって24ビット+アルファ値じゃないん?



81 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 13:05:55 ]
1画素32ビットであることには違いあるまい。

82 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 14:56:45 ]
std::basic_string<uint32_t>でいい気もするが
必要なコードを全部書くのは面倒くさいし
リテラルが簡単に書けないし
uint32_tの文字はオーバーロード時にただの整数と見なされてしまう

特にリテラルが簡単に書けないのは実用上大問題

83 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 15:12:20 ]
いらない子じゃん

84 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 00:15:12 ]
たまにはsizeof (wchar_t) == 4でUCS-4/UTF-32な奴らも忘れないで。

>>82
std::basic_string<uint32_t> u32(const wchar_t*);のような関数を定義しておけば、
これくらいにはできる。

typedef std::basic_string<uint32_t> u32string;
u32string s = u32(L"hogehoge");

Win32 APIの_TやTEXTマクロみたいなもんだと思えばたいしたことはない、ってダメ?

それはともかく、C++0xにはchar16_tやchar32_tなる型が入るらしいよ。
www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html
pc11.2ch.net/test/read.cgi/tech/1149440647/372-

85 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:27:35 ]
>>84
_Tマクロはプリプロセス時に解決されリテラルとして埋め込まれるが
その手法だといちいち実行時に変換される
どっちかっつーとC2Wとかのマクロに近いかな
本物のリテラルと違って一時オブジェクトの寿命を気にする必要があるし
ワイド文字リテラルがまともに使えるコンパイラを相手にするとしても、
wchar_tのサイズによって実装を場合分けしないといかんのも面倒だ

C++0xのユニコード文字型が導入されれば大分マシになりそうだが
いつになることやら、だな

86 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 19:49:52 ]
D言語だとテンプレート引数に文字列リテラルが使えるらしいな。
そもそもUTF-32なdchar型もあるけどな。

87 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 20:27:11 ]
{ xxx, yyy, zzz } ;のように書き換えるプリプロセッサを用意するだけじゃダメなん?

88 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:18:07 ]
>>87
それだと

const uint32_t *utf32_str = ....
とは書けないし #define にも使えないな

static const uint32_t utf32_str[] = ....
ならそれでいいけど

89 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:30:58 ]
C99の複合リテラルなら静的記憶期間を持つから、
前者にも対応できるけど標準C++にはきっと入らない。

90 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:34:31 ]
もしかしてC99では
printf({'h', 'e', 'l', 'l', 'o', ',' 'w', 'o', 'r','l','d','\n', 0});
とか書けるのか

キモいな



91 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:47:47 ]
seclan.dll.jp/c99d/c99d07.htm#dt19991101
頭にキャストみたいな形で型を指定する必要があるけど、
本当にそんなことも可能。
gcc -std=c99

#include <stdio.h>

int main()
{
printf((char[]){'h', 'e', 'l', 'l', 'o', ',', 'w', 'o', 'r', 'l', 'd', '\n', 0});
}


92 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:50:01 ]
static const uint32_t _utf32_str[] = { うりゃぁ } ;
const uint32_t *utf32_str = _utf32_str ;

これでいいじゃん。


93 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 22:54:40 ]
{ うりゃぁ }
これはダメだろw

それはともかく、内部的にコンパイラはそれに近いことをやって、
ついでにそれをまとめたりしてくれてるわけだ
printf()等の函数の引数に直接リテラルを使えないのはかなり嫌だぞ
いちいちそんな風に書きたくないよ

94 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 23:10:44 ]
"うりゃぁ"のつもりではなくて・・・
{ 14235, 13456, 15196, 15611, 0 }
とかのつもり。

プリプロセッサで処理すれば何ら問題なし。
かつての日本語対応のやりかたと一緒。

95 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 23:14:58 ]
> かつての日本語対応のやりかたと一緒
あー確かにそうだな
Javaのnative2asciiみたいなもんとも言えるな
ただ、昔はリテラルを8進とか16進とかのリテラルに置き換えるだけで
すんでたでしょ

96 名前:デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:31:30 ]
>>93
87の言うようなプリプロセッサの出力が92みたいになればいいと思う。

97 名前:デフォルトの名無しさん mailto:sage [2007/08/23(木) 10:56:49 ]
簡単に言うが、マクロとかテンプレートとか色々考慮してるか?
生半可な考えは絶対破綻する

98 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 07:59:08 ]
char *hage = L"hage";
printf("%s\n", hage);
何も表示されませn

99 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 15:18:14 ]
>>98
スレ違い。

100 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 16:31:16 ]
>>98
それをコンパイルするときに警告が出るようにしろ。
どうやってもそれで警告を出さないコンパイラなんて窓から投げ捨てろ。



101 名前:デフォルトの名無しさん mailto:sage [2007/10/07(日) 14:06:54 ]
用途別に、
アルファベットだけ格納できる文字列クラス、
ひらがなだけ格納できる文字列クラス、
ウかんむりの漢字だけ格納できる文字列クラス、
とか作ったら、激しく労力の無駄でいい感じじゃね?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<51KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef