C++0x - 暇つぶし2ch

C++0x ..

175:デフォルトの名無しさん
06/09/11 21:55:25
>>174
そういうlocale（特にcodecvt）を作ればいいという話ではないのか？

176:デフォルトの名無しさん
06/09/11 22:11:50
STLのlocale周りは、はっきり言って無駄だから、
さっくり削除してほしいと思っているのは自分だけ？

177:デフォルトの名無しさん
06/09/11 22:13:38
実装の話？仕様の話？

178:デフォルトの名無しさん
06/09/11 22:16:05
>>174
> char を UTF-8

どういうこと?
charというか、mbsのこと?

179:デフォルトの名無しさん
06/09/11 22:17:32
>>174
> wchar_t を UTF-16 として

どういうこと?
UTF-16じゃなくて、UCS-4でなく?

180:デフォルトの名無しさん
06/09/11 22:18:43
>>176
君みたいな人は少ないと思う。

181:デフォルトの名無しさん
06/09/12 01:02:06
サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか
邪魔にされる日が来るのかね。
1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。

182:デフォルトの名無しさん
06/09/12 01:24:19
しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、
欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
実際のところどうなのかは知らないが。

ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。

183:デフォルトの名無しさん
06/09/12 02:34:51
URLﾘﾝｸ(www.open-std.org)
> News 2006-09-11: The 2006-09 mailing is available (4700 kb tar.gz, .zip 4700 kb) individual papers
> News 2006-09-11: The C++ Standard Library Issues List (Revision 44) is available (.tar.gz)
> News 2006-09-11: C++ Standard Core Language Issues List (Revision 43) is available, also committee version

184:デフォルトの名無しさん
06/09/12 13:22:39
>>183
(ﾟ∀ﾟ)ktkr
待ってたぜ。これで仕事中こっそり楽し(ry

185:デフォルトの名無しさん
06/09/13 05:22:20
>>182
> 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
だからこそUTF-8でしょ
> ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
日本人の都合なんか知ったこっちゃないし

186:デフォルトの名無しさん
06/09/13 06:41:57
ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。

187:デフォルトの名無しさん
06/09/13 08:27:03
だからさ、char 型なんて廃止して、byte 型にしてほしいぜ
別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが

188:デフォルトの名無しさん
06/09/13 09:48:52
charが実装依存ですが?
basic_stringテンプレート知らない人ですか、ああそうですか

189:デフォルトの名無しさん
06/09/13 12:24:08
日本語も読めないのに皮肉を言おうとするとこうなる。

190:デフォルトの名無しさん
06/09/13 12:54:37
uint8_tで何が不満なんだ? > byte_t

191:デフォルトの名無しさん
06/09/13 18:51:23
8bitとは限らないから…とか？

192:デフォルトの名無しさん
06/09/13 21:24:18
uint8_t i = 32;
std::cout << i;

とやって、32じゃなくて、空白が出力されたるの嫌やん

193:デフォルトの名無しさん
06/09/13 21:26:02
1byteを表すchar
文字を表すchar
双方を別々に定義すべきだという主張かと

194:デフォルトの名無しさん
06/09/13 21:38:12
C++ でせっかく char と signed char と unsigned char に分かれたのに、
なんで cout << で全部文字になっちまうんだ？

195:デフォルトの名無しさん
06/09/13 21:54:36
実際問題、符号ないほうが都合がいいから
文字としてuchar使ってるケースあるし、その辺との兼ね合いでね？

196:デフォルトの名無しさん
06/09/14 08:34:29
>193
そう。バイト単位のデータを表す型と文字を表す型が同一であることが、本気で文字列を
なんとかしようという意志の無さの表れではないかと
実体が wchar_t であろうと char であろうと、１文字を１文字として扱えるなら関心はないよね
文字列の仕様なんてたぶんこの先もふらふらするんだから、ある程度距離を取っておいた
方がいいと思うんだな
string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい

197:デフォルトの名無しさん
06/09/14 08:52:47
>>196
文字列(というか文字)を何とかした結果が今の形 char だと思う。

>string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
ができる柔軟性も、char, wchar_tのおかげと思えば・・

198:デフォルトの名無しさん
06/09/14 22:37:48
char は C との互換性のために残しておく程度でいい
std::string と std::wstring 間にろくな互換性無いだろ？
これを柔軟性というのか？

199:デフォルトの名無しさん
06/09/14 23:06:50
>>198 そういう意味だったのか。

200:デフォルトの名無しさん
06/09/15 00:54:03
>>198
互換性って例えばどういうこと?

201:デフォルトの名無しさん
06/09/15 01:44:55
>>200 もう血が止まってるんだから、変にいじったりしないの！

202:デフォルトの名無しさん
06/09/15 09:11:21
おねがいします。

自分のファイル名(x.exe)を読み込んで
xの部分がAすなわちA.exeだったらaを実行して
xの部分がBすなわちB.exeだったらbを実行する
っていうようなCのプログラムを教えてください。

203:デフォルトの名無しさん
06/09/15 09:26:00
なんでまた C++0x スレに？
もしかしてマルチ？

204:デフォルトの名無しさん
06/09/15 09:34:41
マルチだね
どこだか忘れたが別スレで見た

>202
あっちのスレに答えが書いてあったぞ

205:デフォルトの名無しさん
06/09/17 00:49:06
C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？

たぶんそんなことはないだろうが

206:デフォルトの名無しさん
06/09/17 11:10:37
おじいさんは、裏山に畑を耕しに行ったんじゃない？

たぶんそんなことはないだろうが

207:デフォルトの名無しさん
06/09/17 15:01:57
いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。

208:デフォルトの名無しさん
06/09/17 20:43:56
>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。

209:デフォルトの名無しさん
06/09/17 23:24:34
書かれたものがキチガイだと
本当に誰にも通じないけどな。

210:デフォルトの名無しさん
06/11/24 14:31:34
N2133 06-0203
Editor's ReportPete Becker
2006-11-03
URLﾘﾝｸ(www.open-std.org)

N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
URLﾘﾝｸ(www.open-std.org)
新規色分け版

N2135 06-0205
Programming Languages －C++ Pete Becker
2006-11-06 N2134=06-0204
URLﾘﾝｸ(www.open-std.org)
色分けなし版

211:デフォルトの名無しさん
06/11/24 18:16:23
ちなみにADLのところ、3.4.2のルールが書き変わっています。

stringとchar_traitsのところも結構。
"文字"じゃなくてPODなら入れられる。

212:デフォルトの名無しさん
06/11/24 18:56:53
色の違いだったのね

213:デフォルトの名無しさん
06/11/24 22:19:20
論文リスト、ちらほら C++09 という記述が出始めたな

214:デフォルトの名無しさん
06/11/24 22:21:19
2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。

215:デフォルトの名無しさん
06/11/28 23:58:39
Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。

216:デフォルトの名無しさん
06/11/29 01:24:10
一番ほしいのはTemplate aliasesかな

217:デフォルトの名無しさん
06/11/29 01:31:43
>215
標準ライブラリに対する rvalue reference の導入は
下位互換を完全に意識した設計が提案されているので
＞STLも仕様決め直しだし、
という見方は少し違うような気がします．
std::auto_ptr などは deprecated なだけで廃止されるわけでもないですし．

というよりか，現在の標準ライブラリにおける rvalue reference 対応の提案は，
(いつものことですが) 下位互換の維持のために非常に設計が汚い印象があります．
move に対応していない場合 copy に fallback する設計は，
たとえば例外送出時のときなどの仕様と動作が極めて煩雑になるのではないか，
など個人的には不満も多いです．
(この汚さは標準ライブラリにおける rvalue reference 対応がもたらす汚さで，
言語仕様として導入される rvalue reference の仕様とは独立です)

言語仕様としての rvalue reference は， move semantics の導入と同時に，
the forwarding problem と呼ばれる非常に重要な問題を同時解決しますし，
(この問題の解決も見た目に比してインパクトが極めて大きいと思います)
『便利』程度の恩恵ではなく『マニア向け』の機能でもないと思います．

今現在，そもそも rvalue reference / move semantics 自体が机上の空論ですから，
これについて今何を語っても "almost as much of a hoax as Artificial Intelligence"
でしかないですが，それを承知であえて， rvalue reference / move semantics は
OOP・汎用プログラミング・関数プログラミング・効率・リソース管理・例外安全性
スレッド安全性など，ほぼあらゆるプログラミングパラダイム・概念の全域，
あと特にこれらの概念が交錯する領域での貢献が極めて大きい，
C++0x における (C++98 以来) 最大の進化だと主張したいです．

218:デフォルトの名無しさん
06/11/29 01:42:23
とマニアが言っております

219:デフォルトの名無しさん
06/11/29 01:48:06
いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。

220:デフォルトの名無しさん
06/11/29 12:59:00
>>219
明暗！

221:デフォルトの名無しさん
06/11/29 16:09:12
言い得て妙な変換だなｗ

222:デフォルトの名無しさん
06/11/29 17:42:23
namespace　std0x
{
　　using　namespace　std;
}

223:デフォルトの名無しさん
06/11/30 08:53:29
namespace std0x = std;

224:デフォルトの名無しさん
06/11/30 13:36:58
もうここはあれだ、Andrei Alexandrescu あたりに超変態的 template
テストケース書いてもらってさ、これにパスしないと C++0x 準拠とは
名乗らせないってのはどうよ。
もうさ、これまでみたいなコンパイラ毎の ifdef 分岐の嵐はさすがにもう
勘弁して暮れって感じ

225:デフォルトの名無しさん
06/11/30 13:50:21
>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。

226:デフォルトの名無しさん
06/11/30 14:41:25
>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ

227:デフォルトの名無しさん
06/11/30 16:22:54
BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい

228:デフォルトの名無しさん
06/11/30 16:52:46
"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…

229:デフォルトの名無しさん
06/11/30 20:58:15
>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。

230:デフォルトの名無しさん
06/11/30 23:42:40
>>217
Cryoliteたん？

231:デフォルトの名無しさん
06/12/05 21:36:18
>>215です。

>>217さんのおっしゃることには技術的に白黒の付く部分については同意です。
けど、やっぱりそうなるとC++はどんどんマイナー言語になっていくと思います。
じゃあ拡張しなければいいのかというとそういうわけでもないんですが…
C++の前に萌えた言語(システム)がCLOSである私としては切ない気持ちです。> マイナー化

232:デフォルトの名無しさん
06/12/05 22:07:30
rvalue referenceってなんなのさ？

233:デフォルトの名無しさん
06/12/05 22:37:14
ここで。

A Brief Introduction to Rvalue References
URLﾘﾝｸ(www.open-std.org)

234:デフォルトの名無しさん
06/12/05 22:49:58
>>233
よく纏まっていてわかりやすいね。

235:デフォルトの名無しさん
06/12/06 09:50:22
auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう

236:デフォルトの名無しさん
06/12/06 12:13:53
>>235
一度、標準に採用されたらベンダーの独自拡張じゃないから安心して使ってねっていう
意味を暗に含むから非推奨にはなっても廃止はまずありえんだろうな。

237:デフォルトの名無しさん
06/12/07 04:52:50
ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。

ストラスストラップのハゲの残り少ない髪の毛引き抜いて
クローンハゲを量産して、規格の策定に充てるとかすればいいんじゃないのかと思った。

238:デフォルトの名無しさん
06/12/08 18:26:39
その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし

239:デフォルトの名無しさん
06/12/09 01:08:57
ここで>>217に戻る。

240:デフォルトの名無しさん
06/12/09 01:15:54
まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし

241:デフォルトの名無しさん
06/12/09 05:11:42
>パフォーマンスゲインも5倍

なにその機動戦士ガンダム

242:デフォルトの名無しさん
06/12/09 09:13:34
こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。

243:デフォルトの名無しさん
06/12/09 12:42:51
コンパイル時間も5倍に…

244:デフォルトの名無しさん
06/12/09 12:56:47
>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ

245:デフォルトの名無しさん
06/12/09 16:56:31
父さん、言語拡張症にかかって…

246:デフォルトの名無しさん
06/12/09 22:35:18
これからは言語のモジュール化ですよ。

247:デフォルトの名無しさん
06/12/10 07:07:20
>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？

248:デフォルトの名無しさん
06/12/10 08:50:22
>>247
お前マジ天才じゃね？

249:デフォルトの名無しさん
06/12/10 10:16:27
最終的には今日コンパイルすると昨日完了するようになる

250:デフォルトの名無しさん
06/12/10 10:20:32
そのコンパイラでコンパイラをコンパイルさせてください。

251:デフォルトの名無しさん
06/12/10 10:53:35
おまいらホント暇だなｗ

252:デフォルトの名無しさん
06/12/10 17:55:34
最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？

253:デフォルトの名無しさん
06/12/10 19:57:26
ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか

254:デフォルトの名無しさん
06/12/10 20:04:18
autoはC++09に確実に入るんじゃないのかな?

255:デフォルトの名無しさん
06/12/10 20:17:08
標準委員会、キーワード追加症にかかって…

256:デフォルトの名無しさん
06/12/10 20:22:14
>>254 それはずっと前からキーワード。

257:デフォルトの名無しさん
06/12/10 20:56:19
意味が変更される予約語はautoだけかな

258:デフォルトの名無しさん
06/12/14 13:27:42
しかしautoはどうかと思う…
型の弱い言語みたいだ

259:デフォルトの名無しさん
06/12/14 13:32:51
初期化される時点で型が決まってしまうのに、どこが弱いんだか。

260:デフォルトの名無しさん
06/12/14 14:11:35
コンパイル時に型が決定するのだから、弱いわけがないわな。

261:デフォルトの名無しさん
06/12/14 14:17:45
しかしtemplate引数の省略はどうかと思う・・・
型の弱い言語みたいだ

262:デフォルトの名無しさん
06/12/14 14:19:49
しかしboost.Anyが実装できるのはどうかと思う。
型の弱（ｒｙ

263:デフォルトの名無しさん
06/12/14 19:08:59
キャス(ry

264:デフォルトの名無しさん
06/12/14 20:18:58
vo(ry

265:デフォルトの名無しさん
06/12/14 20:29:55
悲しいかな、reinterpret_castやvoid*などの存在で、
C++が弱い型付けと分類されていることを見かける。

266:デフォルトの名無しさん
06/12/14 20:44:04
まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの

267:デフォルトの名無しさん
06/12/14 21:48:36
その理屈だと、アセンブラは弱い肩か？

268:デフォルトの名無しさん
06/12/14 23:04:19
アセンブラは弱すぎ。虚弱体質だな。

269:デフォルトの名無しさん
06/12/14 23:12:43
低級言語は型とかないだろ

270:デフォルトの名無しさん
06/12/14 23:31:02
>>265
まさにカタ無しだね

271:デフォルトの名無しさん
06/12/15 00:04:48
しかしこのスレの流れはどうかと思う。
頭の弱い……

272:デフォルトの名無しさん
06/12/21 11:30:13
JIS X3014:2003って、
ISO/IEC 14882:2003の逐語訳じゃないんですね。
省略されているところがあってびっくりしました。

13.3.1.2.3のnon-memberのところ。

273:デフォルトの名無しさん
07/01/03 19:15:16
>>272
JISチームのチョンボで抜けちゃったとかじゃなくて？
そういえば、JIS X3014:2003 って買った時期によってPDFの"しおり"があったりなかったり
するらしいね。なんか以前、cppll で金返せ的なことを愚痴ってたヤツがいた。

274:デフォルトの名無しさん
07/01/12 19:40:21
シンボルの undef とこっから先 const の機能がほしい
スレ違いか？

275:デフォルトの名無しさん
07/01/12 20:41:03
シンボルの undef というか、スコープ付の define がほしい。

ここから先 const はいらんなあ。値を変えるところと変えないところで
関数が分かれてないのは設計ミスだと思う。

276:デフォルトの名無しさん
07/01/12 22:21:49
派生の禁止はできるようにならんの？

277:デフォルトの名無しさん
07/01/12 22:29:27
URLﾘﾝｸ(article.gmane.org)

278:デフォルトの名無しさん
07/01/12 23:23:42
あーなるほどね、宣言は出来るけどインスタンスは作れない、と。

279:デフォルトの名無しさん
07/01/12 23:29:21
>>273
>JISチームのチョンボ
まことしやかにささやかれてるけど真実味あるなｗ

280:デフォルトの名無しさん
07/01/13 03:24:39
>>276
あと、派遣の禁止も欲しいよなぁ。

281:デフォルトの名無しさん
07/01/13 23:29:46
>>277
古い。illegal

noninheritableがどっかにあったな

282:デフォルトの名無しさん
07/01/13 23:44:57
boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。

283:デフォルトの名無しさん
07/01/13 23:47:38
-ableにnotは不味いだろ。

284:デフォルトの名無しさん
07/01/13 23:50:06
>>283
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

285:デフォルトの名無しさん
07/01/13 23:51:08
>>282
英語的にはunが正しい。
何故nonになっているのかは不明

286:デフォルトの名無しさん
07/01/13 23:56:44
im と un を混同したのではないか

287:デフォルトの名無しさん
07/01/14 08:33:30
Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。

288:デフォルトの名無しさん
07/01/14 17:09:42
それは俺の戯言なので真に受けないように

289:デフォルトの名無しさん
07/01/14 22:53:43
Effectice C++ 3版でも突っ込まれてたような

290:デフォルトの名無しさん
07/01/26 20:55:16
URLﾘﾝｸ(en.wikipedia.org)
右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね？

291:デフォルトの名無しさん
07/01/27 09:21:41
未定

292:wankuma
07/01/27 19:20:53
わんくま加盟求む
URLﾘﾝｸ(blogs.wankuma.com)

293:デフォルトの名無しさん
07/02/19 19:49:16
URLﾘﾝｸ(herbsutter.spaces.live.com)
>we finish the document in 2009, but because ISO takes most of
>a year to approve and publish a standard, it would end up as
>"C++10" (or, one could uncomfortably imagine, "C++0a").

294:デフォルトの名無しさん
07/02/19 20:04:02
もうC++0fでいいよ。

295:デフォルトの名無しさん
07/02/20 03:31:04
どうせVC7.1であと10年がんばるんですよ

296:デフォルトの名無しさん
07/02/20 08:41:21
>>295
スレ違い。

297:デフォルトの名無しさん
07/02/20 12:48:39
>>157

298:デフォルトの名無しさん
07/03/03 09:39:19
vector<int> v;
auto var = v.begin();

と型推論？ぽい事ができる様になるらしいですが、
この時のvarの型は
vector<int>::iterator
になるんでしょうか　それとも
vector<int>::const_iterator?

299:デフォルトの名無しさん
07/03/03 10:30:49
前者でないと困る。
前者なら、後者はauto const varという宣言で済むと思うが。

300:デフォルトの名無しさん
07/03/03 10:34:50
そうすると、vector<int>::const_iteratorではなくて、
cont vector<int>::iteratorになりそうな

301:デフォルトの名無しさん
07/03/03 11:14:10
const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

302:デフォルトの名無しさん
07/03/03 11:19:20
ああboost::cref使えば良さそうな気がする

303:デフォルトの名無しさん
07/03/03 11:20:36
vector<int> v;
auto var = const_cast<const vector<int>&>(v).begin();
これでいいでしょ？

304:デフォルトの名無しさん
07/03/03 11:24:56
vをconstにしたいって話でcref？

305:デフォルトの名無しさん
07/03/03 11:27:11
>>303
それやるならstatic_castだろ。

型名書くのがめんどくさい場合はcrefじゃね？

306:デフォルトの名無しさん
07/03/03 11:28:58
C++0xを知らんけど
そんなことしてまでauto使う意味わかんね。

307:デフォルトの名無しさん
07/03/03 11:31:24
どっちかっていうと
そんなことまでしてconst_iteratorにする意味わかんね。

308:デフォルトの名無しさん
07/03/03 11:48:48
こういう手もある。まあかえって長ったらしくなっているけど。
boost::range_const_iterator<decltype(v)>::type　var　=　v.begin();

309:デフォルトの名無しさん
07/03/03 11:57:47
アホが来た

310:デフォルトの名無しさん
07/03/03 12:03:54
>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね？
URLﾘﾝｸ(www.open-std.org)

最新のドラフトには載ってるから、採用されたのかな？

311:デフォルトの名無しさん
07/03/03 12:23:44
boost::cref (std::tr1::cref) では無理なのでは？

template< class T >
T const &as_const( T &x )
{ return x; }

とか作って使うのではダメなん？

312:デフォルトの名無しさん
07/03/03 13:02:44
#include <iostream>
#include <vector>
#include <tr1/functional>

using namespace std;

int main(void)
{
　　　　vector<int> v(10);
　　　　cout << typeid(v.begin()).name() << endl;
　　　　cout << typeid(tr1::cref(v).get().begin()).name() << endl;
　　　　return 0;
}

313:デフォルトの名無しさん
07/03/03 13:16:55
boostにconst_beginってなかったっけ？

314:デフォルトの名無しさん
07/03/03 13:20:02
こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。

315:デフォルトの名無しさん
07/03/03 13:27:28
>>312
get() 使うなら当然できるけれど，それなら311で良いのでは？

316:デフォルトの名無しさん
07/03/03 19:12:34
v.begin()じゃなくて、begin(v)を使う派なのだが
（これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる）
こんな人にも、autoは役に立つのかしらん？

317:デフォルトの名無しさん
07/03/03 20:28:01
auto v = v.begin() const;
みたいな呼び出しができたらいいのにと思った

318:デフォルトの名無しさん
07/03/03 20:38:02
const audo v = v.begin()
の方がいいかも！？と思った

319:デフォルトの名無しさん
07/03/03 22:25:17
>>318
>>300
流れよめんのか

320:デフォルトの名無しさん
07/03/05 08:00:08
const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

321:デフォルトの名無しさん
07/03/05 09:26:00
containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、URLﾘﾝｸ(www.open-std.org)

二バージョンないケースでは、何か工夫する必要があるね。

322:デフォルトの名無しさん
07/03/05 10:13:24
一文字の接頭辞が複数続くのってなんかいやん
crend とかなにって感じー

323:デフォルトの名無しさん
07/03/07 00:05:13
何だかんだで、const auto& cv(v);
してから、cv.begin(), cv.end() が一番読みやすいかも

324:デフォルトの名無しさん
07/03/07 16:48:34
数学の関数とかみたいに
コンパイル時に式自体
を計算・展開できるような式関数導入して欲しい。

325:デフォルトの名無しさん
07/03/07 18:43:00
実装も添えて提案して頂かないとイメージが沸かない

326:デフォルトの名無しさん
07/03/07 20:01:57
>>324

つまり
int　a　=　5+1;
は、コンパイラが
int　a　=　6;
としてコードを生成してくれるってことか。

inline　int　func(int　x)　{　return　x*2;　}
int　c　=　func(5);
をコンパイラが
int　c　=　10;
にしてくれるとか。

sinはコンパイラではなくコンパイル後に
リンクするライブラリにある処理だから難しいな。

LUTを作るの面倒だから判らなくもない。

327:デフォルトの名無しさん
07/03/07 20:07:41
今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。

328:デフォルトの名無しさん
07/03/07 20:43:12
>>326
少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と
規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。

329:デフォルトの名無しさん
07/03/07 23:01:37
がんばってtemplateでsinを実装するんだ(w

330:デフォルトの名無しさん
07/03/07 23:04:59
整数演算だけでか？ｗ

331:デフォルトの名無しさん
07/03/07 23:15:43
前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。

332:デフォルトの名無しさん
07/03/07 23:26:01
コンパイル時変数と実行時変数を明示的に区別して定義できるようにならないかなあ。
いっそのことプログラムの実行そのものをコンパイル時と実行時で分けて、
コンパイル時実行ではインタプリタ型で動いて、コンパイル時変数にのみアクセス可能で
JavaScriptばりにクラスのメンバ関数の追加や削除、関数の構成、evalができて、とか。

333:デフォルトの名無しさん
07/03/07 23:29:13
D 言語でいいよ、もう。

334:324
07/03/08 00:03:20
同様にmy_cos,my_tanを作って
my_tan:=my_sin/my_cos;
という関係を作っておく。

my_sin(x)/my_cos(x)という式を使ったときは左記の関数はCallされずに
my_tan(x)がCallされて計算されるといった感じのもの。

//いいかげんなmy_sinの例
template <typename T> T my_sin(T x)
where Type(T,Re) //T：実数
{
calc{return x(1-x*x/6);}//計算値
expr(T a){my_sin(a);}//計算式
}

335:デフォルトの名無しさん
07/03/08 00:05:30
スクリプトでも使ってジェネレートした方がはやくね？

336:デフォルトの名無しさん
07/03/08 00:40:01
プリプロセッサ強化だな。

337:デフォルトの名無しさん
07/03/08 01:35:03
URLﾘﾝｸ(video.google.com)
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。

338:デフォルトの名無しさん
07/03/08 09:01:29
templateの処理をプリプロセッサの役割とする
↓
Cでもtemplateできるようにする。

339:デフォルトの名無しさん
07/03/08 09:50:31
Cfrontみたいだな

340:デフォルトの名無しさん
07/03/08 11:46:16
もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ　

341:デフォルトの名無しさん
07/03/08 16:12:16
>>340
「バカヤロウ、まだ始まってもいねえよ。」

342:デフォルトの名無しさん
07/03/08 16:34:10
互換性はあるんじゃないか？今までのが非推奨になる感じで

343:デフォルトの名無しさん
07/03/08 16:35:46
old style cast とかどうするんだろ

344:デフォルトの名無しさん
07/03/08 18:25:58
>>324
再帰はできないわ，まともな制御構文はないわ，で良ければ一応
C++0x に向けて active に動いているっぽい提案
URLﾘﾝｸ(www.open-std.org)
いずれにしろ，元々が traits などに使われるのを想定した提案ですので非力極まりない

もっと抜本的な提案なら
URLﾘﾝｸ(www.open-std.org)
ですけれど，こちらは C++0x には間に合わない様子

345:デフォルトの名無しさん
07/03/14 20:34:06
C++0a になりそうな気配が濃厚になってまいりました

346:デフォルトの名無しさん
07/03/15 00:49:43
C++0x2010でいいからもう

347:デフォルトの名無しさん
07/03/15 23:22:40
それは勘弁してw

348:デフォルトの名無しさん
07/03/16 00:23:13
C+(+0x2010)
→　0x201C
いや、わかっているよ、こう解釈されないことくらい。

349:デフォルトの名無しさん
07/03/16 15:02:28
>>346
8208www

350:デフォルトの名無しさん
07/03/26 18:39:26
C++2008

351:デフォルトの名無しさん
07/03/28 02:06:06
可変個引数テンプレート(Variadic Templates)だけど、template の specialization を使って一つづつ取り出していくだけかと思ったらなかなかすごいことになってるのね。

こんな展開が可能だったり、
---
template<typename...> struct Tuple {};
template<typename T1, typename T2> struct Pair {};

template<typename... Args1> struct zip {
　　template<typename... Args2> struct with {
　　　　typedef Tuple<Pair<Args1, Args2>...> type;
　};
};

typedef zip<short, int>::with<unsigned short, unsigned>::type T1;　// T1 is Tuple<Pair<short, unsigned short>, Pair<int, unsigned> >
---

これで任意引数個の perfect forwarding function になったり(rvalue reference利用)
---
template<typename T>
struct allocator {
　　template<typename... Args>
　　void construct(T* ptr, Args&&... args) { new (ptr)(static cast<Args&&>(args)...); }
};
---

Variadic Templates の概要は↓がわかりやすい
URLﾘﾝｸ(www.open-std.org)
↓は規格の変更点について
URLﾘﾝｸ(www.open-std.org)
GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。
URLﾘﾝｸ(conceptgcc.wordpress.com)
おまいらもヒトバシラーしてみませんか？

352:デフォルトの名無しさん
07/03/28 08:47:26
Variadic Templates、入るかねえ?

353:デフォルトの名無しさん
07/04/01 22:08:44
>352
何か具体的な懸念が？
提案者自身は
>Variadic templates seem to be moving smoothly,
と言ってるけどね。
URLﾘﾝｸ(conceptgcc.wordpress.com)

354:デフォルトの名無しさん
07/04/12 07:04:47
URLﾘﾝｸ(www.devsource.com)
によれば、template aliases が入ることになっているなあ。嬉しい。

355:デフォルトの名無しさん
07/04/16 20:57:47
nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど
そういうのはないんかな

356:デフォルトの名無しさん
07/04/16 21:18:55
#define nameof(x) typeid(x).name()

357:デフォルトの名無しさん
07/04/16 21:21:15
typeid(hoge).name()があるでしょ。
マングルされてたりいろいろ面倒だけど。

358:デフォルトの名無しさん
07/04/16 22:08:34
typeid().name()は正直使えない

359:デフォルトの名無しさん
07/04/16 22:13:47
まあ保証されている事と言えば同一の型のname()も同一である
という事だけだからな
リフレクションのような事は正直無理

360:デフォルトの名無しさん
07/04/27 00:24:43
>352
URLﾘﾝｸ(conceptgcc.wordpress.com)
だそうな。

361:デフォルトの名無しさん
07/04/27 07:28:21
まじか。
機能的にはC++0xに入る必然性があるけれど、
さらにデバックしにくくなりそう…

variadic templatesを直接使う人じゃなくて、
variadic templatesが使われたlibraryを使う人ね。
エラーメッセージがさらにハナモゲラ化w

362:デフォルトの名無しさん
07/04/27 12:49:13
>>361
現状でも Boost.Function とか Boost.Variant とか
BOOST__PP_* で T0,T1,T2,... を生成してるやつは
エラーメッセージがハナモゲラ化してるわけで

その部分が T0... みたいに可変長ぽく省略表示されるだけで
だいぶ見やすくなると思うんだが

363:デフォルトの名無しさん
07/05/14 14:22:20
concept が入ればエラーメッセージはかなりましになるのでは？

364:デフォルトの名無しさん
07/05/14 14:24:15
URLﾘﾝｸ(www.open-std.org)

365:デフォルトの名無しさん
07/05/28 01:09:30
ほ

366:デフォルトの名無しさん
07/05/31 00:47:25
とりあえずC99準拠で

367:デフォルトの名無しさん
07/05/31 01:59:00
C99はC++の精神に反しているのに
実装にはC++の機能が必要というトンデモ言語

368:デフォルトの名無しさん
07/05/31 03:13:42
C++の精神自体がトンデモの塊だから問題ない

369:デフォルトの名無しさん
07/05/31 06:35:41
Javaのキャストみたいなもんだな

370:デフォルトの名無しさん
07/05/31 06:43:51
c99にc++の機能が必要とは初耳だな。

371:デフォルトの名無しさん
07/05/31 06:56:08
コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？

372:デフォルトの名無しさん
07/05/31 07:09:44
内容的には>>360 >>364で既出ですが、URLﾘﾝｸ(herbsutter.spaces.live.com)より

New Language Features Voted Into (Draft) C++09
・Template aliases (aka typedef templates, generalized typedefs) [N2258]
・Variadic templates (aka "type varargs" for templates) [N2242; see N2087 for a more readable description and rationale]
・Unicode characters and strings [N2249]
・Rvalue references [N1952]

373:デフォルトの名無しさん
07/05/31 16:54:12
へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。

374:デフォルトの名無しさん
07/05/31 17:46:31
すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。

375:デフォルトの名無しさん
07/05/31 19:57:46
これですな
URLﾘﾝｸ(www.open-std.org)

そのうちstd::u16stringとかstd::u32stringとかもできるんだろか

376:373
07/06/01 00:57:02
入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。

377:デフォルトの名無しさん
07/06/01 01:12:11
L"文字列" はどういう扱いになるん？

378:デフォルトの名無しさん
07/06/01 01:36:05
こんな感じかな？

wchar_t wc = L'あ';　// wcの値は実装依存 (今と同じ)
char16_t c16 = u'あ';　// c16は0x3042
char32_t c32 = U'あ';　// c32は0x00003042

379:デフォルトの名無しさん
07/06/01 01:39:40
UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？

380:デフォルトの名無しさん
07/06/01 01:40:47
あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。

381:デフォルトの名無しさん
07/06/01 01:44:07
UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする

382:デフォルトの名無しさん
07/06/01 08:22:04
>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?

383:デフォルトの名無しさん
07/06/01 08:22:49
>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。

384:デフォルトの名無しさん
07/06/01 08:35:43
下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ

385:デフォルトの名無しさん
07/06/01 09:07:21
uint8_tと読み直せばいいんじゃない。

386:デフォルトの名無しさん
07/06/01 09:09:30
uint8_t って optional だったよね。

387:デフォルトの名無しさん
07/06/01 13:30:21
何年か経ったらwchar_tはいらない子扱いされてそうだ

388:デフォルトの名無しさん
07/06/01 15:19:52
tcharでいいじゃん

389:デフォルトの名無しさん
07/06/01 16:02:57
>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw

390:デフォルトの名無しさん
07/06/01 16:43:08
>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375

391:デフォルトの名無しさん
07/06/01 17:00:04
どうせウニコードなんか窓しか使わないのにイラネ

392:デフォルトの名無しさん
07/06/01 17:05:18
>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ

393:デフォルトの名無しさん
07/06/01 17:14:12
LinuxもUTF-8なご時世になんて寝言を……

394:デフォルトの名無しさん
07/06/01 17:43:00
ふつーにEUC

395:デフォルトの名無しさん
07/06/01 18:46:06
Unicode関連のロケールが標準に入ると考えていいんだろうか・・

396:デフォルトの名無しさん
07/06/01 20:20:04
CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？

397:デフォルトの名無しさん
07/06/01 20:53:50
8は保証されてるの？

398:デフォルトの名無しさん
07/06/01 21:14:54
下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。

399:デフォルトの名無しさん
07/06/02 11:33:29

世の中のプログラマのほとんどが

>どうせウニコードなんか窓しか使わないのにイラネ

と思っていたはずなのに

>LinuxもUTF-8なご時世になんて寝言を……

になってしまったのはいつから？なぜ？

400:デフォルトの名無しさん
07/06/02 11:43:17
>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。

401:デフォルトの名無しさん
07/06/02 11:44:01
そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。

なんだかんだ言ってもUnicode周辺には、
"Technical Notes", "Technical Reports"その他に、
ノウハウがたまってきているので、強力にサポートすべき。

wchar_tの実装をUnicode onlyにするなんてのには大反対。
n2249はGJ。

402:デフォルトの名無しさん
07/06/02 11:55:15
じゃぁ、wchar_t はTRON用ということでおｋ？

403:デフォルトの名無しさん
07/06/02 12:29:48
TRONはwwchar_tです。

404:デフォルトの名無しさん
07/06/02 13:10:56
でも、Windows は UTF-16 なんだよな？

405:デフォルトの名無しさん
07/06/02 13:31:23
>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。

406:デフォルトの名無しさん
07/06/02 13:41:47
どちらにしろ UTF-16 だろ？

407:デフォルトの名無しさん
07/06/02 15:39:01
つWM_UNICHAR
URLﾘﾝｸ(msdn2.microsoft.com)

408:デフォルトの名無しさん
07/06/02 18:51:20
char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。

409:デフォルトの名無しさん
07/06/02 19:15:39
C95みたいに後から追補出せばいいよ

410:デフォルトの名無しさん
07/06/02 19:44:42
streamやfacetsは対応しないみたい
URLﾘﾝｸ(www2.open-std.org)

あとUTF-8の案もあった
今のところWDには含められていないけど
URLﾘﾝｸ(www2.open-std.org)

プリフィックスは E で、1バイト8ビット以上を保証すると

411:デフォルトの名無しさん
07/06/02 21:41:23
>streams of non-char types have not attracted wide usage, so it is not clear
>that there is a real need for

う～ん…8bit圏の人にとっちゃそうかもしれんけどさ。

412:デフォルトの名無しさん
07/06/02 22:39:06
まあその辺はゆっくりやって、後から補完でいいんじゃないの?
Primitive typeとして導入されたわけだから、
いろいろ実装してみるための最低限のことは決まるわけだからさ。
typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。

413:デフォルトの名無しさん
07/06/02 22:59:52
Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。

414:デフォルトの名無しさん
07/06/02 23:14:12
WCHARあるからねー

415:デフォルトの名無しさん
07/06/03 00:28:53
>>413
意味が分からない。
どれに対するレス?

416:デフォルトの名無しさん
07/06/03 00:29:10
Windowsなんかうんこ

417:デフォルトの名無しさん
07/06/03 00:29:51
>>415
>>411

418:デフォルトの名無しさん
07/06/03 00:35:57
char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが

419:デフォルトの名無しさん
07/06/03 00:35:59
それはWindowsにはニュートラルな話。

420:デフォルトの名無しさん
07/06/03 00:37:38
Windowsとか持ち出してるのはただの馬鹿だろ

421:デフォルトの名無しさん
07/06/03 00:46:50
>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。

422:デフォルトの名無しさん
07/06/03 00:56:23
GCC だと wchar_t は 4 だったな。

423:デフォルトの名無しさん
07/06/03 01:00:45
>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。

424:デフォルトの名無しさん
07/06/03 01:27:10
char16_t, char32_tの入った処理系では、
typedef char16_t wchar_t か、typedef char32_t wchar_t で、
wchar_tなライブラリも使えるし、char*_tなライブラリも構築していけるし、
とりえあえずは問題ないんじゃない?

>>423
utf-32が扱える処理系では、
wchar_tが2 byteだと規格違反だけどね。

>Type wchar_t is a distinct type whose values can represent distinct codes for all members
>of the largest extended character set specified among the supported locales (22.1.1).

425:デフォルトの名無しさん
07/06/03 01:32:30
なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。

426:デフォルトの名無しさん
07/06/03 02:03:02
wchar_tがUnicodeじゃない処理系ってあるのかな？

427:デフォルトの名無しさん
07/06/03 02:10:30
>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?

428:デフォルトの名無しさん
07/06/03 04:26:58
GCC　4.3にC++0xの実験的サポート
URLﾘﾝｸ(gcc.gnu.org)

429:デフォルトの名無しさん
07/06/03 04:55:14
>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。

@todo Implement this function.
@todo Document this function.
だらけだった。

430:デフォルトの名無しさん
07/06/03 05:36:10
w

431:デフォルトの名無しさん
07/06/04 22:53:08
MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。

432:デフォルトの名無しさん
07/06/05 01:37:14
C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。

433:デフォルトの名無しさん
07/06/05 22:01:36
久しぶりにスレ伸びたな～

434:デフォルトの名無しさん
07/06/05 23:26:19
まあ全部俺の一人芝居なんだけどな

435:デフォルトの名無しさん
07/06/06 01:57:38
同感

436:デフォルトの名無しさん
07/06/06 10:51:13
全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。

437:デフォルトの名無しさん
07/06/06 12:41:13
それがまさに独り芝居というものでは？

438:デフォルトの名無しさん
07/06/06 13:20:54
自問自答++

439:デフォルトの名無しさん
07/06/06 14:47:48
そうか、僕はここにいてもいいんだ！

440:デフォルトの名無しさん
07/06/06 16:22:24
おめでとう

441:デフォルトの名無しさん
07/06/06 16:54:37
>>431-432
まあでもC++0xに全く無関心でない様子は伺える
URLﾘﾝｸ(blogs.msdn.com)

442:デフォルトの名無しさん
07/06/06 17:40:42
そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。

443:デフォルトの名無しさん
07/06/06 17:56:40
struct S {

　　int m;
};

sizeof(S::m)

これが規格外だったなんて知らなかった。
そういえばこれは合法になるのかな？

template < typename T >
class Foo
{
　　friend T ;
}

444:デフォルトの名無しさん
07/06/06 18:38:36
>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う

次ページ