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


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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

キモいな



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

#include <stdio.h>

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


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

これでいいじゃん。


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

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

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

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

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

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

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

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

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

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



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

102 名前:デフォルトの名無しさん [2007/10/12(金) 08:22:41 ]
テンプレートで自動生成したいなそれ

103 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 09:33:24 ]
>>102
まずは対応する文字クラスを作らなきゃなぁ。

104 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 12:13:26 ]
やはり問題の根元は、
文字型がCにないことだな。

105 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 13:29:43 ]
逆に無かった事で今日まで生き残れた

106 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 14:25:02 ]
素朴な疑問だが、文字型が存在する言語って何がある?

107 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 14:54:20 ]
C++ wchar_t

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

108 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 14:57:20 ]
>>106
Javaとか

109 名前:デフォルトの名無しさん mailto:sage [2007/10/15(月) 18:29:55 ]
クラスで扱う文字コードは、
OSのAPIが要求する文字コードにあわせるのが一番なんだろうけどな。

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

110 名前:デフォルトの名無しさん mailto:sage [2007/10/15(月) 18:51:28 ]
>>109
結局、char なら ASCII もしくはマルチバイト、
wchar なら UTF-16 って自分の中では決めてる。
で、マルチバイトに関しては環境に合わせる方向で。
でも実際には wchar だからって UTF-16 と決められないケースもおおいよね。
C++0x ではまた新たな型が追加されるみたいだねぇ。



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



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

113 名前:110 mailto:sage [2007/10/15(月) 19:08:04 ]
いっそのこと Mule のコードを流用、というのはやりすぎか。
www.dennougedougakkai-ndd.org/~delmonta/emacs/27.html

114 名前:デフォルトの名無しさん [2007/10/15(月) 19:08:07 ]
char64_tがあれば…

115 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 01:07:28 ]
>> std::basic_string<uint32_t>
本気で実装するなら、facetから作ることになるのか…char_trait<uint32_t>…
それでコンストラクタではSHIFT-JISから変換格納?
すごく遅そう…ただでさえfacetキャッシュしないと遅いのに…

116 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 02:55:26 ]
俺思うんだ...
文字コードの体系が増えれば増えるほどややこしくなってるって...


117 名前:110 mailto:sage [2007/10/16(火) 16:33:31 ]
文字を捨てよう。
動物に帰ろう。

118 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 19:31:15 ]
それはやりすぎ。
ASCIIだけ残せばいい。

119 名前:デフォルトの名無しさん mailto:sage [2007/10/19(金) 10:27:05 ]
>>116
漏れの作った新しい文字コードをみんなが使えばいいんだ
問題はすべて解決だ

120 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:17:23 ]
0x00 = ひ
0x01 = ろ
0x02 = ゆ
0x03 = き
0x04 = 改行

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



121 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 19:13:20 ]
0x05ぬ
0x06る
0x07ぽ

122 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 14:11:08 ]
0x08=ガ
0x09=ッ

123 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 16:00:40 ]
つか、1バイト長で日本語表現するつもりですかw


124 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:11:07 ]
0x0a い
0x0b つ
0x0c て
0x0d よ
0x0e し
0x0f 。
0x10 お
0x11 ま
0x12 え
0x13 も
0x14 な
0x15 ー

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

125 名前:デフォルトの名無しさん [2007/10/22(月) 23:31:40 ]
0x16 = o
0x17 = r
0x18 = z
0x19 = O
0x1a = T
0x1b = L

126 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 09:29:48 ]
0xfe 終
0xff 了

127 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:02:20 ]
0x100宇
0x101宙
0x102ヤ
0x103バ
0x104イ

128 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 13:13:16 ]
>>127を持ちまして可変長コードになりました。

129 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:52:02 ]
>>128
しかも、それが1byte目なのか2byte目なのか判別不能な可変長コード...

130 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:28:50 ]
以下、
リトルエンディアンとビッグエンディアンによる骨肉の争い。



131 名前:デフォルトの名無しさん [2007/10/24(水) 00:20:28 ]
文字列ぐらい言語仕様で持ちやがれ

132 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 08:19:51 ]
C++の歴史は文字列の抽象化の歴史だ。
言語仕様で文字列を定義したが最後、
C++の進化は止まるだろう…

133 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 12:23:40 ]
char や int のビット幅すらきめうちにはしなかったわけだからなぁ。
あ、そういうわけでビットローテートが演算子として用意されていないのかな?
ローテート結果に関して何か決めようとするとビット幅が固定されて
いないと何も言えないからねぇ。

134 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 12:40:30 ]
ローテートはビット数に依存するからCの仕様では無理だわな
VCには独自拡張であるけどね。2005からは8,16ビットにも対応してる

135 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 16:54:06 ]
>>1-135
ここの住人のやる気のなさがわかったおwwww

136 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 18:27:57 ]
もうC++で文字列使うのやめようぜ

137 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:40:07 ]
basic_stringはピザだからなぁ…
非メンバ非friendな便利関数としてデザインし直したものを作ってやろうかと妄想してるよ

138 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 20:03:59 ]
>>134
え?Visual C++ にはあるの?
どんな感じの構文?

139 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 20:08:16 ]
_rotl だっけ?

140 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:17:35 ]
それ、演算子じゃなくて関数じゃないか



141 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:28:16 ]
わかったよ、じゃあ文字コードの次は演算子の策定と行こうか

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

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

142 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:47:39 ]
文字列をローテートするとどうなる。

143 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 14:23:32 ]
>>142
たぶん読みにくくてたまらない。

144 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 17:19:41 ]
>>142
ジェットストリームアタック

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

145 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 20:15:42 ]
>>144の中にウォーリーがいます。君はみつけられるかな?

146 名前:デフォルトの名無しさん mailto:sage [2007/10/26(金) 23:55:15 ]
みつからねぇ…

147 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 13:01:58 ]
単項演算子「!」を提案するよ
矢印の右が演算後の値ね
詳細な仕様と実装はあとの人に任せる

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

148 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 20:44:32 ]
は?

149 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 17:19:10 ]
それ実現させたらどんだけデータベース抱えたクラスになるとおもっとるんだww

150 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 14:46:45 ]
!"このスレ" → ?



151 名前:デフォルトの名無しさん [2007/11/14(水) 21:06:23 ]
C++で独自の中置演算子を定義出来たら、
どんなに素晴らしい世界が待っているんだろう。

152 名前:デフォルトの名無しさん mailto:age [2007/11/14(水) 21:08:51 ]
ある日NOぷりすたぁ
www.freewebs.com/photoradio/?518235


153 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 21:12:28 ]
そこでホワイトスペースのオーバーライドですよ

154 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 21:49:01 ]
純粋抽象クラス(ようはインタフェース)を定義して
ファクトリから文字セットを指定してインスタンスを得る仕様がいいのかな。
バイトオーダー非依存かつマルチバイトであるUTF-8を最初にサポートすれば
他の文字セットのサポートor最適化もしやすいだろうし。

155 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 22:02:28 ]
改行やTABもやれば Whitespace っぽくできるかも
「C++で関数型プログラミング」の次は「C++でWhitespace」だな
間違いない。

156 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:57:32 ]
完全素人だが
内部をUNICODEで実装しといて
どんな文字列も受けれるな仕様にしたらいかんの?

157 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 08:14:02 ]
ウニ文字の内部表現はどうするのさ?

158 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 14:05:34 ]
参考までに聞きたいんだけど、JISコード(SJISじゃなくて「)を直接操作する
文字列クラスって作ったことありますか?
格納だけじゃなく検索とかの機能付きで。
一般的にはSJISに変換してるんだろうか。

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

159 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 15:04:51 ]
文字のコードポイントと、エンコーディングと、
文字列の内部表現とをごっちゃにして
釣ろうとしてるようにしか見えない。


160 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 01:25:05 ]
マジレスすると、必要なのは新しい文字列クラスではなく、
エンコーディングを意識した文字列イテレータ。

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



161 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 03:21:34 ]
アルゴリズム(ポリシー?)を与えておけば
コピーされる際にそれを使って自動的にエンコードしてくれるって寸法か
いいなそれいいな
って誰かがもう作ってそうなふいんきだけど

162 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 15:30:10 ]
>>160
substringクラスでも作るか?

163 名前:デフォルトの名無しさん mailto:sage [2007/11/22(木) 22:55:43 ]
>>158
それはコードじゃなくてC言語系の規則。
BSTRていうのは配列の頭に文字数を入れたはずだし、
D言語ではその規則も使えるが、配列が配列長をしってるから、
そんなナンセンスなことは必要ない。

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

164 名前:デフォルトの名無しさん mailto:sage [2007/11/22(木) 22:59:32 ]
>>160
その希望は多分Rangeって概念だと思うよ。Boostに入ってる。

165 名前:デフォルトの名無しさん mailto:sage [2007/11/22(木) 23:02:34 ]
>>161
それいいね。でも変換関数なりを書くのが一番だるいって言う。
一回書けばつぶしが利くのだけど、その一回がなぁ。

166 名前:デフォルトの名無しさん mailto:sage [2007/11/22(木) 23:26:35 ]
>>164
チゲーよバカ

167 名前:デフォルトの名無しさん mailto:sage [2007/11/24(土) 13:04:15 ]
あれ?
あぁ、後者って書き忘れたなぁ。
エンコーディングはよぉーしらん。

168 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 16:13:34 ]
目的のものを作っちゃった俺がきましたよ

169 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 20:25:38 ]
>>168
公開!公開!

170 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 20:54:18 ]
オプソ化きぼんぬ



171 名前:デフォルトの名無しさん mailto:sage [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でいいじゃん?
力作のレスだぜ。さあ叩いてくれ

172 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 22:36:15 ]
文字コードを知っている必要があるのはコンテナではなくイテレータだってアイデアはいいと思うよ。

173 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 19:34:33 ]
双方向イテレータとランダムアクセスイテレータを作るのは
難しそうだけど。

174 名前:デフォルトの名無しさん [2007/12/19(水) 23:07:33 ]
文字単位でランダムアクセスできる機能は
大部分の用途に対してオーバースペックだから捨てるのが前提だ。
必要に応じて、途中のイテレータを保存しとくとか、
32bit文字オブジェクトのベクタに変換したりしてどうにかする。

175 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 23:21:31 ]
内部表現がUTF-16なら双方向は楽でしょ。
マルチバイトとはいえ下位サロゲートが出現したら、その前を頭にすればいい。
ランダムアクセスは内部で結局はイテレートするしかないよね。

176 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 23:48:11 ]
内部表現がUTF-16(UCS2)かUTF-8で、UCS4を取り出すようなイテレータだったら、
boostのicuで使われてるはず。

177 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 04:20:58 ]
>>174
可変長ならランダムアクセスはそもそも実装不可能だろう

178 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 13:10:06 ]
ランダムアクセスあきらめたら、
「与えられたテキストファイルで使われているすべての文字の一覧を求めろ」
と言われたときどうするの?
STLでsort() → unique()、という手が真っ先に思い浮かぶんだけど、
sort()はランダムアクセスイテレータがいるんだよね。

179 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 14:20:33 ]
コピーするほかない
コピーするのかビューなのかを
場合により選べるのがイテレータの良いところ

180 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 17:34:43 ]
どうせWin32APIの文字受け渡しが癌



181 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 17:49:42 ]
癌は受け渡しより受け取りの方だと思うが。

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

182 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 17:59:40 ]
>>33を使えばAPIからの受け取りもそれほど面倒ではないけど、文字コードが違う場合には
自動で変換できるようにしないとな。






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

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

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