トップページ⇒tech
1001コメント251KB

C++0x 6

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2009/06/16(火) 03:57:31
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

Wikipedia
http://ja.wikipedia.org/wiki/C%2B%2B0x

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
0002デフォルトの名無しさん2009/06/16(火) 06:02:49
2
0003デフォルトの名無しさん2009/06/16(火) 06:10:25
>>2
お前はそれで満足なのか？
人生に何の疑問も感じないのか？
0004デフォルトの名無しさん2009/06/16(火) 10:11:49
いらない子、そんな言語を熱く語るいらないエンジニアの溜まり場。
0005デフォルトの名無しさん2009/06/16(火) 20:32:46
C++0x学園の人々

○コンセプトさん
学園のアイドルだが、入学してから一度も登校していない。退学の噂も。

○ラムダさん
ものすごい顔のせいでみんなから避けられてるいじめられっ子。
アルゴリズム部とは仲が良い。

○右辺値参照さん
成績優秀だが気難しい。仲良くなれればお得。

○禿
校長先生。

ここまで書いて飽きた
0006デフォルトの名無しさん2009/06/16(火) 21:01:16
21世紀中に完成するだろうか・・・
0007デフォルトの名無しさん2009/06/16(火) 22:35:58
完成→停滞→死

つまり完成しない方が良いということにならないだろうか？
0008デフォルトの名無しさん2009/06/16(火) 22:42:55
なんて横浜駅･･･、もとい、サグラダファミリア･･･
0009デフォルトの名無しさん2009/06/17(水) 00:07:29
>>6
それ何てロングパス
0010デフォルトの名無しさん2009/06/17(水) 19:55:54
完成しても、仕事じゃ使えねーよ。
0011デフォルトの名無しさん2009/06/17(水) 20:41:02
完成しないと枯れないから、いっそう使われないだろ
0012デフォルトの名無しさん2009/06/20(土) 03:16:59
Singnal/Slot機構が入らないのは痛いな。
0013デフォルトの名無しさん2009/06/20(土) 04:41:40
使えない言ってる人もコンパイラが対応しだしたら当たり前のように使うに100ペソ。
0014デフォルトの名無しさん2009/06/20(土) 07:09:51
プログラマって基本的に新しい物好きだと思うから趣味としてはそうなんだろうが、仕事となると同じようにはいかないよね
0015デフォルトの名無しさん2009/06/20(土) 07:55:10
今のところ仕様を追いかけるのは大丈夫だが、いつ疲れるのだろうか
0016デフォルトの名無しさん2009/06/20(土) 12:23:34
>>15
もうとっくに疲れてるよ…。orz
0017デフォルトの名無しさん2009/06/20(土) 16:24:22
マッサージしてあげるよっ！と妙にハイテンションな美少女中学生
0018デフォルトの名無しさん2009/06/20(土) 20:33:58
>>12
特定フレームワークでしか使わないでしょ。
0019デフォルトの名無しさん2009/06/21(日) 01:12:22
>>18
だが、そのフレームワークで使って欲しいんだな

それと、TR2とGCの実装が楽しみだな。何年後になるかわからんけど…
0020デフォルトの名無しさん2009/06/21(日) 13:11:27
GCいらね
0021デフォルトの名無しさん2009/06/21(日) 13:18:07
>>19
gtkmmのことか？
0022デフォルトの名無しさん2009/06/21(日) 17:42:09
qtかも
0023デフォルトの名無しさん2009/06/21(日) 17:47:32
gtkmmには既にsigC++があるしな。
qtのはまだmoc使ってんでしょ。
0024192009/06/21(日) 18:04:24
>>21
ご察しの通りgtkmmのことです。gtkmmは0xになると、Glib::RefPtr
の代わりにshared_ptrを使うようになるはずだし、libsigc++も
標準のものになれば良かったなと。
0025デフォルトの名無しさん2009/06/24(水) 03:11:44
ttp://gcc.gnu.org/projects/cxx0x.html#concepts
ここでコンセプトの実装をしようとしているから、g++はちゃんと
コンセプトを実装するんじゃない？
0026デフォルトの名無しさん2009/06/24(水) 03:17:19
ちなみに、C++にGCが実装されるとなるとどういう実装になるんだ？
クラスの作成に制限があったりするのかな。
0027デフォルトの名無しさん2009/06/24(水) 09:45:31
>>25
されてないよw
http://gcc.gnu.org/viewcvs/branches/cxx0x-concepts-branch/gcc/cp/concept.c?view=log
0028デフォルトの名無しさん2009/06/24(水) 16:55:29
クソみそに遅くなりそうだな。
0029デフォルトの名無しさん2009/06/24(水) 20:18:07
美少女中学生はスカトロには興味ありません！ありませんったら！
0030デフォルトの名無しさん2009/06/24(水) 20:51:38
conceptGCCは中心開発者が抜けて事実上の開発中止です
0031デフォルトの名無しさん2009/06/25(木) 02:11:57
ほんとだ。こうなったら、標準化委員会にリファレンスコンパイラを
作ってもらうしかないか。
つうか、俺にとってはg++がある意味リファレンス実装だからなぁ、
頑張ってほしいもんだ。
0032デフォルトの名無しさん2009/06/25(木) 05:06:19
http://www.open-std.org/jtc1/sc22/wg21/
News 2009-06-24: The 2009-06 pre-Frankfurt mailing is available
News 2009-06-24: The C++ Standard Core Language Issues List (Revision 64) is available
News 2009-06-24: The C++ Standard Library Issues List (Revision 65) is available

current draft: N2914
0033デフォルトの名無しさん2009/06/25(木) 07:24:02
>>30
> conceptGCCは中心開発者が

export concept mapだってさw
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2918.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-06
0034デフォルトの名無しさん2009/06/25(木) 07:47:57
export concept mapがないと、
constrainedなコードと、unconstrainedなコードで重複したコードを書かなければならない。
その場合、どうせコピペされるだろうから。言語でマシな方法を提供した方がいい。

最高の提案とも言えないが、必要だと思う。
0035デフォルトの名無しさん2009/06/25(木) 19:38:08
そうは言ってもexportと聞いただけで体が拒否反応を起こす
0036デフォルトの名無しさん2009/06/25(木) 22:35:11
しかしまとまるのか？
つーか禿はこの期に及んで新規提案とか何考えてるの
0037デフォルトの名無しさん2009/06/25(木) 22:44:27
たぶん提案しているうちが一番楽しいんだろう
0038デフォルトの名無しさん2009/06/26(金) 00:46:53
N2905とか悪い冗談にしか見えないんだがどこまで本気なんだろ
0039デフォルトの名無しさん2009/06/26(金) 09:06:47
コンパイル時とランタイム時で、似たようなことをするための文法に、統一性がなさすぎだなー。
継承とテンプレートとコンセプトで全然別の書き方をおぼえろって。
0040デフォルトの名無しさん2009/06/26(金) 09:11:26
VCはconceptの実装について見通しとか立ててるのかな
0041デフォルトの名無しさん2009/06/26(金) 11:06:09
http://blogs.msdn.com/vcblog/default.aspx
で検索してもほぼスルーだから、
VC++ 2010には入らないんじゃ。
2012とか2013あたりかね。
0042デフォルトの名無しさん2009/06/26(金) 11:08:06
>>34
交合した時に便利なんだけど、
混合すると既存のコードのルックアップも変る可能性があるのが、
痛し痒しなところだね。
0043デフォルトの名無しさん2009/06/28(日) 15:38:33
C++0xのshared_ptrはスレッドセーフ？
0044デフォルトの名無しさん2009/06/28(日) 15:44:08
まさか
0045デフォルトの名無しさん2009/06/28(日) 18:03:04
C++はどこまで肥大化していくのだろうか。
コンパイラ開発者泣かせだよな。
そのうちGCCとVC++くらいしか追従出来なくなったりして。
0046デフォルトの名無しさん2009/06/28(日) 18:18:48
すでに追従できてないし＾＾
VCなんかダイアモンド継承すらまともにできない。
0047デフォルトの名無しさん2009/06/29(月) 00:22:41
intelががんばるよ
0048デフォルトの名無しさん2009/06/29(月) 01:48:34
PL/Iの二の舞だよな
折角UNIXとCでスリムアップしたのに
0049デフォルトの名無しさん2009/06/29(月) 01:50:29
>>46
kwsk
最近はVCの方がg++より規格準拠度が高いと聞いていたが。
0050デフォルトの名無しさん2009/06/29(月) 02:07:20
VC6の事だろjk
0051デフォルトの名無しさん2009/06/29(月) 07:55:47
vc6は窓から投げ捨てろ
0052デフォルトの名無しさん2009/06/29(月) 08:08:15
concept以外は、もうg++もVCもそれなりに満足行くレベルで対応してるよね。
VCはまだ正式には出てないけど。
詳しくないけど、conceptも実はやってみたらすぐだったりしないのかなぁ。
極論言えば、テンプレート引数に対する超かしこいマクロなだけだよね。
プリプロセッサの後にconceptチェッカを通して、それがOKならコンパイラに渡す、とかで。
0053デフォルトの名無しさん2009/06/29(月) 15:06:59
>>52
さあ、おまえが早速実装するんだ
0054デフォルトの名無しさん2009/06/29(月) 15:25:01
憶測書いている暇あるならg++のgcc/cp/concept.c読めばいいのに
0055デフォルトの名無しさん2009/06/29(月) 18:11:39
>>49
https://connect.microsoft.com:443/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=304536

「バグ」に分類されてるけど、「修正しない」方針、つまりVCの仕様で決着。
VCではダイアモンド継承については仕様に合致しない方針で行くということになっている。
もちろん、最新の2008でもこの仕様。
0056デフォルトの名無しさん2009/06/29(月) 21:11:49
そこでそのうち見直すって言ってるけど2010でも直ってないの？
0057デフォルトの名無しさん2009/06/29(月) 23:35:03
「バグだけど2008には間に合わない」って書いてあるようにみえるけど？
0058デフォルトの名無しさん2009/06/29(月) 23:50:23
VS2008 SP1でも直ってないのなら、あまり修正する気が無いのか、
余程大幅な修正が必要なのかのどちらかだろうな。

ところでComeau使ってる人いる？C++0xへの準拠度はどんなもの？
0059デフォルトの名無しさん2009/06/30(火) 00:07:20
>>55
ATLで多用しているから修正しないのか
ひでえ話だな
0060デフォルトの名無しさん2009/06/30(火) 00:07:28
2008SP1Expressでは直ってなかった
誰か2010βで試してくれ
0061デフォルトの名無しさん2009/06/30(火) 06:24:30
2010beta1
error C2250: 'D' : 'A *V::vf(void)' のあいまいな継承です
0062デフォルトの名無しさん2009/06/30(火) 18:23:20
直ってないのか…
忘れてるのか直す気がないのか
0063デフォルトの名無しさん2009/06/30(火) 18:50:52
だから仕様。
0064デフォルトの名無しさん2009/06/30(火) 18:51:50
MSもバグだって認めてるだろ。直す気が無いだけ。
0065デフォルトの名無しさん2009/06/30(火) 18:53:13
直す気のないバグは仕様と同じじゃないかｗ

2010までは既存のコンパイラを修正しーしー使ってるけど
2010の次のバージョンではコンパイラをフルスクラッチするって言ってたはずなので
2010の次のバージョンで直るんじゃないか？
C++0xへの準拠もその時点で･･･って気がする。
0066デフォルトの名無しさん2009/06/30(火) 20:07:43
exportは201x年のうちに対応したコンパイラ出てくるのかな。
0067デフォルトの名無しさん2009/06/30(火) 20:15:11
exportもういらないだろ
word aroundがBoostですっかり定着しちゃったし
0068デフォルトの名無しさん2009/06/30(火) 20:16:32
あっそうか
templateを使ったソースを分割コンパイルする時に問題が生じるのか
(ビルド時間)
現時点ではCPUの速度でカバーしてもらおうか
0069デフォルトの名無しさん2009/07/01(水) 02:05:22
ja.wikipedia.orgには、
> C++0x標準には、C++でのガベージコレクションの実装を容易にする機能が導入される。
とあるけど、 どんな機能なんでしょうか？さっぱり分かりません…
0070デフォルトの名無しさん2009/07/01(水) 02:51:40
単純にスマートポインタのことじゃないの。
0071デフォルトの名無しさん2009/07/01(水) 03:17:50
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm
質問しておいて何ですが、色々ググってみたら↑が見つかりました。
多分これだと思いますがほんとに実装されるのでしょうか…
0072デフォルトの名無しさん2009/07/01(水) 22:11:00
それは単に規格に入れる文面だ。それ以上じゃない。
ユーザーからしたら、とくにコードに変化はない。何も機能が追加されるわけじゃない。
文字通り、GCを将来入れる際に、最低限のことを決めておこうというだけのことだ。
ポインタに対してXORなどのある種の演算をしたらGCを保証しないよというだけのこと。
0073デフォルトの名無しさん2009/07/02(木) 00:29:14
APIも定義されてる。
0074デフォルトの名無しさん2009/07/02(木) 21:04:51
>58
ここ見る限りではもう少し頑張りましょうってとこかと。
ttp://www.comeaucomputing.com/43101features.html
0075デフォルトの名無しさん2009/07/03(金) 00:14:19
あのexportを見事実装したComeauでさえコンセプトは実装できてないのか
もう無理じゃね？
0076デフォルトの名無しさん2009/07/03(金) 00:25:03
禿はどのコンパイラが一番好きなんだろうか。
日常的に6つ位使ってると書いてあったが。
0077デフォルトの名無しさん2009/07/03(金) 10:50:06
自分の所のコンパイラがあるのはプローガー氏だっけ？
0078デフォルトの名無しさん2009/07/03(金) 11:53:57
Dinkumwareはライブラリしか作ってないと思ってたけど、違うの？
0079デフォルトの名無しさん2009/07/03(金) 12:14:12
これは Bjarne スッポスッポがどれかのコンパイラに concept を実装しないと誰も実装しないかもね
0080デフォルトの名無しさん2009/07/03(金) 12:19:39
コンセプトってそんなに実装むずいの？
0081デフォルトの名無しさん2009/07/03(金) 12:51:56
もう標準化委員会でリファレンス実装を与えた方が良い気がする。
このままではコンパイラベンダもC++コミュニティも共倒れになりそう。
0082デフォルトの名無しさん2009/07/03(金) 13:25:50
たしかに、これだけ高レベルな概念の実装にターゲット依存するものは無いだろうしね。

で、その実装を書くための言語は何にするんだぜ？
0083デフォルトの名無しさん2009/07/03(金) 13:39:18
C++0xがCのC99のような運命を辿らなければいいのだが
0084デフォルトの名無しさん2009/07/03(金) 14:38:10
>>82
実装に使う言語は一つ前の標準を使うということで、C++03で良いのではないかと。
0085デフォルトの名無しさん2009/07/03(金) 15:43:36
boostにコンパイラフレームワークとC++0xコンパイラを追加すればいい。
0086デフォルトの名無しさん2009/07/03(金) 15:54:23
boost::interpreter
0087デフォルトの名無しさん2009/07/03(金) 20:58:00
>>84
世界中のバイナリファイルがウィルスに感染してソースコードしか残らなかったら
どうやってコンパイルするんだ！
0088デフォルトの名無しさん2009/07/03(金) 21:06:06
本当のプログラマはヘキサエディタでコンパイラ書くよ。
0089デフォルトの名無しさん2009/07/03(金) 22:25:25
>>87 大丈夫。その時には OS すら動作してないから
0090デフォルトの名無しさん2009/07/03(金) 22:54:23
　 　 　　　＿＿＿_
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　今日もまた、紙に穴を開ける作業が始まるお
　 |　　　　 （__人__）　　　　|
　 ＼　　 　 ｀ ⌒´ 　 　 ／
0091デフォルトの名無しさん2009/07/04(土) 21:14:47
>>90
なんの話だよｗ
0092デフォルトの名無しさん2009/07/04(土) 21:17:25
キーパンチャーじゃないか？
0093デフォルトの名無しさん2009/07/04(土) 21:54:01
パンチカードでプログラムしてるんだよ。
ちなみに、実行結果もパンチカードで出てくるんだよ。
0094デフォルトの名無しさん2009/07/04(土) 22:03:40
今時パンチカードのシステムを使っている所なんかあるのかよ
0095デフォルトの名無しさん2009/07/04(土) 22:12:35
ノイマン式をリセット出来るなら今度は9bit/byteのコンピュータにしようぜ
0096デフォルトの名無しさん2009/07/04(土) 22:17:35
>>95
何か意味あるのか？
命令数が増やせるとか数の表現範囲が広がるとかその程度かメリットは
0097デフォルトの名無しさん2009/07/04(土) 22:18:10
オクタエディタが必要だな
0098デフォルトの名無しさん2009/07/04(土) 22:45:23
ヲタクエディタかと思った
0099デフォルトの名無しさん2009/07/04(土) 23:13:58
16bit/byteのCPUなら結構使われてるよ
そいつのCはcharが16bitだ
0100デフォルトの名無しさん2009/07/04(土) 23:51:42
>>95
charが9bitの処理系って普通にあったような
確かUTF-9絡みで知った覚えがある
0101デフォルトの名無しさん2009/07/04(土) 23:58:18
UTF-9/UTF-18 はジョークRFCです

でもまあ確かに昔36bitワードのアーキテクチャはあった
0102デフォルトの名無しさん2009/07/05(日) 00:11:37
8bit目は無駄に消費されていることが多い。
地球環境を守るため7bit/byteにすべきだ。
0103デフォルトの名無しさん2009/07/05(日) 00:19:35
地球環境を守るならパソコンを捨てるべきだ。
0104デフォルトの名無しさん2009/07/05(日) 00:20:30
再び日本語が化ける日々が続くのか…
0105デフォルトの名無しさん2009/07/05(日) 00:43:53
short が16bitから18bitになれば扱える記号が二十万増えるんだよ
こんなに経済的なことはないじゃないか
0106デフォルトの名無しさん2009/07/05(日) 00:47:40
UCS-4でおｋ
0107デフォルトの名無しさん2009/07/05(日) 04:21:22
>>83
C99はこっそりと普及しつつあると想像
してるんだけど、実際はどうなんだろ。
0108デフォルトの名無しさん2009/07/05(日) 04:47:08
>>107
考えが甘すぎる
もう10年経ってるんだよ？
0109デフォルトの名無しさん2009/07/05(日) 07:33:36
そんなこというと ANSI C の普及も遅々としていた気がする
0110デフォルトの名無しさん2009/07/05(日) 08:23:10
>>101
今でも ACOS-6 は word 32bit/char 9bit だ
0111デフォルトの名無しさん2009/07/05(日) 08:26:01
>>96
ノイマン型コンピュータを実装するとき、状態素子の取り得る状態の数はネイピア数に近い方が実行の効率がいいと聞いたことがある。
0112デフォルトの名無しさん2009/07/05(日) 10:02:50
>>107
俺的には、C99はGCCの独自拡張。

>>111
「トランジスタのレベルで3値論理回路があるなら」って条件付きで、
3進数の方が情報の効率はいいって話だったと思う。

世の中2値論理が主流だから、その前提成り立たない。
0113デフォルトの名無しさん2009/07/05(日) 10:13:01
主流だから、というのは関係ないと思うんだが。
確か Skip List の論文で引用されてたかな。
0114デフォルトの名無しさん2009/07/05(日) 10:18:13
2進数素子を3進数素子に置き換えた所で
情報量は1.6倍くらいにしかならないんだが
0115デフォルトの名無しさん2009/07/05(日) 10:18:16
>>111
> ノイマン型コンピュータを実装するとき
eを基数にすると、もっとも効率のいい符号化が出来るって、話とちゃう?
でもって、符号化の話はノイマン型コンピュータに限らないわけだが…
0116デフォルトの名無しさん2009/07/05(日) 10:24:19
俺が子供の頃のコンピュータは
１０進数で計算してたんだよ
0117デフォルトの名無しさん2009/07/05(日) 10:25:34
計算屋さんですか
0118デフォルトの名無しさん2009/07/06(月) 08:38:28
10進数って1bitが10値だったってこと？
0119デフォルトの名無しさん2009/07/06(月) 09:01:21
つ BCD
0120デフォルトの名無しさん2009/07/06(月) 09:35:22
俺が子供の頃の粘土板なんて60進数で計算してたぞ
0121デフォルトの名無しさん2009/07/06(月) 09:41:29
これ思い出した：

348 名前：名無しさん＠お腹いっぱい。[] 投稿日：2009/01/09(金) 15:26:15 ID:1j1gqbOE
スライド書架つくりたいんだけど、
文庫本1000冊つめたら200キロだよね？
手で動かないよね？どうしよう。

349 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/09(金) 16:45:14 ID:???
意外と動く

350 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/09(金) 19:31:57 ID:???
>>348
つベアリング

351 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/09(金) 22:34:49 ID:???
200?入りドラム缶だって一人でも運べるし

352 名前：348[sage] 投稿日：2009/01/10(土) 00:33:28 ID:???
人類のテクノロジーがそこまで進んでいるとは思いませんでした。正直びっくりです。
でもよく考えてみれば、水平に動かすならば、摩擦係数さえ何とかすれば大丈夫なんですね。
昔エジプト人が石をコロに乗せてピラミッドの上まで運んでいるのをみたんですが、そんなのを想像していました。
0122デフォルトの名無しさん2009/07/06(月) 09:41:32

353 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/10(土) 00:43:11 ID:???
>>352
昔見たって・・・いつ時代の人間だよ・・・

床の耐荷重も気をつけてネ

354 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/10(土) 23:49:07 ID:???
>>352
>>昔エジプト人が石をコロに乗せてピラミッドの上まで運んでいるのをみたんですが、

わたしを明るくしてくれてありがとう+。:.ﾟヽ(*´∀｀)ﾉﾟ:.｡+ﾟ

355 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/01/11(日) 02:50:45 ID:???
一行目の「人類のテクノロジーが〜」がまた効いてるなｗ
0123デフォルトの名無しさん2009/07/06(月) 18:29:44
>>120
で、あんたの年はいくつなの？ｗ
0124デフォルトの名無しさん2009/07/06(月) 19:02:12
>>118
10進数は decimal digit
0125デフォルトの名無しさん2009/07/06(月) 21:19:36
>>119
これはひどい環境破壊だな。
世界中ののこり6bitに住まわせてくれ。
0126デフォルトの名無しさん2009/07/06(月) 21:26:31
sexadecimal
0127デフォルトの名無しさん2009/07/06(月) 22:13:57
sexという単語に過剰反応する美少女中学生
0128デフォルトの名無しさん2009/07/07(火) 00:29:47
sexagesimal
0129デフォルトの名無しさん2009/07/07(火) 10:12:59
sexagesimal といわれるとこれ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2601.html
を出さんわけにはいかんな
0130デフォルトの名無しさん2009/07/07(火) 18:33:16
くだらんげんごになった。
0131デフォルトの名無しさん2009/07/07(火) 19:04:07
くらげだんごになった。
0132デフォルトの名無しさん2009/07/07(火) 19:23:57
くらげだんごってどんな味がするんだろうと本気で思案する美少女中学生
0133デフォルトの名無しさん2009/07/08(水) 16:00:06
こんな言語では萌えない。
0134デフォルトの名無しさん2009/07/10(金) 01:07:43
デストラクタのにゅる記号萌え〜
0135デフォルトの名無しさん2009/07/10(金) 02:00:58
struct churuyasan{
~churuyasan(){std::cout << "にょろ〜ん" << std::endl;}
};
0136デフォルトの名無しさん2009/07/10(金) 23:24:52
struct churuyasan??<
??-churuyasan()??<std::cout << "にょろ〜ん" << std::endl;??>
??>;

やはりトライグラフには風情がない
0137デフォルトの名無しさん2009/07/10(金) 23:43:34
トライグラフ使う環境なのに、日本語文字列はOKなのかよ！
0138デフォルトの名無しさん2009/07/11(土) 00:28:25
わらたｗ
0139デフォルトの名無しさん2009/07/11(土) 12:52:31
>>137
ローマ字入力だったら、英字キーと
変換キーだけで充分だよ？
日本向けPDAならありえること。
0140デフォルトの名無しさん2009/07/11(土) 12:57:51
例えばどのPDAですか?
0141デフォルトの名無しさん2009/07/11(土) 14:53:38
前々から他人とは少し違う自分を感じていたが、
今朝起きたら左手の甲にトライグラフの紋章が現れてた。
0142デフォルトの名無しさん2009/07/11(土) 15:07:04
. △
△△　tanasinn
0143デフォルトの名無しさん2009/07/11(土) 16:56:16
それはトライフォース
0144デフォルトの名無しさん2009/07/12(日) 02:14:07
>>140
オレが今使ってるやつだと、
中カッコの入力方法がわからん。

普通のキーボードと同程度に文字を
入力できるPDAなんかあるのか？
0145デフォルトの名無しさん2009/07/12(日) 11:15:45
お前の話はいいよ。
0146デフォルトの名無しさん2009/07/12(日) 14:29:47
自分のことをオレと呼ぶ美少女中学生かもしれないじゃないか
0147デフォルトの名無しさん2009/07/12(日) 14:44:48
よろしい、ならば聞こう
0148デフォルトの名無しさん2009/07/13(月) 05:24:25
ahaha
0149デフォルトの名無しさん2009/07/14(火) 08:02:10
Concept廃止と聞いて！
0150デフォルトの名無しさん2009/07/14(火) 08:13:54
おい、マジかよ。
まあ、明日辺りには詳しいことが分かるだろうけど。
0151デフォルトの名無しさん2009/07/14(火) 09:35:37
本当なのか。

ずっと議論続いてたから見送りなっても仕方ないだろうとは思っていたが。
0152デフォルトの名無しさん2009/07/14(火) 10:19:19
ソースｷﾎﾞﾝ
0153デフォルトの名無しさん2009/07/14(火) 11:47:46
concept_mapは革新的だったがあまりにも革新的すぎたのか？
0154デフォルトの名無しさん2009/07/14(火) 12:26:21
革新的かどうかより、今さらの実装は
現実的じゃないってことなのでは。

多重継承とは違って、意地で実装するには
難し過ぎるんだろうなあ。
0155デフォルトの名無しさん2009/07/14(火) 14:55:13
ソースどこだよ！！！
0156デフォルトの名無しさん2009/07/14(火) 15:58:59
これじゃね
ttp://lists.puremagic.com/pipermail/digitalmars-d-announce/2009-July/013799.html
0157デフォルトの名無しさん2009/07/14(火) 16:30:24
D言語のニュースグループかよｗｗ
0158デフォルトの名無しさん2009/07/14(火) 19:38:54
ああ、今フランクフルトで会議中なのか。
post-Frankfurt mailingが出るまで真偽の程はお預けかな。
0159デフォルトの名無しさん2009/07/14(火) 20:04:11
次次期標準までのスパンを短くしてそのとき入れてくれればいいよ
0160デフォルトの名無しさん2009/07/14(火) 21:05:31
無くすなら無くすで大変だろ
今さらドラフトからコンセプト関連の文言消して回るのか？
拡張for文はどうするんだ？
0161デフォルトの名無しさん2009/07/14(火) 21:17:04
おそらくただのダックタイピングになるだけだろう。
組み込み配列だけはアドホックに対応して、後はあきらめることになると思う
0162デフォルトの名無しさん2009/07/14(火) 22:15:45
公約守れなかったら禿に不信任決議で委員会解散総選挙の刑
0163デフォルトの名無しさん2009/07/14(火) 22:25:14
素直にC++{1,2}xに変更しようぜ。
0164デフォルトの名無しさん2009/07/14(火) 22:39:15
コンセプトなんて0xの新機能の中でもかなり早くから議論されてる方だよなぁ
本当に廃止になったら情けないわ
0165デフォルトの名無しさん2009/07/14(火) 23:35:12
>>163
ぶれた
0166デフォルトの名無しさん2009/07/14(火) 23:47:45
　　　　 　　 　 　　 　 　 　 　 　 　　 ┗0=============0┛
　　　 　 　 　 　　 　 ＼===========［_|_|_|_|_|_|_|_|_|_|_|_|_|_］===========／
　　　　　　　　　　　 ／三三三三三三三三三三三三三三三三三三三三＼
　 　 　 　 　 　 　 　 　 0　│ |∞∞∞ |::|∞∞田田∞∞|::|∞∞∞ | ::|　 0
　　　　　　　　　　　　［二］ | ::| 　 　 　 |::|┏━━━━┓|::| 　 　 　 | ::l ［二］
◎○＠※◎○＠※. |□|.│ |┌┬┐ |::|┃ concept ┃|::| ┌┬┐| ::|. |□|　◎○＠※◎○＠※
ii|iiii|iiii|iiii|iiii|iiii|iiii|iiii| ｀)三(´| ::|├┼┤ |::|┃（（（　））） ┃|::| ├┼┤| ::|｀)三(´iｌ|iiii|iiii|iiii|iiii|iiii|iiii|iiii|
＠※◎○＠※◎○　| ::|　| ::|└┴┘ |::|┃（　´∀｀） ┃|::| └┴┘| ::|　| ::|　 ＠※◎○＠※◎○
ii|iiii|iiii|iiii|iiii|iiii|iiii|iiii|ｌi┏━━━━━┓|::|┃（ 　　　 ） ┃|::|┏━━━━━┓ ｌi|iiii|iiii|iiii|iiii|iiii|iiii|iiii|ｌ
◎○＠iiii※◎○＠ ┣┳┳┳┳┳┫|::|┗━━━━┛|::|┣┳┳┳┳┳┫ ◎○＠iiii※◎○＠
ii|iiii|iiii|iiii|iiii|iiii|iiii|iiii|ｌ　○　 　　●　 　 　 　 ∫∬∫∬　 　 　 　 ●　　 　○　ii|iiii|iiii|iiii|iiii|iiii|iiii|iiii|ｌi
　　　 　 　　 　 　 　 ○○　　●●　　　　　 iiiii iii ii iiii 　　　 　 ●●　　○○
　　　　　　　　　　　［￣￣］ ［￣￣］　　　（￣￣￣￣￣）　 　 ［￣￣］ ［￣￣］
　 　 　 　 　 　 　 　 |_○_|　 .|_○_|　　　　 |＿＿＿＿_|　　　　 |_○_|　 .|_○_|

さようならコンセプト
0167デフォルトの名無しさん2009/07/14(火) 23:57:16
ここで Bjarne が超人的コード力を発揮して、concept-cfront を三日で書き上げるに3ペリカ
0168デフォルトの名無しさん2009/07/15(水) 00:00:05
禿、頼むよ・・・
0169デフォルトの名無しさん2009/07/15(水) 00:01:36
喜々として廃止票入れてそうな気もするがな
0170デフォルトの名無しさん2009/07/15(水) 00:01:36
C++にconceptが入らないって事はないと思うよ。
たとえC++0xで見送られたとしても。
0171デフォルトの名無しさん2009/07/15(水) 00:03:17
exportと同じ道を歩むくらいなら無くなってくれて良かったと思おう
0172デフォルトの名無しさん2009/07/15(水) 01:33:55
0xはすぐにでも使いたい即効性のあるもんばっかりなんで、
個人的にはリリースの延期だけはしないで欲しいなぁ。
0173デフォルトの名無しさん2009/07/15(水) 02:35:20
>>171
そうなんだよな。
誰も実装しない機能なんてないのと同じだからな。
0174デフォルトの名無しさん2009/07/15(水) 09:37:51
>>171
exportとは全然違うでしょ。
conceptは重要な機能満載なんで。
0175デフォルトの名無しさん2009/07/15(水) 10:31:44
でも、実装されなきゃ絵に描いた餅
0176デフォルトの名無しさん2009/07/15(水) 11:42:45
またまた。どうせ実装されても数年は（古いソースコードとの互換性を重視して）使わない気でしょ、みんな？＾＾
0177デフォルトの名無しさん2009/07/15(水) 11:49:59
スレ違いだな、そういう人間は。
0178デフォルトの名無しさん2009/07/15(水) 13:04:38
>>174
＞exportとは全然違うでしょ。
実装されてたら、ビルド時間が超速く
なってて、またいろいろ違う状況に
なってたかもしれないけどね。
0179デフォルトの名無しさん2009/07/15(水) 13:17:28
conceptが入ればコンパイルエラーのメッセージが8メガバイトも出力されずに
済むようになるかもしれない（？）
0180デフォルトの名無しさん2009/07/15(水) 17:55:46
>>178
そんなに速くはならんよ。
0181デフォルトの名無しさん2009/07/15(水) 18:00:45
oファイルの汚染が進んで取り返しのつかない事に成ってたかも知れんね
0182デフォルトの名無しさん2009/07/15(水) 19:36:57
この調子で変態ラムダもrejectよろしこ
0183デフォルトの名無しさん2009/07/15(水) 20:01:58
lambdaを入れずしてC++0xの面目はないだろ。
あと、関数の文法統一とnamed lambdaとlocal functionが欲しい所だが。
0184デフォルトの名無しさん2009/07/15(水) 20:33:54
欲張るとコンセプトみたいに消えるからほどほどにしておけ。
0185デフォルトの名無しさん2009/07/15(水) 20:35:03
>>183みたいなのがC++をダメにしたんだな
0186デフォルトの名無しさん2009/07/16(木) 00:13:55
もうautoと右辺値参照さえあればいいよ…
0187デフォルトの名無しさん2009/07/16(木) 02:12:02
>>178
ビルド時間が？
あんたあほちゃうの？
0188デフォルトの名無しさん2009/07/16(木) 02:13:30
>>186
template書きとしてはdecltype必須。
GCのためのメモリモデルもかなりいいよ。
0189デフォルトの名無しさん2009/07/16(木) 20:58:44
conceptの代わりにユーザー定義リテラルが死ねば良かったのに(´･ω･`)
0190デフォルトの名無しさん2009/07/16(木) 21:26:00
右辺値参照とイニシャライザーリストも死ねばいいのに
0191デフォルトの名無しさん2009/07/16(木) 21:31:05
たまにはaxiomのことも思いだしてあげてください。
0192デフォルトの名無しさん2009/07/16(木) 21:35:32
右辺値参照はもう無くせないよ
よほど実装が簡単だったのかほとんどのコンパイラがもう対応してるし
コンセプトと違って
0193デフォルトの名無しさん2009/07/17(金) 01:51:21
>>191
何言ってるの? axiomはconceptの一部だよ。
>>192
右辺値参照をやっつけるのは、コンパイラ屋には簡単で、
ライブラリ屋には難しい。
0194デフォルトの名無しさん2009/07/18(土) 14:09:22
conceptとenable_ifってキャラ被りじゃね？
0195デフォルトの名無しさん2009/07/18(土) 19:19:03
>>8
あれは教会建築としてはフツーの部類なので問題無い
ミラノ大聖堂なんか完成まで400年以上掛かってるし
設計ミスと資金不足で数百年費やした後未完成なんて教会もあるし
0196デフォルトの名無しさん2009/07/18(土) 20:20:29
突っ込まないぞっ
0197デフォルトの名無しさん2009/07/19(日) 15:55:21
conceptはexportと同類だったのか…

>The Concepts proposal was doomed because the committee wasn't standardizing
>existing practice (which is what it usually does) but instead, invented a huge,
>complex and controversial feature ex nihilo. History shows that features that
>were added in this unusual way to C++ have all failed. This was the case with
>exception specifications and exported templates.
ttp://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
0198デフォルトの名無しさん2009/07/19(日) 17:05:03
ろくな実装がないという点では同じだな。
0199デフォルトの名無しさん2009/07/19(日) 17:18:47
Haskell や Scala でできてること（型によるパターンマッチ？）を C++ に取り込むって感じじゃないの？
0200デフォルトの名無しさん2009/07/19(日) 18:09:32
標準で野心的なことをすると、自分で作ってみろよ、と言われ、便利な機能を標準外で独自
実装すると標準を守れ、と怒られる時代だなｗ
0201デフォルトの名無しさん2009/07/19(日) 19:43:15
comp.std.c++によれば、どうやらC++0xは1年近くずれ込むようで。
0202デフォルトの名無しさん2009/07/19(日) 19:52:20
誰も使わない言語に、マジになりそうだな。
0203デフォルトの名無しさん2009/07/19(日) 20:09:02
conceptはexportよりも実装はずっと楽。
exportはlink時にlazy compileだから。
まあ最近のgccだとexportも実装できそうな勢いだけど。
GIMPLE使ったlink-time optimizationのbranchあるから。
0204デフォルトの名無しさん2009/07/19(日) 20:10:59
VC10がリリースされたら、C++0xの規格がまとまらなくてもautoにlambdaや右辺値は便利だから使うけどね。
0205デフォルトの名無しさん2009/07/19(日) 20:15:54
規格の内容が変わったらどうするんだろうなVC10
0206デフォルトの名無しさん2009/07/19(日) 20:24:08
正式版リリース前なら変更すればいいし、リリース後ならSPで変更すればいい
0207デフォルトの名無しさん2009/07/19(日) 20:25:43
VC6の二の舞か
0208デフォルトの名無しさん2009/07/19(日) 21:03:08
今からコンセプト取り除く作業して拡張for文とかも考え直して…
1年で済むのかなぁ
0209デフォルトの名無しさん2009/07/19(日) 21:38:01
なー、なんで学園アイドルのコンセプトさんは学校こーへんのー?
0210デフォルトの名無しさん2009/07/19(日) 21:53:15
お星様になったからだよ…
0211デフォルトの名無しさん2009/07/19(日) 21:55:41
本物のスターになったわけか
0212デフォルトの名無しさん2009/07/19(日) 22:00:34
それでも禿なら、禿なら颯爽と実装を持ってきてくれるに違いないっ・・・
0213デフォルトの名無しさん2009/07/19(日) 22:03:46
我らがすっぽすっぽ校長なら全校集会で平然と残念なお知らせをするのも造作ない
0214デフォルトの名無しさん2009/07/19(日) 22:19:41
泣き崩れるforさん
明日は我が身と青ざめるラムダさん
仕事が増えそうで憂鬱なstatic_assertさん
出番が増えそうでニヤニヤしてるtype_traitsさん
あまり興味なさそうな右辺値参照さん
爆睡してるautoさんdecltypeさん姉妹
0215デフォルトの名無しさん2009/07/19(日) 23:06:05
コンセプトってそんなに難しいの？
0216デフォルトの名無しさん2009/07/19(日) 23:06:53
むずかしくないよ
0217デフォルトの名無しさん2009/07/19(日) 23:23:06
Concepts のコンセプトが破綻していたから外されたのですね...
0218デフォルトの名無しさん2009/07/19(日) 23:25:19
>>215
経験が足りない。
難しくないと言いきれるほど、徹底的に分かってない。
0219デフォルトの名無しさん2009/07/19(日) 23:31:09
>>215
難しいというか、普通に実装すると遅くなりすぎる。
実装や最適化の方法について目下研究中ってところ。だいぶ成果は上がってきてるらしいけど
0220デフォルトの名無しさん2009/07/19(日) 23:55:08
遅くなるって？
コンパイル時の技術なんだからそんな問題じゃないでしょ
テンプレートで既にかなり遅いし
0221デフォルトの名無しさん2009/07/20(月) 00:18:36
実装が難しいんだろ。
0222デフォルトの名無しさん2009/07/20(月) 00:27:23
>>219
> 普通に実装すると遅くなりすぎる。

無知は黙ってろ
0223デフォルトの名無しさん2009/07/20(月) 00:30:34
>>219
死ね
0224デフォルトの名無しさん2009/07/20(月) 00:32:36
Pythonとかみたいに気軽に仕様追加や変更できるといいのにね。
C++ 09.7とかC++ 09.12とか。
0225デフォルトの名無しさん2009/07/20(月) 00:33:00
ケンカすんな
空の上のコンセプトさんが悲しむぞ
0226デフォルトの名無しさん2009/07/20(月) 03:53:11
コンセプトさんも草葉の陰から見守っていて下さい
0227デフォルトの名無しさん2009/07/20(月) 04:59:42
コンセプト、まじかよ・・・
せっかくエラーメッセージが見やすくなると思って期待してたのに。
0228デフォルトの名無しさん2009/07/20(月) 05:58:50
boost::conceptで我慢しな
0229デフォルトの名無しさん2009/07/20(月) 06:09:27
いや、標準ライブラリがコンセプトを使うようにならないとあまり意味が無い
0230デフォルトの名無しさん2009/07/20(月) 07:38:57
もうboostが標準でいいよ
0231デフォルトの名無しさん2009/07/20(月) 07:54:14
Concept-gcc やってたひとを雇って他のプロジェクトにつかっている Apple が主犯だ
0232デフォルトの名無しさん2009/07/20(月) 07:55:04
もうやめて！あれは不幸な事故だったのよ！わたしたちがいがみ合ったってコンセプトさんは帰ってこないわ！
0233デフォルトの名無しさん2009/07/20(月) 07:56:33
>>231
それ本当？clangの実装させてるとか？
だとしたらApple許しがたいな
0234デフォルトの名無しさん2009/07/20(月) 09:38:21
Concept-GCC やってたのはこの人
http://www.osl.iu.edu/~dgregor/
だけど、
http://www.osl.iu.edu/people.php
みると alumni になってるんだよね。
http://www.linkedin.com/pub/doug-gregor/4/556/731
をみると、Apple の C++ グループで何かやってる。
去年の10月から働いてるようで、そのあたりで突然ブログ
http://conceptgcc.wordpress.com/
も止まってます。

clang は去年の段階では C++ が全然だったから、
きっと clang の C++ サポートを頑張ってるんでは。
http://clang.llvm.org/cxx_status.html
0235デフォルトの名無しさん2009/07/20(月) 09:40:55
Objective-Cの競合相手だからな
潰しに来たとしても不思議じゃない
0236デフォルトの名無しさん2009/07/20(月) 10:09:11
う〜ん、WebKit とかは Objective-C と C++ の両方に依存しているので
競合相手というのはちょっと違うのでは...
concept-clang とか出てくれればいいですが。
0237デフォルトの名無しさん2009/07/20(月) 13:33:18
まあObjective C++があるわけだし、さすがにC++を葬り去りたいわけでは
ないだろうけれど。MSに行かれるより遥かにマシだとも言えるし。
0238デフォルトの名無しさん2009/07/20(月) 13:58:45
>>219
0239デフォルトの名無しさん2009/07/20(月) 14:31:39
もうやめてー、>>219のライフは０よ。
0240デフォルトの名無しさん2009/07/20(月) 16:28:12
Conceptは未だコンセプトの域を出ていないって事だろ。
0241デフォルトの名無しさん2009/07/20(月) 16:29:52
アホは黙ってろ
0242デフォルトの名無しさん2009/07/20(月) 17:30:03
なんでConceptは外されることになったの？
0243デフォルトの名無しさん2009/07/20(月) 19:27:12
>The Committee voted to remove concepts from the version of the standard
>now being worked on because we estimated it would take at least 2 more
>years, and possibly 5, to complete the work and publish.
>
>With many other desirable features ready to go, and with the current
>standard already more than 10 years old, that seemed too long a delay.
>
>The choice was difficult, and nobody was happy about having to drop
>concepts, but the alternatives -- 5 years delay or standardizing an
>unusable version of concepts -- were far worse.

だって。
0244デフォルトの名無しさん2009/07/20(月) 19:35:18
別にConcept自体はどーでもいいけどさ
ここまで来てやっぱやーめた→何このgdgd
0245デフォルトの名無しさん2009/07/20(月) 22:50:53
WinFSよりもひどい
0246デフォルトの名無しさん2009/07/20(月) 23:00:49
もうC#でいいよ。
0247デフォルトの名無しさん2009/07/20(月) 23:15:33
コンセプトさんは悪くないんや
メタプログラミングの道具にしようとした周りの大人が悪いんや
0248デフォルトの名無しさん2009/07/20(月) 23:34:35
こんな高い山を目前にして下山する勇気を持つのはすごいことでしょ。
正しい決断だったと思うよ。
0249デフォルトの名無しさん2009/07/21(火) 00:15:53
トムラウシ山の教訓が生かされましたね
0250デフォルトの名無しさん2009/07/21(火) 00:46:44
登る前に気付くのが真の賢者
0251デフォルトの名無しさん2009/07/21(火) 00:55:32
と言いながら何処にも登らないニート
0252デフォルトの名無しさん2009/07/21(火) 01:27:40
>>243
この理由が通るなら、次回もその次も「誰も喜ばない難しい選択」で外されそうだ。
俺が現役のうちには手にできないかも知れない気がしてくる。
0253デフォルトの名無しさん2009/07/21(火) 03:37:50
禿の書いた"Simplifying the use of Concepts"がトドメを刺したっぽいな。

http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/07/20/the-view-or-trip-report-from-the-july-2009-c-standard-meeting
0254デフォルトの名無しさん2009/07/21(火) 07:20:49
>>251
実装なしで規格の上だけで大半の議論をやってるC++0xの事ですねわかります
0255デフォルトの名無しさん2009/07/21(火) 11:03:07
実装あるよ。未完成なだけで。
0256デフォルトの名無しさん2009/07/21(火) 12:19:54
>>255
Concept-gcc のこと？あれは開発が止まってるわけだが。
clang はエラー報告機能が強化されているらしいが、
いずれconcept 無しで concept 有りのとき並みの
エラーメッセージがでるようになるかな？それは無理かな？
まあまずは C++ をコンパイル出来るようになってもらわないといけないが...
0257デフォルトの名無しさん2009/07/21(火) 12:25:03
>>243
つまり、5年先の将来のバージョンには
含めたいってことなのかな。
0258デフォルトの名無しさん2009/07/21(火) 12:28:06
>>256
おちつけ
0259デフォルトの名無しさん2009/07/21(火) 13:34:50
>>257
Committeeに近い人の話は大体そういう感じだね。
0260デフォルトの名無しさん2009/07/21(火) 20:48:17
>>257そのペースなら、boost::conceptを安心して使えるってことかな？
boost::conceptは既存のSTLと一緒に使えるし。
0261デフォルトの名無しさん2009/07/21(火) 20:55:42
>>243を拙い英語力で訳してみた。

>委員会は、コンセプトを現在作業中バージョンの標準から取り除く事を表明した。
>（コンセプトの）完成と公開には最低２年、可能なら５年は必要だと見積もられたからである。
>
>他の沢山の魅力的な機能は既に固まった。また現在の標準は（策定されてから）１０年以上経った。
>これは長すぎる遅れであろう。
>
>これは辛い決断だった。コンセプトの撤回など誰も喜ばない。しかしこれは一対一の選択である
>−−５年の（コンセプトの）遅れか、誰も使わないコンセプトかの−−それははるかに悪い（？）。
0262デフォルトの名無しさん2009/07/21(火) 21:36:58
最後の段落だけ。

困難な選択だったし、誰も Concepts を削りたくはなかったが、代替案(5 年の遅れか、使いものにならない Concepts の標準化)より遥かにマシだった。
0263デフォルトの名無しさん2009/07/21(火) 21:52:54
簡単な部分だけというわけにはいかないのかな
定義本体のないコンセプトだけとか
0264デフォルトの名無しさん2009/07/21(火) 21:59:56
>>262
unusableは「使えない」「使いにくい」でいいんじゃないかな。
STLがconcept化されてないことを言っているんだと思う。だから、
>>263
それが、
> standardizing an unusable version of concepts
で、
> were far worse.
だと。
0265デフォルトの名無しさん2009/07/22(水) 01:02:37
Conceptsのプロポーザルを書いた一人であるJeremy Siekのコメント

http://lambda-the-ultimate.org/node/3518#comment-50071

これとは直接関係ないが、標準ライブラリでconceptを使うのをやめた時点で
終わってたのかもな
0266デフォルトの名無しさん2009/07/22(水) 01:19:08
concept-based overloading なんかを念頭に置くと
どうしても explicit concept のほうに好みが偏ってしまうかもね

みんな implicit か explicit どっちのほうが好みなんだろうか
0267デフォルトの名無しさん2009/07/22(水) 06:27:08
両方ないと使いづらい。
0268デフォルトの名無しさん2009/07/23(木) 00:03:38
禿自らの記事きたわ
ttp://www.ddj.com/cpp/218600111
0269デフォルトの名無しさん2009/07/23(木) 01:15:43
現状のテンプレートが実装されるまでにもかなりかかったし、そんなペースでいいんだけど。
遅れた分だけ仕様が洗練されるならいいけど、実装が遅れるだけなら前と一緒だし入れて欲しかった。
0270デフォルトの名無しさん2009/07/23(木) 21:13:41
次に消される機能は何かなーﾜｸﾜｸ
0271デフォルトの名無しさん2009/07/23(木) 22:17:01
exceptionを消せよ

邪魔過ぎ
0272デフォルトの名無しさん2009/07/23(木) 22:27:05
まあ例外クラスは新しく作り直してもいいと思う、今のを全部非推奨にして。
0273デフォルトの名無しさん2009/07/23(木) 23:02:02
バベルの塔は崩れゆく
0274デフォルトの名無しさん2009/07/23(木) 23:24:13
Perl6の末路と良く似てるな
0275デフォルトの名無しさん2009/07/23(木) 23:25:54
C++1xのxがいくつになることやら
0276デフォルトの名無しさん2009/07/24(金) 01:34:39
五年後を考えているようだが。
> Bjarne Stroustrup
> Maybe a significantly improved version of "concepts" will be available in five years.
0277デフォルトの名無しさん2009/07/24(金) 01:41:08
もうC#でいいよ。
0278デフォルトの名無しさん2009/07/24(金) 01:52:56
敢えてのDで
02792192009/07/24(金) 02:17:06
何処から叩き出されて流れ着いたのかツマラン奴がスレに居付いてるな
0280デフォルトの名無しさん2009/07/24(金) 02:28:20
9割つまらん奴だろう2chなんて。
0281デフォルトの名無しさん2009/07/24(金) 13:39:16
全人類の9割はつまらん奴だから気にするこたあない
02827602009/07/24(金) 15:05:13
>>277
constとtypedefの無いC#は地獄
0283デフォルトの名無しさん2009/07/24(金) 18:07:03
constを真面目に使ってる奴はほとんどいないし
typedefも型を不完全に隠蔽するだけの邪悪な機能としてよくやり玉に挙がる

なんだこいつらもコンセプトと一緒だな
0284デフォルトの名無しさん2009/07/24(金) 18:15:24
typedefなかったらSTLどうすんだよ。
0285デフォルトの名無しさん2009/07/24(金) 18:37:34
typedefの糞なところは
typedef char hoge;
してhogeの型エラーがでても
エラーメッセージにはcharしか表示されないってとこだっけ
0286デフォルトの名無しさん2009/07/24(金) 19:31:59
いりまくるよぉ、const
constないとconst付けないメソッドとかconst付けない引数とかどう書けばいいんだよ
0287デフォルトの名無しさん2009/07/24(金) 19:33:45
const/immutateも弱いtypedef/強いtypedefもあるDでよくね?
0288デフォルトの名無しさん2009/07/24(金) 19:55:47
DはGC外してから出直してこい
0289デフォルトの名無しさん2009/07/24(金) 20:20:45
>>285
VC++2005つかってるけど、警告最大にして
char c = hoge
とかやったら警告で両方の型が表示された気が。
これって別に規格で定められてるわけじゃないのか。
0290デフォルトの名無しさん2009/07/24(金) 20:29:10
もしDから完全にGCを取り去って使うことができたらC++から移住してしまう人いるのか？
ずっと安定し（て）ないからいないだろ
0291デフォルトの名無しさん2009/07/24(金) 20:37:20
もしGCがなくて安定したDがあれば是非移住したいね

どっちの条件も叶いそうにないが
0292デフォルトの名無しさん2009/07/24(金) 20:56:47
>>282
usingがある程度まではC++のtypedefみたいに使えるぞ。
using HWND = System.IntPtr;のように書ける。
0293デフォルトの名無しさん2009/07/24(金) 21:53:45
>290
俺的にはDよりもLinqのないネイティブなC#の方がいいな
GCは別にフレームワークで実現するからいらない。動作が確定的なCと互換性のある
言語が欲しい
0294デフォルトの名無しさん2009/07/24(金) 22:03:01
Linqはいるだろ。
いや、クエリ式は無くてもいいが、Enumerableクラスは必須。
これがないC#なんて、<algorithm>なしのC++と一緒。
ないと使う気になれない。
0295デフォルトの名無しさん2009/07/24(金) 22:09:15
>294
ああ、そっちは確かに。ただ、クエリ構文はいらん
Dはそんな言語を目指していると思っていたんだがなぁ
0296デフォルトの名無しさん2009/07/25(土) 01:26:33
俺は純粋C++派だけど、query構文は面白いと思う。
0297デフォルトの名無しさん2009/07/25(土) 02:57:10
つまりExpression Templateを駆使したboost/linqとかあればいいわけですねわかりますわかりたくもありません
0298デフォルトの名無しさん2009/07/25(土) 04:02:18
CLinqのことですね。わかります
0299デフォルトの名無しさん2009/07/25(土) 06:26:10
>>298
わざわざ構文にする必要性ってあるのか？
使いやすいSQL操作ライブラリは結構あるけど
そういうのじゃ足りない？
0300デフォルトの名無しさん2009/07/25(土) 09:02:45
Linqは各種のデータに統一構文でアクセスできるのが強みであって、
必ずしもクエリ式を言語に埋め込む必要はないと思うな。
0301デフォルトの名無しさん2009/07/25(土) 10:12:33
>>299
リアルSQLだけしか扱わないならLinqは必要ない。
言語に近いレベルでの統一的枠組みであることが重要。
関数型言語の内包記法のように。
0302デフォルトの名無しさん2009/07/25(土) 10:34:10
一方D言語は、

auto result = linq!q{
from n in numbers
where n % 2 == 0
select n
};
0303デフォルトの名無しさん2009/07/25(土) 10:48:48
linqとか本来の言語仕様と異なる表記方法を含めるのってどうなのかなあ？
0304デフォルトの名無しさん2009/07/25(土) 11:15:09
テンプレートとプリプロセッサの黒魔術で無理矢理DSLを作ってどうにかする方がマシってか？
0305デフォルトの名無しさん2009/07/25(土) 16:26:01
>>304
たとえばテンプレトメタ黒魔術で生まれたboost::spiritも一応C++の文法の範疇だから、既存コードとの整合性も楽だと思う。
0306デフォルトの名無しさん2009/07/25(土) 16:43:24
自分を相当ラディカルだと思ってる俺でもspiritが黒魔術の許容限界ラインだな
0307デフォルトの名無しさん2009/07/25(土) 17:42:23
spirit v1の方は割と素直なTMPの実例に思えてきた
v2は無理
0308デフォルトの名無しさん2009/07/25(土) 17:50:11
俺はsprintfでいいよ。
0309デフォルトの名無しさん2009/07/25(土) 17:51:23
つまりboost::lambdaがあればラムダ構文なんて不要ということですね。わかりますよ。わかりますよ。
0310デフォルトの名無しさん2009/07/25(土) 19:09:41
ラムダさんが教室の隅で怯えています
0311デフォルトの名無しさん2009/07/25(土) 22:36:55
これをboostにだな
ttp://www.codeproject.com/KB/mcpp/clinq.aspx
0312デフォルトの名無しさん2009/07/26(日) 00:28:31
_1とかキモすぎて使う気がおきない
0313デフォルトの名無しさん2009/07/26(日) 00:50:57
ムリムリのテンプレートが必死すぎてキモイから

次の改定では構文を拡張できるようにした方がいいな
0314デフォルトの名無しさん2009/07/26(日) 00:59:57
そろそろCとの互換性をあきらめた
cppppが欲しい
0315デフォルトの名無しさん2009/07/26(日) 01:07:23
>>314
D……いやなんでもない
0316デフォルトの名無しさん2009/07/26(日) 01:16:46
C#だろ、それ
0317デフォルトの名無しさん2009/07/26(日) 01:44:44
DもC#もcppppとは言いがたいな
0318デフォルトの名無しさん2009/07/26(日) 02:40:47
cppppである条件ってなによ
0319デフォルトの名無しさん2009/07/26(日) 03:48:17
プリプロセッサなんだからC++自体と独立なんじゃね。
0320デフォルトの名無しさん2009/07/26(日) 10:29:40
>>318
プログラマがその気になれば、
Cで書かれたコード断片と同じ実行効率にできること。
0321デフォルトの名無しさん2009/07/26(日) 14:21:05
>>320
その気にならなくても、速い言語もあるぞ。
0322デフォルトの名無しさん2009/07/26(日) 17:40:46
>>321例えば？
0323デフォルトの名無しさん2009/07/26(日) 18:59:50
C++
0324デフォルトの名無しさん2009/07/26(日) 19:13:54
あとアセンブリくらいしかなくね？ｗ
0325デフォルトの名無しさん2009/07/26(日) 20:09:21
forth
0326デフォルトの名無しさん2009/07/26(日) 22:10:49
C++と同程度の抽象度を持っていなければ比較する意味ないだろ
0327デフォルトの名無しさん2009/07/26(日) 22:25:53
>>320
lisp
0328デフォルトの名無しさん2009/07/26(日) 22:41:57
forth
0329デフォルトの名無しさん2009/07/27(月) 08:01:26
>>320
まさにDだろｗ
0330デフォルトの名無しさん2009/07/27(月) 09:51:09
COBOLもフォートランもCと同等に速いよ。
COBOLやフォートランでは、OS書けないけど。
0331デフォルトの名無しさん2009/07/27(月) 18:08:04
>>329
ガーベージコレクションがあるので不完全。
0332デフォルトの名無しさん2009/07/27(月) 18:09:25
cのコード走らすだけならGCいらんし．
0333デフォルトの名無しさん2009/07/27(月) 18:19:40
GCありで書かれたコードとGCなしで書かれたコードを
混ぜて走らせるほど恐ろしいことはないと思うんだ
0334デフォルトの名無しさん2009/07/27(月) 20:20:49
> COBOL
が、早いのか?

> フォートラン
載ってるマシンと処理系にもよるけど、
数値計算は C じゃ太刀打ち出来ねぇよ

>>333
メモリマネージメントをまじめに考えてない言語の話だろ?
lisp 系の言語はその辺ちゃんとやってるぞ
# 中には、出来の良くない奴もあるらしいけど…
0335デフォルトの名無しさん2009/07/27(月) 20:44:39
標準を作ってる人たちがやりたいことと、一般のニーズが違うんだよなぁ

>334
managed c++という怖ろしい言語があってだな
0336デフォルトの名無しさん2009/07/27(月) 21:08:12
>>335
managed c++のFormにC++のクラスのメンバ変数を作ろうとしたら、コンパイラにできませんって言われた。
５分で挫折した。
0337デフォルトの名無しさん2009/07/27(月) 21:32:09
どうしてもC++の資産を使わないといけない、というときでないと触れてはいけない言語だった……（遠い目
0338デフォルトの名無しさん2009/07/27(月) 23:31:38
Objective-CとC++を混ぜた学ぶ気がカケラも起きない奴もあってな
0339デフォルトの名無しさん2009/07/27(月) 23:40:18
C/C++のいらない部分をそぎ落として、
いい部分だけを抽出した言語がほしい
0340デフォルトの名無しさん2009/07/27(月) 23:51:24
C#のことですね
0341デフォルトの名無しさん2009/07/27(月) 23:58:17
>>339
なに、C++から++をそぎ落とせだと?
0342デフォルトの名無しさん2009/07/28(火) 00:08:40
仮想関数呼ぶコンストラクタや例外投げるデストラクタにブチ切れてくれるコンパイラが欲しいです
0343デフォルトの名無しさん2009/07/28(火) 00:37:52
DLLやライブラリにメタデータをつけて欲しいわ。メタデータの仕様こそ標準化して欲しい
0344デフォルトの名無しさん2009/07/28(火) 00:39:34
DublinCore
0345デフォルトの名無しさん2009/07/28(火) 00:49:00
GCCかどこかでこのDublinCoreを埋め込む動きとかあるんかいな
0346デフォルトの名無しさん2009/07/28(火) 05:46:49
DublinCoreってHTMLとかのドキュメント向けじゃないの？
LanguageにCとか指定するのか
0347デフォルトの名無しさん2009/07/28(火) 08:31:16
>>338
Objective-C++っていうけど、あれはObjective-CとC++をそのまま混ぜて書けるようにしただけ。
managed C++とかC++/CLIみたいに文法はいじられてないよ。
0348デフォルトの名無しさん2009/07/28(火) 09:18:56
Objective-C++いいかも
クラステンプレートにオブジェクト埋め込んだりできるのか？物凄くグニャグニャですね
0349デフォルトの名無しさん2009/07/28(火) 10:35:35
languageはneutralだろ
0350デフォルトの名無しさん2009/07/30(木) 14:06:32
>>348
やってみたけどゲテモノだったよ。
最近はインスタンスのリファレンスカウントを自前で管理する他に、
gcも混在して使えるようになった
これにc++のnew/deleteが混ざるとまさにカオス

c++のインスタンスはnew/deleteで管理して、objcのインスタンスは
基本gcで処理するが、メモリ効率のために一部ではリファレンス
カウントを自前で調節する

やってられん
0351デフォルトの名無しさん2009/07/30(木) 14:26:59
boehm GCとboostを併用するだけでもカオスになります
0352デフォルトの名無しさん2009/07/30(木) 19:28:06
やっぱりC++/CLIみたいに新しい言語として設計するしかないんだな
0353デフォルトの名無しさん2009/07/30(木) 21:10:55
>>352新しい言語として設計するのは一向に構わないが、

msdnのサイトみたいにC++/CLIのサンプルをC++として掲載するのは止めてほしいよな。
0354デフォルトの名無しさん2009/07/30(木) 21:32:48
そういえば、ISOの取り下げ理由って、数年市場にもまれて出直してこい、だったっけ
規格作る前に数種類の実装がないと問題点がわからないから、Perl6みたいに
いつまでも仕様が決まらなくなるわけだな
0355デフォルトの名無しさん2009/07/30(木) 22:50:06
>>354 ぐぐったけど、C++/CLIはC++じゃないとかにお墨付きなのに笑った。
C++/CLIって C++ + C# だから、
C++ + C# = C+++++++ = C##--で良くないかな？
0356デフォルトの名無しさん2009/07/30(木) 22:55:14
C++/CLIはあくまでC++にCLIを融合させたものであって、C#とは違うだろう。
0357デフォルトの名無しさん2009/07/30(木) 22:59:52
C++/CLI は該当スレで話してやれよ。住人はいてもネタがないから入れ食いだぞｗ
C++0x が纏まった後、Concept とかの仕様漏れした項目はそのまま継続協議するのか
それともいったん仕切り直して新たな標準にするのか、どっちかな
0358デフォルトの名無しさん2009/07/30(木) 23:31:16
しばらく言語仕様には手を入れず、ライブラリの
拡充に集中してほしいな。
char16_tやchar32_tも今のままじゃ使い物にならん。
0359デフォルトの名無しさん2009/07/31(金) 02:05:10
>>358
char16_t や char32_t にはそれなりの利用価値はあると思うんだけど、
使い物にならんというほどひどい欠陥があるの？
0360デフォルトの名無しさん2009/07/31(金) 02:59:57
欠陥てほどじゃないけど、C++0xじゃbasic_stringぐらいしか対応していなくて、
stream系やregexで使おうとしたら、charかwchar_tに変換するしかない。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html
0361デフォルトの名無しさん2009/07/31(金) 03:17:35
>>360
いやいやいや。 char_traitsとcodecvtをちゃんと定義してるんだから、
stream系やregex系だってちゃんと動くってこれ。
ただ単に短い名前のtypedefがされていないってだけで。
0362デフォルトの名無しさん2009/07/31(金) 03:36:24
charやwchar_tとの相互変換は用意されているんだよね？
0363デフォルトの名無しさん2009/07/31(金) 08:40:42
>>362
charとwchar_tの相互変換と同じように、codecvtで変換できるんじゃね
0364デフォルトの名無しさん2009/07/31(金) 13:17:29
>>357　新しい構文をむやみに増やさずにboost::conceptsをベースにライブラリとして規格を決めてほしいな。
conceptがウキペからも削除されてて詳細わかんないんだけど、boost::conceptsで足りないのかな？
0365デフォルトの名無しさん2009/07/31(金) 13:26:33
>>354
> 数年市場にもまれて出直してこい

「市場」とかバカじゃねーの?
0366デフォルトの名無しさん2009/07/31(金) 13:26:44
Boost::Conceptはテンプレートマジックだからエラーメッセージも大してわかりやすくならない。
それにテンプレートの展開はコンパイラ組み込みにするのと比べて速度的にかなり不利。
0367デフォルトの名無しさん2009/07/31(金) 13:31:48
>>364
Conceptは必要ないと判断されたのではなくて、
ほとんどのメンバーが必要なものと考えていたけど、
まだ時期尚早だと判断されたのだよ。
0368デフォルトの名無しさん2009/07/31(金) 18:49:55
C++98策定の直後から10年以上検討を続けてきた物が「時期尚早」ねぇ……
0369デフォルトの名無しさん2009/07/31(金) 18:53:09
>>367
>>368
http://www.ddj.com/cpp/218600111 を読んでから物言え
0370デフォルトの名無しさん2009/07/31(金) 19:58:52
BoostのConceptチェック使ったことあるやつなら分かると思うが、
きちんと対象に必要なコンセプトを定義してライブラリ組み立てていくのは
かなり骨が折れる。

後からちょっと型を追加したくなったりみたいなのがやりにくいし、
かといって最初からイテレータみたいなちゃんとしたモデルを
凡人がほいほいとデザインはできないし。

ドラフトのコンセプト定義が大幅に書き換えられたりしているのを見るにつけ、
偉い先生方も苦労してんだなーと。

もっとも、ばりばりのハスケラー達にとっちゃ失笑モノかもしれんけど。
0371デフォルトの名無しさん2009/08/01(土) 06:42:49
>>368
Conceptは2003年からだよ。
原論文一つも読んだことないだろ。
0372デフォルトの名無しさん2009/08/01(土) 06:51:36
だいぶ昔からお世話になってる SGI STL のドキュメントが Concept を使ったものになってる。
http://www.sgi.com/tech/stl/stl_introduction.html

SGI STL における Concept は C++98 以前からあったんじゃないかな？
0373デフォルトの名無しさん2009/08/01(土) 08:15:23
>>372
それをC++0xにおけるConceptsと同一視するのは間違い。
そのウェブページに

> Concepts are not a part of the C++ language; there is no way to declare a
> concept in a program, or to declare that a particular type is a model of a
> concept. Nevertheless, concepts are an extremely important part of the STL.

とあるように、SGI STLにおけるConceptsとは単なる仕様であって、プログラム内で
Conceptsを使ったりできるわけではない。
0374デフォルトの名無しさん2009/08/01(土) 09:54:54
最近スレを除いてない内にそんな事になってたのか・・
確かにconceptをちゃんと書くのはしんどかったけど
0375デフォルトの名無しさん2009/08/01(土) 12:00:01
規格倒れで決定しそうだな。
0376デフォルトの名無しさん2009/08/01(土) 12:03:20
GCCに実装されてしまえば規格もなにもほぼ関係ないからどーでもいいよ
0377デフォルトの名無しさん2009/08/01(土) 12:11:44
GCCは実装しないと思う
0378デフォルトの名無しさん2009/08/01(土) 12:29:47
コンパイラだけ対応してもライブラリが対応しないと誰も使わないだろうに。
0379デフォルトの名無しさん2009/08/01(土) 13:46:12
結局わけのわからないコンパイルエラーメッセージと格闘し続けなければならんのか
0380デフォルトの名無しさん2009/08/01(土) 14:11:22
ライブラリの対応なんか別にどーでも良くて
継承や関数オブジェクトがこ綺麗に書けるモノと期待してたのに
0381デフォルトの名無しさん2009/08/01(土) 14:46:03
>>380
標準ライブラリが対応すればエラーメッセージがかなり読みやすくなるんだから
どうでもいいということは断じてない。
0382デフォルトの名無しさん2009/08/01(土) 16:22:27
>>372
そのconceptは一般名詞の「コンセプト。」
C++0xから外された言語機能のconceptは、
そのような概念を直接サポートするために考えられたもの。
0383デフォルトの名無しさん2009/08/01(土) 16:24:12
つーか「Concepts and Modeling」ってなってるのに気づけないってどんだけだよ
03843722009/08/02(日) 01:27:43
>371 を読んで、 Concept という考え方自体が 2003 に現れたものであるかの
ように読めんたんで、そうでもないよ、と思って書いたんだ。
最初から言語機能としての Concept の話だったんなら、ごめんよ。
0385デフォルトの名無しさん2009/08/03(月) 22:14:38
const std::string hoge()の様なconst で返す関数がいっぱいあるんですけど
C++0xで右辺値参照を適用させるにはstd::string hoge()に直す必要ありますか？
0386デフォルトの名無しさん2009/08/03(月) 23:05:21
え
0387デフォルトの名無しさん2009/08/03(月) 23:09:46
前にドラフトとか読んでその必要はあると思ったし、
実際VC++10βだと下のプログラムはlvalueと出力される。
#include <iostream>
#include <string>
const std::string f() {
return std::string();
}
void g(const std::string&) {
std::cout << "lvalue" << std::endl;
}
void g(std::string&&) {
std::cout << "rvalue" << std::endl;
}
int main() {
g(f());
}
0388デフォルトの名無しさん2009/08/03(月) 23:29:43
そりゃ、const stringはstringに暗黙変換されないだろ。されたら怖いわ。
0389デフォルトの名無しさん2009/08/04(火) 01:53:50
>>387
> 前にドラフトとか読んで
> 実際VC++10βだと

お前アホだろ。
読めてない癖に「読んで」かよ。
0390デフォルトの名無しさん2009/08/04(火) 12:47:50
#include <iostream>
#include <string>
const std::string f() { return std::string(); }
void g(const std::string&) {
std::cout << "const lvalue" << std::endl;
}
void g(std::string&) {
std::cout << "lvalue" << std::endl;
}
void g(std::string&&) {
std::cout << "rvalue" << std::endl;
}
void g(const std::string&&) {
std::cout << "const rvalue" << std::endl;
}
int main() {
g(f());
}
ふっつーにVC10でも左辺値で取れますが？
03913902009/08/04(火) 12:54:35
あ×左辺値○右辺値の間違いだった。
このタイミングで間違えるとか駄目すぎるな俺
0392デフォルトの名無しさん2009/08/04(火) 15:22:15
全然関係ないけど

string foo() {
　string temp;
　return temp;
}

のような内部変数を値渡しで戻す場合って
コンパイラの最適化でコピーをはしょっていいことになってたよね？
0393デフォルトの名無しさん2009/08/04(火) 15:30:56
NRVOのことかな
0394デフォルトの名無しさん2009/08/04(火) 15:33:49
>>392
初心者質問スレへGO!
0395デフォルトの名無しさん2009/08/04(火) 16:21:48
ぬるぼっ！
0396AAなしのやっつけ感がいいね2009/08/04(火) 16:37:46
がっ！
0397デフォルトの名無しさん2009/08/04(火) 19:11:48
>>394
内容的には初心者でもないでしょ。
0398デフォルトの名無しさん2009/08/04(火) 21:05:04
C++0x特有でもなし。
0399デフォルトの名無しさん2009/08/04(火) 21:47:17
ここから右辺値参照の話しに広げるつもりとか
0400デフォルトの名無しさん2009/08/05(水) 00:04:40
>>390
const右辺値参照って使い道ある？
0401デフォルトの名無しさん2009/08/05(水) 00:54:58
ttp://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
(超訳？ttp://slashdot.jp/~oku/journal/482528)
によると、
>Concepts are dead for good.
(>コンセプトは死んだ。永遠に。)
だそうなんだが、マジか？

つか、informITって記事の信頼性はどれくらい？@ITくらい？
0402デフォルトの名無しさん2009/08/05(水) 00:57:15
ttp://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
(超訳？ttp://slashdot.jp/~oku/journal/482528)
によると、
>Concepts are dead for good.
(>コンセプトは死んだ。永遠に。)
だそうなんだが、マジか？

つか、informITって記事の信頼性はどれくらい？@ITくらい？
0403401-4022009/08/05(水) 00:59:05
連投すまん。なんかまちがってもーた。
0404デフォルトの名無しさん2009/08/05(水) 01:10:14
>>400
const左辺値参照を受け取れる
0405デフォルトの名無しさん2009/08/05(水) 01:15:31
>>401
だからそれは記事書いた人間の予想だろ？
GCを例に挙げて持論を補強しているが、禿も含めてどうなるかは誰も分からんよ。
C++0xも無理になったわけだし、仮にC++10が策定されたとして、次の標準はいつ
になるのか、と考えると悲観的になるのも分かるが。
0406デフォルトの名無しさん2009/08/05(水) 14:27:31
さよならC++
0407デフォルトの名無しさん2009/08/05(水) 14:38:20
C++ Must Go
0408デフォルトの名無しさん2009/08/05(水) 18:11:57
一旦標準に入りかけてひっくり返されたなんて曰く付きの機能を
好んで実装したり使ったりしようとする人がどれくらいいるかな
0409デフォルトの名無しさん2009/08/05(水) 18:14:02
知ったかも大概にしろよ
0410デフォルトの名無しさん2009/08/05(水) 18:20:11
ConceptはHaskellのType ClassでConcept MapはType Instanceだから
Haskell好きの人なら使いたいと思うかもしれない
ちなみにテンプレートは型族っていうHaskellでもまだまともに使えないフィーチャーに相当する
C++恐しい子！！
0411デフォルトの名無しさん2009/08/06(木) 00:06:55
http://www.open-std.org/jtc1/sc22/wg21/
News 2009-08-05: The 2009-08 post-Frankfurt mailing is available
News 2009-08-05: The C++ Standard Core Language Issues List (Revision 65) is available
News 2009-08-05: The C++ Standard Library Issues List (Revision 66) is available
0412デフォルトの名無しさん2009/08/06(木) 03:20:18
＞N2930 09-0120 Range-Based For Loop Wording (Without Concepts)
＞N2943 09-0133 Allocators without Concepts (preview)

コンセプトさんは本当に死んでしまったんですね……
0413デフォルトの名無しさん2009/08/06(木) 09:34:23
一度も学校に来なかったコンセプトさんの机に"without concepts"と書かれた花瓶だけがひっそりと残った
0414デフォルトの名無しさん2009/08/06(木) 09:43:29
Conceptは死なん何度でも甦るさ
0415デフォルトの名無しさん2009/08/06(木) 12:33:07
C++1xになるって、マジ？
0416デフォルトの名無しさん2009/08/06(木) 14:11:58
そのxは16進だと思ってたが
0417デフォルトの名無しさん2009/08/06(木) 14:15:53
>>415
マジ
0418デフォルトの名無しさん2009/08/06(木) 23:27:08
もうC#でいいよ。
0419デフォルトの名無しさん2009/08/07(金) 06:53:38
16進数でもC++1xになりそうな勢いですけどね
0420デフォルトの名無しさん2009/08/07(金) 07:20:12
それを言うならC++0x1だろうが
0421デフォルトの名無しさん2009/08/07(金) 07:25:47
何度も同じことばかり言ってアホか
0422デフォルトの名無しさん2009/08/07(金) 08:53:14
新喜劇みたいなもんだ
0423デフォルトの名無しさん2009/08/07(金) 09:02:44
>>420
1かよw
0424デフォルトの名無しさん2009/08/07(金) 09:26:25
C++0x1y
0425デフォルトの名無しさん2009/08/07(金) 09:32:19
他でやれカス
0426デフォルトの名無しさん2009/08/07(金) 10:00:35
What Happened in Frankfurt?
ttp://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/

Conceptの歴史的経緯と、今回の削除に至った理由について、
あのDouglas Gregorさんが書いている。
読んでおくべきだと思う。

拙約
ttp://cpplover.blogspot.com/2009/08/douglas-gregor.html
0427デフォルトの名無しさん2009/08/07(金) 10:12:49
Conceptが載ったとしても使う予定なんて特に無いんだろ？おまえら
本当に必要なら、boost入れてでも今すぐ使ってるハズ。
0428デフォルトの名無しさん2009/08/07(金) 10:18:46
>>427
愚かなことを口走る前にログ読んでこい
0429デフォルトの名無しさん2009/08/07(金) 11:06:40
>>426
サンクス。非常に興味深い記事だった。
やはりIndianaとTexasの意見の対立が最後まで解消されなかったということか。
0430デフォルトの名無しさん2009/08/07(金) 11:11:32
>>426 乙

もうあれだ。
enable_ifを組み込みにしてエラーメッセージを分かりやすくすればいいんじゃね。
static_assertも組み込みになったんだし。
0431デフォルトの名無しさん2009/08/07(金) 16:05:53
>>430
enable_ifやstatic_assertが組み込みになったてことは、boost/concept_check.hppなどmpl
が少しは高速化されるのかな？
0432デフォルトの名無しさん2009/08/07(金) 18:27:34
落ち着け
enable_ifは組み込まれてない
0433デフォルトの名無しさん2009/08/07(金) 18:37:36
>>429
意見の対立とは読めないなあ。
方向が二つあってうまく中庸に整理できなかっただけで。
この後うまい決着点を見つけるんじゃないでしょうか。
04344292009/08/07(金) 18:59:22
>>433
自分は以下を意見の対立と読んだわけ。標準化委員会で妥協案を出すように
要求されて何度も議論を重ねたが、結局conceptsの根幹部分におけるの問題が
最後まで解決出来なかったということ。これは入れる/外すの二択であって
中庸を取ったりできない。

Along with creating a general sense of unease about the design, these
discussions illustrated plainly how fundamentally different the Indiana and
Texas philosophies still were. In particular, Dr. Stroustrup’s paper
proposed the elimination of so-called “explicit” concepts, which have been a
fundamental part of concepts since 2005 and had been a particularly
contentious issue from the beginning.
0435デフォルトの名無しさん2009/08/07(金) 19:23:05
もうやめてあげてこんせぷとのひっとぽいんとはぜろよ
0436デフォルトの名無しさん2009/08/07(金) 19:35:32
conceptとconcept mapは、もう少し分けて作ったほうが良かったんじゃないかと思う。
そもそもが二つの異なる提案だった歴史的理由もあるのだろうけど。

例えばこんな感じ。

conceptは、テンプレートを使ったコードの、コンパイル時のエラーチェックのみに使う。
conceptの利用に、concept mapを使う必要はないぐらい、concept mapから独立しているべき。

concept mapも、conceptの宣言に合うように既存の型を変えるという機能を提供する。
conceptに依存するのは、あくまでconcept map自体のエラーチェックをするためだけ。
利用方法も、もっと枠を広げて、conceptやテンプレート以外のコードから使えるようにしてもいいと思う。
0437デフォルトの名無しさん2009/08/07(金) 19:43:19
あとそれから、現状のtemplateコードで出来ることは、ぜんぶconceptで記述できるようにするべきだと思う。
例えば、現行のconceptの規格だと、メンバ変数を記述することが出来ない。
その理由については、コードをよりジェネリックにする等の言い分があるのだろうけれど、
普通のtemplateコードで出来ることが、constrained templateなコードでは出来なくなるというのでは、
conceptの使用をためらう人が出てくると思う。
0438デフォルトの名無しさん2009/08/07(金) 19:45:53
templateの使用さえためらう奴が多いのに何を今さら
0439デフォルトの名無しさん2009/08/07(金) 19:48:40
× templateの使用さえためらう奴
〇 templateの使用さえ禁止されている現場
0440デフォルトの名無しさん2009/08/07(金) 20:25:47
そうは言ってもtemplateを完璧にコンパイルできる処理系は未だにないわけで…
0441デフォルトの名無しさん2009/08/07(金) 20:50:43
>>434
> これは入れる/外すの二択であって中庸を取ったりできない。

in some cases, users may have to write an “empty” concept map
to satisfy the requirements of a constrained template in a library

辺りの修正が可能。

> 最後まで解決出来なかったということ。

次の標準がある。

0442デフォルトの名無しさん2009/08/07(金) 21:06:13
>>441
それで中庸にはならないだろ。

> 次の標準がある。
次が無いなどとは言ってないが。
0443デフォルトの名無しさん2009/08/07(金) 21:08:27
>>442
空のconcept mapを書かないでいいってのは
両者の中間でいいんじゃないの?
0444デフォルトの名無しさん2009/08/07(金) 22:45:40
単純化すると、実装者の都合とユーザー利益のどちらを重視するか、
という議論だよね。Bjarne はユーザー利益を譲らないから、最後に
なってあのレポートを出した。しかしまさか削除になるとは思って
なかったフシがあるね。難しいもんだ。
0445デフォルトの名無しさん2009/08/07(金) 22:52:54
いや、禿も正直あきらめていたんじゃね。
禿がSimplifying the use of conceptsを書くまでに数百通のMLでの議論、
書いた後も、そのペーパーを巡って数百通の議論だから、
到底、意見が一致するわけがないことぐらい分かりきっていただろ。
0446デフォルトの名無しさん2009/08/07(金) 23:00:42
>>444
どっちもプログラマのこと考えてるんだよ。
templateの特殊化のように強力なexplicit concept mapをどうするか。
便利だから必要←→ややこしくなるから省いた方がいい
0447デフォルトの名無しさん2009/08/07(金) 23:03:15
>>445
"Simplifying the use of concepts"は、
禿のC++0xへのconcept最終提案だよ。
この新しいconcept提案に入れ変えるか、
これまでのdraft通りのconceptを入れるか、
conceptを廃止するかの投票。
0448デフォルトの名無しさん2009/08/07(金) 23:29:27
中途半端なやさしさのせいでカオスになった型変換規則という悪しき前例があるからなぁ
基本的にimplicityは悪だと思う
禿ペーパーを最初に見たときは勘弁してくれと正直思った
0449デフォルトの名無しさん2009/08/07(金) 23:33:34
しかし、あれは禿の意見に賛成だがな。
conceptは自動でconcept_mapを生成すべきだろ。
明示的にconcept_mapを書かせたい場合だけ、これまた明示的にexplictを書くという方が、
人間的で分かりやすいと思うんだけどな。
0450デフォルトの名無しさん2009/08/08(土) 00:11:37
禿はそんな提案してないじゃん
0451デフォルトの名無しさん2009/08/08(土) 00:17:43
こうやってもつれて行くわけだなｗ
0452デフォルトの名無しさん2009/08/08(土) 02:34:57
C++1hでいいよ
0453デフォルトの名無しさん2009/08/08(土) 06:15:26
Bjarne Stroustrup Expounds on Concepts and the Future of C++
ttp://www.devx.com/cplus/Article/42448/0/page/1
ttp://www.devx.com/cplus/Article/42448/0/page/2
ttp://www.devx.com/cplus/Article/42448/0/page/3
ttp://www.devx.com/cplus/Article/42448/0/page/4

禿が今回のことについて語っている。
少々長いし、4ページに分かれているが、読むべき。
0454デフォルトの名無しさん2009/08/08(土) 10:51:53
>>453

読むから翻訳して
0455デフォルトの名無しさん2009/08/08(土) 12:35:39
>>453
全部読んだけど、これ本当に長いな。舐めたような酷い質問をしまくりで
禿も内心かなり頭にきた部分もあっただろうが、我慢強く答えてる。
0456デフォルトの名無しさん2009/08/08(土) 13:06:30
>>453
Bjarne は本当にできた大人だな。涙が出るよ。これからも頑張って欲しい。
まだ先の事だろうけど、Bjarne がいなくなった後の C++ が心配。
0457デフォルトの名無しさん2009/08/08(土) 16:44:22
禿がいなくなったらなくなるだろうな
アプリ系はJava/C#に完全移行してミドル以下はCに戻る
0458デフォルトの名無しさん2009/08/08(土) 16:53:11
Java はわかるが C# は…どうだ？
今のところ Microsoft しか扱ってないからなぁ。
0459デフォルトの名無しさん2009/08/08(土) 16:59:09
曲がりなりにもISO標準なのだから、禿がいなくなったからと言って
無くなることはない。
まあGCCがC++をアクティブにサポートし続ける限りは安泰だろう。
0460デフォルトの名無しさん2009/08/08(土) 17:30:32
安泰とかばかじゃね？
仕事で使えねーよ、こんな仕様じゃよ。
0461デフォルトの名無しさん2009/08/08(土) 17:31:07
仕様のせいにするなよ。才能だよ。
0462デフォルトの名無しさん2009/08/08(土) 17:34:13
安泰ってのはお前がこれからもまともに使いこなしていけるかって意味じゃねーんだよ
0463デフォルトの名無しさん2009/08/08(土) 18:08:51
>>460
知能の低い者はお引き取りください
0464デフォルトの名無しさん2009/08/08(土) 21:43:53
良くも悪くも禿の天才的センスに支えられた変態マニアック言語という側面と、
Cに次ぐ世界標準のネイティブ開発言語という側面と、
明らかに共存しそうにない二つの側面が共存しちゃってるからなぁ
0465デフォルトの名無しさん2009/08/09(日) 00:10:02
>>458
今でもすでにJavaよりC#の方がプログラマー多い。
SUNが悲惨だからJavaの将来の方が不安かと。
0466デフォルトの名無しさん2009/08/09(日) 00:39:21
>>463
その場合C++は滅亡する
0467デフォルトの名無しさん2009/08/09(日) 01:16:18
C#の方がJavaよりプログラマ多いって…そんな、ご冗談を＾＾
0468デフォルトの名無しさん2009/08/09(日) 14:15:14
つーかプログラムなんて、専門学校卒の仕事だろ？
大学でてプログラムなんてバカじゃね？

道具は簡単に使えればそれにこしたことはないんだがな。
0469デフォルトの名無しさん2009/08/09(日) 14:34:35
専門卒の仕事さえ出来ない大卒
0470デフォルトの名無しさん2009/08/09(日) 14:52:43
スレ違いはお引き取り願います
0471デフォルトの名無しさん2009/08/14(金) 23:52:20
>>453を翻訳
ttp://cpplover.blogspot.com/2009/08/bjarne-stroustrupconcept_14.html

正直疲れた。
質問者のDanny Kalevがウザすぎる。
その分、訳すのは楽しかったが、禿に対しては、あまりに無礼じゃないかと思う。
0472デフォルトの名無しさん2009/08/15(土) 00:13:05
>>471
乙
0473デフォルトの名無しさん2009/08/15(土) 00:47:58
>>471
YOUは最高だ。日本のC++コミュニティにとっていい仕事をした。誇っていい。
0474デフォルトの名無しさん2009/08/15(土) 00:57:35
>>471
面白かった。お爺さんと孫の問答みたいだった。
さらに、色々解って実用面でも効果テキメンですよ。
0475デフォルトの名無しさん2009/08/15(土) 01:07:35
Alexが1976年からSTL作ってた事にびっくりだよ
0476デフォルトの名無しさん2009/08/15(土) 01:16:42
ヒャッハーッ！
0477デフォルトの名無しさん2009/08/15(土) 05:04:35
>>471
ブログの宣伝するな速やかに削除依頼出して死ねカス
0478デフォルトの名無しさん2009/08/15(土) 05:24:03
いかにも私は学歴低いですって感じの煽りに吹いた
0479デフォルトの名無しさん2009/08/15(土) 09:44:30
言い方はともかく、DKが質問した内容はここで愚痴っていた内容と変わらんな。GCはいらんけど
頭の悪い一般のC++ユーザーが委員会に対して感じていた不満をぶつけたような記事だ
0480デフォルトの名無しさん2009/08/15(土) 09:57:44
じじい口調が気に食わん。
禿はオカマ言葉であるべきだ。
0481デフォルトの名無しさん2009/08/15(土) 10:17:45
あれでDannyが委員会のメンバだったっていうのが信じられない。
0482デフォルトの名無しさん2009/08/15(土) 10:51:15
でも誰もが聞いてみたかったことだろ？
0483デフォルトの名無しさん2009/08/15(土) 11:23:26
確かに禿はおかま口調の方が実際の声に近い感じがあるな。
0484デフォルトの名無しさん2009/08/15(土) 11:31:02
そんなにカマ臭いのかと動画をググってしまったじゃねーか。

納得。
0485デフォルトの名無しさん2009/08/15(土) 11:33:13
訳文だけ読んだ感じだとガチ問答でなくFAQ的なやらせ問答みたいだな。うざくて無礼なのはキャラ作りじゃないの。
0486デフォルトの名無しさん2009/08/15(土) 19:17:24
>>471
やる！本文以外も翻訳するとは！
0487デフォルトの名無しさん2009/08/15(土) 20:05:45
>>475
Adaのgenerics機能で実装していたからね。
0488デフォルトの名無しさん2009/08/15(土) 23:27:28
「○○の機能を使うのは一部のプログラマだから、
その機能が入っていても複雑ではない」っていう論法はどうなんだろう。
完全にライブラリとして閉じていたりすれば、そうなんだろうけど。
0489デフォルトの名無しさん2009/08/16(日) 00:09:47
びょーんびょーん
0490デフォルトの名無しさん2009/08/16(日) 00:16:03
>>488
演算子のオーバーロードなんかそれじゃないかな。
std::complexを使えば最初から言語に複素数が組み込まれていたかのように複素数が使える。
しかも、演算子のオーバーロードの書き方を知らなくてもライブラリユーザーは自由に複素数を使える。
0491デフォルトの名無しさん2009/08/16(日) 00:17:05
ライブラリ記述用C++と利用者用C++が必要だ
0492デフォルトの名無しさん2009/08/16(日) 00:18:34
利用者用C++ってC#だろ
0493デフォルトの名無しさん2009/08/16(日) 00:22:45
std::complexも罠の多いライブラリだからなぁ
中身知らずに使い切るのは難しいよ
0494デフォルトの名無しさん2009/08/16(日) 00:25:15
ぜんぜんインペーできてねージャンww
0495デフォルトの名無しさん2009/08/16(日) 00:36:56
templateにエラー出しコードを仕込める様になればいいんだよ。
0496デフォルトの名無しさん2009/08/16(日) 00:54:49
コンパイラ拡張用インタプリタ言語を規定すれば良いんだよ。
0497デフォルトの名無しさん2009/08/16(日) 01:15:17
conceptの文法って、templateバリバリ作る人向けでしょ。
templateまで作れるレベル。
classは作れるレベル。
ただ利用するレベル。
みたいな、一種のセキュリティレベルが必要か。
0498デフォルトの名無しさん2009/08/16(日) 02:41:57
何のために？
0499デフォルトの名無しさん2009/08/16(日) 08:38:59
>>497
かなり見当違いですね。
papers読めとまでは言わないけど、
>>453くらい読んで理解しようよ。
0500デフォルトの名無しさん2009/08/16(日) 09:13:00
>>497
ただ利用するレベルの人が、listのコンテナをsortに渡そうとしてエラーが
てんこ盛りになったときにこそconceptが必要でしょう。

0501デフォルトの名無しさん2009/08/16(日) 10:40:15
てか別に自分で作るtemplateが従来通りエラーぐちゃぐちゃでいいならconcept使う必要もないわけでなぁ
単に既存のtemplate使うだけならconceptがどんなものか知る必要もないし
0502デフォルトの名無しさん2009/08/16(日) 11:18:24
>>500
それは、conceptの機能の必要性であって、
conceptの定義文法を書けることの必要性（プログラマの能力）じゃないでしょ。

>>499
ストラウストラップの言ってることは、
「C++は複雑化していると言われるが、追加機能はどれも必要な機能だ」
「みんながみんな、C++を詳細に理解する必要はない」
「そういう詳細まで理解してプログラミングする人間は一部でいいし、実際に一部だ」
「プログラマは、自分の問題解決に必要な知識までを持てばいいんだ」
ってことじゃないの？
0503デフォルトの名無しさん2009/08/16(日) 11:58:59
確かに詳細まで理解してプログラミングしなくていい様にはできてる
(ただしプログラムが正常動作している時に限る)
0504デフォルトの名無しさん2009/08/16(日) 12:50:49
>>502
確かに禿が言っているのは大体その通り。
でも現状のSTLなんかはエラーが出たときに多少は実装を知らないと対処するのが
難しい面もある。慣れの問題とも言えるが。
Conceptsによってその辺の敷居が大幅に下がると期待してたんだがな。
0505デフォルトの名無しさん2009/08/16(日) 12:58:40
>>471
このスレにはりついててよかった
0506デフォルトの名無しさん2009/08/16(日) 14:18:40
http://cpplover.blogs pot.com/2009/08/bjarne-stroustrupconcept_14.html
0507デフォルトの名無しさん2009/08/17(月) 10:09:54
>>502
conceptはクラスライブラリの仕様をプログラムの中に陽に記述し、
それをコンパイラに検証させるために非常に重要って肝心のが抜けてるじゃない。
そこを理解できてないから、>>497を妄想だけで書いてしまう。
>>471が張られてても理解できないなんて信じられない。
0508デフォルトの名無しさん2009/08/17(月) 11:25:31
Danny Kalev役を演じているだけでしょう…
0509デフォルトの名無しさん2009/08/17(月) 11:33:16
件のinterviewでのDanny Kalevもまた平均的なC++プログラマを演じているだけなんだけどね
0510デフォルトの名無しさん2009/08/17(月) 11:45:10
>>509
こいつDanny Kalevじゃね？
0511デフォルトの名無しさん2009/08/17(月) 11:49:36
原文を読んでたら>>509のような捻くれた見方は有り得ないんだが。
0512デフォルトの名無しさん2009/08/17(月) 12:15:33
まあ、DKのような挑発的な質問をするには、これまでの経緯を知っている必要があるぜ。
このスレには、まともにドラフトもペーパーも読まず、
脳内規格とペーパーのタイトルだけで分かった気になっている奴がいるようだな。
0513デフォルトの名無しさん2009/08/17(月) 21:05:22
で、結局俺らは引き続きコンパイルエラーの
謎メッセージと戦い続ける事になっちゃったの？
0514デフォルトの名無しさん2009/08/17(月) 21:30:30
Conceptでエラーメッセージが分かりやすくなるとかいうのは
都市伝説だから

試しにConceptGCCで(うわなにをするやめｒ
0515デフォルトの名無しさん2009/08/17(月) 21:41:20
あれはエラー報告の実装が腐ってるだけ
Boost.ConceptCheckを使って
grepでconcept_check_failedがある行でフィルタするだけでもかなり違う
0516デフォルトの名無しさん2009/08/17(月) 23:14:44
static_assertと<type_traits>でコンセプトの代わりは大体出来る
mapはできないけど
0517デフォルトの名無しさん2009/08/17(月) 23:18:43
>>515
まあだからそれもあんまり良くなかったんじゃないの

ConceptGCCというのがあるみたいだし、
ちょっとコンセプトとやらを試してみるかーって時に
そこが腐ってたら、そりゃなんだコレってことになるわけで
0518デフォルトの名無しさん2009/08/17(月) 23:27:09
それをするなら、コードから、コンパイラ自体にメッセージを表示させる仕組みが欲しいよな。
VCの#pragma messageみたいに。
0519デフォルトの名無しさん2009/08/17(月) 23:44:35
Javadocのコメント文法を言語仕様に含めてもらいたいな
0520デフォルトの名無しさん2009/08/17(月) 23:53:42
そんなことしたらまた仕様が膨れるじゃないか
doxygenで十分
0521デフォルトの名無しさん2009/08/18(火) 00:32:13
膨れて何が悪い
0522デフォルトの名無しさん2009/08/18(火) 00:35:47
理由も分からん馬鹿か
0523デフォルトの名無しさん2009/08/18(火) 00:38:32
と言って説明せずに逃げるアホ
0524デフォルトの名無しさん2009/08/18(火) 00:48:55
説明しろだとか、さすが夏だな
0525デフォルトの名無しさん2009/08/18(火) 00:51:13
C++の仕様が膨れると悪いということについて、合理的な理由は提示されませんでした。

よって、
>>519 採用
>>520 却下
0526デフォルトの名無しさん2009/08/18(火) 00:54:06
ままごと遊びかよ
0527デフォルトの名無しさん2009/08/18(火) 01:00:16
小学生はママのおっぱい飲んで早く寝ろよ
0528デフォルトの名無しさん2009/08/18(火) 09:25:36
小学生までママのおっぱい飲んでた人の煽りはやっぱ違うな
0529デフォルトの名無しさん2009/08/18(火) 17:30:41
美少女中学生のおっぱい飲みたい
0530デフォルトの名無しさん2009/08/18(火) 19:40:17
>>525　C++の仕様が膨れても良いという合理的な理由が示されませんでした。
よって
>>519却下
>>520採用

てか、ム板で二重否定かよ
0531デフォルトの名無しさん2009/08/18(火) 19:50:07
>>519によれば、コンパイラーでドキュメントの自動生成が可能になる。
できないことができるようになるのは良いことだ。
以上により、>>519の合理性は示された。

一方、C++の仕様が膨れると悪いということについて、合理的な理由は提示されていない。

よって、
>>519 採用
>>520 却下
0532デフォルトの名無しさん2009/08/18(火) 19:56:56
やっぱりこれからは俺俺言語の時代か。
0533デフォルトの名無しさん2009/08/18(火) 19:57:27
こんなところで不毛な言い争いしてないでproposal書いてISOに送れよ
0534デフォルトの名無しさん2009/08/19(水) 14:33:57
自分のプロポーションを気にして風呂場の鏡の前でおっぱいをよいしょっと持ち上げる美少女中学生
0535デフォルトの名無しさん2009/08/19(水) 18:25:52
>>531
仕様が膨れると、高卒が理解できない。
大卒でITは、頭がおかしいので除外。
0536デフォルトの名無しさん2009/08/19(水) 20:36:36
>>535
要するに日本のIT業界にはバカとキチガイしかいないってことか。
だとすると名実ともに Embedded C++ は日本人専用なので、これでも使っとけ。
当然、C++0x は禁止ってことになるな。
0537デフォルトの名無しさん2009/08/19(水) 21:19:57
名前空間とtemplate無い時点で誰も使わんわ
0538デフォルトの名無しさん2009/08/19(水) 21:53:39
template省くのはまだ理解できなくもないが
名前空間を無くす意味がまったくわからない
0539デフォルトの名無しさん2009/08/19(水) 22:12:20
template省くと何かいいことあるの？
0540デフォルトの名無しさん2009/08/19(水) 22:25:02
高卒はC使ってろって話。
0541デフォルトの名無しさん2009/08/19(水) 22:27:21
>>539
コンパイラ作るのが楽になる。
0542デフォルトの名無しさん2009/08/19(水) 22:35:30
テンプレートと名前空間は最初のころは無かったし。
0543デフォルトの名無しさん2009/08/19(水) 22:36:48
じゃあ、クラスも無くていいな。
0544デフォルトの名無しさん2009/08/19(水) 22:41:57
テンプレートは無いとコンパイル速くなるよ。
0545デフォルトの名無しさん2009/08/19(水) 22:44:01
テンプレートも名前空間もクラスもないC++っていうと何が残って･･･
関数のオーバーロード？
0546デフォルトの名無しさん2009/08/19(水) 23:02:24
まだデストラクタがある。
0547デフォルトの名無しさん2009/08/19(水) 23:04:01
クラスが滅びたのにデストラクタだけ残るなんて滑稽だわ
0548デフォルトの名無しさん2009/08/19(水) 23:17:47
例外、テンプレート、名前空間がなければＣのプリプロセッサ改造だけでコンパイラが作れそうだな。
0549デフォルトの名無しさん2009/08/19(水) 23:20:10
C99でおｋ
0550デフォルトの名無しさん2009/08/19(水) 23:31:04
>>547
クラスは滅びぬ、何度でもよみがえるさ。再利用可能なモジュールこそがプログラマの夢だからだ。
0551デフォルトの名無しさん2009/08/19(水) 23:52:37
再利用よりも、簡単に仕様変更できたり、刷新できたりする方向で
進化して欲しいなと最近思う。
0552デフォルトの名無しさん2009/08/20(木) 05:08:41
C with classesで
0553デフォルトの名無しさん2009/08/20(木) 07:15:26
>>540
大卒でITなんて、負け組。
バカなんじゃないの？
0554デフォルトの名無しさん2009/08/20(木) 07:47:33
やっぱ院卒だよな
0555デフォルトの名無しさん2009/08/20(木) 13:00:03
555
0556デフォルトの名無しさん2009/08/20(木) 18:17:50
院卒でITは終わったな。
0557デフォルトの名無しさん2009/08/20(木) 18:22:07
スレ違いも大概にしろ
0558デフォルトの名無しさん2009/08/20(木) 19:43:01
個人的にはSTLのないC++に存在意義感じない
組み込みは元々事実上使えないから問題ないんだろうけど
0559デフォルトの名無しさん2009/08/20(木) 19:59:03
lambda式がないSTLも微妙だ
0560デフォルトの名無しさん2009/08/20(木) 21:12:45
頑張って関数オブジェクト書けよ
お父さんはそうしてきたぞ
0561デフォルトの名無しさん2009/08/20(木) 22:43:27
>>553
院卒のIT系高給取りでごめんな
0562デフォルトの名無しさん2009/08/20(木) 23:21:12
院卒w
0563デフォルトの名無しさん2009/08/20(木) 23:27:02
マ板でやれ
0564デフォルトの名無しさん2009/08/21(金) 07:40:34
>>561
バカだな。その程度の給料で高給とは片腹痛い。
ためしにいくらもらってるか書いてみろよ。
0565デフォルトの名無しさん2009/08/21(金) 07:43:27
なんか今凄まじい矛盾を見た気がした
0566デフォルトの名無しさん2009/08/21(金) 18:13:35
Embedded C++は事実上死亡している。
なにしろ「いらね」というTRが出ているくらいだ。
0567デフォルトの名無しさん2009/08/22(土) 02:20:55
>>558
組み込みだってSTL使うよ。
デフォルトアロケータのコンテナを使わないだけだ。
0568デフォルトの名無しさん2009/08/24(月) 14:50:33
>>567
組み込みだと例外処理が使えなかったりしないか?
例外なしの STL って辛くないか?
0569デフォルトの名無しさん2009/08/24(月) 14:57:01
STLは汎用性のためスペックを多く使う。
動作が遅いCPCではつかえない
0570デフォルトの名無しさん2009/08/24(月) 15:01:47
スペックは使うものではないのでは？
0571デフォルトの名無しさん2009/08/24(月) 18:55:20
>>568
例外が発生しないように使う。
まったく問題ない。
0572デフォルトの名無しさん2009/08/24(月) 19:26:07
404 ：デフォルトの名無しさん[sage]：2007/11/07(水) 22:28:18
　　conceptは間に合うんだろうか

405 ：デフォルトの名無しさん[sage]：2007/11/08(木) 04:58:25
　　あ、concept は余裕で間に合うよ。安心しといて。
　　それより問題なのは export なんだよ。実は。

408 ：デフォルトの名無しさん[sage]：2007/11/12(月) 21:22:45
　　concepts抜きでは送り出さんと書いてあるね。
　　ttp://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry
　　
　　知らん間にスケジュールが1年ずれてたんだな…
0573デフォルトの名無しさん2009/08/25(火) 19:58:56
>>568
具体的に、何の例外が欲しい？

>>569
具体的に、どれが遅かった？
0574デフォルトの名無しさん2009/08/25(火) 21:17:33
C++の仕様には把握できないほどの仕様を常に盛り込んでいくべきだ
そうでなければ萌えない
0575デフォルトの名無しさん2009/08/25(火) 21:29:13
ゼロオーバーヘッドルールだけで３杯はいける。
後の仕様はどうだっていい。
0576デフォルトの名無しさん2009/08/25(火) 21:35:26
つ多重継承
0577デフォルトの名無しさん2009/08/25(火) 21:46:16
俺的な萌えポイントはゼロオーバーヘッドとメタプログラミング
ただメタプログラミングはもう少し綺麗に書けるようになって欲しい
メタ演算子が定義できればなぁ
0578デフォルトの名無しさん2009/08/26(水) 01:43:37
プロパティ入れて欲しい
0579デフォルトの名無しさん2009/08/26(水) 02:01:34
アクセサめんどいしなぁ
確かにプロパティは欲しいっつーか構文糖だし簡単に入れられそうだけどなぁ
0580デフォルトの名無しさん2009/08/26(水) 02:17:43
プロパティは=や->のオーバーロードが絡むとカオスになる
無理だろ
0581デフォルトの名無しさん2009/08/26(水) 03:00:34
特定のアクセサ関数に何かしらの方法で紐付けして、直接アクセスしようとしたら後ろに
()が付いてると見なす、とかじゃ駄目なん？
俺的にはクラスを書くのが面倒とかより、アクセサかそうでないかで書き分けになるのが
後々まで悩ましくて困るんで、それさえ解決できれば十分嬉しいんだけど
0582デフォルトの名無しさん2009/08/26(水) 05:10:55
TC++PL読んでて思ったけど、もう3rd出てから12年経つのな。
1986 1st 初の商用リリース(Cfront 1.0)
1992 2nd 標準化初期-テンプレートの実装(Cfront 3.0)
(1994 STL標準へ)
1997 3rd 標準ほぼ確定
(201x 4th C++0x確定)
各版の出版時期を調べてみたらこんな感じで、
3rdから12年を過去に遡るとTC++PLの初版すら出ていない時期で、
3rdが出た頃って今知られているような書籍は
Effectiveの初版とMore Effectiveくらいしか出てなかったんだよね。
そう考えると、3rdの頃から大きく変わったC++のプログラミングスタイルと、
C++0xを盛り込んだ4thが待ち遠しくて仕方ない。
0583デフォルトの名無しさん2009/08/26(水) 10:20:14
Effectiveは、更新をこまめにやるから生き残っている。
昔も、C++ GEMSとか、CoplienのAdvanced C++ Programming Styles and Idioms、
Ruminations on C++とか、イディオム系のいい本はたくさんあった。
tC++PLは、イディオムはあまり書かずに、機能面に集中しているから、
このスレにいるような人は既知のことが多いのでは。

0584デフォルトの名無しさん2009/08/26(水) 11:18:59
>>573
・メモリ確保に失敗したら、メモリ不足画面を出し速やかにアプリを終了させなければならない

という環境で、さらに例外が無かった。
ありえない
0585デフォルトの名無しさん2009/08/26(水) 11:24:02
>>584
set_new_handler()も知らないのか
0586デフォルトの名無しさん2009/08/26(水) 11:41:54
メモリ不足画面を出すメモリの確保に失敗したら？
0587デフォルトの名無しさん2009/08/26(水) 11:48:21
>>586
そんなことがあると >584 の仕様を満たせないから、メモリ不足画面は追加の
メモリ確保が要らない状態で待機させとくべきだろう。
0588デフォルトの名無しさん2009/08/26(水) 11:52:29
BREW環境の話だなたぶんｗ
あれは、メモリー確保に失敗しても正常にアプリが動作し続け、かつスレッドが使えず、かつOSに制御を戻さなければならない（無限ループ禁止）
また、終了の際自分が確保したメモリは全てきっちり解放しなければならない(long jumpでの大脱出禁止）

なのでset_new_handlerしてそこでエラー画面を出すこともできない
最近は例外使えるようになったから、メモリー確保失敗したらいっきにメインループの外までジャンプできるようになった
0589デフォルトの名無しさん2009/08/26(水) 17:53:09
そういう環境なら例外に対応した方が結果的には楽になりそうだな
つーか例外無しでどうやってたんだそれ
0590デフォルトの名無しさん2009/08/26(水) 17:54:24
ああ、newの戻り値いちいちチェックするだけか
で、STLとか使えない環境だぜ、ってなる訳ね、なるほど
0591デフォルトの名無しさん2009/08/28(金) 01:55:25
「GSoCの学生には任せておけん」ってことになったかは知らないけど、
gcc cxx0x-lambdas-branchのメンテナが2人になったようだね。
新しくメンテナになったJason MerrillはC++標準化委員会のメンバーみたいだし、
lambdaが正式に実装される日もそこまでは遠くなさそうだ。
0592デフォルトの名無しさん2009/08/28(金) 02:20:10
だといいがな…

ConceptGCCはもう捨てるのかな
0593デフォルトの名無しさん2009/08/28(金) 03:05:49
>>592
http://gcc.gnu.org/ml/gcc/2009-07/msg00641.html
だとさ

http://wiki.apache.org/stdcxx/C++0xCompilerSupport
見ていると、gccは細かい仕様の実装が早くて、ICC, VCは重要なもの優先、
そしてC++ Builderはマイペースな感じだな
0594デフォルトの名無しさん2009/08/28(金) 17:53:07
>>584
STL じゃなければ、ありうる状況になるの？
元の議論をたどってみなよ。何の反論にもなってないと思うけど。
例えばSTLコンテナを使用禁止にしても、配列を std::sort() したり std::equal_range() したり
std::count_if() したりするためだけでも、十分 STL の恩恵があると思うよ。
C の標準関数の qsort() とか bsearch() とかの方が好み？
0595デフォルトの名無しさん2009/08/28(金) 17:57:46
それそもそも反論なのか？
0596デフォルトの名無しさん2009/08/29(土) 14:20:38
>>594
「よくわからないから」という理由でSTL禁止にしたウチのPMに言ってやってください
0597デフォルトの名無しさん2009/08/29(土) 19:04:15
そういうのはマ板でやってよ…
0598デフォルトの名無しさん2009/08/29(土) 20:25:54
STL禁止の所があるのかｗｗ
0599デフォルトの名無しさん2009/08/29(土) 20:46:09
>>596
昔、若かったころはSTLでコンパイルエラーが出ても意味不明だったんだから許してあげてよ。
0600デフォルトの名無しさん2009/08/29(土) 21:23:40
その後進歩してないってことだから許さない
0601デフォルトの名無しさん2009/08/29(土) 22:28:22
>598
海外のソフトのカスタマイズではコーディング規約としてそういう縛りはふつうにあるよ
海外だと結構お年の人が現役でコード組んでるから、なるべくコードの意味が多重化する
機能を禁止する傾向がある
0602デフォルトの名無しさん2009/08/29(土) 22:43:45
STLって使いやすいとは思わなかったから使ってなかったんだけど、boostと一緒に使うと驚くほど使いやすくなった。
BOOST_FOREACHとかiterator_adaptorとかiterator_rangeとかと組み合わせるとすごい強力で使いやすい。
STL使わなかった人もこれなら満足するんじゃないかな。
0603デフォルトの名無しさん2009/08/29(土) 22:47:45
>>601
そうなんだ
車輪の再発明が好きなお年寄りが多いんだな
ご苦労なことだ
0604デフォルトの名無しさん2009/08/29(土) 23:00:23
>603
それをカスタマイズする人たちが知る必要はないだけ
機能を提供する側はSTLをtypedefしているだけかもしれないよ

define が衝突するのでそれはないが
0605デフォルトの名無しさん2009/08/30(日) 02:32:03
STLと例外がないC++なんて面倒くさくてやってられない
0606名無しさん＠そうだ選挙に行こう2009/08/30(日) 03:41:46
Boostの無いC++も面倒くさくてやってられない
0607名無しさん＠そうだ選挙に行こう2009/08/30(日) 05:19:31
C++03にすらついてきていない俗世の話はおいといて、スレに沿った話をしようぜ。
もっとも、Conceptが外れることが決まってC++0xは
ほとんど確定してしまったからあまりネタが無いと思うんで、
そろそろC++0xの次についてを話題にしても良いんじゃないかと思うね。
言語仕様はConceptは個別にTRとして世に出ることは無いとすっぽすっぽが言ってたから、
C++0xの次の標準まで待たなくてはならないことは確か。
わりと影響が大きそうなModules in C++(N2316)は個別TRを予定しているらしい。あとはGCがどうなるか。
ライブラリに関してはLibrary TR2として
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html の
"〜 Accepted into TR2"と"〜 Planned for a Future TR"
からは大きくは違わないものが入るのはほぼ間違いない。
"Papers With an Open Status"になってるものも、改良されて入ってくる可能性が高いね。

他に何に入ってほしい？
0608名無しさん＠そうだ選挙に行こう2009/08/30(日) 06:11:47
N2316を見てみたが、Introduction読むだけで汁が漏れそうだ
0609名無しさん＠そうだ選挙に行こう2009/08/30(日) 06:14:50
STL w
0610名無しさん＠そうだ選挙に行こう2009/08/30(日) 06:20:34
>>607のリンクは正しくは
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2870.html
だった
0611名無しさん＠そうだ選挙に行こう2009/08/30(日) 11:42:40
じゃあGCの話でも

すっぽすっぽはD&EでC++にGCを入れるなら，入れるか入れないかのどちらかで，
入れたり入れなかったりする選択肢を作ることはありえないみたいなことを言っていたと思います

では入れるとして，問題になるのはGCが使えないような環境ですが，
今時GCが使えなくてC++を使っている環境ってありますかね？
あまり知りませんが，そういうところはいまだにあえてCを使っているということはないでしょうか
0612名無しさん＠そうだ選挙に行こう2009/08/30(日) 12:00:20
>>611
そういう時のためのスマートポインタでありRAIIでありPimplイディオムなわけだが
0613名無しさん＠そうだ選挙に行こう2009/08/30(日) 12:07:55
RAIIで固めまくっててリーク何それ状態なのに今更GCなんか来ても何も嬉しくないんだが…
0614名無しさん＠そうだ選挙に行こう2009/08/30(日) 12:14:29
>>611
C++にはゼロオーバーヘッド原則あるから組み込みでも
Embedded C++みたいなサブセットじゃなくてC++使えば良いよ
ってことが書かれたのがPerformance TR。
だから、C++が今使われてない環境はあっても、使えない環境は事実上無い。

でも、GCはリアルタイム性の確保が不可能だからその手の環境じゃ
少なくともコーディング規約上禁止されるに違いないし、
GCについてもゼロオーバーヘッド原則は守られなければならない、ってところかな。
0615名無しさん＠そうだ選挙に行こう2009/08/30(日) 13:24:18
GCか・・・昔は欲しかったけど今はどうでもいいな
0616名無しさん＠そうだ選挙に行こう2009/08/30(日) 13:33:04
スマポが十分使えるからmark&sweep方式のGCとか使えるようになっても俺は使わないだろうなぁ
thisの参照を数えないから自分への最後の参照を切るような処理をするとsuicideしちゃう点だけ何か上手い方法あればなと思うくらい
0617名無しさん＠そうだ選挙に行こう2009/08/30(日) 13:34:33
>thisの参照を数えないから

kwsk
0618名無しさん＠そうだ選挙に行こう2009/08/30(日) 14:53:26
スマートポインタで十分だと思うし。スマートポインタでうまくいかない場合が思いつかない。
0619名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:12:47
循環参照の問題があるから所有権を明確に管理しないとまずいし。
イベントドリブンなコードをOOP的に書いてるとすぐ循環する。
0620名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:17:57
いやだからBoostのスマポは何種類かわざと用意されているわけで
0621名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:20:53
一方に、弱弱しいポインタを使えば解決。
0622名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:21:30
手段があればいいってもんでもなくて。
それを正しい知識を持った人が選択しないと有効に働かないってのがなぁ。
0623名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:23:00
ほとんどの循環参照は設計で解決できる。
それでも解決できないイベントハンドラのような循環参照を起こしやすいものはweak_ptrで解決できる
0624名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:32:23
スマポで必要十分なのは確かだけど古めのフレームワークで
RAIIに従ってないのがあるとすり併せに苦労するのが辛い
0625名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:41:21
>>622どんな道具も正しく使わないと効果を発揮しないものだ。
たとえGCがあっても不要なデリゲートやら参照やらをいつまでも保持していると
リソースの開放をしてくれない。
0626名無しさん＠そうだ選挙に行こう2009/08/30(日) 17:04:57
Javaだって循環参照するとリークするからわざわざ参照を4種類も用意してる
GCは万能ではない
0627名無しさん＠そうだ選挙に行こう2009/08/30(日) 18:01:48
>>626
＞Javaだって循環参照するとリークするから
それはない。
循環参照でリークするのはJava仕様違反。
0628名無しさん＠そうだ選挙に行こう2009/08/30(日) 18:51:28
>>616
これでできないか？
class A :public boost::enable_shread_from_this<A>
{
public:
void hoge()
{
shared_ptr<A> my=this->shared_from_this();
}
};
0629名無しさん＠そうだ選挙に行こう2009/08/30(日) 18:57:26
>>611
ゲーム屋や組み込み系のこともたまには思い出してあげてください

例外やRTTI無しがデフォっす
0630名無しさん＠そうだ選挙に行こう2009/08/30(日) 18:57:52
まぁでも、C++に標準的にGCが導入されたら世の中のメモリリークがある程度減る
という想像は付く（問題が先送りされただけって考え方もあるが）
逆に、リークさせてはStop the world、なアプリが無駄に増えそうな気もするが…
どっちがいいんだろうなぁ
ゼロオーバーヘッドが守られるならどうでもいい、ってのはある
0631名無しさん＠そうだ選挙に行こう2009/08/30(日) 19:09:35
リークがなくなるといっても、わざとリークさせてGCが回収するってことだから設計がいい加減なソフトが蔓延しそうな気がして怖い。
0632名無しさん＠そうだ選挙に行こう2009/08/30(日) 19:13:42
scope_exitも言語仕様でサポートしてくれ
0633名無しさん＠そうだ選挙に行こう2009/08/30(日) 19:16:22
Perlのループラベル構文もパクってくれ
0634名無しさん＠そうだ選挙に行こう2009/08/30(日) 19:52:57
>>632
shared_ptrのカスタムデリータにlamda関数をセット
0635名無しさん＠そうだ選挙に行こう2009/08/30(日) 20:08:46
lambda
0636デフォルトの名無しさん2009/08/30(日) 21:43:09
そういうのになると多分適当な連中は手抜きして使わないんだよなぁ…
というか、たまには綺麗に書ける為だけの追加があってもいいと思うんだ
0637デフォルトの名無しさん2009/08/30(日) 21:47:19
ライブラリでできることはライブラリでって方針なんじゃ？
0638デフォルトの名無しさん2009/08/30(日) 22:36:31
scope_exitはマクロで制約付きだからなぁ
制約付きのマクロでいいなら、新しいfor構文も要らないことになるし
0639デフォルトの名無しさん2009/08/31(月) 16:35:45
finally入れろって？
0640デフォルトの名無しさん2009/08/31(月) 16:52:31
VCはfinally入るっぽいんだっけか
0641デフォルトの名無しさん2009/08/31(月) 18:43:05
>>633
賛成！
それがあったら、gotoを使わなくても
よくなるのに。
0642デフォルトの名無しさん2009/08/31(月) 19:21:35
finallyじゃなくscope(exit)の方がいいなぁ
つーかfinallyだったら別にイラネ
0643デフォルトの名無しさん2009/08/31(月) 19:34:17
イディオムで何とかなればいい、使える奴が使えればいい、ってのに慣れすぎてる
ところはあると思う
爺さんもある程度の危惧はあるみたいだが…
0644デフォルトの名無しさん2009/08/31(月) 20:05:08
auto h = shared_new Hoge;
でshared_ptr<Hoge>が帰ってくるようにならねえかなあ
0645デフォルトの名無しさん2009/08/31(月) 20:18:00
>>644できるよ！
auto h=boost::make_shared<Hoge>();
0646デフォルトの名無しさん2009/08/31(月) 20:45:59
可能な限りライブラリ主義は問題ない。
ソースの先頭に #include <...> が十数行必要になること以外は。
0647デフォルトの名無しさん2009/08/31(月) 20:47:43
#include "all.h"
0648デフォルトの名無しさん2009/08/31(月) 20:51:55
使用頻度が高いものはプリコンパイルヘッダーに入れちゃうけどね。
boostのヘッダーなんか一箇所でも使う箇所があったらプリコンパイルヘッダーに入れてる。
0649デフォルトの名無しさん2009/08/31(月) 21:11:01
pchを使わない生活には戻れないなぁ
VC++のは癖ありすぎだけど

Boostで提供してるマクロは、つまりは言語サポートが不足してる部分だと思ってる
FOREACHもSCOPE_EXITもSTATIC_ASSERTもそうだし、そもそもPP系が全部そう
まぁPP系は最終手段として必要だろうけどな…
0650デフォルトの名無しさん2009/08/31(月) 21:20:15
プリプロセッサがもっと強力になればいいんだな

そうだPHP埋め込めば(ry
0651デフォルトの名無しさん2009/08/31(月) 21:46:53
#define BOOST_FOREACH foreach
とすれば組み込み機能かと錯覚しちゃうぐらいだよ
0652デフォルトの名無しさん2009/08/31(月) 21:52:49
錯覚できるくらい完全なら幸せなんだろうけどなぁ
0653デフォルトの名無しさん2009/08/31(月) 22:20:36
安心しろ、C++0xでは本物のforeachが言語組み込みになる！

はずだったじゃないか、なあ
0654デフォルトの名無しさん2009/08/31(月) 22:27:15
本来、Range-based for はconceptを前提にして設計されていたからな。
それをADLなんていう、根本的に邪悪な機能で実装しようとしたら、
悲惨なことになるのは当たり前だろ。

ほんとにどうするんだろ、n2930。
0655デフォルトの名無しさん2009/08/31(月) 22:35:16
差し当たりダサい実装になるのは仕方ないけど
後で新生concept版に置き換えるときに邪魔になってグダグダになるのが一番怖い
0656デフォルトの名無しさん2009/08/31(月) 22:46:15
すっぽすっぽおじさんはちゃんと>>646-648のことも考えてくれているんだよ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf
0657デフォルトの名無しさん2009/08/31(月) 22:47:02
>>651
それ#define間違ってね？
0658デフォルトの名無しさん2009/08/31(月) 23:10:44
#define BOOST_CONSTEXPR constexpr
#define BOOST_DECLTYPE decltype
#define BOOST_NULLPTR nullptr
#define BOOST_LAMBDA []
#define BOOST_AUTO(v,e) auto v = e
#define BOOST_ENUM_CLASS enum class
0659デフォルトの名無しさん2009/09/01(火) 00:03:35
しかしさ。n2930だと、begin(), end()は、stdをassociated namespaceに付け加えたADLによって探されると規定されているんだよね。
つまり、通常のunqualified lookupは実行されない。
問題ありすぎるよな。

自作のクラスで、イテレーターを返すメンバ関数のシグネチャがbegin(), end()じゃなかったりする場合に、
自作クラスをRange-based forで使えるようにするには、ADLが何かということを理解していなければならない。

例えば、ある名前の名前空間に入っている自作クラスをRange-based forに対応させるためのbegin(), end()を、
グローバル名前空間に書いても、Range-based forは動かない。
なぜなら、通常のunqualified lookupは実行されないから。

テンプレート引数の型の名前空間もassociated namespaceになるので、
ある名前空間でテンプレートクラスとbegin()/end()を定義して、
別の名前空間の型をクラスのテンプレート引数に渡したとき、
たまたまシグネチャが一致するbegin()/end()が、別の名前空間にあっただけで、曖昧でエラーになる。

Joe coderにADLの理解を強要するのか？
0660デフォルトの名無しさん2009/09/01(火) 00:14:40
ADLを理解していないレベルのJoe coderは自作クラスを
Range-based forに対応させようと思うどころか、
対応させることが出来るとも思わないんじゃないか、という疑問
0661デフォルトの名無しさん2009/09/01(火) 07:34:52
ライブラリだけで使っていれば良いんだよ
0662デフォルトの名無しさん2009/09/01(火) 12:27:36
使わね〜
0663デフォルトの名無しさん2009/09/03(木) 09:37:36
不定値を表すリテラルとか欲しいなぁ
0664デフォルトの名無しさん2009/09/03(木) 09:40:00
>>663 何に使えるの？
0665デフォルトの名無しさん2009/09/03(木) 10:25:52
不定値で済ませれば最適化が掛けられる場所もあるなぁと
まぁ例えば、API関数にダミー突っ込む時とか？
0666デフォルトの名無しさん2009/09/03(木) 10:32:30
>>665
それだけじゃ良く分からん。具体例を示して
0667デフォルトの名無しさん2009/09/03(木) 10:54:14
>>665
具体的に！
0668デフォルトの名無しさん2009/09/03(木) 10:54:41
sub sp, 16
とか
dw ?
とかに相当する操作が欲しいってだけで、使い道も効果も微妙だから総合的には微妙
ただ「アセンブラならここは不定値だよなぁ」って思う時がたまにあるから思い出しただけ
0669デフォルトの名無しさん2009/09/03(木) 10:56:35
と書いてて思ったけど
dw ?
は多分普通に初期化しない静的変数として書いてるな
0670デフォルトの名無しさん2009/09/03(木) 11:00:02
と書いてて思ったけど（連投ですまんが）、結局関数の引数以外は不定値普通に書けるな

int dummy;
f(dummy,dummy,dummy,dummy);
がpush四回になるかsub sp,16になるかはコンパイラ次第か。別に不定値要らないな。
0671デフォルトの名無しさん2009/09/03(木) 12:08:54
>>670
COMとかのoutみたいなもんか。
0672デフォルトの名無しさん2009/09/03(木) 12:25:28
いや、COMのoutはちゃんと0入れないとやばくね
0673デフォルトの名無しさん2009/09/03(木) 17:00:37
includeを打ち消すdecludeみたいなのが欲しいなぁ。
undefみたいなノリで
0674デフォルトの名無しさん2009/09/03(木) 18:19:36
推薦図書スレに誤爆した奴がいるらしい
0675デフォルトの名無しさん2009/09/03(木) 19:10:41
>>673
一体どういう挙動するんだそれ…
0676デフォルトの名無しさん2009/09/03(木) 19:17:14
includeで読み込んだh内のclassとかdefineとか変数とか一切合財
decludeで無かったことになる、と。

include <hoge.h>

〜　hoge.h で記述されてるものを使ったコード　〜

declude <hoge.h>
ここから無効


pimplしなくてもhを軽くできて良いんじゃないかなぁと。
激しく実装するのが面倒そうだが
0677デフォルトの名無しさん2009/09/03(木) 19:18:34
>>676
> pimplしなくてもhを軽くできて良いんじゃないかなぁと。

お前勉強し直しな。
0678デフォルトの名無しさん2009/09/03(木) 19:22:49
>>677
勉強すればheaderのチェーンを断ち切る目的でpimpl使おうと思わなくなれるんですか？
0679デフォルトの名無しさん2009/09/03(木) 20:20:09
> hが軽くできて

kwsk
0680デフォルトの名無しさん2009/09/03(木) 20:25:07
>>679
簡単にｴｯﾁできるって意味では無いと思うぞ
0681デフォルトの名無しさん2009/09/03(木) 20:54:45
>>676
結局ヘッダ読み込んでコンパイルしてる上に、 declude の処理が増えてるじゃん。
ヘッダが「軽く」なるように感じる要素がまるで無い。
0682デフォルトの名無しさん2009/09/03(木) 21:09:30
せめてexcludeとかにしてくれ・・
0683デフォルトの名無しさん2009/09/03(木) 21:21:29
make 使わなくても済む様に C++ で規格化してくれりゃIDE毎の違いやら鈍足 template が一気に解決するのにね
0684デフォルトの名無しさん2009/09/03(木) 21:26:30
pascalのようにuses で自動的にコンパイル＆リンクまでしてくれるとありがたいのに。
0685デフォルトの名無しさん2009/09/03(木) 21:46:09
PGOみたいな最適化の邪魔になるような気がする
0686デフォルトの名無しさん2009/09/03(木) 22:11:25
includeの話をしてる奴らはとりあえずModules in C++も一応嫁
0687デフォルトの名無しさん2009/09/03(木) 22:14:01
>>683
何を言っているのだ、お前は？
0688デフォルトの名無しさん2009/09/04(金) 00:14:45
>>681
ヘッダの連鎖コンパイルは減るじゃん
0689デフォルトの名無しさん2009/09/04(金) 00:36:58
何で減るんだ？
0690デフォルトの名無しさん2009/09/04(金) 00:38:36
そもそもヘッダの連鎖だかチェーンだかとやらが意味不明なんだけど、何のことを
指してるんだ？
0691デフォルトの名無しさん2009/09/04(金) 06:48:08
減らないし、g++もVC++もpre-compiled headerあるし、
>>676って、下手な考え休むに似たり、ってことでしかない。
0692デフォルトの名無しさん2009/09/04(金) 07:49:38
pimplならローカルなクラスの宣言は .cpp のほうに書けばいいんでないの
0693デフォルトの名無しさん2009/09/04(金) 07:51:03
すまん、692は忘れてくれ
0694デフォルトの名無しさん2009/09/04(金) 08:11:15
VC++のpchはそろそろ改善して欲しいけどな
まぁ2010の次のバージョンが全面改修らしいから、あるとしても遠い話か

しかし、>>676は明らかに何かを誤解してると思うんだが、どう誤解してるのかが
気になるなぁ
0695デフォルトの名無しさん2009/09/04(金) 11:22:49
>>694
勘違いというか、あれで内部的にpimpl相当になって外部のクラスを
変更しても影響受けない素敵状態になってくれないかなぁという妄想みたいな。

誰か書いてたけどexcludeとか、class_ｅｘｔｅｒｎ見たいな方が適切だったと思う。
0696デフォルトの名無しさん2009/09/04(金) 11:43:44
外部のクラスってのが何を指してるのか分からんし、どう見てもpimplを何か変に
誤解してるようにしか見えないが…

クラスのサイズが分からないとインスタンスは生成できない
→privateメンバ変数すら全てヘッダ中で定義しなきゃならない
→ポインタの向こうの構造体にメンバ変数を全部隠せばいい

ってだけの話だぞpimplは。
もっと綺麗に分離する為に、普通はポインタの向こうに不完全型の実装クラスを
置いて、中身全部そっちに移して転送関数を書きまくる訳だけど。
0697デフォルトの名無しさん2009/09/04(金) 12:59:12
>>695は今すぐExceptional C++を穴が空くほど読むべき
0698デフォルトの名無しさん2009/09/04(金) 13:10:16
pimplしたくないからprivateメンバをヘッダ以外に追い出せる別な方法が欲しいって話なんだけどなぁ。
0699デフォルトの名無しさん2009/09/04(金) 13:15:19
>>698
別の方法と言うなら、空のインターフェースクラスと実装クラスに分ける方法があるじゃないか。
0700デフォルトの名無しさん2009/09/04(金) 13:28:30
>>698
>>673>>676は追い出せてないじゃんw

0701デフォルトの名無しさん2009/09/04(金) 13:31:36
ヘッダの問題はModules in C++がTRとして出て解決する予定になっている。
だから、同じ問題を解決するものは
意味論的にModuleより優れていない限り、考慮する価値も無い。
よってこのネタは終了。
0702デフォルトの名無しさん2009/09/04(金) 13:51:16
>>673>>676で追い出せると思ってる理由が分からんｗ
0703デフォルトの名無しさん2009/09/04(金) 14:04:05
>>702
いや、技術的にこれで追い出せる〜みたいな話じゃなく、
こんな書き方で追い出せるようにならないかなって妄想でｗ
0704デフォルトの名無しさん2009/09/04(金) 14:04:56
>>701
ヘッダ問題解決する予定があるなら、本当にどうでもいい話でした
0705デフォルトの名無しさん2009/09/04(金) 14:34:43
クラスを丸ごとpimpl化するのは面倒なので、クラス内に包含する一部のオブジェクトのメンバ変数をshared_ptr<>にしてる。
そうすれば一部だけでもヘッダーをcppに移せるからそこそこ効果がある。

0706デフォルトの名無しさん2009/09/04(金) 14:37:26
>>705 は中途半端。
対処としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。

http://pc12.2ch.net/test/read.cgi/tech/1221557484/182
これ思い出した。
0707デフォルトの名無しさん2009/09/04(金) 14:48:47
>>705
pimplじゃん
0708デフォルトの名無しさん2009/09/04(金) 14:55:31
やけくそ頻繁に参照されるメンバがあって、そこだけpimplから外に出したりすることはある
0709デフォルトの名無しさん2009/09/04(金) 14:59:32
>>707うん、メンバすべて丸ごとじゃなくて一部のメンバにpimpを適用。
すべてのメンバ関数で間接呼び出しさせる必要がない。.演算子を->にするだけでいい。

>>706中途半端なのはそうだけど、手間と効果の兼ね合いかな。
0710デフォルトの名無しさん2009/09/04(金) 15:08:23
初心者スレかよ。
0711デフォルトの名無しさん2009/09/04(金) 15:42:25
>>673から一気にアホな流れになったな
0712デフォルトの名無しさん2009/09/04(金) 16:02:28
汚染してしまってすまん
0713デフォルトの名無しさん2009/09/04(金) 16:06:46
これでもまだマシ、っていうのが世間におけるC++のレベルなんだろうな。

C++0xの言語側の実装状況は
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
みたいの見ればすぐ分かるし、ネタにもよくあがるけど、
ライブラリの方はどの程度ついてきているのだろう。
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x
見ると、constexprが無いのが結構響いてるっぽいなあ。

右辺値参照(というかMove Semantics)のライブラリ側の対応も大体済んだみたいだし、
そろそろ実用面でのベンチマークを見てみたいね。
0714デフォルトの名無しさん2009/09/04(金) 16:24:24
http://gcc.gnu.org/ml/libstdc++/2009-04/msg00116.html
によると、constexprの実装はGCC-4.5で入るのかな？
0715デフォルトの名無しさん2009/09/04(金) 16:24:32
ベンチマーク必要な変更はない。
0716デフォルトの名無しさん2009/09/04(金) 16:45:04
必要か不要かじゃなくてどの程度かを知りたいって話だろ・・・
0717デフォルトの名無しさん2009/09/04(金) 17:22:30
標準コンテナをvalue semanticsで使っているようなプログラムは
g++のコンパイラオプションに-std=c++0xを入れるだけでかなり早くなるかもしらんが、
そんなプログラムはあまり無いだろうなあ。
使っているとしてもstd::stringくらいか。
0718デフォルトの名無しさん2009/09/04(金) 17:50:15
コンテナにshared_ptrを突っ込んで使ってる人は自動的に速くなるだろうな。
アトミックオペレーションのコストって高いからなあ
0719デフォルトの名無しさん2009/09/04(金) 18:28:50
constexprて実装側で無く利用側で指定するようには出来なかったのかね
0720デフォルトの名無しさん2009/09/04(金) 18:33:54
>>719
例えばどんなメリットがあるん？
0721デフォルトの名無しさん2009/09/04(金) 19:05:21
デメリットや実装難度を見たいって話なんだから
メリットが判らん様な低脳は黙ってればいいと思うよ
0722デフォルトの名無しさん2009/09/04(金) 19:22:34
decludeと同じく何を意図しているのか分からんが、
案を出すなら構文と意味論の例を提示しろと。

定義は1回なのに対し、利用するところは無数にある。
その全ての箇所で指定するなんて、現実的じゃない。
明らかに、定義時に指定する方が合理的。

指定しないでもコンパイラがコンパイル時に判断すれば良いって？
D使えば良いんじゃない？
0723デフォルトの名無しさん2009/09/04(金) 19:39:06
>>719利用者側で指定するとはどういう意味かわからん
実装時にconstexprによってコンパイル時の評価が可能で且つ同じ引数に対して同じ定数が戻ることが
保証できるわけだろ。それで十分だと思われる。
0724デフォルトの名無しさん2009/09/04(金) 19:50:39
>>708
よけくそ頻繁ってどこの方言？
純粋に興味で知りたい
0725デフォルトの名無しさん2009/09/04(金) 19:56:32
やけくそ　と書いたところで頻繁の方が良いカナと思ったが、
どっちが良いかは全文を書いてから決めることにして、取り合えず
両方残したままにしたのが裏目にでて、消すのを忘れてたと読む。
0726デフォルトの名無しさん2009/09/04(金) 19:59:39
>>721
態度は悪いが良い指針
で、メリット何？
0727デフォルトの名無しさん2009/09/04(金) 20:06:55
constexprはコンパイル時定数として自然に使えることを目的としているんだから、
使用時に何か指定が要るっていう時点で問題外だろ……

「ぼくのかんがえたC++0xはスレ違い」の文言をテンプレに追加するべきだ
あと、「papers嫁」もだな
0728デフォルトの名無しさん2009/09/04(金) 21:27:25
http://d.hatena.ne.jp/faith_and_brave/20090902/1251879571#c
> この点をふまえて考えると、 std::list::size() でリンクをたどって
> 数える処理は「コンテナ内のオブジェクトに対する操作」ではないので、
> 計算量の要件が仮に定数時間とされても、実装を変更する必要は無いと
> 言えてしまいそうだったりします。

これ、どうなの？
これがほんとなら N2923 をまじめに考えてた委員会の人とかみんな
この点を見落としてるってこと？
0729デフォルトの名無しさん2009/09/04(金) 21:29:43
>>697
そんな本読む必要なし。
だから、その手の本を日本人がかけないんだよ。
0730デフォルトの名無しさん2009/09/04(金) 21:42:29
>>728 emptyが有れば十分たい
0731デフォルトの名無しさん2009/09/04(金) 21:44:46
連結リストに対してsize()なんかが必要になる時点で設計おかしいよな
0732デフォルトの名無しさん2009/09/04(金) 21:48:17
えー誰得？
0733デフォルトの名無しさん2009/09/04(金) 21:50:48
>>731
それを断言できるスキルがうらやましいです＾＾；；
もっと精進せねば＾＾
0734デフォルトの名無しさん2009/09/04(金) 22:17:56
>>728
そのコメントは嘘。

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13537
で問題にしているのはamortized constant timeかconstant timeかの違い。
GCCでの実装がamortized constant timeなのにStandardではconstant timeと
書いてあるから、これはGCCのバグだよね、と言うのが論旨。

結局、Standardで
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#139
と修正されているので、amortized constant time操作であるstd::deque::push_back()
はStandard通りの振る舞いということ。
0735デフォルトの名無しさん2009/09/04(金) 22:36:49
>>734
その解釈には無理が無いか？

もしそのとおりであれば、 gcc のバグ報告に対して 23.1/2 をあげる必要が
無かったはず。

それに、 defect 139 を挙げてるのは、報告者が vector の push_back に
言及してたからでしょ。 deque の push_back については最新のドラフトでも
constant time が要求されてるよ。
0736デフォルトの名無しさん2009/09/04(金) 22:59:02
>>735
無い。無理があるのは

You are talking about complexity in terms of the number of operations
performed on pointers to the contained objects.

の方だと思うぞ。そもそも、Standardでは

23.1.1
All of the complexity requirements in this Clause are stated solely in terms
of the number of operations on the contained objects. [ Example: the copy
constructor of type vector <vector<int> > has linear complexity, even though
the complexity of copying each contained vector<int> is itself linear. end
example ]

とわざわざ例を挙げて言っているように、ポインタ経由でアクセスしているか否かを
問題にしているわけではない。
最新のドラフトでは確かに"should have constant complexity"と書いてあるが、
そもそもDefect 139は "Status: TC Submitter: Andrew Koenig Date: 30 Mar 1999"
とあるように、確実に当時のStandardに反映されている。その後complexityに対する
委員会の見解が変わったか、エンバグしたかのどちらかだろう。
0737デフォルトの名無しさん2009/09/04(金) 23:16:42
>>736
誰もポインタ経由でアクセスしているか否かなんて問題にしてないよ。

問題なのはコンテナ内の要素に対する操作か否か。
list の size で要素を数え上げる処理は明らかに違うでしょ。

あと、 deque の push_back の要件は defect 139 で修正された
Optional sequence operations じゃなくて、 23.2.1.3 [lib.deque.modifiers] に
別途記載されている。最新のドラフトだと 23.3.2.3 ね。
> Inserting a single element either at the beginning or end of a deque always
> takes constant time and causes a single call to a constructor of T.

やっぱりおかしいよ。
0738デフォルトの名無しさん2009/09/04(金) 23:31:13
>>736
"should have constant complexity" って、どこ見てるの？

defect 139 で修正された Optional sequence operations についての記述では
2003 の時点でも最新のドラフトでも
"shall implement them so as to take amortized constant time" って書いてあるよ。

まぁ、もう元の話とは関係ないんだけどね。
0739デフォルトの名無しさん2009/09/05(土) 00:38:32
>>737
そもそもGCCのバグ報告を持ち出したのは、ポインタ経由での要素へのアクセスは
オブジェクトへのアクセスでは無いからcomplexityに影響しないということだと
思うが。

> 問題なのはコンテナ内の要素に対する操作か否か。
> list の size で要素を数え上げる処理は明らかに違うでしょ。
その認識が合っているとは思えない。list::reverse()のcomplexityはlinear time
だとStandardにあるが、これはlist::size()同様にリンクポインタをいじることで
実現可能。もしリストのリンクを辿ることが"operations on the contained objects"
でないのなら、list::reverse()のcomplexityも当然constant timeと書くと思うが。

こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
誤解をしているとも思えない。
0740デフォルトの名無しさん2009/09/05(土) 00:46:04
>>738
> "should have constant complexity" って、どこ見てるの？
これは間違いだった。General container requirementsのsize()について見ていた。

> defect 139 で修正された Optional sequence operations についての記述では
> 2003 の時点でも最新のドラフトでも
> "shall implement them so as to take amortized constant time" って書いてあるよ
見落としていたが、確認した。
0741デフォルトの名無しさん2009/09/05(土) 00:57:07
>>739
gcc のバグ報告ちゃんと読んでる？
ポインタ経由での要素へのアクセスなんてどこにもでてきてないはずなんだけど。
問題になってるのは deque 内に持ってるポインタ配列の再確保とコピーね。

> こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
> 誤解をしているとも思えない。

みんなそう思ってるんだけど、事実は矛盾が発生しているようだという話ね。

list のリンク操作は "operations on the contained objects" であって
deque のポインタ配列操作はそうではない、というのはおかしい。

元々の意図はそうなんだろうとは思うけど、それが 23.1/2 の記述が甘いせいで
おかしくなっている、と。
0742デフォルトの名無しさん2009/09/05(土) 01:09:31
>>741
正しくはポインタへのアクセスだったな。まあそのくらい補完してくれよ。

で、お前さんの立場は何なの？
list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
書くべきだという意見？

自分は、こんな大事に気づかずに放置するわけが無くて、deque::push_back()の
complexityをamortized O(1)と書くべきという意見。
amortized complexityを良く理解していない人は結構多い上に、defect 139に
あるように実際同様のバグがあったこと、こちらの方が可能性が高いと考える。
0743デフォルトの名無しさん2009/09/05(土) 01:09:40
調べてみると、こんなのが出てきた。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0937R1.asc
ここの Issue Number 20-036 で問題の 23.1 p2 の追加が行われている。

これが "10 July 1996" とあるので、おそらく list の計算量要求なんかはそれ以前から
あったもので、操作全体の時間について言っていたのがそのままになってる可能性が高い。

N2923 も含めて、 list のリンク操作はあきらかに計算量に含まれる想定で書かれている
ので、 23.1 p2 の文面を現状に合うように修正するべきなんじゃないかと思う。

そうすると、 deque の push_back に対する要求は amortized constant に合わせて修正
しないといけなくなりそう。ただし、これは制限を緩めるものなので、現状の実装を変更する
必要は生じないはず。
0744デフォルトの名無しさん2009/09/05(土) 01:29:39
>>742
> で、お前さんの立場は何なの？
> list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
> 書くべきだという意見？

そうするか、 >>743 のとおり 23.1/2 のほうを直すか、とにかく矛盾を直すべき
だとは思う。

>>743 のほうが自然だし、楽だね。
0745デフォルトの名無しさん2009/09/05(土) 01:32:24
>>743
なるほど。確かにそういう事になるだろうな。そうすれば>>728や>>735>>737
のようなおかしな解釈をする輩がいなくなる。

そもそもコンテナ内の要素数に依存するような操作をしているのにポインタへの
アクセスは関係ない、なんて言い出したらcomplexityを明示することが無意味に
なってしまう。
0746デフォルトの名無しさん2009/09/05(土) 02:15:43
どちらかというと「標準委員会が矛盾に気づかないわけがない」なんて
思い込んでるほうがおかしいだろ。
0747デフォルトの名無しさん2009/09/05(土) 02:48:46
>>746
見苦しいぞ
07487462009/09/05(土) 03:01:16
へ？なんで？意味がわからない。
0749デフォルトの名無しさん2009/09/05(土) 09:28:43
>>746
おまいは>>728から100回読み直してこい
0750デフォルトの名無しさん2009/09/05(土) 13:05:38
どっちがおかしいよかよくわかってない美少女中学生もお忘れなく
0751デフォルトの名無しさん2009/09/05(土) 15:48:55
規格の文面をまじめに読むと、どっちの解釈が「おかしい」とも言い切れない状態に
なってるのが問題。
0752デフォルトの名無しさん2009/09/05(土) 15:56:27
ここでいう「どっち」は >>728 と >>743 の２つね。（ >>745-746 は敢えてスルー）
728 は deque::push_back の（計算量）要求は正しくて list::size() の要求は無意味。
743 は list::size() の要求には意味があって deque::push_back の要求は間違ってる。
0753デフォルトの名無しさん2009/09/06(日) 12:29:21
23.1.1 の記述を問題にしてる人は、具体的にどう直せば厳密になると思う？

俺はまともに書き下せる気がしないので、
「今の文面を、常識的に考えて意図したいであろう意味と解釈して読め」
が現実的だと思うんだけど。
0754デフォルトの名無しさん2009/09/06(日) 13:04:37
計算量とか「実装の質」で切り捨てたらあかんの？
なんか言語の規格で決める事じゃないような気がする
0755デフォルトの名無しさん2009/09/06(日) 13:13:12
>>754
それはさすがに認識のレベルが出発点にすら立ってない
0756デフォルトの名無しさん2009/09/06(日) 15:01:14
>>754
ループの中で計算量nの関数を使ったら酷い事になるでしょう。
計算量をを明らかにすればvectorとlistのどちらを使うか簡単に選べられる。
sizeも現実的な計算量を規格で定めてもらえば十分なはずなんだけど・・・
0757デフォルトの名無しさん2009/09/06(日) 15:10:23
>>753
「コンテナ内のオブジェクトに対する操作はすべて定数時間で済むと仮定した場合の
計算時間について言及している。（例: vector<vector<int>> は（以下略）」
とか？

この場合は deque::puach_back は償却定数時間に格下げね。

現状の deque::push_back の要求をそのままにしながら list の計算量を意味のある
ものにするような記述は不可能なように思う。
07587572009/09/06(日) 15:14:03
この案で言う「コンテナ内のオブジェクトに対する操作」は単一要素に対する
コンストラクタ・デストラクタ・コピー・移動あたりね。明記しておいたほうがいいかも。
0759デフォルトの名無しさん2009/09/06(日) 15:22:19
>>758
それは>>736にあるように具体例付きで明記されてる。
0760デフォルトの名無しさん2009/09/06(日) 15:23:29
お、日本 WG の人が動き出してんのかな？

まじめに規格の文面に仕上げようと考えてるなら 2ch でやるのは不適切じゃないか？
著作権関係とか。
0761デフォルトの名無しさん2009/09/06(日) 15:29:58
規格については、deque::push_back()を計算量要求をamortized constant time
と変更するだけで良い。
>>728や>>737は「わざわざ」曲解して釣っただけ。
0762デフォルトの名無しさん2009/09/06(日) 15:30:58
>>760
まさか。WGが2ちゃんを参考にしてるとしたらアホだ。
0763デフォルトの名無しさん2009/09/06(日) 15:38:14
>>761
それって、 deque のポインタテーブル操作も list のリンク操作も
"operations on the contained objects" だと強弁するの？
無理じゃね？
0764デフォルトの名無しさん2009/09/06(日) 15:40:20
>>763
馬鹿か？
>>728から>>743までを読み直せ
0765デフォルトの名無しさん2009/09/06(日) 15:43:30
>>764
自分が馬鹿じゃないと思うなら deque のポインタテーブル操作も list のリンク操作も
"operations on the contained objects" だと言える根拠を示してよ。

それとも、「標準委員会が矛盾に気づかないわけがない」っていうのが根拠なの？
0766デフォルトの名無しさん2009/09/06(日) 15:46:29
お前が先に変な事を言い出したのだから、お前がまず根拠を示せ
0767デフォルトの名無しさん2009/09/06(日) 15:52:35
>>766
"the contained objects" って言ったら deque<T>, list<T> についての T のことで、
deque<T> 実装内のポインタテーブルの操作や list<T> 実装内のリンクをたどったり
つなぎ変えたりする操作は T に対する操作ではない。
つまり "operations on the contained objects" ではない。
0768デフォルトの名無しさん2009/09/06(日) 16:06:16
the contained objects としか書いてないんだから
あるコンテナに含まれているもの全て（実装詳細も含む）だろう

例えば、list<T>::size() は T に一切タッチしない（リンクセルをたどるだけ）ので
O(1)-time ってことになるのか？
そんな訳の分からない計算で求められた時間計算量が実際のプログラミングで何の役に立つの？
0769デフォルトの名無しさん2009/09/06(日) 16:12:21
>>763や>>767は今までのレスを読んだ上でそんなことを言ってるのか？

>>767
根拠は、list::size()やlist::reverse()をO(1)とした場合、実装者にとっても
ユーザーにとっても計算量が全く意味をなさなくなるから。
意味があるというなら、その根拠を示してくれ。

そこまで強弁したいなら、さっさとペーパー書いてWG21に送り、ここにも晒せ。
どうせ笑われて終わるだろうが。
0770デフォルトの名無しさん2009/09/06(日) 16:12:30
>>768
それだと続く vector <vector<int> > の例で vector<int> 自体の計算量が無視されてる
理由にならないでしょ。
0771デフォルトの名無しさん2009/09/06(日) 16:18:50
>>770
おまいは一体何を主張したいの？反論したいだけじゃないの？
違うのなら>>753の言うように23.1.1の文面の改正案を出してくれよ
0772デフォルトの名無しさん2009/09/06(日) 16:23:06
規格なんだから論文と同じかそれ以上の厳格さ，正確さが必要だと思う．
こういう議論が起こる時点で曖昧であることは自明なのだから，
何とかして意図した意味にしか取れないように修正するべきことは確か．
0773デフォルトの名無しさん2009/09/06(日) 16:24:08
>>771
苦しくなったら話そらすのやめなよ。見苦しい。
07747712009/09/06(日) 16:29:42
>>773
俺は>>768じゃないから、的外れな事言うなよ。何も苦しくないぞw
いいから>>771に答えてよ
0775デフォルトの名無しさん2009/09/06(日) 16:31:01
>>771 >>728
0776デフォルトの名無しさん2009/09/06(日) 16:34:27
>>771 >>757

ちなみに、 23.1.1 じゃなくて 23.1 paragraph 2 な。最新のドラフトでは 23.2.1 p2 。
07777712009/09/06(日) 16:36:19
>>775
それは改正案ではないから答えになってない
0778デフォルトの名無しさん2009/09/06(日) 16:37:48
こんなところでグダグダ言い合ったって
標準には何一つ反映されないんだからもうやめろよ
0779デフォルトの名無しさん2009/09/06(日) 16:42:06
ちょっと前の流れよりはよほどマシだから、良いぞもっとやれ
でも出来れば美少女中学生にも分かるように話してほしい
07807712009/09/06(日) 16:57:47
>>776
おまいは>>767=>>770か？分かりにくいからコテつけてくれ
0781デフォルトの名無しさん2009/09/06(日) 16:58:16
どうせここにいる誰にも改正案なんて出せないんだ
07827632009/09/06(日) 17:02:15
スマンカッタ。実は >>763=>>767=>>770=>>775=>>776 だ。
0783デフォルトの名無しさん2009/09/06(日) 17:10:07
以上、本日の釣りでした
0784デフォルトの名無しさん2009/09/06(日) 17:20:14
議論に割って入ろうと思ったが英語に苦戦している間に終息したでござるの巻
0785デフォルトの名無しさん2009/09/06(日) 17:32:48
2chにはせいぜいautoマンセーと0b論争がお似合い
0786デフォルトの名無しさん2009/09/06(日) 18:10:18
>785
namespace の階層化のことも思い出してください
0787デフォルトの名無しさん2009/09/06(日) 18:13:35
progress_displayがTRに入りたそうにこちらを見ている
0788デフォルトの名無しさん2009/09/06(日) 18:47:25
こっちみんな
0789デフォルトの名無しさん2009/09/07(月) 14:19:08
>>785
lambdaの文法きもくね？が抜けてるぞ
0790デフォルトの名無しさん2009/09/07(月) 14:22:34
lambdaの文法気に入ってる俺はどうすれば
0791デフォルトの名無しさん2009/09/07(月) 18:18:19
俺は慣れてきた
文法は別にこれでいい

それよりラムダテンプレートを作れるようにしてほしい
(最新のドラフトだと作れるようになってる？)
0792デフォルトの名無しさん2009/09/07(月) 18:44:49
ラムダは->intがどうしても許せない
戻り値の型は左でいいじゃん
0793デフォルトの名無しさん2009/09/07(月) 19:03:13
>>792
戻り値を右側に置くと、引数の型から戻り値を決定するのが書きやすい。
template <class T, class U>
auto add(T t, U u) -> decltype(t + u)
{
return t + u;
}
ラムダもそれを意識しているはずで、
791も言っている多相的なラムダへの布石の1つに違いない。
0794デフォルトの名無しさん2009/09/07(月) 19:08:16
らむだなんか、メンテナンスせいがおちるから、利用禁止だ。
0795デフォルトの名無しさん2009/09/07(月) 19:47:10
一度しか使わない関数オブジェクトを作るのがメンテナンスせいが高いとも思えんのだ。
Boostのlambdaとかphoenixだったらまあ、利用禁止になっても仕方ない。
0796デフォルトの名無しさん2009/09/07(月) 20:04:07
ラムダさんをいじめるなッ！
0797デフォルトの名無しさん2009/09/07(月) 20:15:15
船団は一番進むのが遅い船に合わせろ
だが次の出航では港に置いていけ
0798うちラムだっちゃ2009/09/07(月) 20:16:36
そうだそうだ
0799デフォルトの名無しさん2009/09/07(月) 22:32:50
関数の中で一時関数を定義できればいいのにね。
例えばこんな感じ。

void function( int n ) {
　int inner_function( int n ) {
　　return n * 2;
　}
　cout << inner_function( n );
}
0800デフォルトの名無しさん2009/09/07(月) 22:39:31
もうすぐできるようになるよ！

多分
0801デフォルトの名無しさん2009/09/07(月) 22:41:47
>>799

void function( int n ) {
　struct {
　　int operator()(int n) { return n * 2; }
　} inner_function;
　cout << inner_function(n);
}
0802デフォルトの名無しさん2009/09/07(月) 22:45:59
ついでに >>801 の続き：

http://codepad.org/oQxIIZXH
http://codepad.org/i53WLBID
0803デフォルトの名無しさん2009/09/07(月) 22:49:18
>>802
2個目

警告 W8105 inner_function2.cpp 11: <定数> メンバ ' ::x' があるクラスにコンストラクタがない (関数 main() )
警告 W8105 inner_function2.cpp 19: リファレンス メンバ ' ::v' があるクラスにコンストラクタがない (関数 main() )
警告 W8105 inner_function2.cpp 34: リファレンス メンバ ' ::v' があるクラスにコンストラクタがない (関数 main() )
0804デフォルトの名無しさん2009/09/07(月) 23:09:13
無名クラスにコンストラクタがないといわれても、ご無体な。
0805デフォルトの名無しさん2009/09/07(月) 23:15:46
そうか
ちなみにgcc4.4.0では通る

という事はbccの最新版ecc6.2.0のバグか
0806うちラムだっちゃ2009/09/07(月) 23:20:30
>>799 lambda関数に任せるっちゃ
0807デフォルトの名無しさん2009/09/07(月) 23:24:08
うわっgcc4.4.1が出てる
今から入れよう
しかしbccは使えんのう
0808デフォルトの名無しさん2009/09/08(火) 02:33:20
BCC使う理由が分からん
すっぽすっぽみたいにコンパイラオタとかか？
0809デフォルトの名無しさん2009/09/08(火) 08:31:42
らむだなんか、素人エンジニアが学生程度の奴しか歓迎しないだろ。
0810デフォルトの名無しさん2009/09/08(火) 09:26:16
ラムダ便利じゃん
0811デフォルトの名無しさん2009/09/08(火) 11:29:31
lambdaが空気みたいになってる言語ばかり利用していると
lambdaがない言語では窒息死しそうになるんだYohhhh
0812デフォルトの名無しさん2009/09/08(火) 11:47:14
lambdaの使い道が分からないのは老害
0813デフォルトの名無しさん2009/09/08(火) 12:06:25
lambdaがあるとないとではalgorithmの関数テンプレートの使い勝手が全然違う
0814デフォルトの名無しさん2009/09/08(火) 15:46:16
>>813
でもなー
vector<複雑な型>::iterator みたいな型だと
　for_each(v.begin(), v.end(), [](decltype(v.begin()) it) { 処理 });
みたいに書くのはちと微妙というか

まあこの場合は
　for (auto it : v) { 処理 }
でいいのかもしれんけど
0815デフォルトの名無しさん2009/09/08(火) 16:34:00
>>814
標準アルゴリズムで関数にイテレータが渡されるものなんてあったっけ？
0816デフォルトの名無しさん2009/09/08(火) 16:39:47
>>815
配列舐めて処理する系はbeginとendつかわないかい？
0817デフォルトの名無しさん2009/09/08(火) 16:44:56
>>808
dmcを使う漏れはどうすれば…
0818デフォルトの名無しさん2009/09/08(火) 16:55:00
関数オブジェクトに渡されるのはイテレータじゃなくて参照なのだから、
[](reference_type<typeof(v)>::type x) { ... }
みたいになるんじゃね？とかそういう話だと思った
08198162009/09/08(火) 17:02:04
>>818
あぁ、関数オブジェクトに。か。
そこまで読めてなかった。すまん。
0820デフォルトの名無しさん2009/09/08(火) 19:32:29
ほんとにここC++0xのスレか？

統一関数文法のペーパーはまだ生きていて、フランクフルト後も更新されてるぞ。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2931.html

しかも、一度消されたはずのnamed lambdaが復活している。
0821デフォルトの名無しさん2009/09/08(火) 20:05:07
autoか[]かの自転車置き場の議論がいつの間にかとんでもないことになってるからな
勘弁して欲しい
0822デフォルトの名無しさん2009/09/08(火) 20:07:58
だがそれがいい
0823デフォルトの名無しさん2009/09/08(火) 20:24:00
両方で
0824デフォルトの名無しさん2009/09/09(水) 00:29:17
[]foo() -> decltype(foo)

きもい
0825デフォルトの名無しさん2009/09/09(水) 06:24:48
どっちでも使えればいいよ
0826デフォルトの名無しさん2009/09/09(水) 09:22:55
このスレじゃあまり話題にならないけど、
世間一般的にはC++0xの一番の強みってConcurrencyだよね
0827デフォルトの名無しさん2009/09/09(水) 09:43:08
>>826
そうかな？

標準規格化されることで、今までプラットフォームべったりだったプログラムを
移植可能な形で書くことができるようになるんだろうけど、わざわざ既存のコードを
書き直すモチベーションがあることは少ないだろうし、新しく書くとしても使うライブラリが
違うだけって感じで、 C++0x になったから楽になるような部分はあんまり無いような
気がする。

具体的にたとえば何が「強み」なの？
0828デフォルトの名無しさん2009/09/09(水) 09:54:35
そもそも普通の意味の「世間一般」が使う言語じゃなくなってる訳で、何をもって
世間一般とするか次第
0829デフォルトの名無しさん2009/09/09(水) 10:03:13
boost communityを世間一般にしようぜ
0830デフォルトの名無しさん2009/09/09(水) 10:45:09
Memory Modelから規定してAtomicとかMemory Fenceみたいな粒度が細かい操作を
移植性が高い方法で書けるようになった。
Concurrencyサポート無くてはOSのAPIとか使ってもまともに動く保証は無かったわけで
システムプログラミング用の言語としては大きな進歩だよ。
0831デフォルトの名無しさん2009/09/09(水) 11:05:58
いや移植性はともかくOSのAPIを使えばまともに動くってｗ
0832デフォルトの名無しさん2009/09/09(水) 11:19:03
>>827
クラスライブラリ開発者が楽になれば、
いいライブラリが増えるって感じかねえ。
0833デフォルトの名無しさん2009/09/09(水) 12:09:58
thread, mutexその他諸々のクラスの再発明が止まるだけでも十分だわ
0834デフォルトの名無しさん2009/09/09(水) 12:12:35
OSのAPIを使って、高レベルの同期系ユーティリティ作る時も、
やっぱり今回の規格がある方が便利。
問題は追従するコンパイラがどの程度かって事。
特にVC++はmemory modelの追従がかなり遅い可能性がある。
0835デフォルトの名無しさん2009/09/09(水) 16:13:58
並列処理に力入れてるICCなら準拠してくれると信じてる
0836デフォルトの名無しさん2009/09/09(水) 18:36:50
restrictポインタは入るの？
0837デフォルトの名無しさん2009/09/09(水) 18:37:28
入るわけがない
0838デフォルトの名無しさん2009/09/09(水) 18:46:33
もうC99のコードをC++0xに移植する作業は嫌だお…
0839デフォルトの名無しさん2009/09/09(水) 21:07:29
宿題とえっちな遊びの並列処理ができずに結局宿題をほっぽり出す美少女中学生
0840デフォルトの名無しさん2009/09/09(水) 21:27:24
いい加減6スレ目だけどそのネタつまらない事に気付け。
0841デフォルトの名無しさん2009/09/09(水) 21:28:36
VCなら__restrictを入れてくれると思うのでそれで我慢しろ
というかベクトル化をしたいならIntel C++コンパイラにしろ
0842デフォルトの名無しさん2009/09/09(水) 21:31:22
金がないというかあんな糞コンパイラ使いたくない。
0843デフォルトの名無しさん2009/09/09(水) 21:36:41
FORTRAN並みの速度を出したいんじゃないのか
0844デフォルトの名無しさん2009/09/10(木) 09:03:50
>restrictポインタ
どうしてC++0xに入れないんだろう。
最適化の邪魔になってるはずなのに。
0845デフォルトの名無しさん2009/09/10(木) 11:42:40
D&E の 6.5.2 で restrict について詳しく書かれています。
0846デフォルトの名無しさん2009/09/10(木) 13:05:32
>>845
かいつまんで教えてくだちい。
0847デフォルトの名無しさん2009/09/10(木) 13:42:52
>>846
お前さんがD&Eを買わなくなるといけないのであまり詳しくは
教えないが、FORTRANに比べてrestrictポインタは速度を
向上させる反面犠牲が大きすぎるんだと

C/C++ではポインタや参照を多用するので危険が増すので
FORTRANやアセンブラなどの代替手段に当分頼れだってさ
0848デフォルトの名無しさん2009/09/10(木) 13:50:55
未来を語るなら過去を知るべき、ってことでD&Eはこのスレでは必携だよね。

わざわざundefined behaviorになる原因増やすくらいなら、
今ならGPGPUとかuBLAS使えよ、ってことで。
0849デフォルトの名無しさん2009/09/10(木) 18:23:50
“図書館で2回借りて読んだけど”、これを超える本がまだ無いんですね。
何章何節でストラウストラップが何を言ったか暗唱できるようにとか
言語機能のストラウストラップコレクションを絶対視するとか
まじついていけない。
0850デフォルトの名無しさん2009/09/10(木) 18:26:50
C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す（1/3）：CodeZine
ttp://codezine.jp/article/detail/4035
08518462009/09/10(木) 18:33:43
>>847
どもあり。

理屈はわからないでもないけど、すでに
C99にはあるものなのにな。ｗ

個人的な感覚だと、未定義動作のヤバさ
加減は非volatileとあんまりかわらない。
とはちょっと言い過ぎか。
0852デフォルトの名無しさん2009/09/10(木) 18:40:56
>>850
にわか者だけどすごいなこれ。
Javascript大好き人間なんだが、大分近くなってきたな。
しかもネーティブで。

ワクテカ！
0853デフォルトの名無しさん2009/09/10(木) 18:45:14
いまどきlambda程度で喜んでるのかよ。
0854デフォルトの名無しさん2009/09/10(木) 18:57:14
それだけC++が時代遅れって事さ
0855デフォルトの名無しさん2009/09/10(木) 19:00:24
ゼロ・オーバーヘッドでこれだけやってる時点で十分フロンティアだろ
0856デフォルトの名無しさん2009/09/10(木) 19:03:48
でもlambdaは無かった訳で
0857デフォルトの名無しさん2009/09/10(木) 20:17:54
ラムダ式ならC#3.0やってれば知ってるはずだろ
LINQも強力だぞ
スレチだが
0858デフォルトの名無しさん2009/09/10(木) 20:45:43
>>851
こっちの問題の方が大きい

restrict shared_ptr<Hoge>
0859デフォルトの名無しさん2009/09/10(木) 22:02:19
>>849
> 何章何節でストラウストラップが何を言ったか暗唱できるようにとか

お前は内容を理解できないから、後から思い出すことができないんだよ、
restrictについてどういうことが述べられていたか。
0860デフォルトの名無しさん2009/09/11(金) 07:47:20
>>851 危険度の割りにrestrictにどれほどの効果があるか分からないし。効果の分かるサンプルが欲しいな。
volatileはより安全な方向だし
0861デフォルトの名無しさん2009/09/11(金) 07:55:07
>>860
http://seclan.dll.jp/c99d/c99d07.htm#dt19991018
0862デフォルトの名無しさん2009/09/11(金) 08:52:31
>>861をC++で試してみた。インライン展開させればrestrictがなくても自動判別するようだ。
void sumup(int n, int * /*restrict*/ array1,/*restrict*/ int * array2)
{
//　　assert((n % 4)== 0);
for(int i = 0; i < n; i++) array1[i] += array2[i];
}

int a[100];
int b[100];

int _tmain(int argc, _TCHAR* argv[])
{
sumup(100,a,a); //VC8 アンロールされない ICC11 アンロールされない
sumup(100,a,b); //VC8 ５個にアンロールされる ICC11 paddに展開される。
sumup(99,a,b); //VC8 ３個にアンロールされる ICC11 端数分以外はpaddに展開される。
return 0;
}
0863デフォルトの名無しさん2009/09/11(金) 09:06:18
C99の規格上もコンパイラは無視してよい、って書いてあるし
各処理系の独自拡張で十分なんじゃないかな。
採択されなかった、ってことはコンパイラ屋もライブラリ屋も標準C++には要らない
って判断したからだよね。
時期尚早な最適化でなくて実際に必要としている人は居るのかね。

コンパイラへのヒントにすぎないって点だとinlineも似たようなものだけど。
0864デフォルトの名無しさん2009/09/11(金) 09:23:27
>>862少し間違えた
×　sumup(100,a,a); //VC8 アンロールされない ICC11 アンロールされない
○　sumup(100,a,a); //VC8 アンロールされない ICC11 paddに展開される。
0865デフォルトの名無しさん2009/09/11(金) 11:20:48
>>863 確かにベクトル化並列化に強いコンパイラはもっと細かい指定が欲しいし、
それらは言語の規格とは別で独自拡張で詳細なほうがいいね。
OpenMPなんか対応コンパイラと非対応コンパイラで同じコードが使えるのはすごいね。

0866デフォルトの名無しさん2009/09/11(金) 12:32:10
現状ではVCみたいな __restrict キーワードでいいわけか
C++0xも
0867デフォルトの名無しさん2009/09/11(金) 18:03:45
ただでさえカオスなC++の型規則にこれ以上余計なもの入れるなってのが本音だろう
Cみたいに「CV修飾子に新しい仲間が増えました^^」の一文加えるだけじゃ済まないもん
0868デフォルトの名無しさん2009/09/11(金) 18:05:51
逆に、今更このくらいの追加でガタガタ言うな、って気もする
0869デフォルトの名無しさん2009/09/11(金) 18:24:32
>>862
BCC6.2.0だとアンロールされない
さすが最適化に関しては糞だ

でもrestrictポインタに限って言えば、XMMレジスタを
使わずかつループ回数が多い場合はあまり意味がないね

アンロールはしてもらわないとFPUを使う時に特にレイテンシが
大きくなる

まあ複雑に絡んだ問題だな
0870デフォルトの名無しさん2009/09/11(金) 18:27:44
>>852
メンテナンス性では退化だよ。
なんだよ、Javaスクリプト大好きって。
0871デフォルトの名無しさん2009/09/11(金) 18:28:21
>>863
独自拡張でいいといってしまえば
標準規格の意味がない。

どうせコンパイラ依存なんだから、とにかく
つるっと含めちまえよ、とは思う。

＞Cみたいに「CV修飾子に新しい仲間が増えました^^」の一文加えるだけじゃ済まないもん
CV修飾子というよりは、register系だろ。
エイリアスの不安はわかるけど、
型システムに影響があるか？
0872デフォルトの名無しさん2009/09/11(金) 18:29:58
最大化の最適化を使って製品をリリースしている奴がいないように、コンパイルのオプションで潰されそうな機能だな。
0873デフォルトの名無しさん2009/09/11(金) 19:01:57
>>871
restrict * restrict *intとか出来ないといけないからregister系じゃないぞ
C99でも「型修飾子」としてconst,volatileと一緒に括られてる
08748712009/09/11(金) 19:11:20
>>873
そういうつもりじゃなくて、値渡しした
ときに性質が伝播しないって意味。
あれ、ひょっとして、伝播するんだっけ？
0875デフォルトの名無しさん2009/09/11(金) 22:02:25
仕様は知らんが、ポインタに付いたrestrict性質は値渡ししても伝播するというのが自然だな。
0876デフォルトの名無しさん2009/09/11(金) 22:36:37
restrictはconstのように伝播しながら安全性を増すようにできないかな？
例えば、無名（右辺値？）の複製しかできないとかにして、関数の引数で渡せるが他の変数に代入できないことでエイリアスがないことを保障するとかかな。
0877デフォルトの名無しさん2009/09/11(金) 23:48:15
volatileは外部世界とのやりとり(メモリマップドI/O)の関係もあって、
コンパイラの中で自己完結できず、取り入れざるを得ない。
restrictについてはコンパイラが頑張れば必要ない。だから入れない。
この辺の事情はnoalias修飾子に良く似ている。
0878デフォルトの名無しさん2009/09/12(土) 00:05:38
ポインタ周りの最適化は極めて困難なんじゃなかったのか？
0879デフォルトの名無しさん2009/09/12(土) 00:07:31
volatileって役立たずだったような。
メモリバリアやatomicの方がよっぽど必要。
0880デフォルトの名無しさん2009/09/12(土) 00:16:41
メモリ直接叩く時にvolatile付けないのは自殺行為だぞ
0881デフォルトの名無しさん2009/09/12(土) 00:54:48
volatileはマルチスレッドプログラミングでは必須だぞ
付けないと最適化で式そのものが消えてしまったり原因不明で
何日も悩む事になる
0882デフォルトの名無しさん2009/09/12(土) 00:59:51
>>881
釣りはよそでやれ
0883デフォルトの名無しさん2009/09/12(土) 01:06:22
JavaやC#のvolatileとC/C++のvolatileは
CとC++0xのauto以上に別物
0884デフォルトの名無しさん2009/09/12(土) 01:55:23
だからmutexなんかで挟んでアトミックにする時は大抵フラグは
メモリ上に取るだろ

それがvolatile付けないとレジスタ変数で処理されてしまったりして
？？？な動作するんだよ
0885デフォルトの名無しさん2009/09/12(土) 02:03:13
役に立たないのはアレだ、volatile付けたクラス
0886デフォルトの名無しさん2009/09/12(土) 02:04:28
最適化を有効にしてデバッグする人がいると聞いて
0887デフォルトの名無しさん2009/09/12(土) 02:18:11
最適化有効でリリースするなら有効でテストするに決まってる
0888デフォルトの名無しさん2009/09/12(土) 02:33:58
>>883の言うように残念ながらC/C++のvolatileはマルチスレッドには役立たない。
ttp://www.lambdacs.com/cpt/FAQ.html#Q56
ttp://d.hatena.ne.jp/yupo5656/20040618/p2

ただし例外として、VC++は独自仕様としてメモリバリアを形成するので、マルチスレッド対策にも使える。
ttp://msdn.microsoft.com/en-us/library/12a04hfd.aspx
そうなったのは2005から。
ttp://msdn.microsoft.com/ja-jp/library/bb310595.aspx
0889デフォルトの名無しさん2009/09/12(土) 02:40:52
>>888
盲点だった
mutexだけで十分か
0890デフォルトの名無しさん2009/09/12(土) 02:57:33
盲点？
最初から「マルチスレッドのために volatile 使う」なんて話がまったくの迷信だっただけのこと。
せっかく正しい認識が広まりかけてたところに VC++ の独自仕様がさらなる混乱を持ち込みやがった。
0891デフォルトの名無しさん2009/09/12(土) 03:18:38
volatile は割り込み処理で書き換えられた変数が、その後のアクセスで
取得できる事を保証するもんだと認識している。
0892デフォルトの名無しさん2009/09/12(土) 07:25:51
つーかC/C++のvolatileがマルチスレッドの排他に有効というのも勘違いだが（VC8-は別）、
volatileが何の意味もない役立たずな修飾ってのもまた勘違い

volatileってそんな難しいもんかねぇ…
0893デフォルトの名無しさん2009/09/12(土) 08:11:28
>>889
盲点じゃなくてFAQですよ。
0894デフォルトの名無しさん2009/09/12(土) 08:16:14
>>891
volatileの意味は1.9 program executionに書いてあるので、
その通りに理解するのがいいと思いますよ。
0895デフォルトの名無しさん2009/09/12(土) 08:34:22
おっぱいのサイズがvolatileな美少女中学生
0896デフォルトの名無しさん2009/09/12(土) 10:18:11
>>891
http://mkosaki.blog46.fc2.com/blog-entry-91.html
３．メモリ引数命令を使うことは保障されない
0897デフォルトの名無しさん2009/09/12(土) 10:21:48
>>896
その記事は「メモリオペランドのx86命令を生成することを保証しない」の意味で
書かれてる訳だが、何か>>891に関係あるのか？
0898デフォルトの名無しさん2009/09/12(土) 10:32:28
割り込み処理前に読み込み割り込み処理後に書き込むケースを避けるため、>>891のように使う場合は割り込み以外の部分では書き戻ししないように注意しろってこと言いたいんじゃね?
0899デフォルトの名無しさん2009/09/12(土) 10:43:51
いや、単純に「read-modify-write命令を使いません」ってだけだろ？
別にアトミックな命令ですら無いし、その記事のその項目自体がほぼ無意味な気も
するんだが
0900デフォルトの名無しさん2009/09/12(土) 11:17:31
volataileは最適化が抑制されるから、プログラムに書いてる通りに実行しますよってことでしょ。
でもこれは、言語レベルでマルチプロセッサ間の排他処理とは無関係。
プロセッサ間の排他処理にmutexやクリティカルセクションを使えばプロセッサの
アトミック命令が使われるのでメモリバリアが施されるってこと。

vc8 releaseでの逆アセンブル。

volatile int vola;
int nvola;
int _tmain(int argc, _TCHAR* argv[])
{
vola=argc;
00401000 mov eax,dword ptr [esp+4]
00401004 mov dword ptr [vola (403378h)],eax
nvola=vola; //volaは読み直されている。
00401009 mov ecx,dword ptr [vola (403378h)]
0040100F mov dword ptr [nvola (403374h)],ecx
return nvola;//nvolaは読み直されていない。
00401015 mov eax,ecx
}
00401017 ret
0901デフォルトの名無しさん2009/09/12(土) 11:17:59
マルチコアやHTのあるCPUだと意味ないな。
シングルコア/HT無しの場合には意味はあるかもな。uopsの途中で割り込みに処理移ることやそういうcpuってあったけか。
0902デフォルトの名無しさん2009/09/12(土) 11:19:50
>>901は>>899宛
0903デフォルトの名無しさん2009/09/12(土) 11:24:02
volatileは淡々と最適化を抑制するだけです。
過度な期待はしないでください。
0904デフォルトの名無しさん2009/09/12(土) 11:40:14
>>900
> volataileは最適化が抑制されるから、プログラムに書いてる通りに実行しますよってことでしょ。

逆だ。
書いてあるとおりの読み書きを保証しないといけないから、最適化が抑制されるという結果になる。
0905デフォルトの名無しさん2009/09/12(土) 11:41:35
>>901
当然ある、つーかそのためにLOCK#がある

そもそも
mov eax,[edx]
ですらキャッシュアラインされてないとアトミックじゃないのに
0906デフォルトの名無しさん2009/09/12(土) 11:51:31
uopsの内部的な挙動は断言できなくね？
0907デフォルトの名無しさん2009/09/12(土) 13:07:26
>>906
命令実行じゃなくてバストランザクションに割り込めるか否かの
問題の方が大きいわけだが
0908デフォルトの名無しさん2009/09/12(土) 20:11:57
ところでCriticalSectionのインスタンスってvolatile付けなくていいのかな？
EnterCriticalSectionなどの関数の引数がvolatile無しで受けとるようになってるので。
0909デフォルトの名無しさん2009/09/12(土) 20:31:51
クラスのインスタンスそのものにvolatile性は無いだろ
volatile性を持つべきかもしれないのはあくまでもプライベートメンバで、それを
クライアントが認識する必要は無い
0910デフォルトの名無しさん2009/09/12(土) 20:57:55
>>908
君みたいな初心者が来るスレじゃないよ。
0911デフォルトの名無しさん2009/09/12(土) 21:24:35
そのうちvolatileがNGワードにされそうな勢いだな
0912デフォルトの名無しさん2009/09/12(土) 21:39:38
>>908
C++側はそのインスタンスへのポインタを扱ってるだけで、そのインスタンスにアクセスするのはAPI側だからvolatileは不要だろう。
0913デフォルトの名無しさん2009/09/12(土) 22:53:08
いや時々こうしてここを見ている全員が納得が行くまで
徹底的に議論する事は必要

そのうち delete は本当にメモリを返しているかとかで
揉めそうな気がするｗ
0914デフォルトの名無しさん2009/09/12(土) 22:57:20
>>913
> ここを見ている全員が納得が行くまで

共産党の全国大会じゃないんだから…
0915デフォルトの名無しさん2009/09/12(土) 22:59:21
2ちゃんでまともな議論なんて馬鹿げてるにも程がある
知ったかが偉そうに騒ぐだけ
0916デフォルトの名無しさん2009/09/12(土) 23:04:39
可哀想に
全部開眼の砂だと思っている奴が痛い
中にはキラリと光る宝石のような意見もあるのに
0917デフォルトの名無しさん2009/09/12(土) 23:16:05
ゴミに埋もれたら宝石もゴミ

掬い出すコストがバカにならない
0918デフォルトの名無しさん2009/09/12(土) 23:40:44
>>917
必要なのはコストではない
砂漠の砂の中から宝石を見つけ出す慧眼だけである
0919デフォルトの名無しさん2009/09/13(日) 00:13:28
砂漠にしか無い特殊な宝石があるなら、それもいいかもね。
でも2chにはそんなものは無い。
「たまーに、出るトコ出ても通じる良い意見がある」というだけの話であり、
それなら初めから「出るトコ」で活動するほうが良い。
0920デフォルトの名無しさん2009/09/13(日) 00:14:17
いつからここは詩人の集うスレになったんだ？
0921デフォルトの名無しさん2009/09/13(日) 00:49:20
難しい話はいいから0bの話しようぜ
0922デフォルトの名無しさん2009/09/13(日) 13:19:01
乳首の話するのか？
0923デフォルトの名無しさん2009/09/13(日) 13:30:04
つまらない上に下ネタきもひ
0924デフォルトの名無しさん2009/09/13(日) 18:35:25
C++0xのレンジベースのforってbegin()とend()とiteratorを用意すればいいの？
コンセプトが延期になったことで、組み込みのforとユーザークラスのインターフェースってどういう風になるのか疑問
0925デフォルトの名無しさん2009/09/13(日) 20:50:42
未定だけど多分大体そんな感じ

またわけわからんところで「beginがねーぞｺﾞﾙｧ」とか怒られるようになるんだろうなぁ
やだやだ
0926デフォルトの名無しさん2009/09/13(日) 21:13:38
「beginが予約語になりますた」ってことじゃないよねｗ。

0927デフォルトの名無しさん2009/09/14(月) 00:11:19
>>924
conceptが廃止されたことにより、ADLベースに変わってる。forの使い方は変わらない。
お前が書いたクラスをrange-based forで回したい場合、一番簡単なのは、メンバ関数に、イテレーターを返すbegin()とend()を持っていること。
<iterator>ヘッダをincludeするだけで、後は何もしなくても動く。
そうでは無い場合、お前の書いたクラスを引数に取り、イテレーターを返す、ADLによって呼び出せる（ココ重要）、begin()/end()関数が必要。

詳しく説明すると、associated namespaceに、特別にstdを追加したADLによって、お前の書いたクラスを引数に取るbegin()/end()が探される。
注意すべきなのは、通常のlookupは実行されないこと。begin()/end()は、ADLによって発見できなければならない。

namespace Hoge {
class Foo{} ;
iterator begin( Foo & ) ;
iterator end( Foo & ) ;
}

はOKだが、（iteratorという型については省略。何らかのイテレーターだと思ってくれ）

namespace Hoge { class Foo{} ; }
//Global namespace
iterator begin( Hoge::Foo & ) ;
iterator end( Hoge::Foo & ) ;

はエラーになる。（ADLでは見つからないから）
で、なんでメンバ関数にbegin()/end()を持っているだけでOKかというと、<iterator>等のヘッダをincludeすると、std名前空間内に、例えば

template<typename C> auto begin(C& c) -> decltype(c.begin()) { return c.begin() ; }

等という一連の関数が定義される。特別にstd名前空間がassociated namespace に追加されるので、呼び出すことが出来る。
お前の書いたクラスがbegin()メンバ関数を持っていない場合、SFINAEによって、この関数は呼び出し候補から除外される。

これが現行のn2930の提案。問題点は、一時オブジェクトの寿命とADLの誤爆だが、それを記すには余白が足りない。
conceptさえあれば、もっとマシになったんだがなぁ。
0928デフォルトの名無しさん2009/09/14(月) 01:10:05
解説乙

なんかもう一から言語仕様作り直したい衝動に駆られるよなｗ
0929デフォルトの名無しさん2009/09/14(月) 01:38:35
期待の新構文だったのに一気に邪悪な黒魔術に成り下がって悲しい
0930デフォルトの名無しさん2009/09/14(月) 02:05:10
というかADL自体が邪悪なんだよ。
koenigは腹を切るべきだと思う。
オペレーターオーバーロードが動かない？
少々不便でも、using directiveやusing declarationを使うようにしていた方が、
まだマシだったんじゃないのか。この汚い現状を考えたら。

他にも例えば、std::swap()がユーザー定義のswap()関数を見つけられるとかいう利点もあるんだろうが、
それは副次的な産物で、むしろrvalue referenceとかで積極的に解決すべきものだし。
0931デフォルトの名無しさん2009/09/14(月) 07:24:46
後からだったら何とでも言える
0932デフォルトの名無しさん2009/09/14(月) 07:33:04
失敗を後から全力で糾弾していいという文化じゃC++なんかとても作れんわな
0933デフォルトの名無しさん2009/09/14(月) 08:15:14
>>930
ADLを利用してるだけの身にはピンとこないんだが
どのあたりが邪悪なの？
0934デフォルトの名無しさん2009/09/14(月) 08:33:07
俺はADL万歳
template爆発はADLのおかげ
0935デフォルトの名無しさん2009/09/14(月) 08:41:04
>>933
すべての名前空間にわたって名前の意味づけを行ってしまうところ。
言い換えると、名前空間を汚染してしまうところ。

たとえば range based for のために begin() の意味が決められてしまうと、
全然関係ない役割で begin() という名前の関数を使っていたところに影響が
出てしまう。
0936デフォルトの名無しさん2009/09/14(月) 10:59:20
定義時にひとめでADL用とわかるように、せめて
　begin(std::adl_tag, T&)
みたいなオーバーロードにしてくれればいいんだけどな
0937デフォルトの名無しさん2009/09/14(月) 12:57:35
>>935
うーん…なるほど
しかしADLそのものに関しては、得られるメリットを考えれば邪悪とまでは言えないのでは…

begin/endが残念な黒魔術になりそうな悪寒なのは確かにその通りだと思う
0938デフォルトの名無しさん2009/09/14(月) 13:46:27
使えれば何でもいいよ。
0939デフォルトの名無しさん2009/09/14(月) 14:28:11
conceptあれば>>935は解決できるし、
conceptあってもADLは必要。
ADLの問題というよりも、
C++の"interface"の欠如の問題。
ADL無用論はおかしい。
0940デフォルトの名無しさん2009/09/14(月) 18:21:15
特殊な意味をつけるのはrange based for の存在自体だから
ADLは直接関係ないだろう。
0941デフォルトの名無しさん2009/09/14(月) 18:25:32
>>927
フェルマー乙。
余白があったら書ききれるのか？ｗ
0942デフォルトの名無しさん2009/09/14(月) 19:04:25
conceptsは300年後に実装されました
0943デフォルトの名無しさん2009/09/14(月) 19:25:25
>>941
実際に行数制限に引っかかりそうで改行減らした。
range-based forの使い方とか、問題点については、
すでに複数の日本語のブログでも取り上げられているので、
それを参照した方が良いかと。
0944デフォルトの名無しさん2009/09/15(火) 08:29:27
range forとかconceptをあてにしてた
ような機能は全部次回標準に順延
するんじゃないの？
0945デフォルトの名無しさん2009/09/15(火) 08:56:34
先延ばしにして2015辺りを目指した方がよさそうね。
0946デフォルトの名無しさん2009/09/15(火) 14:19:30
>>944
俺もそう思うけどな
ていうかてっきりそうなるもんだと思ってた
0947デフォルトの名無しさん2009/09/15(火) 18:37:19
次回なんてないよ。c99で終わったようにな。
0948デフォルトの名無しさん2009/09/15(火) 19:21:10
>>947
C1xは無視っすか
もはや主流ではないのは確かだけど
0949デフォルトの名無しさん2009/09/15(火) 19:25:34
>>947
WG21の人たちやる気満々だよ。
次はもっと短い期間で出すって。
0950デフォルトの名無しさん2009/09/15(火) 20:51:28
できもしないことにやる気出されるほどタチ悪いものはない
0951デフォルトの名無しさん2009/09/15(火) 21:55:21
実際にそれをやるヒトと文句だけ言うヒトといるのは仕方がないコトだ。
現状はそれで成り立っているし、やるべきヒトがやればそれでいい。
0952デフォルトの名無しさん2009/09/15(火) 23:14:34
まあできもしないと思ってたらできはしないもんだ
0953デフォルトの名無しさん2009/09/15(火) 23:26:13
できると思うだけでできるもんでもないけどな
0954デフォルトの名無しさん2009/09/15(火) 23:54:59
出来もしないことをとりあえず目標にして、実際は適当なところで
手を打つってのは欧米ではよくある手
0955デフォルトの名無しさん2009/09/16(水) 00:01:31
お前等そんな言葉の綾はどうでもいいから、もっと具体的な話をしろよ。
0956デフォルトの名無しさん2009/09/16(水) 00:20:06
じゃ問題

struct X{
　[]operator=(const X&) -> std::result_of<decltype(&X::operator=)>::type { return *this; }
};

これは正しいでしょうか
0957デフォルトの名無しさん2009/09/16(水) 00:47:28
>>956
たぶん正しいんじゃないかと思うが、
Unified Function Syntaxが導入された暁には、
（というかそれ自体がUnified Function Syntaxが導入されることを前提にしたコードだし）
そんなややこしいことしなくても、

struct X
{
[] operator = ( const X & ) { return *this; }
} ;

これだけで、同じ意味なんだが。
それは分かってて、あえて聞いているんだろうか。
0958デフォルトの名無しさん2009/09/16(水) 00:56:53
もちろんそうよ
ちなみにoperator=をoperator+なり、適当にfooなりに変えると結論が変わります
0959デフォルトの名無しさん2009/09/16(水) 04:22:55
std::result_ofのとこはtypenameいらんの？
0960デフォルトの名無しさん2009/09/16(水) 05:24:36
いらない。
そこに値が許されると思うか？
0961デフォルトの名無しさん2009/09/16(水) 05:27:12
>>960はMPL使ったこと無いの？
0962デフォルトの名無しさん2009/09/16(水) 05:30:47
依存型じゃないからじゃね？
0963デフォルトの名無しさん2009/09/16(水) 05:48:48
あれ、テンプレート関数の戻り値の型を指定するのにtypename必要なのか？
値なんて指定できないはずだよね。
何故？

template < typename T >
//typenameが必要？　でもここには型しかありえないのでは？
T::type
f() ;
0964デフォルトの名無しさん2009/09/16(水) 05:52:00
「型じゃなきゃエラーが起きるところは型として解釈しようと努力する」って仕様なら
typename自体が不要になるんじゃね？
09659632009/09/16(水) 05:53:11
14.6に書かれてるから仕方ないのかな。
それにしても分からない。
0966デフォルトの名無しさん2009/09/16(水) 05:56:04
で、結局実際に要るのか要らないのかは…
コンパイラが安定し始めるくらいにならないと運用上どうなのかは分からないか
0967デフォルトの名無しさん2009/09/16(水) 05:56:39
ベースクラスの指定には、typenameいらないじゃん。
だったら、戻り値の型の指定にだって、必要だとは思わないんだけどなぁ。
0968デフォルトの名無しさん2009/09/16(水) 05:59:52
テンプレート引数に依存せずに型であることが特定可能だからtypename不要だな
0969デフォルトの名無しさん2009/09/16(水) 06:01:58
D言語にはtypenameないんだけど、C++と何が違うの？
0970デフォルトの名無しさん2009/09/16(水) 06:03:45
実用経験
0971デフォルトの名無しさん2009/09/16(水) 06:06:42
>>966
>>956のコードは、そもそもテンプレートですらないから、typenameはいらないだろうけどね。
現行ドラフトも、文面はだいぶ変わっているけれど、
typenameが必要ない箇所にelaborated-type-specifierが追加されているだけだから、
多分、>>956のXがテンプレートクラスだったら、必要だと思うよ。
0972デフォルトの名無しさん2009/09/16(水) 06:11:19
>>969
Dでは型とも値ともとれる場合、型とみなされる。
括弧で囲えば値になる。
0973デフォルトの名無しさん2009/09/16(水) 22:27:19
ほう、それは合理的だな。
0974デフォルトの名無しさん2009/09/17(木) 21:02:42
> 括弧で囲えば

だせえ
0975デフォルトの名無しさん2009/09/17(木) 21:05:31
typenameは付けすぎてもエラーにならないようにして欲しいな。

とあるマクロでtypenameがある版と無い版を作る必要ができて困ったことがある。
0976デフォルトの名無しさん2009/09/17(木) 21:11:48
マクロだとそういうことあるね。
decltypeの登場でマクロの必要がなくなったケースもあるけど。
0977デフォルトの名無しさん2009/09/17(木) 21:18:32
>>975
そんなあなたにVC++
http://blogs.wankuma.com/andochin/archive/2009/05/27/173705.aspx
0978デフォルトの名無しさん2009/09/17(木) 21:34:14
>>974はきっとC++0xのdecltypeの仕様を知らない
0979デフォルトの名無しさん2009/09/17(木) 21:51:01
decltypeのアレは何とかならないのか
0980デフォルトの名無しさん2009/09/18(金) 03:00:06
>>974
かっこいい
0981デフォルトの名無しさん2009/09/18(金) 07:26:26
(〃e〃)ゞ ﾃﾍﾍ
0982デフォルトの名無しさん2009/09/18(金) 07:52:56
((〃e〃))ゞ ﾃﾍﾍ
0983デフォルトの名無しさん2009/09/18(金) 17:58:35
そろそろ次スレの季節
0984デフォルトの名無しさん2009/09/18(金) 18:51:22
このスレ、9の次は何番になるんだろうな。
0985デフォルトの名無しさん2009/09/18(金) 19:19:53
その前に規格ができるから心配していない。
0986デフォルトの名無しさん2009/09/18(金) 20:41:02
このスレを消化するのに三ヶ月。
このスレと同じペースで進んでいくとして、
9が埋まるのは九ヶ月後。

規格制定出来てるか怪しい物だな。
0987デフォルトの名無しさん2009/09/18(金) 20:43:43
lambdaと右辺値参照とautoあたりがまとめて消えて祭りになればなんとか
0988デフォルトの名無しさん2009/09/18(金) 20:59:20
何が残るんだよ？ｗ
0989デフォルトの名無しさん2009/09/18(金) 21:24:44
>>987
Intel C++とVisualC++は既に実装されているのに削除しろと？
むごい。むごすぎる。
0990デフォルトの名無しさん2009/09/18(金) 21:30:46
>>988
ユーザ定義リテラル
0991デフォルトの名無しさん2009/09/18(金) 21:32:37
ユーザー定義リテラルとかクソだし。
0992デフォルトの名無しさん2009/09/18(金) 21:36:36
別に1xになってもいいから
ちゃんと仕事してくれ
0993デフォルトの名無しさん2009/09/18(金) 21:45:17
>>990
pgr
0994デフォルトの名無しさん2009/09/18(金) 21:58:13
>>995
次スレよろしく
0995デフォルトの名無しさん2009/09/18(金) 22:14:09
次スレはなし
0996デフォルトの名無しさん2009/09/18(金) 22:21:14
だそうです。
0997デフォルトの名無しさん2009/09/18(金) 22:26:50
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
0998デフォルトの名無しさん2009/09/18(金) 22:30:35
1000取り合戦
0999デフォルトの名無しさん2009/09/18(金) 22:33:18
1000だったらフサフサになる。
1000デフォルトの名無しさん2009/09/18(金) 22:36:14
1000 = 丸禿
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。