09/01/27 00:40:08
いいえ。あれは劣化デストラクタですらない、Cでfreeをきちんと書くのと同じこと。
C#のusingこそ（いい意味で）劣化デストラクタと呼べる存在だ。後発だけあってJavaより賢い。
51:デフォルトの名無しさん
09/01/27 00:47:28
Cで言えばgotoでエラー処理ルーチンに飛ばすようなもの
52:デフォルトの名無しさん
09/01/27 00:48:28
いや例えないでいいから
53:デフォルトの名無しさん
09/01/27 00:52:25
>>47
最近、サーバーサイドの案件はほとんどJavaかC#よ。
Windows Server 使えるならC# 1択。
あと、社内ツールとかには .NET 使ってる人多い。
お客様にランタイムインストールしてもらわなきゃとか気にしなくていいし。
54:デフォルトの名無しさん
09/01/27 21:50:11
>>50
usingがいいのはわかる。
でも、インデントつかブロックが深くなって
しまうーところがかなりイヤ。
やっぱりC++の真デストラクタこそが最強！
55:デフォルトの名無しさん
09/01/27 21:56:00
D の scope キーワード最強だろ。
56:デフォルトの名無しさん
09/01/27 22:54:32
>>47
脳内の現場や脳内の研究の話をされても…
57:デフォルトの名無しさん
09/01/28 08:46:59
>>56
一方的に脳内認定されてもな。
速度とメモリ効率考えると、実用するコードは
fortran,C,C++くらいしか選びようが無い分野も
多いとおもうんだけど。少なくとも自分の周りは
何処いっても同じようなもの。
普通に書いたCやC++とほぼ同等レベルの
速度で動けば十分な用途だとjavaやC#でもいいんだろうけど、
この辺で目指しているのは最終手段として
インラインアセンブラでベクトル化することもあるからな。
58:デフォルトの名無しさん
09/01/28 08:47:01
>>55
Dってだけでよわい。
59:デフォルトの名無しさん
09/01/28 13:05:25
>>57
＞自分の周りは 何処いっても同じようなもの。
もっと見聞を広めたほうがいい。
でなければ、黙って脳内認定を受け入れろ。
60:デフォルトの名無しさん
09/01/28 13:59:15
>>57
実行速度とメモリ効率だけならFORTRAN以外の選択肢は無いな…
C/C++含めて、FORTRAN以外が選択されることがあるのは、それだけが言語の選択基準じゃないってことだと思うんだが
61:デフォルトの名無しさん
09/01/28 22:48:26
でも最近はC++も見直されつつあると思う
62:デフォルトの名無しさん
09/01/28 23:34:59
>>60
Pascal
63:デフォルトの名無しさん
09/01/28 23:40:09
JAVAが実用じゃないといってる時点でもアウトだろ。
64:デフォルトの名無しさん
09/01/28 23:43:04
でもJavaは嫌い
65:デフォルトの名無しさん
09/01/29 00:08:22
つーかcontrol invocation syntaxがC++にも欲しい。
Javaより先に入れちゃえと言いたいところだけど、
もう閉じちゃったから10年後なんだよな orz
66:デフォルトの名無しさん
09/01/29 03:20:14
>>47だけみて誤解されているようだけど、別にJavaやC#が
実用的でないといっている訳ではないよ。
C++使えない、0xなんて現場で必要とされていないみたいな流れで、
逆にJavaやC#を使っていない・適用しづらい分野もあると
表明したかっただけ。
67:デフォルトの名無しさん
09/01/29 08:36:42
>>66
「分野による」って話だと、
.NET やら Java VM 移植されてない環境だってあるわけだし、
組み込みだと未だCだし、
>>47 みたいな書き方するまでもなく、自明な話なんだが。
68:デフォルトの名無しさん
09/01/29 20:27:40
>>65
いらん。
これ以上、デブにしてどうするよ？
69:デフォルトの名無しさん
09/01/29 21:04:52
デブに穴欄よ
70:デフォルトの名無しさん
09/01/29 22:43:27
語れるほど経験を積んでないのに無理するから
71:デフォルトの名無しさん
09/01/30 08:40:04
GCC 4.3.3 の tr1 見たらもうバリバリ Variadic Template 使ってんのな
72:デフォルトの名無しさん
09/01/30 09:17:28
それがどうしたハゲ。
73:デフォルトの名無しさん
09/01/30 11:14:42
誰がハゲだと！？もう一度言ってみろ！！
74:デフォルトの名無しさん
09/01/30 12:32:40
>>73
0x対応の第4版早く書けハゲ
75:デフォルトの名無しさん
09/01/30 13:08:20
そんなに褒めてやるなよ。
76:デフォルトの名無しさん
09/01/30 18:03:36
メタプログラミング厨が喜びそうな機能を真っ先に入れるあたりはやっぱりGCC
77:デフォルトの名無しさん
09/01/30 19:56:09
ハゲがデブい言語を御所望ですね。
臭くね？
78:デフォルトの名無しさん
09/01/31 16:07:56
>>53
> お客様にランタイムインストールしてもらわなきゃとか気にしなくていいし。
なぜかVBのランタイムなら入れてやってもいいという客が多い。
79:デフォルトの名無しさん
09/01/31 17:54:22
どうも、「.netはカスだ」と言い張った営業マンの戦略に乗せられている例も多いらしい。
要は、その営業マンの所属するソフト屋が新しい技術についていけないだけなんだけどね。
その所為か、某官庁のシステムは未だにVB6が使われていたり。
80:デフォルトの名無しさん
09/01/31 23:03:55
vbに比べたら.netの方がマシだな。作る側としては。
使う側としては.netの方がランタイムが大きい分、抵抗ありそう。
81:デフォルトの名無しさん
09/01/31 23:10:05
色々思うところはあるがスレ違いはそろそろ・・・
82:デフォルトの名無しさん
09/01/31 23:14:01
あぶねえ。
.netランタイムは複数バージョンを同居させないといけないのが気に食わない
と書いてしまうところだった。
サンクス>>81
83:デフォルトの名無しさん
09/02/01 00:59:08
VBに比べたらC++/CLIのほうがましだといいたいんですね、わかります。
84:デフォルトの名無しさん
09/02/01 01:22:38
C++/CLIは割と良くできてると思うんだ
85:デフォルトの名無しさん
09/02/01 01:25:44
^ とか勘弁して欲しい
86:デフォルトの名無しさん
09/02/01 01:37:15
__gc*よりはましだぜ。
87:デフォルトの名無しさん
09/02/01 01:48:05
C++/CLI 使った事無いんだけど
Hoge^ hoge;
Hoge^* phoge = &hoge;
Hoge^*& rphoge = phoge;
って可能なの？
88:デフォルトの名無しさん
09/02/01 01:52:39
できるけど、そのままだと安全じゃないよ
89:デフォルトの名無しさん
09/02/01 01:58:11
広義の弱い参照になるって話？
まあ、ダングリングポインタ自体は元々危険だから
改めて気にすることは無いと思うけど。
90:デフォルトの名無しさん
09/02/01 02:13:41
C++/CLI使ってるやついないだろ。川俣もC#に戻ったし。
91:デフォルトの名無しさん
09/02/01 04:02:09
MSオンリーでなければ手を出すんだがな。
プロパティーとか、属性とかMS臭いすぎる仕様が気に食わん。
92:デフォルトの名無しさん
09/02/01 08:51:23
プロパティはもともとデルファイのものでは。
属性は Java にも Annotation 付いたし。
MSはほんと後だしじゃんけんでいい物作るよ。
93:デフォルトの名無しさん
09/02/01 09:00:46
C#はもともとMSがDelphiの開発者を引き抜いてきて作ったものだからな
94:デフォルトの名無しさん
09/02/01 10:29:48
MSに引き抜かれた技術は全部「MS臭い」といわれるんですね。
分かります。
95:デフォルトの名無しさん
09/02/01 11:41:06
ウンコなすりつけられた奴が全員ウンコ臭いのは事実
96:デフォルトの名無しさん
09/02/01 15:03:48
MSの属性は元を辿ればMIDLだろう。
その後、いつだか忘れたけど、ATL属性プログラミングといって、MIDLの属性の構文をVC++に持ち込んだ。
その構文がマネージドC++やC++/CLIにも引き継がれて今に至る。
97:デフォルトの名無しさん
09/02/01 15:05:38
F#やIronPythonやIronRubyがあるからOCamlやPythonやRubyもMS臭いのですね
98:デフォルトの名無しさん
09/02/01 15:17:26
>>66
最初から誤解される書き方しかできない知能しか持ち合わせていないカスが、プログラミング言語を語るとは・・・
コンピューターの前に座ってばっかりじゃなくて、たまには人間と会話した方がいいぞ
99:デフォルトの名無しさん
09/02/01 17:57:10
で、0ｘの次の標準の主なネタは何？
100:デフォルトの名無しさん
09/02/01 18:04:59
まず念願のGCだな
あと多重ディスパッチとかyieldとか
メタコンセプトもどうせ作るんだろうな
あとは何だ
101:デフォルトの名無しさん
09/02/01 18:25:55
標準ライブラリの完全なconcept化
102:デフォルトの名無しさん
09/02/01 18:32:10
tr2てのはC++0xの次って事でいいの？
ThreadとかNetworkとかDatetimeとかFilesystemとか
実用的なのが多いね
103:デフォルトの名無しさん
09/02/01 19:38:27
正直、これ以上 C++ を高機能化しても仕方が無いと思う。
C++ は構文解析と意味解析が複雑に入り組んでいる事で悪名高いから、
これらが完全に分離された言語に一旦整理し直した、別言語を作るべき。
あくまで C++ と機能的には変わりのない範囲で。
104:デフォルトの名無しさん
09/02/01 19:59:30
それは他の人／団体／企業がやってるよ。
105:デフォルトの名無しさん
09/02/01 20:26:24
意味はあるだろ
C++を使ってる俺が嬉しい
106:デフォルトの名無しさん
09/02/01 20:27:43
コンパイラ作る側がひぃひぃ言って
サポートが遅れてもあんまり意味が無いからなあ
107:デフォルトの名無しさん
09/02/01 20:45:47
>>103
何そのD言語
108:デフォルトの名無しさん
09/02/01 21:11:31
MS付きのC++/CLIでさえあの体たらくだというのに…
109:デフォルトの名無しさん
09/02/01 21:19:19
D言語もGCあるからなあ・・・
常に scope を使えばいいのかもしれないが、なんだかな・・・
110:デフォルトの名無しさん
09/02/01 21:20:10
>>109
D言語でもGCを止めて、C++のように書くことはできる。
111:デフォルトの名無しさん
09/02/01 21:28:30
スコープにとらわれないタイミングで delete できるの？
112:デフォルトの名無しさん
09/02/01 21:38:00
>>111
普通にC++のようにdeleteすればいい。
113:デフォルトの名無しさん
09/02/01 21:54:39
delete できるのか。
いいね、それ。
114:デフォルトの名無しさん
09/02/02 00:49:28
C++はそろそろコンストラクタとデストラクタの前と後に呼び出される処理をデフォルトで追加するべきだな。
ファクトリー関数とかだるすぎる。
スマートポインタをコンストラクタ内で作れなくてもいいから、コンストラクトが終わった後になんか呼び出してくれ。
115:デフォルトの名無しさん
09/02/02 01:05:44
>>114
before-daemon, after-daemonｷﾀｰ!
116:デフォルトの名無しさん
09/02/02 02:09:14
コントラクトとかアスペクトとか、
そういうのは入らんのか。
テンプレートにちょっといろいろ
たすだけでできそうだが。
117:デフォルトの名無しさん
09/02/02 02:59:18
その辺研究した上でconceptに昇華された。
AspectJ, Eiffel, ML, Haskell辺りの型システムを、
型の専門家が研究した成果を取り入れてる。
118:デフォルトの名無しさん
09/02/02 08:53:22
さあ！みんなDゲンガーになろう！
119:116
09/02/02 18:50:48
>>117
conceptはtraitのちょっとした拡張くらいに
思ってたけど、違うんだ？
# 詳しくはまだ見てないんす。orz
何かの言語で、処理（関数）の前後とかに
別途定義する処理を定型的にねじ込む
機能を見たとき、すげぇ超うらやましい！
と思ったんだけど、あれが使えるのかな。
120:デフォルトの名無しさん
09/02/02 20:05:08
C++って、もともとCのソースをつくるだけだったんだぜ。
121:デフォルトの名無しさん
09/02/02 22:53:18
例外で破綻したけどな
122:デフォルトの名無しさん
09/02/03 04:26:09
>>103
C++の構文解析って、今はすべて手書きらしいね
こういうことがC++の将来に悪い影響を与えそうな気がする
構文を書き換える時期に来ているのかもしれない
123:デフォルトの名無しさん
09/02/03 04:52:16
たしかに、C++は複雑だからという理由も大いにあるだろうけど、
ほかの綺麗な言語でも高速な解析を目指せば自ずと自前で解析するだろうし、
何より今更そんな気にすることか？と思う。
124:デフォルトの名無しさん
09/02/03 08:36:01
確か、IronPythonとかも手書きって話だったと。
125:デフォルトの名無しさん
09/02/03 09:18:53
使わない仕様とか、勝手にエゴで古いコードの書き方を意味もなく変えたり。
バカだなぁと思う。
特にifとカッコの間にスペース開ける奴。
騙されてるよなぁー、と思う。
126:デフォルトの名無しさん
09/02/03 09:20:41
なぜ？
127:デフォルトの名無しさん
09/02/03 09:22:14
>>126
カッコまでが言語仕様だから。
カッコなしで通るなら、スペースを開けるのが正しいと思う。
128:デフォルトの名無しさん
09/02/03 09:24:03
いやお前の文章の意味が分からん。
「騙されてる」の主語は誰だよ？
「ifとカッコの間にスペース開ける奴」が「騙されてるよなぁー」だと思ったぞ。
129:デフォルトの名無しさん
09/02/03 09:25:06
>>128
スペース開けてる奴は、騙されてるよ。
130:デフォルトの名無しさん
09/02/03 09:29:50
恥ずかしい言語仕様を隠すためだけに、権威筋が言い始めたのを真に受けて従ってるわけだろ？
騙されてなけりゃ、単なるバカ。
131:デフォルトの名無しさん
09/02/03 09:33:02
自分の口からだだ漏れ状態の上から目線に興奮冷めやらぬのはわかったけど、
もうちょっと具体的に説明しないとただの電波さんｗ
132:デフォルトの名無しさん
09/02/03 09:46:14
どう見てもただの基地外さんだろ。 文章の意味が全く通っていない。
133:デフォルトの名無しさん
09/02/03 09:46:41
いやぁ、どう説明しても只の電波だろ。片や「騙されてる」と言いながら、片や「正しいと思う」だし。
134:デフォルトの名無しさん
09/02/03 10:00:46
その辺はスルーして、
C++の構文解析は自然言語構文解析並みwと書いた人が以前いたが、
(g++のMLだったか?)
最近手でパーザを書くのが結構流行っているのは、
エラー処理をきちんとやりたいから。
g++のパーザはすごくわかりやすい。
gccのパーザはbisonの出力したCコードから派生しているけど、
これも以外にもすごくわかりやすい。
v8(Javascript)の手書きパーザもすごく綺麗。
135:デフォルトの名無しさん
09/02/03 10:11:05
>>134
理屈はわかるが、いざ自分がそのパーサを書く係になったらと思うとぞっとするな。
136:デフォルトの名無しさん
09/02/03 10:42:34
エラー処理、得にエラー表示は、UIに属することだからね。
GUIで、入力足りないと、ダイアログウィンドウ出して、
入力してないフィールドを赤く表示して入力を促し、
側に警告も表示するっての似て、手間ばかり多いね。
ちなみにg++のパーザは2万行w (gccは8千行)
C++で書けばいいのに…
conceptg++のパーザは+1400行ですね。
// というかgcc本家のconcept branch放置されてる…
137:デフォルトの名無しさん
09/02/03 15:50:22
手で書かなくてもエラー処理をまともにする方法はある気はするんだけどなぁ
parser combinatorとか使ってコード量を10分の1ぐらいにできないのかなぁ
138:デフォルトの名無しさん
09/02/03 18:19:38
>>125
あなたはreturnにカッコを付ける人ですね
分かります
139:デフォルトの名無しさん
09/02/03 18:27:17
相談室もだが、今日は変なやつがいるな
もしかして同じ人？
140:デフォルトの名無しさん
09/02/03 18:41:11
>>137
簡単なんでいいから一回パーサーを
書いてみろ。
気のきいたエラー処理がどれだけ
めんどくさいものか体感するべき。
141:デフォルトの名無しさん
09/02/04 00:26:20
>>139
最近あちこちで電波垂れ流してる脳内住人が出没してる。
ここのスレにも、見てわかるとおり。多分同一人物だろうな。
142:デフォルトの名無しさん
09/02/04 00:31:07
パーサのエラー処理は地獄だよ
143:デフォルトの名無しさん
09/02/04 00:38:09
エラー1つ検出して終わりなら大分楽だが
今時そんなコンパイラじゃ誰も使ってくれないだろう。
144:デフォルトの名無しさん
09/02/04 00:39:41
むしろコンパイル速度さえ爆速であればエラーを一つ検出して終わりというコンパイラもアリだと思う。
145:デフォルトの名無しさん
09/02/04 00:48:25
this -> m_Hoge = 10;
これでも通るんだし別にいいんじゃね。
146:デフォルトの名無しさん
09/02/04 00:57:46
>>144
連鎖的にエラーが出る事が多いから、
結局最初の１つくらいしか見ないとか多いしな。
そこ直したらもっかいコンパイルした方がエラーが見やすいし。
147:デフォルトの名無しさん
09/02/04 01:07:22
権威にはからきし弱い、太鼓持ち。
148:デフォルトの名無しさん
09/02/04 02:10:26
じゃあ柔軟なエラー処理ができ、かつ簡潔で速度もそこそこ出るパーザの実装手法を考案して有名になってやる
149:デフォルトの名無しさん
09/02/04 12:49:40
期待してるよ
150:デフォルトの名無しさん
09/02/04 12:53:03
このスレで宣言するからにはC++0xのパーザも。
151:デフォルトの名無しさん
09/02/04 18:39:36
しかし改めて思うがひっでー文法だな
特にdeclarationまわり
152:デフォルトの名無しさん
09/02/04 23:54:43
varとかtypeとかfunctionとかのキーワードがないのに合わせて、
typedefが止めを刺した感じ。
classやtemplateやcoceptはキーワード付けてくれて本当に良かったよ。
153:デフォルトの名無しさん
09/02/05 11:08:28
>>152
何かで見たけど、キーワードはできるだけ
追加しないってのがポリシーなんだよね。
154:デフォルトの名無しさん
09/02/05 11:14:40
>>138
わかってないな。
省略できるから、つけようがつけまいが自由なんだぞ。
単にあのかっこも、一時期のバグ回避だし。
155:デフォルトの名無しさん
09/02/05 11:45:46
どうでもいいことで盛り上がるなこのスレ
156:デフォルトの名無しさん
09/02/05 11:54:32
馬鹿が必死になるから挑発しないでくれ
157:デフォルトの名無しさん
09/02/05 12:00:29
というか、どうでもいいことだから盛り上がる
158:デフォルトの名無しさん
09/02/05 12:12:45
ごめんなさい…
159:デフォルトの名無しさん
09/02/08 20:28:10
>>154
へー、そんな理由がねぇ。
おいらてっきり、void return(x);的な関数に見せかけたいが為に
やってんだと思ってた。あんま関係ないけど
int(main)(int(argc),char**(argv))なんて所にも括弧付けれるね。
まぁ、当方returnですらカッコ付けたことは無いから付ける輩の気持ちは解らんけど。
160:デフォルトの名無しさん
09/02/08 20:33:08
return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
ANSI 以前の。
大昔の良書（今となっては歴史的資料）がANSI以前の文法で書かれてたりするせいで、
それが正しい書式だと思ってる人が絶えなかった。
161:デフォルトの名無しさん
09/02/08 20:35:06
未だにflex/bisonみたいな古いツールの解説では旧形式の関数定義があったりするな。
162:デフォルトの名無しさん
09/02/08 22:26:28
>>160
＞return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
それはない。exit()の実装と勘違いしていないか?
163:デフォルトの名無しさん
09/02/08 22:51:35
>>160
このレスは全て間違い。以下無視するように。
164:デフォルトの名無しさん
09/02/08 22:56:56
C FAQを当たってみたけど、
URLﾘﾝｸ(www.kouno.jp)
> 20.19:
> returnの後ろに来る式をくくるカッコは本当に省略可能か。
> A:
> 省略可能だ。
> 大昔、Cの初期には、必要であった。そのころにCを学んだ人がたくさんいるし、
> そのころ書かれたコードが今でも世の中に出まわっている。 それでカッコが
> 今でも必要であるという考えが広まっている。
ということで、昔は必要だった(が関数ではない)ってのが正しいようだ。
165:デフォルトの名無しさん
09/02/09 00:52:05
ifとかwhileが関数ではないけど括弧が要るってのと同じことだったんだと思う。
166:デフォルトの名無しさん
09/02/09 06:58:32
統一性を考えたらカッコが必要なままでもよかった気がする。
つか、不要にするならするで if や while もカッコ不要にして統一しろよ。
167:デフォルトの名無しさん
09/02/09 07:24:14
>>166
ifやwhileは括弧があっても、タイプミスをするとコンパイル時に検出できるが、
returnに括弧があるとそうはいかない。
168:デフォルトの名無しさん
09/02/09 08:53:03
>>166
retrun() でハマるというネタが
169:デフォルトの名無しさん
09/02/09 10:42:17
>>166
つーか
統一するという言葉自体に惹かれても意味ないし
第一、統一する理由がない
170:デフォルトの名無しさん
09/02/09 11:42:57
括弧無しでも文法としては作れるよね？
そうしろっていってるんじゃなくて、ふとした疑問で
171:デフォルトの名無しさん
09/02/09 12:30:29
return-statement := return EXP
と定義すれば既に統一されてるじゃん
空白や(は識別子に含めないからそこで打ち切られてreturnが認識され、
以降の式が続けて認識される
172:デフォルトの名無しさん
09/02/09 16:13:55
>>166
break continue sizeof系統だからある意味統一されてるだろ。
173:デフォルトの名無しさん
09/02/09 16:26:05
>>172
sizeofちと違う
174:デフォルトの名無しさん
09/02/09 17:58:38
>>170
ついでにifなどにぶら下がる文を複文限定にして、中括弧必須にしてくれればいいのにと思う。
175:デフォルトの名無しさん
09/02/09 18:14:32
P e r l 化 決 定
176:デフォルトの名無しさん
09/02/09 19:22:59
#define begin {
#define end }
177:デフォルトの名無しさん
09/02/09 20:02:27
>>176
嘘のような、本当の話。
178:デフォルトの名無しさん
09/02/09 21:21:51
昔々のはなしじゃねーか。
つーか、ゴテゴテ強化してJAVAより遅くなってたら笑える。
179:デフォルトの名無しさん
09/02/09 21:23:53
>>176
STL コンテナと一緒に使えますか？
180:デフォルトの名無しさん
09/02/09 21:42:50
#defineはコンパイル以前に発現するのでSTLと一緒には使えません。
181:デフォルトの名無しさん
09/02/10 09:15:30
えー
182:デフォルトの名無しさん
09/02/10 11:57:45
#define private public
183:デフォルトの名無しさん
09/02/10 19:11:50
#define privata public
184:デフォルトの名無しさん
09/02/10 20:59:45
#define mein main
#define retrun return
#define cahr char
185:デフォルトの名無しさん
09/02/10 21:06:58
#define itn int
#define sohrt short
#define unsgied unsigned
#define long lgon
#define vodi void
#define defien define
#define incldue include
#define thrwo throw
186:デフォルトの名無しさん
09/02/10 21:18:27
#define unsinged unsigned がないのはおかしい
187:デフォルトの名無しさん
09/02/10 22:49:20
^t
188:デフォルトの名無しさん
09/02/10 23:04:18
結局、単なるデブ言語か。
テンプレートでarray使うと、C#より遅くなるんだからたまらん。
189:デフォルトの名無しさん
09/02/11 00:08:35
>>188
え～。コンパイル時に最適化掛けてないとかそんな話じゃないよね？
190:デフォルトの名無しさん
09/02/11 00:36:58
「テンプレートで」とか、馬鹿に決まってるから相手にするな。
191:デフォルトの名無しさん
09/02/11 01:09:58
すいませんでした。いや、数年前に、
知り合いで大学院で C++ でシミュレーションをしていた奴が、
遅くて困るんだよね... といってたから最適化オプションはどうしてる？と聞いたら
何もしらなくて、調べてみるとなんとデバッグオプションつきで
inline 展開も無しだったという恐ろしい話があったのでね...
192:デフォルトの名無しさん
09/02/11 01:20:19
188はコンパイルが遅いって話かと思った
193:デフォルトの名無しさん
09/02/11 01:36:50
遅いなら速くすればいいじゃない
194:デフォルトの名無しさん
09/02/11 03:34:24
コンパイルが遅いならDをｔ（ｒｙ
195:デフォルトの名無しさん
09/02/11 23:05:34
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
196:デフォルトの名無しさん
09/02/12 22:07:49
いやいや、三次元配列だとすで使っても遅いぞ。
197:デフォルトの名無しさん
09/02/13 18:09:29
mailing2009来てるじゃん
スレッドのバグが山のように報告されてて吹いた
198:デフォルトの名無しさん
09/02/13 20:58:23
constexpr の再帰が復帰してるっぽ。
199:デフォルトの名無しさん
09/02/13 21:15:07
停止判定できないのはテンプレートも同じだからな
200:デフォルトの名無しさん
09/02/13 22:36:24
結局コンパイラ側で制限かけるんじゃね？
201:デフォルトの名無しさん
09/02/14 00:28:13
そういう問題じゃない。
202:デフォルトの名無しさん
09/02/15 02:07:01
final class に相当するものは導入されてんの？
const class とかでキーワード導入しなくても大丈夫そうな気がするんだけど。
203:デフォルトの名無しさん
09/02/15 02:14:04
されてない
204:デフォルトの名無しさん
09/02/15 02:33:02
意見すら出なかったのだろうか
205:デフォルトの名無しさん
09/02/15 03:36:12
0x はそういう小手先の便利さとかとは掛け離れた大きいものを狙っている気がする。
206:デフォルトの名無しさん
09/02/15 05:12:01
小手先の便利さはライブラリやコーディングテクで補うのが禿と愉快な仲間たちの趣味です。
207:デフォルトの名無しさん
09/02/15 08:03:04
あるあるw
208:デフォルトの名無しさん
09/02/15 13:43:24
>>202
[[final]]っていうオーバーライド禁止属性が入る
209:デフォルトの名無しさん
09/02/15 14:56:54
class hoge [[final]] ってのは入る事になったの？
virtual member function にたいしてだけ？
210:デフォルトの名無しさん
09/02/15 16:24:18
N2800では入ってる
効果はクラスの全仮想関数に[[final]]を付けるのと同じ
211:デフォルトの名無しさん
09/02/15 16:46:12
>>210
継承禁止ならともかく仮想関数オーバーラード禁止してどうするの？
virtual付けなきゃ良いだけじゃない。
212:デフォルトの名無しさん
09/02/15 17:10:07
豚脂の摂り過ぎは禁止じゃないけど控えた方がいいだろうな。
213:デフォルトの名無しさん
09/02/15 17:14:36
>>211
> virtual付けなきゃ良いだけじゃない。
（ ﾟдﾟ）ﾎﾟｶｰﾝ
214:デフォルトの名無しさん
09/02/15 17:45:54
>>211
俺に言われても困るが、virtual付き関数のオーバーライドさえ封じておけば
基底クラスの機能を派生側で変更できなくなるんだから十分だろう
virtualにしないという手は、基底クラスから受け継いだ仮想関数がある場合には使えない
クラス付き[[final]]はそういうのにも効いてくれるから意味がある
215:デフォルトの名無しさん
09/02/15 19:25:02
>>214
やっぱりそういう事なんだ。成るほどね。
>>202に「final classに相当するもの」って書いてあったから、
Javaと同系統の機能なのかと混乱したよ。
216:デフォルトの名無しさん
09/02/16 01:57:18
Java の final メソッドと同じだな
217:デフォルトの名無しさん
09/02/16 21:39:37
どうせクラスと関数でセマンティクスが変わるのが嫌だったんだろうけど
やっぱりキッパリと「派生クラス作ったらアウト」にして欲しかったな
仮想デストラクタ作らないと派生禁止にできないのは本末転倒な気がする
218:デフォルトの名無しさん
09/02/16 22:39:33
デフォルトがアーリーバインディングのC++で
final が必要なケースのほとんどは悪い設計の尻拭いでしょ
そんなことより早く仕様Fixして欲しいよ
219:デフォルトの名無しさん
09/02/16 22:40:34
安全性より速度側に倒すC++だからこそ
finalが必要なんだろう。
220:デフォルトの名無しさん
09/02/16 22:45:07
統一関数構文周りがここへ来てまた愉快なことになってるからな
今年中には無理だな
221:デフォルトの名無しさん
09/02/16 23:41:14
統一関数構文とかって、英語話者なら前から読んでわかりやすいかもしらんが
日本語だとあんまり C のとかわらなくね？
function of int i and int j which returns array of pointers to function of int i
とかそのままになる？んだろうけど日本語の語順とは全然ちがうよね。
222:デフォルトの名無しさん
09/02/17 00:09:52
まあ戻り値を引数列の後ろに置きたいための変更で
読みやすさのためじゃないからな
しっかし既存の宣言に無理矢理押し込むためにこれ→[]を型扱いしようとしたり
この期に及んで関数とラムダを完全統合しようと派手に文法いじくり回したり
迷走がひどい
223:デフォルトの名無しさん
09/02/17 00:22:59
てかC++使いに自然言語的可読性気にする奴いるのかね？
最早ここまで崩れたら英語圏だろうどこの人間でも
気にする気にもならんと思うんだが。
224:デフォルトの名無しさん
09/02/17 00:23:56
統一関数構文は別言語でやってくれって感じだ。
C++にいれるには無理がある。
225:デフォルトの名無しさん
09/02/17 01:06:20
最初に思い切ってfuncdefでも予約語にすると決定すれば良かったんだ
226:デフォルトの名無しさん
09/02/17 01:07:08
いや、あれは必要だ。
とくにdecltypeがあるC++0xにとっては。
227:デフォルトの名無しさん
09/02/17 01:24:49
shared_ptrが付いたのはいいけど、やっぱり演算子にならないといまいち使えないよなー。構文長くなりすぎだし。
[*]とか何か導入できなかったのかな。バカだなー。
228:デフォルトの名無しさん
09/02/17 01:41:12
最大の問題はstd::shared_ptrがboost::shared_ptrと同じように使えるとは限らないこと
dynamic deleterが要件に入ってないとか何なの？死ぬの？
229:デフォルトの名無しさん
09/02/17 02:08:28
そんなあほな
230:デフォルトの名無しさん
09/02/17 02:29:42
>>224
入れないほうが無理があるよw
俺はあのスタイルは好きじゃないけれど、
なんか入れないと>>226の言う通りで破綻する。
231:デフォルトの名無しさん
09/02/17 02:44:02
C++って何がしたいの？
232:デフォルトの名無しさん
09/02/17 03:52:37
>>228
どこ読んでそう思ったの？
n2800 見たけど、 get_deleter() とかあるし、 template 引数には静的な deleter 型は無いよ。
これなら deleter については boost::shared_ptr と同じでしょ。
233:デフォルトの名無しさん
09/02/17 07:22:12
>>226
関数の戻り値の型は前置しても
以降の部分を考慮できるようにはできないんだろうか。
234:デフォルトの名無しさん
09/02/17 14:53:02
デブが集うスレ。
235:デフォルトの名無しさん
09/02/17 16:33:44
時間が経ってみるとこの構文も悪くない気がして来た
[] func(int arg) -> void {}
236:デフォルトの名無しさん
09/02/17 16:35:51
いい具合に洗脳されてきてますね
237:デフォルトの名無しさん
09/02/17 18:30:44
何を今更。C++0x最高！
238:デフォルトの名無しさん
09/02/17 20:53:21
>>232
コンストラクタで明示的に指定するdeleterの話じゃないぞ
boost::shared_ptr<Base> p(new Derived);
が（~Base()が仮想じゃなくても）デストラクタで~Derived()を呼んでくれるのがdynamic deleterだけど
N2800のtemplate<class Y> explicit shared_ptr(Y* p);の説明をよく読んでくれ
4 Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
5 Effects: Constructs a shared_ptr object that owns the pointer p.
6 Postconditions: use_count() == 1 && get() == p.
ポインタpを所有したshared_ptrを作るとは書いてあるが、Y*として所有するとは書いてない
pはT*に変換できなければならないし、事後条件で出てくるget()の戻り値型はT*だし
T*として所有する実装は十分にありうる
そして~shared_ptr()の説明には（deleterを指定していなければ）所有するポインタpに対して
delete p;を呼ぶとしか書いてない
つまり、Y*を持ってるshared_ptrならdelete (Y*)p;を呼んで欲しい（そしてboostはそうなってる）のに、
stdの方はdelete (T*)p;を呼びやがる可能性がある（そして破滅が待ってる）
というわけで、shared_ptr<Base> p(new Derived);の解体に~Base()を呼び
shared_ptr<void>は使い物にならずpimplに使うと鼻から悪魔を呼ぶ「標準準拠」のshared_ptrがありうるわけだ
恐ろしい話だと思わないか
239:デフォルトの名無しさん
09/02/17 21:18:19
Y* として delete pとなるようにすべきである、
というように書いてあるような気がするんだけど。
仮にそこが保障されなかったとしてもdeleterを指定できるんだから、
ファクトリ関数ひとつ書くだけですべてうまくいくような気がするんだけど。
240:デフォルトの名無しさん
09/02/17 21:23:54
>>231
とにかく最強を目指す
ただし何が最強かは重要ではない
241:デフォルトの名無しさん
09/02/17 21:31:15
>Constructs a shared_ptr object that owns the pointer p.
「このポインタpを所有するshared_ptrオブジェクト」とあるから T*では
条件を満たさないんじゃね？
242:デフォルトの名無しさん
09/02/17 21:33:54
>>239
どこに書いてる？
コンストラクタの説明ではdelete pがwell formed/well defined behaviorじゃなきゃダメだとは書いてるけど
デストラクタの説明には「そのdelete p」を呼ぶとは書いてない（pの真の型については何も触れてない）
それにget()の説明を見ると「stored pointer」はT*であるというようにも見える
Y*で持ってY*で解体しろと強制してる箇所は見あたらないと思うんだけどなぁ
deleter指定すればどうにかなるってのは関係ない話
boost::shared_ptrはそんなものなくても上手くいってるんだから
243:デフォルトの名無しさん
09/02/17 21:39:11
>>241
そこがハッキリしないんだよなぁ
「ポインタ」がアドレス値の情報だけなら別の型のポインタで持ったっていい訳だし
型も含めて全部保存しろとなると、今度はboostの方アウトになるような気がする
確か内部的にはvoid*で持ってるから
244:デフォルトの名無しさん
09/02/17 21:41:33
[] func(int arg) -> void {}
と
auto func(int arg) -> void {}
どちらが正式になりそう？
245:デフォルトの名無しさん
09/02/17 21:45:50
unified function syntaxが入るなら前者で、入らないなら後者なわけだが。
俺としては、後々のことも考えて、統一して欲しいところなんだが、（今回は規格に入らないlocal functionとかnamed lambdaなどを入れる際に簡単）
でもなー、実際に書かれたコードを読むと、後者のほうがぱっと見に分かりやすいんだよね。
246:デフォルトの名無しさん
09/02/17 21:45:52
あと一年時間があれば間違いなく[]が正式になっただろうけど、今の状況だと微妙だな
autoが意味持ちすぎだから[]の方がいいと思うけどね
247:デフォルトの名無しさん
09/02/17 21:47:57
いや、こんな調子じゃ、あと一年ぐらいじゃ規格制定までは無理だろ。
まだ数年かかるんじゃない？
x == 9にはならんだろう。
248:デフォルトの名無しさん
09/02/17 21:51:16
>>242
>Y*で持ってY*で解体しろと強制してる箇所
だから
Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
これでしょ？
デストラクタのところに書いてあるわけないじゃん。
>deleter指定すればどうにかなるってのは関係ない話
deleter指定したら確実にうまくいくんだから、関係無くはないだろ。
お前もギャーギャー騒ぐ必要がなくなる。
249:デフォルトの名無しさん
09/02/17 21:58:18
>>248
pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない
としか書いてないように見えるんだけど、どこで「Y*で持ってY*で解体しろと強制してる」の？
それにdeleter指定するだけでいいとは言うけど、
boost::shared_ptrを使ってる所を全部探して適切なdeleter作って書き直すのと
ただboost::shared_ptrをstd::shared_ptrに置換するだけで済むのでは全然違うと思うんだがね
250:デフォルトの名無しさん
09/02/17 22:05:13
pimplで使うことを考えるとY==Tだとしても問題だしな
251:デフォルトの名無しさん
09/02/17 22:06:31
Yのデストラクタがvirtualでなければならないとはどこかに書いてあるのかな？
書いてなければ、delete p がwell formedになるためには、一体どうすればいいんだろうな。
252:デフォルトの名無しさん
09/02/17 22:09:11
>pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない
delete p;の形式についてだけ適格で定義済みの振る舞いを要求していて、
delete (T*)p; の形式については適格で定義済みの振る舞いを要求していない以上、
実装がY*として解体するのはもう強制でしょ。
>deleter作って書き直す
いちいち個別にdeleter作る必要は無いけどね。
>ただboost::shared_ptrをstd::shared_ptrに置換するだけで済む
ちょっと頭使った置換じゃないと確かにうまくいかんかもなー。
253:デフォルトの名無しさん
09/02/17 22:09:31
Yが基底クラス持たなければ常に適格だな
それがどうした
254:デフォルトの名無しさん
09/02/17 22:12:32
Tがvoidのとき適格じゃないけど。
255:デフォルトの名無しさん
09/02/17 22:14:39
これの話だろ？
URLﾘﾝｸ(d.hatena.ne.jp)
問題は保存してるポインタの型じゃなくて呼ばれるデストラクタがいつ決まるか
N2800には何も書いてない
256:デフォルトの名無しさん
09/02/17 22:15:43
書いてるって
257:デフォルトの名無しさん
09/02/17 22:21:05
素朴な疑問
1) どうしてここまでして C++ 使いたいんだ?
2) 型に厳格な関数型言語で十分じゃね?
258:デフォルトの名無しさん
09/02/17 22:22:43
とにかく最強を目指す
ただし何が最強かは重要ではない
259:デフォルトの名無しさん
09/02/17 22:23:40
>>257
スレ違いどころか板違いです。
260:デフォルトの名無しさん
09/02/17 22:27:53
>>256
だからどこに？
コンストラクタではdelete pがwell definedでもデストラクタでdelete pが未定義になりうるってのが
pimplでの問題なんだけど
261:デフォルトの名無しさん
09/02/17 22:34:32
>>260
Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
262:デフォルトの名無しさん
09/02/17 22:40:12
>>261
だからそれはコンストラクタでしょ
shared_ptrのコンストラクタではimplクラスの完全な定義が見えてなきゃならないから、
その位置ではdelete p;はwell definedになるけど、
外側のデストラクタが自動生成だった場合にimplクラスの定義が見えてなくて
shared_ptrのデストラクタが呼ぶdelete p;が未定義になりうるんだが、
それを禁じる要件はshared_ptrのデストラクタの説明には書いてない
わかる？
263:デフォルトの名無しさん
09/02/17 22:41:22
そういう仕様のアラを突き上げるのが去年の集まりだったんだよなあ。
今年もやるらしいから、そんとき誰かが言えば、委員会の人まで話が届くぞ。
264:デフォルトの名無しさん
09/02/17 22:47:21
>>262
デストラクタにdeleterを持つときは、d(p)となると書いてある。
ここでは明確に書かれていないが
template<class Y> explicit shared_ptr(Y* p);
は、Y*として解体するdeleterを設定しなければ仕様を満たせない。
template<class Y> explicit shared_ptr(Y* p);
の仕様に
The expression delete (T*)p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
という一文が無い限りは。
265:デフォルトの名無しさん
09/02/17 22:50:16
>>264
やっぱりわかってなかったのな
pimplの時の問題だと言ってるだろう
Y==Tの場合だ
shared_ptr<impl>をimpl*で作った時に呼ばれるimplのデストラクタの話をしてるんだぞ
266:デフォルトの名無しさん
09/02/17 22:53:30
>>265
いや、それでも同じ話ですけど。
適切なdeleterがなされなければ、仕様を満たさないでしょ
267:デフォルトの名無しさん
09/02/17 22:56:43
なくても満たしちゃうだろ、と言ってるんだけど
もう一度言うけどY==Tでの話だぞ
268:デフォルトの名無しさん
09/02/17 23:01:07
N2800で言う所のdeleterってのは
template<class Y, class D> shared_ptr(Y* p, D d);の形のコンストラクタで渡されるdのことであって
template<class Y> explicit shared_ptr(Y* p);は「deleterを所有」しない
269:デフォルトの名無しさん
09/02/18 00:05:26
結局pimplにshared_ptr使っていいの？
270:デフォルトの名無しさん
09/02/18 01:31:05
>>238
> template<class Y> explicit shared_ptr(Y* p);
> Effects: Constructs a shared_ptr object that owns the pointer p.
> ~shared_ptr();
> Effects:
（略）
> ? Otherwise, *this owns a pointer p, and delete p is called.
ここでイタリックになってる "owns" を厳密な用語として読めばつながる。
つまり
int* p = new int;
shared_ptr<void> x(p);
によって x は p を「所持」する。 (void*)p を「所持」するのではない。
このまま x のデストラクタが実行されるとき、 x は deleter を持たず
p を「所持」しているので、 delete p が実行される。何も問題ない。
271:デフォルトの名無しさん
09/02/18 02:17:33
そっちの話は終わってるだろ
問題はデストラクタテンプレートの実体化時点でpが不完全型ポインタになってる時に
「delete p」が未定義動作にならないような仕掛けが規格で強制されてるかどうか
272:デフォルトの名無しさん
09/02/18 03:08:39
>>233
できるよ。現にD言語ではそうなってるし。
単に実装面倒だからコンパイラベンダが反対してるだけでしょ。
Dだと、こんなふうにかける：
typeof(T+U) add(T, U)(T t, U u) { return t + u; }
もっと簡単に
auto add(T, U)(T t, U u) { return t + u; }
ともかけるけど。
273:デフォルトの名無しさん
09/02/18 03:12:24
>>271
そういうことか。
なるほど。今の記述だとはっきりしないね。
Effects の記述は boost のドキュメントと同じだけど、 boost のほうには
template<class Y> explicit shared_ptr(Y * p) について注釈が添えられている。
> The destructor will call delete with the same pointer, complete with its original type, even when T does not have a virtual destructor, or is void.
規格にもこれが必要（できればもっとはっきり強制する書き方で）ってことだね。
早めに DR 挙げてくれ。
274:デフォルトの名無しさん
09/02/18 08:02:53
>>272
実装が面倒っての、ここまですでに複雑な言語だと、結構な問題では。
あと、C# 使いとして言わせてもらうと、
T Add<T>(T x, T y) の最初の T でインテリセンスが利かないのはかなりのストレス。
275:デフォルトの名無しさん
09/02/18 08:27:04
×C#使い
○VisualStudio使い
◎MS迎合派
276:デフォルトの名無しさん
09/02/18 09:17:10
こんなデブで非実用的な言語なんか使えねー
277:デフォルトの名無しさん
09/02/18 09:30:04
まあC++使ってない携帯電話探す方が難しいけどな。
278:デフォルトの名無しさん
09/02/18 16:16:50
Embedded C++（笑）
279:デフォルトの名無しさん
09/02/18 17:59:58
Embedded C++0xを予想するスレ
とりあえずラムダは真っ先に消される
コンセプトはテンプレートがないんだから入るわけがないな
右辺値参照はどうかな、組み込みでこそ必要だと思うけど消しそうだなｗ
280:デフォルトの名無しさん
09/02/18 18:24:51
それ以前にEmbedded C++はフリースタンディング環境で
ライブラリがないから特殊用途以外は既に死んでる。
DarwinのI/O Kitですらnamespaceはありになってるし。
281:デフォルトの名無しさん
09/02/18 19:18:32
C++にはフリースタンディングの規格は元々あるけど、
Embeddedって日本独自の規格だっけ？
製品化されてる実装なんてあるの？
282:デフォルトの名無しさん
09/02/18 19:35:47
>>281
>Embeddedって日本独自の規格だっけ？
事実上日本独自規格
C++のまともな処理系が作れないから、作りやすい縮小規格を作ったってだけ
>製品化されてる実装なんてあるの？
GHS C++なんかはサポートしてるみたい
283:デフォルトの名無しさん
09/02/18 19:41:57
>>281
URLﾘﾝｸ(www.dinkumware.com)
> ・a full implementation of EC++, the widely used embedded subset of Standard C++
彼は"Embedded Systems Programming"にコラム書いていて、
よくコンサルもやってた。URLﾘﾝｸ(www.plauger.com)
メイヤーさんも組み込み屋相手によくレクチャーしてる。EC++はやってるかどうかしらんが。
284:デフォルトの名無しさん
09/02/18 20:08:08
使い物になるやつを頼む。
C#より早いやつを頼むよ。
285:デフォルトの名無しさん
09/02/18 21:44:24
コンパイル速度の速さなら一生かなわない自信がある。
286:デフォルトの名無しさん
09/02/19 00:55:27
EC++のほうがC++より幾分ましだよ。
言語オタクにはわからんだろうが。
287:デフォルトの名無しさん
09/02/19 01:03:03
とにかく必要なモノは実用品だ。
288:デフォルトの名無しさん
09/02/19 01:56:22
EC++のページ見に行ったけど、2002年で更新止まってるしURL削ったら会社潰れたとか書いてるし
もう死んでるようにしか見えないんだけどどうなの
どっかで亡霊みたいに生き延びてるの？
289:デフォルトの名無しさん
09/02/19 02:01:24
生き延びてたとしたら俺が殺しにいくかもしれない。
290:デフォルトの名無しさん
09/02/19 02:15:51
なんで日本のこういうジャンルはクソなもんばかりなんだろうな？
うまいこと行ったのはRubyぐらいか？
てか著名なソフトの作者は大体医者だったりする所が泣ける。
291:デフォルトの名無しさん
09/02/19 02:43:25
rubyも最近は面白くなさそうだけどな。
292:デフォルトの名無しさん
09/02/19 07:41:03
>>289
これが止め刺したから必要ない。
C++ - TR 18015
Technical Report on C++ Performance
URLﾘﾝｸ(www.open-std.org)
要約すると「フルセットのC++でもパフォーマンスに問題なんかねえよ、屑」
293:デフォルトの名無しさん
09/02/19 09:21:51
>>269
問題としては >>271,273 が残ってるだけなので、生成時に deleter として
std::default_delete<Y>() を渡しとけば現状のドラフトの記述でも動作保証はできる。
しかし激しくダルイな。
現実としては記述に不備があるだけで、未定義動作の可能性は本来の意図では
無いし実装としても boost のやつを持ってくれば問題ないはずだから、あんまり
心配しなくていいと思う。
294:デフォルトの名無しさん
09/02/19 18:47:09
>>292
わざわざそんなドキュメントを出されなくても
フツーに考えたら、C++がパフォーマンスで
劣るハズがないのに。
世間はバカなの？死ぬの？
ECは、パフォーマンス優先なのでrestrict
ポインタを実装必須にするとかなら、
一理あると思うし、覚悟もわかるんだけど。
295:デフォルトの名無しさん
09/02/19 19:13:46
>>292
てかEC++はパフォーマンスなんて謳ってたの？
速度なら、例外とnew deleteぐらい、容量なら
templateとinline関数とランタイム。実際には、
それぞれ自前で調整できるからまったく問題ないのは
バカでも解ると思うが。
296:デフォルトの名無しさん
09/02/19 20:31:53
利点しかない新形式キャストを全部消してるあたり（多分RTTIとdynamic_cast消す時に巻き添え食らったんだろう）
C++を理解してない奴らが作ってたのは明白
297:デフォルトの名無しさん
09/02/19 20:37:24
>>294
かわいそうな人。
バカじゃね？
現時点でもパフォーマンスにもんだいあんのによ。
298:デフォルトの名無しさん
09/02/19 20:37:38
>>293
でもちゃんと規定しておいてくれないとvectorの連続性保証みたいなことになるからな
はっきり書いてない要件はやっぱり信用できない
たとえ事実上全部の実装がそうなってたとしても
299:デフォルトの名無しさん
09/02/19 23:16:37
バカ専用にしょぼい言語つくろうって話なんだからｗ
300:デフォルトの名無しさん
09/02/19 23:47:39
同じ事ができるならシンプルな方が正しい。
301:デフォルトの名無しさん
09/02/19 23:54:10
百歩譲ってシンプルな事は認めても、同じ事(表現)はできないだろ
302:デフォルトの名無しさん
09/02/20 00:13:28
EC++は名前空間さえ残してれば単なるC++サブセットでほぼ済んだのに
なんでわざわざ互換性捨てちゃったんだろうな
303:デフォルトの名無しさん
09/02/20 00:44:53
いらないから。
やたら短い関数名つけて検索性下げるバカとか普通に多いから。
304:デフォルトの名無しさん
09/02/20 00:45:36
EC++のメリットがパフォーマンスとか言っちゃうやつらに何いってもね。
305:デフォルトの名無しさん
09/02/20 00:52:47
日本の企業が中心になって決めたから。
306:デフォルトの名無しさん
09/02/20 09:15:46
>>300
それは大きなカンチガイ。
このバカ。
307:デフォルトの名無しさん
09/02/20 10:53:55
シンプルだと言うにも視点はそれぞれだからね
短かく書ければシンプルであるというわけでもない
308:デフォルトの名無しさん
09/02/20 11:00:10
ああ、三項演算子がバグの元とかいうアレですね
309:デフォルトの名無しさん
09/02/20 12:22:46
いいかげんgccのコナピルまんどくせ
310:デフォルトの名無しさん
09/02/20 15:31:51
昔gccにあったSignatureいつか次期C++で復活しないかなぁ。
interfaceなんかより遥に便利そうなんだけど何で廃止されかなぁ。
311:デフォルトの名無しさん
09/02/20 15:32:54
>>303
逆にループ変数にわざわざcounterとかつけてたり、引数に関数名が入ってたりするアホも見たことがある
312:デフォルトの名無しさん
09/02/20 15:50:13
>ループ変数にわざわざcounter
いや、それは別にいいんでねーの。
最近はディスプレイの解像度も上がったし、MSのインテリセンスに代表されるように、
エディタには補完機能があって便利だし。
変数一覧でiとかcntなんて表示されるよりよほど分かりやすそうだ。
引数に関数名ってのがよくわからんが。
こういうのか？
void hoge( int hoges_first_argument, int hoges_second_argument ) ;
313:デフォルトの名無しさん
09/02/20 16:14:24
そんなん
ループ変数の方はアホはいい過ぎだったな
314:デフォルトの名無しさん
09/02/20 16:31:42
>>306
それはシンプルという言葉から、アインシュタイン言うところの
「単純化せよ。ただし単純化しすぎてもいけない」
の後者のケースばかり思い出すから出てくる反応で、
前者を完全スルーするお前の姿勢がカンチガイってオチじゃないの？
315:デフォルトの名無しさん
09/02/20 19:56:49
>>314
アインシュタインはプログラマーか？
つーか、シンプルとか言えたのはアインシュタインが最後だって知ってたか？
このバカ！
316:デフォルトの名無しさん
09/02/20 20:34:28
simplicityとかいった形で数値化できればいいのにな
でさらにある法則に沿って変形していったらsimplicityがmonotonically decreasingになっていってそれを使って機械的にコードを変形して云々
317:デフォルトの名無しさん
09/02/20 20:34:51
アインシュタインのその言葉を引用するには致命的なほど具体性にかけているな。
318:デフォルトの名無しさん
09/02/20 21:23:40
w
319:デフォルトの名無しさん
09/02/20 21:43:09
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
320:デフォルトの名無しさん
09/02/20 23:17:46
>>310
concept来たやん
321:デフォルトの名無しさん
09/02/21 00:14:40
クラス作る時にコンセプト使って
InputIterator my_iterator{/*...*/};
とかやって要件満たしてなかったらエラー出してくれるみたいな使い方ができればよかったのに
322:デフォルトの名無しさん
09/02/21 00:16:33
表記が違うだけで出来るやん
323:デフォルトの名無しさん
09/02/21 00:27:12
いや、そりゃやろうと思えばできるけどさ
こんな風になるのかな
class my_iterator{/*...*/};
template<InputIterator T> class InputIteratorChecker{};
static_assert(sizeof(InputIteratorChecker<my_iterator>));
めんどくさくね？
324:デフォルトの名無しさん
09/02/21 00:29:53
>>315
主旨だけシンプルに書きましょう。
わめいて逃げてるようにしか見えませんｗ
325:デフォルトの名無しさん
09/02/21 00:49:16
>>323
Only required,
> requires InputIterator
326:デフォルトの名無しさん
09/02/21 01:02:42
>>325
それでどうやって簡単に書くんだ？
requiresってテンプレートとコンセプトの中でしか使えないだろ
327:デフォルトの名無しさん
09/02/21 01:13:26
my_iteratorは、template<～> iteratorとは無縁のクラス、
まったく別のsignatureってわけですか?
だったらconcept_map書くしかないですね。
328:デフォルトの名無しさん
09/02/21 01:18:10
めんどくさい誤解招いてるみたいだからInputIteratorやめる
auto concept HasFoo<class T>{
void foo();
};
があるときに
HasFoo Hoge{void foo(){}}; //OK
HasFoo Fuga{}; //NG
とかできたらいいなー、というのが>>321の趣旨
329:デフォルトの名無しさん
09/02/21 02:01:42
fooにT型の関与なしかあ。
auto concept HasFoo<>{
void foo();
};
template<> class Hoge {
void foo();
};
template<> concept_map HasFoo<Hoge> {
void foo() {}
};
～ Hoge<> ～
でいいのかなあ。
330:デフォルトの名無しさん
09/02/21 02:14:42
めんどくさいなぁ
やりたいことはただ自作クラスがHasFooコンセプト満たしてるかどうかチェックしたいだけだってのに
チェックするためだけにテンプレート化すんの？
馬鹿げてる
331:デフォルトの名無しさん
09/02/21 02:23:59
これでいいじゃん
template<> class Hoge {
void foo();
requires HasFoo<Hoge>;
};
332:デフォルトの名無しさん
09/02/21 02:23:59
auto concept HasFoo<typename T>{
void foo(T);
};
だと、
template<typename T> class Hoge {
requires HasFoo<T> void foo(T) {}
}
って書けるけど。
template<> class Hoge {
requires HasFoo<> void foo() {}
}
はいけるかどうかわからん。もう一回ドラフト読まんと。
333:332
09/02/21 02:26:50
間違えた。
class Hoge {
requires HasFoo<> void foo() {}
}
これは駄目だった。
>>331
ああそだね。
334:デフォルトの名無しさん
09/02/21 02:28:05
>>332
それ以前の問題として
HasFooは簡単なコンセプトだからいいけど
これがもし10個の型名と20個の関数を要求するコンセプトだったら
Hogeの型名と関数全部にそのrequires付けて回る気か？
>>323の方が楽だわ
335:デフォルトの名無しさん
09/02/21 02:31:08
直接こう書ければなんの問題もないのにな
class Hoge {
void foo();
requires HasFoo<Hoge>;
};
336:デフォルトの名無しさん
09/02/21 02:44:18
C++ってほんとに糞言語ですね☆
337:デフォルトの名無しさん
09/02/21 02:45:25
C++がwadlerとかにボロ糞に貶されるところを見てみたい
338:デフォルトの名無しさん
09/02/21 03:30:09
class Hoge : public HasFoo<Hoge> {
void foo();
};
こう書かせろよ。めんどくさいな
339:デフォルトの名無しさん
09/02/21 03:53:18
>>320
配列で使えんやん
340:デフォルトの名無しさん
09/02/21 08:56:53
>>338
class Hoge requires HasFoo {
void foo();
};
ならあり得るかも。
341:デフォルトの名無しさん
09/02/21 12:08:31
>>339
concept_map ?
342:デフォルトの名無しさん
09/02/21 18:07:11
>>341
concept_mapってsignatureのようなことできる様になるの？
便利やね。
struct A
{
//・・・
void Method();
};
struct B
{
//・・・
void Method():
};
signature Sig
{
void Method();
};
Sig array[]={new A(),new B()};//継承関係の無いオブジェクトを代入
array[0].Method();//それぞれ正しいメンバーが呼び出される
343:デフォルトの名無しさん
09/02/21 20:13:06
↓がg++4なら通るけどVC9などintがint&に変えられなくて駄目といって通らない。
これって自分何か勘違いしてますか？VC9のバグってことはありませんか？
struct MyClass {
int value;
void set_value(int v) { value = v; }
int get_value(void) const { return value; }
};
vector<shared_ptr<MyClass> > v;
...vに適当に要素を入れる...
for_each(v.begin(), v.end(), bind(&MyClass::set_value, _1, bind(&MyClass::get_value, _1))); // 駄目子ちゃん
344:343
09/02/21 20:14:24
あ、bindは<functional>のstd::tr1::bind、_1はstd::tr1::placeholders::_1です。
345:343
09/02/21 20:21:13
スレ違いな気がしてきた。C++スレへ行きます。すみません。
346:デフォルトの名無しさん
09/02/22 15:49:24
さあもう一度アインシュタインでなにか例え話してみれば？
347:デフォルトの名無しさん
09/02/22 17:01:38
誰もアインシュタインで例えたことなんて無いと思うが。
348:デフォルトの名無しさん
09/02/22 17:47:07
誰かアインシュタインclass作れよ
349:デフォルトの名無しさん
09/02/22 18:35:28
__declspec(dllimport) class Einstein * __stdcall BangEinstein(void);
class Einstein *Albert=BangEinstein();
350:デフォルトの名無しさん
09/02/22 18:55:22
assert(E==mc2)
351:デフォルトの名無しさん
09/02/22 19:19:11
アインシュタインタンジェント
352:デフォルトの名無しさん
09/02/23 10:05:15
もう拡張メソッドも組み込んじゃえよ
353:デフォルトの名無しさん
09/02/23 19:54:44
C++に拡張メソッドは色々と面倒で厄介な問題があるから無理
354:デフォルトの名無しさん
09/02/23 23:39:28
もうちょっと説明ｸﾚ
抽象的な言い方では判らないよ
355:デフォルトの名無しさん
09/02/24 00:23:27
ヒント：拡張メソッドはメンバ関数もどきを提供するんだから
当然ポインタから->を通して呼ぶこともできるべきだよな、C++的に考えて
ここから思いつく面倒ごとに思いを馳せれば現実的じゃないという結論には簡単にたどり着く
356:デフォルトの名無しさん
09/02/24 05:30:40
>>355
テンプレートメンバ関数の特殊化と同じような方法で実装すればいいんじゃね？
あれも新しいメンバ関数をクラスの定義の外で作ってるわけだし。
357:デフォルトの名無しさん
09/02/24 10:13:33
なんか演算子余ってないの？
p->>func() を func(p) の糖衣構文として扱うとかそんなんでいいんだが
358:デフォルトの名無しさん
09/02/24 10:17:34
>>356
特殊化はシグネチャを変えているわけじゃない。
359:デフォルトの名無しさん
09/02/24 15:44:17
>>357
->* とか?
でも (p->*func)() みたいに括弧が必須なのが面倒。
360:デフォルトの名無しさん
09/02/24 18:49:01
>>359
肛門を指してるように見えた俺は逝ったほうがいいんだろうな orz
361:デフォルトの名無しさん
09/02/24 19:02:12
)*(
362:デフォルトの名無しさん
09/02/24 22:53:49
>>352
拡張メソッドのメリットって何？
363:デフォルトの名無しさん
09/02/25 01:13:23
>>361
むしろ梅干し食べてる感じ
364:デフォルトの名無しさん
09/02/25 03:35:03
>>356
難しく考えすぎ
普通に第一引数がthisでそれ以外が普通の関数の定義と同じようになるようにすれば良い。
たとえば
class foo {}; // 定義
class foo { int bar(int baz) { return baz; } }; // 拡張メソッド(C#風)
って書いたら
int foo_extended_method_bar(foo* this, int baz) { return baz;}
って書くのと同じようになるようにすればいい。
でも継承したらどうなるかとかは知らん
>>362
使ったこと無いからわかんないなぁ
rubyのサンプルコードで良く見るけど
365:デフォルトの名無しさん
09/02/25 09:00:55
>>364
なにその生産性の低い記述は。
366:デフォルトの名無しさん
09/02/25 09:13:32
あくまで後から擬似的にメンバメソッドを追加できるようにするシンタックスシュガーでしょ。
あんまりいい例じゃないけど、なんでこの行列クラス、固有値求められないんだよ…ってときに：
#include "matrix"
// class Matrix;
#include "eigenvalues"
// vector<double> eigenvalues(const Matrix& this);
Matrix m;
auto es = m.eigenvalues(); // eigenvalues(m); と同等
Matrix* pm;
pm->eigenvalues(); // eigenvalues(*pm);
367:デフォルトの名無しさん
09/02/25 11:11:44
比較的簡単な処理の流れはメソッドチェイン出来ると楽ってだけかと
ただC++だと例外を軽く使えないからエラー処理をどうしようってことでMaybeモナドが欲しくなる
368:デフォルトの名無しさん
09/02/25 12:10:37
>>366
例が悪すぎます
369:デフォルトの名無しさん
09/02/25 12:45:38
>>366
Matrixをテンプレートの型パラメータで渡したときなんか拡張メソッドの定義includeの読み込み順で拡張メソッドが適用されたりされなかったりするのかな
370:デフォルトの名無しさん
09/02/25 15:11:17
oven(egg)のpipableは拡張メソッドっぽい
371:デフォルトの名無しさん
09/02/25 19:56:06
ソースが短くなるだけで、生産性の低い、動きがトロい、そんなバイナリーができそうだな。
現状のSTLも遅いし。
372:デフォルトの名無しさん
09/02/25 20:06:19
拡張メソッドの解決は動的ポリモルしなければコンパイル時に行うことができるんでそうとも言いきれない
373:デフォルトの名無しさん
09/02/25 22:40:52
第一引数を前に出す、単なる糖衣構文だから、バイナリが遅くなるなんてことはないわ
374:デフォルトの名無しさん
09/02/25 23:12:40
C++だとただの糖衣じゃ済まないから注意しないとオーバーヘッドはかかるな
375:デフォルトの名無しさん
09/02/25 23:15:33
operator.ぐらいの糖衣
376:デフォルトの名無しさん
09/02/25 23:47:58
generic functionがあるのに必要ですかね。
377:デフォルトの名無しさん
09/02/26 01:09:52
>>372
それが問題なんでねぇかい
テンプレートメンバ関数はその辺上手く逃げたよなぁ
378:デフォルトの名無しさん
09/02/26 05:05:59
普通のオーバーロード解決でなんか問題あるんか。
379:デフォルトの名無しさん
09/02/26 11:52:07
>>378
kwsk
380:デフォルトの名無しさん
09/02/26 13:18:24
objがfuncメソッドを持ってなくて、スコープにfunc拡張関数がある場合、
obj.func(args) を func(obj, args) と字面上同義みなすってことでは？
381:デフォルトの名無しさん
09/02/26 13:20:17
generic functionがあるのに必要ですかね。
382:デフォルトの名無しさん
09/02/26 13:35:21
必要です。目的が違います。
383:デフォルトの名無しさん
09/02/26 13:39:08
ほとんど変らないんじゃない？
virtualにならないんだし。
384:デフォルトの名無しさん
09/02/26 13:44:28
generic functionて何。
385:デフォルトの名無しさん
09/02/26 18:48:11
あるオブジェクトに対して行う処理を
まずオブジェクト名から入力できるとインテリセンスとかで楽できるんだよね
候補が狭まるから
386:デフォルトの名無しさん
09/02/26 20:08:43
あほくさ
387:デフォルトの名無しさん
09/02/26 22:52:27
今時インテリセンスも使いこなせない奴がいるのか・・・
388:デフォルトの名無しさん
09/02/26 22:56:03
0xの次で多重ディスパッチが入れば一緒に入るんじゃないかい＞拡張メソッド
389:デフォルトの名無しさん
09/02/26 23:18:24
汎関数の多重ディスパッチは既にある。
390:デフォルトの名無しさん
09/03/15 11:12:39
おっぱいを大きく見せたくて多重ブラジャーする美少女中学生
391:デフォルトの名無しさん
09/03/15 12:53:17
久々に上がってるんで見に来てみたら…
この前、時間が作れたんでようやくmailing2009-02を少し読めた。
久々の単独署名のDouglas Gregorの"Concepts and Ref-qualifiers"、
いやーやはりRvalue Referencesは難しいですね。
それからDouglas GregorってAppleに就職したんだな。(2008/10)
古くはIOKit、今はWebKitとC++結構使ってるからな。
392:デフォルトの名無しさん
09/03/15 15:36:14
0xって本当に0xに出せるの?
393:デフォルトの名無しさん
09/03/15 15:46:12
残念ながら1xがほぼ決定
394:デフォルトの名無しさん
09/03/15 15:47:12
でも未完成のまま強引に0xに出しそうな気もする
やめてほしいけど
395:デフォルトの名無しさん
09/03/15 15:50:09
ISOの手続きのスケジュールの都合で無理なのでは？
それがなかったとしても十分09に間に合いそうもないが。
396:デフォルトの名無しさん
09/03/15 16:03:26
もう出しても意味ネーよ。
397:デフォルトの名無しさん
09/03/15 16:24:56
>>391
auto concept HasAssign<typename T, typename U> {
typename result_type;
result_type T::operator=(U) &; // ←Rvalue reference!
}
ﾜﾛｽ
398:デフォルトの名無しさん
09/03/15 18:27:34
>>395 そうきいている
399:デフォルトの名無しさん
09/03/15 21:34:43
autoっぽいものを現行のC++で実現するマクロってあったような気がするんですがマクロ名を知りませんか
400:デフォルトの名無しさん
09/03/15 21:56:24
BOOST_AUTOのこと？
401:デフォルトの名無しさん
09/03/15 22:44:53
gccのtypeofかなぁ？
402:デフォルトの名無しさん
09/03/21 14:58:40
僕は言語仕様の問題のほか、現実的な理解者とコンパイラがいつ現れるかも
気になる。現行のSTLやBoostですらコンパイルエラー、ワーニングが長すぎて
解読困難なのに、これ以上になるのかと思うと気が重くなる。
403:デフォルトの名無しさん
09/03/21 14:59:11
しまった・・・sage忘れた・・・
404:デフォルトの名無しさん
09/03/21 15:03:06
C++0xのconceptにはエラーメッセージを簡易にする目的もあります。
405:デフォルトの名無しさん
09/03/21 15:03:38
俺を含む凡人以下からすれば
「まずはまともな処理系を出してくれ、話はそれからだ」
だからな
WGにいる仕様書だけでコードを書いてあーだこーだ議論してる奴等は化け物に思えてくる
406:デフォルトの名無しさん
09/03/21 15:06:55
>>404
一般的な開発者がその恩恵を受けられるのは、
どんなに早くても2012年頃かと思われますw
407:デフォルトの名無しさん
09/03/21 15:12:33
concept については厳しいだろうけど他の機能についてはちょこちょこ実装されつつあるじゃん。
408:デフォルトの名無しさん
09/03/21 17:13:32
可変長テンプレートとか右辺値参照とかばっかり先行してて
可読性を良くする機能はことごとく後回しにされてるけどな
409:デフォルトの名無しさん
09/03/21 17:16:56
可変長テンプレートはありがたいだろ。
TEMPL1(X)
TEMPL2(X1, X2)
TEMPL3(X2, X2, X3)
：
TEMPL20(X1, X2, X3 .. X20)
とかもうイヤだよ。
410:デフォルトの名無しさん
09/03/21 17:24:11
そりゃそうだけど、ソースが読みやすくなる訳じゃないじゃん
エラーメッセージは多分もっとわかりにくくなるだろうし
411:デフォルトの名無しさん
09/03/21 17:27:25
可変長テンプレートが「可読性を良くする機能」ではないとすると、
後回しにされてる機能って何のこと言ってるの？
412:409
09/03/21 17:29:11
>>410
そりゃまあ一般論としてはそうかな。
ただ俺は馬鹿だからか、機械生成しなかったのが悪いのか、
5引数のやつだけ書き間違えて大填まりしたことあるわ。
気づくわけないっての
413:デフォルトの名無しさん
09/03/25 03:24:35
URLﾘﾝｸ(www.open-std.org)
News 2009-03-24: The 2009-03 post-Summit mailing is available
News 2009-03-24: The C++ Standard Core Language Issues List (Revision 62) is available
News 2009-03-24: The C++ Standard Library Issues List (Revision 63) is available
414:デフォルトの名無しさん
09/03/25 12:21:54
というわけで最新のWorking DraftはN2857ですか。
415:デフォルトの名無しさん
09/03/25 18:44:11
あんまり面白くねーな
ラムダ関係がボロボロで全面書き直しって事くらいか
あと日本からのコメントrejectされまくり
416:デフォルトの名無しさん
09/03/26 21:07:56
結局ラムダ式って Monomorphic なやつだけしか入らんの？
型名書くのだりーよ…
結局 Boost.Lambda のほうが便利じゃんってオチ？
417:デフォルトの名無しさん
09/03/27 05:20:03
>>416
何言ってるのかわからん。 Boost.Lambda のどんな用法のことを言ってるの？
C++0x のラムダ式で置きかえらない用法があるってことなんだよね？
418:デフォルトの名無しさん
09/03/27 08:58:21
>417
単に引数の型書くのが面倒という話では？
_1 + 1
[] (int n) { return n + 1; }
もともともラムダ式の提案では引数の型を指定しないでよいものも込みだったんだけど、
分割して型を指定するものだけ先に持ってきたのが Monomorphic なラムダ式のはず。
419:デフォルトの名無しさん
09/03/27 09:13:54
[] (auto x) { (ry }とか[] (x) { (ry }とかでできないのかな？
420:デフォルトの名無しさん
09/03/27 11:06:48
>>417
Boost.Lambda は多相じゃん。
(_1 + _2)(1, 1) // -> int 2
(_1 + _2)(1.0, 1.0) // -> double 2.0
単相にして保持したければ
function<double(double, double)> f = (_1 + _2);
f(1, 1) // double 2.0
とかもできるし。
ちょっと調べてみたら n2529 で、
(n2329 にあるように higher implementation cost なんで)
"We do not propose generic lambda functions for C++0x."
って書いてあるな… これはダメっぽい。
421:デフォルトの名無しさん
09/03/27 12:35:25
range based algorithmの採用も却下されたことだし
まだまだboostの役目は終わらないということだな
422:デフォルトの名無しさん
09/03/27 17:45:45
boostの肝心な機能を骨抜きにしたのが標準だな
結局みんなboostを使い続け、std名前空間を汚染するゴミが残るだけという
423:デフォルトの名無しさん
09/03/28 14:18:37
という意見をぜひ comp.std.c++ あたりに投稿してくれ
日本の総意ってことで
424:デフォルトの名無しさん
09/03/29 10:22:55
> range based algorithmの採用も却下されたことだし
（ ﾟдﾟ）
425:デフォルトの名無しさん
09/03/30 13:50:22
配列初期化の記述だけはサッサと実現してほしい。
426:デフォルトの名無しさん
09/03/30 19:48:55
関数型言語とC/C++の関数ってどういう関係？
427:デフォルトの名無しさん
09/03/30 19:54:20
特に関係はない
428:デフォルトの名無しさん
09/03/30 19:55:43
ちょっと確認。
cout<<boolalpha<<uppercase<<true;
ってした場合でも、TRUE(大文字)とは出力されないんだっけ？
それで規格どおり？
429:デフォルトの名無しさん
09/03/30 20:14:51
>>427
そんなこともないだろ。両方関数だし。
430:デフォルトの名無しさん
09/03/30 20:16:11
じゃあC/C++の関数が関数型言語とどう関係あるのか教えてよ
431:デフォルトの名無しさん
09/03/30 20:22:42
関数型言語の関数は、数学的な関数ほぼそのもののことを指している。
Cとかの関数は、それから来ている名前ではあるけど、(サブ)ルーチンのことを
そう呼んでるだけ。たまに数学的な関数のような性質を持ってることもある。
432:デフォルトの名無しさん
09/03/30 21:42:56
>>431
いや>>426は「関数型言語における関数と、C/C++における関数」の性質の違いを
知りたがっているのではなくて、「関数型言語」と「C/C++の関数」の関係を知りたがってる。
葉巻型UFOと日本たばこ産業の関係を質問するくらい、わけのわからない質問ではあるが。
433:デフォルトの名無しさん
09/03/30 22:04:53
＞関数型言語の関数は、数学的な関数ほぼそのもののことを指している。
＞たまに数学的な関数のような性質を持ってることもある。
ん？どう違うの？
434:デフォルトの名無しさん
09/03/30 22:20:25
つ URLﾘﾝｸ(ja.wikipedia.org)
435:デフォルトの名無しさん
09/03/30 22:25:30
さすがwikipedia
436:デフォルトの名無しさん
09/03/30 22:27:55
つまり状態の使用や副作用をおこさなければ関数型言語と等価ということですね。
437:デフォルトの名無しさん
09/03/30 22:41:34
>>436
基本的には Yes.
ただし、状態も副作用もない関数を書くとしても、
手続き的な考え方だとローカル変数を値を変えながらループして計算したりするのに対し、
関数型言語的な考え方だとローカル変数に一度束縛したら値を変えず、ループのかわりに再帰とか集合演算とかを使う。
そこらへんの美学の違いは理解すべきかな。
438:デフォルトの名無しさん
09/03/30 23:44:29
>>428
真偽値を表す文字列をnumpunctから取得して、
ストリームへ「インサートする」って書いてあるから、
uppercaseは適用されないね。
取得した文字列を再度operator<<するわけじゃないから。
439:デフォルトの名無しさん
09/03/30 23:46:01
それで自分流のnumpunctを定義する方法は、
22.2.8.13に例が挙げてある。
440:デフォルトの名無しさん
09/03/31 09:00:20
その筋の用語では「参照透明性」な
441:デフォルトの名無しさん
09/03/31 10:01:21
ぷ
442:デフォルトの名無しさん
09/03/31 16:41:02
美少女中学生のおなら？
443:428
09/03/31 19:51:14
>>438-439
ありがと。
規格の該当パラグラフも確認しました。
locale関連になっちゃうのね。。。
そのあたりの深入りは避けたいので、簡単に文字列として
出力しようと思いますた。
444:デフォルトの名無しさん
09/03/31 20:30:21
そうそう。
結局、os << b ? "TRUE" : "FALSE";を関数にまとめればいいやというとこに落ち着いちゃうんだよね。
445:438
09/04/02 17:10:08
本来の主旨とちょっと違ってくるけど、
マイ書式には引数付きマニュピュレーター使って
その中で出力しちゃってる。
けどこれC++0xの話題じゃないじゃんw
446:デフォルトの名無しさん
09/04/02 18:39:32
美少女中学生の話題をしようぜ！
447:デフォルトの名無しさん
09/04/02 23:27:37
女子中学生をいじったら汁が出てきたよ（＾－＾）
448:428
09/04/03 21:06:55
>>445
あー、たしかにマニピュレータはよさそう。
また機会があったらオレもそうしよ。
>けどこれC++0xの話題じゃないじゃんw
そうだった。ｗ
でも、C++で規格ガチの話ってこのスレが一番じゃね？
449:デフォルトの名無しさん
09/04/04 00:34:14
>>448
C++相談室でいいよ。だいたい規格ガチで文句言われるスレなんてないだろ。
450:デフォルトの名無しさん
09/04/04 15:20:15
ここは標準化委員会の迷走を横目で生暖かく見守るスレです
451:デフォルトの名無しさん
09/04/05 01:16:11
そんなんだから日本からのコメントがrejectされまくるんだよ。
452:デフォルトの名無しさん
09/04/05 01:21:45
あれは結構な割合で、rejectされるだろうけど一応送っておくか、的な雰囲気のものが入っていた気がする。
453:デフォルトの名無しさん
09/04/05 02:50:54
どーせ仕事じゃ誰も使わないよ。
454:デフォルトの名無しさん
09/04/05 03:45:10
>>452
Unicode関係とか結構気合い入れて議論してたんじゃないの？
サックリrejectされてて笑ったが
455:デフォルトの名無しさん
09/04/05 16:09:19
あんなコメント読まされる方もたまったもんじゃない。
かなり基本的な部分でUTF-8前提にしろとかもうアホかと。
456:デフォルトの名無しさん
09/04/05 17:24:29
URLﾘﾝｸ(ja.wikipedia.org)ビャーネ・ストロヴストルップ
ビャーネ・ストロヴストルップ（Bjarne Stroustrup, 1950年6月11日 - ）は、
デンマークのオーフス生まれのコンピュータ科学者。
本人による自身の名前の発音は「びよーねすっぽすっぽ」に近い。
457:デフォルトの名無しさん
09/04/05 20:12:24
URLﾘﾝｸ(www.research.att.com)
URLﾘﾝｸ(www.research.att.com)
どのへんが近いんだ？
458:デフォルトの名無しさん
09/04/05 20:34:26
そうだよな、「すっぽすっぽ」じゃなくて「すぽっすぽっ」だろ？
459:デフォルトの名無しさん
09/04/05 20:41:39
JPのコメントにすぽすぽも呆れとったわ
460:デフォルトの名無しさん
09/04/05 23:11:55
とりあえず提案だけは出しておこうってのはどう考えても間違いだったな
無理なものは無理と委員会で止めるべきだった
461:デフォルトの名無しさん
09/04/06 01:07:29
説明が足りてるか、表現が正確か、おかしな解釈が出来てしまわないか、あたりの確認なのに
JPだけ変な気合い入れて新機能の提案みたいなことしてて明らかに浮いてる
恥ずかしいわ
462:デフォルトの名無しさん
09/04/06 01:09:30
そんなことに恥ずかしがるのはJPだけ
みんな言いたいこと言ってる
463:デフォルトの名無しさん
09/04/06 04:26:23
「スドゥハウっスドホッブ」を「すっぽすっぽ」のリズムで読めば良い。
strou と strup の間の「っ」(stød) で声門を絞めるのが肝
464:デフォルトの名無しさん
09/04/06 09:22:45
肛門が閉まりました。
つーか読みにくい時は、呼び名つけるだろ？
てきとうに、太郎とかつけりゃいいんだよ。
465:デフォルトの名無しさん
09/04/06 09:46:58
禿
466:デフォルトの名無しさん
09/04/06 10:19:55
そんな議論はどこで読めるんですか？
467:デフォルトの名無しさん
09/04/06 10:35:34
>>457
ほんとだ、「びや～ね=すぽっすぽっ」に聞こえる。
468:デフォルトの名無しさん
09/04/06 14:42:26
あまりの卑猥さに美少女中学生も赤面！！！！！！１１１１
469:デフォルトの名無しさん
09/04/06 18:44:45
生粋のデニッシュには言いやすい発音なんだろうな
470:デフォルトの名無しさん
09/04/07 15:54:36
C++0x出たらJAVAとかいらなくなるんだよね？
またCさえあればいい時代が来るってことか
471:デフォルトの名無しさん
09/04/07 18:39:09
Javaがどうなるかは知らんが、0xはGC付き言語の代わりにはならんよ
472:デフォルトの名無しさん
09/04/07 19:16:45
Javaと対抗になるのはC#とC++/CLIだわな
473:デフォルトの名無しさん
09/04/08 04:33:23
D…いやなんでもない
474:デフォルトの名無しさん
09/04/08 06:13:38
>>473
Delphiですね、わかります
475:デフォルトの名無しさん
09/04/08 08:57:43
C# vs Java
F# vs Scala
C++ vs D…いやなんでもない
476:デフォルトの名無しさん
09/04/08 10:49:00
>>473-475
おまいらとは別スレであってるような気がしてならない
477:デフォルトの名無しさん
09/04/08 12:02:15
>>458
URLﾘﾝｸ(twitter.com)
478:インドリ
09/04/09 10:06:39
URLﾘﾝｸ(blogs.wankuma.com)
URLﾘﾝｸ(d.hatena.ne.jp)
479:デフォルトの名無しさん
09/04/09 13:49:35
> 税込2,940円
高い！
480:デフォルトの名無しさん
09/04/09 14:23:51
淫鳥
481:デフォルトの名無しさん
09/04/09 17:17:02
まあ、どうせ某所にうpされるだろうし
そうなったら眺めてみるか
482:デフォルトの名無しさん
09/04/09 17:31:41
C++でこの手の本を書くと、バッドノウハウの詰め合わせみたいになるのは必至だろ…
483:デフォルトの名無しさん
09/04/09 17:37:08
だがそれがいい
484:デフォルトの名無しさん
09/04/10 00:19:14
びよーんすぽっすぽっ
誰も名前だとは気づかないな
485:デフォルトの名無しさん
09/04/10 00:44:38
バッドでもナンでも成程と思わせる何かが含まれてるかどうか
邦人の著者は入門レベルでお茶濁すパターンの繰り返しだからねぇ
486:デフォルトの名無しさん
09/04/10 01:18:06
>>484
「びよーん」じゃないよ「びや～ね」だよ。
487:デフォルトの名無しさん
09/04/10 01:49:46
MC++Dの焼き直しみたいな本じゃなけりゃいいけどな
488:デフォルトの名無しさん
09/04/10 02:01:02
参考書買ったつもりが
中身は校正不足な教科書崩れですタ
みたいな
489:デフォルトの名無しさん
09/04/10 02:16:06
入門書はもういいよ
490:デフォルトの名無しさん
09/04/10 02:39:24
ガチガチの数学選書みたいにまともなコンパイラもない今の時点での0xの応用を書いてある本がほしいです。
491:デフォルトの名無しさん
09/04/10 12:08:52
どうせ著者のブログ記事の焼き直しでしょ
492:デフォルトの名無しさん
09/04/10 14:04:27
誰も仕事じゃ使わんだろ。
493:デフォルトの名無しさん
09/04/10 19:13:34
>>490
つ 規格書
494:デフォルトの名無しさん
09/04/10 20:34:27
規格書に応用なんて書いてないだろ。
495:デフォルトの名無しさん
09/04/12 03:56:21
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
496:デフォルトの名無しさん
09/04/14 20:39:55
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
497:デフォルトの名無しさん
09/04/15 00:29:40
_, ._
（ ・ω・）
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
~~~~~
498:デフォルトの名無しさん
09/04/15 00:33:54
テンプレートクラスを入れ子にすると>>演算子が優先されてエラーになることが何度かあったんだが
これって次で直るかなぁ？ 演算子の優先度の問題だから無理だよな・・・？
499:デフォルトの名無しさん
09/04/15 00:39:49
>>498
C++0xでは vector<vector<int>> も大丈夫
500:デフォルトの名無しさん
09/04/15 02:19:16
URLﾘﾝｸ(www.open-std.org)
これな
gcc 4.3では取り込まれてる
501:デフォルトの名無しさん
09/04/15 02:20:57
まあ、読みづらいから俺は空白であけるけどな
502:デフォルトの名無しさん
09/04/15 23:37:36
ビルド通らないから空白あけてるけどさｗ
3つ以上入れ子にすると逆に見づらいというか、typedefつかえってことか。
503:デフォルトの名無しさん
09/04/16 01:44:57
そんなに入れ子にしたら、遅くてたまらんだろ。
504:デフォルトの名無しさん
09/04/16 01:55:51
それほどでもない
505:デフォルトの名無しさん
09/04/16 12:48:27
いや遅いって。
javaや.netよりかなり遅くなるぞ。
506:デフォルトの名無しさん
09/04/16 12:50:07
遅いってコンパイルの話じゃなかったの？
507:デフォルトの名無しさん
09/04/16 17:40:23
何だそりゃ？
508:デフォルトの名無しさん
09/04/16 18:14:57
javaや.netよりかなり遅くなるって何のネタだよｗ
509:デフォルトの名無しさん
09/04/16 18:32:55
コンパイルの時間の話なら、そんな入れ子にしなくても元から十分遅いし。
510:デフォルトの名無しさん
09/04/16 18:34:26
コンパイルはC++よりC#の方が速いって話でしょ。実行速度の話じゃない
でもMPLでもやらない限りテンプレートはあまり関係ないと思うけどね
511:デフォルトの名無しさん
09/04/16 19:47:04
MPL = MetaProgramming Library な。
512:デフォルトの名無しさん
09/04/16 21:35:25
TMP!TMP!
513:デフォルトの名無しさん
09/04/16 21:36:15
vectorを三つ入れ子にしたら、実行速度は確かにスゲー遅くなるだろうな。
514:デフォルトの名無しさん
09/04/16 21:42:46
MPL() { 笑 };
515:デフォルトの名無しさん
09/04/17 02:17:16
実行速度の話だろ？
バカなのか？お前らは。
516:デフォルトの名無しさん
09/04/17 04:37:53
誰が真の馬鹿なのかは、俺の心の中にしまっておくよ。
517:デフォルトの名無しさん
09/04/17 06:16:19
そこでしか生きられない言い分だものな。
518:デフォルトの名無しさん
09/04/17 08:47:38
みんなでシャドーボクシング
519:デフォルトの名無しさん
09/04/17 10:02:29
じゃあこの山括弧をくっつけて動くようにしろよ！
520:デフォルトの名無しさん
09/04/17 10:15:20
lヽ ﾉ l ｌ l ｌ ヽ ヽ
)'ｰーノ( | | | ､ / l｜ ｌ ハヽ |ｰ‐''"ｌ
/ M | | |／| ﾊ / / ,/ /|ﾉ /l / ｌ l ｌ| ｌ M ヽ
l ･ i´ | ヽ､| |ｒ|| | //--‐'" ｀'メ､_ｌﾉ| / ・ /
| P l トー-トヽ| |ノ ''"´｀ ｒｰ-/// | P ｜
| ･ |／ | l ||､ ''""" j ""''/ | |ヽｌ ・ ｜
| L | | l | ヽ, ― ／ | | ｌ L |
| !! | / | | | ` ｰ-‐ ' ´|| ,ﾉ| | | !! ｜
ノｰ‐---､,| / │ｌ､l |ﾚ' ,ﾉﾉ ﾉハ､_ノヽ
/ ／ ノ⌒ヾ､ ヽ ノハ, |
,/ ,イーｆ'´ /´ ＼ | ,／´ ｜ヽl |
／-ト、| ┼―- ､_ヽﾒr' , -=ｌ''"ハ | ｌ
,／ | ヽ ＼ _,ノｰｆ' ´ ﾉノ ヽ ｜ |
､_ _ ‐''ｌ `ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ _,ノ ノ
￣￣ | ／
プロプロセッサ・メタプログラミングもお忘れなく。
521:デフォルトの名無しさん
09/04/17 11:00:58
c++で何でわざわざ遅いプログラムつくらなあかんのか。
メタなんて価値なしのオナニーだよな。
522:デフォルトの名無しさん
09/04/17 11:06:51
はいはいクマクマ
523:デフォルトの名無しさん
09/04/17 17:18:26
JVM向けのコンパイラ書く奴いねぇかなぁ。
そしたら、ワザワザJavaに書き換える事もなくなって便利なんだが。
ところで、いつのまにやら入れ子クラスから外のクラスにアクセス
出きるようになったんだな。BCC5.5だったか、CL8.0だったか
対応してなくて、ずっとそういうもんだと思い込んでfriend使ってたわ。
524:デフォルトの名無しさん
09/04/17 17:49:55
>>519
なるよ。
525:デフォルトの名無しさん
09/04/18 01:38:10
VECTOR３つでも用途によるだろ。
いまどき遅いといっても知れてるわ。
526:デフォルトの名無しさん
09/04/18 02:31:07
数えられる程度にしか回らないコード部分なら結果が正しければ少々何しようと勝手だよな
527:デフォルトの名無しさん
09/04/18 04:00:06
まったくだ
とはいえ、vectorを三つも入れ子にするようなコードが
数えられる程度にしか回らないケースって少ないような気もするけどな
528:デフォルトの名無しさん
09/04/18 08:28:02
>>513は知恵おくれだろ
馬鹿馬鹿しいからスルー推奨
529:デフォルトの名無しさん
09/04/18 10:49:30
>>528
知恵遅れはお前だろカスだな。
530:デフォルトの名無しさん
09/04/18 12:17:11
本人登場。幼稚なオウム返しによって相手の見方が正しいと証明してしまいました。
531:デフォルトの名無しさん
09/04/18 12:35:00
読み書きの速度は配列と変わんないですよね？
サイズ変更は起こらないケースで
532:デフォルトの名無しさん
09/04/18 13:05:02
違う。配列とは別物なんだから変わってもおかしくない。コンパイラの頑張り次第。
533:デフォルトの名無しさん
09/04/18 13:12:48
コンパイラ？
534:デフォルトの名無しさん
09/04/18 13:19:00
コンパイラ∋オプティマイザ
535:デフォルトの名無しさん
09/04/18 13:21:05
>>532
別物なんですか？どう違うんですか？
536:デフォルトの名無しさん
09/04/18 13:21:59
同じだよ。
537:デフォルトの名無しさん
09/04/18 13:41:32
配列とvectorは全く同じというわけではない。
でも要素を指すポインタの配置だとかの制限が多々あって、
vectorの内部構造は配列を使うことが多い。
その場合、最適化次第で配列とほぼ同じ速度で動かせる。
538:デフォルトの名無しさん
09/04/18 15:02:39
どちらかというと
たいていの場合はまったく同じ速度で動かせる、のが正しいだろ
なんだよほぼ同じ速度ってｗ
539:デフォルトの名無しさん
09/04/18 15:04:19
operator[]をいちいち呼び出すかもしれないって事でわ？
540:デフォルトの名無しさん
09/04/18 15:12:03
実測しろ。
vectorは連続性が保証されているから、&[0]で先頭アドレスを取って配列として使うなら、配列と同速度であろうことは想像できる。
ただ、配置される場所がヒープかスタックによっても速度は変わるかもしれない。
541:デフォルトの名無しさん
09/04/18 15:19:17
実測、実測って、様々なプラットフォームで実行するプログラムはどうするんだよ。
何でもアホみたく実測する前に、一般論で考察しろ。
542:デフォルトの名無しさん
09/04/18 15:27:11
>>541
様々なプラットフォームで実測して、場合によっては最適な実装を
コンパイラスイッチで切り替えるぐらいはしてもいいんじゃない。
一般論で考察して済むようなら、最初から速度が問題になるような箇所じゃないってことだよ。
543:デフォルトの名無しさん
09/04/18 15:29:40
実測馬鹿
544:デフォルトの名無しさん
09/04/18 15:34:52
なんちゃってー！カクカクカクカクカク！
545:デフォルトの名無しさん
09/04/18 17:06:23
544 名前：デフォルトの名無しさん[sage] 投稿日：2009/04/18(土) 15:34:52
なんちゃってー！カクカクカクカクカク！
546:デフォルトの名無しさん
09/04/18 17:12:51
激烈バカとはなつかしい
547:デフォルトの名無しさん
09/04/18 19:31:45
カクカクと聞いていやらしいことを想像してしまった美少女中学生がこのスレにいます！
548:デフォルトの名無しさん
09/04/18 23:16:36
>>540
保証されてない
549:デフォルトの名無しさん
09/04/18 23:18:40
されてるよ。
550:デフォルトの名無しさん
09/04/18 23:26:03
当初03の規格には入ってなかったんだけど
後から委員会のほうで「そういう風に作ってね」って付け加えたんだっけか。
いずれにしても現在では保証されてたはず。
551:デフォルトの名無しさん
09/04/19 01:17:23
23.2.4.1(2003年版)に
> The elements of a vector are stored contiguously, meaning that if v is
> a vector<T, Allocator> where T is some type other than bool, then it
> obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().
と明記されているのでれっきとした仕様です。1998年版にはありませんでした。
552:デフォルトの名無しさん
09/04/19 01:42:29
まあ、むやみに大きさかえまくってたら遅いだろうけど、そういう場合はlist使うだろうし
どっちにしろ入れ子にしなきゃならんものは、Cで書いてもそれなりに重い処理になる。
ということは、使った方が手軽で安全ということになるな。
553:デフォルトの名無しさん
09/04/19 02:34:15
伸びてたから期待して来たのにこんな流れかよ…
ムーブセマンティクスがどう効くかとかarrayと比べてどうとかいう話かと思ったのに
03以前だけの話ならSTLスレでやれよ
554:デフォルトの名無しさん
09/04/19 03:44:12
548 名前：デフォルトの名無しさん[sage] 投稿日：2009/04/18(土) 23:16:36
>>540
保証されてない
555:デフォルトの名無しさん
09/04/19 09:32:40
>>552
それはないだろ。
556:デフォルトの名無しさん
09/04/19 14:49:10
3重vectorの話がでてたけど、
vectorってムーブセマンティクスやCOW
の実装あるんだっけ？
557:デフォルトの名無しさん
09/04/19 18:23:47
あるよ。
558:デフォルトの名無しさん
09/04/19 21:42:09
素朴な疑問すまん。
C++0xってx=9になるの?
それともなんかしくじって、
C++1xに続くの?
559:デフォルトの名無しさん
09/04/19 21:57:41
もう09にはならないはず
560:デフォルトの名無しさん
09/04/19 22:02:11
C++0xAでも0xBでもいいから早く出て来い。
561:デフォルトの名無しさん
09/04/19 22:10:10
>>558
八進数なのに9はない。
562:デフォルトの名無しさん
09/04/19 22:20:41
なんで八進数なんだろね。
K&Rもビット演算で八進数使うんだよね。
二進数と十六進数しかなじみのなかった自分は
ちょっとデカルチャーだった。
563:デフォルトの名無しさん
09/04/19 22:32:06
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
564:デフォルトの名無しさん
09/04/19 23:51:30
C言語 → UNIX → PDP-11
後はもう分かるな？
565:デフォルトの名無しさん
09/04/20 00:10:43
わからない
566:デフォルトの名無しさん
09/04/20 00:48:32
1バイト9ビットのマシンだと八進法も使う機会があると聞いたことがあるけど、PDP-11は違うよね？
567:デフォルトの名無しさん
09/04/20 04:06:37
二進数ベースの数値を10キー(の数字)だけで二進数直打ちよりは楽に入力できるからだよ。
568:デフォルトの名無しさん
09/04/20 08:23:01
x == 10 (ローマ数字)という
無理矢理解釈で2010年リリースか？
569:デフォルトの名無しさん
09/04/20 09:06:44
昔はコンソールにテンキーしかない計算機たくさんあったから。
だから昔の人は基本8進数と10進数。
古いアセンブラの仕様を漁れば分かる。
570:デフォルトの名無しさん
09/04/20 09:35:47
それはない
571:デフォルトの名無しさん
09/04/20 09:47:51
>>561
標準化まえのCの処理系では'\91'(=73)とかできたらしい。
572:デフォルトの名無しさん
09/04/20 23:35:57
例えテンキー入力でも 「8」 「9」キーででもシフト管理すれば簡単に 16進打ち 可能じゃん
char get(char k){
static char f=0;
if(k==9){f=8;return 16}
if(k==8){f=0;return 16}
if(k>=0&&k<=7) return k|f;
つらつら;
}
573:デフォルトの名無しさん
09/04/21 03:28:00
>>572
歴史も現場も知らない人間の机上の発想だな。同様のことを考えた人はいたかもしれんが表に出て主流になることはなかった、ってのはそういうことだ。
574:デフォルトの名無しさん
09/04/21 03:50:52
歴史を知っていると、10キーのカンマや演算子をa-fに割り当てる入力ツールを思い出せるんだけどね。
まぁ、>569はどうかと思うけれど。
575:デフォルトの名無しさん
09/04/21 08:01:02
10キー使わないし
576:デフォルトの名無しさん
09/04/21 08:11:18
俺もテンキー嫌いだし一生使うことは無いと思ってたが、
携帯のせいでテンキー的なものを強要されるようになったな。
577:デフォルトの名無しさん
09/04/21 08:15:48
>>568
ローマに0はなかった…
578:デフォルトの名無しさん
09/04/21 11:22:50
>>576
やっぱりテレビのチャンネルを変えるときは本体のを回したりするんですね
579:デフォルトの名無しさん
09/04/21 12:38:39
そういう人は、チャンネルを「変える」じゃなくて、
「回す」って言うらしいぞ。
580:デフォルトの名無しさん
09/04/21 18:19:48
>>569
当時は逆にテンキーがなかったんじゃ。
タイプライターにはテンキーなんかないし、
今と違ってスイッチいっこが高かった
だろうし。
8進数のいいわけはなんかで見た記憶が
ある。古いCかUNIXかの本だったか。
581:デフォルトの名無しさん
09/04/21 18:30:00
テンキーしかないコンピュータってのはマイコンキットとかだな。
582:デフォルトの名無しさん
09/04/21 18:42:28
>>569はど素人
583:576
09/04/21 21:01:55
>>578
携帯やパソコンのテンキーは少なくとも一秒に３タイプくらいは出来ないと効率悪すぎるし、
テレビのリモコンは３０分に１タイプできれば十分事足りるからな。
それとこれとは話が全然違うだろうとマジレスしておく。
584:デフォルトの名無しさん
09/04/21 21:05:27
玄人はこんなスレに来ません
585:デフォルトの名無しさん
09/04/21 21:33:04
回される想像をしてドキドキしている美少女中学生がこのスレにいる！
586:デフォルトの名無しさん
09/04/21 22:58:32
>>581
大丈夫、マイコンキットならきっと16キーだ。
587:デフォルトの名無しさん
09/04/22 03:42:50
>>566
マジレスするとインストラクションの基本形式が
16bit を 1+3, 3+3, 3+3 に分解して使ってたから
octal の方が表現しやすかった.
588:デフォルトの名無しさん
09/04/22 13:40:15
いつまで続けるんだ
589:デフォルトの名無しさん
09/04/22 15:18:38
単にioが四ビットだった名残だろ。
590:デフォルトの名無しさん
09/04/22 15:50:01
4ビットなら8進より16進の方が都合いいだろ