06/12/26 20:24:15
CString , string , wstringに負けないものをみんなで作ろうね。
前スレ: ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
06/12/26 20:25:17
CFString
3:デフォルトの名無しさん
06/12/26 20:25:17
>>1
おお、いいスレが立ったな。乙！
4:デフォルトの名無しさん
06/12/26 20:30:13
こんなスレが欲しかった
>>1乙
5:デフォルトの名無しさん
06/12/26 20:30:50
Stringでどうよ？
6:デフォルトの名無しさん
06/12/26 20:33:40
でもそれ.NETがなきゃ動かんじゃん
7:デフォルトの名無しさん
06/12/26 20:34:47
>>3
>>4
自演乙（藁
そして終了（禿藁
8:デフォルトの名無しさん
06/12/26 20:36:20
>>1はどうでもいいから前スレで挙がってたC2charうｐきぼん
9:デフォルトの名無しさん
06/12/26 20:41:06
>>8 =>>1な罠（藁
10:デフォルトの名無しさん
06/12/26 20:45:25
∧ ∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
～′ ￣￣( ﾟДﾟ)＜ >>1は早急に逝ってよしだｺﾞﾙｧ!!
UU￣￣ U U ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
11:1
06/12/26 20:58:01
伸びないなぁ。
>>8も俺からもきぼん！
12:1
06/12/26 20:59:49
仕方ない
俺が作った（まだ発展途上だけど）かなり便利な文字列クラスをあげるか
それをみんなで改造しよう！！１１
13:1
06/12/26 21:07:07
上げました。
URLﾘﾝｸ(tune.ache-bang.com)
14:1
06/12/26 21:09:52
>>13←なんとこれ作るのに丸一日かかりました!疲れた...
15:デフォルトの名無しさん
06/12/26 21:11:32
String使えよ。
16:1
06/12/26 21:13:40
アドレス間違えました
URLﾘﾝｸ(tune.ache-bang.com)
17:デフォルトの名無しさん
06/12/26 21:14:01
String使えよ。
18:デフォルトの名無しさん
06/12/26 21:15:16
>>17
>>6
19:デフォルトの名無しさん
06/12/26 21:18:16
>>１8
.net使えばいいだろ。
20:デフォルトの名無しさん
06/12/26 21:20:47
基本的にstd::stringとstd::stringstreamでできるなー。
それを交えて作り直してみたらコードかなり圧縮できるとおもう。
あと、>>1のクラスのformatメソッドがやばいと思う。
21:デフォルトの名無しさん
06/12/26 21:22:35
NSStringをC++でラップしたら強いのが出来そうじゃね？
22:デフォルトの名無しさん
06/12/26 21:24:01
>>16
丸一日掛かってこれかよ（ﾌﾟ
23:デフォルトの名無しさん
06/12/26 21:27:10
前スレはdat逝きか
makimo.toにも無かった
24:デフォルトの名無しさん
06/12/26 21:32:47
vsprintfはwvsprintf使うべき
25:デフォルトの名無しさん
06/12/26 21:36:15
STLのstringは、マルチバイト文字をまともに扱えるの?
26:デフォルトの名無しさん
06/12/26 21:37:59
>>25
あれは基本的にコンテナなんだと思うけど。
27:デフォルトの名無しさん
06/12/26 21:40:37
みんなwstring使えば解決
なんでみんなUNICODE使おうとしないのか
28:デフォルトの名無しさん
06/12/26 21:42:54
wvsprintfってウインドウズ？
29:デフォルトの名無しさん
06/12/26 21:59:36
さようなら>>1の人。
30:デフォルトの名無しさん
06/12/26 22:02:44
D言語マンセー
31:デフォルトの名無しさん
06/12/26 22:13:42
D言語もまともなstringがない。
main（char[ ][ ]）だもんな。。。
32:デフォルトの名無しさん
06/12/26 22:53:25
>>31
つ std.string/std.conv
"test".toupper()とか"12".toInt()とか可能。
33:デフォルトの名無しさん
06/12/27 00:59:26
つ URLﾘﾝｸ(tricklib.com)
34:デフォルトの名無しさん
06/12/27 01:21:32
最強の文字列クラスを作るスレ
とかの方がよかったんじゃないか
35:デフォルトの名無しさん
06/12/27 17:55:20
>>21
CFString
36:1
07/01/31 00:29:04
まだあったんだコノスレ(
37:デフォルトの名無しさん
07/01/31 04:24:08
AnsiStringは放置ですか。そうですか。
38:デフォルトの名無しさん
07/03/05 01:01:54
>>1
まずCString, string, wstringには現状どのような問題点があるのか？
それを明らかにして、そこをよりよくしたものにするという風にするのが手っ取り早いと思う。
真面目にやる気があるのなら。
39:デフォルトの名無しさん
07/03/05 02:10:19
string: マルチバイト脂肪
wstring: サロゲートペア脂肪
CString: 脂肪の塊
40:デフォルトの名無しさん
07/05/14 00:36:49
basic_string<uint64_t>使えば？
41:デフォルトの名無しさん
07/06/25 12:18:03
万能ナイフを作るな!
というのは文字列クラスにも言えると思う。
自作の文字列クラスは、constな文字列用だけでも、いくつもあるよ。
42:デフォルトの名無しさん
07/06/27 21:12:23
俺は逆だな
大体std::basic_string<>で済ませる
まあたまにATL::CStringT<>、ATL::CComBSTR、_bstr_tも使うが
43:デフォルトの名無しさん
07/06/27 21:49:05
>>42
うしろ2つは文字列クラスというよりは、MSのCOMのためのものだろう。
44:デフォルトの名無しさん
07/06/28 16:53:32
wchar_tとか、あとJavaも.NETもそうだけど、
UNICODEな文字列って内部では全部UTF-16じゃないですか。
なんでUTF-8にしないんだろう？
45:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/28 19:32:10
>>45
ああ、その時代のことは知っていたんだが、
UTF-16と決まってるわけじゃないことは知らなかった。サンクス
GCCはUTF-32なのか・・・
でも後発の.NETまでcharが１６ビットなのは、やっぱり内部でUTF-8をそのまま使うのは
あまり都合がよくないからなんだろうか・・・
47:デフォルトの名無しさん
07/06/28 21:13:22
>>46
仮に、日本語しか考えない場合、
UTF-8は、マルチバイトと同じく、
扱いにくいのですよ。
.NETのUnicode文字列が16ビットなのは、
WindowsのCスタイルのAPIや、
COMのUnicode文字列が16ビットだから。
48:デフォルトの名無しさん
07/07/06 05:47:29
std::string って std::vector<char> を継承しているのかとか
勝手に思ってたけどそうじゃないんだね。
std::string って \0 （ヌル文字）を途中に挟んだような
文字列でも扱える？
49:デフォルトの名無しさん
07/07/07 18:04:46
>>48
STLのリファレンス読めばわかることを、なぜ聞くのだ。
50:デフォルトの名無しさん
07/07/07 19:06:00
読むより聞いた方が速いからじゃないの？
他に理由は浮かばないなあ
51:デフォルトの名無しさん
07/07/07 19:38:50
>>48
途中にヌル文字があろうと扱えるはず。
また、std::basic_stringがstd::vectorを包含している実装は考えられる。
52:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/07/08 12:40:37
じゃあ、リファレンス見るより聞いた方が楽だからじゃないの？
さすがに他に理由は浮かばないなあ
54:デフォルトの名無しさん
07/07/08 13:55:08
>>52
聞いた時点では３分でわかる可能性もあったんだよ。
競馬場とかに行くと、そういう自分に都合の言い夢見てる人っていっぱいいるよ。
55:デフォルトの名無しさん
07/07/08 14:15:19
まあ３分で分かるかもしれない可能性を信じて質問する奴の将来なんてたかが知れてるわな
56:デフォルトの名無しさん
07/07/08 14:41:16
投機実行かもしれないけどね (w
57:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/07/30 18:54:51
スケルトンにつかってくだせぇ
61:デフォルトの名無しさん
07/07/31 10:43:44
んなBorlandローカルなものをどうしろと。
62:デフォルトの名無しさん
07/08/01 02:38:29
俺にはVCローカルに見えるが・・・。
63:デフォルトの名無しさん
07/08/01 05:09:19
＞__declspec(property(get=Memory,put=Copy)) char* str;
これってどっち?
64:デフォルトの名無しさん
07/08/01 11:53:21
少なくともVC++には存在する。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
COM対応の#importしたときにインタフェースのプロパティで使われている。
65:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/01 16:09:33
__declspec(property....
はBCCもVCも使えると思うんだが
67:デフォルトの名無しさん
07/08/01 22:52:57
どっちもつかわないからどっちでもいいよ。
68:デフォルトの名無しさん
07/08/02 18:38:07
でっていう
69:デフォルトの名無しさん
07/08/03 06:13:48
汎用的な文字列クラスを作るよりは、
用途別に文字列クラスを作ったほうがいいと思う。
大文字小文字を区別しないで比較する回数が多い文字列のためのクラス
constな文字列のためのクラス
とても短い長さの文字列のためのクラス
マルチバイト文字列とUnicode文字列の相互変換回数が多い文字列のためのクラス
非常に寿命が長い文字列のためのクラス
非常に寿命が短い文字列のためのクラス
同じ内容をたくさんの箇所で使うconstな文字列のためのクラス
70:デフォルトの名無しさん
07/08/03 07:35:38
>>69
それのどこにどんなメリットが?
71:デフォルトの名無しさん
07/08/03 08:15:31
>>70
わからない人には必要のないものです。
72:デフォルトの名無しさん
07/08/03 10:48:58
>>71
必要の有無を聞いているのではないのでメリット(=利点)について宜しく。
73:デフォルトの名無しさん
07/08/03 11:12:39
パフォーマンスだろうな。
74:デフォルトの名無しさん
07/08/03 11:16:22
シンプルな文字列クラスを作って、それを用途別に派生させればいいような気がするのだが。
75:デフォルトの名無しさん
07/08/03 11:27:30
>>69は文字列のクラスというよりは、文字列を記憶するクラスという感じだな。
76:デフォルトの名無しさん
07/08/07 07:15:11
>>69の文章は異様に圧縮が効きそうだな。
77:デフォルトの名無しさん
07/08/16 04:01:58
文字列を、「文字」ごとに処理させるのはどうやってやります？
あと、文字数を数える処理とか。（こっちは簡単だけど
charだと（Shift_JISでもEUC-JPでもUTF-8でも）マルチバイトの処理が面倒だし、
wchar_tだと（UTF-16として）サロゲートが入ってたら2つで1文字なので…
UTF-32とかUCS-4な文字列クラス使ってる人いますか？
78:デフォルトの名無しさん
07/08/16 09:32:08
パフォーマンスを求めなければ、
マルチバイト→先人がやってきたようにやる
Unicode→32ビットでやる
自分はサロゲートなんてシラネーヨと高をくくって1文字16ビット固定でやってる。
79:デフォルトの名無しさん
07/08/16 12:16:11
>>77
> UTF-32とかUCS-4な文字列クラス使ってる人いますか？
ﾉｼ 自作 UCS4+UTF8+SJIS+EUCJ
32ビットつってもフルカラー1ピクセルも32ビットだしな
80:デフォルトの名無しさん
07/08/16 12:53:19
32ビットカラーって24ビット＋アルファ値じゃないん？
81:デフォルトの名無しさん
07/08/16 13:05:55
1画素32ビットであることには違いあるまい｡
82:デフォルトの名無しさん
07/08/16 14:56:45
std::basic_string<uint32_t>でいい気もするが
必要なコードを全部書くのは面倒くさいし
リテラルが簡単に書けないし
uint32_tの文字はオーバーロード時にただの整数と見なされてしまう
特にリテラルが簡単に書けないのは実用上大問題
83:デフォルトの名無しさん
07/08/16 15:12:20
いらない子じゃん
84:デフォルトの名無しさん
07/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なる型が入るらしいよ。
URLﾘﾝｸ(www.open-std.org)
ｽﾚﾘﾝｸ(tech板:372-番)
85:デフォルトの名無しさん
07/08/22 09:27:35
>>84
_Tマクロはプリプロセス時に解決されリテラルとして埋め込まれるが
その手法だといちいち実行時に変換される
どっちかっつーとC2Wとかのマクロに近いかな
本物のリテラルと違って一時オブジェクトの寿命を気にする必要があるし
ワイド文字リテラルがまともに使えるコンパイラを相手にするとしても、
wchar_tのサイズによって実装を場合分けしないといかんのも面倒だ
C++0xのユニコード文字型が導入されれば大分マシになりそうだが
いつになることやら、だな
86:デフォルトの名無しさん
07/08/22 19:49:52
D言語だとテンプレート引数に文字列リテラルが使えるらしいな。
そもそもUTF-32なdchar型もあるけどな。
87:デフォルトの名無しさん
07/08/22 20:27:11
{ xxx, yyy, zzz } ;のように書き換えるプリプロセッサを用意するだけじゃダメなん?
88:デフォルトの名無しさん
07/08/22 22:18:07
>>87
それだと
const uint32_t *utf32_str = ....
とは書けないし #define にも使えないな
static const uint32_t utf32_str[] = ....
ならそれでいいけど
89:デフォルトの名無しさん
07/08/22 22:30:58
C99の複合リテラルなら静的記憶期間を持つから、
前者にも対応できるけど標準C++にはきっと入らない。
90:デフォルトの名無しさん
07/08/22 22:34:31
もしかしてC99では
printf({'h', 'e', 'l', 'l', 'o', ',' 'w', 'o', 'r','l','d','\n', 0});
とか書けるのか
キモいな
91:デフォルトの名無しさん
07/08/22 22:47:47
URLﾘﾝｸ(seclan.dll.jp)
頭にキャストみたいな形で型を指定する必要があるけど、
本当にそんなことも可能。
gcc -std=c99
#include <stdio.h>
int main()
{
printf((char[]){'h', 'e', 'l', 'l', 'o', ',', 'w', 'o', 'r', 'l', 'd', '\n', 0});
}
92:デフォルトの名無しさん
07/08/22 22:50:01
static const uint32_t _utf32_str[] = { うりゃぁ } ;
const uint32_t *utf32_str = _utf32_str ;
これでいいじゃん。
93:デフォルトの名無しさん
07/08/22 22:54:40
{ うりゃぁ }
これはダメだろｗ
それはともかく、内部的にコンパイラはそれに近いことをやって、
ついでにそれをまとめたりしてくれてるわけだ
printf()等の函数の引数に直接リテラルを使えないのはかなり嫌だぞ
いちいちそんな風に書きたくないよ
94:デフォルトの名無しさん
07/08/22 23:10:44
"うりゃぁ"のつもりではなくて・・・
{ 14235, 13456, 15196, 15611, 0 }
とかのつもり。
プリプロセッサで処理すれば何ら問題なし。
かつての日本語対応のやりかたと一緒。
95:デフォルトの名無しさん
07/08/22 23:14:58
> かつての日本語対応のやりかたと一緒
あー確かにそうだな
Javaのnative2asciiみたいなもんとも言えるな
ただ、昔はリテラルを8進とか16進とかのリテラルに置き換えるだけで
すんでたでしょ
96:デフォルトの名無しさん
07/08/23 08:31:30
>>93
87の言うようなプリプロセッサの出力が92みたいになればいいと思う。
97:デフォルトの名無しさん
07/08/23 10:56:49
簡単に言うが、マクロとかテンプレートとか色々考慮してるか？
生半可な考えは絶対破綻する
98:デフォルトの名無しさん
07/08/26 07:59:08
char *hage = L"hage";
printf("%s\n", hage);
何も表示されませｎ
99:デフォルトの名無しさん
07/08/26 15:18:14
>>98
スレ違い。
100:デフォルトの名無しさん
07/08/26 16:31:16
>>98
それをコンパイルするときに警告が出るようにしろ。
どうやってもそれで警告を出さないコンパイラなんて窓から投げ捨てろ。
101:デフォルトの名無しさん
07/10/07 14:06:54
用途別に、
アルファベットだけ格納できる文字列クラス、
ひらがなだけ格納できる文字列クラス、
ウかんむりの漢字だけ格納できる文字列クラス、
とか作ったら、激しく労力の無駄でいい感じじゃね？
102:デフォルトの名無しさん
07/10/12 08:22:41
テンプレートで自動生成したいなそれ
103:デフォルトの名無しさん
07/10/12 09:33:24
>>102
まずは対応する文字クラスを作らなきゃなぁ。
104:デフォルトの名無しさん
07/10/13 12:13:26
やはり問題の根元は、
文字型がCにないことだな。
105:デフォルトの名無しさん
07/10/13 13:29:43
逆に無かった事で今日まで生き残れた
106:デフォルトの名無しさん
07/10/13 14:25:02
素朴な疑問だが、文字型が存在する言語って何がある?
107:デフォルトの名無しさん
07/10/13 14:54:20
C++ wchar_t
今度の0xではchar16_t, char32_tが追加の予定。
108:デフォルトの名無しさん
07/10/13 14:57:20
>>106
Javaとか
109:デフォルトの名無しさん
07/10/15 18:29:55
クラスで扱う文字コードは、
OSのAPIが要求する文字コードにあわせるのが一番なんだろうけどな。
cinで入力される度に、文字コード変換して格納、
coutで出力するたびに再度文字コードを変換して出力ってのは無駄が多いし。
110:デフォルトの名無しさん
07/10/15 18:51:28
>>109
結局、char なら ASCII もしくはマルチバイト、
wchar なら UTF-16 って自分の中では決めてる。
で、マルチバイトに関しては環境に合わせる方向で。
でも実際には wchar だからって UTF-16 と決められないケースもおおいよね。
C++0x ではまた新たな型が追加されるみたいだねぇ。
111:110
07/10/15 18:54:47
C++0x になったら UTF-16と決めている場合には char16_t をつかうべき？
そりゃそうと、根本的な疑問なんだが、 UTF-8 も UTF-16 も
所詮は可変長文字だよね。内部コードとしてどちらを使うべきかは
どうやって決めればいいんだろう。好きなの使えば？ってのは無しの方向で。
自分の中でどういうガイドラインを作っておけばいいかなぁ、と迷う。
112:110
07/10/15 19:06:18
URLﾘﾝｸ(www.rubyist.net)
まつもと氏はバイトオーダーの問題があるから
事実上 UTF-8 でいいじゃんって主張みたいだねぇ。
まぁわからないでもない。ただ Windows で
プログラムを書くことが多い身としては UTF-16
との変換をしばしばする必要があるのは屋だなぁ。
UTF-8とUTF-16のマップは表現系だけの変換で
マップは必要ないからそんなに苦にはならないか。
113:110
07/10/15 19:08:04
いっそのこと Mule のコードを流用、というのはやりすぎか。
URLﾘﾝｸ(www.dennougedougakkai-ndd.org)
114:デフォルトの名無しさん
07/10/15 19:08:07
char64_tがあれば…
115:デフォルトの名無しさん
07/10/16 01:07:28
>> std::basic_string<uint32_t>
本気で実装するなら、facetから作ることになるのか…char_trait<uint32_t>…
それでコンストラクタではSHIFT-JISから変換格納？
すごく遅そう…ただでさえfacetキャッシュしないと遅いのに…
116:デフォルトの名無しさん
07/10/16 02:55:26
俺思うんだ...
文字コードの体系が増えれば増えるほどややこしくなってるって...
117:110
07/10/16 16:33:31
文字を捨てよう。
動物に帰ろう。
118:デフォルトの名無しさん
07/10/16 19:31:15
それはやりすぎ。
ASCIIだけ残せばいい。
119:デフォルトの名無しさん
07/10/19 10:27:05
>>116
漏れの作った新しい文字コードをみんなが使えばいいんだ
問題はすべて解決だ
120:デフォルトの名無しさん
07/10/20 00:17:23
0x00 = ひ
0x01 = ろ
0x02 = ゆ
0x03 = き
0x04 = 改行
ここまで策定した。残りはよろしく
121:デフォルトの名無しさん
07/10/20 19:13:20
0x05ぬ
0x06る
0x07ぽ
122:デフォルトの名無しさん
07/10/22 14:11:08
0x08=ガ
0x09=ッ
123:デフォルトの名無しさん
07/10/22 16:00:40
つか、1バイト長で日本語表現するつもりですかw
124:デフォルトの名無しさん
07/10/22 23:11:07
0x0a い
0x0b つ
0x0c て
0x0d よ
0x0e し
0x0f 。
0x10 お
0x11 ま
0x12 え
0x13 も
0x14 な
0x15 ー
案外被らずにいけるもんだな。
125:デフォルトの名無しさん
07/10/22 23:31:40
0x16 = o
0x17 = r
0x18 = z
0x19 = O
0x1a = T
0x1b = L
126:デフォルトの名無しさん
07/10/23 09:29:48
0xfe 終
0xff 了
127:デフォルトの名無しさん
07/10/23 10:02:20
0x100宇
0x101宙
0x102ヤ
0x103バ
0x104イ
128:デフォルトの名無しさん
07/10/23 13:13:16
>>127を持ちまして可変長コードになりました。
129:デフォルトの名無しさん
07/10/23 14:52:02
>>128
しかも、それが1byte目なのか2byte目なのか判別不能な可変長コード...
130:デフォルトの名無しさん
07/10/23 21:28:50
以下、
リトルエンディアンとビッグエンディアンによる骨肉の争い。
131:デフォルトの名無しさん
07/10/24 00:20:28
文字列ぐらい言語仕様で持ちやがれ
132:デフォルトの名無しさん
07/10/24 08:19:51
C++の歴史は文字列の抽象化の歴史だ。
言語仕様で文字列を定義したが最後、
C++の進化は止まるだろう…
133:デフォルトの名無しさん
07/10/24 12:23:40
char や int のビット幅すらきめうちにはしなかったわけだからなぁ。
あ、そういうわけでビットローテートが演算子として用意されていないのかな？
ローテート結果に関して何か決めようとするとビット幅が固定されて
いないと何も言えないからねぇ。
134:デフォルトの名無しさん
07/10/24 12:40:30
ローテートはビット数に依存するからCの仕様では無理だわな
VCには独自拡張であるけどね。2005からは8,16ビットにも対応してる
135:デフォルトの名無しさん
07/10/24 16:54:06
>>1-135
ここの住人のやる気のなさがわかったおｗｗｗｗ
136:デフォルトの名無しさん
07/10/24 18:27:57
もうC++で文字列使うのやめようぜ
137:デフォルトの名無しさん
07/10/24 19:40:07
basic_stringはピザだからなぁ…
非メンバ非friendな便利関数としてデザインし直したものを作ってやろうかと妄想してるよ
138:デフォルトの名無しさん
07/10/24 20:03:59
>>134
え？Visual C++ にはあるの？
どんな感じの構文？
139:デフォルトの名無しさん
07/10/24 20:08:16
_rotl だっけ？
140:デフォルトの名無しさん
07/10/24 22:17:35
それ、演算子じゃなくて関数じゃないか
141:デフォルトの名無しさん
07/10/24 22:28:16
わかったよ、じゃあ文字コードの次は演算子の策定と行こうか
><< ＝左ローテート
>>< ＝右ローテート
ここまで策定した。残りはよろしく
142:デフォルトの名無しさん
07/10/24 22:47:39
文字列をローテートするとどうなる。
143:デフォルトの名無しさん
07/10/25 14:23:32
>>142
たぶん読みにくくてたまらない。
144:デフォルトの名無しさん
07/10/25 17:19:41
>>142
ジェットストリームアタック
文字列をローテートするとどうなる。
。文字列をローテートするとどうなる
る。文字列をローテートするとどうな
なる。文字列をローテートするとどう
うなる。文字列をローテートするとど
どうなる。文字列をローテートすると
とどうなる。文字列をローテートする
るとどうなる。文字列をローテートす
するとどうなる。文字列をローテート
トするとどうなる。文字列をローテー
ートするとどうなる。文字列をローテ
テートするとどうなる。文字列をロー
ーテートするとどうなる。文字列をロ
ローテートするとどうなる。文字列を
をローテートするとどうなる。文字列
列をローテートするとどうなる。文字
字列をローテートするとどうなる。文
文字列をローテートするとどうなる。
145:デフォルトの名無しさん
07/10/25 20:15:42
>>144の中にウォーリーがいます。君はみつけられるかな？
146:デフォルトの名無しさん
07/10/26 23:55:15
みつからねぇ…
147:デフォルトの名無しさん
07/10/30 13:01:58
単項演算子「!」を提案するよ
矢印の右が演算後の値ね
詳細な仕様と実装はあとの人に任せる
!"良スレ" → "糞スレ"
!"有用な議論" → "不毛なダベり"
148:デフォルトの名無しさん
07/10/30 20:44:32
は？
149:デフォルトの名無しさん
07/10/31 17:19:10
それ実現させたらどんだけデータベース抱えたクラスになるとおもっとるんだｗｗ
150:デフォルトの名無しさん
07/11/04 14:46:45
!"このスレ" → ？
151:デフォルトの名無しさん
07/11/14 21:06:23
C++で独自の中置演算子を定義出来たら、
どんなに素晴らしい世界が待っているんだろう。
152:デフォルトの名無しさん
07/11/14 21:08:51
ある日ＮＯぷりすたぁ
URLﾘﾝｸ(www.freewebs.com)
153:デフォルトの名無しさん
07/11/14 21:12:28
そこでホワイトスペースのオーバーライドですよ
154:デフォルトの名無しさん
07/11/14 21:49:01
純粋抽象クラス（ようはインタフェース）を定義して
ファクトリから文字セットを指定してインスタンスを得る仕様がいいのかな。
バイトオーダー非依存かつマルチバイトであるUTF-8を最初にサポートすれば
他の文字セットのサポートor最適化もしやすいだろうし。
155:デフォルトの名無しさん
07/11/14 22:02:28
改行やTABもやれば Whitespace っぽくできるかも
「C++で関数型プログラミング」の次は「C++でWhitespace」だな
間違いない。
156:デフォルトの名無しさん
07/11/14 23:57:32
完全素人だが
内部をUNICODEで実装しといて
どんな文字列も受けれるな仕様にしたらいかんの？
157:デフォルトの名無しさん
07/11/15 08:14:02
ウニ文字の内部表現はどうするのさ？
158:デフォルトの名無しさん
07/11/15 14:05:34
参考までに聞きたいんだけど、JISコード(SJISじゃなくて「)を直接操作する
文字列クラスって作ったことありますか？
格納だけじゃなく検索とかの機能付きで。
一般的にはSJISに変換してるんだろうか。
あ～、ついでに終端が0じゃない文字列コードって存在するんですか～？
159:デフォルトの名無しさん
07/11/15 15:04:51
文字のコードポイントと、エンコーディングと、
文字列の内部表現とをごっちゃにして
釣ろうとしてるようにしか見えない。
160:デフォルトの名無しさん
07/11/17 01:25:05
マジレスすると、必要なのは新しい文字列クラスではなく、
エンコーディングを意識した文字列イテレータ。
さらに、部分文字列(あるいはマルチバイトの一文字分)をポイントする
beginとendのペアみたいなデータ型が標準化されれば、
色んなユーティリティを作りやすくなると思う。
161:デフォルトの名無しさん
07/11/17 03:21:34
アルゴリズム(ポリシー?)を与えておけば
コピーされる際にそれを使って自動的にエンコードしてくれるって寸法か
いいなそれいいな
って誰かがもう作ってそうなふいんきだけど
162:デフォルトの名無しさん
07/11/17 15:30:10
>>160
substringクラスでも作るか？
163:デフォルトの名無しさん
07/11/22 22:55:43
>>158
それはコードじゃなくてC言語系の規則。
BSTRていうのは配列の頭に文字数を入れたはずだし、
D言語ではその規則も使えるが、配列が配列長をしってるから、
そんなナンセンスなことは必要ない。
ま、C++でもVC系（これしか知らない。）のstd::stringは内部的には長さで処理しているが、便宜上0終端を強制されてる感じっぽい。
164:デフォルトの名無しさん
07/11/22 22:59:32
>>160
その希望は多分Rangeって概念だと思うよ。Boostに入ってる。
165:デフォルトの名無しさん
07/11/22 23:02:34
>>161
それいいね。でも変換関数なりを書くのが一番だるいって言う。
一回書けばつぶしが利くのだけど、その一回がなぁ。
166:デフォルトの名無しさん
07/11/22 23:26:35
>>164
チゲーよバカ
167:デフォルトの名無しさん
07/11/24 13:04:15
あれ？
あぁ、後者って書き忘れたなぁ。
エンコーディングはよぉーしらん。
168:デフォルトの名無しさん
07/12/07 16:13:34
目的のものを作っちゃった俺がきましたよ
169:デフォルトの名無しさん
07/12/07 20:25:38
>>168
公開！公開！
170:デフォルトの名無しさん
07/12/07 20:54:18
オプソ化きぼんぬ
171:デフォルトの名無しさん
07/12/07 22:21:14
オプソしたってめこめこに叩かれるだけじゃないのか？
前の方にあったiteratorが文字コードみなきゃいけないっていうのは
その通りだと思う。
だからiteratorは抽象文字を返す感じにしてるね。ope++で各文字コードに
応じたiterateをして*iteで抽象文字クラス参照を返す感じ。
ここ絶対速くないといけないから全部inline
統一iteratorさえできれば、アルゴリズムは結構全文字コードで共有化
できるから負担はだいぶ減ったかな。
wstring,stringみたいに文字コードによってクラスがちがうのは絶対やだから
UTF-16,8,sisとかも統一的に扱える感じにしてる。
なので文字端末は文字コードによって0が1つになったり2つになったり。
jisはシフトイン見たり、sjis,euc,utf-8は各バイト見たり。
結合時のbom削除とかコードの変換とか、検索時にネイティブAPI使ったり、
ほんと死ぬほど大変だった気がする。
でも誰かもうそういうのオプソでやってそうじゃね？てか需要なし？
CString使えボケ？std::wstringでいいじゃん？
力作のレスだぜ。さあ叩いてくれ
172:デフォルトの名無しさん
07/12/07 22:36:15
文字コードを知っている必要があるのはコンテナではなくイテレータだってアイデアはいいと思うよ。
173:デフォルトの名無しさん
07/12/19 19:34:33
双方向イテレータとランダムアクセスイテレータを作るのは
難しそうだけど。
174:デフォルトの名無しさん
07/12/19 23:07:33
文字単位でランダムアクセスできる機能は
大部分の用途に対してオーバースペックだから捨てるのが前提だ。
必要に応じて、途中のイテレータを保存しとくとか、
32bit文字オブジェクトのベクタに変換したりしてどうにかする。
175:デフォルトの名無しさん
07/12/19 23:21:31
内部表現がUTF-16なら双方向は楽でしょ。
マルチバイトとはいえ下位サロゲートが出現したら、その前を頭にすればいい。
ランダムアクセスは内部で結局はイテレートするしかないよね。
176:デフォルトの名無しさん
07/12/19 23:48:11
内部表現がUTF-16(UCS2)かUTF-8で、UCS4を取り出すようなイテレータだったら、
boostのicuで使われてるはず。
177:デフォルトの名無しさん
07/12/20 04:20:58
>>174
可変長ならランダムアクセスはそもそも実装不可能だろう
178:デフォルトの名無しさん
07/12/20 13:10:06
ランダムアクセスあきらめたら、
「与えられたテキストファイルで使われているすべての文字の一覧を求めろ」
と言われたときどうするの？
STLでsort() → unique()、という手が真っ先に思い浮かぶんだけど、
sort()はランダムアクセスイテレータがいるんだよね。
179:デフォルトの名無しさん
07/12/20 14:20:33
コピーするほかない
コピーするのかビューなのかを
場合により選べるのがイテレータの良いところ
180:デフォルトの名無しさん
07/12/20 17:34:43
どうせWin32APIの文字受け渡しが癌
181:デフォルトの名無しさん
07/12/20 17:49:42
癌は受け渡しより受け取りの方だと思うが。
GetBuffer→API呼ぶ(→ReleaseBuffer) の流れからは逃れられない
182:デフォルトの名無しさん
07/12/20 17:59:40
>>33を使えばAPIからの受け取りもそれほど面倒ではないけど、文字コードが違う場合には
自動で変換できるようにしないとな。
183:デフォルトの名無しさん
07/12/20 18:25:18
>>33がリッチなのはわかる。
でも、ただGetBuffer/ReleaseBufferが面倒なだけだったら、単純なユーティリティクラスでいいんじゃない？
class GR {
CString str;
size_t siz;
LPTSTR p;
public:
~GR() {
str.ReleaseBuffer();
}
GR(CString &str_, size_t size_) : str(str_), p(NULL), siz(0) {
p = str.GetBuffer(size);
siz = size_;
}
operator LPTSTR() { return p; }
size_t size() const { return siz; }
};
多分こんな風に使えるはず。
CString s;
{ GR buf(s, 1000); GetCurrentDirectory(buf, buf.size()); }
思いつきで書いただけで、コンパイルもテストもしてないけど。
184:デフォルトの名無しさん
07/12/20 19:01:05
何文字返ってくるか分からないがね～
185:デフォルトの名無しさん
07/12/20 19:27:31
受け取ったらそのまま、普通に持ち運びしたいよな、何も考えずに。
186:デフォルトの名無しさん
07/12/20 21:56:39
>>184
MSのプログラマですらオーバーフロー度々起こすってことはやっぱ問題があるんだよな。
187:デフォルトの名無しさん
07/12/20 22:02:05
safeiteratorを実装するしか
188:デフォルトの名無しさん
07/12/21 11:37:49
>>33のcapture_stringをパクればいいんでね？
class CaptureString {
public:
typedef char value_type;
private:
CString *target;
size_t size;
value_type *buffer;
public:
CaptureString(CString *target_, size_t size_ = DEFAULT_SIZE)
: target(target_), size(size_), buffer(NULL) {
}
~CaptureString() {
if (buffer != NULL) {
target->ReleaseBuffer();
}
}
operator value_type *() {
if (buffer == NULL) {
buffer = target->GetBuffer(size);
}
return buffer;
}
};
// 使用例
CString str;
fgets(stdin, CaptureString(&str, BUF_SIZE), BUF_SIZE);
189:デフォルトの名無しさん
07/12/21 14:43:07
>>184,185
>>183のやつだったら、
for (GR buf(s); ! buf.enough(GetCurrentDirectory(buf, buf.size())); buf.grow());
みたいに書けるようにメソッド追加すればいいし、
>>188のやつだったら、
size_t BUF_SIZE = 100;
while (GetCurrentDirectory(CaptureString(&str, BUF_SIZE), BUF_SIZE) >= BUF_SIZE)
BUF_SIZE *= 2;
とか書けばいい。
190:デフォルトの名無しさん
07/12/21 16:36:16
結局、固定長バッファで長さ不明のもの受け取る時点で…
リトライすると結果が変わる場合もあるし。
191:デフォルトの名無しさん
08/01/07 15:18:41
既出かもしれないけど
URLﾘﾝｸ(ast.qt-space.com)
結構使いやすいと思った
192:デフォルトの名無しさん
08/01/07 15:41:17
>>191
意図しているのかしていないのか、コードはバグっているしドキュメントには不備があるし、windows.h必須だし……
193:デフォルトの名無しさん
08/01/07 15:53:14
Win32APIで可変長文字列が扱えて置換できるっていうの探してたら
ようやく見つかったから貼ってみた。
このスレ的にはナシなのか。
それでも、どこがバグってるか分からず使ってる幸せ脳なオレ
URLﾘﾝｸ(ayusya.hp.infoseek.co.jp)
これは可変長文字列が使えないし、置換の処理が間違ってた。
194:デフォルトの名無しさん
08/01/07 15:53:35
const性を全く考慮していない辺り、ｱｲﾀﾀﾀなのだが。
つまり、const SJStringを作ってしまうと殆ど(或いは全部か?)のメソッドが使えなくなる罠。
const SJStringから何かを検索することも、SJStringの検索文字列をconst SJStringで与えることもできやしない。
195:デフォルトの名無しさん
08/01/07 16:03:18
>>193
>191のメソッドの、parseInt()かisOnlyNumber()辺りを2バイト数字で試してみて。
>193のクラスも、>194の問題があるね。windows.hに依存しない分だけ使えそうだけど。
196:デフォルトの名無しさん
08/01/07 16:12:09
ずれてる…
１００→211
９９９→333
になった。
197:デフォルトの名無しさん
08/01/07 16:18:41
書き方が悪かった。parseIntでの結果
０ １ ２ ３ ４ ５ ６ ８ ９
1 2 4 5 6 7 8 9 3
７が出てくると0になる。（６７８→0）
・・・変だね。
198:デフォルトの名無しさん
08/01/07 16:20:50
このスレに触発されて文字列クラス作ってるけど、疲れてきたよ。
char awstr[] = "あいaうえbおc";
typedef fixedstring<traits_SJIS> mystring;
mystring fs(awstr);
std::sort(fs.begin(), fs.end());
fs[3] = "字";
fs += 'Z';
std::string tmpstr = fs;
traits_SJIS::char_type dd("そ");
if (dd == "そ");
out_iterator<sys2_to_ucs2> oi("てすとabc文字列");
wcout << with_nul(*oi)() << endl;
fs.assign(oi);
fs *= 3;
wcout << fs;
199:デフォルトの名無しさん
08/01/07 16:55:55
>>197
parseInt()の実装を見てご覧。意図的なら兎も角、こんなバグを作りこむ香具師が信用できる?
200:デフォルトの名無しさん
08/01/07 17:01:25
>>199
どうやら数字を1から9まで数えられない人が作ったようです。
parseInt()だけ直して使おうかなと。
どうせ置換と可変文字列が使えればいいし。
そこだけならwindows.hもいらないみたいだし。
（一番大きな理由は自分では作れないという事）
201:デフォルトの名無しさん
08/01/07 17:06:08
>>200
バグっているのはそこだけじゃないから、充分注意してね。
# つーか、MBCSなら置換も楽なんだけど……
202:デフォルトの名無しさん
08/01/07 17:08:00
なんだろう。この無駄な中括弧の多さは…
文字列を修正して
CString strNumber = __TEXT("-0123456789－０１２３４５６７８９");
その下のif文にコレ追加して
else if (p == 11)
{
str += "-";
}
if文の終わりのところを11にすればいいのかな。
str += strNumber.charAt(p - 11);
203:デフォルトの名無しさん
08/01/07 17:14:18
parseInt()が有るのにparseDouble()なんかが無いのも不思議。
ここらへん全部作ってあるクラスがあっても良さそう。
というか探せばありそう。また探してくるわ
204:デフォルトの名無しさん
08/02/09 12:36:32
結局良いのは存在しないのか・・・
205:デフォルトの名無しさん
08/02/10 13:40:06
ほんとに「完璧」な文字列クラスを作ろうとすると、
・各種エンコーディングの相互変換
・各種エンコーディングの自動判別
・文字列←→整数、小数への変換
・検索、置き換え（正規表現対応で）
・マルチバイト、ワイド文字(2バイト、4バイト両方)に対応
最低でもこれくらいは必要になるからめちゃくちゃ大変。
206:デフォルトの名無しさん
08/02/10 14:21:47
ヘッダーファイル一つインクルードするだけで使えるようなのがいいんだけどなぁ。
正規表現まで対応するとなるとかなりの量になるよね。
207:デフォルトの名無しさん
08/02/10 14:51:45
当然イテレータで要素巡回できるようにしてほしいし、
ついでに、レンジやコンテナの要件も満たしていてほしい。
208:デフォルトの名無しさん
08/02/10 15:23:45
wstringのサロゲートなんとかするだけでもいいっすよ
209:デフォルトの名無しさん
08/02/10 15:29:08
そうするとchar_traitsだけじゃ足りないんだよな。
210:デフォルトの名無しさん
08/02/13 00:13:40
海外のプログラマーはどうしてるんかね？
マルチバイトｶﾝｹｰﾈｰであまり気にしないんだろうか。
普段はstd::stringでも構わないんだけど
GetWindowTextとか使うときに不便だから
ここらへんを一まとめにしたようなのどこかにないかね。
211:デフォルトの名無しさん
08/02/13 14:07:59
中国人とかも困ってるだろうにね。
212:デフォルトの名無しさん
08/02/13 18:58:13
>>210
今度の改定でstd::basic_string<>も
vector同様に要素がメモリ上で連続されることが保証されるようになるらしい。
213:デフォルトの名無しさん
08/02/13 21:50:47
中国人は字が読めるヤツは英語も読めて
英語出来ないヤツは字も読めないから問題ないんだよ
214:デフォルトの名無しさん
08/02/13 21:52:32
国内向けアプリは普通中国語で作るんだろ？
215:デフォルトの名無しさん
08/02/13 22:24:57
それはどうかな
216:デフォルトの名無しさん
08/02/14 05:32:36
仕事でパソコンを使う奴は英語でいいし、英語を読めない奴にパソコンを教えても使えないから問題ない。
217:デフォルトの名無しさん
08/02/14 12:28:31
ワープロやエディタのように英語が読めてもデータとして中国語を扱う必要もあるだろうに。
218:デフォルトの名無しさん
08/02/14 19:21:56
その場合は、中国語だけを扱えばいいから何の問題もない
219:デフォルトの名無しさん
08/02/18 08:04:42
アニメ「さよなら絶望先生」には
糸色 望（いとしき のぞむ） → 絶望
糸色 命（いとしき みこと） → 絶命
糸色 交（いとしき まじる） → 絶交
こういったネタが出てくるのですが、これって文字コードの正規化の一種ですよね？
人気アニメでも使われるくらいなので、かなりニーズのある処理だと思うのですが、
残念ながらこういった「文字の結合」ができるライブラリを寡黙にして知りません。
そこでお願いなのですが、是非新たな文字列クラスにはこういった機能をデフォルトで組み込んでもらえませんか？
220:デフォルトの名無しさん
08/02/18 08:40:08
＞こういったネタが出てくるのですが、これって文字コードの正規化の一種ですよね？
いいえ。
＞残念ながらこういった「文字の結合」ができるライブラリを寡黙にして知りません。
それを言うなら、「寡聞にして存じ上げません」でしょう。
221:デフォルトの名無しさん
08/02/18 12:41:52
雲
雲雲
龍 ←これで一字
龍龍
>>これって文字コードの正規化の一種ですよね？
>いいえ。
222:デフォルトの名無しさん
08/02/18 13:34:06
>>221
言葉遊びとごっちゃにしてませんか?
223:デフォルトの名無しさん
08/02/18 15:01:13
糸色 = 文字コードの正規化
>>221 = 言葉遊び
なぜそう言いきれるのか理由を説明してくれ。
コンピュータにも分かるように。
224:デフォルトの名無しさん
08/02/18 15:33:56
>>223
逆。
>219は言葉遊び。通称「絶望」先生は、本名「糸色望」なのだから。
225:デフォルトの名無しさん
08/02/18 19:19:25
>>205
エンコーディングの自動判別機能については文字列クラスじゃなく、
フリー関数かlocaleを表現するクラスのメンバ関数に持たせるべきだと思う。
国際化された検索機能などを文字列クラス自体が持つとすると、
文字列はエンコーディングとバイト列の組になっているか、
あるいは特定の内部コードに正規化されているはずだけど
自動判別アルゴリズムの入力は「バイト列」と「エンコーディングの候補」になる。
これらを与えることが可能な場所はコンストラクタしかないが、
コード変換しないでエンコーディングだけ知りたい場合に困ってしまう。
226:デフォルトの名無しさん
08/02/19 01:58:32
きっと>>219が言いたかったのは
文字コードで悩むならいっそ画像化して画像解析すればいいじゃない
ってことだろう。
無いな。
227:219(本物)
08/02/19 18:01:30
私の言いたかったことは
「言葉遊びで言葉遊びを説明する・・・
そんな言葉遊びを言葉遊び的に言葉遊びで言葉遊びするという
言葉遊びを言葉遊びしてほしい」
ということです
228:デフォルトの名無しさん
08/02/25 21:12:30
縦読みも正規化だな
229:デフォルトの名無しさん
08/03/09 22:31:12
俺は>>198ではないがオレ流に作ってみたので晒してみる
つ URLﾘﾝｸ(sij.dip.jp)
話にならんってレベルだったらスルーしてくれ…
230:デフォルトの名無しさん
08/04/13 18:49:20
>>229
亀レスだが、文字コードによって文字列クラスを変えるのはどうかと思う。
内部フラグか何かでどうにかならんかな？
こういうことがしたい）
strjp sjis("Shift_JIS文字", encoding::sjis);
strjp euc("EUC文字", encoding::euc);
sjis = euc;
euc = sjis.conv_to(encoding::euc);