C++0x

おねがいします。

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

なんでまた C++0x スレに？
もしかしてマルチ？

マルチだね
どこだか忘れたが別スレで見た

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

C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？

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

おじいさんは、裏山に畑を耕しに行ったんじゃない？

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

いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。

>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。

書かれたものがキチガイだと
本当に誰にも通じないけどな。

N2133 06-0203
Editor's ReportPete Becker
2006-11-03
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2133.html

N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
新規色分け版

N2135 06-0205
Programming Languages −C++ Pete Becker
2006-11-06 N2134=06-0204
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf
色分けなし版

ちなみにADLのところ、3.4.2のルールが書き変わっています。

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

色の違いだったのね

論文リスト、ちらほら C++09 という記述が出始めたな

2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。

Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。

一番ほしいのはTemplate aliasesかな

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

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

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

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

とマニアが言っております

いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。

>>219
明暗！

言い得て妙な変換だなｗ

namespace std0x
{
  using namespace std;
}

namespace std0x = std;

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

>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。

>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ

BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい

"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…

>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。

>>217
Cryoliteたん？

>>215です。

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

rvalue referenceってなんなのさ？

ここで。

A Brief Introduction to Rvalue References
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html

>>233
よく纏まっていてわかりやすいね。

auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう

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

ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。

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

その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし

ここで>>217に戻る。

まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし

>パフォーマンスゲインも5倍

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

こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。

コンパイル時間も5倍に…

>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ

父さん、言語拡張症にかかって…

これからは言語のモジュール化ですよ。

>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？

>>247
お前マジ天才じゃね？

最終的には今日コンパイルすると昨日完了するようになる

そのコンパイラでコンパイラをコンパイルさせてください。

おまいらホント暇だなｗ

最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？

ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか

autoはC++09に確実に入るんじゃないのかな?

標準委員会、キーワード追加症にかかって…

>>254 それはずっと前からキーワード。

意味が変更される予約語はautoだけかな

しかしautoはどうかと思う…
型の弱い言語みたいだ

初期化される時点で型が決まってしまうのに、どこが弱いんだか。

コンパイル時に型が決定するのだから、弱いわけがないわな。

しかしtemplate引数の省略はどうかと思う・・・
型の弱い言語みたいだ

しかしboost.Anyが実装できるのはどうかと思う。
型の弱（ｒｙ

キャス(ry

vo(ry

悲しいかな、reinterpret_castやvoid*などの存在で、
C++が弱い型付けと分類されていることを見かける。

まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの

その理屈だと、アセンブラは弱い肩か？

アセンブラは弱すぎ。虚弱体質だな。

低級言語は型とかないだろ

>>265
まさにカタ無しだね

しかしこのスレの流れはどうかと思う。
頭の弱い……

JIS X3014:2003って、
ISO/IEC 14882:2003の逐語訳じゃないんですね。
省略されているところがあってびっくりしました。

13.3.1.2.3のnon-memberのところ。

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

シンボルの undef とこっから先 const の機能がほしい
スレ違いか？

シンボルの undef というか、スコープ付の define がほしい。

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

派生の禁止はできるようにならんの？

ttp://article.gmane.org/gmane.comp.lib.boost.devel/101260

あーなるほどね、宣言は出来るけどインスタンスは作れない、と。

>>273
>JISチームのチョンボ
まことしやかにささやかれてるけど真実味あるなｗ

>>276
あと、派遣の禁止も欲しいよなぁ。

>>277
古い。illegal

noninheritableがどっかにあったな

boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。

-ableにnotは不味いだろ。

>>283
ttp://msdn2.microsoft.com/ja-jp/library/h278d2d4(VS.80).aspx

>>282
英語的にはunが正しい。
何故nonになっているのかは不明

im と un を混同したのではないか

Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。

それは俺の戯言なので真に受けないように

Effectice C++ 3版でも突っ込まれてたような

http://en.wikipedia.org/wiki/C%2B%2B0x
右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね？

未定

わんくま加盟求む
http://blogs.wankuma.com/

ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry
>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").

もうC++0fでいいよ。

どうせVC7.1であと10年がんばるんですよ

>>295
スレ違い。

>>157

vector<int> v;
auto var = v.begin();

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

前者でないと困る。
前者なら、後者はauto const varという宣言で済むと思うが。

そうすると、vector<int>::const_iteratorではなくて、
cont vector<int>::iteratorになりそうな

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

ああboost::cref使えば良さそうな気がする

vector<int> v;
auto var = const_cast<const vector<int>&>(v).begin();
これでいいでしょ？

vをconstにしたいって話でcref？

>>303
それやるならstatic_castだろ。

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

C++0xを知らんけど
そんなことしてまでauto使う意味わかんね。

どっちかっていうと
そんなことまでしてconst_iteratorにする意味わかんね。

こういう手もある。まあかえって長ったらしくなっているけど。
boost::range_const_iterator<decltype(v)>::type var = v.begin();

アホが来た

>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf

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

boost::cref (std::tr1::cref) では無理なのでは？

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

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

#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;
}

boostにconst_beginってなかったっけ？

こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。

>>312
get() 使うなら当然できるけれど，それなら311で良いのでは？

v.begin()じゃなくて、begin(v)を使う派なのだが
（これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる）
こんな人にも、autoは役に立つのかしらん？

auto v = v.begin() const;
みたいな呼び出しができたらいいのにと思った

const audo v = v.begin()
の方がいいかも！？と思った

>>318
>>300
流れよめんのか

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf

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

一文字の接頭辞が複数続くのってなんかいやん
crend とかなにって感じー

何だかんだで、const auto& cv(v);
してから、cv.begin(), cv.end() が一番読みやすいかも

数学の関数とかみたいに
コンパイル時に式自体
を計算・展開できるような式関数導入して欲しい。

実装も添えて提案して頂かないとイメージが沸かない

>>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を作るの面倒だから判らなくもない。

今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。

>>326
少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と
規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。

がんばってtemplateでsinを実装するんだ(w

整数演算だけでか？ｗ

前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。

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

D 言語でいいよ、もう。

同様に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);}//計算式
}

スクリプトでも使ってジェネレートした方がはやくね？

プリプロセッサ強化だな。

ttp://video.google.com/videoplay?docid=-1790714981047186825
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。

templateの処理をプリプロセッサの役割とする
↓
Cでもtemplateできるようにする。

Cfrontみたいだな

もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ　

>>340
「バカヤロウ、まだ始まってもいねえよ。」

互換性はあるんじゃないか？今までのが非推奨になる感じで

old style cast とかどうするんだろ

>>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 には間に合わない様子

C++0a になりそうな気配が濃厚になってまいりました

C++0x2010でいいからもう

それは勘弁してw

C+(+0x2010)
→ 0x201C
いや、わかっているよ、こう解釈されないことくらい。

>>346
8208www

C++2008

可変個引数テンプレート(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/
おまいらもヒトバシラーしてみませんか？

Variadic Templates、入るかねえ?

>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

http://www.devsource.com/article2/0,1895,2061095,00.asp
によれば、template aliases が入ることになっているなあ。嬉しい。

nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど
そういうのはないんかな

#define nameof(x) typeid(x).name()

typeid(hoge).name()があるでしょ。
マングルされてたりいろいろ面倒だけど。

typeid().name()は正直使えない

まあ保証されている事と言えば同一の型のname()も同一である
という事だけだからな
リフレクションのような事は正直無理

>352
ttp://conceptgcc.wordpress.com/2007/04/24/variadic-templates-are-in-c0x/
だそうな。

まじか。
機能的にはC++0xに入る必然性があるけれど、
さらにデバックしにくくなりそう…

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

>>361
現状でも Boost.Function とか Boost.Variant とか
BOOST__PP_* で T0,T1,T2,... を生成してるやつは
エラーメッセージがハナモゲラ化してるわけで

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

concept が入ればエラーメッセージはかなりましになるのでは？

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-05

ほ

とりあえずC99準拠で

C99はC++の精神に反しているのに
実装にはC++の機能が必要というトンデモ言語

C++の精神自体がトンデモの塊だから問題ない

Javaのキャストみたいなもんだな

c99にc++の機能が必要とは初耳だな。

コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？

内容的には>>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]

へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。

すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。

これですな
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html

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

入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。

L"文字列" はどういう扱いになるん？

こんな感じかな？

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

UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？

あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。

UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする

>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?

>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。

下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ

uint8_tと読み直せばいいんじゃない。

uint8_t って optional だったよね。

何年か経ったらwchar_tはいらない子扱いされてそうだ

tcharでいいじゃん

>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw

>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375

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

>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ

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

ふつーにEUC

Unicode関連のロケールが標準に入ると考えていいんだろうか・・

CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？

8は保証されてるの？

下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。

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

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

と思っていたはずなのに

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

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

>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。

そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。

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

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

じゃぁ、wchar_t はTRON用ということでおｋ？

TRONはwwchar_tです。

でも、Windows は UTF-16 なんだよな？

>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。

どちらにしろ UTF-16 だろ？

つWM_UNICHAR
http://msdn2.microsoft.com/en-us/library/ms646288.aspx

char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。

C95みたいに後から追補出せばいいよ

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ビット以上を保証すると

>streams of non-char types have not attracted wide usage, so it is not clear
>that there is a real need for

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

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

Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。

WCHARあるからねー

>>413
意味が分からない。
どれに対するレス?

Windowsなんかうんこ

>>415
>>411

char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが

それはWindowsにはニュートラルな話。

Windowsとか持ち出してるのはただの馬鹿だろ

>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。

GCC だと wchar_t は 4 だったな。

>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。

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).

なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。

wchar_tがUnicodeじゃない処理系ってあるのかな？

>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?

GCC 4.3にC++0xの実験的サポート
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。


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

w

MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。

C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。

久しぶりにスレ伸びたな〜

まあ全部俺の一人芝居なんだけどな

同感

全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。

それがまさに独り芝居というものでは？

自問自答++

そうか、僕はここにいてもいいんだ！

おめでとう

>>431-432
まあでもC++0xに全く無関心でない様子は伺える
http://blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx

そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。

struct S {

　　int m;
};

sizeof(S::m)

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

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

>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う

いや、C++0xではどうなるかという話なんだけど。

friend のはこれ？ (PDF)

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

443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる

sizeof(S().m)みたいに一時インスタンス化すればおｋ？

OKでしょ。

ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。

いっそUnicode str;を入れようぜ

>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。

>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下

じゃ、_Unicode str;

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

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

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

まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う

>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。

ワイドな文字ってよく考えると意味不明だよね

仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ

もうUTF8って名前に決めちゃえばいいよ

ちょっと上の話題ぐらい読もうや。

>>458
UTF-8はmbs、つまりchar[]だろ。

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

名前の衝突を避けるにはダサネーミングはある程度しかたない

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

ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）

virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・

>>462
wchar_tのwは、wideでは？

>>450のshort charとか、long charとかで思い出したけど、
昔、整数型のshort (int) - int - long (int)からの連想で、
浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった

そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。

>>464
C++では予約語だが、Cではそうではない。

_Bool は仕方がないとは思うが失笑したな。

wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな

MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。

>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ

>>462
　そうだね勉強するよ。
　そういえば、1語長2語長なんて言葉もあったね。(敢えて言うが、
勿論1語長が1Byteなどと思っているわけではない。)
MSのAPIの影響(DWORDとかQWORDとか)でWORDを2byteと仮定して書いてしまった。
　あと、wchar_tはwide charなのにword charと書いたのは、素で間違えた。

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

訂正

× >>464
○ >>473

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

また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。

もともとobj-cはC++とは全然別物だろうに

>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。

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

gccがsizeof(wchar_t)==4でいいんだったっけ

-fshort_wchar フラグを指定したら 2 になるけどな。

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

C++0x実現まであと9年もあるから大丈夫

>479
cygwin 上だと gcc でも 2。

今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。

亡くなって当然ｗ

>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・

後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?

え、VC の cl にだけど

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

C++1xに名前変えるか

何でこんなに時間掛かるんだろう？

やっつけでやられても困る。

>>490
天才のお前が傍観者だからだよ

Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。

>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。

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 の更新情報は
今回からこっちに貼ることにしました。

C++X
の方が魚の骨っぽくて好き

もう規格なんてやめてBoost全部取り込んじゃえよ

それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う

古い Fortran みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。

C++はPL/Iを超える化け物言語になりつつあるな。

Javaほどじゃないけどな

は？

またジャバグラマか。

そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ

禿が死ぬまでには出来てると思うから気長に待つよ

なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話

>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…



…いや、的確か

PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー

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

他の言語は要らなくなるから、Programming Language/1。

その C++ と Objective-C を無理矢理繋げた変態言語の立場は。

お前ら頭良いんだからサッサと立派な規格でまとめてくれよ

よしきた

標準ヘッダファイル2chを追加

boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない

競争相手が無かったから

C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？

>JavaやLL言語のようなものはあっただろうか？

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

ねーよ。
C++の影響は計り知れない

cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。

その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。

勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。

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

C++ってマクロなんでしょ？

???

っ MFC

MFCとVC6は大量のC++挫折者を生み出しました

>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。

シェア90%のOSが推奨すれば広まって当然

じゃあこれからはドトネト天国だね

C#する気もしない気も〜VMの性能にかかっているんだよ〜

C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ

D が完成しさえすれば・・・。

ネイティブでGC無しというところが、
C++の強さにして弱み。

し、C++/CLIとかどうですか・・

Dもキメラ過ぎる

Dがもっとリッチに色々揃えば良いけど。

やっぱC++は最高だな

C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな

>533
でも委員会で GC の話してるみたいよ？

今のところHans Boehmの提案が最有力候補かな？

GC ねえ。
GC なしで組めるモードもあるんだよね？

C99に合わせたりはしないのかな。

>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ

>>542
だいたいのところは取り込まれてるみたい。

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-06-30: The 2007-06-pre-Toronto mailing is available

>>543
えーーー！

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

勘違いしてた

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

ごめんなさい

C++的には、使わなければ余分なコストはかからないというのは必須だろ。

そこでGCCですよ

GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので

GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな

>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。

>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？

shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし

なんだよかたそういう対照性か。
まさかソースコード上の対照性を言っているのかと思って心配になった。

>>554
メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない？
削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。

うーんもうちょっと調べ物してから言えばよかったかな。
あんまりはっきりしたこともいえないんで、スルー推奨。

超基本的な質問なんだけど

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

GCってオンオフするもんなの？
当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。
^とgcnewみたいなものじゃまずいのかなぁ。

すみません
int a[] = new int[10];
int *b = new int[10];
みたいに確保したときって
delete a;
delete a[];
delete b;
delete b[];
それぞれ解放の仕方で動作おかしくなりますか？

>>560 スレ違い。こっち逝け→ http://pc11.2ch.net/test/read.cgi/tech/1182740506/

>>560
とりあえず Effective C++ でも買ってこい

>>545
今回はいつもよりちと早めだね
小技系だが、N2332 がはげしく欲しい

やっぱSL73だろ
http://gradeup.blog39.fc2.com/blog-entry-31.html

みんな好き勝手いいやがって……だれが実装すると思ってるんだ

>>563
make_*関数が要らなくなるのは確かに便利だな。

最近のSutterは完全にC++/CLI宣伝だな。
そういう契約なのかな…

最新のドラフトってこれでいいのかな？

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

今日付けでn2369が出たみたい。

今日付けw　何とタイムリーな。
こいつかな？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

今日じゃないや、6日だ…

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

decltype 追加か。細かい仕様はともかく、追加は確定なのかな。
あと alignas, alignof, constexpr も追加。
そして、char16_t, char32_t も追加？ 色は変わってないけど。

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

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

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

しかし、結構ドラスティックな変更が多いと思うけど、
こんなんがあと二年でまとまるんだろうか

constexprは制限が強すぎて見た目ほど強力じゃなかったはず

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

FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、
気になって仕方がない。

= default と = delete がいまいち分かんないな。

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

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

うわあああ
もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ
=0ですらキモすぎるのに=deleteとか=defaultとか

フフフ。そのキモさが C++ なのさ！

純粋仮想関数とかいいながら、構文が汚れてるよな

不純だわ

不接触の純粋さは当然のこと。
穢れに触れて、それでも尚純粋であることの方が素晴らしい。

それもこれもstaticが全ての始まりでした…

*じゃね？

& もなかなか

POD という表現がことごとく修正されてるのは、
やっぱ constexpr の影響？

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

defaultをわざわざ指定するというのも可笑しい

default constructorをprivate宣言してというIDEOMともおさらばか。

.hと.cppを分けて書かせるのはいつになったらやめてくれるんだ

.hだけ書いて.cppの骨組みは自動生成するようにして、
関数の中身にタグジャンプとかすれば大して気にならんと思うけど

そんなん冗長にして無駄そのものじゃないか
現役言語でそんなことやってるのC++だけだぜ
存在することのメリットが一つもない

inline指定できないほど長い関数はアンチパターンだ
というのが委員会の非公式な見解（うそ）

.hを自動生成するg++へのpatch誰か作れ

>590
全部テンプレートで解決

>>587
= default は inline 化されないと書いてあるんだけど、
inline と = default の同時指定とかできるのかな？
同時指定できるならその目的に使えるとは思うけど。

ダメって書いてないから、出来るんじゃないの。
宣言は明示的だけど、実装はdefaultってのが、= defaultだから、
勝手にinline宣言したことにもしないって流儀じゃないかな。

.hが更新されてるかどうかで再コンパイルするかどうか決めるっていう
仕組みが前提だから.hが必要なんだろ
誰がこんなアホな仕組みにしたんだ

>>597
なるほど。それなら使い道あるやね。
protected にするとか使えそう。

>>598
それは別に問題ないよ。
.hを自動生成すればいいだけの話。

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

D とか .h と .d とに分かれてないけど

しかし.hが内容同じでも更新時間が変わってたら
再コンパイルされちまうぞ

それはC++0xの言語仕様じゃなくて、処理系の問題。

細かく差分みてコンパイルしてくれるような開発環境が必要だな

UMLでクラス図を書く→スケルトンとテストケース、make生成→あとは.cpp埋めてくだけ
ってのが欲しい

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

誰かヘッダ生成ツール作ってくれえ

欲しいと思ったときがプログラミング時です

いいこと言うなあ

たしかVC++もGCCもプロトタイプ生成の機能は持っているはず。
関数・変数だけだったらヘッダ生成に使えるだろうけど。

Cの現状はCとの互換性のためだからしょーがないだろ
C99があさっての方にいっちゃったけど、今更捨てる気もないだろし

C99でCﾊｼﾞﾏﾀと思ったのは俺だけじゃないはず

Cなんて代物を使うのは移植性と過去のしがらみのためだけで、
それ気にする必要も無いんならC++使うよ

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

いいこと言うなあ

ObjC厨の俺に喧嘩売ってんのか

Objected-Cは今後どうなるの？

どうにもならないだろうな

Objected-Cってなんだよｗ

これから始めれば無問題

>>600
dはコンパイル時に.hに相当するものを生成するオプションがある
ライブラリ作成時には必須

つーか.hは.cppから生成しないと最適化に必要な情報をぼんぼん取りこぼすと思うけどなあ
だからって最適化のためにいちいちinline展開しなきゃいけないというのもおかしな話だし

クラスの定義もcppに書くのかい？

>>587
デフォルトのコピーコンストラクタは各基底クラスと各データメンバのコピーコンストラクタを
使う。ビットコピーじゃないよ。

つーか、IDE 使うんなら .h と .cpp というファイルを直接編集するんじゃなくて、
もっと抽象的な形で編集できていいと思うんだよ。

>>624
その「抽象的な形」で書くってことは、つまり C++ ではない別の言語を使うということに
なるのではないかな。

俺の書くクラスは、.hppのクラス定義の中に全てのメンバー関数定義がある。
inline指定ない関数も、毎回コンパイルされているが、気にしない。
.cppも.hもない。

export template を使っておりますよ

hppに書いたらinlineと書かなくてもinline展開しようとする、と
言語仕様で決まってるんじゃなかったっけ
hppに書いたらinline展開するか、再コンパイルするかなど
コンパイラがよきにはからう、という言語仕様にしてれば
今頃は誰も分割なんかしてないだろう

>>628
> hppに書いたらinlineと書かなくてもinline展開しようとする

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

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

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

inlineを指定しなくても指定したかのように扱われるのは、
メンバ関数の定義をクラス定義内に書いたらの話。

しかしhppに全部書いたら関数に変更加えるだけで
依存するクラス全部再コンパイルされて、
それに依存するクラスも全部再コンパイルされて・・・
となってほぼ全クラス再コンパイルされちまうよな
なんでこんな糞仕様なんだ

>>631
Visual C++の簡易リビルドは、そういうときに
再コンパイルをしなくていいものはしないという機能ではないか？
仕様がアレでもコンパイラが頑張るとそんなこともできるという話。

>>631
つ pimpl

こうなったら
inline = default
も追加だ

>>633
pimplは.hと.cppをがっつり分けてもなお依存性がやばいことになるという
C++の仕様に対する対策じゃん
ポインタ越しの関数もinline展開されたらまるで対抗できない

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

gccにもプリコンパイルドヘッダはありますが。

簡易リビルドは、ヘッダが変更されていても、
変更された部分に依存していなければ再コンパイルする必要がない場合を
うまく見分ける機能じゃないの？
gccにそんなんあるかい

>>635
> ポインタ越しの関数もinline展開されたらまるで対抗できない

ｵｲｵｲw

>>638
.hに実装を書いたらpimpl使ったって
virtualでない限り基本的にはinline展開されちまうだろ

いったいコンパイラは実装が別の翻訳単位にある
メソッドをどうやってインライン展開するというのだろうか。

リンク時にがんばればいい。

あれ、展開されないか
かなりおかしなことを言ってるな

>>640
cl.exe の /Og がまさにそれじゃなかったか？

そういえばVC++は最適化のために
.cppに書いてあるものも勝手にinline展開したりするんだよな

まあよくわからんけど、.hと.cppに分けないとpimplも使えないし
そもそも何もしなくてもデフォルトでpimplになってるべきだよな
その辺の仕様が古臭すぎる

>>644
gccもiccも当たり前のようにinline展開しますが何か。

毎日コンパイルしてテストせよという時代に
pimplなど笑止千万。

毎日コンパイルしてテストせなならんから
コンパイル速度を上げるpimplが必要なんだろ

>>647はpimplを何だと思ってるんだ？

にきび

>>644
それどころかDLL内の関数すらインライン展開できる。
http://msdn2.microsoft.com/ja-jp/library/feffc7b5(vs.80).aspx

VCの最適化能力は異常

>>639 がスルーされている件について

うまいことごまかしたと思ったんだが・・・

.cppが無理やりインライン展開されちまうんじゃ
.cppのちょっとした変更でも再コンパイルがわけわかんないとこまで広がりかねんな

そこでインライン展開は実行時JITに任せる方式が登場するわけです

おまえらここじゃなくて最適化スレを活用しろよ
0x++でそこらへんの仕様が変わるって言うなら別だが

そこらへんの仕様は変わらんのか
じゃあC++の今後には何の期待も出来んな

それはお前の勝手。

もっと声をあげていかなアカンと思うぜ
.hと.cppを分けなければならないのは冗長で腐った考え方だ
クロージャを導入する前にそこをまずなんとかしろ

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

>>660
言語仕様を俺の頭の悪さに合わせろ！とはなんとも無茶な注文ですね

まじめな顔して書くが
>>660みたいなのはDやればと思ってしまう

そもそも規格自体は .h と .cpp をわけろとか一言も書いてないと思うけど...
標準のヘッダは .h というか拡張しなかったりするけど、それ以外は
プリプロセッサが処理したあとの話しか規定してないわけだし。

分けたくないなら全部.hに書けよ、一人で勝手にさぁ。

まあでも、ヘッダとcppファイル間の間には、
IDEの支援がもっとあってもいいと思う。

D言語はGCがあるからパフォーマンスが必要なプログラムが書けない
せっかくネイティブなのに

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

.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
言語仕様で決まってるんだよスカタン
なんだこの糞仕様

＞.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
妄想乙。

妄想じゃねー
暗黙 inline とかでぐぐれ

>>667は文章が下手。
「全部inline展開しようとする」は、
「全部必ずinline展開しようとする」、
「全部inline展開の考慮対象とする」のどちらにも読める。

>>670
どっちも同じ意味だろ
どっちも間違ってない

>>669
それはクラス定義内での関数定義の話ではないのか？

>>672
定義と宣言というのは正しい用語だがわかりにくいから
俺は.hに実装を書けばという言い方をする
.hの中でクラス定義と関数定義を分ける意味がないから普通は
クラス定義内の関数定義のことだと分かってもらえると思うが

>>673
こんなスレでそんなわかりにくさを気にするような奴はいないから、
そんな気を使う必要はないよ。

でも気遣う努力は素晴らしいことだよ、とフォロー。

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

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

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

outline とか追加されねーかなあ

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;

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

実装隠したければ・リンク互換性保ちたければ
pimpl使えってことじゃないのC++的には
ただのイディオムではなく言語的にもっとサポートがあると楽でいいんだがな
いつもいつもいちいち委譲のコードなんて書きたくないし

#includeなんてソースコードほんとに読み込むしな
原始的すぎる
Packageみたいなものをサポートする予定はないのかね

ヘッダでインクルードガードを検出したら同じ翻訳単位内では以後無視する最適化はしてあるよね
pImpl は extern と export で撲滅できるし

>>666
GC使わないこともできるよ。

インクルードガードも、たとえばVCの#pragma onceみたいなものを規格化すべきだと思っているんだけど、
必要ないのかな？

>>681
むしろexportのほうが撲滅されそうないきおいジャマイカ

インクルードの仕組み自体全部作り直せよ
ソースを置き換えるっていうこと自体問題が多すぎる
パッケージ内のクラス定義を一気に導入して
実際に使っているクラス定義にしか依存しない、という機能があればいい

>>685
Cとの互換性を捨てていいんならいくらでもやりようはあるだろうけど
今更それは出来んだろ

includeはincludeで残して、
packageというのを作ればいいんじゃね
これ導入したらincludeまで壊れるか？

ああ、includeも互換性のために残したままでシンボルテーブルをインポートする
新しい仕組みを作るのか
それならいいかもな

それはどこの .net f(ry

>>667 は inline 関数は全部 inline 展開されるとでも思ってるのかね。

「しようとする」という書き方を見て、「されるとでも思ってるのかね」もないもんだと思うがなぁ。

頭大丈夫か?

>>692
お前の頭の話なら、ダメかも。

>>684
export を使うとコンパイルの挙動が異様におもしろくなるので
コード書きのモチベーションに変化があったりなかっ…なくはない

なんでexportでpimplがいらなくなるんだ？

>>678
"to be preferred"を"優先される"は強すぎるだろ。
これこそ「しようとする」だ。

C++0xに関する映像出てるね
びょーんすっぽすっぽサマの声が聞けて嬉しす。

>>686
C++は既にCとの互換性を失っていますが

C++をおかしくした禿げのことか

これは良スレ

もうJavaっぽいGCなしのネイティブ言語つくろうぜ

Qtをさわった感じがそんなんだった。＞GC無しJava

字句解析つきマクロがあれば何でもできる。

そこでNemerleですよ

boostを作った変態たちにまともなマクロを与えたら
とんでもない言語を作ってくれると思うんだけどなあ
templateだけじゃやっぱ弱いよ

今のところ成功してるマクロはLispのものしかないな
「何でもできる」ってのはやっぱ危険だよ。

なんでも出来るのがC++の強みだよ

SASのマクロもかなり強力でかなり凶悪ですよ。
知っている人ほとんどいないと思うけど･･･

>>701
D言語に謝れ

実際組んでると auto が便利すぎてﾜﾗﾀなんだこれ

autoってなに？
typeof(hoge) var;のこと？

>711
多分同じことを指してるだろうが auto i = c.begin(); みたいに書いた方がわかりやすくないか？

暗黙的な型推論はC#3.0は本決まりでJavaは検討段階だっけかな

auto 仕様

※ PDF ! PDF !

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

記憶指定子のautoよさらば！
って感じだな。
で、ついでにデフォルトのintも廃止されるのかな。

デフォルトの int ってまだ有効なんだっけ？

少なくともISO C++98にはない。おそらくそれ以前になくなったはず。
ついでに言うとC99でもなくなった。

後生大事に auto を予約語に残しておいた甲斐があったなｗ

export…

C++ 0xを実験的に実装したコンパイラとかないのか

>>720
Comeauのv439β使ってる
コンパイラの実装制限による仕様抑制が全くないC++の開発効率の高さは異常

地味な変更に今更気づいたけど、
別のコンストラクタを呼ぶことができるようになったんだね。

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

Comeau ってことは、export が使えるやつか。いいなあ。

ConceptGCCもそれなりに0x実装しているんじゃないのかな

込め会うってどこで手にはいるの？

ここから買え→ http://www.comeaucomputing.com/

>>720 g++

補足。
ttp://gcc.gnu.org/gcc-4.3/cxx0x_status.html

>>726
下の方でチラチラしてるやつ胡散くせーなぁｗ

0xには結局GCは入るの？

gcnew

GCCでもexport使えるようにならんのかなぁ

>>726
広告ｳｻﾞｽｗｗｗｗｗ
どこぞのエロサイトかと

export早く消えねえかな

20年後位にautoみたいなすてきキーワードになって帰ってくるはずさ

たまにはregisterのことも思い出してやってください

完全に忘れてたｗ

覚えてるよ
しかし使ったのは４年くらい前が最後か

>>736
なつかしす。autoみたいに、いかす再利用法を考えてあげようぜ。

なんかregisterも、いつの日か再利用される日が来たりして。

単語の意味的に再利用する方法がおもいつかん…

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

「登録する」とか系の意味で再利用できんかな

register obj

objのGCに抵抗する。

レジスタと同じ大きさの数値型とか。
intはCPU/OS依存ではなく処理系依存だしねぇ。

javaみたいに整数型のビット数は言語仕様で固定として、
浮動小数点数は strictfp で IEEE 仕様に変更できるとかがいいな。
その上でregisterが整数型として存在するならありがたい。

template引数でビット数とか浮動小数点の精度とか
数の特性を指定できるようにすりゃいいんだよ
型も作っちゃいますみたいな

>>743
分かって言ってるんだとは思うが、抵抗するはresist

re gist erをgoogle翻訳すると「再要点えー」

>745
strictfpって、遅くなる可能性がなかった？

不動小数点数の扱いを規格化作するから速度的にはね。
飽くまでCPUごとのFPUに依存したくないときに指定するものだし。

near,farが完全に忘れられてるんだが

DOSとその有害な子孫の16ビット処理系コンパイラにしか存在して無いだろ

ファーッ、こんな侮辱初めてだわ。

ニイヤー、それほどでもないよ。

美少女中学生のフラットなおっぱいの先端を仮想エクステンドさせで何度もコールするとにゃッとかふァァッとかいい声で鳴くわけですね

すごい勢いでクソスレ化している

near, far って既に規格から消去されてないか？

一度でも標準規格に載ったことがあったか？

もちろん参考扱いだったはずだが、
JIS X3014:2003を見ると、allocatorのところに、
farポインタ用のchar_traitsを定義する例が載っているんだ。

アロケータでnearとfarを隠蔽する試みって結局失敗したんじゃないか？

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]

C++0xって楽しそう！
使ってみたい！
あ

い

う

e

オスマン・サンコンですぅ〜

だまれ

>>762->>766
つ あ
http://pc11.2ch.net/test/read.cgi/tech/1186388884/

あれっなんか変だ…
○>>762-768

×>>769
○>>762-766
スレ汚してすまそん逝ってきます…orz

急に盛り上がってると思ったらゴミレスか

もう俺C++ 0xで開発するわ
autoのない世界に戻れそうにない

C++03なら既に入手可能だな

03は98とほぼ同じ代物だし

C++2.0とか命名しなかったセンスは褒めたい

あんな風潮に迎合できるほど彼らの髪は残ってないからな。

777

どうせすぐにC++1xの策定準備に入るつもりだからだろう

アメ公ならx使ったら次は360とかにするかも

++C++

C++ 2008 XP Professional

C++ Home Edition

C++ Ultimate

C++ Orz

>>784
C++にひざまずいてるように見えるな

Wirth先生、PASCALがヒットしたのに(Turbo Pascalがあったからね)
気をよくして第２？３弾としてMODULA２を作ったけどさっぱりだった。

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

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

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

　　ﾋﾞﾖ〜ﾝ
〜（＾Д＾）〜

>>786
Modula-3, Oberon, Oberon-2も知らないのね。

>>789
知らんでもいい。
Ada-95を知っていれば十分。

C--
C>>
C<<
C==
C||
C&&

C
C++
C+=2
C+=3

Dを先にとられちゃったのが痛いな

C Abnormal

>>793
「元祖D」とか「総本家D」で桶

はじめてのC

やればできるC
いきなりのC

それは入門書の名前だろ

HOW TO 本だろ

はうはううううう

頭文字C

--D

~C

いつからC++の次期バージョンの名前を考えるスレに？

そろそろ、捨てるべきものを捨てて言語を整理するべき時期に来たんじゃないかな
だから、新しい名前が必要に・・・

もっとあぶないC++

C++フォーエヴァー TVスペシャル0x

C^2

JavaC++

C++ デンマークから愛をこめて
C++ C++は二度死ぬ
C++ わたしを愛したJava

愛をこぬて

C NEXT

After C

Alternate+C

CXX mkII

G

Cex

C++'s Counterattack

関数テンプレート構文がこんな感じに書けたら楽なのにな
auto func<int val>(auto arg) { return val * arg; }

それって
template <int val, typename T> T func(T arg) { return val * arg; };
だとなんかマズい？

あぁ、書き方の問題か。

>>819
それって、引数に与える型によって返値型がころころ変わるのがいやだなあ。

>>819
引数や返値にautoを使用したとすると、参照にしたい時とか面倒そうだなあ

きっと auto& を使うんだyo

#include <auto.h>

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

>>822
template構文でも、こう書けば同様に戻り値の型が
ころころ変わることを表現できそう（実際これが可能かは知らない）。
template<int val, typename T>
decltype(val * T()) func(T arg);

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

auto func = <>(val) { <>(arg : val) { val * arg } };
auto func10 = func(10);

…というのはクロージャじゃないからダメかなやっぱ (N2329ね)

C++0xのコンパイラどこ？

ドクロが見つめる一本杉の根本に埋めてあるよ

>>830
ドラえもん乙

>>830
教えてくれてありがとう！

>>830
ぴぴるぴるぴる（略

9月分来てるね。

何が変わってる？

マルチメソッドなんて入るの？

C++に入れられない仕様など無い。

マルチメソッドって禿のお気に入りだったやつ？
D&Eでしつこいほどに言及してたけど。

>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);

正直Objective-C++0xに期待してまふ

げろげろ

俺はC++/CLI0xに期待だぜ

C++/CLI (笑)

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)
とかってのは駄目？

どんな型を持った変数に戻り値を入れるんだろうと
::&演算子?

あと2年半弱か..

やっぱり、2009年内に間に合わなかったら
そこからあと90年待つのかな。

>>844
現行のC++にもメンバへの参照はないな。

>>848
レスありがと。
そっか、別に必要と思う局面は思いつかないけど
なんで無いんだろうねぇ。

>>849
参照は必ず実体を指す、という制約がクラス継承によってさっくり破られるからな

>>850
おー！なるほど！
そういうことだったのか。
T& を T* const と思い込んでたから気付かなかったんだぜ。

C++0x　<-よーくみろ！これは数字じゃなくて16進定数のプレフィックスだ！
ってことは、ってことは！！

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






まさに外道。

C → C++ → C++0x → <<C++0x → <<C++0x() → <<C++0x(\->)

それなんて顔文字？

ほんとにC++09は間に合うのかね？
てか、g++は追従できるんだろうか・・・。

comeauならやってくれるさ

米屋ぁう

Ct

C++0x2009

>>859だと C+(+0x2009)になるのかな？

>>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

VC8だとローカルクラスをテンプレートパラメータに渡せてしまったんだが、
これが標準になれば、lambda無くても良くね？

むしろローカル関数を

lambdaじゃなくて名前付きのローカル関数？

>>863
ローカルクラスのstaticメソッドで十分では。

>>865
めんどいしhackっぽいのが嫌じゃない？
クロージャも使えないし。

>>866
たしかに面倒というほかないが、
tr1::bindとstaticメソッドさえあればクロージャはできるよね。
まあ、lambda欲しいけど。

たのむ、0x0000_0000_0000って書ける様にしてくれ。64ビット時代になったらしむる。
そんな大それたお願いじゃないからさ

32進数を作ればいいじゃない

>>868
2進表記もほすい

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

typeofはどうなるんだ

decltype が入るジャン？

どうせなら好きな基数で数を書けるようにして欲しい
3進法や5進法が欲しくなることもたまにあるし

アンダースコアによる数値の書式整理は欲しいね。Python がうらやましい

>>875
Pythonにアンスコ区切りないよ？
バイナリリテラルはあるかも知れないが

人気者のPythonがうらやましす

>876
あれ。違ったか。ごめん。ずっと Python だと覚えてた
12_000_000 って数値の書式を整理できるﾔｼ

_区切りは慣れると手放しがたくて困る。

perlは_区切りできる。
perlで出きるのを見てて、Cでも出来るものと勘違いしてたよ。
あると読みやすいね。

64bitが主流になったら検討されるかな

int64_t hoge = 0xFFFFFFFFFFFFFFFF;

とか書きたくないな

昔ながらのMAKEWORDの類のマクロまたはインライン関数でいいんじゃねぇの？
コンパイル時に定数として埋め込まれるでしょ

アンスコを数値に追加してパース時に読み飛ばしてくれるだけで対応できるんだけど
こういうちょっと便利な内容っていつでもできるからって議題に上がらなくて
結局、入らないんだよね

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

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

>>881
int64_t hoge = ~0;

>>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 };
};

>>871
Binary<0101>::value で static_assert 失敗するのはダメだろ。

>>886
8進数になるから無視していいのでは。

数値のカンマ区切りならoperator orverloadで現行でも何とかなりそうとか思ってみたりみなかったり

英語力に自信のある人、ドラフト投げてみてくれ。
今を逃すとc++1x送りになるだろし。

>>888
そりゃ難しくないかい？俺の頭では無理っぽい。
だって、何桁目のカンマか識別できないもん・・・(´・ω・｀)

return rhs*1000+lhs; すりゃいいわけだから、識別しなくていいんじゃね？

実行時評価ｗ

こういうのって可読性の問題だから「俺様定義すれば可能」より「標準の機能」であることが
好ましいように思うな。でも何十年も拒否してきた機能を今さら入れるだろうか？

>>891
lhsとrhsが逆じゃね？（普通の習慣では）

いま>>892がいいことを言った。

演算子オーバーロードってユーザ定義型じゃないとだめじゃん

orepp → cpp → cc → ar
これで解決
流用できないのでGPLも怖くないｗｗｗ

そんなQtみたいなソルーションは断る。

誰が使うの？

しゃーねーなぁ。一丁ドラフトでも書いてみるか。
0b10101010 とか 0xAA_BB_CC_DD とか 1,024 とか。

俺の英語力を駆使してみた。
I want to use >>900.

0bはすでに脚下済では？

>901
お前頭いいなぁ

0bは滅びぬ。何度でも蘇るさ。

こりゃ次スレが必要だね。

>>885
このstatic assert頭よくね？
コンパイルタイムでなくリンクタイムの失敗になるだろうけど。

>>906
コンパイルタイムに弾くよ。
だって、static_assert<false> は未定義になるから、
illegal_bin_digit_found のサイズがわからーんってなるもん。

>>906
失敗したらコンパイルエラーで止まるよ。

勘違い。ごめん。
boostのはもちっと複雑だよね？boostのも同じ原理だっけ?

>>900
>1,024

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

0-Fを見て0000-1111が浮かばないのか？

だったら下線や空白なら平気ではないのか？

dead_beefという変数に誤爆する可能性はないか？いや、無いか

やべ、牛肉供給日の beef_feed も誤爆？いや、無いか

0xを先行させるルールを忘れたもうな。

(0x0)

XCは0b出来たよな、記憶違いか…？

独自に 0b をサポートしてるコンパイラは多い

$ 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

俺が慰めてやるよ

orz.c

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

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

↓mainの戻り値云々

こまけーこというなよ

>>920
(TдT)ｱﾘｶﾞﾄｳ

$ 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

>>921
orzの戻り値に依存してコード組んだら文字通りorzな結果になるんだから、
それはそれでいい。

そろそろ次スレのことも視野に入れることが必要にもかかわらず
だんだんと低俗になってゆく悪寒。

alias orz="echo '(´･ω･｀)'"

>>919
ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479

>>928
情報ありが豚。

リトルエンディアンとビッグエンディアンで二通りのルール作っていいから、
ビットフィールドの上がLSBって規格にしてくれないかな。

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

最適化の機会を奪うな！なーんてな。

メンバポインタ使えばいいのに

残念ながら世の中にはリトルでもビッグでもない変態エンディアンのアーキテクチャが存在します

ttp://ml.tietew.jp/cppll/cppll/article/12789
こういうのかw
これは正直ワロタ

>>930
やれやれ
初心者スレ行ってくれ

0bってなんで却下されたの？

>>935
自分がさも玄人のように上から見下ろした書き方をしているが、
実際にはお前だって大した人間じゃないだろう

目くそ鼻くそ。

大違いってことだな。

しかし今さら非互換が出る構造体配置規定はないでしょう

boostがsmart_struct作ってくれるよきっと

>>940
現状特に規定が無いのだから、今さら非互換ってのにはあたらない
と思うが。あと0xは現状との互換性を完全に踏襲しようとしてるの？

アーキテクチャによってはメンバーポインタがかなり複雑な実装になりそう。

>>943
そのこころは？

なんか、DがC++とリンク可能になったらしい…
クラスオブジェクトも相互利用できるらしい…
C++0xの優位性って何…？

>>945
そうなの？C++ってABIぐちゃぐちゃなのに
g++の出力した*.oとはリンクできるとか、そういう話か？

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

そういえば、var って戻り値として宣言できるの？

>>945
そもそも名前マングリングさえ統一されてないのに
どうやってリンクすんの？
特定の環境限定？

というかDに何の興味もない

>>945
boostが使えねーyo

boostスレのこのコードは0xでは通る?
enum{ value = "a"[0] };

ぱっと見では通りそうに見えるけど…
（キャストしなくてもいいのかは気になるが）
なんか問題あるコードなんだっけ？

>>952
Boostスレ見れ

C++0xが試せるコンパイラってあんの？
GCC4.3とか?

>>954

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

>>948
どうせDMC限定でしょ？

0xが出るおかげでD涙目ｗｗｗ

どうせ両方とも変態言語なんだから方向性を尊重しつつ影響を与えあいつつ仲良くやってきゃいいと思うんだけどね。

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

これ大真面目に議論されているのかな。
C++ってどんな言語だったっけ。

C with classes

「何でもあり」
とWikipediaに書き込んだのは俺

>>962
おまのせいでこんな言語になったのか！

perlより読みにくいコードになりそうだな

perlが読みにくいとか（笑）

読みにくく書けちゃう、が正しいな。

いあほんとにperlは糞だと思うよ
あの読み難さはビギナーにはかなりの苦痛。
C++も同じ方向に向かってると思うと悲しくてならん。

次スレ・・・要らん、か。

常考的に考えて必要。

糞スレだから要らない

次スレタイトルを>>959の記法で考えてみてくれ。

C++0x2でいいのでは

C++0xの国際化対応の文字列ってどうなるの？

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

仕様とは？

文字セット？

conceptはいいな。早く使いたい。

C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

糞ｽﾚ乙

ええぇー

>>973
つ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2149.html

U"こういうことか"

C++ 2.0 とかでよくね

だせ

ぶっちゃけ++を継続する必要もないんじゃね

No longer C++に一票。

Cとのソースレベルの互換性を捨てて
NLC (No Longer C)とするのか。

Nurupo Language C

NULLをさっさと予約語にしてほしい

予約語使い回しの現状を鑑みるに、ありえないだろうな。

C++への開発リソースを、D1.0系のライブラリや開発環境への開発リソースに・・・

>>988-989
残念、nullptr というのが与薬後になるよ。

 

testy

this is a pen!

asdf

fuck you

1000

1000ならC++2015。

あぽ

１０００なら次スレ>>1死亡

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