アカウント名:
パスワード:
C++大好きな人が「そんなCみたいなコーディングして!」とぶーたれている図ならあちこちで見られますやね。けどC大好きな人の「そのC++的発想やめてほしい」みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
> 上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに> 幽霊オブジェクトを保持していて仮想関数呼んじゃってアボーン
ってのは、本質的には言語の問題ではなくて・呼び出し先の制約条件を無視して呼び出している・不要な制約条件を呼び出し先に付与してしまっているのどちらかの設計・実装的な問題だと思います。
前者であれば、> Cならこんなこと絶対起きないですから。C++で上記のような問題引き起こしている人は、C言語でも初期化前や後処理後にコールバック呼び出して不安定な動作を引き起こすでしょ。# しかも明示的に落ちない分、見つけ出すまでの解析が大変だったりする
後者であれば、> 言語仕様の都合によって導入された部分staticメソッドで実装すればいいところを通常メソッドで実装してるだけで、単なる言語仕様に対する理解不足かと。
> Cならコールバック関数を使う場面が、C++だと仮想関数になるわけですけどってあたりが既に...
というわけで、> すごく腹が立ちます。> すごく理不尽だと思うんですよね。ってのはC++に向けるべき矛先には見えません。# やつあたり?
>本質的には言語の問題ではなくて
本質的に言語の問題じゃないというのはそうでしょうか?オブジェクト指向言語にとってオブジェクトは本質でしょ?そしてオブジェクトの構築・削除に起因するバグがC++にはとても多い傾向があるってのは否定しがたい事実だと思います。そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
プログラムってのは煎じ詰めれば機械語命令とデータの羅列でしかないわけで、そこにオブジェクトなんてものは存在しないわけですよね、本来。CPUがオブジェクトなんてものを認識したり解釈したりできるわけじゃない。つまりオブジェクトと
> そしてオブジェクトの構築・削除に起因するバグが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++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。
すみません、言ってる意味が判りません。Java ならともかく、C++ なら普通にスタックに積めるよね。RAII の観点からもそっちが良いと思うし。
デバイスを制御するクラスがnew/delteが必要だったりする場合が多くて、
new 必要? placement new で mmap IO してるってこと?
C++ はゼロオーバーヘッドルールが原則だから、C から C++ にしたところで問題にはならないと思うんだが。コールバックで十分ならそれでいいじゃん。なんで仮想関数なんか使うの?
>そうするとオブジェクトが必要になるわけですね。
個人的にC++(やJavaも)の嫌いな点なんですが、staticメソッドがstaticである、というか「仮想関数になれない」という点が嫌いです。
マイナーで恐縮ですがBorland Delphiは出来ました。staticというかクラスメソッドがvirtualになる、ということが出来ます。(コンストラクタも「仮想メソッドであるクラスメソッド」として定義する(ことができる))
同じく?組み込み屋ですが、C++も使ってます。
> オブジェクト指向で嫌なのはやたらnew/deleteを使うところですね。別にオブジェクト指向設計とnew/deleteの使用は必ずしも直結しないと思っているので、状況に合わせてオブジェクトの静的・動的生成使い分けてます。
ほとんどのケースでは静的なインスタンスを使い続けるか、起動時・終了時に動的確保・生成を行うのみで、定常状態での動的操作は不要ですね。
バッファ管理など、どうしても定常状態で獲得・解放が必要なケースでも、malloc()/free()並みの自由度が必要なケースはほとんど無いので、自前の固定長領域管理などでnew/deleteをオーバーライドして使ってます。ヒープのフラグメントも怖いですし。
なお、自分の経験上、C++実装でnew/deleteを使用するべきケースではC実装でもmalloc()/free()もしくはそれに類する動的領域管理が必要になりますので、C++だから、オブジェクト指向だから、というところでの違いをあまり感じることはありません。
確かにそういうところに気を使って実装しないC++プログラマの方もいますが、同程度に組み込みなどの特性に配慮しないCプログラマの方もおられますので、言語の問題ではなくスキルの問題なのではないでしょうか。# 先の読めない再帰処理動かしたり、巨大な構造体を引数やauto変数に置いて# スタック飛ばしたりとか、定常処理でmalloc()/free()繰り返して# ヒープフラグメント引き起こしたりとか。
>別にデバイス自体は生まれたり死んだりしねーよ
そう文句いいたくなるとしたら、それはOOPが悪いんじゃなく「OOPの使い方」が悪いんです。かっこつけた言葉でいうOO設計って奴が、うまくいってないのね。
* デバイスじゃなく「デバイスの身代わり」「デバイスへのアクセス手段」を産んだり殺したりする、のだと捉えてください。 ** 古典的に言い換えればハンドルですよ。 ** かっこつけた言葉では「プロキシ(パターン)」と呼んだりします。
* そして、その捉え方に基づいて設計してください。 ** 設計というのは、そういうのを念頭に
より多くのコメントがこの議論にあるかもしれませんが、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言語でも
初期化前や後処理後にコールバック呼び出して不安定な動作を引き起こすでしょ。
# しかも明示的に落ちない分、見つけ出すまでの解析が大変だったりする
後者であれば、
> 言語仕様の都合によって導入された部分
staticメソッドで実装すればいいところを通常メソッドで実装してるだけで、
単なる言語仕様に対する理解不足かと。
> Cならコールバック関数を使う場面が、C++だと仮想関数になるわけですけど
ってあたりが既に...
というわけで、
> すごく腹が立ちます。
> すごく理不尽だと思うんですよね。
ってのはC++に向けるべき矛先には見えません。
# やつあたり?
Re: (スコア:0)
>本質的には言語の問題ではなくて
本質的に言語の問題じゃないというのはそうでしょうか?
オブジェクト指向言語にとってオブジェクトは本質でしょ?
そしてオブジェクトの構築・削除に起因するバグがC++には
とても多い傾向があるってのは否定しがたい事実だと思います。
そうであるならばそれは言語自体が本質的にはらむ欠陥なんじゃないでしょうか。
プログラムってのは煎じ詰めれば機械語命令とデータの羅列でしかないわけで、
そこにオブジェクトなんてものは存在しないわけですよね、本来。
CPUがオブジェクトなんてものを認識したり解釈したりできるわけじゃない。
つまりオブジェクトと
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++はこんなフレームワークも許すような自由度が高すぎること自体が言語的な欠点、
拡張を繰り返しているせいで可読性も低いと思います。そのせいでメモリリーク、破壊関連のバグが全く減らない。
Re: (スコア:0)
すみません、言ってる意味が判りません。Java ならともかく、C++ なら普通にスタックに積めるよね。RAII の観点からもそっちが良いと思うし。
new 必要? placement new で mmap IO してるってこと?
C++ はゼロオーバーヘッドルールが原則だから、C から C++ にしたところで問題にはならないと思うんだが。
コールバックで十分ならそれでいいじゃん。なんで仮想関数なんか使うの?
Re: (スコア:0)
>そうするとオブジェクトが必要になるわけですね。
個人的にC++(やJavaも)の嫌いな点なんですが、
staticメソッドがstaticである、というか「仮想関数になれない」という点が嫌いです。
マイナーで恐縮ですがBorland Delphiは出来ました。
staticというかクラスメソッドがvirtualになる、ということが出来ます。
(コンストラクタも「仮想メソッドであるクラスメソッド」として定義する(ことができる))
Re: (スコア:0)
> 仮想関数呼んじゃってアボーン、というバグに遭遇することがとっても多くて、これもすごく腹が立ちます。
上位・下位って何ですか?
オブジェクトを保持ってどういうこと?
一部でしか通用しないローカル用語が意味不明だが、設計が悪いんじゃないの?
そういう腐った設計をやる人にはC++を使う資格はないと思う。
Re:逆なら見るけども (スコア:2, 興味深い)
同じく?組み込み屋ですが、C++も使ってます。
> オブジェクト指向で嫌なのはやたらnew/deleteを使うところですね。
別にオブジェクト指向設計とnew/deleteの使用は必ずしも直結しないと思っているので、
状況に合わせてオブジェクトの静的・動的生成使い分けてます。
ほとんどのケースでは静的なインスタンスを使い続けるか、
起動時・終了時に動的確保・生成を行うのみで、定常状態での動的操作は不要ですね。
バッファ管理など、どうしても定常状態で獲得・解放が必要なケースでも、
malloc()/free()並みの自由度が必要なケースはほとんど無いので、
自前の固定長領域管理などでnew/deleteをオーバーライドして使ってます。
ヒープのフラグメントも怖いですし。
なお、自分の経験上、C++実装でnew/deleteを使用するべきケースでは
C実装でもmalloc()/free()もしくはそれに類する動的領域管理が
必要になりますので、C++だから、オブジェクト指向だから、
というところでの違いをあまり感じることはありません。
確かにそういうところに気を使って実装しないC++プログラマの方もいますが、
同程度に組み込みなどの特性に配慮しないCプログラマの方もおられますので、
言語の問題ではなくスキルの問題なのではないでしょうか。
# 先の読めない再帰処理動かしたり、巨大な構造体を引数やauto変数に置いて
# スタック飛ばしたりとか、定常処理でmalloc()/free()繰り返して
# ヒープフラグメント引き起こしたりとか。
Re: (スコア:0)
>別にデバイス自体は生まれたり死んだりしねーよ
そう文句いいたくなるとしたら、それはOOPが悪いんじゃなく「OOPの使い方」が悪いんです。
かっこつけた言葉でいうOO設計って奴が、うまくいってないのね。
* デバイスじゃなく「デバイスの身代わり」「デバイスへのアクセス手段」を産んだり殺したりする、のだと捉えてください。
** 古典的に言い換えればハンドルですよ。
** かっこつけた言葉では「プロキシ(パターン)」と呼んだりします。
* そして、その捉え方に基づいて設計してください。
** 設計というのは、そういうのを念頭に