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

C++0x ..

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かなんかで話題にあがったが、確か違法だったと思う

445:デフォルトの名無しさん
07/06/06 18:48:08
いや、C++0xではどうなるかという話なんだけど。

446:デフォルトの名無しさん
07/06/06 22:03:04
friend のはこれ？ (PDF)

URLﾘﾝｸ(www.open-std.org)

447:デフォルトの名無しさん
07/06/07 03:54:58
443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる

448:デフォルトの名無しさん
07/06/07 05:25:03
sizeof(S().m)みたいに一時インスタンス化すればおｋ？

449:デフォルトの名無しさん
07/06/08 12:09:52
OKでしょ。

450:デフォルトの名無しさん
07/06/17 22:03:19
ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。

451:デフォルトの名無しさん
07/06/17 22:07:28
いっそUnicode str;を入れようぜ

452:デフォルトの名無しさん
07/06/17 22:57:31
>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。

453:デフォルトの名無しさん
07/06/17 22:58:22
>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下

454:デフォルトの名無しさん
07/06/17 23:00:08
じゃ、_Unicode str;

えーい、いっそのことソースコードもUTF8強制して

文字 str = L"こんちには世界";

って書けるようにしようぜ？

455:デフォルトの名無しさん
07/06/17 23:23:48
まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う

456:デフォルトの名無しさん
07/06/17 23:30:08
>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。

457:デフォルトの名無しさん
07/06/17 23:34:21
ワイドな文字ってよく考えると意味不明だよね

458:デフォルトの名無しさん
07/06/17 23:37:11
仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ

459:デフォルトの名無しさん
07/06/17 23:39:23
もうUTF8って名前に決めちゃえばいいよ

460:デフォルトの名無しさん
07/06/18 08:27:41
ちょっと上の話題ぐらい読もうや。

461:デフォルトの名無しさん
07/06/18 08:36:17
>>458
UTF-8はmbs、つまりchar[]だろ。

462:デフォルトの名無しさん
07/06/18 22:47:59
>>452
確かに、2Byte=WORDという意味でword char
をwcharとするなら、別に構わないが、wchat_tと
書くと、いかにも規格外で後からつけました感が
あって、気に入らんのだがねぇ。それより、
shortやlongといった元からあり、且つwordの様に
変数のサイズを2Byteとか具体的に意識させない型の方が、
自然な感じがするんだけどねぇ。

463:デフォルトの名無しさん
07/06/18 22:50:57
名前の衝突を避けるにはダサネーミングはある程度しかたない

_Boolとかunorderd_mapとかダサすぎるし

464:デフォルトの名無しさん
07/06/18 23:10:05
ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）

465:デフォルトの名無しさん
07/06/18 23:10:16
virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・

466:デフォルトの名無しさん
07/06/18 23:25:01
>>462
wchar_tのwは、wideでは？

467:デフォルトの名無しさん
07/06/18 23:47:46
>>450のshort　charとか、long　charとかで思い出したけど、
昔、整数型のshort　(int)　-　int　-　long　(int)からの連想で、
浮動小数点数型も、short　float　-　float　-　long　floatにすれば良かったのにと考えたことがあった

468:デフォルトの名無しさん
07/06/19 00:32:15
そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。

469:デフォルトの名無しさん
07/06/19 01:35:30
>>464
C++では予約語だが、Cではそうではない。

470:デフォルトの名無しさん
07/06/19 01:41:38
_Bool は仕方がないとは思うが失笑したな。

471:デフォルトの名無しさん
07/06/19 02:37:05
wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな

472:デフォルトの名無しさん
07/06/19 02:40:36
MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。

473:デフォルトの名無しさん
07/06/19 04:43:21
>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ

474:デフォルトの名無しさん
07/06/19 20:23:00
>>462
　そうだね勉強するよ。
　そういえば、1語長2語長なんて言葉もあったね。(敢えて言うが、
勿論1語長が1Byteなどと思っているわけではない。)
MSのAPIの影響(DWORDとかQWORDとか)でWORDを2byteと仮定して書いてしまった。
　あと、wchar_tはwide charなのにword charと書いたのは、素で間違えた。

　それはそうと、C++0xが実現するとObjective-C++やC++/CLIはどうなるんだ
ろうねぇ。三者三様の完全別言語路線に進むのか？0xに合わせてそれぞれ拡張
するのはは厳しい気がするが。実装的に。

475:474
07/06/19 20:25:01
訂正

× >>464
○ >>473

自分を指して何やってんだが…。

476:474
07/06/19 20:29:41
また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。

477:デフォルトの名無しさん
07/06/19 20:30:02
もともとobj-cはC++とは全然別物だろうに

478:デフォルトの名無しさん
07/06/19 22:43:01
>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。

まぁ、あんまり気を落とすな。

479:デフォルトの名無しさん
07/06/19 22:58:22
gccがsizeof(wchar_t)==4でいいんだったっけ

480:デフォルトの名無しさん
07/06/19 23:51:09
-fshort_wchar フラグを指定したら 2 になるけどな。

481:デフォルトの名無しさん
07/06/20 02:58:24
>>474
C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。
しかし純然たる研究者だったはずの二人が、
どうしてC++/CLIに必死なのか良くワカランネ。
契約になんか書かれているのかな。

482:デフォルトの名無しさん
07/06/20 08:40:01
C++0x実現まであと9年もあるから大丈夫

483:デフォルトの名無しさん
07/06/21 22:32:37
>479
cygwin 上だと gcc でも 2。

484:デフォルトの名無しさん
07/06/22 01:24:22
今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。

亡くなって当然ｗ

485:デフォルトの名無しさん
07/06/22 01:24:48
>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・

486:デフォルトの名無しさん
07/06/22 01:44:27
後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?

487:デフォルトの名無しさん
07/06/22 22:10:11
え、VC の cl にだけど

488:デフォルトの名無しさん
07/06/23 10:46:35
マイクロソフトは規格への追従遅いじゃん。
メジャー番号が変わるまで延々放置って事がよくある。
スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。

489:デフォルトの名無しさん
07/06/24 21:02:05
C++1xに名前変えるか

490:デフォルトの名無しさん
07/06/25 06:03:52
何でこんなに時間掛かるんだろう？

491:デフォルトの名無しさん
07/06/25 09:41:11
やっつけでやられても困る。

492:デフォルトの名無しさん
07/06/25 13:37:16
>>490
天才のお前が傍観者だからだよ

493:デフォルトの名無しさん
07/06/25 17:37:29
Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。

494:デフォルトの名無しさん
07/06/25 19:56:26
>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。

495:デフォルトの名無しさん
07/06/26 03:02:50
News 2007-06-25: C++ Standard Core Language Issues List (Revision 48) is available
News 2007-06-25: The C++ Standard Library Issues List (Revision 49) is available

今までC++相談室に貼ってた JTC1/SC22/WG21 の更新情報は
今回からこっちに貼ることにしました。

496:デフォルトの名無しさん
07/06/26 03:12:13
C++X
の方が魚の骨っぽくて好き

497:デフォルトの名無しさん
07/06/26 13:38:12
もう規格なんてやめてBoost全部取り込んじゃえよ

498:デフォルトの名無しさん
07/06/26 17:06:10
それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う

499:デフォルトの名無しさん
07/06/26 17:57:38
古い　Fortran　みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。

500:デフォルトの名無しさん
07/06/26 18:18:06
C++はPL/Iを超える化け物言語になりつつあるな。

501:デフォルトの名無しさん
07/06/26 22:21:29
Javaほどじゃないけどな

502:デフォルトの名無しさん
07/06/26 22:24:57
は？

503:デフォルトの名無しさん
07/06/26 22:31:00
またジャバグラマか。

504:デフォルトの名無しさん
07/06/26 23:26:45
そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ

505:デフォルトの名無しさん
07/06/26 23:27:57
禿が死ぬまでには出来てると思うから気長に待つよ

506:デフォルトの名無しさん
07/06/27 03:44:26
なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話

507:デフォルトの名無しさん
07/06/27 09:25:40
>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…

…いや、的確か

508:デフォルトの名無しさん
07/06/27 09:29:07
PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー

あ、でも糞言語だったけどね
消えたし

509:デフォルトの名無しさん
07/06/27 09:58:55
他の言語は要らなくなるから、Programming Language/1。

510:デフォルトの名無しさん
07/06/27 10:33:28
その　C++　と　Objective-C　を無理矢理繋げた変態言語の立場は。

511:デフォルトの名無しさん
07/06/27 22:21:53
お前ら頭良いんだからサッサと立派な規格でまとめてくれよ

512:デフォルトの名無しさん
07/06/27 22:24:43
よしきた

513:デフォルトの名無しさん
07/06/27 22:27:55
標準ヘッダファイル2chを追加

514:デフォルトの名無しさん
07/06/27 22:30:20
boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない

515:デフォルトの名無しさん
07/06/27 22:33:48
競争相手が無かったから

516:デフォルトの名無しさん
07/06/27 23:05:19
C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？

517:デフォルトの名無しさん
07/06/27 23:09:41
>JavaやLL言語のようなものはあっただろうか？

普通にあったんじゃない？

518:デフォルトの名無しさん
07/06/27 23:18:46
ねーよ。
C++の影響は計り知れない

519:デフォルトの名無しさん
07/06/28 01:15:28
cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。

520:デフォルトの名無しさん
07/06/28 01:34:50
その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。

521:デフォルトの名無しさん
07/06/28 09:02:38
勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。

522:デフォルトの名無しさん
07/06/28 09:09:11
C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。
こんなに人材が集まったことは今だかつてないんじゃないか?
C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。

523:デフォルトの名無しさん
07/06/28 12:08:12
C++ってマクロなんでしょ？

524:デフォルトの名無しさん
07/06/28 12:11:46
???

525:デフォルトの名無しさん
07/06/28 14:00:51
っ MFC

526:デフォルトの名無しさん
07/06/28 14:14:36
MFCとVC6は大量のC++挫折者を生み出しました

527:デフォルトの名無しさん
07/06/28 17:52:57
>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。

528:デフォルトの名無しさん
07/06/28 20:02:22
シェア90%のOSが推奨すれば広まって当然

529:デフォルトの名無しさん
07/06/28 21:26:08
じゃあこれからはドトネト天国だね

530:デフォルトの名無しさん
07/06/28 21:38:39
C#する気もしない気も～VMの性能にかかっているんだよ～

531:デフォルトの名無しさん
07/06/28 22:21:08
C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ

532:デフォルトの名無しさん
07/06/28 22:22:00
D が完成しさえすれば・・・。

533:デフォルトの名無しさん
07/06/28 22:50:37
ネイティブでGC無しというところが、
C++の強さにして弱み。

534:デフォルトの名無しさん
07/06/28 22:52:36
し、C++/CLIとかどうですか・・

535:デフォルトの名無しさん
07/06/29 00:03:58
Dもキメラ過ぎる

536:デフォルトの名無しさん
07/06/29 23:28:16
Dがもっとリッチに色々揃えば良いけど。

537:デフォルトの名無しさん
07/06/29 23:32:38
やっぱC++は最高だな

538:デフォルトの名無しさん
07/06/30 19:25:36
C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな

539:デフォルトの名無しさん
07/06/30 19:46:15
>533
でも委員会で GC の話してるみたいよ？

540:デフォルトの名無しさん
07/06/30 20:31:26
今のところHans Boehmの提案が最有力候補かな？

541:デフォルトの名無しさん
07/06/30 20:32:07
GC ねえ。
GC なしで組めるモードもあるんだよね？

542:デフォルトの名無しさん
07/06/30 21:19:39
C99に合わせたりはしないのかな。

543:デフォルトの名無しさん
07/06/30 21:37:25
>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ

544:デフォルトの名無しさん
07/06/30 22:30:57
>>542
だいたいのところは取り込まれてるみたい。

545:デフォルトの名無しさん
07/07/01 11:32:07
URLﾘﾝｸ(www.open-std.org)
News 2007-06-30: The 2007-06-pre-Toronto mailing is available

546:デフォルトの名無しさん
07/07/01 11:33:18
>>543
えーーー！

いくらなんでもそれは無くね？

547:546
07/07/01 11:34:11
勘違いしてた

「GCなしでも組める」事が必須条件なのね

ごめんなさい

548:デフォルトの名無しさん
07/07/01 11:51:16
C++的には、使わなければ余分なコストはかからないというのは必須だろ。

549:デフォルトの名無しさん
07/07/01 11:53:34
そこでGCCですよ

550:デフォルトの名無しさん
07/07/01 11:57:17
GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので

551:デフォルトの名無しさん
07/07/01 12:00:52
GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな

552:デフォルトの名無しさん
07/07/01 12:02:25
>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。

553:デフォルトの名無しさん
07/07/01 12:03:19
>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？

次ページ