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ではつかえない
570:デフォルトの名無しさん
09/08/24 15:01:47
スペックは使うものではないのでは？
571:デフォルトの名無しさん
09/08/24 18:55:20
>>568
例外が発生しないように使う。
まったく問題ない。
572:デフォルトの名無しさん
09/08/24 19:26:07
404 ：デフォルトの名無しさん[sage]：2007/11/07(水) 22:28:18
conceptは間に合うんだろうか
405 ：デフォルトの名無しさん[sage]：2007/11/08(木) 04:58:25
あ、concept は余裕で間に合うよ。安心しといて。
それより問題なのは export なんだよ。実は。
408 ：デフォルトの名無しさん[sage]：2007/11/12(月) 21:22:45
concepts抜きでは送り出さんと書いてあるね。
URLﾘﾝｸ(herbsutter.spaces.live.com)
知らん間にスケジュールが1年ずれてたんだな…
573:デフォルトの名無しさん
09/08/25 19:58:56
>>568
具体的に、何の例外が欲しい？
>>569
具体的に、どれが遅かった？
574:デフォルトの名無しさん
09/08/25 21:17:33
C++の仕様には把握できないほどの仕様を常に盛り込んでいくべきだ
そうでなければ萌えない
575:デフォルトの名無しさん
09/08/25 21:29:13
ゼロオーバーヘッドルールだけで３杯はいける。
後の仕様はどうだっていい。
576:デフォルトの名無しさん
09/08/25 21:35:26
つ多重継承
577:デフォルトの名無しさん
09/08/25 21:46:16
俺的な萌えポイントはゼロオーバーヘッドとメタプログラミング
ただメタプログラミングはもう少し綺麗に書けるようになって欲しい
メタ演算子が定義できればなぁ
578:デフォルトの名無しさん
09/08/26 01:43:37
プロパティ入れて欲しい
579:デフォルトの名無しさん
09/08/26 02:01:34
アクセサめんどいしなぁ
確かにプロパティは欲しいっつーか構文糖だし簡単に入れられそうだけどなぁ
580:デフォルトの名無しさん
09/08/26 02:17:43
プロパティは=や->のオーバーロードが絡むとカオスになる
無理だろ
581:デフォルトの名無しさん
09/08/26 03:00:34
特定のアクセサ関数に何かしらの方法で紐付けして、直接アクセスしようとしたら後ろに
()が付いてると見なす、とかじゃ駄目なん？
俺的にはクラスを書くのが面倒とかより、アクセサかそうでないかで書き分けになるのが
後々まで悩ましくて困るんで、それさえ解決できれば十分嬉しいんだけど
582:デフォルトの名無しさん
09/08/26 05:10:55
TC++PL読んでて思ったけど、もう3rd出てから12年経つのな。
1986 1st 初の商用リリース(Cfront 1.0)
1992 2nd 標準化初期-テンプレートの実装(Cfront 3.0)
(1994 STL標準へ)
1997 3rd 標準ほぼ確定
(201x 4th C++0x確定)
各版の出版時期を調べてみたらこんな感じで、
3rdから12年を過去に遡るとTC++PLの初版すら出ていない時期で、
3rdが出た頃って今知られているような書籍は
Effectiveの初版とMore Effectiveくらいしか出てなかったんだよね。
そう考えると、3rdの頃から大きく変わったC++のプログラミングスタイルと、
C++0xを盛り込んだ4thが待ち遠しくて仕方ない。
583:デフォルトの名無しさん
09/08/26 10:20:14
Effectiveは、更新をこまめにやるから生き残っている。
昔も、C++ GEMSとか、CoplienのAdvanced C++ Programming Styles and Idioms、
Ruminations on C++とか、イディオム系のいい本はたくさんあった。
tC++PLは、イディオムはあまり書かずに、機能面に集中しているから、
このスレにいるような人は既知のことが多いのでは。
584:デフォルトの名無しさん
09/08/26 11:18:59
>>573
・メモリ確保に失敗したら、メモリ不足画面を出し速やかにアプリを終了させなければならない
という環境で、さらに例外が無かった。
ありえない
585:デフォルトの名無しさん
09/08/26 11:24:02
>>584
set_new_handler()も知らないのか
586:デフォルトの名無しさん
09/08/26 11:41:54
メモリ不足画面を出すメモリの確保に失敗したら？
587:デフォルトの名無しさん
09/08/26 11:48:21
>>586
そんなことがあると >584 の仕様を満たせないから、メモリ不足画面は追加の
メモリ確保が要らない状態で待機させとくべきだろう。
588:デフォルトの名無しさん
09/08/26 11:52:29
BREW環境の話だなたぶんｗ
あれは、メモリー確保に失敗しても正常にアプリが動作し続け、かつスレッドが使えず、かつOSに制御を戻さなければならない（無限ループ禁止）
また、終了の際自分が確保したメモリは全てきっちり解放しなければならない(long jumpでの大脱出禁止）
なのでset_new_handlerしてそこでエラー画面を出すこともできない
最近は例外使えるようになったから、メモリー確保失敗したらいっきにメインループの外までジャンプできるようになった
589:デフォルトの名無しさん
09/08/26 17:53:09
そういう環境なら例外に対応した方が結果的には楽になりそうだな
つーか例外無しでどうやってたんだそれ
590:デフォルトの名無しさん
09/08/26 17:54:24
ああ、newの戻り値いちいちチェックするだけか
で、STLとか使えない環境だぜ、ってなる訳ね、なるほど
591:デフォルトの名無しさん
09/08/28 01:55:25
「GSoCの学生には任せておけん」ってことになったかは知らないけど、
gcc cxx0x-lambdas-branchのメンテナが2人になったようだね。
新しくメンテナになったJason MerrillはC++標準化委員会のメンバーみたいだし、
lambdaが正式に実装される日もそこまでは遠くなさそうだ。
592:デフォルトの名無しさん
09/08/28 02:20:10
だといいがな…
ConceptGCCはもう捨てるのかな
593:デフォルトの名無しさん
09/08/28 03:05:49
>>592
URLﾘﾝｸ(gcc.gnu.org)
だとさ
URLﾘﾝｸ(wiki.apache.org)
見ていると、gccは細かい仕様の実装が早くて、ICC, VCは重要なもの優先、
そしてC++ Builderはマイペースな感じだな
594:デフォルトの名無しさん
09/08/28 17:53:07
>>584
STL じゃなければ、ありうる状況になるの？
元の議論をたどってみなよ。何の反論にもなってないと思うけど。
例えばSTLコンテナを使用禁止にしても、配列を std::sort() したり std::equal_range() したり
std::count_if() したりするためだけでも、十分 STL の恩恵があると思うよ。
C の標準関数の qsort() とか bsearch() とかの方が好み？
595:デフォルトの名無しさん
09/08/28 17:57:46
それそもそも反論なのか？
596:デフォルトの名無しさん
09/08/29 14:20:38
>>594
「よくわからないから」という理由でSTL禁止にしたウチのPMに言ってやってください
597:デフォルトの名無しさん
09/08/29 19:04:15
そういうのはマ板でやってよ…
598:デフォルトの名無しさん
09/08/29 20:25:54
STL禁止の所があるのかｗｗ
599:デフォルトの名無しさん
09/08/29 20:46:09
>>596
昔、若かったころはSTLでコンパイルエラーが出ても意味不明だったんだから許してあげてよ。
600:デフォルトの名無しさん
09/08/29 21:23:40
その後進歩してないってことだから許さない
601:デフォルトの名無しさん
09/08/29 22:28:22
>598
海外のソフトのカスタマイズではコーディング規約としてそういう縛りはふつうにあるよ
海外だと結構お年の人が現役でコード組んでるから、なるべくコードの意味が多重化する
機能を禁止する傾向がある
602:デフォルトの名無しさん
09/08/29 22:43:45
STLって使いやすいとは思わなかったから使ってなかったんだけど、boostと一緒に使うと驚くほど使いやすくなった。
BOOST_FOREACHとかiterator_adaptorとかiterator_rangeとかと組み合わせるとすごい強力で使いやすい。
STL使わなかった人もこれなら満足するんじゃないかな。
603:デフォルトの名無しさん
09/08/29 22:47:45
>>601
そうなんだ
車輪の再発明が好きなお年寄りが多いんだな
ご苦労なことだ
604:デフォルトの名無しさん
09/08/29 23:00:23
>603
それをカスタマイズする人たちが知る必要はないだけ
機能を提供する側はSTLをtypedefしているだけかもしれないよ
define が衝突するのでそれはないが
605:デフォルトの名無しさん
09/08/30 02:32:03
STLと例外がないC++なんて面倒くさくてやってられない
606:名無しさん＠そうだ選挙に行こう
09/08/30 03:41:46
Boostの無いC++も面倒くさくてやってられない
607:名無しさん＠そうだ選挙に行こう
09/08/30 05:19:31
C++03にすらついてきていない俗世の話はおいといて、スレに沿った話をしようぜ。
もっとも、Conceptが外れることが決まってC++0xは
ほとんど確定してしまったからあまりネタが無いと思うんで、
そろそろC++0xの次についてを話題にしても良いんじゃないかと思うね。
言語仕様はConceptは個別にTRとして世に出ることは無いとすっぽすっぽが言ってたから、
C++0xの次の標準まで待たなくてはならないことは確か。
わりと影響が大きそうなModules in C++(N2316)は個別TRを予定しているらしい。あとはGCがどうなるか。
ライブラリに関してはLibrary TR2として
URLﾘﾝｸ(www.open-std.org) の
"～ Accepted into TR2"と"～ Planned for a Future TR"
からは大きくは違わないものが入るのはほぼ間違いない。
"Papers With an Open Status"になってるものも、改良されて入ってくる可能性が高いね。
他に何に入ってほしい？
608:名無しさん＠そうだ選挙に行こう
09/08/30 06:11:47
N2316を見てみたが、Introduction読むだけで汁が漏れそうだ
609:名無しさん＠そうだ選挙に行こう
09/08/30 06:14:50
STL w
610:名無しさん＠そうだ選挙に行こう
09/08/30 06:20:34
>>607のリンクは正しくは
URLﾘﾝｸ(www.open-std.org)
だった
611:名無しさん＠そうだ選挙に行こう
09/08/30 11:42:40
じゃあGCの話でも
すっぽすっぽはD&EでC++にGCを入れるなら，入れるか入れないかのどちらかで，
入れたり入れなかったりする選択肢を作ることはありえないみたいなことを言っていたと思います
では入れるとして，問題になるのはGCが使えないような環境ですが，
今時GCが使えなくてC++を使っている環境ってありますかね？
あまり知りませんが，そういうところはいまだにあえてCを使っているということはないでしょうか
612:名無しさん＠そうだ選挙に行こう
09/08/30 12:00:20
>>611
そういう時のためのスマートポインタでありRAIIでありPimplイディオムなわけだが
613:名無しさん＠そうだ選挙に行こう
09/08/30 12:07:55
RAIIで固めまくっててリーク何それ状態なのに今更GCなんか来ても何も嬉しくないんだが…
614:名無しさん＠そうだ選挙に行こう
09/08/30 12:14:29
>>611
C++にはゼロオーバーヘッド原則あるから組み込みでも
Embedded C++みたいなサブセットじゃなくてC++使えば良いよ
ってことが書かれたのがPerformance TR。
だから、C++が今使われてない環境はあっても、使えない環境は事実上無い。
でも、GCはリアルタイム性の確保が不可能だからその手の環境じゃ
少なくともコーディング規約上禁止されるに違いないし、
GCについてもゼロオーバーヘッド原則は守られなければならない、ってところかな。
615:名無しさん＠そうだ選挙に行こう
09/08/30 13:24:18
GCか・・・昔は欲しかったけど今はどうでもいいな
616:名無しさん＠そうだ選挙に行こう
09/08/30 13:33:04
スマポが十分使えるからmark&sweep方式のGCとか使えるようになっても俺は使わないだろうなぁ
thisの参照を数えないから自分への最後の参照を切るような処理をするとsuicideしちゃう点だけ何か上手い方法あればなと思うくらい
617:名無しさん＠そうだ選挙に行こう
09/08/30 13:34:33
>thisの参照を数えないから
kwsk
618:名無しさん＠そうだ選挙に行こう
09/08/30 14:53:26
スマートポインタで十分だと思うし。スマートポインタでうまくいかない場合が思いつかない。
619:名無しさん＠そうだ選挙に行こう
09/08/30 15:12:47
循環参照の問題があるから所有権を明確に管理しないとまずいし。
イベントドリブンなコードをOOP的に書いてるとすぐ循環する。
620:名無しさん＠そうだ選挙に行こう
09/08/30 15:17:57
いやだからBoostのスマポは何種類かわざと用意されているわけで
621:名無しさん＠そうだ選挙に行こう
09/08/30 15:20:53
一方に、弱弱しいポインタを使えば解決。
622:名無しさん＠そうだ選挙に行こう
09/08/30 15:21:30
手段があればいいってもんでもなくて。
それを正しい知識を持った人が選択しないと有効に働かないってのがなぁ。
623:名無しさん＠そうだ選挙に行こう
09/08/30 15:23:00
ほとんどの循環参照は設計で解決できる。
それでも解決できないイベントハンドラのような循環参照を起こしやすいものはweak_ptrで解決できる
624:名無しさん＠そうだ選挙に行こう
09/08/30 15:32:23
スマポで必要十分なのは確かだけど古めのフレームワークで
RAIIに従ってないのがあるとすり併せに苦労するのが辛い
625:名無しさん＠そうだ選挙に行こう
09/08/30 15:41:21
>>622どんな道具も正しく使わないと効果を発揮しないものだ。
たとえGCがあっても不要なデリゲートやら参照やらをいつまでも保持していると
リソースの開放をしてくれない。
626:名無しさん＠そうだ選挙に行こう
09/08/30 17:04:57
Javaだって循環参照するとリークするからわざわざ参照を4種類も用意してる
GCは万能ではない
627:名無しさん＠そうだ選挙に行こう
09/08/30 18:01:48
>>626
＞Javaだって循環参照するとリークするから
それはない。
循環参照でリークするのはJava仕様違反。
628:名無しさん＠そうだ選挙に行こう
09/08/30 18:51:28
>>616
これでできないか？
class A :public boost::enable_shread_from_this<A>
{
public:
void hoge()
{
shared_ptr<A> my=this->shared_from_this();
}
};
629:名無しさん＠そうだ選挙に行こう
09/08/30 18:57:26
>>611
ゲーム屋や組み込み系のこともたまには思い出してあげてください
例外やRTTI無しがデフォっす
630:名無しさん＠そうだ選挙に行こう
09/08/30 18:57:52
まぁでも、C++に標準的にGCが導入されたら世の中のメモリリークがある程度減る
という想像は付く（問題が先送りされただけって考え方もあるが）
逆に、リークさせてはStop the world、なアプリが無駄に増えそうな気もするが…
どっちがいいんだろうなぁ
ゼロオーバーヘッドが守られるならどうでもいい、ってのはある
631:名無しさん＠そうだ選挙に行こう
09/08/30 19:09:35
リークがなくなるといっても、わざとリークさせてGCが回収するってことだから設計がいい加減なソフトが蔓延しそうな気がして怖い。
632:名無しさん＠そうだ選挙に行こう
09/08/30 19:13:42
scope_exitも言語仕様でサポートしてくれ
633:名無しさん＠そうだ選挙に行こう
09/08/30 19:16:22
Perlのループラベル構文もパクってくれ
634:名無しさん＠そうだ選挙に行こう
09/08/30 19:52:57
>>632
shared_ptrのカスタムデリータにlamda関数をセット
635:名無しさん＠そうだ選挙に行こう
09/08/30 20:08:46
lambda
636:デフォルトの名無しさん
09/08/30 21:43:09
そういうのになると多分適当な連中は手抜きして使わないんだよなぁ…
というか、たまには綺麗に書ける為だけの追加があってもいいと思うんだ
637:デフォルトの名無しさん
09/08/30 21:47:19
ライブラリでできることはライブラリでって方針なんじゃ？
638:デフォルトの名無しさん
09/08/30 22:36:31
scope_exitはマクロで制約付きだからなぁ
制約付きのマクロでいいなら、新しいfor構文も要らないことになるし
639:デフォルトの名無しさん
09/08/31 16:35:45
finally入れろって？
640:デフォルトの名無しさん
09/08/31 16:52:31
VCはfinally入るっぽいんだっけか
641:デフォルトの名無しさん
09/08/31 18:43:05
>>633
賛成！
それがあったら、gotoを使わなくても
よくなるのに。
642:デフォルトの名無しさん
09/08/31 19:21:35
finallyじゃなくscope(exit)の方がいいなぁ
つーかfinallyだったら別にイラネ
643:デフォルトの名無しさん
09/08/31 19:34:17
イディオムで何とかなればいい、使える奴が使えればいい、ってのに慣れすぎてる
ところはあると思う
爺さんもある程度の危惧はあるみたいだが…
644:デフォルトの名無しさん
09/08/31 20:05:08
auto h = shared_new Hoge;
でshared_ptr<Hoge>が帰ってくるようにならねえかなあ
645:デフォルトの名無しさん
09/08/31 20:18:00
>>644できるよ！
auto h=boost::make_shared<Hoge>();
646:デフォルトの名無しさん
09/08/31 20:45:59
可能な限りライブラリ主義は問題ない。
ソースの先頭に #include <...> が十数行必要になること以外は。
647:デフォルトの名無しさん
09/08/31 20:47:43
#include "all.h"
648:デフォルトの名無しさん
09/08/31 20:51:55
使用頻度が高いものはプリコンパイルヘッダーに入れちゃうけどね。
boostのヘッダーなんか一箇所でも使う箇所があったらプリコンパイルヘッダーに入れてる。
649:デフォルトの名無しさん
09/08/31 21:11:01
pchを使わない生活には戻れないなぁ
VC++のは癖ありすぎだけど
Boostで提供してるマクロは、つまりは言語サポートが不足してる部分だと思ってる
FOREACHもSCOPE_EXITもSTATIC_ASSERTもそうだし、そもそもPP系が全部そう
まぁPP系は最終手段として必要だろうけどな…
650:デフォルトの名無しさん
09/08/31 21:20:15
プリプロセッサがもっと強力になればいいんだな
そうだPHP埋め込めば(ry
651:デフォルトの名無しさん
09/08/31 21:46:53
#define BOOST_FOREACH foreach
とすれば組み込み機能かと錯覚しちゃうぐらいだよ
652:デフォルトの名無しさん
09/08/31 21:52:49
錯覚できるくらい完全なら幸せなんだろうけどなぁ
653:デフォルトの名無しさん
09/08/31 22:20:36
安心しろ、C++0xでは本物のforeachが言語組み込みになる！
はずだったじゃないか、なあ
654:デフォルトの名無しさん
09/08/31 22:27:15
本来、Range-based for はconceptを前提にして設計されていたからな。
それをADLなんていう、根本的に邪悪な機能で実装しようとしたら、
悲惨なことになるのは当たり前だろ。
ほんとにどうするんだろ、n2930。
655:デフォルトの名無しさん
09/08/31 22:35:16
差し当たりダサい実装になるのは仕方ないけど
後で新生concept版に置き換えるときに邪魔になってグダグダになるのが一番怖い
656:デフォルトの名無しさん
09/08/31 22:46:15
すっぽすっぽおじさんはちゃんと>>646-648のことも考えてくれているんだよ
URLﾘﾝｸ(www.open-std.org)
657:デフォルトの名無しさん
09/08/31 22:47:02
>>651
それ#define間違ってね？
658:デフォルトの名無しさん
09/08/31 23:10:44
#define BOOST_CONSTEXPR constexpr
#define BOOST_DECLTYPE decltype
#define BOOST_NULLPTR nullptr
#define BOOST_LAMBDA []
#define BOOST_AUTO(v,e) auto v = e
#define BOOST_ENUM_CLASS enum class
659:デフォルトの名無しさん
09/09/01 00:03:35
しかしさ。n2930だと、begin(), end()は、stdをassociated namespaceに付け加えたADLによって探されると規定されているんだよね。
つまり、通常のunqualified lookupは実行されない。
問題ありすぎるよな。
自作のクラスで、イテレーターを返すメンバ関数のシグネチャがbegin(), end()じゃなかったりする場合に、
自作クラスをRange-based forで使えるようにするには、ADLが何かということを理解していなければならない。
例えば、ある名前の名前空間に入っている自作クラスをRange-based forに対応させるためのbegin(), end()を、
グローバル名前空間に書いても、Range-based forは動かない。
なぜなら、通常のunqualified lookupは実行されないから。
テンプレート引数の型の名前空間もassociated namespaceになるので、
ある名前空間でテンプレートクラスとbegin()/end()を定義して、
別の名前空間の型をクラスのテンプレート引数に渡したとき、
たまたまシグネチャが一致するbegin()/end()が、別の名前空間にあっただけで、曖昧でエラーになる。
Joe coderにADLの理解を強要するのか？
660:デフォルトの名無しさん
09/09/01 00:14:40
ADLを理解していないレベルのJoe coderは自作クラスを
Range-based forに対応させようと思うどころか、
対応させることが出来るとも思わないんじゃないか、という疑問
661:デフォルトの名無しさん
09/09/01 07:34:52
ライブラリだけで使っていれば良いんだよ
662:デフォルトの名無しさん
09/09/01 12:27:36
使わね～
663:デフォルトの名無しさん
09/09/03 09:37:36
不定値を表すリテラルとか欲しいなぁ
664:デフォルトの名無しさん
09/09/03 09:40:00
>>663 何に使えるの？
665:デフォルトの名無しさん
09/09/03 10:25:52
不定値で済ませれば最適化が掛けられる場所もあるなぁと
まぁ例えば、API関数にダミー突っ込む時とか？
666:デフォルトの名無しさん
09/09/03 10:32:30
>>665
それだけじゃ良く分からん。具体例を示して
667:デフォルトの名無しさん
09/09/03 10:54:14
>>665
具体的に！
668:デフォルトの名無しさん
09/09/03 10:54:41
sub sp, 16
とか
dw ?
とかに相当する操作が欲しいってだけで、使い道も効果も微妙だから総合的には微妙
ただ「アセンブラならここは不定値だよなぁ」って思う時がたまにあるから思い出しただけ
669:デフォルトの名無しさん
09/09/03 10:56:35
と書いてて思ったけど
dw ?
は多分普通に初期化しない静的変数として書いてるな
670:デフォルトの名無しさん
09/09/03 11:00:02
と書いてて思ったけど（連投ですまんが）、結局関数の引数以外は不定値普通に書けるな
int dummy;
f(dummy,dummy,dummy,dummy);
がpush四回になるかsub sp,16になるかはコンパイラ次第か。別に不定値要らないな。
671:デフォルトの名無しさん
09/09/03 12:08:54
>>670
COMとかのoutみたいなもんか。
672:デフォルトの名無しさん
09/09/03 12:25:28
いや、COMのoutはちゃんと0入れないとやばくね
673:デフォルトの名無しさん
09/09/03 17:00:37
includeを打ち消すdecludeみたいなのが欲しいなぁ。
undefみたいなノリで
674:デフォルトの名無しさん
09/09/03 18:19:36
推薦図書スレに誤爆した奴がいるらしい
675:デフォルトの名無しさん
09/09/03 19:10:41
>>673
一体どういう挙動するんだそれ…
676:デフォルトの名無しさん
09/09/03 19:17:14
includeで読み込んだh内のclassとかdefineとか変数とか一切合財
decludeで無かったことになる、と。
include <hoge.h>
～ hoge.h で記述されてるものを使ったコード ～
declude <hoge.h>
ここから無効
pimplしなくてもhを軽くできて良いんじゃないかなぁと。
激しく実装するのが面倒そうだが
677:デフォルトの名無しさん
09/09/03 19:18:34
>>676
> pimplしなくてもhを軽くできて良いんじゃないかなぁと。
お前勉強し直しな。
678:デフォルトの名無しさん
09/09/03 19:22:49
>>677
勉強すればheaderのチェーンを断ち切る目的でpimpl使おうと思わなくなれるんですか？
679:デフォルトの名無しさん
09/09/03 20:20:09
> hが軽くできて
kwsk
680:デフォルトの名無しさん
09/09/03 20:25:07
>>679
簡単にｴｯﾁできるって意味では無いと思うぞ
681:デフォルトの名無しさん
09/09/03 20:54:45
>>676
結局ヘッダ読み込んでコンパイルしてる上に、 declude の処理が増えてるじゃん。
ヘッダが「軽く」なるように感じる要素がまるで無い。
682:デフォルトの名無しさん
09/09/03 21:09:30
せめてexcludeとかにしてくれ・・
683:デフォルトの名無しさん
09/09/03 21:21:29
make 使わなくても済む様に C++ で規格化してくれりゃIDE毎の違いやら鈍足 template が一気に解決するのにね
684:デフォルトの名無しさん
09/09/03 21:26:30
pascalのようにuses で自動的にコンパイル＆リンクまでしてくれるとありがたいのに。
685:デフォルトの名無しさん
09/09/03 21:46:09
PGOみたいな最適化の邪魔になるような気がする
686:デフォルトの名無しさん
09/09/03 22:11:25
includeの話をしてる奴らはとりあえずModules in C++も一応嫁
687:デフォルトの名無しさん
09/09/03 22:14:01
>>683
何を言っているのだ、お前は？
688:デフォルトの名無しさん
09/09/04 00:14:45
>>681
ヘッダの連鎖コンパイルは減るじゃん
689:デフォルトの名無しさん
09/09/04 00:36:58
何で減るんだ？
690:デフォルトの名無しさん
09/09/04 00:38:36
そもそもヘッダの連鎖だかチェーンだかとやらが意味不明なんだけど、何のことを
指してるんだ？
691:デフォルトの名無しさん
09/09/04 06:48:08
減らないし、g++もVC++もpre-compiled headerあるし、
>>676って、下手な考え休むに似たり、ってことでしかない。
692:デフォルトの名無しさん
09/09/04 07:49:38
pimplならローカルなクラスの宣言は .cpp のほうに書けばいいんでないの
693:デフォルトの名無しさん
09/09/04 07:51:03
すまん、692は忘れてくれ
694:デフォルトの名無しさん
09/09/04 08:11:15
VC++のpchはそろそろ改善して欲しいけどな
まぁ2010の次のバージョンが全面改修らしいから、あるとしても遠い話か
しかし、>>676は明らかに何かを誤解してると思うんだが、どう誤解してるのかが
気になるなぁ
695:デフォルトの名無しさん
09/09/04 11:22:49
>>694
勘違いというか、あれで内部的にpimpl相当になって外部のクラスを
変更しても影響受けない素敵状態になってくれないかなぁという妄想みたいな。
誰か書いてたけどexcludeとか、class_ｅｘｔｅｒｎ見たいな方が適切だったと思う。
696:デフォルトの名無しさん
09/09/04 11:43:44
外部のクラスってのが何を指してるのか分からんし、どう見てもpimplを何か変に
誤解してるようにしか見えないが…
クラスのサイズが分からないとインスタンスは生成できない
→privateメンバ変数すら全てヘッダ中で定義しなきゃならない
→ポインタの向こうの構造体にメンバ変数を全部隠せばいい
ってだけの話だぞpimplは。
もっと綺麗に分離する為に、普通はポインタの向こうに不完全型の実装クラスを
置いて、中身全部そっちに移して転送関数を書きまくる訳だけど。
697:デフォルトの名無しさん
09/09/04 12:59:12
>>695は今すぐExceptional C++を穴が空くほど読むべき
698:デフォルトの名無しさん
09/09/04 13:10:16
pimplしたくないからprivateメンバをヘッダ以外に追い出せる別な方法が欲しいって話なんだけどなぁ。
699:デフォルトの名無しさん
09/09/04 13:15:19
>>698
別の方法と言うなら、空のインターフェースクラスと実装クラスに分ける方法があるじゃないか。
700:デフォルトの名無しさん
09/09/04 13:28:30
>>698
>>673>>676は追い出せてないじゃんw
701:デフォルトの名無しさん
09/09/04 13:31:36
ヘッダの問題はModules in C++がTRとして出て解決する予定になっている。
だから、同じ問題を解決するものは
意味論的にModuleより優れていない限り、考慮する価値も無い。
よってこのネタは終了。
702:デフォルトの名無しさん
09/09/04 13:51:16
>>673>>676で追い出せると思ってる理由が分からんｗ
703:デフォルトの名無しさん
09/09/04 14:04:05
>>702
いや、技術的にこれで追い出せる～みたいな話じゃなく、
こんな書き方で追い出せるようにならないかなって妄想でｗ
704:デフォルトの名無しさん
09/09/04 14:04:56
>>701
ヘッダ問題解決する予定があるなら、本当にどうでもいい話でした
705:デフォルトの名無しさん
09/09/04 14:34:43
クラスを丸ごとpimpl化するのは面倒なので、クラス内に包含する一部のオブジェクトのメンバ変数をshared_ptr<>にしてる。
そうすれば一部だけでもヘッダーをcppに移せるからそこそこ効果がある。
706:デフォルトの名無しさん
09/09/04 14:37:26
>>705 は中途半端。
対処としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。
ｽﾚﾘﾝｸ(tech板:182番)
これ思い出した。
707:デフォルトの名無しさん
09/09/04 14:48:47
>>705
pimplじゃん
708:デフォルトの名無しさん
09/09/04 14:55:31
やけくそ頻繁に参照されるメンバがあって、そこだけpimplから外に出したりすることはある
709:デフォルトの名無しさん
09/09/04 14:59:32
>>707うん、メンバすべて丸ごとじゃなくて一部のメンバにpimpを適用。
すべてのメンバ関数で間接呼び出しさせる必要がない。.演算子を->にするだけでいい。
>>706中途半端なのはそうだけど、手間と効果の兼ね合いかな。
710:デフォルトの名無しさん
09/09/04 15:08:23
初心者スレかよ。
711:デフォルトの名無しさん
09/09/04 15:42:25
>>673から一気にアホな流れになったな
712:デフォルトの名無しさん
09/09/04 16:02:28
汚染してしまってすまん
713:デフォルトの名無しさん
09/09/04 16:06:46
これでもまだマシ、っていうのが世間におけるC++のレベルなんだろうな。
C++0xの言語側の実装状況は
URLﾘﾝｸ(wiki.apache.org)
みたいの見ればすぐ分かるし、ネタにもよくあがるけど、
ライブラリの方はどの程度ついてきているのだろう。
URLﾘﾝｸ(gcc.gnu.org)
見ると、constexprが無いのが結構響いてるっぽいなあ。
右辺値参照(というかMove Semantics)のライブラリ側の対応も大体済んだみたいだし、
そろそろ実用面でのベンチマークを見てみたいね。
714:デフォルトの名無しさん
09/09/04 16:24:24
URLﾘﾝｸ(gcc.gnu.org)
によると、constexprの実装はGCC-4.5で入るのかな？
715:デフォルトの名無しさん
09/09/04 16:24:32
ベンチマーク必要な変更はない。
716:デフォルトの名無しさん
09/09/04 16:45:04
必要か不要かじゃなくてどの程度かを知りたいって話だろ・・・
717:デフォルトの名無しさん
09/09/04 17:22:30
標準コンテナをvalue semanticsで使っているようなプログラムは
g++のコンパイラオプションに-std=c++0xを入れるだけでかなり早くなるかもしらんが、
そんなプログラムはあまり無いだろうなあ。
使っているとしてもstd::stringくらいか。
718:デフォルトの名無しさん
09/09/04 17:50:15
コンテナにshared_ptrを突っ込んで使ってる人は自動的に速くなるだろうな。
アトミックオペレーションのコストって高いからなあ
719:デフォルトの名無しさん
09/09/04 18:28:50
constexprて実装側で無く利用側で指定するようには出来なかったのかね
720:デフォルトの名無しさん
09/09/04 18:33:54
>>719
例えばどんなメリットがあるん？
721:デフォルトの名無しさん
09/09/04 19:05:21
デメリットや実装難度を見たいって話なんだから
メリットが判らん様な低脳は黙ってればいいと思うよ
722:デフォルトの名無しさん
09/09/04 19:22:34
decludeと同じく何を意図しているのか分からんが、
案を出すなら構文と意味論の例を提示しろと。
定義は1回なのに対し、利用するところは無数にある。
その全ての箇所で指定するなんて、現実的じゃない。
明らかに、定義時に指定する方が合理的。
指定しないでもコンパイラがコンパイル時に判断すれば良いって？
D使えば良いんじゃない？
723:デフォルトの名無しさん
09/09/04 19:39:06
>>719利用者側で指定するとはどういう意味かわからん
実装時にconstexprによってコンパイル時の評価が可能で且つ同じ引数に対して同じ定数が戻ることが
保証できるわけだろ。それで十分だと思われる。
724:デフォルトの名無しさん
09/09/04 19:50:39
>>708
よけくそ頻繁ってどこの方言？
純粋に興味で知りたい
725:デフォルトの名無しさん
09/09/04 19:56:32
やけくそ と書いたところで頻繁の方が良いカナと思ったが、
どっちが良いかは全文を書いてから決めることにして、取り合えず
両方残したままにしたのが裏目にでて、消すのを忘れてたと読む。
726:デフォルトの名無しさん
09/09/04 19:59:39
>>721
態度は悪いが良い指針
で、メリット何？
727:デフォルトの名無しさん
09/09/04 20:06:55
constexprはコンパイル時定数として自然に使えることを目的としているんだから、
使用時に何か指定が要るっていう時点で問題外だろ……
「ぼくのかんがえたC++0xはスレ違い」の文言をテンプレに追加するべきだ
あと、「papers嫁」もだな
728:デフォルトの名無しさん
09/09/04 21:27:25
URLﾘﾝｸ(d.hatena.ne.jp)
> この点をふまえて考えると、 std::list::size() でリンクをたどって
> 数える処理は「コンテナ内のオブジェクトに対する操作」ではないので、
> 計算量の要件が仮に定数時間とされても、実装を変更する必要は無いと
> 言えてしまいそうだったりします。
これ、どうなの？
これがほんとなら N2923 をまじめに考えてた委員会の人とかみんな
この点を見落としてるってこと？
729:デフォルトの名無しさん
09/09/04 21:29:43
>>697
そんな本読む必要なし。
だから、その手の本を日本人がかけないんだよ。
730:デフォルトの名無しさん
09/09/04 21:42:29
>>728 emptyが有れば十分たい
731:デフォルトの名無しさん
09/09/04 21:44:46
連結リストに対してsize()なんかが必要になる時点で設計おかしいよな
732:デフォルトの名無しさん
09/09/04 21:48:17
えー誰得？
733:デフォルトの名無しさん
09/09/04 21:50:48
>>731
それを断言できるスキルがうらやましいです＾＾；；
もっと精進せねば＾＾
734:デフォルトの名無しさん
09/09/04 22:17:56
>>728
そのコメントは嘘。
URLﾘﾝｸ(gcc.gnu.org)
で問題にしているのはamortized constant timeかconstant timeかの違い。
GCCでの実装がamortized constant timeなのにStandardではconstant timeと
書いてあるから、これはGCCのバグだよね、と言うのが論旨。
結局、Standardで
URLﾘﾝｸ(anubis.dkuug.dk)
と修正されているので、amortized constant time操作であるstd::deque::push_back()
はStandard通りの振る舞いということ。
735:デフォルトの名無しさん
09/09/04 22:36:49
>>734
その解釈には無理が無いか？
もしそのとおりであれば、 gcc のバグ報告に対して 23.1/2 をあげる必要が
無かったはず。
それに、 defect 139 を挙げてるのは、報告者が vector の push_back に
言及してたからでしょ。 deque の push_back については最新のドラフトでも
constant time が要求されてるよ。
736:デフォルトの名無しさん
09/09/04 22:59:02
>>735
無い。無理があるのは
You are talking about complexity in terms of the number of operations
performed on pointers to the contained objects.
の方だと思うぞ。そもそも、Standardでは
23.1.1
All of the complexity requirements in this Clause are stated solely in terms
of the number of operations on the contained objects. [ Example: the copy
constructor of type vector <vector<int> > has linear complexity, even though
the complexity of copying each contained vector<int> is itself linear. end
example ]
とわざわざ例を挙げて言っているように、ポインタ経由でアクセスしているか否かを
問題にしているわけではない。
最新のドラフトでは確かに"should have constant complexity"と書いてあるが、
そもそもDefect 139は "Status: TC Submitter: Andrew Koenig Date: 30 Mar 1999"
とあるように、確実に当時のStandardに反映されている。その後complexityに対する
委員会の見解が変わったか、エンバグしたかのどちらかだろう。
737:デフォルトの名無しさん
09/09/04 23:16:42
>>736
誰もポインタ経由でアクセスしているか否かなんて問題にしてないよ。
問題なのはコンテナ内の要素に対する操作か否か。
list の size で要素を数え上げる処理は明らかに違うでしょ。
あと、 deque の push_back の要件は defect 139 で修正された
Optional sequence operations じゃなくて、 23.2.1.3 [lib.deque.modifiers] に
別途記載されている。最新のドラフトだと 23.3.2.3 ね。
> Inserting a single element either at the beginning or end of a deque always
> takes constant time and causes a single call to a constructor of T.
やっぱりおかしいよ。
738:デフォルトの名無しさん
09/09/04 23:31:13
>>736
"should have constant complexity" って、どこ見てるの？
defect 139 で修正された Optional sequence operations についての記述では
2003 の時点でも最新のドラフトでも
"shall implement them so as to take amortized constant time" って書いてあるよ。
まぁ、もう元の話とは関係ないんだけどね。
739:デフォルトの名無しさん
09/09/05 00:38:32
>>737
そもそもGCCのバグ報告を持ち出したのは、ポインタ経由での要素へのアクセスは
オブジェクトへのアクセスでは無いからcomplexityに影響しないということだと
思うが。
> 問題なのはコンテナ内の要素に対する操作か否か。
> list の size で要素を数え上げる処理は明らかに違うでしょ。
その認識が合っているとは思えない。list::reverse()のcomplexityはlinear time
だとStandardにあるが、これはlist::size()同様にリンクポインタをいじることで
実現可能。もしリストのリンクを辿ることが"operations on the contained objects"
でないのなら、list::reverse()のcomplexityも当然constant timeと書くと思うが。
こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
誤解をしているとも思えない。
740:デフォルトの名無しさん
09/09/05 00:46:04
>>738
> "should have constant complexity" って、どこ見てるの？
これは間違いだった。General container requirementsのsize()について見ていた。
> defect 139 で修正された Optional sequence operations についての記述では
> 2003 の時点でも最新のドラフトでも
> "shall implement them so as to take amortized constant time" って書いてあるよ
見落としていたが、確認した。
741:デフォルトの名無しさん
09/09/05 00:57:07
>>739
gcc のバグ報告ちゃんと読んでる？
ポインタ経由での要素へのアクセスなんてどこにもでてきてないはずなんだけど。
問題になってるのは deque 内に持ってるポインタ配列の再確保とコピーね。
> こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
> 誤解をしているとも思えない。
みんなそう思ってるんだけど、事実は矛盾が発生しているようだという話ね。
list のリンク操作は "operations on the contained objects" であって
deque のポインタ配列操作はそうではない、というのはおかしい。
元々の意図はそうなんだろうとは思うけど、それが 23.1/2 の記述が甘いせいで
おかしくなっている、と。
742:デフォルトの名無しさん
09/09/05 01:09:31
>>741
正しくはポインタへのアクセスだったな。まあそのくらい補完してくれよ。
で、お前さんの立場は何なの？
list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
書くべきだという意見？
自分は、こんな大事に気づかずに放置するわけが無くて、deque::push_back()の
complexityをamortized O(1)と書くべきという意見。
amortized complexityを良く理解していない人は結構多い上に、defect 139に
あるように実際同様のバグがあったこと、こちらの方が可能性が高いと考える。
743:デフォルトの名無しさん
09/09/05 01:09:40
調べてみると、こんなのが出てきた。
URLﾘﾝｸ(www.open-std.org)
ここの Issue Number 20-036 で問題の 23.1 p2 の追加が行われている。
これが "10 July 1996" とあるので、おそらく list の計算量要求なんかはそれ以前から
あったもので、操作全体の時間について言っていたのがそのままになってる可能性が高い。
N2923 も含めて、 list のリンク操作はあきらかに計算量に含まれる想定で書かれている
ので、 23.1 p2 の文面を現状に合うように修正するべきなんじゃないかと思う。
そうすると、 deque の push_back に対する要求は amortized constant に合わせて修正
しないといけなくなりそう。ただし、これは制限を緩めるものなので、現状の実装を変更する
必要は生じないはず。
744:デフォルトの名無しさん
09/09/05 01:29:39
>>742
> で、お前さんの立場は何なの？
> list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
> 書くべきだという意見？
そうするか、 >>743 のとおり 23.1/2 のほうを直すか、とにかく矛盾を直すべき
だとは思う。
>>743 のほうが自然だし、楽だね。
745:デフォルトの名無しさん
09/09/05 01:32:24
>>743
なるほど。確かにそういう事になるだろうな。そうすれば>>728や>>735>>737
のようなおかしな解釈をする輩がいなくなる。
そもそもコンテナ内の要素数に依存するような操作をしているのにポインタへの
アクセスは関係ない、なんて言い出したらcomplexityを明示することが無意味に
なってしまう。
746:デフォルトの名無しさん
09/09/05 02:15:43
どちらかというと「標準委員会が矛盾に気づかないわけがない」なんて
思い込んでるほうがおかしいだろ。
747:デフォルトの名無しさん
09/09/05 02:48:46
>>746
見苦しいぞ
748:746
09/09/05 03:01:16
へ？なんで？意味がわからない。
749:デフォルトの名無しさん
09/09/05 09:28:43
>>746
おまいは>>728から100回読み直してこい
750:デフォルトの名無しさん
09/09/05 13:05:38
どっちがおかしいよかよくわかってない美少女中学生もお忘れなく
751:デフォルトの名無しさん
09/09/05 15:48:55
規格の文面をまじめに読むと、どっちの解釈が「おかしい」とも言い切れない状態に
なってるのが問題。
752:デフォルトの名無しさん
09/09/05 15:56:27
ここでいう「どっち」は >>728 と >>743 の２つね。（ >>745-746 は敢えてスルー）
728 は deque::push_back の（計算量）要求は正しくて list::size() の要求は無意味。
743 は list::size() の要求には意味があって deque::push_back の要求は間違ってる。
753:デフォルトの名無しさん
09/09/06 12:29:21
23.1.1 の記述を問題にしてる人は、具体的にどう直せば厳密になると思う？
俺はまともに書き下せる気がしないので、
「今の文面を、常識的に考えて意図したいであろう意味と解釈して読め」
が現実的だと思うんだけど。
754:デフォルトの名無しさん
09/09/06 13:04:37
計算量とか「実装の質」で切り捨てたらあかんの？
なんか言語の規格で決める事じゃないような気がする
755:デフォルトの名無しさん
09/09/06 13:13:12
>>754
それはさすがに認識のレベルが出発点にすら立ってない