5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++0x

1 :デフォルトの名無しさん:2006/06/05(月) 02:04:07
どんな感じになるの?

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

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


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

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

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

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

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

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

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

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

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

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

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

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

310 :デフォルトの名無しさん:2007/03/03(土) 12:03:54
>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf

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

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

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

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

312 :デフォルトの名無しさん:2007/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 :デフォルトの名無しさん:2007/03/03(土) 13:16:55
boostにconst_beginってなかったっけ?

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

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

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

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

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

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

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

321 :デフォルトの名無しさん:2007/03/05(月) 09:26:00
containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf

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


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

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

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


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

326 :デフォルトの名無しさん:2007/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 :デフォルトの名無しさん:2007/03/07(水) 20:07:41
今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。

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

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

330 :デフォルトの名無しさん:2007/03/07(水) 23:04:59
整数演算だけでか?w

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

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

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

334 :324:2007/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 :デフォルトの名無しさん:2007/03/08(木) 00:05:30
スクリプトでも使ってジェネレートした方がはやくね?

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

337 :デフォルトの名無しさん:2007/03/08(木) 01:35:03
ttp://video.google.com/videoplay?docid=-1790714981047186825
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。

338 :デフォルトの名無しさん:2007/03/08(木) 09:01:29
templateの処理をプリプロセッサの役割とする

Cでもtemplateできるようにする。

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

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

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

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

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

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

もっと抜本的な提案なら
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
ですけれど,こちらは C++0x には間に合わない様子

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

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

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

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

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

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

351 :デフォルトの名無しさん:2007/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 の概要は↓がわかりやすい
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf
↓は規格の変更点について
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2152.pdf
GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。
http://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/
おまいらもヒトバシラーしてみませんか?

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

353 :デフォルトの名無しさん:2007/04/01(日) 22:08:44
>352
何か具体的な懸念が?
提案者自身は
>Variadic templates seem to be moving smoothly,
と言ってるけどね。
ttp://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/#comment-131

354 :デフォルトの名無しさん:2007/04/12(木) 07:04:47
http://www.devsource.com/article2/0,1895,2061095,00.asp
によれば、template aliases が入ることになっているなあ。嬉しい。

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

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

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

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

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

360 :デフォルトの名無しさん:2007/04/27(金) 00:24:43
>352
ttp://conceptgcc.wordpress.com/2007/04/24/variadic-templates-are-in-c0x/
だそうな。

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

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



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

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


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

364 :デフォルトの名無しさん:2007/05/14(月) 14:24:15
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-05

365 :デフォルトの名無しさん:2007/05/28(月) 01:09:30


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

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

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

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

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

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

372 :デフォルトの名無しさん:2007/05/31(木) 07:09:44
内容的には>>360>>364で既出ですが、http://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 :デフォルトの名無しさん:2007/05/31(木) 16:54:12
へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。

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

375 :デフォルトの名無しさん:2007/05/31(木) 19:57:46
これですな
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html

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

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

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

378 :デフォルトの名無しさん:2007/06/01(金) 01:36:05
こんな感じかな?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

397 :デフォルトの名無しさん:2007/06/01(金) 20:53:50
8は保証されてるの?

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

399 :デフォルトの名無しさん:2007/06/02(土) 11:33:29

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

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

と思っていたはずなのに

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

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



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

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

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

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

402 :デフォルトの名無しさん:2007/06/02(土) 11:55:15
じゃぁ、wchar_t はTRON用ということでおk?

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

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

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

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

407 :デフォルトの名無しさん:2007/06/02(土) 15:39:01
つWM_UNICHAR
http://msdn2.microsoft.com/en-us/library/ms646288.aspx

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

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

410 :デフォルトの名無しさん:2007/06/02(土) 19:44:42
streamやfacetsは対応しないみたい
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html

あとUTF-8の案もあった
今のところWDには含められていないけど
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2209.html

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

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


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

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

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


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

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

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

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

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

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

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

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

424 :デフォルトの名無しさん:2007/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 :デフォルトの名無しさん:2007/06/03(日) 01:32:30
なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。

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

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


428 :デフォルトの名無しさん:2007/06/03(日) 04:26:58
GCC 4.3にC++0xの実験的サポート
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

429 :デフォルトの名無しさん:2007/06/03(日) 04:55:14
>>428
ワクワクテカテカしつつDLしてregexを見てみた。


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

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

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

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

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

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

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

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

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

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

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

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

441 :デフォルトの名無しさん:2007/06/06(水) 16:54:37
>>431-432
まあでもC++0xに全く無関心でない様子は伺える
http://blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx

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

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

  int m;
};

sizeof(S::m)

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

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

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

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

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

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

466 :デフォルトの名無しさん:2007/06/18(月) 23:25:01
>>462
wchar_tのwは、wideでは?

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

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

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

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

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

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

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

474 :デフォルトの名無しさん:2007/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:2007/06/19(火) 20:25:01
訂正

× >>464
>>473

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

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

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

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

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

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

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

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

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

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

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

亡くなって当然w

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

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

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

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

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

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

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

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

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

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

495 :デフォルトの名無しさん:2007/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 :デフォルトの名無しさん:2007/06/26(火) 03:12:13
C++X
の方が魚の骨っぽくて好き

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

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

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

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

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

502 :デフォルトの名無しさん:2007/06/26(火) 22:24:57
は?

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

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

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

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

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



…いや、的確か

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

546 :デフォルトの名無しさん:2007/07/01(日) 11:33:18
>>543
えーーー!

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

547 :546:2007/07/01(日) 11:34:11
勘違いしてた

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

ごめんなさい

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

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


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

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

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

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

554 :デフォルトの名無しさん:2007/07/01(日) 12:05:59
shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし

555 :デフォルトの名無しさん:2007/07/01(日) 12:07:50
なんだよかたそういう対照性か。
まさかソースコード上の対照性を言っているのかと思って心配になった。

556 :デフォルトの名無しさん:2007/07/01(日) 12:11:55
>>554
メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない?
削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。

557 :556:2007/07/01(日) 12:16:45
うーんもうちょっと調べ物してから言えばよかったかな。
あんまりはっきりしたこともいえないんで、スルー推奨。

558 :デフォルトの名無しさん:2007/07/01(日) 12:17:46
超基本的な質問なんだけど

GCありの場合でも自動変数がスコープ抜けた時とかにデストラクタは呼ばれるの?
その場合、そのクラスがフリーストアへのポインタを持っていた場合、
クラスのインスタンス自体は破棄されるけど、参照されていたメモリは
GCの場合はすぐに回収されないってことになるの?

559 :デフォルトの名無しさん:2007/07/01(日) 12:21:51
GCってオンオフするもんなの?
当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。
^とgcnewみたいなものじゃまずいのかなぁ。

560 :デフォルトの名無しさん:2007/07/01(日) 12:38:43
すみません
int a[] = new int[10];
int *b = new int[10];
みたいに確保したときって
delete a;
delete a[];
delete b;
delete b[];
それぞれ解放の仕方で動作おかしくなりますか?



561 :デフォルトの名無しさん:2007/07/01(日) 12:45:19
>>560 スレ違い。こっち逝け→ http://pc11.2ch.net/test/read.cgi/tech/1182740506/

562 :デフォルトの名無しさん:2007/07/01(日) 15:35:28
>>560
とりあえず Effective C++ でも買ってこい

563 :デフォルトの名無しさん:2007/07/01(日) 23:47:23
>>545
今回はいつもよりちと早めだね
小技系だが、N2332 がはげしく欲しい

564 :デフォルトの名無しさん:2007/07/02(月) 07:35:17
やっぱSL73だろ
http://gradeup.blog39.fc2.com/blog-entry-31.html

565 :デフォルトの名無しさん:2007/07/02(月) 09:24:38
みんな好き勝手いいやがって……だれが実装すると思ってるんだ

566 :デフォルトの名無しさん:2007/07/02(月) 12:50:56
>>563
make_*関数が要らなくなるのは確かに便利だな。

567 :デフォルトの名無しさん:2007/08/07(火) 08:31:37
最近のSutterは完全にC++/CLI宣伝だな。
そういう契約なのかな…

568 :デフォルトの名無しさん:2007/08/09(木) 21:18:40
最新のドラフトってこれでいいのかな?

# ISO/IEC 14882: Programming Language C++ - draft
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2315.pdf

569 :デフォルトの名無しさん:2007/08/09(木) 21:27:04
今日付けでn2369が出たみたい。

570 :デフォルトの名無しさん:2007/08/09(木) 22:45:56
今日付けw 何とタイムリーな。
こいつかな?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

571 :デフォルトの名無しさん:2007/08/09(木) 22:49:14
今日じゃないや、6日だ…

今月分のもろもろ。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-08

572 :デフォルトの名無しさん:2007/08/09(木) 23:50:33
decltype 追加か。細かい仕様はともかく、追加は確定なのかな。
あと alignas, alignof, constexpr も追加。
そして、char16_t, char32_t も追加? 色は変わってないけど。

constexpr は D のコンパイル時実行みたいなもんか。
メタプロの世界がまた1つ広がりそうだな。

alignas と alignof は構造体のアラインメント関連か。
alignas で指定して、alignof で取得する、といったところか。

char16_t と char32_t は UTF-16 と UTF-32 用の char だっけ?
何か前に話題に出てたよね。

573 :デフォルトの名無しさん:2007/08/10(金) 00:01:26
しかし、結構ドラスティックな変更が多いと思うけど、
こんなんがあと二年でまとまるんだろうか

574 :デフォルトの名無しさん:2007/08/10(金) 00:10:12
constexprは制限が強すぎて見た目ほど強力じゃなかったはず

575 :デフォルトの名無しさん:2007/08/10(金) 06:15:42
http://www.open-std.org/jtc1/sc22/wg21/
News 2007-08-09: The 2007-08-post-Toronto mailing is available
News 2007-08-09: C++ Standard Core Language Issues List (Revision 49) is available
News 2007-08-09: The C++ Standard Library Issues List (Revision 50) is available

576 :デフォルトの名無しさん:2007/08/10(金) 09:46:56
FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、
気になって仕方がない。

577 :デフォルトの名無しさん:2007/08/11(土) 06:43:14
= default と = delete がいまいち分かんないな。

= default はデフォルトで作られるメンバ関数を非 inline 化するためのもの・・・でいいのか?
いまいち使い道が分からんが。

= delete は関数を使えなくする・・・でいいのか?
こっちはまあ使い道あるだろうけど、
10.3p14 を見るに、基底クラスのメンバを殺すのには使えんのか?

578 :デフォルトの名無しさん:2007/08/11(土) 08:08:25
うわあああ
もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ
=0ですらキモすぎるのに=deleteとか=defaultとか

579 :デフォルトの名無しさん:2007/08/11(土) 08:13:20
フフフ。そのキモさが C++ なのさ!

580 :デフォルトの名無しさん:2007/08/11(土) 08:41:36
純粋仮想関数とかいいながら、構文が汚れてるよな

581 :デフォルトの名無しさん:2007/08/11(土) 08:47:17
不純だわ

582 :デフォルトの名無しさん:2007/08/11(土) 08:51:54
不接触の純粋さは当然のこと。
穢れに触れて、それでも尚純粋であることの方が素晴らしい。

583 :デフォルトの名無しさん:2007/08/11(土) 09:01:36
それもこれもstaticが全ての始まりでした…

584 :デフォルトの名無しさん:2007/08/11(土) 09:23:04
*じゃね?

585 :デフォルトの名無しさん:2007/08/11(土) 09:24:11
& もなかなか

586 :デフォルトの名無しさん:2007/08/11(土) 09:34:31
POD という表現がことごとく修正されてるのは、
やっぱ constexpr の影響?

587 :デフォルトの名無しさん:2007/08/23(木) 18:52:57
>>577
デフォルトのコピーコンストラクタはビットコピーする。
だから、単純なコピーで済むクラスなら書かなくていい。
しかし宣言すら存在しないのは、
プログラマがクラスのコピーについて何も言及していないようで、
必要がなくて書かなかったのか、書き忘れてるのか分からない。
じゃあコメントで言及?
それは美学がない。
そういう訳で、=defaultを使う。


588 :デフォルトの名無しさん:2007/08/23(木) 19:01:10
defaultをわざわざ指定するというのも可笑しい


589 :デフォルトの名無しさん:2007/08/23(木) 19:02:33
default constructorをprivate宣言してというIDEOMともおさらばか。

590 :デフォルトの名無しさん:2007/08/23(木) 19:04:07
.hと.cppを分けて書かせるのはいつになったらやめてくれるんだ

591 :デフォルトの名無しさん:2007/08/23(木) 19:17:14
.hだけ書いて.cppの骨組みは自動生成するようにして、
関数の中身にタグジャンプとかすれば大して気にならんと思うけど

592 :デフォルトの名無しさん:2007/08/23(木) 19:22:48
そんなん冗長にして無駄そのものじゃないか
現役言語でそんなことやってるのC++だけだぜ
存在することのメリットが一つもない

593 :デフォルトの名無しさん:2007/08/23(木) 19:38:14
inline指定できないほど長い関数はアンチパターンだ
というのが委員会の非公式な見解(うそ)

594 :デフォルトの名無しさん:2007/08/23(木) 19:47:39
.hを自動生成するg++へのpatch誰か作れ

595 :デフォルトの名無しさん:2007/08/23(木) 19:49:23
>590
全部テンプレートで解決

596 :デフォルトの名無しさん:2007/08/23(木) 19:52:47
>>587
= default は inline 化されないと書いてあるんだけど、
inline と = default の同時指定とかできるのかな?
同時指定できるならその目的に使えるとは思うけど。

597 :デフォルトの名無しさん:2007/08/23(木) 20:01:59
ダメって書いてないから、出来るんじゃないの。
宣言は明示的だけど、実装はdefaultってのが、= defaultだから、
勝手にinline宣言したことにもしないって流儀じゃないかな。

598 :デフォルトの名無しさん:2007/08/23(木) 20:33:39
.hが更新されてるかどうかで再コンパイルするかどうか決めるっていう
仕組みが前提だから.hが必要なんだろ
誰がこんなアホな仕組みにしたんだ

599 :デフォルトの名無しさん:2007/08/23(木) 21:31:34
>>597
なるほど。それなら使い道あるやね。
protected にするとか使えそう。

600 :デフォルトの名無しさん:2007/08/23(木) 22:13:27
>>598
それは別に問題ないよ。
.hを自動生成すればいいだけの話。

Javaは.classが.o(.obj)と.hを兼ねているけど、
あれはbyte codeだから.oサイドも共通にできる。
C++で.cpp, .h, .oに分かれているのは自然。


601 :デフォルトの名無しさん:2007/08/23(木) 22:15:03
D とか .h と .d とに分かれてないけど

602 :デフォルトの名無しさん:2007/08/23(木) 22:25:43
しかし.hが内容同じでも更新時間が変わってたら
再コンパイルされちまうぞ

603 :デフォルトの名無しさん:2007/08/23(木) 22:31:54
それはC++0xの言語仕様じゃなくて、処理系の問題。

604 :デフォルトの名無しさん:2007/08/23(木) 22:33:36
細かく差分みてコンパイルしてくれるような開発環境が必要だな

605 :デフォルトの名無しさん:2007/08/23(木) 22:38:58
UMLでクラス図を書く→スケルトンとテストケース、make生成→あとは.cpp埋めてくだけ
ってのが欲しい

606 :デフォルトの名無しさん:2007/08/23(木) 22:45:15

それはヘッダを生成するさいに、一時ファイル経由でdiffでもとって、
変更がなければ上書きしなければよいのでは

607 :デフォルトの名無しさん:2007/08/23(木) 23:02:32
誰かヘッダ生成ツール作ってくれえ

608 :デフォルトの名無しさん:2007/08/23(木) 23:08:19
欲しいと思ったときがプログラミング時です

609 :デフォルトの名無しさん:2007/08/23(木) 23:08:59
いいこと言うなあ

610 :デフォルトの名無しさん:2007/08/23(木) 23:16:44
たしかVC++もGCCもプロトタイプ生成の機能は持っているはず。
関数・変数だけだったらヘッダ生成に使えるだろうけど。

611 :デフォルトの名無しさん:2007/08/23(木) 23:19:44
Cの現状はCとの互換性のためだからしょーがないだろ
C99があさっての方にいっちゃったけど、今更捨てる気もないだろし

612 :デフォルトの名無しさん:2007/08/23(木) 23:20:27
C99でCハジマタと思ったのは俺だけじゃないはず

613 :デフォルトの名無しさん:2007/08/23(木) 23:22:08
Cなんて代物を使うのは移植性と過去のしがらみのためだけで、
それ気にする必要も無いんならC++使うよ

C99なんて使いどころが全然無い

614 :デフォルトの名無しさん:2007/08/23(木) 23:37:46
いいこと言うなあ

615 :デフォルトの名無しさん:2007/08/23(木) 23:46:16
ObjC厨の俺に喧嘩売ってんのか

616 :デフォルトの名無しさん:2007/08/23(木) 23:51:37
Objected-Cは今後どうなるの?

617 :デフォルトの名無しさん:2007/08/23(木) 23:57:42
どうにもならないだろうな

618 :デフォルトの名無しさん:2007/08/24(金) 00:03:12
Objected-Cってなんだよw

619 :デフォルトの名無しさん:2007/08/24(金) 00:04:46
これから始めれば無問題

620 :デフォルトの名無しさん:2007/08/24(金) 01:17:02
>>600
dはコンパイル時に.hに相当するものを生成するオプションがある
ライブラリ作成時には必須

621 :デフォルトの名無しさん:2007/08/24(金) 02:13:11
つーか.hは.cppから生成しないと最適化に必要な情報をぼんぼん取りこぼすと思うけどなあ
だからって最適化のためにいちいちinline展開しなきゃいけないというのもおかしな話だし

622 :デフォルトの名無しさん:2007/08/24(金) 02:29:04
クラスの定義もcppに書くのかい?

623 :デフォルトの名無しさん:2007/08/24(金) 02:42:36
>>587
デフォルトのコピーコンストラクタは各基底クラスと各データメンバのコピーコンストラクタを
使う。ビットコピーじゃないよ。

624 :デフォルトの名無しさん:2007/08/24(金) 02:46:17
つーか、IDE 使うんなら .h と .cpp というファイルを直接編集するんじゃなくて、
もっと抽象的な形で編集できていいと思うんだよ。

625 :デフォルトの名無しさん:2007/08/24(金) 03:13:45
>>624
その「抽象的な形」で書くってことは、つまり C++ ではない別の言語を使うということに
なるのではないかな。

626 :デフォルトの名無しさん:2007/08/24(金) 07:12:43
俺の書くクラスは、.hppのクラス定義の中に全てのメンバー関数定義がある。
inline指定ない関数も、毎回コンパイルされているが、気にしない。
.cppも.hもない。

627 :デフォルトの名無しさん:2007/08/24(金) 08:24:18
export template を使っておりますよ

628 :デフォルトの名無しさん:2007/08/24(金) 09:51:35
hppに書いたらinlineと書かなくてもinline展開しようとする、と
言語仕様で決まってるんじゃなかったっけ
hppに書いたらinline展開するか、再コンパイルするかなど
コンパイラがよきにはからう、という言語仕様にしてれば
今頃は誰も分割なんかしてないだろう

629 :デフォルトの名無しさん:2007/08/24(金) 09:56:39
>>628
> hppに書いたらinlineと書かなくてもinline展開しようとする

クラス定義内の関数定義は、暗黙のinline宣言だね。

> inline展開するか、再コンパイルするかなど
> コンパイラがよきにはからう、という言語仕様にしてれば

そういう仕様だよ。inline宣言はコンパイラに対するヒントに過ぎない。
"prefered"ではあるんだけれど。



630 :デフォルトの名無しさん:2007/08/24(金) 09:57:14
inlineを指定しなくても指定したかのように扱われるのは、
メンバ関数の定義をクラス定義内に書いたらの話。

631 :デフォルトの名無しさん:2007/08/24(金) 10:15:36
しかしhppに全部書いたら関数に変更加えるだけで
依存するクラス全部再コンパイルされて、
それに依存するクラスも全部再コンパイルされて・・・
となってほぼ全クラス再コンパイルされちまうよな
なんでこんな糞仕様なんだ

632 :デフォルトの名無しさん:2007/08/24(金) 10:20:36
>>631
Visual C++の簡易リビルドは、そういうときに
再コンパイルをしなくていいものはしないという機能ではないか?
仕様がアレでもコンパイラが頑張るとそんなこともできるという話。

633 :デフォルトの名無しさん:2007/08/24(金) 10:32:04
>>631
つ pimpl

634 :デフォルトの名無しさん:2007/08/24(金) 10:51:23
こうなったら
inline = default
も追加だ

635 :デフォルトの名無しさん:2007/08/24(金) 10:54:29
>>633
pimplは.hと.cppをがっつり分けてもなお依存性がやばいことになるという
C++の仕様に対する対策じゃん
ポインタ越しの関数もinline展開されたらまるで対抗できない

>>632
簡易リビルドを指定すれば.hと.cppを分けなくてもいいという話は聞いたことがないぜ
.hが変更されていても再コンパイルする必要がない場合は有効だろうけど
inline展開されてたらどうしたって再コンパイルしなきゃならなくなるし
まあデバッグビルドならinline展開されないだろうから大丈夫なのかな

636 :デフォルトの名無しさん:2007/08/24(金) 11:03:51
gccにもプリコンパイルドヘッダはありますが。

637 :デフォルトの名無しさん:2007/08/24(金) 11:05:41
簡易リビルドは、ヘッダが変更されていても、
変更された部分に依存していなければ再コンパイルする必要がない場合を
うまく見分ける機能じゃないの?
gccにそんなんあるかい

638 :デフォルトの名無しさん:2007/08/24(金) 11:29:08
>>635
> ポインタ越しの関数もinline展開されたらまるで対抗できない

オイオイw

639 :デフォルトの名無しさん:2007/08/24(金) 11:33:25
>>638
.hに実装を書いたらpimpl使ったって
virtualでない限り基本的にはinline展開されちまうだろ

640 :デフォルトの名無しさん:2007/08/24(金) 17:32:10
いったいコンパイラは実装が別の翻訳単位にある
メソッドをどうやってインライン展開するというのだろうか。

641 :デフォルトの名無しさん:2007/08/24(金) 17:33:08
リンク時にがんばればいい。

642 :デフォルトの名無しさん:2007/08/24(金) 17:58:10
あれ、展開されないか
かなりおかしなことを言ってるな

643 :デフォルトの名無しさん:2007/08/24(金) 18:46:25
>>640
cl.exe の /Og がまさにそれじゃなかったか?

644 :デフォルトの名無しさん:2007/08/24(金) 18:51:29
そういえばVC++は最適化のために
.cppに書いてあるものも勝手にinline展開したりするんだよな

645 :デフォルトの名無しさん:2007/08/24(金) 18:57:51
まあよくわからんけど、.hと.cppに分けないとpimplも使えないし
そもそも何もしなくてもデフォルトでpimplになってるべきだよな
その辺の仕様が古臭すぎる

646 :デフォルトの名無しさん:2007/08/24(金) 19:24:17
>>644
gccもiccも当たり前のようにinline展開しますが何か。

647 :デフォルトの名無しさん:2007/08/24(金) 19:30:47
毎日コンパイルしてテストせよという時代に
pimplなど笑止千万。

648 :デフォルトの名無しさん:2007/08/24(金) 19:45:17
毎日コンパイルしてテストせなならんから
コンパイル速度を上げるpimplが必要なんだろ

649 :デフォルトの名無しさん:2007/08/24(金) 19:59:58
>>647はpimplを何だと思ってるんだ?

650 :デフォルトの名無しさん:2007/08/24(金) 20:04:01
にきび

651 :デフォルトの名無しさん:2007/08/24(金) 20:04:26
>>644
それどころかDLL内の関数すらインライン展開できる。
http://msdn2.microsoft.com/ja-jp/library/feffc7b5(vs.80).aspx

652 :デフォルトの名無しさん:2007/08/24(金) 22:12:58
VCの最適化能力は異常

653 :デフォルトの名無しさん:2007/08/24(金) 22:27:32
>>639 がスルーされている件について

654 :デフォルトの名無しさん:2007/08/24(金) 22:47:10
うまいことごまかしたと思ったんだが・・・

655 :デフォルトの名無しさん:2007/08/24(金) 23:50:52
.cppが無理やりインライン展開されちまうんじゃ
.cppのちょっとした変更でも再コンパイルがわけわかんないとこまで広がりかねんな

656 :デフォルトの名無しさん:2007/08/25(土) 00:15:18
そこでインライン展開は実行時JITに任せる方式が登場するわけです

657 :デフォルトの名無しさん:2007/08/25(土) 00:43:06
おまえらここじゃなくて最適化スレを活用しろよ
0x++でそこらへんの仕様が変わるって言うなら別だが

658 :デフォルトの名無しさん:2007/08/25(土) 00:53:15
そこらへんの仕様は変わらんのか
じゃあC++の今後には何の期待も出来んな

659 :デフォルトの名無しさん:2007/08/25(土) 01:51:03
それはお前の勝手。

660 :デフォルトの名無しさん:2007/08/25(土) 02:15:58
もっと声をあげていかなアカンと思うぜ
.hと.cppを分けなければならないのは冗長で腐った考え方だ
クロージャを導入する前にそこをまずなんとかしろ

テンプレートのメタプログラミングはわけわからんからまともなマクロを導入しろ
足元をまず見直せ

661 :デフォルトの名無しさん:2007/08/25(土) 02:20:22
>>660
言語仕様を俺の頭の悪さに合わせろ!とはなんとも無茶な注文ですね


662 :デフォルトの名無しさん:2007/08/25(土) 04:27:56
まじめな顔して書くが
>>660みたいなのはDやればと思ってしまう

663 :デフォルトの名無しさん:2007/08/25(土) 08:25:25
そもそも規格自体は .h と .cpp をわけろとか一言も書いてないと思うけど...
標準のヘッダは .h というか拡張しなかったりするけど、それ以外は
プリプロセッサが処理したあとの話しか規定してないわけだし。

664 :デフォルトの名無しさん:2007/08/25(土) 09:05:30
分けたくないなら全部.hに書けよ、一人で勝手にさぁ。

665 :デフォルトの名無しさん:2007/08/25(土) 09:42:43
まあでも、ヘッダとcppファイル間の間には、
IDEの支援がもっとあってもいいと思う。

666 :デフォルトの名無しさん:2007/08/25(土) 10:47:41
D言語はGCがあるからパフォーマンスが必要なプログラムが書けない
せっかくネイティブなのに

まあDelphi使えばいいんだけどな

667 :デフォルトの名無しさん:2007/08/25(土) 10:51:29
.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
言語仕様で決まってるんだよスカタン
なんだこの糞仕様

668 :デフォルトの名無しさん:2007/08/25(土) 10:54:09
>.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
妄想乙。

669 :デフォルトの名無しさん:2007/08/25(土) 11:00:46
妄想じゃねー
暗黙 inline とかでぐぐれ

670 :デフォルトの名無しさん:2007/08/25(土) 11:13:39
>>667は文章が下手。
「全部inline展開しようとする」は、
「全部必ずinline展開しようとする」、
「全部inline展開の考慮対象とする」のどちらにも読める。



671 :デフォルトの名無しさん:2007/08/25(土) 11:27:38
>>670
どっちも同じ意味だろ
どっちも間違ってない

672 :デフォルトの名無しさん:2007/08/25(土) 11:27:45
>>669
それはクラス定義内での関数定義の話ではないのか?

673 :デフォルトの名無しさん:2007/08/25(土) 11:31:32
>>672
定義と宣言というのは正しい用語だがわかりにくいから
俺は.hに実装を書けばという言い方をする
.hの中でクラス定義と関数定義を分ける意味がないから普通は
クラス定義内の関数定義のことだと分かってもらえると思うが

674 :デフォルトの名無しさん:2007/08/25(土) 11:35:31
>>673
こんなスレでそんなわかりにくさを気にするような奴はいないから、
そんな気を使う必要はないよ。

675 :デフォルトの名無しさん:2007/08/25(土) 11:38:04
でも気遣う努力は素晴らしいことだよ、とフォロー。

676 :デフォルトの名無しさん:2007/08/25(土) 11:58:39
>>673
> .hの中でクラス定義と関数定義を分ける意味がないから、普通は
> クラス定義内の関数定義のことだと分かってもらえると思うが
俺はごく短いもの以外、inlineさせたいメンバ関数は、.hの中で分けて書いてinline付けてるよ。
class hoge { }; のひとカタマリは、できるだけインターフェースの全容を一望しやすい形にしておきたいんで。
俺みたいな好みを持たない人でも、クラステンプレートがかなりでかいメンバ関数を持つことになって、
それを.hの中で分けて書いた、なんてことは何度もあるんじゃないかと思う。

つまり、「.hの中でクラス定義と関数定義を分ける」ことは、割とある。
だから「.hに実装を書く」という表現で、一気に「クラス定義部に実装を書くこと」まで限定した会話が
できると考えるのは、ちょっと行き過ぎなんじゃないかと思う。

・・・でもそれはそれとして、クラス定義内の強制inlineに対する気持ちはわかるw

677 :デフォルトの名無しさん:2007/08/25(土) 12:28:02
outline とか追加されねーかなあ

678 :デフォルトの名無しさん:2007/08/25(土) 12:29:20
7.1.2 Function specifiers

A function declaration with an inline specifier declares an inline function.

インライン指定を備えた関数宣言はインライン関数を宣言します。

The inline specifier indicates to the implementation
that inline substitution of the function body at
the point of call is to be preferred to
the usual function call mechanism.

インライン指定は、呼び出し位置の関数本体のインライン置換が
通常の関数呼び出し機構より優先されることを実装に示します。

An implementation is not required to perform
this inline substitution at the point of call;

実装は呼び出し位置でこのインライン置換を実行することは要求されません。

679 :デフォルトの名無しさん:2007/08/25(土) 12:36:45
実装隠したければ・リンク互換性保ちたければ
pimpl使えってことじゃないのC++的には
ただのイディオムではなく言語的にもっとサポートがあると楽でいいんだがな
いつもいつもいちいち委譲のコードなんて書きたくないし

680 :デフォルトの名無しさん:2007/08/25(土) 12:44:01
#includeなんてソースコードほんとに読み込むしな
原始的すぎる
Packageみたいなものをサポートする予定はないのかね

681 :デフォルトの名無しさん:2007/08/25(土) 14:08:32
ヘッダでインクルードガードを検出したら同じ翻訳単位内では以後無視する最適化はしてあるよね
pImpl は extern と export で撲滅できるし

682 :デフォルトの名無しさん:2007/08/25(土) 14:23:56
>>666
GC使わないこともできるよ。

683 :デフォルトの名無しさん:2007/08/25(土) 14:24:42
インクルードガードも、たとえばVCの#pragma onceみたいなものを規格化すべきだと思っているんだけど、
必要ないのかな?

684 :デフォルトの名無しさん:2007/08/25(土) 14:28:03
>>681
むしろexportのほうが撲滅されそうないきおいジャマイカ

685 :デフォルトの名無しさん:2007/08/25(土) 14:29:14
インクルードの仕組み自体全部作り直せよ
ソースを置き換えるっていうこと自体問題が多すぎる
パッケージ内のクラス定義を一気に導入して
実際に使っているクラス定義にしか依存しない、という機能があればいい

686 :デフォルトの名無しさん:2007/08/25(土) 14:30:19
>>685
Cとの互換性を捨てていいんならいくらでもやりようはあるだろうけど
今更それは出来んだろ

687 :デフォルトの名無しさん:2007/08/25(土) 14:32:45
includeはincludeで残して、
packageというのを作ればいいんじゃね
これ導入したらincludeまで壊れるか?

688 :デフォルトの名無しさん:2007/08/25(土) 14:33:46
ああ、includeも互換性のために残したままでシンボルテーブルをインポートする
新しい仕組みを作るのか
それならいいかもな

689 :デフォルトの名無しさん:2007/08/25(土) 15:21:21
それはどこの .net f(ry

690 :デフォルトの名無しさん:2007/08/25(土) 15:46:32
>>667 は inline 関数は全部 inline 展開されるとでも思ってるのかね。

691 :デフォルトの名無しさん:2007/08/25(土) 15:59:32
「しようとする」という書き方を見て、「されるとでも思ってるのかね」もないもんだと思うがなぁ。

692 :デフォルトの名無しさん:2007/08/25(土) 16:05:57
頭大丈夫か?

693 :デフォルトの名無しさん:2007/08/25(土) 16:19:37
>>692
お前の頭の話なら、ダメかも。

694 :デフォルトの名無しさん:2007/08/25(土) 16:51:25
>>684
export を使うとコンパイルの挙動が異様におもしろくなるので
コード書きのモチベーションに変化があったりなかっ…なくはない

695 :デフォルトの名無しさん:2007/08/25(土) 17:20:34
なんでexportでpimplがいらなくなるんだ?

696 :デフォルトの名無しさん:2007/08/25(土) 17:41:12
>>678
"to be preferred"を"優先される"は強すぎるだろ。
これこそ「しようとする」だ。

697 :デフォルトの名無しさん:2007/08/25(土) 19:39:43
C++0xに関する映像出てるね
びょーんすっぽすっぽサマの声が聞けて嬉しす。

698 :デフォルトの名無しさん:2007/08/25(土) 22:04:39
>>686
C++は既にCとの互換性を失っていますが

699 :デフォルトの名無しさん:2007/08/25(土) 23:07:46
C++をおかしくした禿げのことか

700 :デフォルトの名無しさん:2007/08/29(水) 02:32:45
これは良スレ

701 :デフォルトの名無しさん:2007/08/29(水) 18:31:03
もうJavaっぽいGCなしのネイティブ言語つくろうぜ

702 :デフォルトの名無しさん:2007/08/29(水) 18:34:46
Qtをさわった感じがそんなんだった。>GC無しJava

703 :デフォルトの名無しさん:2007/08/29(水) 18:45:41
字句解析つきマクロがあれば何でもできる。

704 :デフォルトの名無しさん:2007/08/29(水) 19:49:27
そこでNemerleですよ

705 :デフォルトの名無しさん:2007/08/29(水) 21:06:18
boostを作った変態たちにまともなマクロを与えたら
とんでもない言語を作ってくれると思うんだけどなあ
templateだけじゃやっぱ弱いよ

706 :デフォルトの名無しさん:2007/08/29(水) 21:20:25
今のところ成功してるマクロはLispのものしかないな
「何でもできる」ってのはやっぱ危険だよ。

707 :デフォルトの名無しさん:2007/08/29(水) 21:21:09
なんでも出来るのがC++の強みだよ

708 :デフォルトの名無しさん:2007/08/29(水) 21:50:44
SASのマクロもかなり強力でかなり凶悪ですよ。
知っている人ほとんどいないと思うけど・・・

709 :デフォルトの名無しさん:2007/08/29(水) 22:06:29
>>701
D言語に謝れ

710 :デフォルトの名無しさん:2007/08/29(水) 22:54:57
実際組んでると auto が便利すぎてワラタなんだこれ

711 :デフォルトの名無しさん:2007/08/29(水) 22:57:17
autoってなに?
typeof(hoge) var;のこと?

712 :デフォルトの名無しさん:2007/08/29(水) 23:00:05
>711
多分同じことを指してるだろうが auto i = c.begin(); みたいに書いた方がわかりやすくないか?

713 :デフォルトの名無しさん:2007/08/29(水) 23:01:57
暗黙的な型推論はC#3.0は本決まりでJavaは検討段階だっけかな

714 :710:2007/08/29(水) 23:34:19
auto 仕様

※ PDF ! PDF !

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

715 :デフォルトの名無しさん:2007/08/29(水) 23:40:21
記憶指定子のautoよさらば!
って感じだな。
で、ついでにデフォルトのintも廃止されるのかな。

716 :デフォルトの名無しさん:2007/08/29(水) 23:41:31
デフォルトの int ってまだ有効なんだっけ?

717 :デフォルトの名無しさん:2007/08/29(水) 23:49:25
少なくともISO C++98にはない。おそらくそれ以前になくなったはず。
ついでに言うとC99でもなくなった。

718 :デフォルトの名無しさん:2007/08/30(木) 02:01:46
後生大事に auto を予約語に残しておいた甲斐があったなw

719 :デフォルトの名無しさん:2007/08/30(木) 02:15:02
export…

720 :デフォルトの名無しさん:2007/08/30(木) 09:53:48
C++ 0xを実験的に実装したコンパイラとかないのか

721 :デフォルトの名無しさん:2007/08/30(木) 10:19:44
>>720
Comeauのv439β使ってる
コンパイラの実装制限による仕様抑制が全くないC++の開発効率の高さは異常

722 :デフォルトの名無しさん:2007/08/30(木) 10:20:22
地味な変更に今更気づいたけど、
別のコンストラクタを呼ぶことができるようになったんだね。

struct C {
 C(int) { }
 C() : C(42) { }
};

723 :デフォルトの名無しさん:2007/08/30(木) 10:20:59
Comeau ってことは、export が使えるやつか。いいなあ。

724 :デフォルトの名無しさん:2007/08/30(木) 10:35:37
ConceptGCCもそれなりに0x実装しているんじゃないのかな

725 :デフォルトの名無しさん:2007/08/30(木) 12:22:54
込め会うってどこで手にはいるの?

726 :デフォルトの名無しさん:2007/08/30(木) 12:26:41
ここから買え→ http://www.comeaucomputing.com/

727 :デフォルトの名無しさん:2007/08/30(木) 14:50:23
>>720 g++

728 :デフォルトの名無しさん:2007/08/30(木) 23:32:23
補足。
ttp://gcc.gnu.org/gcc-4.3/cxx0x_status.html

729 :デフォルトの名無しさん:2007/08/31(金) 00:01:53
>>726
下の方でチラチラしてるやつ胡散くせーなぁw

730 :デフォルトの名無しさん:2007/08/31(金) 09:03:54
0xには結局GCは入るの?

731 :デフォルトの名無しさん:2007/08/31(金) 09:30:59
gcnew

732 :デフォルトの名無しさん:2007/08/31(金) 21:32:29
GCCでもexport使えるようにならんのかなぁ

733 :デフォルトの名無しさん:2007/08/31(金) 22:32:47
>>726
広告ウザスwwwww
どこぞのエロサイトかと

734 :デフォルトの名無しさん:2007/08/31(金) 22:38:57
export早く消えねえかな

735 :デフォルトの名無しさん:2007/08/31(金) 22:43:50
20年後位にautoみたいなすてきキーワードになって帰ってくるはずさ

736 :デフォルトの名無しさん:2007/08/31(金) 23:23:33
たまにはregisterのことも思い出してやってください

737 :デフォルトの名無しさん:2007/08/31(金) 23:31:22
完全に忘れてたw

738 :デフォルトの名無しさん:2007/08/31(金) 23:43:15
覚えてるよ
しかし使ったのは4年くらい前が最後か

739 :デフォルトの名無しさん:2007/08/31(金) 23:47:34
>>736
なつかしす。autoみたいに、いかす再利用法を考えてあげようぜ。

740 :デフォルトの名無しさん:2007/08/31(金) 23:48:54
なんかregisterも、いつの日か再利用される日が来たりして。

741 :デフォルトの名無しさん:2007/08/31(金) 23:50:22
単語の意味的に再利用する方法がおもいつかん…

autoは見事すぎる。現れる位置ももともとのautoに近いし

742 :デフォルトの名無しさん:2007/09/01(土) 00:09:08
「登録する」とか系の意味で再利用できんかな

743 :デフォルトの名無しさん:2007/09/01(土) 01:00:41
register obj

objのGCに抵抗する。

744 :デフォルトの名無しさん:2007/09/01(土) 02:13:49
レジスタと同じ大きさの数値型とか。
intはCPU/OS依存ではなく処理系依存だしねぇ。

745 :デフォルトの名無しさん:2007/09/01(土) 02:46:49
javaみたいに整数型のビット数は言語仕様で固定として、
浮動小数点数は strictfp で IEEE 仕様に変更できるとかがいいな。
その上でregisterが整数型として存在するならありがたい。

746 :デフォルトの名無しさん:2007/09/01(土) 02:57:18
template引数でビット数とか浮動小数点の精度とか
数の特性を指定できるようにすりゃいいんだよ
型も作っちゃいますみたいな

747 :デフォルトの名無しさん:2007/09/01(土) 03:48:58
>>743
分かって言ってるんだとは思うが、抵抗するはresist

748 :デフォルトの名無しさん:2007/09/01(土) 04:01:33
re gist erをgoogle翻訳すると「再要点えー」

749 :デフォルトの名無しさん:2007/09/01(土) 06:00:46
>745
strictfpって、遅くなる可能性がなかった?

750 :デフォルトの名無しさん:2007/09/01(土) 10:28:48
不動小数点数の扱いを規格化作するから速度的にはね。
飽くまでCPUごとのFPUに依存したくないときに指定するものだし。

751 :デフォルトの名無しさん:2007/09/01(土) 11:13:09
near,farが完全に忘れられてるんだが

752 :デフォルトの名無しさん:2007/09/01(土) 11:17:20
DOSとその有害な子孫の16ビット処理系コンパイラにしか存在して無いだろ

753 :デフォルトの名無しさん:2007/09/01(土) 11:19:42
ファーッ、こんな侮辱初めてだわ。

754 :デフォルトの名無しさん:2007/09/01(土) 11:20:13
ニイヤー、それほどでもないよ。

755 :デフォルトの名無しさん:2007/09/01(土) 12:26:44
美少女中学生のフラットなおっぱいの先端を仮想エクステンドさせで何度もコールするとにゃッとかふァァッとかいい声で鳴くわけですね

756 :デフォルトの名無しさん:2007/09/01(土) 12:27:56
すごい勢いでクソスレ化している

757 :デフォルトの名無しさん:2007/09/02(日) 09:01:11
near, far って既に規格から消去されてないか?

758 :デフォルトの名無しさん:2007/09/02(日) 09:02:38
一度でも標準規格に載ったことがあったか?

759 :デフォルトの名無しさん:2007/09/02(日) 09:06:26
もちろん参考扱いだったはずだが、
JIS X3014:2003を見ると、allocatorのところに、
farポインタ用のchar_traitsを定義する例が載っているんだ。

760 :デフォルトの名無しさん:2007/09/02(日) 10:36:39
アロケータでnearとfarを隠蔽する試みって結局失敗したんじゃないか?

761 :デフォルトの名無しさん:2007/09/02(日) 13:46:10
ISO/IEC 14882:2003 24.3.1.2

[Note: If there is an additional pointer type _ _far such that
the difference of two _ _far is of type long, an implementation may define

template<class T> struct iterator_traits<T _ _far*> {
 typedef long difference_type;
 typedef T value_type;
 typedef T _ _far* pointer;
 typedef T _ _far& reference;
 typedef random_access_iterator_tag iterator_category;
};

-end note]

762 :デフォルトの名無しさん:2007/09/02(日) 14:10:30
C++0xって楽しそう!
使ってみたい!


763 :デフォルトの名無しさん:2007/09/02(日) 18:19:28


764 :南米院 ◆QUsHlZHWHA :2007/09/02(日) 21:45:39


765 :デフォルトの名無しさん:2007/09/03(月) 04:08:08
e

766 :デフォルトの名無しさん:2007/09/03(月) 09:05:16
オスマン・サンコンですぅ〜

767 :デフォルトの名無しさん:2007/09/03(月) 11:32:23
だまれ

768 :デフォルトの名無しさん:2007/09/03(月) 12:18:21
>>762->>766
つ あ
http://pc11.2ch.net/test/read.cgi/tech/1186388884/

769 :768:2007/09/03(月) 12:22:31
あれっなんか変だ…
>>762-768

770 :768:2007/09/03(月) 12:25:34
×>>769
>>762-766
スレ汚してすまそん逝ってきます…orz

771 :デフォルトの名無しさん:2007/09/03(月) 12:31:07
急に盛り上がってると思ったらゴミレスか

772 :デフォルトの名無しさん:2007/09/03(月) 22:32:34
もう俺C++ 0xで開発するわ
autoのない世界に戻れそうにない

773 :デフォルトの名無しさん:2007/09/04(火) 19:25:48
C++03なら既に入手可能だな

774 :デフォルトの名無しさん:2007/09/04(火) 20:42:51
03は98とほぼ同じ代物だし

775 :デフォルトの名無しさん:2007/09/04(火) 20:45:22
C++2.0とか命名しなかったセンスは褒めたい

776 :デフォルトの名無しさん:2007/09/04(火) 21:51:29
あんな風潮に迎合できるほど彼らの髪は残ってないからな。

777 :デフォルトの名無しさん:2007/09/04(火) 21:54:46
777

778 :デフォルトの名無しさん:2007/09/04(火) 21:56:09
どうせすぐにC++1xの策定準備に入るつもりだからだろう

779 :デフォルトの名無しさん:2007/09/04(火) 22:00:49
アメ公ならx使ったら次は360とかにするかも

780 :デフォルトの名無しさん:2007/09/04(火) 23:24:49
++C++

781 :デフォルトの名無しさん:2007/09/05(水) 00:24:27
C++ 2008 XP Professional

782 :デフォルトの名無しさん:2007/09/05(水) 01:06:04
C++ Home Edition

783 :デフォルトの名無しさん:2007/09/05(水) 01:07:59
C++ Ultimate

784 :デフォルトの名無しさん:2007/09/05(水) 02:56:47
C++ Orz

785 :デフォルトの名無しさん:2007/09/05(水) 02:59:32
>>784
C++にひざまずいてるように見えるな

786 :デフォルトの名無しさん:2007/09/05(水) 09:48:16
Wirth先生、PASCALがヒットしたのに(Turbo Pascalがあったからね)
気をよくして第2?3弾としてMODULA2を作ったけどさっぱりだった。

C++0xもほどほどで公開した方がいい。あんまりもったいぶると、いざ
公開されたときには「こんなのイラネ」と誰も使わないかもしれんぞ。

ご存知のように、言語とかライブラリとかは技術的に優れているから
受け入れられるかというと必ずしもそうではない。アメリカの某団体
が強く推奨するとか、マイクロソフトが採用する、とか運みたいな
ものがあるから。

787 :デフォルトの名無しさん:2007/09/05(水) 09:54:05

ageてる割に中身が無く、
誰に言ってるのかわからない文章

788 :デフォルトの名無しさん:2007/09/05(水) 10:06:41
  ビヨ〜ン
〜(^Д^)〜

789 :デフォルトの名無しさん:2007/09/05(水) 10:08:20
>>786
Modula-3, Oberon, Oberon-2も知らないのね。

790 :デフォルトの名無しさん:2007/09/05(水) 10:38:40
>>789
知らんでもいい。
Ada-95を知っていれば十分。

791 :デフォルトの名無しさん:2007/09/05(水) 15:11:27
C--
C>>
C<<
C==
C||
C&&

792 :デフォルトの名無しさん:2007/09/05(水) 15:47:19
C
C++
C+=2
C+=3

793 :デフォルトの名無しさん:2007/09/05(水) 15:59:14
Dを先にとられちゃったのが痛いな

794 :デフォルトの名無しさん:2007/09/05(水) 16:27:20
C Abnormal

795 :デフォルトの名無しさん:2007/09/05(水) 16:30:18
>>793
「元祖D」とか「総本家D」で桶

796 :デフォルトの名無しさん:2007/09/05(水) 16:47:29
はじめてのC

797 :デフォルトの名無しさん:2007/09/05(水) 18:24:19
やればできるC
いきなりのC

798 :デフォルトの名無しさん:2007/09/05(水) 18:25:49
それは入門書の名前だろ

799 :デフォルトの名無しさん:2007/09/05(水) 20:48:47
HOW TO 本だろ

800 :デフォルトの名無しさん:2007/09/05(水) 21:24:49
はうはううううう

801 :デフォルトの名無しさん:2007/09/05(水) 22:36:25
頭文字C

802 :デフォルトの名無しさん:2007/09/05(水) 22:57:43
--D

803 :デフォルトの名無しさん:2007/09/05(水) 23:06:24
~C

804 :デフォルトの名無しさん:2007/09/05(水) 23:17:40
いつからC++の次期バージョンの名前を考えるスレに?

805 :デフォルトの名無しさん:2007/09/05(水) 23:20:53
そろそろ、捨てるべきものを捨てて言語を整理するべき時期に来たんじゃないかな
だから、新しい名前が必要に・・・

806 :デフォルトの名無しさん:2007/09/05(水) 23:24:12
もっとあぶないC++

807 :デフォルトの名無しさん:2007/09/05(水) 23:49:05
C++フォーエヴァー TVスペシャル0x

808 :デフォルトの名無しさん:2007/09/06(木) 00:17:09
C^2

809 :デフォルトの名無しさん:2007/09/06(木) 09:19:00
JavaC++


810 :デフォルトの名無しさん:2007/09/06(木) 10:42:56
C++ デンマークから愛をこめて
C++ C++は二度死ぬ
C++ わたしを愛したJava

811 :デフォルトの名無しさん:2007/09/06(木) 12:34:26
愛をこぬて

812 :デフォルトの名無しさん:2007/09/06(木) 12:55:55
C NEXT

813 :デフォルトの名無しさん:2007/09/06(木) 18:11:21
After C

814 :デフォルトの名無しさん:2007/09/06(木) 19:55:48
Alternate+C

815 :デフォルトの名無しさん:2007/09/06(木) 20:13:50
CXX mkII

816 :デフォルトの名無しさん:2007/09/06(木) 22:50:58
G

817 :デフォルトの名無しさん:2007/09/06(木) 23:10:49
Cex

818 :デフォルトの名無しさん:2007/09/07(金) 00:16:00
C++'s Counterattack

819 :デフォルトの名無しさん:2007/09/07(金) 17:46:48
関数テンプレート構文がこんな感じに書けたら楽なのにな
auto func<int val>(auto arg) { return val * arg; }

820 :デフォルトの名無しさん:2007/09/07(金) 18:43:45
それって
template <int val, typename T> T func(T arg) { return val * arg; };
だとなんかマズい?

821 :デフォルトの名無しさん:2007/09/07(金) 18:46:31
あぁ、書き方の問題か。

822 :デフォルトの名無しさん:2007/09/07(金) 22:04:11
>>819
それって、引数に与える型によって返値型がころころ変わるのがいやだなあ。

823 :デフォルトの名無しさん:2007/09/07(金) 22:18:32
>>819
引数や返値にautoを使用したとすると、参照にしたい時とか面倒そうだなあ

824 :デフォルトの名無しさん:2007/09/08(土) 00:08:47
きっと auto& を使うんだyo

825 :auto:2007/09/08(土) 00:15:41
#include <auto.h>

int main()
{
auto ;//Do anything you want.
return 0 ;
}

826 :デフォルトの名無しさん:2007/09/08(土) 00:16:50
>>822
template構文でも、こう書けば同様に戻り値の型が
ころころ変わることを表現できそう(実際これが可能かは知らない)。
template<int val, typename T>
decltype(val * T()) func(T arg);

Boost.Lambdaみたいなライブラリでは役に立つのかもしれないと思う。

827 :デフォルトの名無しさん:2007/09/08(土) 19:16:25
auto func = <>(val) { <>(arg : val) { val * arg } };
auto func10 = func(10);


828 :デフォルトの名無しさん:2007/09/08(土) 19:19:28
…というのはクロージャじゃないからダメかなやっぱ (N2329ね)

829 :デフォルトの名無しさん:2007/09/08(土) 23:08:45
C++0xのコンパイラどこ?

830 :デフォルトの名無しさん:2007/09/08(土) 23:12:37
ドクロが見つめる一本杉の根本に埋めてあるよ

831 :デフォルトの名無しさん:2007/09/08(土) 23:18:24
>>830
ドラえもん乙

832 :デフォルトの名無しさん:2007/09/09(日) 01:59:47
>>830
教えてくれてありがとう!

833 :デフォルトの名無しさん:2007/09/09(日) 02:06:05
>>830
ぴぴるぴるぴる(略

834 :デフォルトの名無しさん:2007/09/15(土) 10:51:47
9月分来てるね。

835 :デフォルトの名無しさん:2007/09/19(水) 19:09:37
何が変わってる?

836 :デフォルトの名無しさん:2007/09/20(木) 18:33:43
マルチメソッドなんて入るの?

837 :デフォルトの名無しさん:2007/09/20(木) 21:59:39
C++に入れられない仕様など無い。

838 :デフォルトの名無しさん:2007/09/20(木) 23:43:23
マルチメソッドって禿のお気に入りだったやつ?
D&Eでしつこいほどに言及してたけど。

839 :デフォルトの名無しさん:2007/09/21(金) 08:45:21
>835
9 月分だと draft の変更はなし。concurrency 関連の paper が多め、といったところだと思う。

>826
簡単に T が Default constructible でなくても良く書く方法として
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
に、↓な書き方が提案されている。
template<int val, typename T>
auto func (T arg) -> decltype(val * arg);

840 :デフォルトの名無しさん:2007/09/21(金) 08:52:53
正直Objective-C++0xに期待してまふ

841 :デフォルトの名無しさん:2007/09/21(金) 12:34:23
げろげろ

842 :デフォルトの名無しさん:2007/09/21(金) 15:30:53
俺はC++/CLI0xに期待だぜ

843 :デフォルトの名無しさん:2007/09/21(金) 16:15:30
C++/CLI (笑)

844 :デフォルトの名無しさん:2007/09/21(金) 16:26:56
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
を読んでて、ふと思ったんだけど 2.4.1 Variable and function names の所で
  int foo(char);
  decltype(&foo)     // int(*)(char)
  decltype(*&foo)    // int(&)(char)
とグローバル関数については例が載ってるけど、メンバ関数については
  class A {
      int foo(char);
  };
  decltype(&A::foo)  // int(Foo::*)(char)
と、メンバ関数ポインタについてのみ書いてある。
  decltype(*&A::foo) // int(Foo::&)(char)
とかってのは駄目?

845 :デフォルトの名無しさん:2007/09/21(金) 17:39:06
どんな型を持った変数に戻り値を入れるんだろうと
::&演算子?


846 :デフォルトの名無しさん:2007/09/23(日) 06:58:20
あと2年半弱か..


847 :デフォルトの名無しさん:2007/09/23(日) 08:24:34
やっぱり、2009年内に間に合わなかったら
そこからあと90年待つのかな。

848 :デフォルトの名無しさん:2007/09/23(日) 10:34:44
>>844
現行のC++にもメンバへの参照はないな。

849 :デフォルトの名無しさん:2007/09/23(日) 16:09:28
>>848
レスありがと。
そっか、別に必要と思う局面は思いつかないけど
なんで無いんだろうねぇ。

850 :デフォルトの名無しさん:2007/09/23(日) 16:44:05
>>849
参照は必ず実体を指す、という制約がクラス継承によってさっくり破られるからな

851 :デフォルトの名無しさん:2007/09/23(日) 18:48:13
>>850
おー!なるほど!
そういうことだったのか。
T& を T* const と思い込んでたから気付かなかったんだぜ。

852 :デフォルトの名無しさん:2007/09/24(月) 14:39:56
C++0x <-よーくみろ!これは数字じゃなくて16進定数のプレフィックスだ!
ってことは、ってことは!!

この動作は不定ってことだぁーーーーーーーーーーーー。






まさに外道。

853 :デフォルトの名無しさん:2007/09/24(月) 14:49:53
C → C++ → C++0x → <<C++0x → <<C++0x() → <<C++0x(\->)

854 :デフォルトの名無しさん:2007/09/24(月) 18:13:39
それなんて顔文字?

855 :デフォルトの名無しさん:2007/09/25(火) 03:58:34
ほんとにC++09は間に合うのかね?
てか、g++は追従できるんだろうか・・・。

856 :デフォルトの名無しさん:2007/09/25(火) 08:31:55
comeauならやってくれるさ

857 :デフォルトの名無しさん:2007/09/25(火) 08:48:01
米屋ぁう

858 :デフォルトの名無しさん:2007/09/25(火) 11:43:41
Ct



859 :デフォルトの名無しさん:2007/09/25(火) 22:45:09
C++0x2009

860 :デフォルトの名無しさん:2007/09/26(水) 12:27:55
>>859だと C+(+0x2009)になるのかな?

861 :デフォルトの名無しさん:2007/09/27(木) 18:36:20
>>860

$ cat > a.cc
 int main() {
  int C = 0;
C++0x2009;
 }
$ g++ a.cc
a.cc: In function `int main()':
a.cc:3: error: expected `;' before numeric constant
$ orz
bash: orz: command not found

862 :デフォルトの名無しさん:2007/09/28(金) 00:31:01
VC8だとローカルクラスをテンプレートパラメータに渡せてしまったんだが、
これが標準になれば、lambda無くても良くね?


863 :デフォルトの名無しさん:2007/09/28(金) 00:45:41
むしろローカル関数を

864 :デフォルトの名無しさん:2007/09/28(金) 00:50:49
lambdaじゃなくて名前付きのローカル関数?

865 :デフォルトの名無しさん:2007/09/28(金) 01:46:21
>>863
ローカルクラスのstaticメソッドで十分では。


866 :デフォルトの名無しさん:2007/09/28(金) 02:07:00
>>865
めんどいしhackっぽいのが嫌じゃない?
クロージャも使えないし。

867 :デフォルトの名無しさん:2007/09/28(金) 03:35:47
>>866
たしかに面倒というほかないが、
tr1::bindとstaticメソッドさえあればクロージャはできるよね。
まあ、lambda欲しいけど。


868 :デフォルトの名無しさん:2007/09/28(金) 23:26:53
たのむ、0x0000_0000_0000って書ける様にしてくれ。64ビット時代になったらしむる。
そんな大それたお願いじゃないからさ

869 :デフォルトの名無しさん:2007/09/29(土) 00:23:38
32進数を作ればいいじゃない

870 :デフォルトの名無しさん:2007/09/29(土) 00:24:23
>>868
2進表記もほすい

871 :デフォルトの名無しさん:2007/09/29(土) 01:27:17
template <unsigned long N>
struct Binary {
enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
enum { value = 0 };
};

Binary<1101>::value -> 13
あるいは
#define HEX_DIGIT_0000 0
#define HEX_DIGIT_0001 1
...
#define HEX_DIGIT_1111 f
#define HEX_DIGIT(a) HEX_DIGIT ## a

#define BINARY8H(a,b,c,d,e,f,g,h) (0x##a##b##c##d##e##f##g##h)
#define BINARY8I(a,b,c,d,e,f,g,h) BINARY8H(a,b,c,d,e,f,g,h)
#define BINARY8(a,b,c,d,e,f,g,h) BINARY8I(HEX_DIGIT(a), HEX_DIGIT(b), ..., HEX_DIGIT(h))

BINARY8(1010,0101,1010,0101,1010,0101,1010,0101) -> 0xa5a5a5a5

872 :デフォルトの名無しさん:2007/09/29(土) 13:56:24
typeofはどうなるんだ

873 :デフォルトの名無しさん:2007/09/29(土) 16:47:09
decltype が入るジャン?

874 :デフォルトの名無しさん:2007/09/29(土) 19:23:05
どうせなら好きな基数で数を書けるようにして欲しい
3進法や5進法が欲しくなることもたまにあるし

875 :デフォルトの名無しさん:2007/09/29(土) 20:01:52
アンダースコアによる数値の書式整理は欲しいね。Python がうらやましい

876 :デフォルトの名無しさん:2007/09/30(日) 07:30:05
>>875
Pythonにアンスコ区切りないよ?
バイナリリテラルはあるかも知れないが

877 :デフォルトの名無しさん:2007/09/30(日) 09:51:09
人気者のPythonがうらやましす

878 :デフォルトの名無しさん:2007/09/30(日) 12:08:03
>876
あれ。違ったか。ごめん。ずっと Python だと覚えてた
12_000_000 って数値の書式を整理できるヤシ

879 :デフォルトの名無しさん:2007/09/30(日) 12:46:51
_区切りは慣れると手放しがたくて困る。

880 :デフォルトの名無しさん:2007/09/30(日) 14:33:48
perlは_区切りできる。
perlで出きるのを見てて、Cでも出来るものと勘違いしてたよ。
あると読みやすいね。

881 :デフォルトの名無しさん:2007/09/30(日) 14:37:18
64bitが主流になったら検討されるかな

int64_t hoge = 0xFFFFFFFFFFFFFFFF;

とか書きたくないな

882 :デフォルトの名無しさん:2007/09/30(日) 14:46:06
昔ながらのMAKEWORDの類のマクロまたはインライン関数でいいんじゃねぇの?
コンパイル時に定数として埋め込まれるでしょ


883 :デフォルトの名無しさん:2007/09/30(日) 15:27:06
アンスコを数値に追加してパース時に読み飛ばしてくれるだけで対応できるんだけど
こういうちょっと便利な内容っていつでもできるからって議題に上がらなくて
結局、入らないんだよね

int64_t max_value = 3_764_000_000;
int64_t max_value = UNDERSCOUT_FORMAT(3_764_000_000);

可読性がぜんぜん違うっしょ

884 :デフォルトの名無しさん:2007/09/30(日) 17:42:05
>>881
int64_t hoge = ~0;

885 :デフォルトの名無しさん:2007/09/30(日) 17:46:30
>>871
ごめん。スレ違いだけどちょっと気になって・・・

template <bool B> struct static_assert;
template <> struct static_assert<true> {};

template <unsigned long N>
struct Binary {
  static_assert<N % 10 == 0 || N % 10 == 1> illegal_bin_digit_found;
  enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
  enum { value = 0 };
};

886 :デフォルトの名無しさん:2007/09/30(日) 18:50:56
>>871
Binary<0101>::value で static_assert 失敗するのはダメだろ。

887 :デフォルトの名無しさん:2007/09/30(日) 19:07:45
>>886
8進数になるから無視していいのでは。

888 :デフォルトの名無しさん:2007/09/30(日) 22:53:01
数値のカンマ区切りならoperator orverloadで現行でも何とかなりそうとか思ってみたりみなかったり

889 :デフォルトの名無しさん:2007/09/30(日) 23:20:19
英語力に自信のある人、ドラフト投げてみてくれ。
今を逃すとc++1x送りになるだろし。

890 :デフォルトの名無しさん:2007/09/30(日) 23:58:34
>>888
そりゃ難しくないかい?俺の頭では無理っぽい。
だって、何桁目のカンマか識別できないもん・・・(´・ω・`)

891 :デフォルトの名無しさん:2007/10/01(月) 00:00:56
return rhs*1000+lhs; すりゃいいわけだから、識別しなくていいんじゃね?


892 :デフォルトの名無しさん:2007/10/01(月) 00:02:11
実行時評価w

893 :デフォルトの名無しさん:2007/10/01(月) 00:02:40
こういうのって可読性の問題だから「俺様定義すれば可能」より「標準の機能」であることが
好ましいように思うな。でも何十年も拒否してきた機能を今さら入れるだろうか?

894 :デフォルトの名無しさん:2007/10/01(月) 00:03:46
>>891
lhsとrhsが逆じゃね?(普通の習慣では)

895 :デフォルトの名無しさん:2007/10/01(月) 00:03:57
いま>>892がいいことを言った。


896 :デフォルトの名無しさん:2007/10/01(月) 00:06:31
演算子オーバーロードってユーザ定義型じゃないとだめじゃん

897 :デフォルトの名無しさん:2007/10/01(月) 00:18:29
orepp → cpp → cc → ar
これで解決
流用できないのでGPLも怖くないwww


898 :デフォルトの名無しさん:2007/10/01(月) 00:23:07
そんなQtみたいなソルーションは断る。

899 :デフォルトの名無しさん:2007/10/01(月) 00:23:37
誰が使うの?

900 :デフォルトの名無しさん:2007/10/01(月) 00:37:02
しゃーねーなぁ。一丁ドラフトでも書いてみるか。
0b10101010 とか 0xAA_BB_CC_DD とか 1,024 とか。

901 :デフォルトの名無しさん:2007/10/01(月) 00:39:22
俺の英語力を駆使してみた。
I want to use >>900.


902 :デフォルトの名無しさん:2007/10/01(月) 00:44:00
0bはすでに脚下済では?

903 :デフォルトの名無しさん:2007/10/01(月) 00:46:59
>901
お前頭いいなぁ

904 :デフォルトの名無しさん:2007/10/01(月) 00:50:41
0bは滅びぬ。何度でも蘇るさ。

905 :デフォルトの名無しさん:2007/10/01(月) 01:07:50
こりゃ次スレが必要だね。

906 :デフォルトの名無しさん:2007/10/01(月) 01:13:41
>>885
このstatic assert頭よくね?
コンパイルタイムでなくリンクタイムの失敗になるだろうけど。

907 :デフォルトの名無しさん:2007/10/01(月) 01:23:41
>>906
コンパイルタイムに弾くよ。
だって、static_assert<false> は未定義になるから、
illegal_bin_digit_found のサイズがわからーんってなるもん。

908 :デフォルトの名無しさん:2007/10/01(月) 01:24:09
>>906
失敗したらコンパイルエラーで止まるよ。

909 :デフォルトの名無しさん:2007/10/01(月) 01:26:13
勘違い。ごめん。
boostのはもちっと複雑だよね?boostのも同じ原理だっけ?

910 :デフォルトの名無しさん:2007/10/01(月) 08:24:02
>>900
>1,024

既存プログラムに非互換が出るから駄目だと思う。


911 :デフォルトの名無しさん:2007/10/01(月) 08:33:10
0-Fを見て0000-1111が浮かばないのか?

912 :デフォルトの名無しさん:2007/10/01(月) 08:46:56
だったら下線や空白なら平気ではないのか?

913 :デフォルトの名無しさん:2007/10/01(月) 12:05:06
dead_beefという変数に誤爆する可能性はないか?いや、無いか

914 :デフォルトの名無しさん:2007/10/01(月) 14:42:09
やべ、牛肉供給日の beef_feed も誤爆?いや、無いか

915 :デフォルトの名無しさん:2007/10/01(月) 14:47:59
0xを先行させるルールを忘れたもうな。

916 :デフォルトの名無しさん:2007/10/01(月) 15:04:47
(0x0)

917 :デフォルトの名無しさん:2007/10/01(月) 15:11:13
XCは0b出来たよな、記憶違いか…?

918 :デフォルトの名無しさん:2007/10/01(月) 15:13:34
独自に 0b をサポートしてるコンパイラは多い

919 :デフォルトの名無しさん:2007/10/01(月) 16:06:56
$ cat > a.cc
int i = 0b1010;
$ g++ -c a.cc
a.cc:1:9: invalid suffix "b1010" on integer constant
$ orz
bash: orz: command not found

920 :デフォルトの名無しさん:2007/10/01(月) 17:29:43
俺が慰めてやるよ

orz.c

#include <stdio.h>
main(){
printf("まあまあ\n");
}

コンパイルして使ってくれ。

921 :デフォルトの名無しさん:2007/10/01(月) 17:32:17
↓mainの戻り値云々

922 :デフォルトの名無しさん:2007/10/01(月) 17:33:41
こまけーこというなよ

923 :919:2007/10/01(月) 17:34:25
>>920
(TдT)アリガトウ

924 :デフォルトの名無しさん:2007/10/01(月) 17:41:28
$ cat > orz.cc
#include <iostream>
int main() {
  std::cout << "orz===3 プスー" << std::endl;
}
$ g++ -o orz orz.cc
$ orz
orz===3 プスー
$ w
 17:39:23 up 25 days, 23:16,  1 user,  load average: 0.00, 0.00, 0.00
 USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
 yy       tty1     -                 17:40    0.00s  0.09s  0.01s w

925 :デフォルトの名無しさん:2007/10/01(月) 17:45:42
>>921
orzの戻り値に依存してコード組んだら文字通りorzな結果になるんだから、
それはそれでいい。

926 :デフォルトの名無しさん:2007/10/01(月) 18:03:04
そろそろ次スレのことも視野に入れることが必要にもかかわらず
だんだんと低俗になってゆく悪寒。

927 :デフォルトの名無しさん:2007/10/01(月) 18:06:08
alias orz="echo '(´・ω・`)'"

928 :デフォルトの名無しさん:2007/10/01(月) 18:28:25
>>919
ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479

929 :デフォルトの名無しさん:2007/10/01(月) 21:12:13
>>928
情報ありが豚。

930 :デフォルトの名無しさん:2007/10/01(月) 21:43:54
リトルエンディアンとビッグエンディアンで二通りのルール作っていいから、
ビットフィールドの上がLSBって規格にしてくれないかな。

ビットフィールドに限らないけど、構造体で新しいメンバを下に書き足したら、
既存のメンバの位置がずれるなんて馬鹿かと。(そんなのに依存する書き方を
するなとか言うのはまた今度。言語としてルールが決まってても困らんだろうし)


931 :デフォルトの名無しさん:2007/10/02(火) 02:08:13
最適化の機会を奪うな!なーんてな。

932 :デフォルトの名無しさん:2007/10/02(火) 02:50:04
メンバポインタ使えばいいのに

933 :デフォルトの名無しさん:2007/10/02(火) 04:08:44
残念ながら世の中にはリトルでもビッグでもない変態エンディアンのアーキテクチャが存在します

934 :デフォルトの名無しさん:2007/10/02(火) 06:07:59
ttp://ml.tietew.jp/cppll/cppll/article/12789
こういうのかw
これは正直ワロタ

935 :デフォルトの名無しさん:2007/10/02(火) 08:04:39
>>930
やれやれ
初心者スレ行ってくれ

936 :デフォルトの名無しさん:2007/10/02(火) 08:14:32
0bってなんで却下されたの?

937 :デフォルトの名無しさん:2007/10/02(火) 10:07:15
>>935
自分がさも玄人のように上から見下ろした書き方をしているが、
実際にはお前だって大した人間じゃないだろう

938 :デフォルトの名無しさん:2007/10/02(火) 10:34:53
目くそ鼻くそ。

939 :デフォルトの名無しさん:2007/10/02(火) 10:48:05
大違いってことだな。

940 :デフォルトの名無しさん:2007/10/02(火) 13:22:29
しかし今さら非互換が出る構造体配置規定はないでしょう

941 :デフォルトの名無しさん:2007/10/02(火) 13:53:26
boostがsmart_struct作ってくれるよきっと

942 :デフォルトの名無しさん:2007/10/02(火) 14:51:09
>>940
現状特に規定が無いのだから、今さら非互換ってのにはあたらない
と思うが。あと0xは現状との互換性を完全に踏襲しようとしてるの?

943 :デフォルトの名無しさん:2007/10/02(火) 14:57:37
アーキテクチャによってはメンバーポインタがかなり複雑な実装になりそう。

944 :デフォルトの名無しさん:2007/10/03(水) 00:19:55
>>943
そのこころは?

945 :デフォルトの名無しさん:2007/10/06(土) 21:38:02
なんか、DがC++とリンク可能になったらしい…
クラスオブジェクトも相互利用できるらしい…
C++0xの優位性って何…?

946 :デフォルトの名無しさん:2007/10/06(土) 21:42:21
>>945
そうなの?C++ってABIぐちゃぐちゃなのに
g++の出力した*.oとはリンクできるとか、そういう話か?

どっちみち現在のC++はテンプレートベースのライブラリが多いから、
*.oとリンクできたところで何が嬉しいんだかよくわからん
それだけじゃ、STLもboostも使えないだろ

947 :デフォルトの名無しさん:2007/10/06(土) 21:47:56
そういえば、var って戻り値として宣言できるの?

948 :デフォルトの名無しさん:2007/10/06(土) 21:52:21
>>945
そもそも名前マングリングさえ統一されてないのに
どうやってリンクすんの?
特定の環境限定?

949 :デフォルトの名無しさん:2007/10/06(土) 23:03:14
というかDに何の興味もない

950 :デフォルトの名無しさん:2007/10/06(土) 23:27:19
>>945
boostが使えねーyo

951 :デフォルトの名無しさん:2007/10/06(土) 23:32:25
boostスレのこのコードは0xでは通る?
enum{ value = "a"[0] };


952 :デフォルトの名無しさん:2007/10/06(土) 23:33:56
ぱっと見では通りそうに見えるけど…
(キャストしなくてもいいのかは気になるが)
なんか問題あるコードなんだっけ?

953 :デフォルトの名無しさん:2007/10/06(土) 23:37:14
>>952
Boostスレ見れ

954 :デフォルトの名無しさん:2007/10/06(土) 23:48:08
C++0xが試せるコンパイラってあんの?
GCC4.3とか?

955 :デフォルトの名無しさん:2007/10/07(日) 00:28:14
>>954

Status of Experimental C++0x Support in GCC 4.3
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

956 :デフォルトの名無しさん:2007/10/07(日) 00:47:32
>>948
どうせDMC限定でしょ?

957 :デフォルトの名無しさん:2007/10/07(日) 10:41:44
0xが出るおかげでD涙目www

958 :デフォルトの名無しさん:2007/10/07(日) 10:54:37
どうせ両方とも変態言語なんだから方向性を尊重しつつ影響を与えあいつつ仲良くやってきゃいいと思うんだけどね。

959 :デフォルトの名無しさん:2007/10/07(日) 13:04:32
0b の話を蒸し返すけど
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
が通れば同じようなことはできるようになるはず。prefix じゃなくて suffix だけど。
ユーザーが拡張可能になるからものすごい変態的機能が実現できそうな気がする。

960 :デフォルトの名無しさん:2007/10/07(日) 13:30:32
これ大真面目に議論されているのかな。
C++ってどんな言語だったっけ。

961 :デフォルトの名無しさん:2007/10/07(日) 13:43:39
C with classes

962 :デフォルトの名無しさん:2007/10/07(日) 13:54:34
「何でもあり」
とWikipediaに書き込んだのは俺

963 :デフォルトの名無しさん:2007/10/07(日) 14:35:58
>>962
おまのせいでこんな言語になったのか!

964 :デフォルトの名無しさん:2007/10/07(日) 14:57:54
perlより読みにくいコードになりそうだな

965 :デフォルトの名無しさん:2007/10/07(日) 16:44:18
perlが読みにくいとか(笑)

966 :デフォルトの名無しさん:2007/10/07(日) 18:07:33
読みにくく書けちゃう、が正しいな。

967 :デフォルトの名無しさん:2007/10/07(日) 18:43:49
いあほんとにperlは糞だと思うよ
あの読み難さはビギナーにはかなりの苦痛。
C++も同じ方向に向かってると思うと悲しくてならん。

968 :デフォルトの名無しさん:2007/10/07(日) 18:44:55
次スレ・・・要らん、か。

969 :デフォルトの名無しさん:2007/10/07(日) 18:47:24
常考的に考えて必要。

970 :デフォルトの名無しさん:2007/10/07(日) 18:52:47
糞スレだから要らない

971 :デフォルトの名無しさん:2007/10/07(日) 18:54:46
次スレタイトルを>>959の記法で考えてみてくれ。

972 :デフォルトの名無しさん:2007/10/07(日) 18:59:20
C++0x2でいいのでは

973 :デフォルトの名無しさん:2007/10/07(日) 19:37:14
C++0xの国際化対応の文字列ってどうなるの?

今のC++のワイド文字はOS、コンパイラ変えると
仕様が変わるからメンドクサイんだけど・・・



974 :デフォルトの名無しさん:2007/10/07(日) 19:38:49
仕様とは?

975 :デフォルトの名無しさん:2007/10/07(日) 19:45:31
文字セット?

976 :デフォルトの名無しさん:2007/10/07(日) 19:54:26
conceptはいいな。早く使いたい。

977 :デフォルトの名無しさん:2007/10/07(日) 19:59:11
C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

978 :デフォルトの名無しさん:2007/10/07(日) 20:01:36
糞スレ乙

979 :デフォルトの名無しさん:2007/10/07(日) 20:13:20
ええぇー

980 :デフォルトの名無しさん:2007/10/07(日) 20:32:31
>>973
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2149.html

981 :デフォルトの名無しさん:2007/10/07(日) 21:36:38
U"こういうことか"

982 :デフォルトの名無しさん:2007/10/08(月) 02:12:51
C++ 2.0 とかでよくね

983 :デフォルトの名無しさん:2007/10/08(月) 03:43:17
だせ

984 :デフォルトの名無しさん:2007/10/08(月) 14:17:41
ぶっちゃけ++を継続する必要もないんじゃね

985 :デフォルトの名無しさん:2007/10/08(月) 14:45:40
No longer C++に一票。

986 :デフォルトの名無しさん:2007/10/08(月) 15:02:14
Cとのソースレベルの互換性を捨てて
NLC (No Longer C)とするのか。

987 :デフォルトの名無しさん:2007/10/08(月) 16:05:35
Nurupo Language C

988 :デフォルトの名無しさん:2007/10/08(月) 16:38:47
NULLをさっさと予約語にしてほしい

989 :デフォルトの名無しさん:2007/10/08(月) 16:41:45
予約語使い回しの現状を鑑みるに、ありえないだろうな。

990 :デフォルトの名無しさん:2007/10/08(月) 17:05:44
C++への開発リソースを、D1.0系のライブラリや開発環境への開発リソースに・・・

991 :デフォルトの名無しさん:2007/10/08(月) 17:19:29
>>988-989
残念、nullptr というのが与薬後になるよ。

992 :デフォルトの名無しさん:2007/10/08(月) 17:46:57
 

993 :デフォルトの名無しさん:2007/10/08(月) 17:47:29
testy

994 :デフォルトの名無しさん:2007/10/08(月) 17:48:05
this is a pen!

995 :デフォルトの名無しさん:2007/10/08(月) 17:48:47
asdf

996 :デフォルトの名無しさん:2007/10/08(月) 17:49:52
fuck you

997 :デフォルトの名無しさん:2007/10/08(月) 18:18:11
1000

998 :デフォルトの名無しさん:2007/10/08(月) 18:20:07
1000ならC++2015。

999 :デフォルトの名無しさん:2007/10/08(月) 18:22:40
あぽ

1000 :デフォルトの名無しさん:2007/10/08(月) 18:23:14
1000なら次スレ>>1死亡

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

170 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)