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

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

はいはい、2げっと

--------------------- 終了 --------------------------

>>1
CString , string , wstringでだめな理由をあげてください。

なんでこの板の人間は非建設的で新しいスレが立つと何も考えずに叩こうとするんだろう。
興味なければ書き込まなければいいのに。

>>4
> なんでこの板の人間は

2chはそういうところ。挨拶みたいなものだ。

何でこの板には>>4のような駄スレを立てる厨房がいるんだろう。
こんな下らないスレなんて立てなければいいのに。

>>1 それなんですか?
どのnamespace?
C++よくしらない香具師にもわかりやすく説明してくれ

>>4 説明が足りないから

typedef char * _2chstring;

クラスじゃないけどこれでいいよ。
領域確保は利用者が自分でやる。

>>8 アイタタタタ......

それよりコンテナ要件を(ほぼ)満たすvalarrayが欲しい

俺も >>3 と同じ疑問。
>>1
御託はいいから答えれ。

>>11
むしろこちらが聞きたい。どうして満足できるのかと。

>>1
まず１が思う必要な機能を書いてくれ

ｱﾗｼは時間の無駄だから、他のスレに行ってくれ。
それとも、そんなに暇でつか？

>>12
どこが満足できないのかを語れといってるのでは？

>>13
荒らしというのは10分でスレを潰すようなのをいう。

質問を質問で返すなボケ

string::c_str() が書き込み可能だったらいいなと思うことはあるな。
新しい文字列型を作るほどではないが。

とりあえず>1は反省しる！
そして、文字列クラスを継承して138ヶ国語に対応したトランスレータをつけれ！

>>17
了解しました。

現在すでに存在するstringでの問題点を上げることで、
改良、新規開発を行う意義が出てくると思います。

目的なくしては、歯車の発明を繰り返すように不毛です。
具体的には、どの変が問題でしょう？

>>19
stringが言語仕様に組み込まれていないこと
標準ライブラリがstringを完全にサポートしていないこと(なのでc_strを多用しないといけない)｡

ゆえに手遅れ｡

>>16
それどういうこと？

>>20
言語使用に組み込まれている利点はなに？
あと、標準ライブラリってなんぞ？

C++ の文字列型の最大の問題点は、文字列型が多すぎることだと思うが。

char*, wchar_t* に始まって std::string, std::wstring, CString (MFC), WTL::CString,
_bstr_t, CComBstr, etc..

これ以上、増やさんでくれ…

みんな。wstring使ってる？

実行効率のために目的の分だけ用意しようって感じだからねえ。

>>24
使ってみた。

俺のUNKOString最強
変なスプリッタとか置換とか不気味な暗号化とか不気味な機能搭載しまくりで最高

おれぁ、日本人なら、stringなんか使わず、全部wstringにすりゃいいのにって
思うんだけど、誰も賛成してくんねーのよ。
結果として、wstringは使えない。

なんか変じゃないのか、日本。

>言語使用に組み込まれている利点はなに？
文字列クラスを乱造するｱﾌｫがいなくなること

>あと、標準ライブラリってなんぞ？
std

>>29
c++でのstdはSTLだと思うのだが、これいかに。
っていうかstdってなんだ？unistdとかのことかな。

もしかして、c++をbetter cとして使いたいだけ？

>>27
公開ｷﾎﾞﾝﾇ

>c++でのstdはSTLだと思うのだが、これいかに。
ﾊｧ?

まぁ、文字列リテラルがstd::basic_stringだったら、と思うことはたまにあるが。
つーか、どうせならCharset変換用facetのフリー実装でも作ってくれ。
Dinkumwareのは有料のはずだし。

>>28
wstring, wchar_t は扱い微妙なんだよな。

std::exception::what() の戻り値も char* だけで wchar_t* ないしさ。

>>28
char*との相互変換が簡単だとよかったのにね。

>>34　>>35
勉強になりました。

class strong {
unko buriburi;
}

inline std::string::operator const char * () const { return this->c_str(); }
キボンヌ

inline std::string::operator const char () const { return this->c_str()[ rand() % strlen( this->c_str()) ]; }
キボンヌ

char*廃止
キボンヌ

>>39
何がやりてーんだよ（ｗ

>>40
Yahoo!メールで利用できるディスク容量は最大で6.0MBです。

お客様は既に7.0MBを使用しており、使用できるディスク容量をかなり
超過しています。そのため、一時的に新しいメールを受信できなくなっており
ます。新しいメールを受信する前に、既読の古いメールもしくは容量の大きな
メールをフォルダから削除してください。（削除したいメールのチェック
ボックスをオンにして「選択されたメールを削除」ボタンをクリックしてくだ
さい。）

どうせなら2CHTL作ろうよ

>>43
C 「炭素 （Carbon）」 （6） 原子量 12.0111
　単体には、黒くてもろい黒鉛と、透明で硬いダイヤモンドがある。このうちダイヤモンドは
　電気を通さないが、黒鉛はゆるい層状構造の間を電子が移動できるので、金属などと同じく
　電導性を持つ。

H 「水素 （Hydrogen）」 （1） 原子量 1.007947
　もっとも軽い元素。常温で２分子の気体になる。反応性に富み、酸素と一緒に火を付けると、
　高熱を出して燃える。同位体には、普通の軽水素（元素記号Ｈ）、重水素（元素記号Ｄ）、
　３重水素（元素記号Ｔ）がある。３重水素は同位体として不安定で、時間がたつとヘリウム
　の同位体に変化する。
　映画「宇宙戦艦ヤマト・完結編」において、３重水素が常温で液体であるかのように描かれ
　ていたが、これは何かの間違いであろう。波動砲の一撃で大爆発を起こしたが、もちろん
　真空中ではこのようなことは起きないはずである。

H 「タリウム （Thallium）」 （81） 原子量 204.38332
　ガリウムやインジウムと同じく存在量は非常に少ない。黄鉄鉱などの硫化鉱物を焼いた際の煙
　から取れる程度である。この族の他の金属と異なり、塩酸や硫酸にゆっくりとしか溶けない。

で、何するの？

> H 「タリウム （Thallium）」

Tl 「タリウム （Thallium）」

char *だけで十分でしょ(笑)

>>46
と言う奴に限って文字列リテラルでバグる罠。

ほれ。
class _2chstring{
public:
　　char str[65535];
};

前にあるアンダーバーはなんだ？

>>49
先頭が 2 じゃエラーになるだろ。

くっ。

>>49
標準規格に入れるという野望があるんだろ。

で、結局皆は文字列何使ってんの?

俺はこんなふうにしてる
#ifdef _UNICODE
typedef std::wstring TString;
#else
typedef std::string TString;
#endif

そんなことせんでも
typedef
std::basic_string<TCHAR, std::char_traits<TCHAR>, std::allocator<TCHAR> >
tstring;
としとけば良いじゃん。

MFCってCString とか CWnd とか、良い名前全部取っちゃっ
てるからずるいよな。名前が重ならないようにしないと・・。

デフォルトの名前空間で優先順位がつけられたらいいのに。

文字列クラスなんか要らん。遅くなるだけだ

遅いと感じるなら、標準アロケータから俺様アロケータに換えればいいのでは？

>>56
54氏がやってるように
某島流の「T何たら」にすればよかんべ

>>55 おお、そんな手がありましたか、勉強になりますた。

>>59
Tって何の略でつか？

>>59
>54氏がやってるように
>某島流の「T何たら」にすればよかんべ

54氏がやってるのは、
LPTSTRやTCHARのTを真似ているんだと思うんだけど、
某島流の「T何たら」のTも同じ意味から来てるの？

>>61
漏れも知りたい。想像でTranslateあたりと思ってるんだけど、
実際はなんなのか知らんし。

>>61-62

T は Type じゃないの？　知らんけど。

Delphiだろ

>>64
Delphi は島だよヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ!!

T〜はテンプレート

Turboに決まってんだろがこのスットコドッコイ

#undef char
class char;

誰か適当に char 作って

charはマクロじゃないYO!

class Char{};
#define Char char

こうかな?

C++では#defineを使ってはならないと聞いたけど本当？？

定数を作る場合と関数風マクロを作る場合は使うべきではない

ただ#defineじゃないと出来ないことがちょびっとあるので
使ってはならない訳でも無いのですか?

条件付きコンパイルやインクルードガードには必用だよな

ふむ、自分用の文字列関数既に作ってる。
あんまり調べずに作ったから、
C++にwstringというライブラリが存在していたのかー。と焦っちまった。

Stringクラスの実装て結構難しい門奈。

class String{
public:
　std::string data;
};


終了

そうでもない
面倒なだけ

class String : public std::string{};
こっちのほうがいいと思われます、終了

>>78
くやしいけど俺の負けだ。

いや。

typedef std::string String;

で、どうかな。終了

俺はこうしてる。

typedef std::wstring String;

C++で16bit文字は使いづらいよう。
文字列リテラルの前にLいるし、char *じゃナイトだめな関数が結構あるし。

そうなんだよな。俺なんかDirectMusic使っていきなり
WCHARでファイル名を格納せにゃならないと知った時
面倒だと思ったよ。そんでもってUNICODEじゃないという。
２度びっくり。

>>82
マルチバイト文字列の処理と比べれば楽だと思うけどな。
ただ変換すればいいだけなんだし。

Lは面倒だが癖になっちまったよ。
JavaでもついついLを付けちまう。

WinNT系のようにOS自体がUNICODE化されており、ほぼあらゆるAPIに
WCS版があるという幸せな環境なら楽だが、UNIX系のOSだと、システムコール
にしろライブラリを使うにしろ、ほぼ何をするにも変換が必要になると思われ。
C++ならまだどうとでもなるが、Cだと「ただ変換をするだけ」でも結構
面倒くさい。
どっちが楽かは、どの程度字句単位の処理をするかによるんじゃないのかな。

ワイド文字リテラルはまともにサポートしてないコンパイラがあるんで
困りもの。
エンコーディングもUCS2/UTF32に決まってる訳じゃないし。

>>77
実用上、参照カウントとかコピーオンライトとか実装しないと駄目だろ。
結構難しいんじゃないかと。

System::Stringを使えば解決

ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ ｽﾀｰﾊﾞｯｸｽｺｰﾋｰ

死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ
死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ 死ぬ気でｽﾀｰﾊﾞｯｸｽｺｰﾋｰ

やかまし

>>88-89
そんなお前は昔、俺と共にどっかの糞スレでｽﾀｰﾊﾞｯｸｽｺｰﾋｰを書いてた奴だな。
感動の再会。

dat落ちしてるけどここか。
http://pc2.2ch.net/test/read.cgi/tech/1017223873/

std::stringのfind系はマルチバイト文字に対応してないから使えないよな。
俺は派生クラスを作ってるから構わんけど。

STLのクラスを継承するなよ

>>94
じゃあどういう解決法がある？

自分で一から書けよ。

>>96
誰がそんなアホらしいことやるかよ

>>97
委譲汁

で、何でSTLクラスを継承したら逝けないの?
ATLではテンプレートクラスでも継承しまくりだけど。

仮想デストラクタを持っていないから。

>>100
仮想関数を使わなければいいんじゃないの？

激しく意味不明のことを書いてしまったな

というか、std::stringでMBCSを使いたいなら適当なtraitsを作って食わせるのが正道なんだが。

>>103
残念ながらchar_traitsを定義しても、MBCSには完全対応できないのですよ。

>>100
じゃあ基底クラスのポインタでdeleteしないように注意すれば、仮想デストラクタについては問題なしってこと？

所有で解決出来るのに、わざわざ継承するのは良くない

public継承を無理矢理やることは出来るが、std::stringは効率優先で
virtualを排除している以上、ポリモーフィズムは機能しないから、
邪道と云うべきだろう。要はpublic継承なのにインタフェースの継承
にならない。実装を利用したいだけならprivate継承かaggregationを
使うべき。

stlのstringメンバ関数多すぎ
とある理由でstringクラスのProxyが必要になったので
同じインターフェイスをもつクラスを作ろうとしたのだか
委譲するのにとても苦労した、というか途中でやめた

stringとwstringの統合ってできないんか？

class my_string : public std::string , public std::wstring{};

>>108
operator std::basic_string<E,T,A>()作ればいいんじゃね？

>>111
擬似参照が必要だった
それだけでは足りなかった

http://www.codeproject.com/useritems/stringex.asp?target=cstringex

とりあえずここ見たら

飾り文字フォントクラスとかないかなー。

宣伝うざい

>>115
>>113はJerry Evansかよ（ｗ

>>116
そうですが。

俺は、CUnicode作ってたまに使ってる。
日本語を含む字句解析（1文字ずつ調べる）がやりやすい。
でも、やっぱりメインは、std::stringだ。

文字列クラスって
内部で動的に確保や、
ちゃんと内部でコピーするコピーコンストラクタ。
いろんな operator
operator = や +=、friend operator + 等も作るし

内部ハンドルをどう渡すか（コピーしたものを渡すか、constにするか）
自分自身に代入した時にデータが消えないように気をつける（内部のdeleteタイミング）
とか

基本的なことだけど
たくさんあるので、いまいちクラスわかってなかったら
勉強のためにやってみる価値はあるかも。

俺は、これに
よく使用するファイルパス名操作関連つけたり、
LCMapStringラッピング？など
追加や派生で、いろいろ出来るの作った。たまにやくだつ。




でも、やっぱり普段使用するのはstd::string。

文字列クラスの開発には高い教育効果がある、と
禿先生も言ってたな。

>>120
奴は信用できん。ソース読むときプロポーショナルフォント使ってる
やつをみて爆笑してたもん

>110
やめなはれ，スライシングが起こるよ．

>>121
興味ある、詳細希望

>>121
俺も詳細希望

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

>>123-124
やつのページのはじめの画像に猫缶使ってみれ

「プログラミング言語 C++ 第3版」はソースをプロポーショナル・フォントで
載っけてありますわな。

★あなたのお悩み解決致します！！
●浮気素行調査
彼氏、彼女、妻、夫の浮気を調査致します！！
●別れさせ工作
あらゆる手段を使ってターゲットを別れさせます！！
●盗聴器盗撮機発見
あなたの部屋に誰かが仕掛けているかも！！
●行方調査
行方不明になっている家族の消息を調査致します！！
●電話番号から住所割り出し
一般電話、携帯から住所を割り出し致します！！
その他人生相談からどんなお悩みでも解決いたします！！
　直通　　０９０−８５０５−３０８６
ＵＲＬ　　http://www.h5.dion.ne.jp/~grobal/
メール　　[email protected]
　　　■グローバル探偵事務所　

>>119
あなた、電波っぽいですね。
板違いです。

filesystemと各文字コード変換機能ついた文字列クラスください。
あと、文字を間単にキャストしたり、パースできたり、
正規表現で検索できて、ランダムアクセスで特定の行の先頭の文字にアクセスできたら上等です。

boost:filesystem:::pathとか

おとといぐらいに出たSambaのセキュリティーホールの原因を見るにつけ、
文字列クラスっぽいのはCでも使ったほうがいいのかねえ。

>>131
boost::string とかつくって
そんなかに
boost::pathとか boost::regex とかがはいっていて欲しいの。

>>130
ICUとBoost混ぜ合わせて
自分でラップクラスでも作れば

>>134
自分で作ったら汎用性にかけるじゃないか！！

（＾＾）

>>129
どう電波なの？

http://homepage.mac.com/ayaya16/

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

で、結局皆は文字列何使ってんの?

char *

>>1よ、C++で新しい文字列クラスをつくるのはいいが、未踏ソフトウエア創造事業に応募してはどうだ？
採用されれば、何千万円もの開発資金を援助してもらえるよ。
もちろん定期的に進行具合をPM（プロジェクトマネージャー）に見せなければならないなどの、面倒くさい点は山ほどあるがね…
だが、それだけあれば、会社なんかやめて、毎日寝てくらせるぞ！！
PMにはアラン・ケイや伊地知をはじめ、いろんな大学教授や企業の研究者などがいる。
またPMは好きなやつを選んで応募できるから、気の合いそうなやつを選ぶといいよ。
これからは、個人でソフトを開発するなら、未踏ソフトウエア創造事業の時代だと思うが、どうよ？

>>140

自作バイト列処理クラス。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

>>140
OreLib::CString<OreLib::CShiftJISEncoding>

誰もやる気ないわけねｗ

test

日本語⇔英語
を自動的に翻訳できる文字列クラスがホスイ

http://www.i-seven.ne.jp/i7/i7SSWEB/service/impress/index_s.asp?code=8897&size=0&speed=0&sc_high=http://impress.tv/im/ondemand/imstv040211ps.asx&sc_middle=http://impress.tv/im/ondemand/imstv040211pb.asx&sc_low=http://impress.tv/im/ondemand/imstv040211p.asx

http://impress.tv/im/ondemand/imstv040211p.asx

　

TStringListみたいなクラスはないのですか？

作ってみだで

ystring 幼女に関連する文字列を入れないとフリーズさせる
mstring 萌えない〃文字列を入れないと処理速度が低下する

fstream使いにくい

どこが?

正直std::stringは危なっかしくて使ってられない．

えー

利便性を図るならライブラリ間で内部エンコーディングの統一と入出力レイヤーでの透過的な変換がほしいところだ。
javaもperlもそういう流れ。

しかし内部エンコーディングを統一するわけにいかないのがCとC++の宿命だからな。
文字について最小限の仮定しか持たないライブラリがほとんどだ。
当然正規表現も何もかも内部エンコーディング別に作り直し。

いや、悪いとはいわんよ。用途によっては必要なことだからな。

>161
>利便性を図るならライブラリ間で内部エンコーディングの統一と入出力レイヤーでの透過的な変換がほしいところだ。
この部分が分かりにくいのですが，分かりやすく説明してもらえませんか？

内部エンコーディングの統一 てのは、
異なるライブラリ間で同じ文字エンコーディングを使うという意味で書いた。
いくつかのライブラリ使う時にそれぞれの文字コードまで考えるの面倒じゃん。

入出力レイヤーでの透過的な変換 てのは、
たとえばあるマイナーな文字コードで書かれたテキストよんでパースするとしようや。
java だと FileInputStream + InputStreamReader + StreamTokenizer(または似た何か) で 構文の手前まで読めるよな。
perl5.8だと3引数openで文字コード指定したら読む側はutf8でふつーに正規表現使えるよな。
どっちもパースする部分で文字コードを意識する必要はない。


このスレで議論してる文字列って、文字の定義が汎用的すぎて上記のような利便性は提供していない。
いや、悪いとはいわんよ。用途によってはそれが正しいんだからな。

>>163
ありがとうございました．
なるほど，確かにそのあたりはjavaやperlがうらやましく思います．

オリジナルの文字列クラス作ったことある。
だけど、n次元配列に改造すると、途端に弱くなるので2度ほど挫折した記憶が…

我ながらスレストに関しては天才的だと思う。とほほ…

Cの標準化委員会は、
Unicodeに向いた新しい文字型を新設する方向だとか。
C99さえまだ普及してないので見送られたらしいが。

そこでMStringのC++版ですよ。

ごめんM-textだった。

class MonaString {
public:
  MonaString(const MonaString& str);
  MonaString(const wchar_t *str = L"");
  MonaString(wchar_t c);
  MonaString(const char *str);
  MonaString(char c);
  MonaString(const std::string& str);
  MonaString(const std::wstring& str);
  MonaString(unsigned int BufSize);
  virtual ~MonaString();

  MonaString& operator= (const MonaString& str);
  MonaString& operator+= (const MonaString& str);
  MonaString operator+ (const MonaString& str) const;
  bool operator== (const MonaString& str) const;
  bool operator!= (const MonaString& str) const {return !(*this == str);}
上5つはwchar_t* char* char wchar版も作る

  bool operator! () const;
  wchar_t operator[] (unsigned int n) const;
  operator const wchar_t * () const;
  operator const char * () const;

MonaString operator- (const MonaString& str) const;
MonaString operator* (const MonaString& str) const;
MonaString operator/ (const MonaString& str) const;

MonaString operator * (unsigned multi) const; // 文字列をmulti回繰り返す

MonaString operator << (unsigned n) const; // 文字列の左側 n 個を除去
MonaString operator >> (unsigned n) const; // 文字列の右側 n 個を除去
MonaString operator & (const MonaString& str) const {return *this + str;} //VB風

>>173&172
operatorのそういう使い方は混乱しませんか？

>>171
意図がよめない。

動的に内部バッファの長さがかわるんですよね？
一本にするとときってやっぱ一本分は確保しないといけないのかなー。
これって対したことないことなんだろうか。

>>171-173って半分冗談じゃないの？

そういえば、

STR01 <<= 3;

とか書くことで、左端の3文字を削除するとかいう文字列クラスを見たことがある。

だからなんあんだ

bool operator >= (const MonaString& str) const;
bool operator > (const MonaString& str) const;
bool operator <= (const MonaString& str) const;
bool operator < (const MonaString& str) const;
unsigned int find(wchar_t c) const;
unsigned int find(const MonaString& str) const;
unsigned int find(const wchar_t *str) const;
unsigned int find(const char *str) const;

unsigned int GetLength();
int ToInt();
double ToDouble();

uzeeeeee

#include <iostream>
#include <string>

struct Nurupo
{
void ga() { std::cout << "ｶﾞｯ"; }
};

class MonaString
{
std::string _str;
public:
MonaString( const char* str ) : _str( str )
{
if ( _str.find( "ぬるぽ" ) != std::string::npos ) throw Nurupo();
}
};

int main()
{
try { MonaString s( "いろはにほへとちりぬるぽ" ); }
catch( Nurupo& e ) { e.ga(); }
return 0;
}

xFind(char *str);
正規表現検索

char *で十分

xって何の略？
せめてrじゃないの？

>>184
regular expressionでxなのでは?

>>184
ｽﾏｿ
正規表現って英語でなんて書くのか知らなかったから適当です。

>>182
文字列ってのは文字のストリームなわけじゃん？
文字のストアやロードに関するメソッドを内在させるのは分かるけど
正規表現検索なんかは外部に持たせて文字列クラスにはそこへの口を持たすってのが
C++的だとおもうぜ
stringstreamがもすこし使いやすいといいんだけどな

UNICODEやマルチバイトをサポートしてないコンパイラやOSでも
日本語が使える文字列クラスってないでしょうか？

>>188
対応していなくても普通、charに文字列を入れることは可能だと思う。
シフトJISなら「表」みたいに2バイト目がバックスラッシュになる文字に気をつけなきゃいけないけど。

関連するメソッドをすべてUTFとかに対応しないと意味ないし

>>188
http://oss.software.ibm.com/icu/
のC++用のやつ

>>170
charへのキャストがあるから、MonaStringを引数を取るやつは要らないような。

車輪の再開発無駄無駄無駄無駄無駄ァ!!

今でもより性能の良いタイヤやホイールの開発/研究が日々続いているのね
つまり194はアフォ

自明のことをageてまで書き込む195もアフォ

全人類が194みたいな人間なら
アルミマグネシウムホイール、いやゴムタイヤすらこの世に無いだろうな

それは車輪の再開発というより、車輪の改良ではないだろうか。

車輪の再開発って国語辞典なんかには載ってないけどどこから出てきた言葉なの？

>>199
なんで先ずググろうとしないのか教えてくれよ

「車輪の再発明」じゃないのか？

どっちでもいいんじゃないか？

>>200
そういうセリフはググって答えがでるか確認してからのほうがいいと思うよ

車輪の再発明の意義を分からんやつは所詮土方プログラマ
まあそんなやつもいるからコストが低くおさまるわけだが

というわけでコスト削減のために
どんどんバカな発言をしてくらはい

結局アレだろ
ゴッホやピカソとそこらの漫画家が生きてる間にどちらが多く稼げるか、みたいな

>>203
出るけど？　何でそんな低脳なの？

あほかそれなら質問なんていらんだろ

検索の仕方も知らないアフォは市ねと言ってるんだろ

知らんやつなんていねえよぼけ

「検索の仕方も知らない」の意味もわからない奴は(ry

おまえだけだ

必死だな

ICUでインテリセンス使えてる？

標準クラスライブラリが貧弱なために
みんながみんな車輪の再発明をする罠

stringに関しては十分な機能を持ったstd::stringがあるわけで、
自分でstringを作るのはそうせざるを得ない理由があるからでしょう。

# UNICODEをサポートしてないから糞とか言ってる人は国際化を
# 勉強しましょうね。

（自分にとって、または作成するプログラムにとって）不必要な機能は豊富なくせに、
必要な機能がなく、少なく、貧弱なことはよくあるから。

とりあえず必要最低限だけあれば十分。
operator+
operator+=
operator=
operator== と operator!= (不等号はいらない)
operator const char * と operator const wchar_t *
あとは文字列長を返すメンバ関数とoperator[]はあってもいいけど、
それ以外は全て不要。

メンバ関数にscanfとか

printfも

＞# UNICODEをサポートしてないから糞とか言ってる人
普通にプログラミングしてて、そんな感想持つヤツは居るのか？

効率重視の為に char* や wchar_t* が有るのは分かるんだけど
std::string はどうにも使いにくい気がしてならない。
標準に取り入れるなら、もっと抽象的な概念をサポートして欲しかった。

>>215
>UNICODEをサポートしてないから糞
何でそんな感想を持つんだ。
UNICODEを使う場合はstd::wstringだろ。

>>221
std::string←→std::wstringの変換方法が用意されていないからとかじゃないのか？

>>222
$(LIBSTDC++)/docs/html/22_locale/codecvt.html
$(LIBSTDC++)/testsuite/performance/wchar_t_in.cc

>>221
CSI...

>>217
>operator const char * と operator const wchar_t *
この両者を保有するってことは、変換器を設定するメンバ関数も必要だなもし
operatorにする是非はとりあえず保留

まずunicodeに統一するのが先
ついでに半角全角も撤廃で

Unicodeに半角カナあるんだがなぁ……

SJISで作って、後で、Unicode変換入出力機能も加える方向で作るっていうのは？
とりあえずWindows優先すれば試験できる人も多い訳だし…

>>227
有るから無くすんだべ

>>228
その時代はもうすでに終わったのでは?
・基本をUnicodeで作って、日本の文字だけ対処。
・完全無欠のCSI
・完全無欠のUnicode実装
の時代では?

やはりテンプレートはどうだ。
template<typename T> class xStringBase
{
public:
　StringBase();
　StringBase(T*);
　~xStringBase();
　xString operator +(T*) const;
　xString& operator +=(T*);
　xString& operator =(T*);
　bool operator ==(T*) const;
　bool operator !=(T* Str) const {return !(*this == Str);}
　operator T*();
　virtual char *ToChar() const = 0;
　virtual wchar_t *ToWChar() const = 0;
};
class xStringA : public xStringBase<char>;
class xStringW : public xStringBase<wchar_t>;
//実際にはToCharとToWCharを書く。

>>230
使ってるんだよ！こっちはｗ
ところでCSIって？

とりあえず作ってみた。

C2char（class 2ch charをもじった）
ttp://up.isp.2ch.net/up/faad1f3043eb.lzh

とりあえず基本はおさえたが、マジでテストしてないので使用する時はデバッグを行うように！（コンパイル通しただけ）
恐ろしいバグが発生しても漏れのせいにしないように！ｗ

まあ、バグを報告してくれれば直しますし、要望があれば受けられるだけ受けますが…
今日はこれくらいにします。

>>233
IsDBCSLeadByteはif(((unsigned char)((x ^ 0x20) - 0xA1) <= 0x3B))の方が早いみたい。
そして直接return TRUE; else return FALSEでいいんじゃないか？
それ以前に今の状態だとメンバ関数にする意味がないような。

operator=と+=がreturn *this;としてC2char&を返してくれればoperator +はこれでいけると思うんだけどな。
C2char operator +(const C2char &s1, const char *s2)
{
　return (C2char() = s1) += s2; //更にコピーコンストラクタがあればC2char(s1) += s2
}
C2char operator +(cconst char *s1, const C2char &s2)
{
　return (C2char() = s1) += s2;
}

うう、いかにもC上がりの(もしくはその影響を受けた)VC使いらしい実装だなぁ。
クラス同士の代入、比較辺りのOperator関数がないし、LPCSTRじゃなくてLPSTRだし。
その癖LPSTRへのCastOperatorがないし。
メモリ確保できなかったときの対策が不充分だし、確保したら毎回クリアして回るし。
うーん、EffectiveC++くらい読んでみたら?

>>28
+演算子しか使わないのに、全ての演算子を定義する気?
Java厨じゃないんだから。

>>234
出口（return）は1箇所ににしたかった。

＞メンバ関数にする意味がないような
あれ？Windows.h系をインクルードしないと駄目なんじゃなかったっけ？（試してないけど）

すまんね。コピーコンストラクタとグローバルなoperator、あんま使って無かったんで忘れてた。

>>235
そのあたりは、CStringのヘルプみた。と言うか、まずCStringをなるべくマネたんでそうなった。
クラス同士の代入は通常の = で通らない？
LPSTRへのCastOperatorが無いのは直接メモリを（なるべく）変更しないようにするためと
勝手に解放できないようにするため。（他にｲｲ方法ありませんか？）

＞メモリ確保できなかったときの対策が不充分
ではどうする？

＞確保したら毎回クリアして回るし。
しない方がｲｲの？＞初期化

>>237
＞クラス同士の代入は通常の = で通らない？

C2char内のoperator=の事ね。

＞メモリ確保できなかったときの対策が不充分

すまん、良く見たら NULL 判定してなかった…＿|￣|○
毎回毎回判定してたのになんで今回忘れたんだろ…鬱だ。

>>237
＞あれ？Windows.h系をインクルードしないと駄目なんじゃなかったっけ？
そうだけどそれ言っちゃこっちもC2char.hのインクルードが必要って話になるだけ。
それに、自身のバッファのN文字目がLeadByteか調べるとかならともかく、そうでないならクラスから外すかstaticメンバにしてくれ。
size_t GetLength( LPSTR pcBuffer, size_t unMaxLen );もメンバにする意味なし。(クラスから外すか、staticでも問題ない)

あと、なんでもかんでもvirtual付けるよりconst(やLP(T)CSTR)を付けられないか考える方が先だよ。

>>234
operator=と+=がC2char&を返してもC2char operator +(cconst char *s1, const C2char &s2)が
コンパイル通らなかった…ﾅﾝﾃﾞ？？

cconstとかいってみる

>>242
あ、いやソースへのコピペはしてないから。
+= class C2char の右オペランド（だっけ？）を扱う2項演算子がない…みたいなこと言われた。
一応あの後、帰り値が C2char の C2char += C2char をクラス内に入れたんだが、それでも駄目だった。

とりあえず、今日のところまで

ttp://up.isp.2ch.net/up/a0296353d7e1.lzh

>>241
まさかとは思うが、メンバ関数にしてないよな>>241

>>245
さすがに、サンプルの >>234 に C2char:: が入ってなかったしね。
それに C2char.h の class 定義の下の方に追加しようとした跡があるだろ？

もっとアフォな間違いやってそうですが…＿|￣|○

こんな風に追加したんだが…コンパイル通らない。
リンクで駄目ならcppに移そうとしたんだがね。
>>234 そのまんま。

ttp://up.isp.2ch.net/up/06c1994fa74c.lzh

>>243
それは出なかった（operator+=(const C2char &ob2)をコメントアウトしても）けど代わりにこんなエラーが。
エラー E2015 test.cpp 5: 'operator +(const C2char &,const char *)' と 'operator +(const char *,const C2char &)' の区別が曖昧(関数 main() )

これはinline C2char operator +(const C2char &s1, const C2char &s2)を作れば平気だった。(中身は他のoperator +と同じ)

あとoperator == が等しいなら0を返すってのはまずい。普通の==の結果は等しかったら1、等しくなかったら0だから、そのノリで使えるようにしてくれ。
例えば、今のoperator ==をCompareってただのメンバ関数にしてクラスの外で新しく作り直すとかさ。
inline bool operator !=(const C2char& s1, LPCSTR s2)
{
　return (bool)s1.Compare(str);
}

inline bool operator ==(const C2char& s1, LPCSTR s2)
{
　return !(s1 != s2);
}

>>247
operator+は(248の(const C2char&, const C2char &)含めて)3種類あるけど全てreturn C2char( ob1 ) += ob2; でいい。

今はLPSTRがバッファの型だからoperator LPC"T"STRはまずくないか？

こーなった。
ttp://up.isp.2ch.net/up/a75b714bb11c.lzh

>>248
ほぼ同じ物が出来た。
int -> bool だとワーニングがうるさいので、ifでかこったが。

>>249
＞return C2char( ob1 ) += ob2;
どうやら、const をクラス内部の二項演算子に付けなかったのが原因だったようです。
コンパイルＯＫで動きも
C2char = C2char + C2char;
で通る。が、operator+演算子でreturnで返した瞬間に、デストラクタが起動して先に全て解放してしまうので
C2char = で代入されるバッファの値は既に解放、ヌルポでした。
今回は消しました。

＞はLPSTRがバッファの型だからoperator LPC"T"STRはまずくないか？
CStringがそうなってたんでその形式になってました。
全て LPCSTR に直した。

>>250
＞int -> bool だとワーニングがうるさい
BCC使っているけどこっちはint -> boolをキャストなしでもwarningを全開にしても出ないもんで。

＞returnで返した瞬間に、デストラクタが起動
ちょと待て。その前にコピーコンストラクタが発動するだろ。

>>251
＞BCC使っているけどこっちはint -> boolをキャストなしでもwarningを全開にしても出ないもんで。
BCCでも通りましたか。コンパイル
気にしてたんだが。

＞ちょと待て。その前にコピーコンストラクタが発動するだろ。
すまん、どのコピーか分からなくなってきた…
一応追加した環境…
ttp://up.isp.2ch.net/up/1a1825aa2c05.lzh
間違ってたら指摘ヨロ…＿|￣|○
>>248 も考慮した。ただし、inline 付けると何故かリンクできないので inline だけ消したけど…

>>252
BCCでもC2Char.cpp自体のコンパイルは成功する。warningも出ない。

ところでorType.hだけど、これだとwindows.hとかをインクルードできないから、
C2Charで使っている型だけC2Char内に移してorType.hは外した方か、
あるいはnamespaceに閉じ込めてC2Char内でusing orType::LPSTR;を並べていくかしてほしい。

そう言えばさっきから2人だけ（248も俺）……。○|￣|＿

いや、私自身忙しいし、落ち着くのを待ったほうがよさそうだと思ってね。

>>253
orType.h の typedef はエラーが出るならどんどんコメント化していってくれ。
もともと、windows.h をインクルードしなかった時、代わりに typedef を行うヘッダーだから。
ちなみに、typdef.h（C2char.h） -> windows.h の順でインクルードすると、何もエラー無しでコンパイル通ったんだが…
VC++で確認。

＞BCCでもC2Char.cpp自体のコンパイルは成功する。warningも出ない。
確かにコンパイルは通るんだが
ch3 = ch1 + ch2;
で行うと、ch3 の値が不定になってる。

>>255
ch3 = ch1 + ch2; がうまく動かないのはoperator+=()の戻り値の型をC2charからC2char&にしたら解決した。
似たようなことがまた起きるかもしれないしopreator=()の戻り値の型もC2char&に修正しておいた方がいいと思う。

いい忘れていたけど249と同じ理由でTCHARもただのCHARに修正してほしい。

今のところ、BCCでこんな警告が出る。
警告 W8037 c2char.h 96: const オブジェクトに対して 非 const 関数 'C2char::Compare(const char *)' が呼ばれた(関数 operator !=(const C2char &,const char *) )
これは宣言にconstを付けてvirtual int Compare( LPCSTR ob2 ) const;にすれば消えた。

ttp://up.isp.2ch.net/up/9be58f11be48.lzh

>>256
＞いい忘れていたけど249と同じ理由でTCHARもただのCHARに修正してほしい。
これも、CStringのマネｗ
ｻｯｿｸ直しました。

＞これは宣言にconstを付けてvirtual int Compare( LPCSTR ob2 ) const;にすれば消えた。
とりあえず、問題無さそう（つーか GetLength() だけしか見てなかったので付け忘れた）でしたので、const付けました。

＞operator+=()の戻り値の型をC2charからC2char&にしたら解決した。
クラス内のもあわせて全てC2char&型に変更した。
が、結果は同じでした。ch3 はNULLポインターを差してます。＞「ch3 = ch1 + ch2;」
なんかデバッグでは「ch3 = ch1 + ch2;」の順を追うと

１．「ch1 + ch2」の C2char& operator+( const C2char &ob1, const C2char &ob2 );
が起動し、内部の C2char( ob1 ) のコピーコンストラクタ C2char( const C2char &ob2 ) が起動。
C2char( ob1 ) 変数（？）に ob1 の内容が入る。
（デバッグでみると C2char( ob1 ) 変数 ≠ ch3 です。）

２．C2char( ob1 ) 変数のクラス演算子 C2char& operator+=( const C2char &ob2 ); が起動し、
C2char( ob1 ) 変数に ch2 の内容が連結。

３．C2char( ob1 ) 変数のデストラクタが起動。全て解放。

４．ch3 ヌルポ。

ってなってました。
俺なんか間違えたのかな？？＿|￣|○

>>257
多分駄目なのは代入演算子。
ch3 = ch1 + ch2;
を
ch3 = ch1;
に変えてみてもぬるぽ。
コピーコンストラクタに頼るより operator = を新たに作った方が安心。

>>258
俺の場合ch3 = ch1;はなんともないけどch3 = ch2;は強制終了のダイアログが出る。
なんなんだ……。OTL

C2char& operator + ( ... )

これはまずいですね。この関数は内部でローカルなオブジェクトを生成して，
そのリファレンスを返していますが，そのオブジェクトは
関数を抜けた瞬間，残念ながら
c3 = c1 + c2;
c3 にコピーされる前に破棄されます。

C2char operator + ( ... )

にするべきです。

あまり重要な事ではありませんが，クラスの設計としては
MemberInitialize() を protected にすると良いです。
外部から任意で呼ばれると，メモリリークを起こしますから。

それから。。。派生を考えての事なのかな？
MemberInitialize を virtual にしているようですが，
"コンストラクト時に一度しか呼ばれてはならない" という性質上，
あまり意味は無いように思えます。
余分な関数テーブルを減らすためにも，
virtual にはしない方がより良くなるでしょう。

ch3 = ch1 + ch2;について。
いろいろ、やったが、何か解決すると複雑な処理が出来なくなる…
とりあえず operator+ は消して operator+= だけにした。

多分、operator+ だけだとどっかしらに動的メモリを取得してそれを代入する変数（C2char クラス）に
渡さないといけないと思う。
（代入する前に、デストラクタが発動してしまうため）

>>260
ch3 にコピーした後、コピー元がメモリリークおきません？
つーかどうやってバッファの解放を？？（いや、マジでわからん）

理想の動きといしては、ch1 と ch2 がその変数以外の C2char 変数にコピーされ
その内容が ch3 にコピー。
ch1 と ch2 からコピーした C2char の内容が破棄…

>>261
＞MemberInitialize() を protected にすると良いです。
確かに外部から呼ばれるとマズイですね。
protected に移動しました。

＞それから。。。派生を考えての事なのかな？
＞MemberInitialize を virtual にしているようですが，
一応考えてます。まあ、この関数名で共通化すれば良いかな？くらいに。
ま、でも改造（派生）させるとなると多分無駄に終わるでしょうｗ

>>234
＞IsDBCSLeadByteはif(((unsigned char)((x ^ 0x20) - 0xA1) <= 0x3B))の方が早いみたい。

すまん。テスト中にただの "i" 文字が先導バイトとして認識したので元に戻します。

ch3 = ch1 + ch2;について
出来た出来た。
今、テストでクラスのメンバーに入れてあるんで、グローバルにして問題無かったら、うｐします。

演算子追加。
ttp://up.isp.2ch.net/up/e8d272f5f481.lzh

operator +()の戻り値はC2charがいいけど、
operator +=()とかoperator =()はむしろC2char&の方がいいと思うが。

C2char str;
str += "nullpo"; // oops!

lpm_StrBuff が NULL の場合を考慮したコードが必要ですね。
430行目と476行目の memcpy の行で
if (lpm_StrBuff) memcpy( ...
としてはどうでしょう。

ほぼどうでもいい話ですが，482行目で，もし this == &ob2 である場合
this->lpm_StrBuff == ob2.lpm_StrBuff でもあります。
「清潔なコード」を心がけたいなら，memmove を使う事も
考えておいた方がよいでしょう。

なお，将来 std::string::c_str() のようなメソッドをつけた場合，
str += str.c_str() + 1;
を正常に行えるために，あまり小さくない改造が必要になるかも
知れません。覚悟しておくべきです。

おっと，まずいな。operator LPCSTR () があるんですね。
str += LPCTSTR(str) + n;
これでアクセス違反が発生します。
それから
C2char str = "nullpo";
str = str;
これもアクセス違反を起こしそう。

時間無いのでちょっとこれだけ。

>>268
＞430行目と476行目の memcpy の行で
一応、9行前のGetLength()で確認してるからこれで良いはず…

>>264
ちなみにここのNo. 3〜4に乗っているのを見つけたのだったけど、どういうときにそうなったのか気になるな。
http://homepage1.nifty.com/herumi/adv/adv40.html

>>271
一応質問投げておいた。
正しい答えが返ってきてくれると嬉しいんだが…

>>272
返事が来ている。
ようするに「signedでもunsignedでも常にifの中でキャストしろ」ということらしい。
if ((unsigned char)((TestChar ^ 0x20 ) - 0xA1) <= 0x3B)
試してみたけどそこを直すだけでうまくいった。

http://www.coara.or.jp/~tkuri/D/019.htm#D2002-10-27
ちなみにここのコードもcharのキャスト1つで結果が変わってくる例。

＞型キャスト，好きな時に適当に使ってればいいやと思っていたのですが，……
＞私はすっかり型キャストをナメていました。
まさにこれだ……。orz

>>273
書いた通り、今でもあんま理解できん。
つまり、( ) で計算された結果は自然数である32bit（通常int等）に置き返られるって事か？
んで、cast が必要…と？

>>274
(TestChar ^ 0x20) - 0xA1をした結果が負になっても、(これには全てIsDBCSLeadByteの結果としてはfalseになる文字しかない)
unsigned charへのキャストによって負数は0x5F〜0xFFになり、SJISの1byte目に当たる文字だけが0x3B以下になるってことのようだ。

233来ない……。

>>275
0x80-0xFFは符合拡張されて、
0xFFFFFF80-0xFFFFFFFFになるからね。
0x3Bは0x3Bのままなんだけど。
符合拡張抑止が(unsigned char)。

>>276
変換の修正だけじゃなくて新しい関数も加えてるのでお待ちを…

やっと出来ました。
http://up.isp.2ch.net/up/ab76303edef3.lzh

>>267
クラス内の演算子で、変更できるものは変更しました。

>>268
＞this == &ob2
今回の更新で全て考慮しました。
もし他にも考慮するべき所があったらお願いします。

>>269
すまん、ちょっと言ってる事が上半分くらい分からんっす。
>>268 で考慮したんでそれでＯＫか？
特に str = str とかの点を。

>>276
お待たせいたしました。m(_ _)m

>>275 >>277
説明どうもっす。ムズッ！
とりあえずこの計算に直した。

追加関数
ｺﾝｽﾄﾗｸﾀの追加文字数指定版
GetSJIS
Insert
Mid

　 -‐　　 '''ｰ
　 ‐ｰ　 くー
´ﾟ　 ,ｒ "_,,>､ >>233さんお元気？
　 ト‐＝‐ｧ'
　 ` ｀二´'

>>281
まあ、ボチボチってとこだな。
そっちはどうよ？

FreewareのBCC FORMのBCC SkeltonのCSTR.hはどうよ？

>>233 再うｐきぼんぬ

>>283

CSTR::FromFileの一部
> delete [] m_str;　　　　　　　　　　//元の文字列を廃棄して
> m_str = new char[dwFileSize];　//読み込んだデータを入れられるようにする
> DWORD dwRead;
> if(ReadFile(hFile, m_str, dwFileSize, &dwRead, NULL)) {
> 　　m_str[dwFileSize] = 0; 　　　//ファイルの終端にNULLを置く
> 　　bSuccess = TRUE;　　　　　//読み込み成功
> }
成功していないってば

> //コンストラクター（整数）
> CSTR::CSTR(const long i) {
>
> 　　char sbuff[MAX_PATH / 8];
> 　　wsprintf(sbuff, "%d", i);
> 　　m_str = new char[lstrlen(sbuff) + 1];
> 　　strcpy(m_str, sbuff);
> }
MAX_PATH / 8の根拠はどこから？

MAX_PATHは80だっけ? それならMAX_PATH / 8 は10。
intの最大桁数は11桁なので、あぼん確定。
つーか、MAX_PATH依存にする辺りｵ�hﾉﾚ。

Win32では260くらいだったと思う＞MAX_PATH

時間があまり無かったんで、>>279 時とまったく同じ状態。

http://up.isp.2ch.net/up/5a8fb5cd4a33.lzh

>>288
クラス C2char ね。書き忘れた。
それから >>284 へのレスね。失礼しやした。

>>233 頂きました。　ありがとうございました。

http://www.geocities.co.jp/SiliconValley-PaloAlto/3388/wstring/README.ja.html
これは？

整数型のバッファはsizeof(T) * 4で十分

>>291
>WRegexp.last_matchはグローバルなので、スレッド間で共有されてしまいます。
この時点で話にならないぽ

>>293
どゆこと？

operator[]がchar&を返したら、って考えたけど、そしたら合法的にchar*(非const)が入手できるようになるからあんまり良くないな。

C++使えると豪語する奴=本当はCしかできない低脳
http://pc5.2ch.net/test/read.cgi/prog/1094445966/

ちょろっと改造。
ttp://up.isp.2ch.net/up/29599d59fd02.lzh
C2char

使ってて気になるところを直した。
・バッファ容量を直接指定出来るようにした。
・SJISの文字を取得出来るようにした。

とりあえず
int unStrSize = cl_str1.StrLen();

if( ( unStrSize >= 1 ) && ( cl_str1.GetSJIS( unStrSize - 1 ) != '\\' ) )
{
cl_str1 += "\\";
}
こんな感じにファイルのパスで使うような事も出来るようにした。

age

中身を見ずに目新しいからといって、それだけで否定している奴っているよな

　　　　　　　　　　　　　　　　　　　　　　　　 ,----、
　　　　　　　　　　　　　　　　　　　　　　　／　／＾ヽヽ
　　　　　　　　　　　　　　　　　　＿＿＿/ .　/　　　| |ヽ＿＿
　　　　　　　　　　　　　　　　　∩　＿_　ヽ＜(。)ヽ |..|.<ヽ＿ |
　　　　　　　　　　　　　　　　　.Ｕ＿￣　　　ヽ　　　| |　 .|＿_.|　　　　
　　　　　　　　　　　　　　　　　　　　｀---,l　 ヽ　　.|/　./
　　　　　　　　　　　　　　　　　　　　　　ヽ　　　＼____／
　　　　　　　　　　　　　　　　　　　　　　/　／＼　　./
　　　　　　　　　　　　　　　　　　　　　 /／　| / ｀、/　　
　　　　　　　　　　　　　　　　　　　　　　￣~ |/　　　|
　　　　　　　　　　　　　　　　　　　　　　/⌒/　　／⌒＼
　　　　　　　　　　　　　　　　　＿／⌒/ （/___／/ 　´￣￣￣＼
　　　　　　　　　　　　　,--´￣　/　　　＿＿＿　　　　　　　　　 ＼
唯一神デオキシス様が華麗に>>300get!!皆の者俺の前にひれふせい！
デオキシスは神!!ノーマルフォルムは「攻守のバランスが取れている」!!DEOKISHISU is god!! DEOKISHISU　is god!!
＞ファイヤー　　　消防や厨房にまで使われない雑魚は引っ込んでな(ﾌﾟ
＞サンダー　　　　どんなに貴様がすばやくても俺を追い越すことは不可能だ!!(ﾌﾟﾌﾟﾌﾟ
＞フリーザー　　　一撃必中？心の目使った後逃げられなければな(ﾜﾗ
＞エンテイ　　　　おまえ伝説だったっけ？弱すぎてしらなかった（ｗ
＞スイクン　　　　強さもかっこよさも俺には勝てないってこった(ｹﾞﾗ
＞ライコウ　　　　お前は影が薄いんだよ(ﾌﾟｹﾞﾗ
＞レックウザ　　　レゴブロックがホウエン最強なんてこの世も末だな(ﾌﾟｹﾞﾗｯﾁｮ
＞ラティ兄妹　　　バトルタワーでﾜﾗﾜﾗ出てきてどこが伝説だ？(藁
＞レジ兄弟　　　　伝説でもない壷に負けてるし(ﾋﾟｯ
＞ミュウツー　　　フリーザのパクリは消えな(＾＾
＞ホウオウ　　　　攻撃高くても物理攻撃少ないじゃねーか(ｹﾞﾗｹﾞﾗ
＞ルギア　　　　　エアロブラスト以外はたいした技ないな(ﾌﾟｹﾞﾗｵﾌﾟｽ
悪タイプ様ツボツボ様テッカニン様カイオーガ様
すいません調子こいてました許してくださいおながいします

　　　　　　 　　　 ...,､ -　 ､
　　　　　　,､ '　 ヾ　、　 　 丶,､ -､
　　　　 ／　　　　ヽ　ヽ　　＼＼:::::ゝ
　／ヽ/　　　i　 i　　　　ヽ　.__.ヽ ヽ::::ヽ
　ヽ:::::l　i.　　l　 ﾄ　　ヽ　 ヽ .___..ヽ　丶::ゝ
　r:::::ｲ/ l　　l.　 i ヽ　　＼　＼/ﾉﾉﾊ　 ヽ
　l:/ /l　l.　　l　　i　 ヽ'"´__ヽ_ヽﾘ }. ',　　',
　'l. i　ト l　　ﾚ'__　　　　'"i:::::iﾞ〉l^ヾ　 |.i.　l
.　l l　lミ l ／r'!:::ヽ　　　　'‐┘ .}　/　 i l　l　　／￣￣￣￣￣￣￣
　 l l　l.ヾlヽ ゝヾ:ﾉ　　 ,　　　　 !'" 　　i i/ i＜　　お呼びですか？
　 iﾊ　l　 (.´ヽ　　　　　_　　 .／　　　 ,' ,'　'　 |　　 ・・・・・
　　 |l. l　　｀ ''丶　　.. __　 イ　　　　　　　　　 ＼＿＿＿＿＿＿＿
　　　ヾ!　　　　　　　 l.　　 ├ｧ ､
　　　　　　　　　　／ﾉ!　　　/　　｀　‐- 、
　　　　　　　　 ／ ヾ_　　　/　　　　 ,,;'' /:i
　　　　　　　 /,,　　',. ｀　 /　　　　,,;'''／:.:.i

再うｐきぼん

ag

ほんぎゅろげーー！！

最新のmetaprogrammingの本でもunstrungとかぼろかすに言われてるな

metaprogramming本じゃなくてExceptional C++ Styleの間違いじゃ・・・

meta の本だと良くない例として軽く話題になった程度。

stringを擁護してどうする

今更だけど、文字をcharで持っているのならならoperator const char *()、
wchar_tで持っているのならoperator const wchar_t *()って言い忘れていた。

鬱(ry

文字コード相互変換できるクラス希望

>>310
ICUじゃだめか？

あくまで用途は文字列クラスだから
普通に使う分には高速に動作して、出力するときだけ変換されるようにして
ICUはクラスじゃなくてライブラリ

単一のクラスで実現しろって事？キツくね？

実際のところ、C++ならrefcountも、copy-on-writeもいらんね。
同期オブジェクトのメモリと、同期のコストを消費するよりも、
素直にコピーした方がまし。
仮引数はconst参照で済むし。
アロケータを細工して、メモリ取得・開放のコストを下げるのは重要だと思うけど。

>>313
キツイって言うか、変換テーブルだけで莫大になりそうな気が…

ttp://www.codeguru.com/Cpp/Cpp/string/alts/article.php/c2777/

じゃ駄目？

tests

つ http://www.tietew.jp/cppll/archive/12285

保守上げ

でっかい文字列用には、SGIのropeがあるって誰か指摘した？

ttp://www.kmonos.net/wlog/39.php
に詳しい解説あるよ。

なるほど、stringよりもぶっとくropeということか。

C++文字列クラスってコンパイラ間で互換性ないから
結局charTポインタにしないといけないのが矢田

（　ﾟдﾟ）ﾎﾟｶｰﾝ