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

C++0x 3 ..

666:デフォルトの名無しさん
08/05/24 16:46:20
無名にしなくても、boostの
namespace detail {
はそういうことやってるんだわな。
>>663はスロット単位でやりたいんだろうけど。

667:デフォルトの名無しさん
08/05/24 17:02:23
>>654
「自尊心はあっても自信が無い」から、衝動で突っ込むけど説明添える勇気は無いんですね、わかります。

668:デフォルトの名無しさん
08/05/24 17:51:48
整数のイタレータのサンプルコード見ればいいんじゃない？ > concept_map

669:デフォルトの名無しさん
08/05/24 18:01:51
autoとcenceptでC++も分かりやすい言語になるかなあ。

670:デフォルトの名無しさん
08/05/24 18:04:22
ならんね

671:デフォルトの名無しさん
08/05/24 18:13:27
そもそも、現行C++も分かりやすい言語にするために
突っ走ってきたという面が多かったと思う、D&E読んだ直後の感想。

しかし、現実はと言うと……。
0xも同じ道を辿るに違いない。

672:デフォルトの名無しさん
08/05/24 18:17:27
>>671
> 分かりやすい言語にするために

皮肉とかじゃなく、そうは思えません。
やはりCとの互換性を抑えた上での、実行効率をメインに考えてきたと思います。

673:デフォルトの名無しさん
08/05/24 18:21:59
>>665
ｋｗｓｋ

674:デフォルトの名無しさん
08/05/24 18:42:42
Perl6 の二の舞になる、なんてことはないよな。あはは

675:デフォルトの名無しさん
08/05/24 18:42:58
>>673
やっぱ出来ねえや
勘違い

676:デフォルトの名無しさん
08/05/24 20:09:08
最近は使う人にやさしくなってきてるよね

つらいのはコンパイラベンダやライブラリベンダ

677:デフォルトの名無しさん
08/05/24 20:21:53
ここまで巨大仕様になるともう新規参入とか不可能だよな

678:デフォルトの名無しさん
08/05/27 08:48:19
GCCからforkすればいい。

679:デフォルトの名無しさん
08/05/27 16:55:43
現行の auto って型名のかわりに
auto i = v.begin();
みたいな書き方をする以外に使い方ありますか？

680:デフォルトの名無しさん
08/05/27 19:07:49
型名の現れうる場所全てに現れて
福音と混沌をもたらします

681:デフォルトの名無しさん
08/05/27 20:05:28
>648

682:デフォルトの名無しさん
08/05/27 20:13:09
自動変数の宣言

683:デフォルトの名無しさん
08/05/27 20:13:47
使うだけの人間としては規格の議論より処理系がいつできるかの方に興味がある

684:デフォルトの名無しさん
08/05/27 21:57:30
規格書いてる奴らが作る訳じゃないからな
2020 ぐらいじゃね？

685:デフォルトの名無しさん
08/05/28 09:04:38
だが実装可能性ぐらいは考えて欲しいんだぜ。

686:デフォルトの名無しさん
08/05/28 15:41:55
もう委員会が「完全準拠のコンパイラを最初に作ったチームに賞金」でいいだろ。
商用コンパイラとかだとその賞金が売り上げを下回るっていう可能性もあるから、
MSの無償配布してるものと同じ様なライセンスでなければいけないとかいう条件をつけてさ。
そうすれば販売方法を確立できない個人でも目指す事ができるし、万が一先を越されてしまっても
その場合は販売すれば良い。

687:デフォルトの名無しさん
08/05/28 15:53:55
C++03の下位互換性から考えると、exportも必須なわけか？
そんな非現実的で理想を追求した完全準拠のコンパイラは、まず実用にはならないと思われる。

688:デフォルトの名無しさん
08/05/28 18:07:34
外部テンプレートなんかさっさと規格からぶち殺して
貴重な予約語exportをもっと他の有意義なことに使えるように努力すべき

689:デフォルトの名無しさん
08/05/28 19:47:46
>>686
個人でやれるような範囲の話ではない

690:デフォルトの名無しさん
08/05/28 20:16:07
MSがバイナリインデックスの並び順で特許取っててそこをCOMに使ってるから無理
テーブルを先頭に持ってくるんだったか程度のもの

691:デフォルトの名無しさん
08/05/28 20:22:03
特許なんてそのうち切れるさ

692:デフォルトの名無しさん
08/05/28 22:23:11
vtblを頭に持ってくるって話？
ABIだと思ってたが、特許なのか？

693:デフォルトの名無しさん
08/05/28 23:46:26
>>684
Conceptは、Douglas Gregorが規格も処理系(ConceptGCC)も書いてるよー。

694:デフォルトの名無しさん
08/05/29 00:25:18
そのGCCではあのクソ気持ち悪いラムダ式とかもコンパイルできるのかい
だったらちょっと試してみたい

695:デフォルトの名無しさん
08/05/29 06:43:01
これはconcept branchだから、
他の新標準機能は入ってないよ。
URLﾘﾝｸ(gcc.gnu.org)
lambdaはgcc headで実装始まってるはず。

696:デフォルトの名無しさん
08/05/29 08:49:35
>>686
2100頃までC++は生き残るわけですね分かります

697:デフォルトの名無しさん
08/05/29 11:46:02
std::*Integralが、
std::*IntegralLikeになってやがる。
FloatingPointLikeってなんだよ
// Revision 1の頃から変わっていたのか

698:デフォルトの名無しさん
08/06/04 13:39:48
C++0xはそろそろJavaの時のような誇大広告を始めて盛り上げるべき。

699:デフォルトの名無しさん
08/06/04 13:52:25
どんだけ人集めてもmove semantics見たらみんな引くって。
大衆には見向きもせずプログラミング言語の実験室として頑張っていただきたい。

700:デフォルトの名無しさん
08/06/04 14:03:10
もはや C++ 自体が大衆向けじゃないよな。
でも、必要としている一部の人間のために頑張って頂きたい。ｗ

701:デフォルトの名無しさん
08/06/04 14:05:12
まずはまともな処理系を、話はそれからだ

702:デフォルトの名無しさん
08/06/04 14:11:26
Move SemanticsとかVariable TemplateとかConceptとか、
ライブラリを書く奴のための機能だから、
一般ピーポーが覚える必要は無いんじゃない？

とは言ったものの、どうやって実装しているか分からないと、
俺としては、使う気にならなかったりするから微妙だ。

STLヤベー、超便利ー。
↓
イテレータとか関数オブジェクトとか分からん。勉強するか。
↓
いわゆる、STLの解説本とかではまともに説明されてねー。何コレ。
↓
テンプレート解説本なら詳しく載ってる。やっべ、スゲー詳しい。面白れー。
↓
Boostたのしー。
↓
あれ、当初の目的って何だっけ？
STL？　デザインが貧弱すぎじゃね？　あれって。

703:デフォルトの名無しさん
08/06/04 16:25:03
素人の人たちに受けのいい機能も少し追加されたんじゃない。
auto とか。

704:デフォルトの名無しさん
08/06/04 16:26:10
conceptだってコンパイル・エラー見やすくなるしね。

705:デフォルトの名無しさん
08/06/05 04:01:49
今回は入門者のためにもなる改良がたくさんあるとどこかで聞きました

706:デフォルトの名無しさん
08/06/05 14:58:46
c++であと１０年は持つのかな
すでにフォートラン化しはじめてる？

707:デフォルトの名無しさん
08/06/05 16:44:53
当分、いろんな意味でC++を越える言語は出てこないだろうな。

708:デフォルトの名無しさん
08/06/05 20:08:45
export イラネ
予約語から外してほしい

709:デフォルトの名無しさん
08/06/05 20:23:20
export の実装って結局二度以上同じソースをコンパイルしてるだけだからな
prelink 工程というのがあってそこで全部解決するまで再帰的にコンパイルしつづける

関数がインラインにならないという効果はあるがそれ以上の利益はない気がする

710:デフォルトの名無しさん
08/06/05 21:53:24
>>706
FORTRAN 77とは全然違う。
FORTRAN 77は数値計算の世界では現役のまま陳腐化した。
C++0xは現役のまま最先端を走り続け、プログラマを置き去りにし続けてる。

711:デフォルトの名無しさん
08/06/05 21:55:37
置き去りかよｗ

712:デフォルトの名無しさん
08/06/05 22:04:19
道を踏み誤りつつあるマッドサイエンティストみたいなもんだな

713:デフォルトの名無しさん
08/06/05 22:04:26
exportは後々autoみたいに役に立つ日がくるのでほっといてやってください

714:デフォルトの名無しさん
08/06/05 22:53:05
>>710
> C++0xは現役のまま最先端を走り続け
「他言語に出来ることが出来ないので悔しい」
って、入れた機能がほとんどじゃないかい？

715:デフォルトの名無しさん
08/06/05 22:53:25
>710
Fortran2008は結構強烈だぞ？

716:デフォルトの名無しさん
08/06/05 23:00:35
>>714
conceptはHaskellだけじゃない、似てる機能があるのは。
しかもそれは後から分かったことだし。
traitsを置き換えるために生まれた。

move semanticsだってかなり狂ってるしね。
明示的なメモリ管理がある言語で導入するとは。

717:デフォルトの名無しさん
08/06/05 23:50:13
C++ はあまりお作法がない言語だったと思っていたんだが、今は作法が大杉って困る

718:デフォルトの名無しさん
08/06/06 00:03:11
意味が不明瞭だ
お作法って具体的にはどういうこと？

719:デフォルトの名無しさん
08/06/06 13:01:23
>>713
registerもいつか役に立つ日が来るのでしょうか?

720:デフォルトの名無しさん
08/06/06 13:06:07
>>715
Fortran2008のco-Arrayなんて、
Crayの実装の後追いじゃないですか。
C++0xなんて規格が独走状態ですよ。
一緒にしないでください、失礼です。

721:デフォルトの名無しさん
08/06/06 13:45:38
>>718
俺のエスパー能力を駆使すると、パラダイムをお作法と訳してるんじゃねーの。
禿げ曰く「C++はマルチパラダイム言語だ」と。
パラダイムがないつーか、ひとつに縛らない言語だがな。
パラダイムが何も無いのがすばらしいなら、ifとgotoだけでいいじゃねーかと。

722:デフォルトの名無しさん
08/06/06 16:09:13
規格を崇拝するお前らに楽しい問題。

class string {
public:
　　string(const char*);
};

void f(string, string, bool = false); // 1
void f(string, bool = false); // 2

void g() {
// どちらの関数が呼ばれるか。
　　f(“Hello”, “Goodbye”);
}

俺はできなかった。
まあ、Overload Resolutionの厳密なルールを暗記してるわけじゃないし。
答え：URLﾘﾝｸ(blogs.msdn.com)

これをもうちょっと人間的にするために、
なにかプログラマが優先順位を指定できるような機能はつくれないのかな。

723:デフォルトの名無しさん
08/06/06 16:39:20
暗黙的に呼ばれる変換コンストラクタに依存するのはよくないってのは有名な話じゃね。
だれしも一回は引っかかる罠だけどね。

724:デフォルトの名無しさん
08/06/06 17:49:35
その辺いじくるとスマートポインタが軒並みぶっ壊れるから
触れないし触らない方がいい

725:デフォルトの名無しさん
08/06/06 17:52:57
つ f(string("Hello"), string("Goodbye"));

726:デフォルトの名無しさん
08/06/06 18:45:45
正直ついていけてません。すみません orz

727:デフォルトの名無しさん
08/06/06 19:38:40
>>719
もしかしたら、&の使用を制限する目的に使えるかもしれない。
例えば、register int foo して func(& foo) したらエラーになるとか。
で、参照渡しができるのなら、ポインタの使用を禁止できることになる。
# 意味が違いすぎるなw

728:デフォルトの名無しさん
08/06/06 20:37:33
俺も最近まで register に & を付けれないと思ってたけど、
C++ では付けれるらしいよ。

729:デフォルトの名無しさん
08/06/06 20:42:27
もうラムダ式のキーワードにregister使ったらいいじゃん
どうせ予約語の意味なんてメチャクチャなんだから

730:デフォルトの名無しさん
08/06/06 20:42:58
何度も言うようだが inline がいいと思うお

731:デフォルトの名無しさん
08/06/06 20:45:01
却下されたんだろそれ

732:デフォルトの名無しさん
08/06/06 20:47:45
やっぱり解析が凶悪になるからか。

733:デフォルトの名無しさん
08/06/06 22:20:43
>>731
だれか提案したの？

734:デフォルトの名無しさん
08/06/06 22:45:36
ここの誰かが突撃してはいはいﾜﾛｽﾜﾛｽされた

735:デフォルトの名無しさん
08/06/06 22:57:33
キチガイ度で言えば現状もどっこいどっこいだと思うだけどな。

736:デフォルトの名無しさん
08/06/06 23:32:07
最初から頭の使い方が足りなくて狂ってるとしか思えないのと
考えに考えた末に発狂するのとでは筋が違うと思う。

737:デフォルトの名無しさん
08/06/06 23:42:24
オーバーロードは罠が多いから・・
特に特殊化と混じったりするとわけわからん

738:デフォルトの名無しさん
08/06/06 23:54:55
>>734
それどこで？
comp.std.c++ と comp.lang.c++ と流し読みしてるけど、とりあえず見覚えが無い。

739:デフォルトの名無しさん
08/06/07 01:11:13
inlineも規格化前に勝手な独自拡張でｸﾁｬｸﾁｬに使われてきた経緯があるから
あまり触れたくないよな

740:デフォルトの名無しさん
08/06/07 19:41:12
inlineってどうするの?

m = inline (auto x, auto y) { return x > y ? x : y; } (10, 20);

とか?

741:デフォルトの名無しさん
08/06/07 20:23:44
無名関数をinlineと呼ぶのはすげえ違和感がある

742:デフォルトの名無しさん
08/06/07 20:35:49
__lambdaとか_Lambdaでいいからキーワード追加してくれよ。
適当に#defineして使うからさあ

743:デフォルトの名無しさん
08/06/07 21:21:55
別に _Lambda だろうが [&] だろうがいいけど
とりあえず #include <lambda> をくれ。

744:デフォルトの名無しさん
08/06/08 20:07:30
C++03 の extern inline って C++0x にまだ残ってる？

745:デフォルトの名無しさん
08/06/09 15:24:25
>>722
でどっちが呼ばれるの？

ふつーに考えて1でしょ？
(ブーッという音が聞こえてるようだ)

746:デフォルトの名無しさん
08/06/09 15:31:18
失礼、答えつけててくれたんだね。。。
んで、pointer-to-boolなんて知らなかったので、さらに調査中。
昔はほんとにC++好きだったんだけどな。今は規格がぎしぎししてるね。

747:デフォルトの名無しさん
08/06/09 18:31:18
その馬鹿げた変換を何とかするためのnullptrだが
全然何ともなってないといういつものパターンなんだろ

748:デフォルトの名無しさん
08/06/09 19:25:05
もうポインタと整数
整数とbool
は互換禁止にすべきだな

やりたきゃ明示的にキャストしれと

749:デフォルトの名無しさん
08/06/09 19:27:18
if(smart_ptr)が出来なくなるとブーたれる奴らが強硬に反対するので無理です

750:デフォルトの名無しさん
08/06/09 20:17:32
それは暗黙的変換とは関係なくね？

751:デフォルトの名無しさん
08/06/09 20:18:01
NULL と比較しろよ・・・。
ただ、if (T* p = dynamic_cast<T*>(q)) { ... } がやりたいので
無くなると困る。

752:デフォルトの名無しさん
08/06/09 20:47:28
「さらば、式の中でも変数を定義できるようにして進ぜよう！」

753:デフォルトの名無しさん
08/06/09 21:45:57
なんでよりカオスな方向に解決するんだよw

754:デフォルトの名無しさん
08/06/09 22:27:43
オカス！？美少女中学生を！？

755:デフォルトの名無しさん
08/06/09 23:42:09
>>751
は？C++でNULLなんて使うなよ。0を使え。

756:デフォルトの名無しさん
08/06/09 23:48:56
これからはnullptrだろ常考

757:デフォルトの名無しさん
08/06/10 00:34:52
nullptrなんて意味ないよなぁ
どうせ変数に入れたら0と区別付かないからやりたい放題なのに

758:デフォルトの名無しさん
08/06/10 01:41:26
>>755
NULL をどう定義するかは処理系定義で、
整数変数に代入しようとした時に警告出してくれるように
定義してくれてるかもしれないというのに
何で 0 なんて使わないといけないのか。

759:デフォルトの名無しさん
08/06/10 01:42:55
>>758
Effective C++ を100回読め

760:デフォルトの名無しさん
08/06/10 01:49:27
NULLを0以外でdefineしてるC++の処理系なんてものがあったとしたら
今すぐ叩き壊した方がいいよ

761:デフォルトの名無しさん
08/06/10 01:58:26
C++では、マクロを使わない事を推奨されている。なのでNULLよりも0を使う方が綺麗。
もちろん、C++はある程度「綺麗」なスタイルを提示しながらも、そうじゃないスタイルを拒絶することはしない。
better Cとして、例外を使わなかったり、templateを使わなかったり、NULLを使っても良い。
ただし、それが推奨されているわけではないことは覚えておくべき。

762:デフォルトの名無しさん
08/06/10 02:08:51
>>760
g++ は __null で定義されているが・・・。

763:デフォルトの名無しさん
08/06/10 02:35:32
NULL 使ってる人は毎回 cstddef あたりを #include してるのか？

764:デフォルトの名無しさん
08/06/10 03:00:50
>>761
enum{NULL = 0};

765:デフォルトの名無しさん
08/06/10 03:03:49
<template T>
T *NULL(){
　return 0;
}

766:デフォルトの名無しさん
08/06/10 07:04:54
NULLより0ってのは、
Effective C++以前のC++ FAQの時代からの常識。
>>759
情けない…このスレに来るのは十年早いよ。

767:デフォルトの名無しさん
08/06/10 07:20:10
>>763
NULL は結構色んなヘッダファイルで定義されてるので
cstddef をインクルードするまでもないことが殆ど。

768:デフォルトの名無しさん
08/06/10 07:24:44
Effective C++ と C++ FAQ の説明内容に違いはあるの？お爺様

769:デフォルトの名無しさん
08/06/10 07:28:50
相変わらず破綻してる言語だな

770:デフォルトの名無しさん
08/06/10 07:29:45
>>765
それだとメンバへのポインタに対応できない気がする。

771:デフォルトの名無しさん
08/06/10 08:42:09
定期的に低レベルの話題で荒れるな

772:デフォルトの名無しさん
08/06/10 08:50:23
>>767
実際のコンパイルでエラーになるまで対応するヘッダをインクルードしないってこと？
ライブラリの実装に依存してそうでイヤじゃない？

773:デフォルトの名無しさん
08/06/10 09:37:26
>>771
低レベルの質問にはよく答えられる低の高くらいのレベルの人が多いんですよ。
おいらも含めて。ｗ

774:デフォルトの名無しさん
08/06/10 10:47:54
低の高っていうと
エントリーモデルの中で頭一つ出た商品みたいで所謂人気商品ってイメージ

775:デフォルトの名無しさん
08/06/10 11:16:08
ある意味正しいな。
今は、プレミアム系商品の人気が高くなっている辺りも含めて。

776:デフォルトの名無しさん
08/06/10 14:01:46
C--

777:デフォルトの名無しさん
08/06/10 15:27:35
>>776
廃れたね。
JVMもCLRもなければ主流になったかも知れないのに。

778:デフォルトの名無しさん
08/06/10 16:32:19
>>772
規格でどのヘッダがNULLを定義してるか決めてあるでしょ。

779:デフォルトの名無しさん
08/06/10 17:05:26
>>772の言っているのは、
使うなら、定義されてるヘッダを必ず明示的にインクルードしないと、
コンパイル通っても、実装依存なコードだってことでしょ。
実際多いよね、そういうコードは。
実装上の都合による孫インクルードに依存しているコード。

780:デフォルトの名無しさん
08/06/10 17:37:45
>>779
多いね。
うっかりやることもあるので、ちゃんと警告するシステムが欲しい。
（あるのかな？）

781:デフォルトの名無しさん
08/06/10 17:43:48
NULLはプリプロセッサマクロだから使うなと言う舌の根も乾かぬうちに
#includeの話題で盛り上がってるあたりC++の病巣がよく表れている

782:デフォルトの名無しさん
08/06/10 17:45:27
#include を使わずに済むしかけを入れて欲しかったな＞C++0x

783:デフォルトの名無しさん
08/06/10 17:50:06
シンボルだけを読み込む機能は確かに欲しいが、
いまさらC++に入れるくらいなら俺はDを使うわ。

784:デフォルトの名無しさん
08/06/10 17:52:09
標準ヘッダーファイルの拡張子を無くしたときにやるべきだったな

785:デフォルトの名無しさん
08/06/10 18:46:50
>>784
標準の拡張子無しのヤツはヘッダっていうんじゃなかった？
自分で作ったらヘッダーファイルだっけね。

786:デフォルトの名無しさん
08/06/10 20:53:48
ヘッダはファイルである必要は必ずしもないという実装者を挑発するルールです

787:デフォルトの名無しさん
08/06/10 21:00:08
Windows使っている俺は、実際のファイル名をヘッダ名と同じにしないでくれと思っている。
具体的に言うとファイル名に拡張子ほしい。<ios>でios.hppを探しに行くような感じで。
拡張子のないファイルは扱いが面倒臭い。

関連付け以外にも、色分けなどのために拡張子で種類を判別するエディタの多いこと。

788:デフォルトの名無しさん
08/06/10 21:19:21
ヘッダファイルにエディタへのヒントとして、ファイルタイプを書くか、
副次ストリームに書く。
エディタはそれを読んで判断。

789:デフォルトの名無しさん
08/06/10 21:41:22
ハードリンクでも張っとけばいいんじゃない？

790:デフォルトの名無しさん
08/06/10 23:15:03
副ストリームって最近冷遇されてる気がするなあ

791:デフォルトの名無しさん
08/06/10 23:17:46
><ios>でios.hppを探しに行くような感じで
でも結局iosのファイルの中身は
#include <ios.hpp>
だけだったりするんだよね

792:デフォルトの名無しさん
08/06/10 23:29:30
0xが正式に導入されたら、今ある入門書って買い換えなきゃいけない？

793:デフォルトの名無しさん
08/06/10 23:31:43
入門レベルなら大して変わらないかと

794:デフォルトの名無しさん
08/06/10 23:38:16
「対して変わらない入門書」なんてものは悪書としか言いようが無い。
C++標準化後にどれだけ旧態然とした入門書が悪影響を与えたか。

795:デフォルトの名無しさん
08/06/10 23:54:23
正式導入されたとしても、
結局 VC++ が無視したら広まらないんだろうな。
C99 みたいに。

796:デフォルトの名無しさん
08/06/10 23:56:17
既にTR1入れてるぐらいだし、比較的早めに0x対応するのではないかと楽観視している

797:デフォルトの名無しさん
08/06/10 23:58:18
STLの書き換えがダルそうだよな
俺らは使うだけだけど

798:デフォルトの名無しさん
08/06/11 00:00:01
どうせ書くのはdinkumwareだろ
MSじゃなくてさ

799:デフォルトの名無しさん
08/06/11 00:00:45
まあ TR1 くらいなら特にコンパイラいじる必要もないから簡単に入れれるけど、
言語仕様に手を入れるのはどうなんだろうね。
VCEE の C++ の力の入れ具合が 2005 で微妙だったのが（デフォでは Platform SDK なし）
2008 で微妙に改善されたので（デフォで Windows SDK あり）
もしかしたらやる気があるのかもしれない。

800:デフォルトの名無しさん
08/06/11 00:16:03
>>799
TR1だってispodとかコンパイラに手を入れないと無理なのもある。

ところで、もしVC++がExpressだと0x使えないって言われたら
喜んでStandard買いそうな気がしてならない。
そんときゃg++で我慢すればいいはずなのに。

801:デフォルトの名無しさん
08/06/11 00:16:59
で、結局入門書は買いなおしたほうがいいんだな？

802:デフォルトの名無しさん
08/06/11 00:19:50
しばらくは取って付けたような入門書ばかり出るんだろうけどね。

803:デフォルトの名無しさん
08/06/11 00:20:53
入門書なんてvarとshared_ptrあたりをさわるので精一杯じゃね

804:デフォルトの名無しさん
08/06/11 00:22:39
var じゃなくて auto じゃね

805:デフォルトの名無しさん
08/06/11 00:23:59
autoとヌルポは絶対教えるだろ。
あとはinitializerでのコンテナ初期化と範囲forとか

806:デフォルトの名無しさん
08/06/11 00:27:12
どうせ数ページ書き直しただけで「C++0x対応・全面改訂版」とかって帯付けて売るんだぜｗ

807:デフォルトの名無しさん
08/06/11 00:29:05
欄外に「新しいC++の規格ではこのように書くことも出来るようになりました」って注釈つけて終わりにしたりな

808:デフォルトの名無しさん
08/06/11 00:31:26
D&E 2015年版が出るなら絶対買う。

809:デフォルトの名無しさん
08/06/11 00:43:26
地味だけどlong longは間違いなくとり上げられる。

810:デフォルトの名無しさん
08/06/11 00:48:09
>>799
けどC++/CLI蹴られたし、ISO C++からは離れるかもね。

811:デフォルトの名無しさん
08/06/11 00:53:26
>>809
型の種類と値の範囲の表をちょっと増やすだけだもんなｗ

個人的にはUTF文字列をまともに扱って欲しい

812:デフォルトの名無しさん
08/06/11 18:58:03
美少女中学生にしてみれば下着の種類が増えるだけだからな
外に出るときの見た目は変わらない

813:デフォルトの名無しさん
08/06/11 19:48:21
対応したコンパイラって、すぐ出るのかな？

814:デフォルトの名無しさん
08/06/11 19:49:30
gccとか既に一部対応してるから、規格になることには全部対応してるんじゃね？

815:デフォルトの名無しさん
08/06/11 19:53:42
ふむ。
gccぶち込んでみるかな。

816:デフォルトの名無しさん
08/06/11 20:54:49
139 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/11(水) 20:50:38
どうでも良いが個人的にまつもと氏に0xに改善されても尚C++が問題外かどうかを訊ねたい。

817:デフォルトの名無しさん
08/06/11 21:31:56
>>816
もっとだめと言うに100万ペリカ

ところで初心者向けと言えば、やっぱりテンプレート絡みの
エラーメッセージがまともになるという1点においてコンセプトが
一番簡単にアピールできる機能だと思う。
コンセプト自体は、入門書で取り上げられるような内容ではないだろうけど。

818:デフォルトの名無しさん
08/06/12 08:16:26
禿は0xむけに第4版出すんだろうか

819:デフォルトの名無しさん
08/06/12 10:28:13
第4版よりD&Eの第2版がほしい

820:デフォルトの名無しさん
08/06/12 14:25:24
D&Eの続編書いて欲しいな。別の本で。
>>693のGregorとか。
一人で大幅な改訂してる暇はたぶんないだろ。
WG21 papers、かなり名前出てくてるからな。

821:デフォルトの名無しさん
08/06/12 14:26:54
Wikiを読んでいると、「うざくなって？」って、思えてきたのですが、
そんなことない？

822:デフォルトの名無しさん
08/06/12 14:32:27
日本語でおｋ

823:デフォルトの名無しさん
08/06/12 16:20:39
美少女中学生が携帯で書き込んでいるようだな

824:デフォルトの名無しさん
08/06/12 17:13:20
>>823
ぼっぼくと付き合ってくださいっ！

825:デフォルトの名無しさん
08/06/12 18:01:42
>>824
文脈的には>>821が美少女中学生だと思う

TC++PLやD&Eの続編って書く予定ないのかなと思って禿のページ見に行ったら
なんかいまC++の入門書書いてるみたいだね

826:デフォルトの名無しさん
08/06/12 18:30:15
VCって、どこまで対応させるのかな～？

827:デフォルトの名無しさん
08/06/12 20:21:40
>>825
おお、それは期待したい

828:デフォルトの名無しさん
08/06/12 20:21:56
テンプレートだって未だにまともになってないのに
そこにコンセプトなんか追加したらどうなることやら

829:デフォルトの名無しさん
08/06/12 22:22:58
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」と書き込もうとしたけどやめた。

830:デフォルトの名無しさん
08/06/12 22:24:03
やめろよ

831:デフォルトの名無しさん
08/06/12 22:31:25
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」っていう書き込みを見て「やめろよ」と書き込もうとしたけどやめた。

832:デフォルトの名無しさん
08/06/12 22:33:18
C++0xは美少女中学生萌え言語ですよ？

833:デフォルトの名無しさん
08/06/12 22:35:17
C++0xと美少女中学生には全く関連性がありません！
両者が結びついているかのような書き込みは控えてください！迷惑です！
ここはC++0xのスレッドです！C++0xの話をしてください！
美少女中学生の話がしたければどこかよそでやってください！

834:デフォルトの名無しさん
08/06/12 22:39:31
えぇーまじでぇー

835:デフォルトの名無しさん
08/06/12 22:55:11
C++0xなら美少女中学生なんてコンパイル時にゲットできる

836:デフォルトの名無しさん
08/06/12 22:56:41
NGワード : 少女

837:デフォルトの名無しさん
08/06/12 22:57:56
>>835
コンパイルに何年かかるんだ？

838:デフォルトの名無しさん
08/06/12 22:58:14
>>828
コンセプトが追加されてはじめてまともになるんじゃないか。何を言ってるんだ

839:デフォルトの名無しさん
08/06/12 23:37:42
>>838
紫の上のコンパイルはたった４年です。

840:デフォルトの名無しさん
08/06/13 21:31:21
>>784
拡張子をなくした理由ってなんだろ？

841:デフォルトの名無しさん
08/06/13 21:32:15
>>792
いつまで入門者でいるつもりなのかなー

842:デフォルトの名無しさん
08/06/13 21:38:19
>>840
ヘッダはファイルである必要は無い
とか言えるようにするため。

843:デフォルトの名無しさん
08/06/14 00:34:50
.hまで含めて名前です。とかでもよかったじゃん。

844:デフォルトの名無しさん
08/06/14 00:36:53
互換性を失う変更を導入するための苦肉の策だったのだと思う

845:デフォルトの名無しさん
08/06/14 00:37:26
名前空間の無い時代に

#include <iostream.h>
int main() {
　cout << "hoge" << endl;
　return 0;
}

とか書かれたプログラムが大量にあってだな・・・。
それとの互換性を考えると名前を変えざるを

846:デフォルトの名無しさん
08/06/14 10:06:58
ほんっとしがらみいっぱい過ぎだよな。

847:デフォルトの名無しさん
08/06/14 10:11:18
互換性無視してしがらみ全部捨てたC++欲しいよな。
特に暗黙の型変換辺り。

ちなみにDなら不要だよ。

848:デフォルトの名無しさん
08/06/14 10:12:46
Dは自分でしがらみ作りまくったりしてるからな・・・
時には思い切って捨てたりしてるけど（信者を）それが逆にしがらみになってる。

849:デフォルトの名無しさん
08/06/14 10:25:48
>>847
仕様だけでも作ってくれ

850:デフォルトの名無しさん
08/06/14 10:28:12
>>847
暗黙関係はトラブルの元だからどうにかしたいな。暗黙関係は警告を出すオプションが欲しい。
デフォルトのコピーコンストラクタが作成できませんなんて余計な警告はあるのになんでないんだ？＞ＶＣ８

851:デフォルトの名無しさん
08/06/14 10:52:11
明示的なメモリ管理ができないC++とか
その場合でもmove semanticsは面白いこと出来ると思う。

852:デフォルトの名無しさん
08/06/14 14:27:37
暗黙の型変換を全部禁止したらどうなるのかな
double d = 1;
とか
Base *b = new Derived();
とかが全部エラーになるんだよな

853:デフォルトの名無しさん
08/06/14 14:29:42
アップキャストは安全なキャストだから禁止する必要もあるまい。

854:デフォルトの名無しさん
08/06/14 14:33:28
安全だろうと何だろうと、何かの暗黙の変換を認めたら
あれも認めろこれも認めろと言うキチガイが出てくるので全て禁止です

そういう思想で作られてる言語ねえのかな

855:デフォルトの名無しさん
08/06/14 14:42:53
OCaml は結構型に厳しかったと思う

856:デフォルトの名無しさん
08/06/14 15:20:30
double d = 1;
は実質
double d( 1 );
と同じだから明示的な変換を表しているんじゃないか?

857:デフォルトの名無しさん
08/06/14 15:22:16
暗黙的なコピーコンストラクタの実行をやめてくれって話じゃなかったのか

858:デフォルトの名無しさん
08/06/14 15:29:26
explicit でおkだっしょ

859:デフォルトの名無しさん
08/06/14 15:41:09
デフォルトのコピーコンストラクタはどうかなあ。

860:デフォルトの名無しさん
08/06/14 15:42:31
ああ、コピーコンストラクタの話か。
0x 的には = delete してくれってことじゃないのかな。

861:デフォルトの名無しさん
08/06/14 15:44:38
組み込み型の暗黙の型変換が結構うざいんだよな。
特にポインタ、文字型、論理型が整数様型と絡むと。

862:デフォルトの名無しさん
08/06/14 15:46:08
explicit をデフォルトにしてほしかった。

863:デフォルトの名無しさん
08/06/14 15:47:36
schemeみたいに簡単に方言作れるkitがあればいいのにな。

864:デフォルトの名無しさん
08/06/14 15:55:09
>>862
それはよく思う。
でも、今更変えらんないんだろうなあ。

865:デフォルトの名無しさん
08/06/14 15:57:43
Javaはreflection APIがあるから、
言語拡張＆コンパイラ実装の研究がどんどん進んでいるね。

866:デフォルトの名無しさん
08/06/14 23:38:08
セックスプリプリシット？

867:デフォルトの名無しさん
08/06/15 09:46:35
虚しいオッサンの虚しい書き込みが続いております

868:デフォルトの名無しさん
08/06/16 13:47:36
>>865
OpenC++の中の人も今はOpenJavaやってるね。

869:デフォルトの名無しさん
08/06/17 06:06:45
クラスの内部ポインタを交換するような例外安全な swap を書くとき
それを std 空間に template <> swap( .. ) と逐一定義しないと std::swap から呼ばれない。
理屈はわかるんですけど、なんとかならないですかね。
一々 namespace std { template <> swap( うんたらかんたらと書くのが面倒くさいです。

870:デフォルトの名無しさん
08/06/17 06:50:04
クラステンプレートならどうにもならない

871:デフォルトの名無しさん
08/06/17 12:24:39
自分の場合は using std::swap してから swap() を呼び出しているので
クラスと同じ名前空間に swap() を定義している。

872:デフォルトの名無しさん
08/06/17 21:01:32
swapなんか使わない設計にしなさい

873:デフォルトの名無しさん
08/06/17 21:08:06
そうですね。
これからは右辺値参照の時代ですもんね。

874:デフォルトの名無しさん
08/06/17 23:41:59
swapを使おうとする前に、一度立ち止まって
自分が値をあべこべに格納していないか考え直しなさい

　　　　　　　　　　　　　　　　　Bjarne Stroustrup

875:デフォルトの名無しさん
08/06/18 00:38:14
>>869
恐らくどうしようもないかと思います．
さらに， std 名前空間以外の名前空間で定義された関数テンプレート
(クラステンプレート内で定義されてた非テンプレート関数もこれに準じますが)
において， unqualified call で swap が呼ばれる場合にも対応しようとすると
クラスと同じ名前空間にも swap を定義しなければいけなくなります．

現時点において，規格として std 名前空間で定義された関数テンプレート内で
>>871 さんの提言する実装 (using std::swap;) が行われている保証が無いことが
本質的な問題だと思います．ただ，ここに文句を言っても現時点での問題は
何も解決されませんので，とりあえずの次善策として， std::swap の特殊化と
associated namespace に swap を定義することの両方を実施することを
個人的には勧めておきます．「面倒くさい」という問題の解決にまったくなっていませんが．
さらに >>870 さんの言うように，クラステンプレートの場合には
根本的な解決策はないです．

>>873
move できるかどうかは， swap できるかどうかとは本質的には独立で，
特に move が可能になるためには，オブジェクトに valid resourceless state が
存在することが必要になり，これはやや強い制限だと思いますから，
move はできないけれども swap はできるという状況は比較的容易に起こりえると思います．
なので， move さえあれば良いということは必ずしも言えないかと思います．

876:デフォルトの名無しさん
08/06/18 00:51:43
concept HasSwapFunction<typename T> { T& swap(T&) throw (); }

template <typename T> requires HasSwapFunction<T>
inline void swap(T& x, T& y) throw () { x.swap(y); }

template <typename T>
inline void swap(T& x, T& y) throw () { std::swap(x, y); }

↑ こういう感じのってダメなの？よくわからんけど…

877:デフォルトの名無しさん
08/06/18 01:00:17
>>876
template<HasSwapFunction T>
concept_map Swappable<T> { void swap(T &x, T &y){ x.swap(y); } }

多分，こんな感じで concept_map で差異を吸収したほうが楽なのではないかと．

878:デフォルトの名無しさん
08/06/18 02:03:49
交換も、コピーコンストラクタや代入演算子と同じように扱えばシンプルになると思うんだけど
・デフォルトはクラスが定義するswapを実行する
・swapが実装されていなければ、言語側で一時オブジェクトを作り処理する
とできないのかな
実装で埋めようとして複雑になっている印象がありますが

879:デフォルトの名無しさん
08/06/18 04:23:08
Namespace issue with specialized swap
URLﾘﾝｸ(groups.google.ca)

880:デフォルトの名無しさん
08/06/18 10:07:18
for文の改良ってしないの？

881:デフォルトの名無しさん
08/06/18 11:18:58
foreachってC++0xになかったっけ？

882:デフォルトの名無しさん
08/06/18 16:00:02
入ったよ。
for (int &entry: aContainer) { ... }

Javaのクロージャを引数に取る拡張に比べるとつまらない。>>48
C++的には最悪のセンスだと思う。

883:デフォルトの名無しさん
08/06/18 17:41:05
Javaから構文パクるなんてC++も地に墜ちたもんだな

884:デフォルトの名無しさん
08/06/18 17:58:22
まあでもC++にeachとかinとかのキーワードを入れるのも有り得ないだろうし、
これくらいしか書きようがないと思う。

885:デフォルトの名無しさん
08/06/18 18:00:07
ところでこのループ変数は参照なの？
参照が指す先変えながらグルグル回るの？

キモッ

886:デフォルトの名無しさん
08/06/18 18:21:35
別にキモくはないだろ。
従来の、for無いのスコープで参照変数を宣言してるようなもの。

887:デフォルトの名無しさん
08/06/18 18:29:26
for (int &&entry: aContainer) { ... } はあり?

888:デフォルトの名無しさん
08/06/18 18:55:18
ぅん・・・

889:1/2
08/06/18 19:11:15
昔々、Sunにとある厨が居た。
彼はＣ言語の研修でポインターでつまづくような無能で、無論Ｃ＋＋など理解出来なかった。
プログラマーとしては全く使い物にならんということでネットワークエンジニアとして使われていた。当然役には立たなかったが、サーバー運びや配線や小間使いぐらいは出来た。
この世にポインターがあるから自分がそんな境遇に陥ったのだと不満を募らせた彼はポインターを憎悪し、ポインターの無い言語があればいいのに、と夢想するようになった。
彼はその夢想言語をJAVAと名付け陳腐な企画書を出したが、すべて無視された。
そんなある日、どうせ役には立たないんだからと、しつこいNetscape社の営業を追い払う仕事を任された。もちろん権限は一切なく、ただNetscape社の営業の話相手をし、すべてを断るだけの仕事だ。
彼は毎日のようにNetscape社の営業と無駄話をした。彼にとってそれは、愚痴や不平不満をこぼす絶好の機会だった。
Netscape社の営業は当然のように彼に同意した。彼の境遇に同情し、彼の才能を認め、褒め称えた。
そして誰も耳を傾けなかった夢想言語JAVAの話になるとNetscape社の営業は強い興味を持ち、ブラウザーに搭載したいと言い出した。当時のNetscape社は、動きのあるページを作る案を求めていた。
夢想言語JAVAが現実のものになる。彼は天にも昇る気持ちになり、全面的に協力を申し出た。が、やはり何の役にも立たなかった。すべての設計、策定、実装はNetscape社によって行われた。
Netscape社は、夢想言語JAVAを「何処でも全く同じに動く言語」としてブラウザーに搭載しようとしたのだ。
これを聞いて驚いたのはSunの役員達だ。直ちにNetscape社と交渉し、JAVAはそもそもSunのものであることを主張し始めた。
交渉の結果夢想言語JAVAの最初の実装はJavaScriptと改名することになり、SunのJAVAとは独立したNetscape社の言語となった。

890:1/2
08/06/18 19:11:45
Sunは直ちに「何処でも全く同じに動く言語」の現実性を調査し、仮想マシンを使うことで可能であることを検証した。
また夢想言語JAVAの詳細を厨に尋ね、規格をまとめ……ようとした。というのは、厨の頭の中には「ポインターを使わない」の他には支離滅裂な妄想以外何も無かったからだ。
役に立たない彼を「夢想言語JAVAを広める為の広報」に追い出し、夢想言語JAVAではなく現実的なJAVA言語の設計が行われた。
だが現実的設計にはいろいろと難があった。その度に開発部は厨に尋ね、その意向を可能な限り反映する努力を行った。しかし無能な厨の意向を反映することは困難を極めた。
その中で最も大きな障害となったのが、多重継承の禁止である。
未だにSunは公式に認めていないが、JAVAが多重継承を禁止する決断をさせたのは、実はMicrosoftの寄与するところが大きかった。
Microsoftは既にMFCとCOMによって多重継承が抱える問題を解決していたからである。
その後も厨は（何度出入り禁止を喰らっても）設計に口を出し、そして開発部はその意向を可能な限り反映する努力を行ない続けた。
特に厨が主張するコーディング規約は支離滅裂を極め、ゴスリンは「それまでに書かれたコードを書き直す量が最も少なくなるコーディング規約」をまとめる必要に迫られた。
この時にまとめられた何の意味も無いコーディング規約は後に、それを知らなかった企画部によって改めてまとめられJAVAの標準のコーディング規約として発表された。
ゴスリンはこの時の心境を「JAVAが最高だと生涯言い張り続ける覚悟を決めた」と述懐している。
厨は熱心に広報活動を行っていたが、役に立ったのは最初だけだった。すごい言語が出来る、ということを印象付けた後は、何の役にも立たなかった。
開発には近寄ることすら許されず、広報からは役立たずの烙印を押された。彼は再びネットワークエンジニアとして保守管理部に戻った。
今では彼は毎日何百ものＬＥＤを見張って、消えたらそれに対応するハードディスクドライブを交換する仕事をしていると言われている。名前は記録されていない。

891:デフォルトの名無しさん
08/06/18 19:12:40
ついに参照の指し変えが認められてしまったのか…

892:デフォルトの名無しさん
08/06/18 20:18:37
>>875
valid resourceless state てなーに？

893:デフォルトの名無しさん
08/06/18 22:24:14
Java の参照型はまさにポインタだろうが・・・。

894:デフォルトの名無しさん
08/06/18 22:26:03
NullPointerExceptionがあるしな

895:デフォルトの名無しさん
08/06/18 22:26:50
Javaの参照型はインクリメントできる？

896:デフォルトの名無しさん
08/06/18 22:28:34
>>893-895
ネタにマジレスｗ

897:デフォルトの名無しさん
08/06/18 22:29:56
マジレスもできない奴は板を替えたほうがいい

898:デフォルトの名無しさん
08/06/18 22:30:34
ネタにマジレスするのが最近のトレンドなんだぜ

899:デフォルトの名無しさん
08/06/18 22:37:47
ネタに、というよりホラにマジレスだな

900:デフォルトの名無しさん
08/06/18 22:38:24
>>892
d = std::move(s);
という構文が実行された直後の s の状態が明確に定義されていなければならないですが，
この状態は有効な状態でなければならず，かつ，
いかなるリソースの所有権も保持していないような状態でなければならないです．
これを valid resourceless state と表現していました．

有効な状態 (valid) でなければならないというのは，
move された直後の s に対しての操作が
well-defined でなければならないという要請を表現したものです．
少なくとも最低限かつ自明の要求として，いかなるタイミングでも
デストラクタの発動は有効に機能しなければならない，という意味で
有効な状態でなければならないことは分かるかと思います．

また， move は no-fail，つまり失敗しない操作であることが要求されます．
ここで仮に move 直後の s が何らかのリソースの所有権を保持した状態であるとすると
s が保持するリソースの確保において失敗が発生する可能性があり，
move が no-fail であるという要求と矛盾します．
従って， s はいかなるリソースの所有権も保持していない状態
(resourceless) である必要が出てきます．

一般に，オブジェクトが常に何らかのリソースを確保している状態であることが自然な場合，
このようなオブジェクトに move の操作が行えることを要求すると，
オブジェクトの構築は完了しているがリソースの確保が完了していない
オブジェクトの状態を有効な状態としてユーザに暴露しなければならなくなり，
RAII の観点から見てやや大きな弱点を生じるように思います．