トップページ⇒tech
259コメント71KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2006/12/26(火) 20:24:15
CString , string , wstringに負けないものをみんなで作ろうね。

前スレ: http://pc8.2ch.net/test/read.cgi/tech/1044098312/
0002デフォルトの名無しさん2006/12/26(火) 20:25:17
CFString
0003デフォルトの名無しさん2006/12/26(火) 20:25:17
>>1
おお、いいスレが立ったな。乙！
0004デフォルトの名無しさん2006/12/26(火) 20:30:13
こんなスレが欲しかった
>>1乙
0005デフォルトの名無しさん2006/12/26(火) 20:30:50
Stringでどうよ？
0006デフォルトの名無しさん2006/12/26(火) 20:33:40
でもそれ.NETがなきゃ動かんじゃん
0007デフォルトの名無しさん2006/12/26(火) 20:34:47
>>3
>>4
自演乙（藁
そして終了（禿藁
0008デフォルトの名無しさん2006/12/26(火) 20:36:20
>>1はどうでもいいから前スレで挙がってたC2charうｐきぼん
0009デフォルトの名無しさん2006/12/26(火) 20:41:06
>>8 =>>1な罠（藁
0010デフォルトの名無しさん2006/12/26(火) 20:45:25
　　　　　　∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′ ￣￣( ﾟДﾟ)＜ >>1は早急に逝ってよしだｺﾞﾙｧ!!
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
001112006/12/26(火) 20:58:01
伸びないなぁ。
>>8も俺からもきぼん！
001212006/12/26(火) 20:59:49
仕方ない
俺が作った（まだ発展途上だけど）かなり便利な文字列クラスをあげるか
それをみんなで改造しよう！！１１
001312006/12/26(火) 21:07:07
上げました。
http://tune.ache-bang.com/~vg/outitem/up/img/12431.txt
001412006/12/26(火) 21:09:52
>>13←なんとこれ作るのに丸一日かかりました!疲れた...
0015デフォルトの名無しさん2006/12/26(火) 21:11:32
String使えよ。
001612006/12/26(火) 21:13:40
アドレス間違えました
http://tune.ache-bang.com/~vg/outitem/up/img/12432.txt
0017デフォルトの名無しさん2006/12/26(火) 21:14:01
String使えよ。
0018デフォルトの名無しさん2006/12/26(火) 21:15:16
>>17
>>6
0019デフォルトの名無しさん2006/12/26(火) 21:18:16
>>１8
.net使えばいいだろ。
0020デフォルトの名無しさん2006/12/26(火) 21:20:47
基本的にstd::stringとstd::stringstreamでできるなー。
それを交えて作り直してみたらコードかなり圧縮できるとおもう。

あと、>>1のクラスのformatメソッドがやばいと思う。
0021デフォルトの名無しさん2006/12/26(火) 21:22:35
NSStringをC++でラップしたら強いのが出来そうじゃね？
0022デフォルトの名無しさん2006/12/26(火) 21:24:01
>>16
丸一日掛かってこれかよ（ﾌﾟ
0023デフォルトの名無しさん2006/12/26(火) 21:27:10
前スレはdat逝きか
makimo.toにも無かった
0024デフォルトの名無しさん2006/12/26(火) 21:32:47
vsprintfはwvsprintf使うべき
0025デフォルトの名無しさん2006/12/26(火) 21:36:15
STLのstringは、マルチバイト文字をまともに扱えるの?
0026デフォルトの名無しさん2006/12/26(火) 21:37:59
>>25
あれは基本的にコンテナなんだと思うけど。
0027デフォルトの名無しさん2006/12/26(火) 21:40:37
みんなwstring使えば解決
なんでみんなUNICODE使おうとしないのか
0028デフォルトの名無しさん2006/12/26(火) 21:42:54
wvsprintfってウインドウズ？
0029デフォルトの名無しさん2006/12/26(火) 21:59:36
さようなら>>1の人。
0030デフォルトの名無しさん2006/12/26(火) 22:02:44
D言語マンセー
0031デフォルトの名無しさん2006/12/26(火) 22:13:42
D言語もまともなstringがない。
main（char[　][　]）だもんな。。。
0032デフォルトの名無しさん2006/12/26(火) 22:53:25
>>31
つ std.string/std.conv
"test".toupper()とか"12".toInt()とか可能。
0033デフォルトの名無しさん2006/12/27(水) 00:59:26
つ ttp://tricklib.com/cxx/dagger/xstring.h
0034デフォルトの名無しさん2006/12/27(水) 01:21:32
最強の文字列クラスを作るスレ
とかの方がよかったんじゃないか
0035デフォルトの名無しさん2006/12/27(水) 17:55:20
>>21
CFString
003612007/01/31(水) 00:29:04
まだあったんだコノスレ(
0037デフォルトの名無しさん2007/01/31(水) 04:24:08
AnsiStringは放置ですか。そうですか。
0038デフォルトの名無しさん2007/03/05(月) 01:01:54
>>1
まずCString, string, wstringには現状どのような問題点があるのか？
それを明らかにして、そこをよりよくしたものにするという風にするのが手っ取り早いと思う。
真面目にやる気があるのなら。
0039デフォルトの名無しさん2007/03/05(月) 02:10:19
string: マルチバイト脂肪
wstring: サロゲートペア脂肪
CString: 脂肪の塊
0040デフォルトの名無しさん2007/05/14(月) 00:36:49
basic_string<uint64_t>使えば？
0041デフォルトの名無しさん2007/06/25(月) 12:18:03
万能ナイフを作るな!
というのは文字列クラスにも言えると思う。

自作の文字列クラスは、constな文字列用だけでも、いくつもあるよ。
0042デフォルトの名無しさん2007/06/27(水) 21:12:23
俺は逆だな
大体std::basic_string<>で済ませる

まあたまにATL::CStringT<>、ATL::CComBSTR、_bstr_tも使うが
0043デフォルトの名無しさん2007/06/27(水) 21:49:05
>>42
うしろ2つは文字列クラスというよりは、MSのCOMのためのものだろう。

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

なんでUTF-8にしないんだろう？
0045デフォルトの名無しさん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。
0046デフォルトの名無しさん2007/06/28(木) 19:32:10
>>45
ああ、その時代のことは知っていたんだが、
UTF-16と決まってるわけじゃないことは知らなかった。サンクス
GCCはUTF-32なのか・・・

でも後発の.NETまでcharが１６ビットなのは、やっぱり内部でUTF-8をそのまま使うのは
あまり都合がよくないからなんだろうか・・・
0047デフォルトの名無しさん2007/06/28(木) 21:13:22
>>46
仮に、日本語しか考えない場合、
UTF-8は、マルチバイトと同じく、
扱いにくいのですよ。

.NETのUnicode文字列が16ビットなのは、
WindowsのCスタイルのAPIや、
COMのUnicode文字列が16ビットだから。
0048デフォルトの名無しさん2007/07/06(金) 05:47:29
std::string って std::vector<char> を継承しているのかとか
勝手に思ってたけどそうじゃないんだね。

std::string って \0 （ヌル文字）を途中に挟んだような
文字列でも扱える？
0049デフォルトの名無しさん2007/07/07(土) 18:04:46
>>48
STLのリファレンス読めばわかることを、なぜ聞くのだ。
0050デフォルトの名無しさん2007/07/07(土) 19:06:00
読むより聞いた方が速いからじゃないの？
他に理由は浮かばないなあ
0051デフォルトの名無しさん2007/07/07(土) 19:38:50
>>48
途中にヌル文字があろうと扱えるはず。
また、std::basic_stringがstd::vectorを包含している実装は考えられる。
0052デフォルトの名無しさん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分でわかることなのに。
0053デフォルトの名無しさん2007/07/08(日) 12:40:37
じゃあ、リファレンス見るより聞いた方が楽だからじゃないの？
さすがに他に理由は浮かばないなあ
0054デフォルトの名無しさん2007/07/08(日) 13:55:08
>>52
聞いた時点では３分でわかる可能性もあったんだよ。

競馬場とかに行くと、そういう自分に都合の言い夢見てる人っていっぱいいるよ。
0055デフォルトの名無しさん2007/07/08(日) 14:15:19
まあ３分で分かるかもしれない可能性を信じて質問する奴の将来なんてたかが知れてるわな
0056デフォルトの名無しさん2007/07/08(日) 14:41:16
投機実行かもしれないけどね (w
0057デフォルトの名無しさん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; }
0058デフォルトの名無しさん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); }
0059デフォルトの名無しさん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; }
};
0060デフォルトの名無しさん2007/07/30(月) 18:54:51
スケルトンにつかってくだせぇ
0061デフォルトの名無しさん2007/07/31(火) 10:43:44
んなBorlandローカルなものをどうしろと。
0062デフォルトの名無しさん2007/08/01(水) 02:38:29
俺にはVCローカルに見えるが・・・。

0063デフォルトの名無しさん2007/08/01(水) 05:09:19
＞__declspec(property(get=Memory,put=Copy)) char* str;
これってどっち?
0064デフォルトの名無しさん2007/08/01(水) 11:53:21
少なくともVC++には存在する。
http://msdn2.microsoft.com/en-us/library/yhfk0thd(VS.80).aspx

COM対応の#importしたときにインタフェースのプロパティで使われている。
0065デフォルトの名無しさん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>も不要。
0066デフォルトの名無しさん2007/08/01(水) 16:09:33
__declspec(property....
はBCCもVCも使えると思うんだが
0067デフォルトの名無しさん2007/08/01(水) 22:52:57
どっちもつかわないからどっちでもいいよ。
0068デフォルトの名無しさん2007/08/02(木) 18:38:07
でっていう
0069デフォルトの名無しさん2007/08/03(金) 06:13:48
汎用的な文字列クラスを作るよりは、
用途別に文字列クラスを作ったほうがいいと思う。

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

0070デフォルトの名無しさん2007/08/03(金) 07:35:38
>>69
それのどこにどんなメリットが?
0071デフォルトの名無しさん2007/08/03(金) 08:15:31
>>70
わからない人には必要のないものです。
0072デフォルトの名無しさん2007/08/03(金) 10:48:58
>>71
必要の有無を聞いているのではないのでメリット(=利点)について宜しく。
0073デフォルトの名無しさん2007/08/03(金) 11:12:39
パフォーマンスだろうな。
0074デフォルトの名無しさん2007/08/03(金) 11:16:22
シンプルな文字列クラスを作って、それを用途別に派生させればいいような気がするのだが。
0075デフォルトの名無しさん2007/08/03(金) 11:27:30
>>69は文字列のクラスというよりは、文字列を記憶するクラスという感じだな。
0076デフォルトの名無しさん2007/08/07(火) 07:15:11
>>69の文章は異様に圧縮が効きそうだな。
0077デフォルトの名無しさん2007/08/16(木) 04:01:58
文字列を、「文字」ごとに処理させるのはどうやってやります？
あと、文字数を数える処理とか。（こっちは簡単だけど

charだと（Shift_JISでもEUC-JPでもUTF-8でも）マルチバイトの処理が面倒だし、
wchar_tだと（UTF-16として）サロゲートが入ってたら2つで1文字なので…
UTF-32とかUCS-4な文字列クラス使ってる人いますか？
0078デフォルトの名無しさん2007/08/16(木) 09:32:08
パフォーマンスを求めなければ、
マルチバイト→先人がやってきたようにやる
Unicode→32ビットでやる

自分はサロゲートなんてシラネーヨと高をくくって1文字16ビット固定でやってる。
0079デフォルトの名無しさん2007/08/16(木) 12:16:11
>>77
> UTF-32とかUCS-4な文字列クラス使ってる人いますか？

ﾉｼ 自作 UCS4+UTF8+SJIS+EUCJ
32ビットつってもフルカラー1ピクセルも32ビットだしな
0080デフォルトの名無しさん2007/08/16(木) 12:53:19
32ビットカラーって24ビット＋アルファ値じゃないん？
0081デフォルトの名無しさん2007/08/16(木) 13:05:55
1画素32ビットであることには違いあるまい｡
0082デフォルトの名無しさん2007/08/16(木) 14:56:45
std::basic_string<uint32_t>でいい気もするが
必要なコードを全部書くのは面倒くさいし
リテラルが簡単に書けないし
uint32_tの文字はオーバーロード時にただの整数と見なされてしまう

特にリテラルが簡単に書けないのは実用上大問題
0083デフォルトの名無しさん2007/08/16(木) 15:12:20
いらない子じゃん
0084デフォルトの名無しさん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なる型が入るらしいよ。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html
http://pc11.2ch.net/test/read.cgi/tech/1149440647/372-
0085デフォルトの名無しさん2007/08/22(水) 09:27:35
>>84
_Tマクロはプリプロセス時に解決されリテラルとして埋め込まれるが
その手法だといちいち実行時に変換される
どっちかっつーとC2Wとかのマクロに近いかな
本物のリテラルと違って一時オブジェクトの寿命を気にする必要があるし
ワイド文字リテラルがまともに使えるコンパイラを相手にするとしても、
wchar_tのサイズによって実装を場合分けしないといかんのも面倒だ

C++0xのユニコード文字型が導入されれば大分マシになりそうだが
いつになることやら、だな
0086デフォルトの名無しさん2007/08/22(水) 19:49:52
D言語だとテンプレート引数に文字列リテラルが使えるらしいな。
そもそもUTF-32なdchar型もあるけどな。
0087デフォルトの名無しさん2007/08/22(水) 20:27:11
{ xxx, yyy, zzz } ;のように書き換えるプリプロセッサを用意するだけじゃダメなん?
0088デフォルトの名無しさん2007/08/22(水) 22:18:07
>>87
それだと

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

static const uint32_t utf32_str[] = ....
ならそれでいいけど
0089デフォルトの名無しさん2007/08/22(水) 22:30:58
C99の複合リテラルなら静的記憶期間を持つから、
前者にも対応できるけど標準C++にはきっと入らない。
0090デフォルトの名無しさん2007/08/22(水) 22:34:31
もしかしてC99では
printf({'h', 'e', 'l', 'l', 'o', ',' 'w', 'o', 'r','l','d','\n', 0});
とか書けるのか

キモいな
0091デフォルトの名無しさん2007/08/22(水) 22:47:47
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});
}
0092デフォルトの名無しさん2007/08/22(水) 22:50:01
static const uint32_t _utf32_str[] = { うりゃぁ } ;
const uint32_t *utf32_str = _utf32_str ;

これでいいじゃん。
0093デフォルトの名無しさん2007/08/22(水) 22:54:40
{ うりゃぁ }
これはダメだろｗ

それはともかく、内部的にコンパイラはそれに近いことをやって、
ついでにそれをまとめたりしてくれてるわけだ
printf()等の函数の引数に直接リテラルを使えないのはかなり嫌だぞ
いちいちそんな風に書きたくないよ
0094デフォルトの名無しさん2007/08/22(水) 23:10:44
"うりゃぁ"のつもりではなくて・・・
{ 14235, 13456, 15196, 15611, 0 }
とかのつもり。

プリプロセッサで処理すれば何ら問題なし。
かつての日本語対応のやりかたと一緒。
0095デフォルトの名無しさん2007/08/22(水) 23:14:58
> かつての日本語対応のやりかたと一緒
あー確かにそうだな
Javaのnative2asciiみたいなもんとも言えるな
ただ、昔はリテラルを8進とか16進とかのリテラルに置き換えるだけで
すんでたでしょ
0096デフォルトの名無しさん2007/08/23(木) 08:31:30
>>93
87の言うようなプリプロセッサの出力が92みたいになればいいと思う。
0097デフォルトの名無しさん2007/08/23(木) 10:56:49
簡単に言うが、マクロとかテンプレートとか色々考慮してるか？
生半可な考えは絶対破綻する
0098デフォルトの名無しさん2007/08/26(日) 07:59:08
char *hage = L"hage";
printf("%s\n", hage);
何も表示されませｎ
0099デフォルトの名無しさん2007/08/26(日) 15:18:14
>>98
スレ違い。
0100デフォルトの名無しさん2007/08/26(日) 16:31:16
>>98
それをコンパイルするときに警告が出るようにしろ。
どうやってもそれで警告を出さないコンパイラなんて窓から投げ捨てろ。
0101デフォルトの名無しさん2007/10/07(日) 14:06:54
用途別に、
アルファベットだけ格納できる文字列クラス、
ひらがなだけ格納できる文字列クラス、
ウかんむりの漢字だけ格納できる文字列クラス、
とか作ったら、激しく労力の無駄でいい感じじゃね？
0102デフォルトの名無しさん2007/10/12(金) 08:22:41
テンプレートで自動生成したいなそれ
0103デフォルトの名無しさん2007/10/12(金) 09:33:24
>>102
まずは対応する文字クラスを作らなきゃなぁ。
0104デフォルトの名無しさん2007/10/13(土) 12:13:26
やはり問題の根元は、
文字型がCにないことだな。
0105デフォルトの名無しさん2007/10/13(土) 13:29:43
逆に無かった事で今日まで生き残れた
0106デフォルトの名無しさん2007/10/13(土) 14:25:02
素朴な疑問だが、文字型が存在する言語って何がある?
0107デフォルトの名無しさん2007/10/13(土) 14:54:20
C++ wchar_t

今度の0xではchar16_t, char32_tが追加の予定。
0108デフォルトの名無しさん2007/10/13(土) 14:57:20
>>106
Javaとか
0109デフォルトの名無しさん2007/10/15(月) 18:29:55
クラスで扱う文字コードは、
OSのAPIが要求する文字コードにあわせるのが一番なんだろうけどな。

cinで入力される度に、文字コード変換して格納、
coutで出力するたびに再度文字コードを変換して出力ってのは無駄が多いし。
0110デフォルトの名無しさん2007/10/15(月) 18:51:28
>>109
結局、char なら ASCII もしくはマルチバイト、
wchar なら UTF-16 って自分の中では決めてる。
で、マルチバイトに関しては環境に合わせる方向で。
でも実際には wchar だからって UTF-16 と決められないケースもおおいよね。
C++0x ではまた新たな型が追加されるみたいだねぇ。
01111102007/10/15(月) 18:54:47
C++0x になったら UTF-16と決めている場合には char16_t をつかうべき？
そりゃそうと、根本的な疑問なんだが、 UTF-8 も UTF-16 も
所詮は可変長文字だよね。内部コードとしてどちらを使うべきかは
どうやって決めればいいんだろう。好きなの使えば？ってのは無しの方向で。
自分の中でどういうガイドラインを作っておけばいいかなぁ、と迷う。

01121102007/10/15(月) 19:06:18
http://www.rubyist.net/~matz/20070312.html
まつもと氏はバイトオーダーの問題があるから
事実上 UTF-8 でいいじゃんって主張みたいだねぇ。
まぁわからないでもない。ただ Windows で
プログラムを書くことが多い身としては UTF-16
との変換をしばしばする必要があるのは屋だなぁ。
UTF-8とUTF-16のマップは表現系だけの変換で
マップは必要ないからそんなに苦にはならないか。
01131102007/10/15(月) 19:08:04
いっそのこと Mule のコードを流用、というのはやりすぎか。
http://www.dennougedougakkai-ndd.org/~delmonta/emacs/27.html
0114デフォルトの名無しさん2007/10/15(月) 19:08:07
char64_tがあれば…
0115デフォルトの名無しさん2007/10/16(火) 01:07:28
>> std::basic_string<uint32_t>
本気で実装するなら、facetから作ることになるのか…char_trait<uint32_t>…
それでコンストラクタではSHIFT-JISから変換格納？
すごく遅そう…ただでさえfacetキャッシュしないと遅いのに…
0116デフォルトの名無しさん2007/10/16(火) 02:55:26
俺思うんだ...
文字コードの体系が増えれば増えるほどややこしくなってるって...
01171102007/10/16(火) 16:33:31
文字を捨てよう。
動物に帰ろう。
0118デフォルトの名無しさん2007/10/16(火) 19:31:15
それはやりすぎ。
ASCIIだけ残せばいい。
0119デフォルトの名無しさん2007/10/19(金) 10:27:05
>>116
漏れの作った新しい文字コードをみんなが使えばいいんだ
問題はすべて解決だ
0120デフォルトの名無しさん2007/10/20(土) 00:17:23
0x00 = ひ
0x01 = ろ
0x02 = ゆ
0x03 = き
0x04 = 改行

ここまで策定した。残りはよろしく
0121デフォルトの名無しさん2007/10/20(土) 19:13:20
0x05ぬ
0x06る
0x07ぽ
0122デフォルトの名無しさん2007/10/22(月) 14:11:08
0x08=ガ
0x09=ッ
0123デフォルトの名無しさん2007/10/22(月) 16:00:40
つか、1バイト長で日本語表現するつもりですかw
0124デフォルトの名無しさん2007/10/22(月) 23:11:07
0x0a い
0x0b つ
0x0c て
0x0d よ
0x0e し
0x0f 。
0x10 お
0x11 ま
0x12 え
0x13 も
0x14 な
0x15 ー

案外被らずにいけるもんだな。
0125デフォルトの名無しさん2007/10/22(月) 23:31:40
0x16 = o
0x17 = r
0x18 = z
0x19 = O
0x1a = T
0x1b = L
0126デフォルトの名無しさん2007/10/23(火) 09:29:48
0xfe 終
0xff 了
0127デフォルトの名無しさん2007/10/23(火) 10:02:20
0x100宇
0x101宙
0x102ヤ
0x103バ
0x104イ
0128デフォルトの名無しさん2007/10/23(火) 13:13:16
>>127を持ちまして可変長コードになりました。
0129デフォルトの名無しさん2007/10/23(火) 14:52:02
>>128
しかも、それが1byte目なのか2byte目なのか判別不能な可変長コード...
0130デフォルトの名無しさん2007/10/23(火) 21:28:50
以下、
リトルエンディアンとビッグエンディアンによる骨肉の争い。
0131デフォルトの名無しさん2007/10/24(水) 00:20:28
文字列ぐらい言語仕様で持ちやがれ
0132デフォルトの名無しさん2007/10/24(水) 08:19:51
C++の歴史は文字列の抽象化の歴史だ。
言語仕様で文字列を定義したが最後、
C++の進化は止まるだろう…
0133デフォルトの名無しさん2007/10/24(水) 12:23:40
char や int のビット幅すらきめうちにはしなかったわけだからなぁ。
あ、そういうわけでビットローテートが演算子として用意されていないのかな？
ローテート結果に関して何か決めようとするとビット幅が固定されて
いないと何も言えないからねぇ。
0134デフォルトの名無しさん2007/10/24(水) 12:40:30
ローテートはビット数に依存するからCの仕様では無理だわな
VCには独自拡張であるけどね。2005からは8,16ビットにも対応してる
0135デフォルトの名無しさん2007/10/24(水) 16:54:06
>>1-135
ここの住人のやる気のなさがわかったおｗｗｗｗ
0136デフォルトの名無しさん2007/10/24(水) 18:27:57
もうC++で文字列使うのやめようぜ
0137デフォルトの名無しさん2007/10/24(水) 19:40:07
basic_stringはピザだからなぁ…
非メンバ非friendな便利関数としてデザインし直したものを作ってやろうかと妄想してるよ
0138デフォルトの名無しさん2007/10/24(水) 20:03:59
>>134
え？Visual C++ にはあるの？
どんな感じの構文？
0139デフォルトの名無しさん2007/10/24(水) 20:08:16
_rotl　だっけ？
0140デフォルトの名無しさん2007/10/24(水) 22:17:35
それ、演算子じゃなくて関数じゃないか
0141デフォルトの名無しさん2007/10/24(水) 22:28:16
わかったよ、じゃあ文字コードの次は演算子の策定と行こうか

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

ここまで策定した。残りはよろしく
0142デフォルトの名無しさん2007/10/24(水) 22:47:39
文字列をローテートするとどうなる。
0143デフォルトの名無しさん2007/10/25(木) 14:23:32
>>142
たぶん読みにくくてたまらない。
0144デフォルトの名無しさん2007/10/25(木) 17:19:41
>>142
ジェットストリームアタック

文字列をローテートするとどうなる。
。文字列をローテートするとどうなる
る。文字列をローテートするとどうな
なる。文字列をローテートするとどう
うなる。文字列をローテートするとど
どうなる。文字列をローテートすると
とどうなる。文字列をローテートする
るとどうなる。文字列をローテートす
するとどうなる。文字列をローテート
トするとどうなる。文字列をローテー
ートするとどうなる。文字列をローテ
テートするとどうなる。文字列をロー
ーテートするとどうなる。文字列をロ
ローテートするとどうなる。文字列を
をローテートするとどうなる。文字列
列をローテートするとどうなる。文字
字列をローテートするとどうなる。文
文字列をローテートするとどうなる。
0145デフォルトの名無しさん2007/10/25(木) 20:15:42
>>144の中にウォーリーがいます。君はみつけられるかな？
0146デフォルトの名無しさん2007/10/26(金) 23:55:15
みつからねぇ…
0147デフォルトの名無しさん2007/10/30(火) 13:01:58
単項演算子「!」を提案するよ
矢印の右が演算後の値ね
詳細な仕様と実装はあとの人に任せる

!"良スレ"　→　"糞スレ"
!"有用な議論"　→　"不毛なダベり"
0148デフォルトの名無しさん2007/10/30(火) 20:44:32
は？
0149デフォルトの名無しさん2007/10/31(水) 17:19:10
それ実現させたらどんだけデータベース抱えたクラスになるとおもっとるんだｗｗ
0150デフォルトの名無しさん2007/11/04(日) 14:46:45
!"このスレ"　→　？
0151デフォルトの名無しさん2007/11/14(水) 21:06:23
C++で独自の中置演算子を定義出来たら、
どんなに素晴らしい世界が待っているんだろう。
0152デフォルトの名無しさん2007/11/14(水) 21:08:51
ある日ＮＯぷりすたぁ
http://www.freewebs.com/photoradio/?518235
0153デフォルトの名無しさん2007/11/14(水) 21:12:28
そこでホワイトスペースのオーバーライドですよ
0154デフォルトの名無しさん2007/11/14(水) 21:49:01
純粋抽象クラス（ようはインタフェース）を定義して
ファクトリから文字セットを指定してインスタンスを得る仕様がいいのかな。
バイトオーダー非依存かつマルチバイトであるUTF-8を最初にサポートすれば
他の文字セットのサポートor最適化もしやすいだろうし。
0155デフォルトの名無しさん2007/11/14(水) 22:02:28
改行やTABもやれば Whitespace っぽくできるかも
「C++で関数型プログラミング」の次は「C++でWhitespace」だな
間違いない。
0156デフォルトの名無しさん2007/11/14(水) 23:57:32
完全素人だが
内部をUNICODEで実装しといて
どんな文字列も受けれるな仕様にしたらいかんの？
0157デフォルトの名無しさん2007/11/15(木) 08:14:02
ウニ文字の内部表現はどうするのさ？
0158デフォルトの名無しさん2007/11/15(木) 14:05:34
参考までに聞きたいんだけど、JISコード(SJISじゃなくて「)を直接操作する
文字列クラスって作ったことありますか？
格納だけじゃなく検索とかの機能付きで。
一般的にはSJISに変換してるんだろうか。

あ〜、ついでに終端が0じゃない文字列コードって存在するんですか〜？
0159デフォルトの名無しさん2007/11/15(木) 15:04:51
文字のコードポイントと、エンコーディングと、
文字列の内部表現とをごっちゃにして
釣ろうとしてるようにしか見えない。
0160デフォルトの名無しさん2007/11/17(土) 01:25:05
マジレスすると、必要なのは新しい文字列クラスではなく、
エンコーディングを意識した文字列イテレータ。

さらに、部分文字列(あるいはマルチバイトの一文字分)をポイントする
beginとendのペアみたいなデータ型が標準化されれば、
色んなユーティリティを作りやすくなると思う。
0161デフォルトの名無しさん2007/11/17(土) 03:21:34
アルゴリズム(ポリシー?)を与えておけば
コピーされる際にそれを使って自動的にエンコードしてくれるって寸法か
いいなそれいいな
って誰かがもう作ってそうなふいんきだけど
0162デフォルトの名無しさん2007/11/17(土) 15:30:10
>>160
substringクラスでも作るか？
0163デフォルトの名無しさん2007/11/22(木) 22:55:43
>>158
それはコードじゃなくてC言語系の規則。
BSTRていうのは配列の頭に文字数を入れたはずだし、
D言語ではその規則も使えるが、配列が配列長をしってるから、
そんなナンセンスなことは必要ない。

ま、C++でもVC系（これしか知らない。）のstd::stringは内部的には長さで処理しているが、便宜上0終端を強制されてる感じっぽい。
0164デフォルトの名無しさん2007/11/22(木) 22:59:32
>>160
その希望は多分Rangeって概念だと思うよ。Boostに入ってる。
0165デフォルトの名無しさん2007/11/22(木) 23:02:34
>>161
それいいね。でも変換関数なりを書くのが一番だるいって言う。
一回書けばつぶしが利くのだけど、その一回がなぁ。
0166デフォルトの名無しさん2007/11/22(木) 23:26:35
>>164
チゲーよバカ
0167デフォルトの名無しさん2007/11/24(土) 13:04:15
あれ？
あぁ、後者って書き忘れたなぁ。
エンコーディングはよぉーしらん。
0168デフォルトの名無しさん2007/12/07(金) 16:13:34
目的のものを作っちゃった俺がきましたよ
0169デフォルトの名無しさん2007/12/07(金) 20:25:38
>>168
公開！公開！
0170デフォルトの名無しさん2007/12/07(金) 20:54:18
オプソ化きぼんぬ
0171デフォルトの名無しさん2007/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でいいじゃん？
力作のレスだぜ。さあ叩いてくれ
0172デフォルトの名無しさん2007/12/07(金) 22:36:15
文字コードを知っている必要があるのはコンテナではなくイテレータだってアイデアはいいと思うよ。
0173デフォルトの名無しさん2007/12/19(水) 19:34:33
双方向イテレータとランダムアクセスイテレータを作るのは
難しそうだけど。
0174デフォルトの名無しさん2007/12/19(水) 23:07:33
文字単位でランダムアクセスできる機能は
大部分の用途に対してオーバースペックだから捨てるのが前提だ。
必要に応じて、途中のイテレータを保存しとくとか、
32bit文字オブジェクトのベクタに変換したりしてどうにかする。
0175デフォルトの名無しさん2007/12/19(水) 23:21:31
内部表現がUTF-16なら双方向は楽でしょ。
マルチバイトとはいえ下位サロゲートが出現したら、その前を頭にすればいい。
ランダムアクセスは内部で結局はイテレートするしかないよね。
0176デフォルトの名無しさん2007/12/19(水) 23:48:11
内部表現がUTF-16(UCS2)かUTF-8で、UCS4を取り出すようなイテレータだったら、
boostのicuで使われてるはず。
0177デフォルトの名無しさん2007/12/20(木) 04:20:58
>>174
可変長ならランダムアクセスはそもそも実装不可能だろう
0178デフォルトの名無しさん2007/12/20(木) 13:10:06
ランダムアクセスあきらめたら、
「与えられたテキストファイルで使われているすべての文字の一覧を求めろ」
と言われたときどうするの？
STLでsort() → unique()、という手が真っ先に思い浮かぶんだけど、
sort()はランダムアクセスイテレータがいるんだよね。
0179デフォルトの名無しさん2007/12/20(木) 14:20:33
コピーするほかない
コピーするのかビューなのかを
場合により選べるのがイテレータの良いところ
0180デフォルトの名無しさん2007/12/20(木) 17:34:43
どうせWin32APIの文字受け渡しが癌
0181デフォルトの名無しさん2007/12/20(木) 17:49:42
癌は受け渡しより受け取りの方だと思うが。

GetBuffer→API呼ぶ(→ReleaseBuffer) の流れからは逃れられない
0182デフォルトの名無しさん2007/12/20(木) 17:59:40
>>33を使えばAPIからの受け取りもそれほど面倒ではないけど、文字コードが違う場合には
自動で変換できるようにしないとな。
0183デフォルトの名無しさん2007/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()); }

思いつきで書いただけで、コンパイルもテストもしてないけど。
0184デフォルトの名無しさん2007/12/20(木) 19:01:05
何文字返ってくるか分からないがね〜
0185デフォルトの名無しさん2007/12/20(木) 19:27:31
受け取ったらそのまま、普通に持ち運びしたいよな、何も考えずに。
0186デフォルトの名無しさん2007/12/20(木) 21:56:39
>>184
MSのプログラマですらオーバーフロー度々起こすってことはやっぱ問題があるんだよな。
0187デフォルトの名無しさん2007/12/20(木) 22:02:05
safeiteratorを実装するしか
0188デフォルトの名無しさん2007/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);
0189デフォルトの名無しさん2007/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;
とか書けばいい。
0190デフォルトの名無しさん2007/12/21(金) 16:36:16
結局、固定長バッファで長さ不明のもの受け取る時点で…
リトライすると結果が変わる場合もあるし。
0191デフォルトの名無しさん2008/01/07(月) 15:18:41
既出かもしれないけど
ttp://ast.qt-space.com/slibrary/sjstring.html
結構使いやすいと思った
0192デフォルトの名無しさん2008/01/07(月) 15:41:17
>>191
意図しているのかしていないのか、コードはバグっているしドキュメントには不備があるし、windows.h必須だし……
0193デフォルトの名無しさん2008/01/07(月) 15:53:14
Win32APIで可変長文字列が扱えて置換できるっていうの探してたら
ようやく見つかったから貼ってみた。
このスレ的にはナシなのか。
それでも、どこがバグってるか分からず使ってる幸せ脳なオレ

ttp://ayusya.hp.infoseek.co.jp/ProgramCString3.html
これは可変長文字列が使えないし、置換の処理が間違ってた。
0194デフォルトの名無しさん2008/01/07(月) 15:53:35
const性を全く考慮していない辺り、ｱｲﾀﾀﾀなのだが。
つまり、const SJStringを作ってしまうと殆ど(或いは全部か?)のメソッドが使えなくなる罠。
const SJStringから何かを検索することも、SJStringの検索文字列をconst SJStringで与えることもできやしない。
0195デフォルトの名無しさん2008/01/07(月) 16:03:18
>>193
>191のメソッドの、parseInt()かisOnlyNumber()辺りを2バイト数字で試してみて。
>193のクラスも、>194の問題があるね。windows.hに依存しない分だけ使えそうだけど。
0196デフォルトの名無しさん2008/01/07(月) 16:12:09
ずれてる…
１００→211
９９９→333
になった。
0197デフォルトの名無しさん2008/01/07(月) 16:18:41
書き方が悪かった。parseIntでの結果
０　１　２　３　４　５　６　８　９
1　 2　4　 5　 6　7　 8　 9　3
７が出てくると0になる。（６７８→0）
・・・変だね。
0198デフォルトの名無しさん2008/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;
0199デフォルトの名無しさん2008/01/07(月) 16:55:55
>>197
parseInt()の実装を見てご覧。意図的なら兎も角、こんなバグを作りこむ香具師が信用できる?
0200デフォルトの名無しさん2008/01/07(月) 17:01:25
>>199
どうやら数字を1から9まで数えられない人が作ったようです。
parseInt()だけ直して使おうかなと。
どうせ置換と可変文字列が使えればいいし。
そこだけならwindows.hもいらないみたいだし。
（一番大きな理由は自分では作れないという事）
0201デフォルトの名無しさん2008/01/07(月) 17:06:08
>>200
バグっているのはそこだけじゃないから、充分注意してね。
# つーか、MBCSなら置換も楽なんだけど……
0202デフォルトの名無しさん2008/01/07(月) 17:08:00
なんだろう。この無駄な中括弧の多さは…

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

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

if文の終わりのところを11にすればいいのかな。
str += strNumber.charAt(p - 11);
0203デフォルトの名無しさん2008/01/07(月) 17:14:18
parseInt()が有るのにparseDouble()なんかが無いのも不思議。
ここらへん全部作ってあるクラスがあっても良さそう。
というか探せばありそう。また探してくるわ
0204デフォルトの名無しさん2008/02/09(土) 12:36:32
結局良いのは存在しないのか・・・
0205デフォルトの名無しさん2008/02/10(日) 13:40:06
ほんとに「完璧」な文字列クラスを作ろうとすると、

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

最低でもこれくらいは必要になるからめちゃくちゃ大変。
0206デフォルトの名無しさん2008/02/10(日) 14:21:47
ヘッダーファイル一つインクルードするだけで使えるようなのがいいんだけどなぁ。
正規表現まで対応するとなるとかなりの量になるよね。
0207デフォルトの名無しさん2008/02/10(日) 14:51:45
当然イテレータで要素巡回できるようにしてほしいし、
ついでに、レンジやコンテナの要件も満たしていてほしい。
0208デフォルトの名無しさん2008/02/10(日) 15:23:45
wstringのサロゲートなんとかするだけでもいいっすよ
0209デフォルトの名無しさん2008/02/10(日) 15:29:08
そうするとchar_traitsだけじゃ足りないんだよな。
0210デフォルトの名無しさん2008/02/13(水) 00:13:40
海外のプログラマーはどうしてるんかね？
マルチバイトｶﾝｹｰﾈｰであまり気にしないんだろうか。

普段はstd::stringでも構わないんだけど
GetWindowTextとか使うときに不便だから
ここらへんを一まとめにしたようなのどこかにないかね。
0211デフォルトの名無しさん2008/02/13(水) 14:07:59
中国人とかも困ってるだろうにね。
0212デフォルトの名無しさん2008/02/13(水) 18:58:13
>>210
今度の改定でstd::basic_string<>も
vector同様に要素がメモリ上で連続されることが保証されるようになるらしい。
0213デフォルトの名無しさん2008/02/13(水) 21:50:47
中国人は字が読めるヤツは英語も読めて
英語出来ないヤツは字も読めないから問題ないんだよ
0214デフォルトの名無しさん2008/02/13(水) 21:52:32
国内向けアプリは普通中国語で作るんだろ？
0215デフォルトの名無しさん2008/02/13(水) 22:24:57
それはどうかな
0216デフォルトの名無しさん2008/02/14(木) 05:32:36
仕事でパソコンを使う奴は英語でいいし、英語を読めない奴にパソコンを教えても使えないから問題ない。
0217デフォルトの名無しさん2008/02/14(木) 12:28:31
ワープロやエディタのように英語が読めてもデータとして中国語を扱う必要もあるだろうに。
0218デフォルトの名無しさん2008/02/14(木) 19:21:56
その場合は、中国語だけを扱えばいいから何の問題もない
0219デフォルトの名無しさん2008/02/18(月) 08:04:42
アニメ「さよなら絶望先生」には

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

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

＞残念ながらこういった「文字の結合」ができるライブラリを寡黙にして知りません。
それを言うなら、「寡聞にして存じ上げません」でしょう。
0221デフォルトの名無しさん2008/02/18(月) 12:41:52
　雲
雲雲
　龍　　　←これで一字
龍龍

>>これって文字コードの正規化の一種ですよね？
>いいえ。
0222デフォルトの名無しさん2008/02/18(月) 13:34:06
>>221
言葉遊びとごっちゃにしてませんか?
0223デフォルトの名無しさん2008/02/18(月) 15:01:13
糸色 = 文字コードの正規化
>>221 = 言葉遊び

なぜそう言いきれるのか理由を説明してくれ。
コンピュータにも分かるように。
0224デフォルトの名無しさん2008/02/18(月) 15:33:56
>>223
逆。
>219は言葉遊び。通称「絶望」先生は、本名「糸色望」なのだから。
0225デフォルトの名無しさん2008/02/18(月) 19:19:25
>>205
エンコーディングの自動判別機能については文字列クラスじゃなく、
フリー関数かlocaleを表現するクラスのメンバ関数に持たせるべきだと思う。
国際化された検索機能などを文字列クラス自体が持つとすると、
文字列はエンコーディングとバイト列の組になっているか、
あるいは特定の内部コードに正規化されているはずだけど
自動判別アルゴリズムの入力は「バイト列」と「エンコーディングの候補」になる。
これらを与えることが可能な場所はコンストラクタしかないが、
コード変換しないでエンコーディングだけ知りたい場合に困ってしまう。
0226デフォルトの名無しさん2008/02/19(火) 01:58:32
きっと>>219が言いたかったのは
文字コードで悩むならいっそ画像化して画像解析すればいいじゃない
ってことだろう。

無いな。
0227219(本物)2008/02/19(火) 18:01:30
私の言いたかったことは
「言葉遊びで言葉遊びを説明する・・・
そんな言葉遊びを言葉遊び的に言葉遊びで言葉遊びするという
言葉遊びを言葉遊びしてほしい」
ということです
0228デフォルトの名無しさん2008/02/25(月) 21:12:30
縦読みも正規化だな
0229デフォルトの名無しさん2008/03/09(日) 22:31:12
俺は>>198ではないがオレ流に作ってみたので晒してみる
つ ttp://sij.dip.jp/strjp/

話にならんってレベルだったらスルーしてくれ…
0230デフォルトの名無しさん2008/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);
0231デフォルトの名無しさん2008/11/20(木) 05:37:34
0232デフォルトの名無しさん2008/11/20(木) 06:45:20
可変バイトな文字を扱えるbasic_stringがあれば全て解決する
0233デフォルトの名無しさん2008/12/16(火) 23:30:32
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));



0234デフォルトの名無しさん2008/12/17(水) 15:44:26
C++0xとboostでなんとかならんものか
0235デフォルトの名無しさん2008/12/18(木) 00:24:34
あと10年もすれば
「もうbasic_string<uint32_t>でいいんじゃね？
メモリ128TBが2000円の時代だぜ」
0236デフォルトの名無しさん2008/12/18(木) 00:48:58
ないな。
0237デフォルトの名無しさん2008/12/19(金) 19:03:18
10年じゃせいぜい128GBくらいだろ
0238デフォルトの名無しさん2008/12/19(金) 21:33:03
Windows Vistaが32bitに対応したせいで64bit化が5年は遅れたな。
せっかく名器XPから衣替えしたんだから、32bitなんて捨てるべきだった。
64bitに一本化してりゃ5年で128GBなんて通過してただろうに。
0239デフォルトの名無しさん2008/12/20(土) 01:48:21
Vista32出してなかったら、XP64よりはマシな程度の普及率だったろうよ。
0240デフォルトの名無しさん2008/12/20(土) 16:09:47
XP64 はバグバグでひどい
0241デフォルトの名無しさん2008/12/20(土) 16:47:17
それServer 2003 x64がバグバグって言ってるのと同じだけど分かってる？
0242デフォルトの名無しさん2008/12/20(土) 18:48:05
だってタスクバーのボタンをクリックしたら
別のアプリが上に来る事があるし、
ゾンビプロセス残りやすいし・・・。
0243デフォルトの名無しさん2008/12/27(土) 17:43:45
何でバグるんだろうな？long(32)にポインタを突っ込んだりしてるから？
流石に天下のミクロソフトがそんなことをするとは思えんが。
0244デフォルトの名無しさん2009/01/22(木) 19:34:23
EUCかJIS(S-JIS)で十分じゃん。
0245デフォルトの名無しさん2009/01/22(木) 22:33:42
>>240>>242
http://pc11.2ch.net/test/read.cgi/win/1229152159/27
ちょっと違う話だけど、デスクトップヒープを増やしたらどう？
0246デフォルトの名無しさん2009/03/18(水) 03:16:33
ちょｗ
0247デフォルトの名無しさん2009/03/19(木) 16:08:19
ダメ
0248デフォルトの名無しさん2009/04/03(金) 06:53:05
やっぱりWindows APIやらの既存ライブラリに文字列を渡すことを考えると
std::wstring + 文字コードを処理できるイテレータっていうのが理想になるのかな
0249デフォルトの名無しさん2009/04/08(水) 01:06:55
スルー推奨
0250デフォルトの名無しさん2009/04/13(月) 13:28:31
は？
0251デフォルトの名無しさん2009/04/14(火) 13:34:25
ひ？
0252デフォルトの名無しさん2009/04/26(日) 21:47:56
wchar_tが2Byteとか言い切っちゃう男の人って
0253this.is.a.tor.exit.router.www.torproject.org2009/08/17(月) 17:39:34
自動焼人 ★　＝　自動保守 ◆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/
にて自動焼人 ★までご連絡ください
0254デフォルトの名無しさん2009/08/28(金) 20:11:26
結局上位レイヤーだけで小細工をしても結局無理が出てしまうわけで。
言語圏の統合という名の下に赤紙が来るならエンジニア達も戦場に行くのではないかということ。
確かに人々が殺しあったり文化を淘汰することはよくないことだけど、そろそろこの問題に終止符を打つことも後世のために必要なのでは。
0255デフォルトの名無しさん2009/11/06(金) 06:31:32
まず文字コードが1byte文字2byte文字で分けられてることが問題なのだ
0256デフォルトの名無しさん2009/11/06(金) 13:20:39
そんな藻前には、これ。　　っUTF-32
0257デフォルトの名無しさん2009/11/07(土) 01:33:59
一番の課題は如何に余所様へ迷惑掛けない様に実装するかだね
0258デフォルトの名無しさん2009/11/07(土) 05:45:55
文字コードを決める標準化団体(あんのか？)が標準文字コード作って
OS作ってる連中やライブラリ作成団体が文字配列の仕様をそれに従えばなんとか・・・
0259デフォルトの名無しさん2009/11/07(土) 10:50:56
unicodeコンソーシアム？
■ このスレッドは過去ログ倉庫に格納されています