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

C++0x 3 ..

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 の観点から見てやや大きな弱点を生じるように思います．