アカウント名:
パスワード:
C++大好きな人が「そんなCみたいなコーディングして!」とぶーたれている図ならあちこちで見られますやね。けどC大好きな人の「そのC++的発想やめてほしい」みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
> 上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに> 幽霊オブジェクトを保持していて仮想関数呼んじゃってアボーン
ってのは、本質的には言語の問題ではなくて・呼び出し先の制約条件を無視して呼び出している・不要な制約条件を呼び出し先に付与してしまっているのどちらかの設計・実装的な問題だと思います。
前者であれば、> Cならこんなこと絶対起きないですから。C++で上記のような問題引き起こしている人は、C言語でも初期化前や後処理後にコールバック呼び出して不安定な動作を引き起こすでしょ。# しかも明示的に落ちない分、見つけ出すまでの解析が大変だったりする
>本質的には言語の問題ではなくて
本質的に言語の問題じゃないというのはそうでしょうか?オブジェクト指向言語にとってオブジェクトは本質でしょ?そしてオブジェクトの構築・削除に起因するバグがC++にはとても多い傾向があるってのは否定しがたい事実だと思います。そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
プログラムってのは煎じ詰めれば機械語命令とデータの羅列でしかないわけで、そこにオブジェクトなんてものは存在しないわけですよね、本来。CPUがオブジェクトなんてものを認識したり解釈したりできるわけじゃない。つまりオブジェクトと
同じく某NTTの携帯電話開発に参加しているものです。(のでAC)
> 具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。> Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、> staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。>(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
えっと、実装ベースで解説しちゃうと、Active Object(CActive)は、CActiveSchedulerで管理される非同期イベントを受信するためのクラスで、これらはSymbian OSの基本かつ汎用の非同期管理機構となっています。CActiveSchedulerは原則そのスレッドの全ての非同期イベントを管理します。管理されるべき非同期イベントのひとつをCActiveが所有します。ヘッダのクラス定義を見ると、CAtiveSchedulerはCAciveを優先度つきキューで管理してます。受信したイベントをしかるべきCActiveへディスパッチするというわけです。
非同期イベントの受信を汎用的に集中管理するのであれば、管理対象(非同期イベント)をオブジェクトにするのはおかしいと思いますか?またその汎用の管理用キューをヒープメモリで保持するのは筋が悪いとは思えません。どうでしょう?
私も最初ハマったので、アクティブオブジェクトがそれなりに悩ましいことは否定しませんが、簡単なものを難しくしているわけじゃなく、難しいものを簡単に仕切れていない(^^;)と捉えることはできませんかね。# とはいえ、メモリ管理でハマッた記憶は無いなぁ。
Symbian OSは標準C++普及前後のC++ネイティブな組み込みOSで、強烈に独特の流儀を強いていますが、この辺りのフレームワークをモダンな標準C++で書き直したら結構面白いのではないかと思います。# 誰か作ってくれないかな。
自分もしばらく某NTTの携帯電話開発に参加してました。symbianのフレームワークはみんな一度ははまりますね。自分もしょっちゅう頭に来て「なんだよエポックってスタートレックかよ!ていうかビルド時間かかりすぎなんだよ!」とか関係ないことも毒づき(八つ当たり?)ながら開発してました。寄り道しましたが、C++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
逆なら見るけども (スコア:0)
C++大好きな人が
「そんなCみたいなコーディングして!」
とぶーたれている図ならあちこちで見られますやね。
けどC大好きな人の
「そのC++的発想やめてほしい」
みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
Re: (スコア:0)
それホントにヒープ使う必要あるの?って思う事は多いです。
デバイスを制御するクラスがnew/delteが必要だったりする場合が多くて、
別にデバイス自体は生まれたり死んだりしねーよと思うんですよね。
デバイスの初期化なんてレジスタ叩くだけじゃねーか、なんでヒープがいるんだよ、と。
制御対象となるシステムからの要請ではなく、言語自体の都合によって
ヒープが必要となるって所がどうにも納得しがたいところがあります。
プログラム言語なんてしょせん道具なのに、道具の癖に無駄なメモリ食うんじゃねーよと。
Re: (スコア:2, すばらしい洞察)
Cならコールバック関数を使う場面が、C++だと仮想関数になるわけですけども、
そうするとオブジェクトが必要になるわけですね。
で、そのオブジェクトを動的に構築していた場合は使い終わったらdeleteしないといけないんですけども、
上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに幽霊オブジェクトを保持していて
仮想関数呼んじゃってアボーン、というバグに遭遇することがとっても多くて、これもすごく腹が立ちます。
コールバックにとって本質的なのは関数であってオブジェクトじゃないのに、その非本質的な、
言語仕様の都合によって導入された部分によってバグが呼び込まれるってすごく理不尽だと思うんですよね。
Cならこんなこと絶対起きないですから。
Re: (スコア:1, すばらしい洞察)
> 上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに
> 幽霊オブジェクトを保持していて仮想関数呼んじゃってアボーン
ってのは、本質的には言語の問題ではなくて
・呼び出し先の制約条件を無視して呼び出している
・不要な制約条件を呼び出し先に付与してしまっている
のどちらかの設計・実装的な問題だと思います。
前者であれば、
> Cならこんなこと絶対起きないですから。
C++で上記のような問題引き起こしている人は、C言語でも
初期化前や後処理後にコールバック呼び出して不安定な動作を引き起こすでしょ。
# しかも明示的に落ちない分、見つけ出すまでの解析が大変だったりする
Re: (スコア:0)
>本質的には言語の問題ではなくて
本質的に言語の問題じゃないというのはそうでしょうか?
オブジェクト指向言語にとってオブジェクトは本質でしょ?
そしてオブジェクトの構築・削除に起因するバグがC++には
とても多い傾向があるってのは否定しがたい事実だと思います。
そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
プログラムってのは煎じ詰めれば機械語命令とデータの羅列でしかないわけで、
そこにオブジェクトなんてものは存在しないわけですよね、本来。
CPUがオブジェクトなんてものを認識したり解釈したりできるわけじゃない。
つまりオブジェクトと
Re:逆なら見るけども (スコア:0)
同じく某NTTの携帯電話開発に参加しているものです。(のでAC)
> 具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。
> Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、
> staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。
>(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
えっと、実装ベースで解説しちゃうと、Active Object(CActive)は、CActiveSchedulerで管理される
非同期イベントを受信するためのクラスで、これらはSymbian OSの基本かつ汎用の非同期管理機構となっています。
CActiveSchedulerは原則そのスレッドの全ての非同期イベントを管理します。
管理されるべき非同期イベントのひとつをCActiveが所有します。
ヘッダのクラス定義を見ると、CAtiveSchedulerはCAciveを優先度つきキューで管理してます。
受信したイベントをしかるべきCActiveへディスパッチするというわけです。
非同期イベントの受信を汎用的に集中管理するのであれば、管理対象(非同期イベント)を
オブジェクトにするのはおかしいと思いますか?
またその汎用の管理用キューをヒープメモリで保持するのは筋が悪いとは思えません。どうでしょう?
私も最初ハマったので、アクティブオブジェクトがそれなりに悩ましいことは否定しませんが、
簡単なものを難しくしているわけじゃなく、難しいものを簡単に仕切れていない(^^;)と
捉えることはできませんかね。
# とはいえ、メモリ管理でハマッた記憶は無いなぁ。
Symbian OSは標準C++普及前後のC++ネイティブな組み込みOSで、
強烈に独特の流儀を強いていますが、
この辺りのフレームワークをモダンな標準C++で書き直したら結構面白いのではないかと思います。
# 誰か作ってくれないかな。
Re: (スコア:0)
自分もしばらく某NTTの携帯電話開発に参加してました。
symbianのフレームワークはみんな一度ははまりますね。
自分もしょっちゅう頭に来て
「なんだよエポックってスタートレックかよ!ていうかビルド時間かかりすぎなんだよ!」
とか関係ないことも毒づき(八つ当たり?)ながら開発してました。
寄り道しましたが、C++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、
拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。