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

CString , string , wstringに負けないものをみんなで作ろうね。

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

CFString

>>1
おお、いいスレが立ったな。乙！

こんなスレが欲しかった
>>1乙

Stringでどうよ？

でもそれ.NETがなきゃ動かんじゃん

>>3
>>4
自演乙（藁
そして終了（禿藁

>>1はどうでもいいから前スレで挙がってたC2charうｐきぼん

>>8 =>>1な罠（藁

　　　　　　∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′ ￣￣( ﾟДﾟ)＜ >>1は早急に逝ってよしだｺﾞﾙｧ!!
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

伸びないなぁ。
>>8も俺からもきぼん！

仕方ない
俺が作った（まだ発展途上だけど）かなり便利な文字列クラスをあげるか
それをみんなで改造しよう！！１１

上げました。
http://tune.ache-bang.com/~vg/outitem/up/img/12431.txt

>>13←なんとこれ作るのに丸一日かかりました!疲れた...

String使えよ。

アドレス間違えました
http://tune.ache-bang.com/~vg/outitem/up/img/12432.txt

String使えよ。

>>17
>>6

>>１8
.net使えばいいだろ。

基本的にstd::stringとstd::stringstreamでできるなー。
それを交えて作り直してみたらコードかなり圧縮できるとおもう。

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

NSStringをC++でラップしたら強いのが出来そうじゃね？

>>16
丸一日掛かってこれかよ（ﾌﾟ

前スレはdat逝きか
makimo.toにも無かった

vsprintfはwvsprintf使うべき

STLのstringは、マルチバイト文字をまともに扱えるの?

>>25
あれは基本的にコンテナなんだと思うけど。

みんなwstring使えば解決
なんでみんなUNICODE使おうとしないのか

wvsprintfってウインドウズ？

さようなら>>1の人。

D言語マンセー

D言語もまともなstringがない。
main（char[　][　]）だもんな。。。

>>31
つ std.string/std.conv
"test".toupper()とか"12".toInt()とか可能。

つ ttp://tricklib.com/cxx/dagger/xstring.h

最強の文字列クラスを作るスレ
とかの方がよかったんじゃないか

>>21
CFString

まだあったんだコノスレ(

AnsiStringは放置ですか。そうですか。

>>1
まずCString, string, wstringには現状どのような問題点があるのか？
それを明らかにして、そこをよりよくしたものにするという風にするのが手っ取り早いと思う。
真面目にやる気があるのなら。

string: マルチバイト脂肪
wstring: サロゲートペア脂肪
CString: 脂肪の塊

basic_string<uint64_t>使えば？

万能ナイフを作るな!
というのは文字列クラスにも言えると思う。

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

俺は逆だな
大体std::basic_string<>で済ませる

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

>>42
うしろ2つは文字列クラスというよりは、MSのCOMのためのものだろう。

wchar_tとか、あとJavaも.NETもそうだけど、
UNICODEな文字列って内部では全部UTF-16じゃないですか。

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

最初にUnicodeを作ったときには16ビットで十分だとされてしまったから、
Unicodeにすれば16ビット固定長文字列でマルチバイト文字の処理とおさらばと思われていた。
それはまだUTF-8/16/32もサロゲートペアもなかった1990年代。

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

>>45
ああ、その時代のことは知っていたんだが、
UTF-16と決まってるわけじゃないことは知らなかった。サンクス
GCCはUTF-32なのか・・・

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

>>46
仮に、日本語しか考えない場合、
UTF-8は、マルチバイトと同じく、
扱いにくいのですよ。

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

std::string って std::vector<char> を継承しているのかとか
勝手に思ってたけどそうじゃないんだね。

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

>>48
STLのリファレンス読めばわかることを、なぜ聞くのだ。

読むより聞いた方が速いからじゃないの？
他に理由は浮かばないなあ

>>48
途中にヌル文字があろうと扱えるはず。
また、std::basic_stringがstd::vectorを包含している実装は考えられる。

>>50
速いのかなぁ。

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

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

じゃあ、リファレンス見るより聞いた方が楽だからじゃないの？
さすがに他に理由は浮かばないなあ

>>52
聞いた時点では３分でわかる可能性もあったんだよ。

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

まあ３分で分かるかもしれない可能性を信じて質問する奴の将来なんてたかが知れてるわな

投機実行かもしれないけどね (w

#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; }

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); }

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; }
};

スケルトンにつかってくだせぇ

んなBorlandローカルなものをどうしろと。

俺にはVCローカルに見えるが・・・。

＞__declspec(property(get=Memory,put=Copy)) char* str;
これってどっち?

少なくともVC++には存在する。
http://msdn2.microsoft.com/en-us/library/yhfk0thd(VS.80).aspx

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

>>57-59
必要がなければ、char型限定にしないでクラステンプレートにしろよ。
あと、CopyやAddはもっと例外安全に強くしろよ。ついでにC++ならswap必須。

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

__declspec(property....
はBCCもVCも使えると思うんだが

どっちもつかわないからどっちでもいいよ。

でっていう

汎用的な文字列クラスを作るよりは、
用途別に文字列クラスを作ったほうがいいと思う。

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

>>69
それのどこにどんなメリットが?

>>70
わからない人には必要のないものです。

>>71
必要の有無を聞いているのではないのでメリット(=利点)について宜しく。

パフォーマンスだろうな。

シンプルな文字列クラスを作って、それを用途別に派生させればいいような気がするのだが。

>>69は文字列のクラスというよりは、文字列を記憶するクラスという感じだな。

>>69の文章は異様に圧縮が効きそうだな。

文字列を、「文字」ごとに処理させるのはどうやってやります？
あと、文字数を数える処理とか。（こっちは簡単だけど

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

パフォーマンスを求めなければ、
マルチバイト→先人がやってきたようにやる
Unicode→32ビットでやる

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

>>77
> UTF-32とかUCS-4な文字列クラス使ってる人いますか？

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

32ビットカラーって24ビット＋アルファ値じゃないん？

1画素32ビットであることには違いあるまい｡

std::basic_string<uint32_t>でいい気もするが
必要なコードを全部書くのは面倒くさいし
リテラルが簡単に書けないし
uint32_tの文字はオーバーロード時にただの整数と見なされてしまう

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

いらない子じゃん

たまには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なる型が入るらしいよ。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html
http://pc11.2ch.net/test/read.cgi/tech/1149440647/372-

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

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

D言語だとテンプレート引数に文字列リテラルが使えるらしいな。
そもそもUTF-32なdchar型もあるけどな。

{ xxx, yyy, zzz } ;のように書き換えるプリプロセッサを用意するだけじゃダメなん?

>>87
それだと

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

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

C99の複合リテラルなら静的記憶期間を持つから、
前者にも対応できるけど標準C++にはきっと入らない。

もしかしてC99では
printf({'h', 'e', 'l', 'l', 'o', ',' 'w', 'o', 'r','l','d','\n', 0});
とか書けるのか

キモいな

http://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});
}

static const uint32_t _utf32_str[] = { うりゃぁ } ;
const uint32_t *utf32_str = _utf32_str ;

これでいいじゃん。

{ うりゃぁ }
これはダメだろｗ

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

"うりゃぁ"のつもりではなくて・・・
{ 14235, 13456, 15196, 15611, 0 }
とかのつもり。

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

> かつての日本語対応のやりかたと一緒
あー確かにそうだな
Javaのnative2asciiみたいなもんとも言えるな
ただ、昔はリテラルを8進とか16進とかのリテラルに置き換えるだけで
すんでたでしょ

>>93
87の言うようなプリプロセッサの出力が92みたいになればいいと思う。

簡単に言うが、マクロとかテンプレートとか色々考慮してるか？
生半可な考えは絶対破綻する

char *hage = L"hage";
printf("%s\n", hage);
何も表示されませｎ

>>98
スレ違い。

>>98
それをコンパイルするときに警告が出るようにしろ。
どうやってもそれで警告を出さないコンパイラなんて窓から投げ捨てろ。

用途別に、
アルファベットだけ格納できる文字列クラス、
ひらがなだけ格納できる文字列クラス、
ウかんむりの漢字だけ格納できる文字列クラス、
とか作ったら、激しく労力の無駄でいい感じじゃね？

テンプレートで自動生成したいなそれ

>>102
まずは対応する文字クラスを作らなきゃなぁ。

やはり問題の根元は、
文字型がCにないことだな。

逆に無かった事で今日まで生き残れた

素朴な疑問だが、文字型が存在する言語って何がある?

C++ wchar_t

今度の0xではchar16_t, char32_tが追加の予定。

>>106
Javaとか

クラスで扱う文字コードは、
OSのAPIが要求する文字コードにあわせるのが一番なんだろうけどな。

cinで入力される度に、文字コード変換して格納、
coutで出力するたびに再度文字コードを変換して出力ってのは無駄が多いし。

>>109
結局、char なら ASCII もしくはマルチバイト、
wchar なら UTF-16 って自分の中では決めてる。
で、マルチバイトに関しては環境に合わせる方向で。
でも実際には wchar だからって UTF-16 と決められないケースもおおいよね。
C++0x ではまた新たな型が追加されるみたいだねぇ。

C++0x になったら UTF-16と決めている場合には char16_t をつかうべき？
そりゃそうと、根本的な疑問なんだが、 UTF-8 も UTF-16 も
所詮は可変長文字だよね。内部コードとしてどちらを使うべきかは
どうやって決めればいいんだろう。好きなの使えば？ってのは無しの方向で。
自分の中でどういうガイドラインを作っておけばいいかなぁ、と迷う。

http://www.rubyist.net/~matz/20070312.html
まつもと氏はバイトオーダーの問題があるから
事実上 UTF-8 でいいじゃんって主張みたいだねぇ。
まぁわからないでもない。ただ Windows で
プログラムを書くことが多い身としては UTF-16
との変換をしばしばする必要があるのは屋だなぁ。
UTF-8とUTF-16のマップは表現系だけの変換で
マップは必要ないからそんなに苦にはならないか。

いっそのこと Mule のコードを流用、というのはやりすぎか。
http://www.dennougedougakkai-ndd.org/~delmonta/emacs/27.html

char64_tがあれば…

>> std::basic_string<uint32_t>
本気で実装するなら、facetから作ることになるのか…char_trait<uint32_t>…
それでコンストラクタではSHIFT-JISから変換格納？
すごく遅そう…ただでさえfacetキャッシュしないと遅いのに…

俺思うんだ...
文字コードの体系が増えれば増えるほどややこしくなってるって...

文字を捨てよう。
動物に帰ろう。

それはやりすぎ。
ASCIIだけ残せばいい。

>>116
漏れの作った新しい文字コードをみんなが使えばいいんだ
問題はすべて解決だ

0x00 = ひ
0x01 = ろ
0x02 = ゆ
0x03 = き
0x04 = 改行

ここまで策定した。残りはよろしく

0x05ぬ
0x06る
0x07ぽ

0x08=ガ
0x09=ッ

つか、1バイト長で日本語表現するつもりですかw

0x0a い
0x0b つ
0x0c て
0x0d よ
0x0e し
0x0f 。
0x10 お
0x11 ま
0x12 え
0x13 も
0x14 な
0x15 ー

案外被らずにいけるもんだな。

0x16 = o
0x17 = r
0x18 = z
0x19 = O
0x1a = T
0x1b = L

0xfe 終
0xff 了

0x100宇
0x101宙
0x102ヤ
0x103バ
0x104イ

>>127を持ちまして可変長コードになりました。

>>128
しかも、それが1byte目なのか2byte目なのか判別不能な可変長コード...

以下、
リトルエンディアンとビッグエンディアンによる骨肉の争い。

文字列ぐらい言語仕様で持ちやがれ

C++の歴史は文字列の抽象化の歴史だ。
言語仕様で文字列を定義したが最後、
C++の進化は止まるだろう…

char や int のビット幅すらきめうちにはしなかったわけだからなぁ。
あ、そういうわけでビットローテートが演算子として用意されていないのかな？
ローテート結果に関して何か決めようとするとビット幅が固定されて
いないと何も言えないからねぇ。

ローテートはビット数に依存するからCの仕様では無理だわな
VCには独自拡張であるけどね。2005からは8,16ビットにも対応してる

>>1-135
ここの住人のやる気のなさがわかったおｗｗｗｗ

もうC++で文字列使うのやめようぜ

basic_stringはピザだからなぁ…
非メンバ非friendな便利関数としてデザインし直したものを作ってやろうかと妄想してるよ

>>134
え？Visual C++ にはあるの？
どんな感じの構文？

_rotl　だっけ？

それ、演算子じゃなくて関数じゃないか

わかったよ、じゃあ文字コードの次は演算子の策定と行こうか

><< ＝左ローテート
>>< ＝右ローテート

ここまで策定した。残りはよろしく

文字列をローテートするとどうなる。

>>142
たぶん読みにくくてたまらない。

>>142
ジェットストリームアタック

文字列をローテートするとどうなる。
。文字列をローテートするとどうなる
る。文字列をローテートするとどうな
なる。文字列をローテートするとどう
うなる。文字列をローテートするとど
どうなる。文字列をローテートすると
とどうなる。文字列をローテートする
るとどうなる。文字列をローテートす
するとどうなる。文字列をローテート
トするとどうなる。文字列をローテー
ートするとどうなる。文字列をローテ
テートするとどうなる。文字列をロー
ーテートするとどうなる。文字列をロ
ローテートするとどうなる。文字列を
をローテートするとどうなる。文字列
列をローテートするとどうなる。文字
字列をローテートするとどうなる。文
文字列をローテートするとどうなる。

>>144の中にウォーリーがいます。君はみつけられるかな？

みつからねぇ…

単項演算子「!」を提案するよ
矢印の右が演算後の値ね
詳細な仕様と実装はあとの人に任せる

!"良スレ"　→　"糞スレ"
!"有用な議論"　→　"不毛なダベり"

は？

それ実現させたらどんだけデータベース抱えたクラスになるとおもっとるんだｗｗ

!"このスレ"　→　？

C++で独自の中置演算子を定義出来たら、
どんなに素晴らしい世界が待っているんだろう。

ある日ＮＯぷりすたぁ
http://www.freewebs.com/photoradio/?518235

そこでホワイトスペースのオーバーライドですよ

純粋抽象クラス（ようはインタフェース）を定義して
ファクトリから文字セットを指定してインスタンスを得る仕様がいいのかな。
バイトオーダー非依存かつマルチバイトであるUTF-8を最初にサポートすれば
他の文字セットのサポートor最適化もしやすいだろうし。

改行やTABもやれば Whitespace っぽくできるかも
「C++で関数型プログラミング」の次は「C++でWhitespace」だな
間違いない。

完全素人だが
内部をUNICODEで実装しといて
どんな文字列も受けれるな仕様にしたらいかんの？

ウニ文字の内部表現はどうするのさ？

参考までに聞きたいんだけど、JISコード(SJISじゃなくて「)を直接操作する
文字列クラスって作ったことありますか？
格納だけじゃなく検索とかの機能付きで。
一般的にはSJISに変換してるんだろうか。

あ〜、ついでに終端が0じゃない文字列コードって存在するんですか〜？

文字のコードポイントと、エンコーディングと、
文字列の内部表現とをごっちゃにして
釣ろうとしてるようにしか見えない。

マジレスすると、必要なのは新しい文字列クラスではなく、
エンコーディングを意識した文字列イテレータ。

さらに、部分文字列(あるいはマルチバイトの一文字分)をポイントする
beginとendのペアみたいなデータ型が標準化されれば、
色んなユーティリティを作りやすくなると思う。

アルゴリズム(ポリシー?)を与えておけば
コピーされる際にそれを使って自動的にエンコードしてくれるって寸法か
いいなそれいいな
って誰かがもう作ってそうなふいんきだけど

>>160
substringクラスでも作るか？

>>158
それはコードじゃなくてC言語系の規則。
BSTRていうのは配列の頭に文字数を入れたはずだし、
D言語ではその規則も使えるが、配列が配列長をしってるから、
そんなナンセンスなことは必要ない。

ま、C++でもVC系（これしか知らない。）のstd::stringは内部的には長さで処理しているが、便宜上0終端を強制されてる感じっぽい。

>>160
その希望は多分Rangeって概念だと思うよ。Boostに入ってる。

>>161
それいいね。でも変換関数なりを書くのが一番だるいって言う。
一回書けばつぶしが利くのだけど、その一回がなぁ。

>>164
チゲーよバカ

あれ？
あぁ、後者って書き忘れたなぁ。
エンコーディングはよぉーしらん。

目的のものを作っちゃった俺がきましたよ

>>168
公開！公開！

オプソ化きぼんぬ

オプソしたってめこめこに叩かれるだけじゃないのか？
前の方にあった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でいいじゃん？
力作のレスだぜ。さあ叩いてくれ

文字コードを知っている必要があるのはコンテナではなくイテレータだってアイデアはいいと思うよ。

双方向イテレータとランダムアクセスイテレータを作るのは
難しそうだけど。

文字単位でランダムアクセスできる機能は
大部分の用途に対してオーバースペックだから捨てるのが前提だ。
必要に応じて、途中のイテレータを保存しとくとか、
32bit文字オブジェクトのベクタに変換したりしてどうにかする。

内部表現がUTF-16なら双方向は楽でしょ。
マルチバイトとはいえ下位サロゲートが出現したら、その前を頭にすればいい。
ランダムアクセスは内部で結局はイテレートするしかないよね。

内部表現がUTF-16(UCS2)かUTF-8で、UCS4を取り出すようなイテレータだったら、
boostのicuで使われてるはず。

>>174
可変長ならランダムアクセスはそもそも実装不可能だろう

ランダムアクセスあきらめたら、
「与えられたテキストファイルで使われているすべての文字の一覧を求めろ」
と言われたときどうするの？
STLでsort() → unique()、という手が真っ先に思い浮かぶんだけど、
sort()はランダムアクセスイテレータがいるんだよね。

コピーするほかない
コピーするのかビューなのかを
場合により選べるのがイテレータの良いところ

どうせWin32APIの文字受け渡しが癌

癌は受け渡しより受け取りの方だと思うが。

GetBuffer→API呼ぶ(→ReleaseBuffer) の流れからは逃れられない

>>33を使えばAPIからの受け取りもそれほど面倒ではないけど、文字コードが違う場合には
自動で変換できるようにしないとな。

>>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
MSのプログラマですらオーバーフロー度々起こすってことはやっぱ問題があるんだよな。

safeiteratorを実装するしか

>>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);

>>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;
とか書けばいい。

結局、固定長バッファで長さ不明のもの受け取る時点で…
リトライすると結果が変わる場合もあるし。

既出かもしれないけど
ttp://ast.qt-space.com/slibrary/sjstring.html
結構使いやすいと思った

>>191
意図しているのかしていないのか、コードはバグっているしドキュメントには不備があるし、windows.h必須だし……

Win32APIで可変長文字列が扱えて置換できるっていうの探してたら
ようやく見つかったから貼ってみた。
このスレ的にはナシなのか。
それでも、どこがバグってるか分からず使ってる幸せ脳なオレ

ttp://ayusya.hp.infoseek.co.jp/ProgramCString3.html
これは可変長文字列が使えないし、置換の処理が間違ってた。

const性を全く考慮していない辺り、ｱｲﾀﾀﾀなのだが。
つまり、const SJStringを作ってしまうと殆ど(或いは全部か?)のメソッドが使えなくなる罠。
const SJStringから何かを検索することも、SJStringの検索文字列をconst SJStringで与えることもできやしない。

>>193
>191のメソッドの、parseInt()かisOnlyNumber()辺りを2バイト数字で試してみて。
>193のクラスも、>194の問題があるね。windows.hに依存しない分だけ使えそうだけど。

ずれてる…
１００→211
９９９→333
になった。

書き方が悪かった。parseIntでの結果
０　１　２　３　４　５　６　８　９
1　 2　4　 5　 6　7　 8　 9　3
７が出てくると0になる。（６７８→0）
・・・変だね。

このスレに触発されて文字列クラス作ってるけど、疲れてきたよ。
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;

>>197
parseInt()の実装を見てご覧。意図的なら兎も角、こんなバグを作りこむ香具師が信用できる?

>>199
どうやら数字を1から9まで数えられない人が作ったようです。
parseInt()だけ直して使おうかなと。
どうせ置換と可変文字列が使えればいいし。
そこだけならwindows.hもいらないみたいだし。
（一番大きな理由は自分では作れないという事）

>>200
バグっているのはそこだけじゃないから、充分注意してね。
# つーか、MBCSなら置換も楽なんだけど……

なんだろう。この無駄な中括弧の多さは…

文字列を修正して
CString strNumber = __TEXT("-0123456789−０１２３４５６７８９");

その下のif文にコレ追加して
else if (p == 11)
{
str += "-";
}

if文の終わりのところを11にすればいいのかな。
str += strNumber.charAt(p - 11);

parseInt()が有るのにparseDouble()なんかが無いのも不思議。
ここらへん全部作ってあるクラスがあっても良さそう。
というか探せばありそう。また探してくるわ

結局良いのは存在しないのか・・・

ほんとに「完璧」な文字列クラスを作ろうとすると、

・各種エンコーディングの相互変換
・各種エンコーディングの自動判別
・文字列←→整数、小数への変換
・検索、置き換え（正規表現対応で）
・マルチバイト、ワイド文字(2バイト、4バイト両方)に対応

最低でもこれくらいは必要になるからめちゃくちゃ大変。

ヘッダーファイル一つインクルードするだけで使えるようなのがいいんだけどなぁ。
正規表現まで対応するとなるとかなりの量になるよね。

当然イテレータで要素巡回できるようにしてほしいし、
ついでに、レンジやコンテナの要件も満たしていてほしい。

wstringのサロゲートなんとかするだけでもいいっすよ

そうするとchar_traitsだけじゃ足りないんだよな。

海外のプログラマーはどうしてるんかね？
マルチバイトｶﾝｹｰﾈｰであまり気にしないんだろうか。

普段はstd::stringでも構わないんだけど
GetWindowTextとか使うときに不便だから
ここらへんを一まとめにしたようなのどこかにないかね。

中国人とかも困ってるだろうにね。

>>210
今度の改定でstd::basic_string<>も
vector同様に要素がメモリ上で連続されることが保証されるようになるらしい。

中国人は字が読めるヤツは英語も読めて
英語出来ないヤツは字も読めないから問題ないんだよ

国内向けアプリは普通中国語で作るんだろ？

それはどうかな

仕事でパソコンを使う奴は英語でいいし、英語を読めない奴にパソコンを教えても使えないから問題ない。

ワープロやエディタのように英語が読めてもデータとして中国語を扱う必要もあるだろうに。

その場合は、中国語だけを扱えばいいから何の問題もない

アニメ「さよなら絶望先生」には

　糸色　望（いとしき　のぞむ）　→　絶望
　糸色　命（いとしき　みこと）　→　絶命
　糸色　交（いとしき　まじる）　→　絶交

こういったネタが出てくるのですが、これって文字コードの正規化の一種ですよね？
人気アニメでも使われるくらいなので、かなりニーズのある処理だと思うのですが、
残念ながらこういった「文字の結合」ができるライブラリを寡黙にして知りません。
そこでお願いなのですが、是非新たな文字列クラスにはこういった機能をデフォルトで組み込んでもらえませんか？

＞こういったネタが出てくるのですが、これって文字コードの正規化の一種ですよね？
いいえ。

＞残念ながらこういった「文字の結合」ができるライブラリを寡黙にして知りません。
それを言うなら、「寡聞にして存じ上げません」でしょう。

　雲
雲雲
　龍　　　←これで一字
龍龍

>>これって文字コードの正規化の一種ですよね？
>いいえ。

>>221
言葉遊びとごっちゃにしてませんか?

糸色 = 文字コードの正規化
>>221 = 言葉遊び

なぜそう言いきれるのか理由を説明してくれ。
コンピュータにも分かるように。

>>223
逆。
>219は言葉遊び。通称「絶望」先生は、本名「糸色望」なのだから。

>>205
エンコーディングの自動判別機能については文字列クラスじゃなく、
フリー関数かlocaleを表現するクラスのメンバ関数に持たせるべきだと思う。
国際化された検索機能などを文字列クラス自体が持つとすると、
文字列はエンコーディングとバイト列の組になっているか、
あるいは特定の内部コードに正規化されているはずだけど
自動判別アルゴリズムの入力は「バイト列」と「エンコーディングの候補」になる。
これらを与えることが可能な場所はコンストラクタしかないが、
コード変換しないでエンコーディングだけ知りたい場合に困ってしまう。

きっと>>219が言いたかったのは
文字コードで悩むならいっそ画像化して画像解析すればいいじゃない
ってことだろう。

無いな。

私の言いたかったことは
「言葉遊びで言葉遊びを説明する・・・
そんな言葉遊びを言葉遊び的に言葉遊びで言葉遊びするという
言葉遊びを言葉遊びしてほしい」
ということです

縦読みも正規化だな

俺は>>198ではないがオレ流に作ってみたので晒してみる
つ ttp://sij.dip.jp/strjp/

話にならんってレベルだったらスルーしてくれ…

>>229
亀レスだが、文字コードによって文字列クラスを変えるのはどうかと思う。
内部フラグか何かでどうにかならんかな？

こういうことがしたい）
strjp sjis("Shift_JIS文字", encoding::sjis);
strjp euc("EUC文字", encoding::euc);
sjis = euc;
euc = sjis.conv_to(encoding::euc);

可変バイトな文字を扱えるbasic_stringがあれば全て解決する

C++ チックに、いてれーたを活用してみるとか
コンテナは std::vector<byte> にして、既存のアルゴリズムが利用できるとか。
正規表現は boost::xpressive を利用。


std::vector<char> sjis(100);
memcpy(&sjis[0], "あいうえお"); // shift_jis

typedef codepage<932> cp_sjis;
typedef codepage<51932> cp_euc_jp;
typedef typename cp_sjis::ucs_iterator sjis2ucs_iterator; // Forward Readonly Iterator

sjis2ucs_iterator first = cp_sjis::begin(sjis);
sjis2ucs_iterator last = cp_sjis::eos;

int len = std::distance(first, last); // 5;

ucs4_t ch = *first; // ch = u3042

std::vector<char> euc;
std::copy_to(first, last, cp_euc_jp::back_inserter(euc));

C++0xとboostでなんとかならんものか

あと10年もすれば
「もうbasic_string<uint32_t>でいいんじゃね？
メモリ128TBが2000円の時代だぜ」

ないな。

10年じゃせいぜい128GBくらいだろ

Windows Vistaが32bitに対応したせいで64bit化が5年は遅れたな。
せっかく名器XPから衣替えしたんだから、32bitなんて捨てるべきだった。
64bitに一本化してりゃ5年で128GBなんて通過してただろうに。

Vista32出してなかったら、XP64よりはマシな程度の普及率だったろうよ。

XP64 はバグバグでひどい

それServer 2003 x64がバグバグって言ってるのと同じだけど分かってる？

だってタスクバーのボタンをクリックしたら
別のアプリが上に来る事があるし、
ゾンビプロセス残りやすいし・・・。

何でバグるんだろうな？long(32)にポインタを突っ込んだりしてるから？
流石に天下のミクロソフトがそんなことをするとは思えんが。

EUCかJIS(S-JIS)で十分じゃん。

>>240>>242
http://pc11.2ch.net/test/read.cgi/win/1229152159/27
ちょっと違う話だけど、デスクトップヒープを増やしたらどう？

ちょｗ

ダメ

やっぱりWindows APIやらの既存ライブラリに文字列を渡すことを考えると
std::wstring + 文字コードを処理できるイテレータっていうのが理想になるのかな

スルー推奨

は？

ひ？

wchar_tが2Byteとか言い切っちゃう男の人って

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その３
『いつもサボってばかりのキャップがウゼえ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★
> 71 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:58:57.28 ID:PVAf+dux0
> >>69
> 大変って言うか
> 毎日、報告されたのを見て、判断して、処理して、完了報告して、以下ループ。
> ちょっとでもミスすると、普段は作業もしてないキャップさんたちがさんざん文句言ってきて
> その言いわけを考えないと、キャップはく奪されたりアカウント凍結されたりするから
>
> 登録されてから一年以上経って、やっといいたいこと言えるようになってきたよ。



----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

結局上位レイヤーだけで小細工をしても結局無理が出てしまうわけで。
言語圏の統合という名の下に赤紙が来るならエンジニア達も戦場に行くのではないかということ。
確かに人々が殺しあったり文化を淘汰することはよくないことだけど、そろそろこの問題に終止符を打つことも後世のために必要なのでは。

まず文字コードが1byte文字2byte文字で分けられてることが問題なのだ

そんな藻前には、これ。　　っUTF-32

一番の課題は如何に余所様へ迷惑掛けない様に実装するかだね

文字コードを決める標準化団体(あんのか？)が標準文字コード作って
OS作ってる連中やライブラリ作成団体が文字配列の仕様をそれに従えばなんとか・・・

unicodeコンソーシアム？