アカウント名:
パスワード:
C++信者です。
中途半端に親切な言語だと、その親切に頼ったコーディングになってしまうような気がします。
たとえば、GCのおかげでメモリリークを気にしなくて良くなったせいで、後始末を省略する癖が付いてしまったとします。すると、ファイルを閉じ忘れて放置するとか、DBを切断し忘れて放置するとか、メモリ以外のリークに配慮が行き届かない、コーディングスタイルが身についてしまわないか心配です。
そこでC++の出番です。デストラクタのおかげで、オブジェクトがスコープから外れると、必ずシステムリソースをクローズした上で解放される、といった仕組みを作り込むことができます。（もちろんバグ有りの腐ったライブラリはこの限りではありませんが）
そんなわけで、JavaやC#はfinalizeされるタイミングが確定的ではないので、GCによるメリットより、C++のようなデストラクタによるメリットの方が上だと思っています。
そのほか、C++の素敵なところは、コピーコンストラクタと代入演算子のオーバーライドができる点が、私のお気に入りです。単純にaをbに代入するというようなコード（b = a;）があったとします。コピーコンストラクタと代入演算子の実装次第で、オブジェクトのディープコピーをさせることもできるし、参照カウンタ付きポインタを実装することもできます。JavaやC#はCloneableなオブジェクトを実装するのが面倒という印象があります。
実際にCのコーデングをしてみれば体感できると思うけれど解放すること自体は、苦になりません。
んー、ちょっと苦になるかな。解放し忘れるリスクは否定できないので、やっぱり、スコープから抜けたら確実に解放できる仕組みが欲しいですね。C++なら作業用メモリは、std::vector tmp(n);とかで確保すればいいし。
スタックに積めばいいだけでは? スコープから抜けたら確実に解放されるよ。
char buf[1024*1024*100];とか平気でやって、スタックオーバーフローをバグだバグだと大騒ぎする人を教育せにゃあ。
その問題はldの--stackオプションでスタックをたっぷり取れば解決する。
> そんなわけで、JavaやC#はfinalizeされるタイミングが確定的ではないので、どうせC#をJavaのパチモンくらいにしか思ってないんでしょ? (タレコミのリンク先の奴と同じで)usingも知らないの? いや知らないこと自体は一向にかまわないんだけどどうして知らないものについてこうも自信満々に語れるのか理解できない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
C関係で思ったこと (スコア:0)
なぜなら、GCがあったとしてもそれに頼るようなコーディングはしないし、
ヘタレなコーディングすればメモリリークはGCがあっても発生するから
実際にCのコーデングをしてみれば体感できると思うけれど
解放すること自体は、苦になりません。
逆に、確保とサイズ変更が大変。
この点はLLとかGCのある言語と比較してCの短所になると思うし、GCの恩恵じゃないかと思う。
※メモリ確保したときは基本同じスコープないで解放もするので
複雑なメモリ管理が必要になるケースはあまりないです。
あと、C#はJavaじゃなくてPASCALをC/C++の文法に似せる形にしていたと思った。
Microsoftのサイトに書いてあったはずなのだけど探してみたけど見つからなかった。
気のせいかな～?
Re:C関係で思ったこと (スコア:2, 興味深い)
C++信者です。
中途半端に親切な言語だと、その親切に頼ったコーディングになってしまうような気がします。
たとえば、GCのおかげでメモリリークを気にしなくて良くなったせいで、後始末を省略する癖が付いてしまったとします。
すると、ファイルを閉じ忘れて放置するとか、DBを切断し忘れて放置するとか、メモリ以外のリークに配慮が行き届かない、コーディングスタイルが身についてしまわないか心配です。
そこでC++の出番です。デストラクタのおかげで、オブジェクトがスコープから外れると、必ずシステムリソースをクローズした上で解放される、といった仕組みを作り込むことができます。（もちろんバグ有りの腐ったライブラリはこの限りではありませんが）
そんなわけで、JavaやC#はfinalizeされるタイミングが確定的ではないので、GCによるメリットより、C++のようなデストラクタによるメリットの方が上だと思っています。
そのほか、C++の素敵なところは、コピーコンストラクタと代入演算子のオーバーライドができる点が、私のお気に入りです。単純にaをbに代入するというようなコード（b = a;）があったとします。コピーコンストラクタと代入演算子の実装次第で、オブジェクトのディープコピーをさせることもできるし、参照カウンタ付きポインタを実装することもできます。JavaやC#はCloneableなオブジェクトを実装するのが面倒という印象があります。
んー、ちょっと苦になるかな。解放し忘れるリスクは否定できないので、やっぱり、スコープから抜けたら確実に解放できる仕組みが欲しいですね。C++なら作業用メモリは、std::vector tmp(n);とかで確保すればいいし。
Re: (スコア:0)
スタックに積めばいいだけでは? スコープから抜けたら確実に解放されるよ。
Re: (スコア:0)
char buf[1024*1024*100];
とか平気でやって、スタックオーバーフローをバグだバグだと大騒ぎする人を教育せにゃあ。
Re: (スコア:0)
その問題はldの--stackオプションでスタックをたっぷり取れば解決する。
Re: (スコア:0)
> そんなわけで、JavaやC#はfinalizeされるタイミングが確定的ではないので、
どうせC#をJavaのパチモンくらいにしか思ってないんでしょ? (タレコミのリンク先の奴と同じで)
usingも知らないの? いや知らないこと自体は一向にかまわないんだけどどうして知らないものについてこうも自信満々に語れるのか理解できない。