アカウント名:
パスワード:
C++大好きな人が「そんなCみたいなコーディングして!」とぶーたれている図ならあちこちで見られますやね。けどC大好きな人の「そのC++的発想やめてほしい」みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
C的発想で作ったプログラムはC++コンパイラでコンパイルできるけど、C++的発想はそもそもC言語の 文法ないで書きあらわあせないので 「そのC++的発想やめてほしい」なんて発言が出ないのでは?
CとC++はというかJAVAも、ミクロなコーディングはほぼ同じ。式、文、複文、ブロック、for文、while文、といったレベルね。 だからといってCとC++を一緒にするのは、A-Zを使ってるから英語とローマ字(表記の日本語)は同じ言語と言うようなもの。
CとC++は何が違うといって、(大きな)プログラムを組み上げるときの方法論が全然違うと思うのですわ。 あと、 CにはSTLは無いので、自分で作る/標準のものを持ってくるの境目の粒度も違う。
なんというかなぁ、法隆寺とまではいわないけど伝統的日本建築とツーバイフォーの家を「どっちも木造」と言っちゃう気持ち悪さ? 木から材木を切り出すところまで大工の視野に入っている(視野に言ってなければ仕事にならない)世界と、出来合いの部材を組み立てる世界。 いや、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設計って奴が、うまくいってないのね。
* デバイスじゃなく「デバイスの身代わり」「デバイスへのアクセス手段」を産んだり殺したりする、のだと捉えてください。 ** 古典的に言い換えればハンドルですよ。 ** かっこつけた言葉では「プロキシ(パターン)」と呼んだりします。
* そして、その捉え方に基づいて設計してください。 ** 設計というのは、そういうのを念頭に
C++のシンボルのname manglingは実装依存でコンパイラのベンダーによってバラバラ。Windowsだとvtable絡みでMicrosoftが特許とってるらしくてC++ ABIをMSVC++互換にはできないっぽい。LinuxのC++ ABIはGNU libstdc++のそれに標準化してたと思うけど、そもそもlibstdc++自体がABI安定してないからなあ。ていうかscim-bridgeが作られたきっかけはABI問題だし、iBusがCで書かれている理由もそれを嫌ってるからだし。
まあOSのコアAPIはCで書くのが無難だよなあ。
LinuxのC++ ABIはGNU libstdc++のそれに標準化してたと思うけど、そもそもlibstdc++自体がABI安定してないからなあ。
ABIが何かを理解していますか?GCCのC++ ABIは何度か変更がありましたが、そのことですよね。
つーか、その2つはセットで考えるべきでしょ。
ABIと言うからにはしっかり区別すべき。ライブラリが規程するのはAPIであってABIではありません。
なんだ、ただの知ったか君か。C/C++のライブラリなんざ注意を払わずに変更を加えた日にゃ簡単にABIが壊れるよ。コンパイラだけの問題じゃない。
C/C++のライブラリなんざ注意を払わずに変更を加えた日にゃ簡単にABIが壊れるよ
では具体例にどうABIを壊すのかを例示してください。そのような変更は、普通APIの互換性を崩す変更と呼ぶと思いますが。
構造体のサイズやレイアウトを変えるとか。
それはAPIの変更であってABIとは関係ないです。あるAPIに含まれる構造体のレイアウトを変更したら、通常はAPIのバージョンを上げて非互換を明示しますが、そんな基本的なことも知らないのですか?
ABIとは、例えばIA-64 C++ ABI [codesourcery.com]で定義されているようなもっと基本的な部分での話です。
>それはAPIの変更であってABIとは関係ないです。
ABIの変更だと言ってるようですが [mit.edu]。
何でか知らんけど、おまいがABIを極めて限定的な範囲で捉えていることと、ソース互換とバイナリ互換の区別がつかないことだけはよくわかった。
ABI incompatible (assuming the struct's size/layout is part of the ABI)
とわざわざ断っているのは、そう思わない人がいるからでしょ?まあABIを随分と広く解釈してバイナリ互換=ABI互換と言う人がいるのは分かりましたが、この場合のABIってコンパイラが作ったバイナリそのものを言うわけですよね?
私は、ABIと言うからにはAPIと同等に明示的に定義されたものである必要があると考えています。
fat にすりゃあ良いってモノじゃあ無い。てのが C 使う理由ですかね。
継承されまくったクラスの無駄な巨大さにはいつも閉口しますが見てみぬふりしてます
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
逆なら見るけども (スコア:0)
C++大好きな人が
「そんなCみたいなコーディングして!」
とぶーたれている図ならあちこちで見られますやね。
けどC大好きな人の
「そのC++的発想やめてほしい」
みたいに言う図って想像できないんだ。
Cラブな人の誇りって、どのへんに宿るんだろう。
C++ is a horrible language (スコア:1)
gitがなぜC++で書かれていないのか、と言った人のコメントに対し *YOU* are full of bullshit. とも・・・
AVG anti-virus data base out of date
Re:逆なら見るけども (スコア:1)
C的発想で作ったプログラムはC++コンパイラでコンパイルできるけど、C++的発想はそもそもC言語の 文法ないで書きあらわあせないので 「そのC++的発想やめてほしい」なんて発言が出ないのでは?
CとC++はというかJAVAも、ミクロなコーディングはほぼ同じ。式、文、複文、ブロック、for文、while文、といったレベルね。 だからといってCとC++を一緒にするのは、A-Zを使ってるから英語とローマ字(表記の日本語)は同じ言語と言うようなもの。
CとC++は何が違うといって、(大きな)プログラムを組み上げるときの方法論が全然違うと思うのですわ。 あと、 CにはSTLは無いので、自分で作る/標準のものを持ってくるの境目の粒度も違う。
なんというかなぁ、法隆寺とまではいわないけど伝統的日本建築とツーバイフォーの家を「どっちも木造」と言っちゃう気持ち悪さ? 木から材木を切り出すところまで大工の視野に入っている(視野に言ってなければ仕事にならない)世界と、出来合いの部材を組み立てる世界。 いや、C++は本を読んだだけなんで、C++ができる人の発言を読み聞きした印象なんですけどね。
Re:逆なら見るけども (スコア:3, すばらしい洞察)
Re: (スコア:0)
違いなんて相対的なもの。
の三つのうち似たもののペアを取り出してみ。伝統的日本建築とツーバイフォーの家を「どっちも木造建築」だからペアにするでしょ。
Re: (スコア:0)
C++も年寄りが使う言語になりつつあるよ。
「C++嫌いだから年寄り」みたいな硬直した考え方してるひとは、
すぐにロートルと後ろ指指されちゃう人に成り下がります。
というかあなたもうそう呼ばれているでしょ。
Re: (スコア:0)
このような硬直的な考え方をするあなたも同じ穴の狢ですね。
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設計って奴が、うまくいってないのね。
* デバイスじゃなく「デバイスの身代わり」「デバイスへのアクセス手段」を産んだり殺したりする、のだと捉えてください。
** 古典的に言い換えればハンドルですよ。
** かっこつけた言葉では「プロキシ(パターン)」と呼んだりします。
* そして、その捉え方に基づいて設計してください。
** 設計というのは、そういうのを念頭に
思う事と口に出すことの違い (スコア:0)
私は新しいものについていけなくなった人です、って自分から
白状してるみたいなので言えない、と言う面もあるのでは。
それを乗り越えてCラブな人の誇りは、多分CPUのアーキテクチャ
に宿ります。インラインアセンブラ万歳!
Re: (スコア:0)
C++のシンボルのname manglingは実装依存でコンパイラのベンダーによってバラバラ。Windowsだとvtable絡みでMicrosoftが特許とってるらしくてC++ ABIをMSVC++互換にはできないっぽい。LinuxのC++ ABIはGNU libstdc++のそれに標準化してたと思うけど、そもそもlibstdc++自体がABI安定してないからなあ。ていうかscim-bridgeが作られたきっかけはABI問題だし、iBusがCで書かれている理由もそれを嫌ってるからだし。
まあOSのコアAPIはCで書くのが無難だよなあ。
Re:逆なら見るけども (スコア:1)
ABIが何かを理解していますか?GCCのC++ ABIは何度か変更がありましたが、そのことですよね。
Re: (スコア:0)
つーか、その2つはセットで考えるべきでしょ。
Re:逆なら見るけども (スコア:1)
ABIと言うからにはしっかり区別すべき。ライブラリが規程するのはAPIであってABIではありません。
Re: (スコア:0)
なんだ、ただの知ったか君か。
C/C++のライブラリなんざ注意を払わずに変更を加えた日にゃ簡単にABIが壊れるよ。
コンパイラだけの問題じゃない。
Re:逆なら見るけども (スコア:1)
では具体例にどうABIを壊すのかを例示してください。
そのような変更は、普通APIの互換性を崩す変更と呼ぶと思いますが。
Re: (スコア:0)
Re: (スコア:0)
構造体のサイズやレイアウトを変えるとか。
Re:逆なら見るけども (スコア:1)
それはAPIの変更であってABIとは関係ないです。あるAPIに含まれる構造体のレイアウトを変更したら、通常はAPIのバージョンを上げて非互換を明示しますが、そんな基本的なことも知らないのですか?
ABIとは、例えばIA-64 C++ ABI [codesourcery.com]で定義されているようなもっと基本的な部分での話です。
Re: (スコア:0)
>それはAPIの変更であってABIとは関係ないです。
ABIの変更だと言ってるようですが [mit.edu]。
Re: (スコア:0)
何でか知らんけど、おまいがABIを極めて限定的な範囲で捉えていることと、ソース互換とバイナリ互換の区別がつかないことだけはよくわかった。
Re:逆なら見るけども (スコア:1)
とわざわざ断っているのは、そう思わない人がいるからでしょ?
まあABIを随分と広く解釈してバイナリ互換=ABI互換と言う人がいるのは分かりましたが、この場合のABIってコンパイラが作ったバイナリそのものを言うわけですよね?
私は、ABIと言うからにはAPIと同等に明示的に定義されたものである必要があると考えています。
Re: (スコア:0)
fat にすりゃあ良いってモノじゃあ無い。
てのが C 使う理由ですかね。
Re: (スコア:0)
継承されまくったクラスの無駄な巨大さには
いつも閉口しますが見てみぬふりしてます