アカウント名:
パスワード:
C++大好きな人が「そんなCみたいなコーディングして!」とぶーたれている図ならあちこちで見られますやね。けどC大好きな人の「そのC++的発想やめてほしい」みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
> 上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに> 幽霊オブジェクトを保持していて仮想関数呼んじゃってアボーン
ってのは、本質的には言語の問題ではなくて・呼び出し先の制約条件を無視して呼び出している・不要な制約条件を呼び出し先に付与してしまっているのどちらかの設計・実装的な問題だと思います。
前者であれば、> Cならこんなこと絶対起きないですから。C++で上記のような問題引き起こしている人は、C言語でも初期化前や後処理後にコールバック呼び出して不安定な動作を引き起こすでしょ。# しかも明示的に落ちない分、見つけ出すまでの解析が大変だったりする
>本質的には言語の問題ではなくて
本質的に言語の問題じゃないというのはそうでしょうか?オブジェクト指向言語にとってオブジェクトは本質でしょ?そしてオブジェクトの構築・削除に起因するバグがC++にはとても多い傾向があるってのは否定しがたい事実だと思います。そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
プログラムってのは煎じ詰めれば機械語命令とデータの羅列でしかないわけで、そこにオブジェクトなんてものは存在しないわけですよね、本来。CPUがオブジェクトなんてものを認識したり解釈したりできるわけじゃない。つまりオブジェクトというのは、オブジェクト指向言語にとって必要な存在なだけであって、プログラムそのものにとっては本来必要なものじゃない。その本来必要でないものがメモリを要求する、あまつさえバグを誘引するってところにどうにも理不尽さを感じちゃうんですよね。
>staticメソッドで実装すればいいところを通常メソッドで実装してるだけで、単なる言語仕様に対する理解不足かと。
ああ、やっぱりこういう突込みが入ったか。コールバックと言っても、実際のシステムにおいては本当にただ単に関数をコールするだけって事は稀で、通常はタスク間の非同期通信機構の一部としてコールバック関数が要求される事が多いわけです。そしてOSなりフレームワークなりの非同期通信機構がC++オブジェクトをパラメータに要求する以上はそうせざるを得ないんですよ。
具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
某NTTの携帯電話開発に参加した時に、このActive Objectの削除に起因するバグに散々悩まされたんですよ。それで疑問に感じたんですね。なんでこんな本質的なじゃない部分のデバッグに散々時間をとられにゃならんのだと。ちゃんと書けばちゃんと動くから本質的な問題じゃないよと言われても、ちゃんと書けない奴がこんだけ居るんだったら、それはやっぱり本質的な問題だろって思っちゃうんですよね。
> そしてオブジェクトの構築・削除に起因するバグがC++には> とても多い傾向があるってのは否定しがたい事実だと思います。> そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
未だに fscanf() で動かない、動かなくなるシステムがあるのは C言語自体が本質的にはらむ欠陥であるということですね。でも、fgets(),sscanf() という解は昔から提案されているので困るのは素人だけです。
標準ライブラリですらない「Symbian OS の Active Object」のための問題だと認識しているなら、C++ のせいにするのはヘンです。heap を使う仕様が気に入らないといっても、それは C++ の仕様ではありませんよね。その愚痴は、そんなフレームワークを採用した企画者に矛先を向けた方が適切な気がします。まあ、充分な予備調査をする時間がないのがそもそもの原因だと思いますが…。
結局、後出しジャンケンした上に・SymbianOSなど特定のOS、frameworkの仕様・開発現場のスキル不足・スキル不足を補うような開発プロセスが組まれていない等をC++の欠点と主張しているように思えますが。
それに、本当に> このActive Objectの削除に起因するバグに散々悩まされたんですよ。のであれば、コードレビューやチェックリストで潰せばいいのに。
既存の成果物を使うなどで自分たちが仕様を自由に決められない場合、OS、デバドラ、特定ライブラリなどのはまりやすいポイントなどのチェックリスト作って、設計/コ
>設計/コードレビュー
これ重要っすね。レビューすること。そしてその情報を共有(いまさらクチはばったいけど)すること。あるいは時には後から気づいてしまった事柄については(社内に)フィードバックすること。
脱線になりますがペアプログラムでシゴトしたいなあ。最高(最速だという意味で)のレビューだから。つまり不味い書き方は3秒後に発見され撲滅されるから。またペアを時々入れ替えるってことをやれば自ずと共有やフィードバックにもなるし。
#外注との意思疎通不足で激しくデグレったのでAC#みんなは外注の「頭が悪い」「コミュニケーション能力が悪い」と思いたいみたいだけど、#こっちも知識の伝え方が不十分だったことを反省しないと、何度やっても同じ失敗の繰り返しだよ?
>そこにオブジェクトなんてものは存在しないわけですよね、本来。
無粋な奴だな。きみは「見立て」という文化を知らんのか。
見立てに背を向けるならば、「関数なんてものも存在しない」のだから、まずCをやめるべきだよ。「1,2,3という数字(字面)も存在しない」のだから、アセンブリ言語どころかダンプリストすら使えないよ。
見立て。計算機畑の言葉でいえば仮想化。これに背を向けたら計算機の歴史の恩恵をまるごと捨てることになるよ。
言い換えれば、この手の文句いう人は大抵、「自分がすでに恩恵受けてる仮想化については空気みたいに無料で勝手に使ってる」「まだ慣れてない仮想化については無駄
同じく某NTTの携帯電話開発に参加しているものです。(のでAC)
> 具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。> Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、> staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。>(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
えっと、実装ベースで解説しちゃうと、Active Object(CActive)は、CActiveSchedulerで管理される非同期イベントを受信するためのクラスで、これらはSymbian OSの基本かつ汎用の非同
自分もしばらく某NTTの携帯電話開発に参加してました。symbianのフレームワークはみんな一度ははまりますね。自分もしょっちゅう頭に来て「なんだよエポックってスタートレックかよ!ていうかビルド時間かかりすぎなんだよ!」とか関係ないことも毒づき(八つ当たり?)ながら開発してました。寄り道しましたが、C++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
逆なら見るけども (スコア: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がオブジェクトなんてものを認識したり解釈したりできるわけじゃない。
つまりオブジェクトというのは、オブジェクト指向言語にとって必要な存在なだけであって、
プログラムそのものにとっては本来必要なものじゃない。
その本来必要でないものがメモリを要求する、あまつさえバグを誘引するって
ところにどうにも理不尽さを感じちゃうんですよね。
>staticメソッドで実装すればいいところを通常メソッドで実装してるだけで、
単なる言語仕様に対する理解不足かと。
ああ、やっぱりこういう突込みが入ったか。
コールバックと言っても、実際のシステムにおいては本当にただ単に関数をコールするだけって事は稀で、
通常はタスク間の非同期通信機構の一部としてコールバック関数が要求される事が多いわけです。
そしてOSなりフレームワークなりの非同期通信機構がC++オブジェクトをパラメータに要求する以上は
そうせざるを得ないんですよ。
具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。
Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、
staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。
(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
某NTTの携帯電話開発に参加した時に、このActive Objectの削除に起因するバグに散々悩まされたんですよ。
それで疑問に感じたんですね。
なんでこんな本質的なじゃない部分のデバッグに散々時間をとられにゃならんのだと。
ちゃんと書けばちゃんと動くから本質的な問題じゃないよと言われても、
ちゃんと書けない奴がこんだけ居るんだったら、それはやっぱり本質的な問題だろって思っちゃうんですよね。
Re:逆なら見るけども (スコア:1)
> そしてオブジェクトの構築・削除に起因するバグがC++には
> とても多い傾向があるってのは否定しがたい事実だと思います。
> そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
未だに fscanf() で動かない、動かなくなるシステムがあるのは C言語自体が本質的にはらむ欠陥であるということですね。でも、fgets(),sscanf() という解は昔から提案されているので困るのは素人だけです。
標準ライブラリですらない「Symbian OS の Active Object」のための問題だと認識しているなら、C++ のせいにするのはヘンです。heap を使う仕様が気に入らないといっても、それは C++ の仕様ではありませんよね。
その愚痴は、そんなフレームワークを採用した企画者に矛先を向けた方が適切な気がします。
まあ、充分な予備調査をする時間がないのがそもそもの原因だと思いますが…。
Re: (スコア:0)
結局、後出しジャンケンした上に
・SymbianOSなど特定のOS、frameworkの仕様
・開発現場のスキル不足
・スキル不足を補うような開発プロセスが組まれていない
等をC++の欠点と主張しているように思えますが。
それに、本当に
> このActive Objectの削除に起因するバグに散々悩まされたんですよ。
のであれば、コードレビューやチェックリストで潰せばいいのに。
既存の成果物を使うなどで自分たちが仕様を自由に決められない場合、
OS、デバドラ、特定ライブラリなどのはまりやすいポイントなどの
チェックリスト作って、設計/コ
Re: (スコア:0)
>設計/コードレビュー
これ重要っすね。
レビューすること。
そしてその情報を共有(いまさらクチはばったいけど)すること。
あるいは時には後から気づいてしまった事柄については(社内に)フィードバックすること。
脱線になりますがペアプログラムでシゴトしたいなあ。
最高(最速だという意味で)のレビューだから。つまり不味い書き方は3秒後に発見され撲滅されるから。
またペアを時々入れ替えるってことをやれば自ずと共有やフィードバックにもなるし。
#外注との意思疎通不足で激しくデグレったのでAC
#みんなは外注の「頭が悪い」「コミュニケーション能力が悪い」と思いたいみたいだけど、
#こっちも知識の伝え方が不十分だったことを反省しないと、何度やっても同じ失敗の繰り返しだよ?
Re: (スコア:0)
>そこにオブジェクトなんてものは存在しないわけですよね、本来。
無粋な奴だな。
きみは「見立て」という文化を知らんのか。
見立てに背を向けるならば、
「関数なんてものも存在しない」のだから、
まずCをやめるべきだよ。
「1,2,3という数字(字面)も存在しない」のだから、
アセンブリ言語どころかダンプリストすら使えないよ。
見立て。計算機畑の言葉でいえば仮想化。
これに背を向けたら計算機の歴史の恩恵をまるごと捨てることになるよ。
言い換えれば、この手の文句いう人は大抵、
「自分がすでに恩恵受けてる仮想化については空気みたいに無料で勝手に使ってる」
「まだ慣れてない仮想化については無駄
Re: (スコア:0)
同じく某NTTの携帯電話開発に参加しているものです。(のでAC)
> 具体的に言うと元の投稿を書いている時にはSymbian OSのActive Objectが念頭にありました。
> Symbian OSの場合、OSのAPI自体がオブジェクトを要求するように出来てるんで、
> staticな関数わたせばいーじゃんって言われてもなかなかそうはいかんのです。
>(僕自身は別にstaticな関数でも全然いいとおもうんですけどね)
えっと、実装ベースで解説しちゃうと、Active Object(CActive)は、CActiveSchedulerで管理される
非同期イベントを受信するためのクラスで、これらはSymbian OSの基本かつ汎用の非同
Re: (スコア:0)
自分もしばらく某NTTの携帯電話開発に参加してました。
symbianのフレームワークはみんな一度ははまりますね。
自分もしょっちゅう頭に来て
「なんだよエポックってスタートレックかよ!ていうかビルド時間かかりすぎなんだよ!」
とか関係ないことも毒づき(八つ当たり?)ながら開発してました。
寄り道しましたが、C++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、
拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。