起さないという目的で使うものです。(2/25)それより重要なことは、間違いには2種類あるということです。使うと、(A)は出てきません。いと思う人は、多いでしょう。最後の部分、同意できませんね。人間は間違う、だから、間違ったとしても安全側に倒れるように作るようにプログラムは作るべしと。過去幾つも発見されています。仕組みを実装することが多いですね。(1/10)ところで、fjvvですが、すでに休眠状態ではありますけど、ある事情から、私としては再開は非常に難しいのではないかと考えています。(1/16)これなんですが、おっしゃることは分かりますが、方法は二つあると思います。(1)どうせ、サーバーを管理する人しかサービスを提供してくれない訳だから(つまり、松宮さんのこと)fjvvになってもらって、スクリプトを共有する。働かない人に渡しても仕方が無い、という考えですね。(2)fj.news.policyで苦情が出るかどうかをみた上で、あっさり公開する。こちらは、久野さんに責任をとってもらう(どういう責任だ?(笑))という考えです。(1/17)いや、それは無駄なので。プログラムを渡して、必要ならdebugの上で、実際に稼動させてもらえるのか?という意味です。(1/17)じゃ、高屋敷さんを含めて異議がなければ、(異義ではない)送ります。(1/17)それはいいんだけど。いう条件で使ってもらうとかいう相談は済んでるんでしょうか、または松宮さんがfjvvに入るのか。いう位置付けなのかよく見えないんで教えてくれませんか。(1/17)こっちは、松宮さんの実績を見て考えるということで。私は、江戸っ子じゃないので、気は長い(笑)。(1/30)>あと、SandBoxな話でJavaのメモリ管理が見えないということの弊害>についてもお伺いしましたっけ。食い潰し...てな事態は決してレア・ケースじゃない。(1/30)便乗質問。(最近C++から離れているもので。(1/30)なにやらできるみたいですよん。(1/30)newで作ったオブジェクトのポインタをstd::auto_ptrとかboost::shared_ptrとかのスマートポインタで受け取るようにすれば、参照カウント式のGCができます。マーク&スイープ方式のようにメモリ空間を探索する手間がなくて、パフォーマンス劣化も少ないのでC++向きかと思います。(1/31)Cでも型情報を持っていて色々やるコードというのはあります。SWIGなんかもそうです。SWIGの場合はスクリプト言語とC/C++コードのコミュニケーションのために持っているのであってGCのためではないですけど。あとはスマートポインタの類も型情報を持っているからこそ参照カウントで消せるといえると思います。(2/2)JavaのC++に対するメリットって「リッチな中間層」で提供されているものですよね。中間層を増やして柔軟性と機能を追加していくのがソフトウェアの基本的性質なら、C++はパフォーマンスのためにあえてその辺りを全部とっぱらった言語と言えます。GCだって、newしたオブジェクトを全部shared_ptrに格納すればできるんですから。タイプ数はちょっと多くなりますけど。(2/4)いっそ、生ポインタを使えない制約と、Objectを自動的に継承するようにサポートするなどの記法(一種の言語のようなもの)を決めて、その記法を通常のC++コードに変換するツール(プリプロセッサ)を作ったらどうでしょう。その記法として「Java」を採用したらよろしいのでは。GC等もサポートします。