09/06/16 06:02:49
2
3:デフォルトの名無しさん
09/06/16 06:10:25
>>2
お前はそれで満足なのか？
人生に何の疑問も感じないのか？
4:デフォルトの名無しさん
09/06/16 10:11:49
いらない子、そんな言語を熱く語るいらないエンジニアの溜まり場。
5:デフォルトの名無しさん
09/06/16 20:32:46
C++0x学園の人々
○コンセプトさん
学園のアイドルだが、入学してから一度も登校していない。退学の噂も。
○ラムダさん
ものすごい顔のせいでみんなから避けられてるいじめられっ子。
アルゴリズム部とは仲が良い。
○右辺値参照さん
成績優秀だが気難しい。仲良くなれればお得。
○禿
校長先生。
ここまで書いて飽きた
6:デフォルトの名無しさん
09/06/16 21:01:16
21世紀中に完成するだろうか・・・
7:デフォルトの名無しさん
09/06/16 22:35:58
完成→停滞→死
つまり完成しない方が良いということにならないだろうか？
8:デフォルトの名無しさん
09/06/16 22:42:55
なんて横浜駅･･･、もとい、サグラダファミリア･･･
9:デフォルトの名無しさん
09/06/17 00:07:29
>>6
それ何てロングパス
10:デフォルトの名無しさん
09/06/17 19:55:54
完成しても、仕事じゃ使えねーよ。
11:デフォルトの名無しさん
09/06/17 20:41:02
完成しないと枯れないから、いっそう使われないだろ
12:デフォルトの名無しさん
09/06/20 03:16:59
Singnal/Slot機構が入らないのは痛いな。
13:デフォルトの名無しさん
09/06/20 04:41:40
使えない言ってる人もコンパイラが対応しだしたら当たり前のように使うに100ペソ。
14:デフォルトの名無しさん
09/06/20 07:09:51
プログラマって基本的に新しい物好きだと思うから趣味としてはそうなんだろうが、仕事となると同じようにはいかないよね
15:デフォルトの名無しさん
09/06/20 07:55:10
今のところ仕様を追いかけるのは大丈夫だが、いつ疲れるのだろうか
16:デフォルトの名無しさん
09/06/20 12:23:34
>>15
もうとっくに疲れてるよ…。orz
17:デフォルトの名無しさん
09/06/20 16:24:22
マッサージしてあげるよっ！と妙にハイテンションな美少女中学生
18:デフォルトの名無しさん
09/06/20 20:33:58
>>12
特定フレームワークでしか使わないでしょ。
19:デフォルトの名無しさん
09/06/21 01:12:22
>>18
だが、そのフレームワークで使って欲しいんだな
それと、TR2とGCの実装が楽しみだな。何年後になるかわからんけど…
20:デフォルトの名無しさん
09/06/21 13:11:27
GCいらね
21:デフォルトの名無しさん
09/06/21 13:18:07
>>19
gtkmmのことか？
22:デフォルトの名無しさん
09/06/21 17:42:09
qtかも
23:デフォルトの名無しさん
09/06/21 17:47:32
gtkmmには既にsigC++があるしな。
qtのはまだmoc使ってんでしょ。
24:19
09/06/21 18:04:24
>>21
ご察しの通りgtkmmのことです。gtkmmは0xになると、Glib::RefPtr
の代わりにshared_ptrを使うようになるはずだし、libsigc++も
標準のものになれば良かったなと。
25:デフォルトの名無しさん
09/06/24 03:11:44
URLﾘﾝｸ(gcc.gnu.org)
ここでコンセプトの実装をしようとしているから、g++はちゃんと
コンセプトを実装するんじゃない？
26:デフォルトの名無しさん
09/06/24 03:17:19
ちなみに、C++にGCが実装されるとなるとどういう実装になるんだ？
クラスの作成に制限があったりするのかな。
27:デフォルトの名無しさん
09/06/24 09:45:31
>>25
されてないよw
URLﾘﾝｸ(gcc.gnu.org)
28:デフォルトの名無しさん
09/06/24 16:55:29
クソみそに遅くなりそうだな。
29:デフォルトの名無しさん
09/06/24 20:18:07
美少女中学生はスカトロには興味ありません！ありませんったら！
30:デフォルトの名無しさん
09/06/24 20:51:38
conceptGCCは中心開発者が抜けて事実上の開発中止です
31:デフォルトの名無しさん
09/06/25 02:11:57
ほんとだ。こうなったら、標準化委員会にリファレンスコンパイラを
作ってもらうしかないか。
つうか、俺にとってはg++がある意味リファレンス実装だからなぁ、
頑張ってほしいもんだ。
32:デフォルトの名無しさん
09/06/25 05:06:19
URLﾘﾝｸ(www.open-std.org)
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
33:デフォルトの名無しさん
09/06/25 07:24:02
>>30
> conceptGCCは中心開発者が
export concept mapだってさw
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)
34:デフォルトの名無しさん
09/06/25 07:47:57
export concept mapがないと、
constrainedなコードと、unconstrainedなコードで重複したコードを書かなければならない。
その場合、どうせコピペされるだろうから。言語でマシな方法を提供した方がいい。
最高の提案とも言えないが、必要だと思う。
35:デフォルトの名無しさん
09/06/25 19:38:08
そうは言ってもexportと聞いただけで体が拒否反応を起こす
36:デフォルトの名無しさん
09/06/25 22:35:11
しかしまとまるのか？
つーか禿はこの期に及んで新規提案とか何考えてるの
37:デフォルトの名無しさん
09/06/25 22:44:27
たぶん提案しているうちが一番楽しいんだろう
38:デフォルトの名無しさん
09/06/26 00:46:53
N2905とか悪い冗談にしか見えないんだがどこまで本気なんだろ
39:デフォルトの名無しさん
09/06/26 09:06:47
コンパイル時とランタイム時で、似たようなことをするための文法に、統一性がなさすぎだなー。
継承とテンプレートとコンセプトで全然別の書き方をおぼえろって。
40:デフォルトの名無しさん
09/06/26 09:11:26
VCはconceptの実装について見通しとか立ててるのかな
41:デフォルトの名無しさん
09/06/26 11:06:09
URLﾘﾝｸ(blogs.msdn.com)
で検索してもほぼスルーだから、
VC++ 2010には入らないんじゃ。
2012とか2013あたりかね。
42:デフォルトの名無しさん
09/06/26 11:08:06
>>34
交合した時に便利なんだけど、
混合すると既存のコードのルックアップも変る可能性があるのが、
痛し痒しなところだね。
43:デフォルトの名無しさん
09/06/28 15:38:33
C++0xのshared_ptrはスレッドセーフ？
44:デフォルトの名無しさん
09/06/28 15:44:08
まさか
45:デフォルトの名無しさん
09/06/28 18:03:04
C++はどこまで肥大化していくのだろうか。
コンパイラ開発者泣かせだよな。
そのうちGCCとVC++くらいしか追従出来なくなったりして。
46:デフォルトの名無しさん
09/06/28 18:18:48
すでに追従できてないし＾＾
VCなんかダイアモンド継承すらまともにできない。
47:デフォルトの名無しさん
09/06/29 00:22:41
intelががんばるよ
48:デフォルトの名無しさん
09/06/29 01:48:34
PL/Iの二の舞だよな
折角UNIXとCでスリムアップしたのに
49:デフォルトの名無しさん
09/06/29 01:50:29
>>46
kwsk
最近はVCの方がg++より規格準拠度が高いと聞いていたが。
50:デフォルトの名無しさん
09/06/29 02:07:20
VC6の事だろjk
51:デフォルトの名無しさん
09/06/29 07:55:47
vc6は窓から投げ捨てろ
52:デフォルトの名無しさん
09/06/29 08:08:15
concept以外は、もうg++もVCもそれなりに満足行くレベルで対応してるよね。
VCはまだ正式には出てないけど。
詳しくないけど、conceptも実はやってみたらすぐだったりしないのかなぁ。
極論言えば、テンプレート引数に対する超かしこいマクロなだけだよね。
プリプロセッサの後にconceptチェッカを通して、それがOKならコンパイラに渡す、とかで。
53:デフォルトの名無しさん
09/06/29 15:06:59
>>52
さあ、おまえが早速実装するんだ
54:デフォルトの名無しさん
09/06/29 15:25:01
憶測書いている暇あるならg++のgcc/cp/concept.c読めばいいのに
55:デフォルトの名無しさん
09/06/29 18:11:39
>>49
URLﾘﾝｸ(connect.microsoft.com:443)
「バグ」に分類されてるけど、「修正しない」方針、つまりVCの仕様で決着。
VCではダイアモンド継承については仕様に合致しない方針で行くということになっている。
もちろん、最新の2008でもこの仕様。
56:デフォルトの名無しさん
09/06/29 21:11:49
そこでそのうち見直すって言ってるけど2010でも直ってないの？
57:デフォルトの名無しさん
09/06/29 23:35:03
「バグだけど2008には間に合わない」って書いてあるようにみえるけど？
58:デフォルトの名無しさん
09/06/29 23:50:23
VS2008 SP1でも直ってないのなら、あまり修正する気が無いのか、
余程大幅な修正が必要なのかのどちらかだろうな。
ところでComeau使ってる人いる？C++0xへの準拠度はどんなもの？
59:デフォルトの名無しさん
09/06/30 00:07:20
>>55
ATLで多用しているから修正しないのか
ひでえ話だな
60:デフォルトの名無しさん
09/06/30 00:07:28
2008SP1Expressでは直ってなかった
誰か2010βで試してくれ
61:デフォルトの名無しさん
09/06/30 06:24:30
2010beta1
error C2250: 'D' : 'A *V::vf(void)' のあいまいな継承です
62:デフォルトの名無しさん
09/06/30 18:23:20
直ってないのか…
忘れてるのか直す気がないのか
63:デフォルトの名無しさん
09/06/30 18:50:52
だから仕様。
64:デフォルトの名無しさん
09/06/30 18:51:50
MSもバグだって認めてるだろ。直す気が無いだけ。
65:デフォルトの名無しさん
09/06/30 18:53:13
直す気のないバグは仕様と同じじゃないかｗ
2010までは既存のコンパイラを修正しーしー使ってるけど
2010の次のバージョンではコンパイラをフルスクラッチするって言ってたはずなので
2010の次のバージョンで直るんじゃないか？
C++0xへの準拠もその時点で･･･って気がする。
66:デフォルトの名無しさん
09/06/30 20:07:43
exportは201x年のうちに対応したコンパイラ出てくるのかな。
67:デフォルトの名無しさん
09/06/30 20:15:11
exportもういらないだろ
word aroundがBoostですっかり定着しちゃったし
68:デフォルトの名無しさん
09/06/30 20:16:32
あっそうか
templateを使ったソースを分割コンパイルする時に問題が生じるのか
(ビルド時間)
現時点ではCPUの速度でカバーしてもらおうか
69:デフォルトの名無しさん
09/07/01 02:05:22
ja.wikipedia.orgには、
> C++0x標準には、C++でのガベージコレクションの実装を容易にする機能が導入される。
とあるけど、 どんな機能なんでしょうか？さっぱり分かりません…
70:デフォルトの名無しさん
09/07/01 02:51:40
単純にスマートポインタのことじゃないの。
71:デフォルトの名無しさん
09/07/01 03:17:50
URLﾘﾝｸ(www.open-std.org)
質問しておいて何ですが、色々ググってみたら↑が見つかりました。
多分これだと思いますがほんとに実装されるのでしょうか…
72:デフォルトの名無しさん
09/07/01 22:11:00
それは単に規格に入れる文面だ。それ以上じゃない。
ユーザーからしたら、とくにコードに変化はない。何も機能が追加されるわけじゃない。
文字通り、GCを将来入れる際に、最低限のことを決めておこうというだけのことだ。
ポインタに対してXORなどのある種の演算をしたらGCを保証しないよというだけのこと。
73:デフォルトの名無しさん
09/07/02 00:29:14
APIも定義されてる。
74:デフォルトの名無しさん
09/07/02 21:04:51
>58
ここ見る限りではもう少し頑張りましょうってとこかと。
URLﾘﾝｸ(www.comeaucomputing.com)
75:デフォルトの名無しさん
09/07/03 00:14:19
あのexportを見事実装したComeauでさえコンセプトは実装できてないのか
もう無理じゃね？
76:デフォルトの名無しさん
09/07/03 00:25:03
禿はどのコンパイラが一番好きなんだろうか。
日常的に6つ位使ってると書いてあったが。
77:デフォルトの名無しさん
09/07/03 10:50:06
自分の所のコンパイラがあるのはプローガー氏だっけ？
78:デフォルトの名無しさん
09/07/03 11:53:57
Dinkumwareはライブラリしか作ってないと思ってたけど、違うの？
79:デフォルトの名無しさん
09/07/03 12:14:12
これは Bjarne スッポスッポがどれかのコンパイラに concept を実装しないと誰も実装しないかもね
80:デフォルトの名無しさん
09/07/03 12:19:39
コンセプトってそんなに実装むずいの？
81:デフォルトの名無しさん
09/07/03 12:51:56
もう標準化委員会でリファレンス実装を与えた方が良い気がする。
このままではコンパイラベンダもC++コミュニティも共倒れになりそう。
82:デフォルトの名無しさん
09/07/03 13:25:50
たしかに、これだけ高レベルな概念の実装にターゲット依存するものは無いだろうしね。
で、その実装を書くための言語は何にするんだぜ？
83:デフォルトの名無しさん
09/07/03 13:39:18
C++0xがCのC99のような運命を辿らなければいいのだが
84:デフォルトの名無しさん
09/07/03 14:38:10
>>82
実装に使う言語は一つ前の標準を使うということで、C++03で良いのではないかと。
85:デフォルトの名無しさん
09/07/03 15:43:36
boostにコンパイラフレームワークとC++0xコンパイラを追加すればいい。
86:デフォルトの名無しさん
09/07/03 15:54:23
boost::interpreter
87:デフォルトの名無しさん
09/07/03 20:58:00
>>84
世界中のバイナリファイルがウィルスに感染してソースコードしか残らなかったら
どうやってコンパイルするんだ！
88:デフォルトの名無しさん
09/07/03 21:06:06
本当のプログラマはヘキサエディタでコンパイラ書くよ。
89:デフォルトの名無しさん
09/07/03 22:25:25
>>87 大丈夫。その時には OS すら動作してないから
90:デフォルトの名無しさん
09/07/03 22:54:23
＿＿＿_
／ ＼
／ _ノ ヽ､_ ＼
／ oﾟ⌒ ⌒ﾟo ＼ 今日もまた、紙に穴を開ける作業が始まるお
| （__人__） |
＼ ｀ ⌒´ ／
91:デフォルトの名無しさん
09/07/04 21:14:47
>>90
なんの話だよｗ
92:デフォルトの名無しさん
09/07/04 21:17:25
キーパンチャーじゃないか？
93:デフォルトの名無しさん
09/07/04 21:54:01
パンチカードでプログラムしてるんだよ。
ちなみに、実行結果もパンチカードで出てくるんだよ。
94:デフォルトの名無しさん
09/07/04 22:03:40
今時パンチカードのシステムを使っている所なんかあるのかよ
95:デフォルトの名無しさん
09/07/04 22:12:35
ノイマン式をリセット出来るなら今度は9bit/byteのコンピュータにしようぜ
96:デフォルトの名無しさん
09/07/04 22:17:35
>>95
何か意味あるのか？
命令数が増やせるとか数の表現範囲が広がるとかその程度かメリットは
97:デフォルトの名無しさん
09/07/04 22:18:10
オクタエディタが必要だな
98:デフォルトの名無しさん
09/07/04 22:45:23
ヲタクエディタかと思った
99:デフォルトの名無しさん
09/07/04 23:13:58
16bit/byteのCPUなら結構使われてるよ
そいつのCはcharが16bitだ
100:デフォルトの名無しさん
09/07/04 23:51:42
>>95
charが9bitの処理系って普通にあったような
確かUTF-9絡みで知った覚えがある
101:デフォルトの名無しさん
09/07/04 23:58:18
UTF-9/UTF-18 はジョークRFCです
でもまあ確かに昔36bitワードのアーキテクチャはあった
102:デフォルトの名無しさん
09/07/05 00:11:37
8bit目は無駄に消費されていることが多い。
地球環境を守るため7bit/byteにすべきだ。
103:デフォルトの名無しさん
09/07/05 00:19:35
地球環境を守るならパソコンを捨てるべきだ。
104:デフォルトの名無しさん
09/07/05 00:20:30
再び日本語が化ける日々が続くのか…
105:デフォルトの名無しさん
09/07/05 00:43:53
short が16bitから18bitになれば扱える記号が二十万増えるんだよ
こんなに経済的なことはないじゃないか
106:デフォルトの名無しさん
09/07/05 00:47:40
UCS-4でおｋ
107:デフォルトの名無しさん
09/07/05 04:21:22
>>83
C99はこっそりと普及しつつあると想像
してるんだけど、実際はどうなんだろ。
108:デフォルトの名無しさん
09/07/05 04:47:08
>>107
考えが甘すぎる
もう10年経ってるんだよ？
109:デフォルトの名無しさん
09/07/05 07:33:36
そんなこというと ANSI C の普及も遅々としていた気がする
110:デフォルトの名無しさん
09/07/05 08:23:10
>>101
今でも ACOS-6 は word 32bit/char 9bit だ
111:デフォルトの名無しさん
09/07/05 08:26:01
>>96
ノイマン型コンピュータを実装するとき、状態素子の取り得る状態の数はネイピア数に近い方が実行の効率がいいと聞いたことがある。
112:デフォルトの名無しさん
09/07/05 10:02:50
>>107
俺的には、C99はGCCの独自拡張。
>>111
「トランジスタのレベルで3値論理回路があるなら」って条件付きで、
3進数の方が情報の効率はいいって話だったと思う。
世の中2値論理が主流だから、その前提成り立たない。
113:デフォルトの名無しさん
09/07/05 10:13:01
主流だから、というのは関係ないと思うんだが。
確か Skip List の論文で引用されてたかな。
114:デフォルトの名無しさん
09/07/05 10:18:13
2進数素子を3進数素子に置き換えた所で
情報量は1.6倍くらいにしかならないんだが
115:デフォルトの名無しさん
09/07/05 10:18:16
>>111
> ノイマン型コンピュータを実装するとき
eを基数にすると、もっとも効率のいい符号化が出来るって、話とちゃう?
でもって、符号化の話はノイマン型コンピュータに限らないわけだが…
116:デフォルトの名無しさん
09/07/05 10:24:19
俺が子供の頃のコンピュータは
１０進数で計算してたんだよ
117:デフォルトの名無しさん
09/07/05 10:25:34
計算屋さんですか
118:デフォルトの名無しさん
09/07/06 08:38:28
10進数って1bitが10値だったってこと？
119:デフォルトの名無しさん
09/07/06 09:01:21
つ BCD
120:デフォルトの名無しさん
09/07/06 09:35:22
俺が子供の頃の粘土板なんて60進数で計算してたぞ
121:デフォルトの名無しさん
09/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:???
人類のテクノロジーがそこまで進んでいるとは思いませんでした。正直びっくりです。
でもよく考えてみれば、水平に動かすならば、摩擦係数さえ何とかすれば大丈夫なんですね。
昔エジプト人が石をコロに乗せてピラミッドの上まで運んでいるのをみたんですが、そんなのを想像していました。
122:デフォルトの名無しさん
09/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:???
一行目の「人類のテクノロジーが～」がまた効いてるなｗ
123:デフォルトの名無しさん
09/07/06 18:29:44
>>120
で、あんたの年はいくつなの？ｗ
124:デフォルトの名無しさん
09/07/06 19:02:12
>>118
10進数は decimal digit
125:デフォルトの名無しさん
09/07/06 21:19:36
>>119
これはひどい環境破壊だな。
世界中ののこり6bitに住まわせてくれ。
126:デフォルトの名無しさん
09/07/06 21:26:31
sexadecimal
127:デフォルトの名無しさん
09/07/06 22:13:57
sexという単語に過剰反応する美少女中学生
128:デフォルトの名無しさん
09/07/07 00:29:47
sexagesimal
129:デフォルトの名無しさん
09/07/07 10:12:59
sexagesimal といわれるとこれ
URLﾘﾝｸ(www.open-std.org)
を出さんわけにはいかんな
130:デフォルトの名無しさん
09/07/07 18:33:16
くだらんげんごになった。
131:デフォルトの名無しさん
09/07/07 19:04:07
くらげだんごになった。
132:デフォルトの名無しさん
09/07/07 19:23:57
くらげだんごってどんな味がするんだろうと本気で思案する美少女中学生
133:デフォルトの名無しさん
09/07/08 16:00:06
こんな言語では萌えない。
134:デフォルトの名無しさん
09/07/10 01:07:43
デストラクタのにゅる記号萌え～
135:デフォルトの名無しさん
09/07/10 02:00:58
struct churuyasan{
~churuyasan(){std::cout << "にょろ～ん" << std::endl;}
};
136:デフォルトの名無しさん
09/07/10 23:24:52
struct churuyasan??<
??-churuyasan()??<std::cout << "にょろ～ん" << std::endl;??>
??>;
やはりトライグラフには風情がない
137:デフォルトの名無しさん
09/07/10 23:43:34
トライグラフ使う環境なのに、日本語文字列はOKなのかよ！
138:デフォルトの名無しさん
09/07/11 00:28:25
わらたｗ
139:デフォルトの名無しさん
09/07/11 12:52:31
>>137
ローマ字入力だったら、英字キーと
変換キーだけで充分だよ？
日本向けPDAならありえること。
140:デフォルトの名無しさん
09/07/11 12:57:51
例えばどのPDAですか?
141:デフォルトの名無しさん
09/07/11 14:53:38
前々から他人とは少し違う自分を感じていたが、
今朝起きたら左手の甲にトライグラフの紋章が現れてた。
142:デフォルトの名無しさん
09/07/11 15:07:04
. △
△△ tanasinn
143:デフォルトの名無しさん
09/07/11 16:56:16
それはトライフォース
144:デフォルトの名無しさん
09/07/12 02:14:07
>>140
オレが今使ってるやつだと、
中カッコの入力方法がわからん。
普通のキーボードと同程度に文字を
入力できるPDAなんかあるのか？
145:デフォルトの名無しさん
09/07/12 11:15:45
お前の話はいいよ。
146:デフォルトの名無しさん
09/07/12 14:29:47
自分のことをオレと呼ぶ美少女中学生かもしれないじゃないか
147:デフォルトの名無しさん
09/07/12 14:44:48
よろしい、ならば聞こう
148:デフォルトの名無しさん
09/07/13 05:24:25
ahaha
149:デフォルトの名無しさん
09/07/14 08:02:10
Concept廃止と聞いて！
150:デフォルトの名無しさん
09/07/14 08:13:54
おい、マジかよ。
まあ、明日辺りには詳しいことが分かるだろうけど。
151:デフォルトの名無しさん
09/07/14 09:35:37
本当なのか。
ずっと議論続いてたから見送りなっても仕方ないだろうとは思っていたが。
152:デフォルトの名無しさん
09/07/14 10:19:19
ソースｷﾎﾞﾝ
153:デフォルトの名無しさん
09/07/14 11:47:46
concept_mapは革新的だったがあまりにも革新的すぎたのか？
154:デフォルトの名無しさん
09/07/14 12:26:21
革新的かどうかより、今さらの実装は
現実的じゃないってことなのでは。
多重継承とは違って、意地で実装するには
難し過ぎるんだろうなあ。
155:デフォルトの名無しさん
09/07/14 14:55:13
ソースどこだよ！！！
156:デフォルトの名無しさん
09/07/14 15:58:59
これじゃね
URLﾘﾝｸ(lists.puremagic.com)
157:デフォルトの名無しさん
09/07/14 16:30:24
D言語のニュースグループかよｗｗ
158:デフォルトの名無しさん
09/07/14 19:38:54
ああ、今フランクフルトで会議中なのか。
post-Frankfurt mailingが出るまで真偽の程はお預けかな。
159:デフォルトの名無しさん
09/07/14 20:04:11
次次期標準までのスパンを短くしてそのとき入れてくれればいいよ
160:デフォルトの名無しさん
09/07/14 21:05:31
無くすなら無くすで大変だろ
今さらドラフトからコンセプト関連の文言消して回るのか？
拡張for文はどうするんだ？
161:デフォルトの名無しさん
09/07/14 21:17:04
おそらくただのダックタイピングになるだけだろう。
組み込み配列だけはアドホックに対応して、後はあきらめることになると思う
162:デフォルトの名無しさん
09/07/14 22:15:45
公約守れなかったら禿に不信任決議で委員会解散総選挙の刑
163:デフォルトの名無しさん
09/07/14 22:25:14
素直にC++{1,2}xに変更しようぜ。
164:デフォルトの名無しさん
09/07/14 22:39:15
コンセプトなんて0xの新機能の中でもかなり早くから議論されてる方だよなぁ
本当に廃止になったら情けないわ
165:デフォルトの名無しさん
09/07/14 23:35:12
>>163
ぶれた
166:デフォルトの名無しさん
09/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 ●● ○○
［￣￣］ ［￣￣］ （￣￣￣￣￣） ［￣￣］ ［￣￣］
|_○_| .|_○_| |＿＿＿＿_| |_○_| .|_○_|
さようならコンセプト
167:デフォルトの名無しさん
09/07/14 23:57:16
ここで Bjarne が超人的コード力を発揮して、concept-cfront を三日で書き上げるに3ペリカ
168:デフォルトの名無しさん
09/07/15 00:00:05
禿、頼むよ・・・
169:デフォルトの名無しさん
09/07/15 00:01:36
喜々として廃止票入れてそうな気もするがな
170:デフォルトの名無しさん
09/07/15 00:01:36
C++にconceptが入らないって事はないと思うよ。
たとえC++0xで見送られたとしても。
171:デフォルトの名無しさん
09/07/15 00:03:17
exportと同じ道を歩むくらいなら無くなってくれて良かったと思おう
172:デフォルトの名無しさん
09/07/15 01:33:55
0xはすぐにでも使いたい即効性のあるもんばっかりなんで、
個人的にはリリースの延期だけはしないで欲しいなぁ。
173:デフォルトの名無しさん
09/07/15 02:35:20
>>171
そうなんだよな。
誰も実装しない機能なんてないのと同じだからな。
174:デフォルトの名無しさん
09/07/15 09:37:51
>>171
exportとは全然違うでしょ。
conceptは重要な機能満載なんで。
175:デフォルトの名無しさん
09/07/15 10:31:44
でも、実装されなきゃ絵に描いた餅
176:デフォルトの名無しさん
09/07/15 11:42:45
またまた。どうせ実装されても数年は（古いソースコードとの互換性を重視して）使わない気でしょ、みんな？＾＾
177:デフォルトの名無しさん
09/07/15 11:49:59
スレ違いだな、そういう人間は。
178:デフォルトの名無しさん
09/07/15 13:04:38
>>174
＞exportとは全然違うでしょ。
実装されてたら、ビルド時間が超速く
なってて、またいろいろ違う状況に
なってたかもしれないけどね。
179:デフォルトの名無しさん
09/07/15 13:17:28
conceptが入ればコンパイルエラーのメッセージが8メガバイトも出力されずに
済むようになるかもしれない（？）
180:デフォルトの名無しさん
09/07/15 17:55:46
>>178
そんなに速くはならんよ。
181:デフォルトの名無しさん
09/07/15 18:00:45
oファイルの汚染が進んで取り返しのつかない事に成ってたかも知れんね
182:デフォルトの名無しさん
09/07/15 19:36:57
この調子で変態ラムダもrejectよろしこ
183:デフォルトの名無しさん
09/07/15 20:01:58
lambdaを入れずしてC++0xの面目はないだろ。
あと、関数の文法統一とnamed lambdaとlocal functionが欲しい所だが。
184:デフォルトの名無しさん
09/07/15 20:33:54
欲張るとコンセプトみたいに消えるからほどほどにしておけ。
185:デフォルトの名無しさん
09/07/15 20:35:03
>>183みたいなのがC++をダメにしたんだな
186:デフォルトの名無しさん
09/07/16 00:13:55
もうautoと右辺値参照さえあればいいよ…
187:デフォルトの名無しさん
09/07/16 02:12:02
>>178
ビルド時間が？
あんたあほちゃうの？
188:デフォルトの名無しさん
09/07/16 02:13:30
>>186
template書きとしてはdecltype必須。
GCのためのメモリモデルもかなりいいよ。
189:デフォルトの名無しさん
09/07/16 20:58:44
conceptの代わりにユーザー定義リテラルが死ねば良かったのに(´･ω･`)
190:デフォルトの名無しさん
09/07/16 21:26:00
右辺値参照とイニシャライザーリストも死ねばいいのに
191:デフォルトの名無しさん
09/07/16 21:31:05
たまにはaxiomのことも思いだしてあげてください。
192:デフォルトの名無しさん
09/07/16 21:35:32
右辺値参照はもう無くせないよ
よほど実装が簡単だったのかほとんどのコンパイラがもう対応してるし
コンセプトと違って
193:デフォルトの名無しさん
09/07/17 01:51:21
>>191
何言ってるの? axiomはconceptの一部だよ。
>>192
右辺値参照をやっつけるのは、コンパイラ屋には簡単で、
ライブラリ屋には難しい。
194:デフォルトの名無しさん
09/07/18 14:09:22
conceptとenable_ifってキャラ被りじゃね？
195:デフォルトの名無しさん
09/07/18 19:19:03
>>8
あれは教会建築としてはフツーの部類なので問題無い
ミラノ大聖堂なんか完成まで400年以上掛かってるし
設計ミスと資金不足で数百年費やした後未完成なんて教会もあるし
196:デフォルトの名無しさん
09/07/18 20:20:29
突っ込まないぞっ
197:デフォルトの名無しさん
09/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.
URLﾘﾝｸ(www.informit.com)
198:デフォルトの名無しさん
09/07/19 17:05:03
ろくな実装がないという点では同じだな。
199:デフォルトの名無しさん
09/07/19 17:18:47
Haskell や Scala でできてること（型によるパターンマッチ？）を C++ に取り込むって感じじゃないの？
200:デフォルトの名無しさん
09/07/19 18:09:32
標準で野心的なことをすると、自分で作ってみろよ、と言われ、便利な機能を標準外で独自
実装すると標準を守れ、と怒られる時代だなｗ
201:デフォルトの名無しさん
09/07/19 19:43:15
comp.std.c++によれば、どうやらC++0xは1年近くずれ込むようで。
202:デフォルトの名無しさん
09/07/19 19:52:20
誰も使わない言語に、マジになりそうだな。
203:デフォルトの名無しさん
09/07/19 20:09:02
conceptはexportよりも実装はずっと楽。
exportはlink時にlazy compileだから。
まあ最近のgccだとexportも実装できそうな勢いだけど。
GIMPLE使ったlink-time optimizationのbranchあるから。
204:デフォルトの名無しさん
09/07/19 20:10:59
VC10がリリースされたら、C++0xの規格がまとまらなくてもautoにlambdaや右辺値は便利だから使うけどね。
205:デフォルトの名無しさん
09/07/19 20:15:54
規格の内容が変わったらどうするんだろうなVC10
206:デフォルトの名無しさん
09/07/19 20:24:08
正式版リリース前なら変更すればいいし、リリース後ならSPで変更すればいい
207:デフォルトの名無しさん
09/07/19 20:25:43
VC6の二の舞か
208:デフォルトの名無しさん
09/07/19 21:03:08
今からコンセプト取り除く作業して拡張for文とかも考え直して…
1年で済むのかなぁ
209:デフォルトの名無しさん
09/07/19 21:38:01
なー、なんで学園アイドルのコンセプトさんは学校こーへんのー?
210:デフォルトの名無しさん
09/07/19 21:53:15
お星様になったからだよ…
211:デフォルトの名無しさん
09/07/19 21:55:41
本物のスターになったわけか
212:デフォルトの名無しさん
09/07/19 22:00:34
それでも禿なら、禿なら颯爽と実装を持ってきてくれるに違いないっ・・・
213:デフォルトの名無しさん
09/07/19 22:03:46
我らがすっぽすっぽ校長なら全校集会で平然と残念なお知らせをするのも造作ない
214:デフォルトの名無しさん
09/07/19 22:19:41
泣き崩れるforさん
明日は我が身と青ざめるラムダさん
仕事が増えそうで憂鬱なstatic_assertさん
出番が増えそうでニヤニヤしてるtype_traitsさん
あまり興味なさそうな右辺値参照さん
爆睡してるautoさんdecltypeさん姉妹
215:デフォルトの名無しさん
09/07/19 23:06:05
コンセプトってそんなに難しいの？
216:デフォルトの名無しさん
09/07/19 23:06:53
むずかしくないよ
217:デフォルトの名無しさん
09/07/19 23:23:06
Concepts のコンセプトが破綻していたから外されたのですね...
218:デフォルトの名無しさん
09/07/19 23:25:19
>>215
経験が足りない。
難しくないと言いきれるほど、徹底的に分かってない。
219:デフォルトの名無しさん
09/07/19 23:31:09
>>215
難しいというか、普通に実装すると遅くなりすぎる。
実装や最適化の方法について目下研究中ってところ。だいぶ成果は上がってきてるらしいけど
220:デフォルトの名無しさん
09/07/19 23:55:08
遅くなるって？
コンパイル時の技術なんだからそんな問題じゃないでしょ
テンプレートで既にかなり遅いし
221:デフォルトの名無しさん
09/07/20 00:18:36
実装が難しいんだろ。
222:デフォルトの名無しさん
09/07/20 00:27:23
>>219
> 普通に実装すると遅くなりすぎる。
無知は黙ってろ
223:デフォルトの名無しさん
09/07/20 00:30:34
>>219
死ね
224:デフォルトの名無しさん
09/07/20 00:32:36
Pythonとかみたいに気軽に仕様追加や変更できるといいのにね。
C++ 09.7とかC++ 09.12とか。
225:デフォルトの名無しさん
09/07/20 00:33:00
ケンカすんな
空の上のコンセプトさんが悲しむぞ
226:デフォルトの名無しさん
09/07/20 03:53:11
コンセプトさんも草葉の陰から見守っていて下さい
227:デフォルトの名無しさん
09/07/20 04:59:42
コンセプト、まじかよ・・・
せっかくエラーメッセージが見やすくなると思って期待してたのに。
228:デフォルトの名無しさん
09/07/20 05:58:50
boost::conceptで我慢しな
229:デフォルトの名無しさん
09/07/20 06:09:27
いや、標準ライブラリがコンセプトを使うようにならないとあまり意味が無い
230:デフォルトの名無しさん
09/07/20 07:38:57
もうboostが標準でいいよ
231:デフォルトの名無しさん
09/07/20 07:54:14
Concept-gcc やってたひとを雇って他のプロジェクトにつかっている Apple が主犯だ
232:デフォルトの名無しさん
09/07/20 07:55:04
もうやめて！あれは不幸な事故だったのよ！わたしたちがいがみ合ったってコンセプトさんは帰ってこないわ！
233:デフォルトの名無しさん
09/07/20 07:56:33
>>231
それ本当？clangの実装させてるとか？
だとしたらApple許しがたいな
234:デフォルトの名無しさん
09/07/20 09:38:21
Concept-GCC やってたのはこの人
URLﾘﾝｸ(www.osl.iu.edu)
だけど、
URLﾘﾝｸ(www.osl.iu.edu)
みると alumni になってるんだよね。
URLﾘﾝｸ(www.linkedin.com)
をみると、Apple の C++ グループで何かやってる。
去年の10月から働いてるようで、そのあたりで突然ブログ
URLﾘﾝｸ(conceptgcc.wordpress.com)
も止まってます。
clang は去年の段階では C++ が全然だったから、
きっと clang の C++ サポートを頑張ってるんでは。
URLﾘﾝｸ(clang.llvm.org)
235:デフォルトの名無しさん
09/07/20 09:40:55
Objective-Cの競合相手だからな
潰しに来たとしても不思議じゃない
236:デフォルトの名無しさん
09/07/20 10:09:11
う～ん、WebKit とかは Objective-C と C++ の両方に依存しているので
競合相手というのはちょっと違うのでは...
concept-clang とか出てくれればいいですが。
237:デフォルトの名無しさん
09/07/20 13:33:18
まあObjective C++があるわけだし、さすがにC++を葬り去りたいわけでは
ないだろうけれど。MSに行かれるより遥かにマシだとも言えるし。
238:デフォルトの名無しさん
09/07/20 13:58:45
>>219
239:デフォルトの名無しさん
09/07/20 14:31:39
もうやめてー、>>219のライフは０よ。
240:デフォルトの名無しさん
09/07/20 16:28:12
Conceptは未だコンセプトの域を出ていないって事だろ。
241:デフォルトの名無しさん
09/07/20 16:29:52
アホは黙ってろ
242:デフォルトの名無しさん
09/07/20 17:30:03
なんでConceptは外されることになったの？
243:デフォルトの名無しさん
09/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.
だって。
244:デフォルトの名無しさん
09/07/20 19:35:18
別にConcept自体はどーでもいいけどさ
ここまで来てやっぱやーめた→何このgdgd
245:デフォルトの名無しさん
09/07/20 22:50:53
WinFSよりもひどい
246:デフォルトの名無しさん
09/07/20 23:00:49
もうC#でいいよ。
247:デフォルトの名無しさん
09/07/20 23:15:33
コンセプトさんは悪くないんや
メタプログラミングの道具にしようとした周りの大人が悪いんや
248:デフォルトの名無しさん
09/07/20 23:34:35
こんな高い山を目前にして下山する勇気を持つのはすごいことでしょ。
正しい決断だったと思うよ。
249:デフォルトの名無しさん
09/07/21 00:15:53
トムラウシ山の教訓が生かされましたね
250:デフォルトの名無しさん
09/07/21 00:46:44
登る前に気付くのが真の賢者
251:デフォルトの名無しさん
09/07/21 00:55:32
と言いながら何処にも登らないニート
252:デフォルトの名無しさん
09/07/21 01:27:40
>>243
この理由が通るなら、次回もその次も「誰も喜ばない難しい選択」で外されそうだ。
俺が現役のうちには手にできないかも知れない気がしてくる。
253:デフォルトの名無しさん
09/07/21 03:37:50
禿の書いた"Simplifying the use of Concepts"がトドメを刺したっぽいな。
URLﾘﾝｸ(www-949.ibm.com)
254:デフォルトの名無しさん
09/07/21 07:20:49
>>251
実装なしで規格の上だけで大半の議論をやってるC++0xの事ですねわかります
255:デフォルトの名無しさん
09/07/21 11:03:07
実装あるよ。未完成なだけで。
256:デフォルトの名無しさん
09/07/21 12:19:54
>>255
Concept-gcc のこと？あれは開発が止まってるわけだが。
clang はエラー報告機能が強化されているらしいが、
いずれconcept 無しで concept 有りのとき並みの
エラーメッセージがでるようになるかな？それは無理かな？
まあまずは C++ をコンパイル出来るようになってもらわないといけないが...
257:デフォルトの名無しさん
09/07/21 12:25:03
>>243
つまり、5年先の将来のバージョンには
含めたいってことなのかな。
258:デフォルトの名無しさん
09/07/21 12:28:06
>>256
おちつけ
259:デフォルトの名無しさん
09/07/21 13:34:50
>>257
Committeeに近い人の話は大体そういう感じだね。
260:デフォルトの名無しさん
09/07/21 20:48:17
>>257そのペースなら、boost::conceptを安心して使えるってことかな？
boost::conceptは既存のSTLと一緒に使えるし。
261:デフォルトの名無しさん
09/07/21 20:55:42
>>243を拙い英語力で訳してみた。
>委員会は、コンセプトを現在作業中バージョンの標準から取り除く事を表明した。
>（コンセプトの）完成と公開には最低２年、可能なら５年は必要だと見積もられたからである。
>
>他の沢山の魅力的な機能は既に固まった。また現在の標準は（策定されてから）１０年以上経った。
>これは長すぎる遅れであろう。
>
>これは辛い決断だった。コンセプトの撤回など誰も喜ばない。しかしこれは一対一の選択である
>－－５年の（コンセプトの）遅れか、誰も使わないコンセプトかの－－それははるかに悪い（？）。
262:デフォルトの名無しさん
09/07/21 21:36:58
最後の段落だけ。
困難な選択だったし、誰も Concepts を削りたくはなかったが、代替案(5 年の遅れか、使いものにならない Concepts の標準化)より遥かにマシだった。
263:デフォルトの名無しさん
09/07/21 21:52:54
簡単な部分だけというわけにはいかないのかな
定義本体のないコンセプトだけとか
264:デフォルトの名無しさん
09/07/21 21:59:56
>>262
unusableは「使えない」「使いにくい」でいいんじゃないかな。
STLがconcept化されてないことを言っているんだと思う。だから、
>>263
それが、
> standardizing an unusable version of concepts
で、
> were far worse.
だと。
265:デフォルトの名無しさん
09/07/22 01:02:37
Conceptsのプロポーザルを書いた一人であるJeremy Siekのコメント
URLﾘﾝｸ(lambda-the-ultimate.org)
これとは直接関係ないが、標準ライブラリでconceptを使うのをやめた時点で
終わってたのかもな
266:デフォルトの名無しさん
09/07/22 01:19:08
concept-based overloading なんかを念頭に置くと
どうしても explicit concept のほうに好みが偏ってしまうかもね
みんな implicit か explicit どっちのほうが好みなんだろうか
267:デフォルトの名無しさん
09/07/22 06:27:08
両方ないと使いづらい。
268:デフォルトの名無しさん
09/07/23 00:03:38
禿自らの記事きたわ
URLﾘﾝｸ(www.ddj.com)
269:デフォルトの名無しさん
09/07/23 01:15:43
現状のテンプレートが実装されるまでにもかなりかかったし、そんなペースでいいんだけど。
遅れた分だけ仕様が洗練されるならいいけど、実装が遅れるだけなら前と一緒だし入れて欲しかった。
270:デフォルトの名無しさん
09/07/23 21:13:41
次に消される機能は何かなーﾜｸﾜｸ
271:デフォルトの名無しさん
09/07/23 22:17:01
exceptionを消せよ
邪魔過ぎ
272:デフォルトの名無しさん
09/07/23 22:27:05
まあ例外クラスは新しく作り直してもいいと思う、今のを全部非推奨にして。
273:デフォルトの名無しさん
09/07/23 23:02:02
バベルの塔は崩れゆく
274:デフォルトの名無しさん
09/07/23 23:24:13
Perl6の末路と良く似てるな
275:デフォルトの名無しさん
09/07/23 23:25:54
C++1xのxがいくつになることやら
276:デフォルトの名無しさん
09/07/24 01:34:39
五年後を考えているようだが。
> Bjarne Stroustrup
> Maybe a significantly improved version of "concepts" will be available in five years.
277:デフォルトの名無しさん
09/07/24 01:41:08
もうC#でいいよ。
278:デフォルトの名無しさん
09/07/24 01:52:56
敢えてのDで
279:219
09/07/24 02:17:06
何処から叩き出されて流れ着いたのかツマラン奴がスレに居付いてるな
280:デフォルトの名無しさん
09/07/24 02:28:20
9割つまらん奴だろう2chなんて。
281:デフォルトの名無しさん
09/07/24 13:39:16
全人類の9割はつまらん奴だから気にするこたあない
282:760
09/07/24 15:05:13
>>277
constとtypedefの無いC#は地獄
283:デフォルトの名無しさん
09/07/24 18:07:03
constを真面目に使ってる奴はほとんどいないし
typedefも型を不完全に隠蔽するだけの邪悪な機能としてよくやり玉に挙がる
なんだこいつらもコンセプトと一緒だな
284:デフォルトの名無しさん
09/07/24 18:15:24
typedefなかったらSTLどうすんだよ。
285:デフォルトの名無しさん
09/07/24 18:37:34
typedefの糞なところは
typedef char hoge;
してhogeの型エラーがでても
エラーメッセージにはcharしか表示されないってとこだっけ
286:デフォルトの名無しさん
09/07/24 19:31:59
いりまくるよぉ、const
constないとconst付けないメソッドとかconst付けない引数とかどう書けばいいんだよ
287:デフォルトの名無しさん
09/07/24 19:33:45
const/immutateも弱いtypedef/強いtypedefもあるDでよくね?
288:デフォルトの名無しさん
09/07/24 19:55:47
DはGC外してから出直してこい
289:デフォルトの名無しさん
09/07/24 20:20:45
>>285
VC++2005つかってるけど、警告最大にして
char c = hoge
とかやったら警告で両方の型が表示された気が。
これって別に規格で定められてるわけじゃないのか。
290:デフォルトの名無しさん
09/07/24 20:29:10
もしDから完全にGCを取り去って使うことができたらC++から移住してしまう人いるのか？
ずっと安定し（て）ないからいないだろ
291:デフォルトの名無しさん
09/07/24 20:37:20
もしGCがなくて安定したDがあれば是非移住したいね
どっちの条件も叶いそうにないが
292:デフォルトの名無しさん
09/07/24 20:56:47
>>282
usingがある程度まではC++のtypedefみたいに使えるぞ。
using HWND = System.IntPtr;のように書ける。
293:デフォルトの名無しさん
09/07/24 21:53:45
>290
俺的にはDよりもLinqのないネイティブなC#の方がいいな
GCは別にフレームワークで実現するからいらない。動作が確定的なCと互換性のある
言語が欲しい
294:デフォルトの名無しさん
09/07/24 22:03:01
Linqはいるだろ。
いや、クエリ式は無くてもいいが、Enumerableクラスは必須。
これがないC#なんて、<algorithm>なしのC++と一緒。
ないと使う気になれない。
295:デフォルトの名無しさん
09/07/24 22:09:15
>294
ああ、そっちは確かに。ただ、クエリ構文はいらん
Dはそんな言語を目指していると思っていたんだがなぁ
296:デフォルトの名無しさん
09/07/25 01:26:33
俺は純粋C++派だけど、query構文は面白いと思う。
297:デフォルトの名無しさん
09/07/25 02:57:10
つまりExpression Templateを駆使したboost/linqとかあればいいわけですねわかりますわかりたくもありません
298:デフォルトの名無しさん
09/07/25 04:02:18
CLinqのことですね。わかります
299:デフォルトの名無しさん
09/07/25 06:26:10
>>298
わざわざ構文にする必要性ってあるのか？
使いやすいSQL操作ライブラリは結構あるけど
そういうのじゃ足りない？
300:デフォルトの名無しさん
09/07/25 09:02:45
Linqは各種のデータに統一構文でアクセスできるのが強みであって、
必ずしもクエリ式を言語に埋め込む必要はないと思うな。
301:デフォルトの名無しさん
09/07/25 10:12:33
>>299
リアルSQLだけしか扱わないならLinqは必要ない。
言語に近いレベルでの統一的枠組みであることが重要。
関数型言語の内包記法のように。
302:デフォルトの名無しさん
09/07/25 10:34:10
一方D言語は、
auto result = linq!q{
from n in numbers
where n % 2 == 0
select n
};
303:デフォルトの名無しさん
09/07/25 10:48:48
linqとか本来の言語仕様と異なる表記方法を含めるのってどうなのかなあ？
304:デフォルトの名無しさん
09/07/25 11:15:09
テンプレートとプリプロセッサの黒魔術で無理矢理DSLを作ってどうにかする方がマシってか？
305:デフォルトの名無しさん
09/07/25 16:26:01
>>304
たとえばテンプレトメタ黒魔術で生まれたboost::spiritも一応C++の文法の範疇だから、既存コードとの整合性も楽だと思う。
306:デフォルトの名無しさん
09/07/25 16:43:24
自分を相当ラディカルだと思ってる俺でもspiritが黒魔術の許容限界ラインだな
307:デフォルトの名無しさん
09/07/25 17:42:23
spirit v1の方は割と素直なTMPの実例に思えてきた
v2は無理
308:デフォルトの名無しさん
09/07/25 17:50:11
俺はsprintfでいいよ。
309:デフォルトの名無しさん
09/07/25 17:51:23
つまりboost::lambdaがあればラムダ構文なんて不要ということですね。わかりますよ。わかりますよ。
310:デフォルトの名無しさん
09/07/25 19:09:41
ラムダさんが教室の隅で怯えています
311:デフォルトの名無しさん
09/07/25 22:36:55
これをboostにだな
URLﾘﾝｸ(www.codeproject.com)
312:デフォルトの名無しさん
09/07/26 00:28:31
_1とかキモすぎて使う気がおきない
313:デフォルトの名無しさん
09/07/26 00:50:57
ムリムリのテンプレートが必死すぎてキモイから
次の改定では構文を拡張できるようにした方がいいな
314:デフォルトの名無しさん
09/07/26 00:59:57
そろそろCとの互換性をあきらめた
cppppが欲しい
315:デフォルトの名無しさん
09/07/26 01:07:23
>>314
D……いやなんでもない
316:デフォルトの名無しさん
09/07/26 01:16:46
C#だろ、それ
317:デフォルトの名無しさん
09/07/26 01:44:44
DもC#もcppppとは言いがたいな
318:デフォルトの名無しさん
09/07/26 02:40:47
cppppである条件ってなによ
319:デフォルトの名無しさん
09/07/26 03:48:17
プリプロセッサなんだからC++自体と独立なんじゃね。
320:デフォルトの名無しさん
09/07/26 10:29:40
>>318
プログラマがその気になれば、
Cで書かれたコード断片と同じ実行効率にできること。
321:デフォルトの名無しさん
09/07/26 14:21:05
>>320
その気にならなくても、速い言語もあるぞ。
322:デフォルトの名無しさん
09/07/26 17:40:46
>>321例えば？
323:デフォルトの名無しさん
09/07/26 18:59:50
C++
324:デフォルトの名無しさん
09/07/26 19:13:54
あとアセンブリくらいしかなくね？ｗ
325:デフォルトの名無しさん
09/07/26 20:09:21
forth
326:デフォルトの名無しさん
09/07/26 22:10:49
C++と同程度の抽象度を持っていなければ比較する意味ないだろ
327:デフォルトの名無しさん
09/07/26 22:25:53
>>320
lisp
328:デフォルトの名無しさん
09/07/26 22:41:57
forth
329:デフォルトの名無しさん
09/07/27 08:01:26
>>320
まさにDだろｗ
330:デフォルトの名無しさん
09/07/27 09:51:09
COBOLもフォートランもCと同等に速いよ。
COBOLやフォートランでは、OS書けないけど。
331:デフォルトの名無しさん
09/07/27 18:08:04
>>329
ガーベージコレクションがあるので不完全。
332:デフォルトの名無しさん
09/07/27 18:09:25
cのコード走らすだけならGCいらんし．
333:デフォルトの名無しさん
09/07/27 18:19:40
GCありで書かれたコードとGCなしで書かれたコードを
混ぜて走らせるほど恐ろしいことはないと思うんだ
334:デフォルトの名無しさん
09/07/27 20:20:49
> COBOL
が、早いのか?
> フォートラン
載ってるマシンと処理系にもよるけど、
数値計算は C じゃ太刀打ち出来ねぇよ
>>333
メモリマネージメントをまじめに考えてない言語の話だろ?
lisp 系の言語はその辺ちゃんとやってるぞ
# 中には、出来の良くない奴もあるらしいけど…
335:デフォルトの名無しさん
09/07/27 20:44:39
標準を作ってる人たちがやりたいことと、一般のニーズが違うんだよなぁ
>334
managed c++という怖ろしい言語があってだな
336:デフォルトの名無しさん
09/07/27 21:08:12
>>335
managed c++のFormにC++のクラスのメンバ変数を作ろうとしたら、コンパイラにできませんって言われた。
５分で挫折した。
337:デフォルトの名無しさん
09/07/27 21:32:09
どうしてもC++の資産を使わないといけない、というときでないと触れてはいけない言語だった……（遠い目
338:デフォルトの名無しさん
09/07/27 23:31:38
Objective-CとC++を混ぜた学ぶ気がカケラも起きない奴もあってな
339:デフォルトの名無しさん
09/07/27 23:40:18
C/C++のいらない部分をそぎ落として、
いい部分だけを抽出した言語がほしい
340:デフォルトの名無しさん
09/07/27 23:51:24
C#のことですね
341:デフォルトの名無しさん
09/07/27 23:58:17
>>339
なに、C++から++をそぎ落とせだと?
342:デフォルトの名無しさん
09/07/28 00:08:40
仮想関数呼ぶコンストラクタや例外投げるデストラクタにブチ切れてくれるコンパイラが欲しいです
343:デフォルトの名無しさん
09/07/28 00:37:52
DLLやライブラリにメタデータをつけて欲しいわ。メタデータの仕様こそ標準化して欲しい
344:デフォルトの名無しさん
09/07/28 00:39:34
DublinCore
345:デフォルトの名無しさん
09/07/28 00:49:00
GCCかどこかでこのDublinCoreを埋め込む動きとかあるんかいな
346:デフォルトの名無しさん
09/07/28 05:46:49
DublinCoreってHTMLとかのドキュメント向けじゃないの？
LanguageにCとか指定するのか
347:デフォルトの名無しさん
09/07/28 08:31:16
>>338
Objective-C++っていうけど、あれはObjective-CとC++をそのまま混ぜて書けるようにしただけ。
managed C++とかC++/CLIみたいに文法はいじられてないよ。
348:デフォルトの名無しさん
09/07/28 09:18:56
Objective-C++いいかも
クラステンプレートにオブジェクト埋め込んだりできるのか？物凄くグニャグニャですね
349:デフォルトの名無しさん
09/07/28 10:35:35
languageはneutralだろ
350:デフォルトの名無しさん
09/07/30 14:06:32
>>348
やってみたけどゲテモノだったよ。
最近はインスタンスのリファレンスカウントを自前で管理する他に、
gcも混在して使えるようになった
これにc++のnew/deleteが混ざるとまさにカオス
c++のインスタンスはnew/deleteで管理して、objcのインスタンスは
基本gcで処理するが、メモリ効率のために一部ではリファレンス
カウントを自前で調節する
やってられん
351:デフォルトの名無しさん
09/07/30 14:26:59
boehm GCとboostを併用するだけでもカオスになります
352:デフォルトの名無しさん
09/07/30 19:28:06
やっぱりC++/CLIみたいに新しい言語として設計するしかないんだな
353:デフォルトの名無しさん
09/07/30 21:10:55
>>352新しい言語として設計するのは一向に構わないが、
msdnのサイトみたいにC++/CLIのサンプルをC++として掲載するのは止めてほしいよな。
354:デフォルトの名無しさん
09/07/30 21:32:48
そういえば、ISOの取り下げ理由って、数年市場にもまれて出直してこい、だったっけ
規格作る前に数種類の実装がないと問題点がわからないから、Perl6みたいに
いつまでも仕様が決まらなくなるわけだな
355:デフォルトの名無しさん
09/07/30 22:50:06
>>354 ぐぐったけど、C++/CLIはC++じゃないとかにお墨付きなのに笑った。
C++/CLIって C++ + C# だから、
C++ + C# = C+++++++ = C##--で良くないかな？
356:デフォルトの名無しさん
09/07/30 22:55:14
C++/CLIはあくまでC++にCLIを融合させたものであって、C#とは違うだろう。
357:デフォルトの名無しさん
09/07/30 22:59:52
C++/CLI は該当スレで話してやれよ。住人はいてもネタがないから入れ食いだぞｗ
C++0x が纏まった後、Concept とかの仕様漏れした項目はそのまま継続協議するのか
それともいったん仕切り直して新たな標準にするのか、どっちかな
358:デフォルトの名無しさん
09/07/30 23:31:16
しばらく言語仕様には手を入れず、ライブラリの
拡充に集中してほしいな。
char16_tやchar32_tも今のままじゃ使い物にならん。
359:デフォルトの名無しさん
09/07/31 02:05:10
>>358
char16_t や char32_t にはそれなりの利用価値はあると思うんだけど、
使い物にならんというほどひどい欠陥があるの？
360:デフォルトの名無しさん
09/07/31 02:59:57
欠陥てほどじゃないけど、C++0xじゃbasic_stringぐらいしか対応していなくて、
stream系やregexで使おうとしたら、charかwchar_tに変換するしかない。
URLﾘﾝｸ(www.open-std.org)
361:デフォルトの名無しさん
09/07/31 03:17:35
>>360
いやいやいや。 char_traitsとcodecvtをちゃんと定義してるんだから、
stream系やregex系だってちゃんと動くってこれ。
ただ単に短い名前のtypedefがされていないってだけで。
362:デフォルトの名無しさん
09/07/31 03:36:24
charやwchar_tとの相互変換は用意されているんだよね？
363:デフォルトの名無しさん
09/07/31 08:40:42
>>362
charとwchar_tの相互変換と同じように、codecvtで変換できるんじゃね
364:デフォルトの名無しさん
09/07/31 13:17:29
>>357 新しい構文をむやみに増やさずにboost::conceptsをベースにライブラリとして規格を決めてほしいな。
conceptがウキペからも削除されてて詳細わかんないんだけど、boost::conceptsで足りないのかな？
365:デフォルトの名無しさん
09/07/31 13:26:33
>>354
> 数年市場にもまれて出直してこい
「市場」とかバカじゃねーの?
366:デフォルトの名無しさん
09/07/31 13:26:44
Boost::Conceptはテンプレートマジックだからエラーメッセージも大してわかりやすくならない。
それにテンプレートの展開はコンパイラ組み込みにするのと比べて速度的にかなり不利。
367:デフォルトの名無しさん
09/07/31 13:31:48
>>364
Conceptは必要ないと判断されたのではなくて、
ほとんどのメンバーが必要なものと考えていたけど、
まだ時期尚早だと判断されたのだよ。
368:デフォルトの名無しさん
09/07/31 18:49:55
C++98策定の直後から10年以上検討を続けてきた物が「時期尚早」ねぇ……
369:デフォルトの名無しさん
09/07/31 18:53:09
>>367
>>368
URLﾘﾝｸ(www.ddj.com) を読んでから物言え
370:デフォルトの名無しさん
09/07/31 19:58:52
BoostのConceptチェック使ったことあるやつなら分かると思うが、
きちんと対象に必要なコンセプトを定義してライブラリ組み立てていくのは
かなり骨が折れる。
後からちょっと型を追加したくなったりみたいなのがやりにくいし、
かといって最初からイテレータみたいなちゃんとしたモデルを
凡人がほいほいとデザインはできないし。
ドラフトのコンセプト定義が大幅に書き換えられたりしているのを見るにつけ、
偉い先生方も苦労してんだなーと。
もっとも、ばりばりのハスケラー達にとっちゃ失笑モノかもしれんけど。
371:デフォルトの名無しさん
09/08/01 06:42:49
>>368
Conceptは2003年からだよ。
原論文一つも読んだことないだろ。
372:デフォルトの名無しさん
09/08/01 06:51:36
だいぶ昔からお世話になってる SGI STL のドキュメントが Concept を使ったものになってる。
URLﾘﾝｸ(www.sgi.com)
SGI STL における Concept は C++98 以前からあったんじゃないかな？
373:デフォルトの名無しさん
09/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を使ったりできるわけではない。
374:デフォルトの名無しさん
09/08/01 09:54:54
最近スレを除いてない内にそんな事になってたのか・・
確かにconceptをちゃんと書くのはしんどかったけど
375:デフォルトの名無しさん
09/08/01 12:00:01
規格倒れで決定しそうだな。
376:デフォルトの名無しさん
09/08/01 12:03:20
GCCに実装されてしまえば規格もなにもほぼ関係ないからどーでもいいよ
377:デフォルトの名無しさん
09/08/01 12:11:44
GCCは実装しないと思う
378:デフォルトの名無しさん
09/08/01 12:29:47
コンパイラだけ対応してもライブラリが対応しないと誰も使わないだろうに。
379:デフォルトの名無しさん
09/08/01 13:46:12
結局わけのわからないコンパイルエラーメッセージと格闘し続けなければならんのか
380:デフォルトの名無しさん
09/08/01 14:11:22
ライブラリの対応なんか別にどーでも良くて
継承や関数オブジェクトがこ綺麗に書けるモノと期待してたのに
381:デフォルトの名無しさん
09/08/01 14:46:03
>>380
標準ライブラリが対応すればエラーメッセージがかなり読みやすくなるんだから
どうでもいいということは断じてない。
382:デフォルトの名無しさん
09/08/01 16:22:27
>>372
そのconceptは一般名詞の「コンセプト。」
C++0xから外された言語機能のconceptは、
そのような概念を直接サポートするために考えられたもの。
383:デフォルトの名無しさん
09/08/01 16:24:12
つーか「Concepts and Modeling」ってなってるのに気づけないってどんだけだよ
384:372
09/08/02 01:27:43
>371 を読んで、 Concept という考え方自体が 2003 に現れたものであるかの
ように読めんたんで、そうでもないよ、と思って書いたんだ。
最初から言語機能としての Concept の話だったんなら、ごめんよ。
385:デフォルトの名無しさん
09/08/03 22:14:38
const std::string hoge()の様なconst で返す関数がいっぱいあるんですけど
C++0xで右辺値参照を適用させるにはstd::string hoge()に直す必要ありますか？
386:デフォルトの名無しさん
09/08/03 23:05:21
え
387:デフォルトの名無しさん
09/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());
}
388:デフォルトの名無しさん
09/08/03 23:29:43
そりゃ、const stringはstringに暗黙変換されないだろ。されたら怖いわ。
389:デフォルトの名無しさん
09/08/04 01:53:50
>>387
> 前にドラフトとか読んで
> 実際VC++10βだと
お前アホだろ。
読めてない癖に「読んで」かよ。
390:デフォルトの名無しさん
09/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でも左辺値で取れますが？
391:390
09/08/04 12:54:35
あ×左辺値○右辺値の間違いだった。
このタイミングで間違えるとか駄目すぎるな俺
392:デフォルトの名無しさん
09/08/04 15:22:15
全然関係ないけど
string foo() {
string temp;
return temp;
}
のような内部変数を値渡しで戻す場合って
コンパイラの最適化でコピーをはしょっていいことになってたよね？
393:デフォルトの名無しさん
09/08/04 15:30:56
NRVOのことかな
394:デフォルトの名無しさん
09/08/04 15:33:49
>>392
初心者質問スレへGO!
395:デフォルトの名無しさん
09/08/04 16:21:48
ぬるぼっ！
396:AAなしのやっつけ感がいいね
09/08/04 16:37:46
がっ！
397:デフォルトの名無しさん
09/08/04 19:11:48
>>394
内容的には初心者でもないでしょ。
398:デフォルトの名無しさん
09/08/04 21:05:04
C++0x特有でもなし。
399:デフォルトの名無しさん
09/08/04 21:47:17
ここから右辺値参照の話しに広げるつもりとか
400:デフォルトの名無しさん
09/08/05 00:04:40
>>390
const右辺値参照って使い道ある？
401:デフォルトの名無しさん
09/08/05 00:54:58
URLﾘﾝｸ(www.informit.com)
(超訳？URLﾘﾝｸ(slashdot.jp))
によると、
>Concepts are dead for good.
(>コンセプトは死んだ。永遠に。)
だそうなんだが、マジか？
つか、informITって記事の信頼性はどれくらい？@ITくらい？
402:デフォルトの名無しさん
09/08/05 00:57:15
URLﾘﾝｸ(www.informit.com)
(超訳？URLﾘﾝｸ(slashdot.jp))
によると、
>Concepts are dead for good.
(>コンセプトは死んだ。永遠に。)
だそうなんだが、マジか？
つか、informITって記事の信頼性はどれくらい？@ITくらい？
403:401-402
09/08/05 00:59:05
連投すまん。なんかまちがってもーた。
404:デフォルトの名無しさん
09/08/05 01:10:14
>>400
const左辺値参照を受け取れる
405:デフォルトの名無しさん
09/08/05 01:15:31
>>401
だからそれは記事書いた人間の予想だろ？
GCを例に挙げて持論を補強しているが、禿も含めてどうなるかは誰も分からんよ。
C++0xも無理になったわけだし、仮にC++10が策定されたとして、次の標準はいつ
になるのか、と考えると悲観的になるのも分かるが。
406:デフォルトの名無しさん
09/08/05 14:27:31
さよならC++
407:デフォルトの名無しさん
09/08/05 14:38:20
C++ Must Go
408:デフォルトの名無しさん
09/08/05 18:11:57
一旦標準に入りかけてひっくり返されたなんて曰く付きの機能を
好んで実装したり使ったりしようとする人がどれくらいいるかな
409:デフォルトの名無しさん
09/08/05 18:14:02
知ったかも大概にしろよ
410:デフォルトの名無しさん
09/08/05 18:20:11
ConceptはHaskellのType ClassでConcept MapはType Instanceだから
Haskell好きの人なら使いたいと思うかもしれない
ちなみにテンプレートは型族っていうHaskellでもまだまともに使えないフィーチャーに相当する
C++恐しい子！！
411:デフォルトの名無しさん
09/08/06 00:06:55
URLﾘﾝｸ(www.open-std.org)
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
412:デフォルトの名無しさん
09/08/06 03:20:18
＞N2930 09-0120 Range-Based For Loop Wording (Without Concepts)
＞N2943 09-0133 Allocators without Concepts (preview)
コンセプトさんは本当に死んでしまったんですね……
413:デフォルトの名無しさん
09/08/06 09:34:23
一度も学校に来なかったコンセプトさんの机に"without concepts"と書かれた花瓶だけがひっそりと残った
414:デフォルトの名無しさん
09/08/06 09:43:29
Conceptは死なん何度でも甦るさ
415:デフォルトの名無しさん
09/08/06 12:33:07
C++1xになるって、マジ？
416:デフォルトの名無しさん
09/08/06 14:11:58
そのxは16進だと思ってたが
417:デフォルトの名無しさん
09/08/06 14:15:53
>>415
マジ
418:デフォルトの名無しさん
09/08/06 23:27:08
もうC#でいいよ。
419:デフォルトの名無しさん
09/08/07 06:53:38
16進数でもC++1xになりそうな勢いですけどね
420:デフォルトの名無しさん
09/08/07 07:20:12
それを言うならC++0x1だろうが
421:デフォルトの名無しさん
09/08/07 07:25:47
何度も同じことばかり言ってアホか
422:デフォルトの名無しさん
09/08/07 08:53:14
新喜劇みたいなもんだ
423:デフォルトの名無しさん
09/08/07 09:02:44
>>420
1かよw
424:デフォルトの名無しさん
09/08/07 09:26:25
C++0x1y
425:デフォルトの名無しさん
09/08/07 09:32:19
他でやれカス
426:デフォルトの名無しさん
09/08/07 10:00:35
What Happened in Frankfurt?
URLﾘﾝｸ(cpp-next.com)
Conceptの歴史的経緯と、今回の削除に至った理由について、
あのDouglas Gregorさんが書いている。
読んでおくべきだと思う。
拙約
URLﾘﾝｸ(cpplover.blogspot.com)
427:デフォルトの名無しさん
09/08/07 10:12:49
Conceptが載ったとしても使う予定なんて特に無いんだろ？おまえら
本当に必要なら、boost入れてでも今すぐ使ってるハズ。
428:デフォルトの名無しさん
09/08/07 10:18:46
>>427
愚かなことを口走る前にログ読んでこい
429:デフォルトの名無しさん
09/08/07 11:06:40
>>426
サンクス。非常に興味深い記事だった。
やはりIndianaとTexasの意見の対立が最後まで解消されなかったということか。
430:デフォルトの名無しさん
09/08/07 11:11:32
>>426 乙
もうあれだ。
enable_ifを組み込みにしてエラーメッセージを分かりやすくすればいいんじゃね。
static_assertも組み込みになったんだし。
431:デフォルトの名無しさん
09/08/07 16:05:53
>>430
enable_ifやstatic_assertが組み込みになったてことは、boost/concept_check.hppなどmpl
が少しは高速化されるのかな？
432:デフォルトの名無しさん
09/08/07 18:27:34
落ち着け
enable_ifは組み込まれてない
433:デフォルトの名無しさん
09/08/07 18:37:36
>>429
意見の対立とは読めないなあ。
方向が二つあってうまく中庸に整理できなかっただけで。
この後うまい決着点を見つけるんじゃないでしょうか。
434:429
09/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.
435:デフォルトの名無しさん
09/08/07 19:23:05
もうやめてあげてこんせぷとのひっとぽいんとはぜろよ
436:デフォルトの名無しさん
09/08/07 19:35:32
conceptとconcept mapは、もう少し分けて作ったほうが良かったんじゃないかと思う。
そもそもが二つの異なる提案だった歴史的理由もあるのだろうけど。
例えばこんな感じ。
conceptは、テンプレートを使ったコードの、コンパイル時のエラーチェックのみに使う。
conceptの利用に、concept mapを使う必要はないぐらい、concept mapから独立しているべき。
concept mapも、conceptの宣言に合うように既存の型を変えるという機能を提供する。
conceptに依存するのは、あくまでconcept map自体のエラーチェックをするためだけ。
利用方法も、もっと枠を広げて、conceptやテンプレート以外のコードから使えるようにしてもいいと思う。
437:デフォルトの名無しさん
09/08/07 19:43:19
あとそれから、現状のtemplateコードで出来ることは、ぜんぶconceptで記述できるようにするべきだと思う。
例えば、現行のconceptの規格だと、メンバ変数を記述することが出来ない。
その理由については、コードをよりジェネリックにする等の言い分があるのだろうけれど、
普通のtemplateコードで出来ることが、constrained templateなコードでは出来なくなるというのでは、
conceptの使用をためらう人が出てくると思う。
438:デフォルトの名無しさん
09/08/07 19:45:53
templateの使用さえためらう奴が多いのに何を今さら
439:デフォルトの名無しさん
09/08/07 19:48:40
× templateの使用さえためらう奴
〇 templateの使用さえ禁止されている現場
440:デフォルトの名無しさん
09/08/07 20:25:47
そうは言ってもtemplateを完璧にコンパイルできる処理系は未だにないわけで…
441:デフォルトの名無しさん
09/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
辺りの修正が可能。
> 最後まで解決出来なかったということ。
次の標準がある。
442:デフォルトの名無しさん
09/08/07 21:06:13
>>441
それで中庸にはならないだろ。
> 次の標準がある。
次が無いなどとは言ってないが。
443:デフォルトの名無しさん
09/08/07 21:08:27
>>442
空のconcept mapを書かないでいいってのは
両者の中間でいいんじゃないの?
444:デフォルトの名無しさん
09/08/07 22:45:40
単純化すると、実装者の都合とユーザー利益のどちらを重視するか、
という議論だよね。Bjarne はユーザー利益を譲らないから、最後に
なってあのレポートを出した。しかしまさか削除になるとは思って
なかったフシがあるね。難しいもんだ。
445:デフォルトの名無しさん
09/08/07 22:52:54
いや、禿も正直あきらめていたんじゃね。
禿がSimplifying the use of conceptsを書くまでに数百通のMLでの議論、
書いた後も、そのペーパーを巡って数百通の議論だから、
到底、意見が一致するわけがないことぐらい分かりきっていただろ。
446:デフォルトの名無しさん
09/08/07 23:00:42
>>444
どっちもプログラマのこと考えてるんだよ。
templateの特殊化のように強力なexplicit concept mapをどうするか。
便利だから必要←→ややこしくなるから省いた方がいい
447:デフォルトの名無しさん
09/08/07 23:03:15
>>445
"Simplifying the use of concepts"は、
禿のC++0xへのconcept最終提案だよ。
この新しいconcept提案に入れ変えるか、
これまでのdraft通りのconceptを入れるか、
conceptを廃止するかの投票。
448:デフォルトの名無しさん
09/08/07 23:29:27
中途半端なやさしさのせいでカオスになった型変換規則という悪しき前例があるからなぁ
基本的にimplicityは悪だと思う
禿ペーパーを最初に見たときは勘弁してくれと正直思った
449:デフォルトの名無しさん
09/08/07 23:33:34
しかし、あれは禿の意見に賛成だがな。
conceptは自動でconcept_mapを生成すべきだろ。
明示的にconcept_mapを書かせたい場合だけ、これまた明示的にexplictを書くという方が、
人間的で分かりやすいと思うんだけどな。
450:デフォルトの名無しさん
09/08/08 00:11:37
禿はそんな提案してないじゃん
451:デフォルトの名無しさん
09/08/08 00:17:43
こうやってもつれて行くわけだなｗ
452:デフォルトの名無しさん
09/08/08 02:34:57
C++1hでいいよ
453:デフォルトの名無しさん
09/08/08 06:15:26
Bjarne Stroustrup Expounds on Concepts and the Future of C++
URLﾘﾝｸ(www.devx.com)
URLﾘﾝｸ(www.devx.com)
URLﾘﾝｸ(www.devx.com)
URLﾘﾝｸ(www.devx.com)
禿が今回のことについて語っている。
少々長いし、4ページに分かれているが、読むべき。
454:デフォルトの名無しさん
09/08/08 10:51:53
>>453
読むから翻訳して
455:デフォルトの名無しさん
09/08/08 12:35:39
>>453
全部読んだけど、これ本当に長いな。舐めたような酷い質問をしまくりで
禿も内心かなり頭にきた部分もあっただろうが、我慢強く答えてる。
456:デフォルトの名無しさん
09/08/08 13:06:30
>>453
Bjarne は本当にできた大人だな。涙が出るよ。これからも頑張って欲しい。
まだ先の事だろうけど、Bjarne がいなくなった後の C++ が心配。
457:デフォルトの名無しさん
09/08/08 16:44:22
禿がいなくなったらなくなるだろうな
アプリ系はJava/C#に完全移行してミドル以下はCに戻る
458:デフォルトの名無しさん
09/08/08 16:53:11
Java はわかるが C# は…どうだ？
今のところ Microsoft しか扱ってないからなぁ。
459:デフォルトの名無しさん
09/08/08 16:59:09
曲がりなりにもISO標準なのだから、禿がいなくなったからと言って
無くなることはない。
まあGCCがC++をアクティブにサポートし続ける限りは安泰だろう。
460:デフォルトの名無しさん
09/08/08 17:30:32
安泰とかばかじゃね？
仕事で使えねーよ、こんな仕様じゃよ。
461:デフォルトの名無しさん
09/08/08 17:31:07
仕様のせいにするなよ。才能だよ。
462:デフォルトの名無しさん
09/08/08 17:34:13
安泰ってのはお前がこれからもまともに使いこなしていけるかって意味じゃねーんだよ
463:デフォルトの名無しさん
09/08/08 18:08:51
>>460
知能の低い者はお引き取りください
464:デフォルトの名無しさん
09/08/08 21:43:53
良くも悪くも禿の天才的センスに支えられた変態マニアック言語という側面と、
Cに次ぐ世界標準のネイティブ開発言語という側面と、
明らかに共存しそうにない二つの側面が共存しちゃってるからなぁ
465:デフォルトの名無しさん
09/08/09 00:10:02
>>458
今でもすでにJavaよりC#の方がプログラマー多い。
SUNが悲惨だからJavaの将来の方が不安かと。
466:デフォルトの名無しさん
09/08/09 00:39:21
>>463
その場合C++は滅亡する
467:デフォルトの名無しさん
09/08/09 01:16:18
C#の方がJavaよりプログラマ多いって…そんな、ご冗談を＾＾
468:デフォルトの名無しさん
09/08/09 14:15:14
つーかプログラムなんて、専門学校卒の仕事だろ？
大学でてプログラムなんてバカじゃね？
道具は簡単に使えればそれにこしたことはないんだがな。
469:デフォルトの名無しさん
09/08/09 14:34:35
専門卒の仕事さえ出来ない大卒
470:デフォルトの名無しさん
09/08/09 14:52:43
スレ違いはお引き取り願います
471:デフォルトの名無しさん
09/08/14 23:52:20
>>453を翻訳
URLﾘﾝｸ(cpplover.blogspot.com)
正直疲れた。
質問者のDanny Kalevがウザすぎる。
その分、訳すのは楽しかったが、禿に対しては、あまりに無礼じゃないかと思う。
472:デフォルトの名無しさん
09/08/15 00:13:05
>>471
乙
473:デフォルトの名無しさん
09/08/15 00:47:58
>>471
YOUは最高だ。日本のC++コミュニティにとっていい仕事をした。誇っていい。
474:デフォルトの名無しさん
09/08/15 00:57:35
>>471
面白かった。お爺さんと孫の問答みたいだった。
さらに、色々解って実用面でも効果テキメンですよ。
475:デフォルトの名無しさん
09/08/15 01:07:35
Alexが1976年からSTL作ってた事にびっくりだよ
476:デフォルトの名無しさん
09/08/15 01:16:42
ヒャッハーッ！
477:デフォルトの名無しさん
09/08/15 05:04:35
>>471
ブログの宣伝するな速やかに削除依頼出して死ねカス
478:デフォルトの名無しさん
09/08/15 05:24:03
いかにも私は学歴低いですって感じの煽りに吹いた
479:デフォルトの名無しさん
09/08/15 09:44:30
言い方はともかく、DKが質問した内容はここで愚痴っていた内容と変わらんな。GCはいらんけど
頭の悪い一般のC++ユーザーが委員会に対して感じていた不満をぶつけたような記事だ
480:デフォルトの名無しさん
09/08/15 09:57:44
じじい口調が気に食わん。
禿はオカマ言葉であるべきだ。
481:デフォルトの名無しさん
09/08/15 10:17:45
あれでDannyが委員会のメンバだったっていうのが信じられない。
482:デフォルトの名無しさん
09/08/15 10:51:15
でも誰もが聞いてみたかったことだろ？
483:デフォルトの名無しさん
09/08/15 11:23:26
確かに禿はおかま口調の方が実際の声に近い感じがあるな。
484:デフォルトの名無しさん
09/08/15 11:31:02
そんなにカマ臭いのかと動画をググってしまったじゃねーか。
納得。
485:デフォルトの名無しさん
09/08/15 11:33:13
訳文だけ読んだ感じだとガチ問答でなくFAQ的なやらせ問答みたいだな。うざくて無礼なのはキャラ作りじゃないの。
486:デフォルトの名無しさん
09/08/15 19:17:24
>>471
やる！本文以外も翻訳するとは！
487:デフォルトの名無しさん
09/08/15 20:05:45
>>475
Adaのgenerics機能で実装していたからね。
488:デフォルトの名無しさん
09/08/15 23:27:28
「○○の機能を使うのは一部のプログラマだから、
その機能が入っていても複雑ではない」っていう論法はどうなんだろう。
完全にライブラリとして閉じていたりすれば、そうなんだろうけど。
489:デフォルトの名無しさん
09/08/16 00:09:47
びょーんびょーん
490:デフォルトの名無しさん
09/08/16 00:16:03
>>488
演算子のオーバーロードなんかそれじゃないかな。
std::complexを使えば最初から言語に複素数が組み込まれていたかのように複素数が使える。
しかも、演算子のオーバーロードの書き方を知らなくてもライブラリユーザーは自由に複素数を使える。
491:デフォルトの名無しさん
09/08/16 00:17:05
ライブラリ記述用C++と利用者用C++が必要だ
492:デフォルトの名無しさん
09/08/16 00:18:34
利用者用C++ってC#だろ
493:デフォルトの名無しさん
09/08/16 00:22:45
std::complexも罠の多いライブラリだからなぁ
中身知らずに使い切るのは難しいよ
494:デフォルトの名無しさん
09/08/16 00:25:15
ぜんぜんインペーできてねージャンww
495:デフォルトの名無しさん
09/08/16 00:36:56
templateにエラー出しコードを仕込める様になればいいんだよ。
496:デフォルトの名無しさん
09/08/16 00:54:49
コンパイラ拡張用インタプリタ言語を規定すれば良いんだよ。
497:デフォルトの名無しさん
09/08/16 01:15:17
conceptの文法って、templateバリバリ作る人向けでしょ。
templateまで作れるレベル。
classは作れるレベル。
ただ利用するレベル。
みたいな、一種のセキュリティレベルが必要か。
498:デフォルトの名無しさん
09/08/16 02:41:57
何のために？
499:デフォルトの名無しさん
09/08/16 08:38:59
>>497
かなり見当違いですね。
papers読めとまでは言わないけど、
>>453くらい読んで理解しようよ。
500:デフォルトの名無しさん
09/08/16 09:13:00
>>497
ただ利用するレベルの人が、listのコンテナをsortに渡そうとしてエラーが
てんこ盛りになったときにこそconceptが必要でしょう。
501:デフォルトの名無しさん
09/08/16 10:40:15
てか別に自分で作るtemplateが従来通りエラーぐちゃぐちゃでいいならconcept使う必要もないわけでなぁ
単に既存のtemplate使うだけならconceptがどんなものか知る必要もないし
502:デフォルトの名無しさん
09/08/16 11:18:24
>>500
それは、conceptの機能の必要性であって、
conceptの定義文法を書けることの必要性（プログラマの能力）じゃないでしょ。
>>499
ストラウストラップの言ってることは、
「C++は複雑化していると言われるが、追加機能はどれも必要な機能だ」
「みんながみんな、C++を詳細に理解する必要はない」
「そういう詳細まで理解してプログラミングする人間は一部でいいし、実際に一部だ」
「プログラマは、自分の問題解決に必要な知識までを持てばいいんだ」
ってことじゃないの？
503:デフォルトの名無しさん
09/08/16 11:58:59
確かに詳細まで理解してプログラミングしなくていい様にはできてる
(ただしプログラムが正常動作している時に限る)
504:デフォルトの名無しさん
09/08/16 12:50:49
>>502
確かに禿が言っているのは大体その通り。
でも現状のSTLなんかはエラーが出たときに多少は実装を知らないと対処するのが
難しい面もある。慣れの問題とも言えるが。
Conceptsによってその辺の敷居が大幅に下がると期待してたんだがな。
505:デフォルトの名無しさん
09/08/16 12:58:40
>>471
このスレにはりついててよかった
506:デフォルトの名無しさん
09/08/16 14:18:40
URLﾘﾝｸ(cpplover.blogs) pot.com/2009/08/bjarne-stroustrupconcept_14.html
507:デフォルトの名無しさん
09/08/17 10:09:54
>>502
conceptはクラスライブラリの仕様をプログラムの中に陽に記述し、
それをコンパイラに検証させるために非常に重要って肝心のが抜けてるじゃない。
そこを理解できてないから、>>497を妄想だけで書いてしまう。
>>471が張られてても理解できないなんて信じられない。
508:デフォルトの名無しさん
09/08/17 11:25:31
Danny Kalev役を演じているだけでしょう…
509:デフォルトの名無しさん
09/08/17 11:33:16
件のinterviewでのDanny Kalevもまた平均的なC++プログラマを演じているだけなんだけどね
510:デフォルトの名無しさん
09/08/17 11:45:10
>>509
こいつDanny Kalevじゃね？
511:デフォルトの名無しさん
09/08/17 11:49:36
原文を読んでたら>>509のような捻くれた見方は有り得ないんだが。
512:デフォルトの名無しさん
09/08/17 12:15:33
まあ、DKのような挑発的な質問をするには、これまでの経緯を知っている必要があるぜ。
このスレには、まともにドラフトもペーパーも読まず、
脳内規格とペーパーのタイトルだけで分かった気になっている奴がいるようだな。
513:デフォルトの名無しさん
09/08/17 21:05:22
で、結局俺らは引き続きコンパイルエラーの
謎メッセージと戦い続ける事になっちゃったの？
514:デフォルトの名無しさん
09/08/17 21:30:30
Conceptでエラーメッセージが分かりやすくなるとかいうのは
都市伝説だから
試しにConceptGCCで(うわなにをするやめｒ
515:デフォルトの名無しさん
09/08/17 21:41:20
あれはエラー報告の実装が腐ってるだけ
Boost.ConceptCheckを使って
grepでconcept_check_failedがある行でフィルタするだけでもかなり違う
516:デフォルトの名無しさん
09/08/17 23:14:44
static_assertと<type_traits>でコンセプトの代わりは大体出来る
mapはできないけど
517:デフォルトの名無しさん
09/08/17 23:18:43
>>515
まあだからそれもあんまり良くなかったんじゃないの
ConceptGCCというのがあるみたいだし、
ちょっとコンセプトとやらを試してみるかーって時に
そこが腐ってたら、そりゃなんだコレってことになるわけで
518:デフォルトの名無しさん
09/08/17 23:27:09
それをするなら、コードから、コンパイラ自体にメッセージを表示させる仕組みが欲しいよな。
VCの#pragma messageみたいに。
519:デフォルトの名無しさん
09/08/17 23:44:35
Javadocのコメント文法を言語仕様に含めてもらいたいな
520:デフォルトの名無しさん
09/08/17 23:53:42
そんなことしたらまた仕様が膨れるじゃないか
doxygenで十分
521:デフォルトの名無しさん
09/08/18 00:32:13
膨れて何が悪い
522:デフォルトの名無しさん
09/08/18 00:35:47
理由も分からん馬鹿か
523:デフォルトの名無しさん
09/08/18 00:38:32
と言って説明せずに逃げるアホ
524:デフォルトの名無しさん
09/08/18 00:48:55
説明しろだとか、さすが夏だな
525:デフォルトの名無しさん
09/08/18 00:51:13
C++の仕様が膨れると悪いということについて、合理的な理由は提示されませんでした。
よって、
>>519 採用
>>520 却下
526:デフォルトの名無しさん
09/08/18 00:54:06
ままごと遊びかよ
527:デフォルトの名無しさん
09/08/18 01:00:16
小学生はママのおっぱい飲んで早く寝ろよ
528:デフォルトの名無しさん
09/08/18 09:25:36
小学生までママのおっぱい飲んでた人の煽りはやっぱ違うな
529:デフォルトの名無しさん
09/08/18 17:30:41
美少女中学生のおっぱい飲みたい
530:デフォルトの名無しさん
09/08/18 19:40:17
>>525 C++の仕様が膨れても良いという合理的な理由が示されませんでした。
よって
>>519却下
>>520採用
てか、ム板で二重否定かよ
531:デフォルトの名無しさん
09/08/18 19:50:07
>>519によれば、コンパイラーでドキュメントの自動生成が可能になる。
できないことができるようになるのは良いことだ。
以上により、>>519の合理性は示された。
一方、C++の仕様が膨れると悪いということについて、合理的な理由は提示されていない。
よって、
>>519 採用
>>520 却下
532:デフォルトの名無しさん
09/08/18 19:56:56
やっぱりこれからは俺俺言語の時代か。
533:デフォルトの名無しさん
09/08/18 19:57:27
こんなところで不毛な言い争いしてないでproposal書いてISOに送れよ
534:デフォルトの名無しさん
09/08/19 14:33:57
自分のプロポーションを気にして風呂場の鏡の前でおっぱいをよいしょっと持ち上げる美少女中学生
535:デフォルトの名無しさん
09/08/19 18:25:52
>>531
仕様が膨れると、高卒が理解できない。
大卒でITは、頭がおかしいので除外。
536:デフォルトの名無しさん
09/08/19 20:36:36
>>535
要するに日本のIT業界にはバカとキチガイしかいないってことか。
だとすると名実ともに Embedded C++ は日本人専用なので、これでも使っとけ。
当然、C++0x は禁止ってことになるな。
537:デフォルトの名無しさん
09/08/19 21:19:57
名前空間とtemplate無い時点で誰も使わんわ
538:デフォルトの名無しさん
09/08/19 21:53:39
template省くのはまだ理解できなくもないが
名前空間を無くす意味がまったくわからない
539:デフォルトの名無しさん
09/08/19 22:12:20
template省くと何かいいことあるの？
540:デフォルトの名無しさん
09/08/19 22:25:02
高卒はC使ってろって話。
541:デフォルトの名無しさん
09/08/19 22:27:21
>>539
コンパイラ作るのが楽になる。
542:デフォルトの名無しさん
09/08/19 22:35:30
テンプレートと名前空間は最初のころは無かったし。
543:デフォルトの名無しさん
09/08/19 22:36:48
じゃあ、クラスも無くていいな。
544:デフォルトの名無しさん
09/08/19 22:41:57
テンプレートは無いとコンパイル速くなるよ。
545:デフォルトの名無しさん
09/08/19 22:44:01
テンプレートも名前空間もクラスもないC++っていうと何が残って･･･
関数のオーバーロード？
546:デフォルトの名無しさん
09/08/19 23:02:24
まだデストラクタがある。
547:デフォルトの名無しさん
09/08/19 23:04:01
クラスが滅びたのにデストラクタだけ残るなんて滑稽だわ
548:デフォルトの名無しさん
09/08/19 23:17:47
例外、テンプレート、名前空間がなければＣのプリプロセッサ改造だけでコンパイラが作れそうだな。
549:デフォルトの名無しさん
09/08/19 23:20:10
C99でおｋ
550:デフォルトの名無しさん
09/08/19 23:31:04
>>547
クラスは滅びぬ、何度でもよみがえるさ。再利用可能なモジュールこそがプログラマの夢だからだ。
551:デフォルトの名無しさん
09/08/19 23:52:37
再利用よりも、簡単に仕様変更できたり、刷新できたりする方向で
進化して欲しいなと最近思う。
552:デフォルトの名無しさん
09/08/20 05:08:41
C with classesで
553:デフォルトの名無しさん
09/08/20 07:15:26
>>540
大卒でITなんて、負け組。
バカなんじゃないの？
554:デフォルトの名無しさん
09/08/20 07:47:33
やっぱ院卒だよな
555:デフォルトの名無しさん
09/08/20 13:00:03
555
556:デフォルトの名無しさん
09/08/20 18:17:50
院卒でITは終わったな。
557:デフォルトの名無しさん
09/08/20 18:22:07
スレ違いも大概にしろ
558:デフォルトの名無しさん
09/08/20 19:43:01
個人的にはSTLのないC++に存在意義感じない
組み込みは元々事実上使えないから問題ないんだろうけど
559:デフォルトの名無しさん
09/08/20 19:59:03
lambda式がないSTLも微妙だ
560:デフォルトの名無しさん
09/08/20 21:12:45
頑張って関数オブジェクト書けよ
お父さんはそうしてきたぞ
561:デフォルトの名無しさん
09/08/20 22:43:27
>>553
院卒のIT系高給取りでごめんな
562:デフォルトの名無しさん
09/08/20 23:21:12
院卒w
563:デフォルトの名無しさん
09/08/20 23:27:02
マ板でやれ
564:デフォルトの名無しさん
09/08/21 07:40:34
>>561
バカだな。その程度の給料で高給とは片腹痛い。
ためしにいくらもらってるか書いてみろよ。
565:デフォルトの名無しさん
09/08/21 07:43:27
なんか今凄まじい矛盾を見た気がした
566:デフォルトの名無しさん
09/08/21 18:13:35
Embedded C++は事実上死亡している。
なにしろ「いらね」というTRが出ているくらいだ。
567:デフォルトの名無しさん
09/08/22 02:20:55
>>558
組み込みだってSTL使うよ。
デフォルトアロケータのコンテナを使わないだけだ。
568:デフォルトの名無しさん
09/08/24 14:50:33
>>567
組み込みだと例外処理が使えなかったりしないか?
例外なしの STL って辛くないか?
569:デフォルトの名無しさん
09/08/24 14:57:01
STLは汎用性のためスペックを多く使う。
動作が遅いCPCではつかえない