C++0x 6 - 暇つぶし2ch

C++0x 6 ..

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に移せるからそこそこ効果がある。

次ページ