C言語でオブジェクト指向
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG0002デフォルトの名無しさん
NGNG実現できない機能も多いがな。
0003デフォルトの名無しさん
NGNGVFS とか Xaw とか？ すでに C++ がある状況で、いまさらやる必要は全くないと
思うが。
0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNG特集 オブジェクト指向の実装技法入門
第4章 多態や隠蔽の実装を解説
オブジェクトやクラスをC言語で表現する
第5章 多重度のちがいによって実装手法が変わる
Cによる関連の実装
第6章 クラス，オブジェクト，多態などを使った
Cによる例外の実装例
0008デフォルトの名無しさん
NGNGC++が使える状況ならC++使え、C++が使えないといったら組み込み分野くらいだ
しかし考えてみると組み込みの仕事は未だに非OOP主流なのか？
0009デフォルトの名無しさん
NGNG組み込みUMLeUMLによるオブジェクト指向組み込みシステム開発
著： 渡辺博之 / 渡辺政彦 / 堀松和人 / 渡守武和記
第8章4 C言語のためのアーキテクチャメカニズム
0010デフォルトの名無しさん
NGNG組み込みといっても範囲が広い。SH4やARM9ベースであるならばC++を
使わない理由はあまり無い。逆にK4やTL9000、H8等を使用するならば
OOA、OODはともかくとしてOOPにするメリットはあまり無い。
>>7,>>9の文献のコードを見ても保守性が良いとは言えないしね。
4bitマイコン応用商品ならば現在でもアセンブラが当たり前。
0011デフォルトの名無しさん
NGNGうちはM32RでCの仕事だけど、C++があったらなぁといつも思っている
0012デフォルトの名無しさん
NGNGいや、それでもC++を使いたくないな。
0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG0015デフォルトの名無しさん
NGNG「オブジェクト指向」ってJavaそっくりなものとか考えてる？
だとすれば相当非現実的なことしないと実現できないだろうけど
「オブジェクト指向」という考え方をCを使って表現することは普通にできるよ
0016デフォルトの名無しさん
NGNG俺、H8でもC++使ったよ。
どうせC言語で書いてもOOP的なコードになるしさ。
0017デフォルトの名無しさん
NGNGソースきぼん
0018デフォルトの名無しさん
NGNG今はH8でもまともなC++コンパイラがあるようだね。チョット前使ってた時はEC++
しかなくて、これならいらんわな、と思っていたよ。
H8で使えるフレームワークがあれば、デメリット考えても選択する価値があるね。
とはいえ16bitCPUのC++って相当な言語外のルールを設けなくては酷い事に
ならない？一般に8/16bitCPUをコンシューマで使用する意図はローコストにある。
現状のOOPはCより大きなROM/RAMと高速なクロックを必要とする。この要求に
応えられるのならばワンランク上のCPUを選択しても良さそうなものだと思うけど…
インスタンスのROM化だとか、仮想関数を使用しないだとかを考えながら設計する
くらいならCでコーディングした方が幸せになれると思うよ。
スレ違なのでこの辺で。
0019デフォルトの名無しさん
NGNGちゃんと設計正しくやればC++で書いてもパフォーマンスの低下は
せいぜい1〜5％程度よ。
ほんの数％でもいいから性能向上させたいならアセンブラ使え。
大体さ、C言語で書いてても、結局OOP的なコード書くなら
効率はC++と全く変わらん。
むしろ、書くのが楽な分、C++の方が手動での最適化かけやすい。
0020デフォルトの名無しさん
NGNG全く変わらん、は言い過ぎ。
一般的な C++ の実装だと、仮想関数呼び出しは vtbl -> vptr と二つの間接参照
が入るが、C でベタに実装する場合には
1. オブジェクトのサイズは増えるが、代わりに間接参照を一つにする
（あるいは switch - case を使う)
2. C++ と同じ方法を使う
といったトレードオフを、プログラマの側でコントロールできる。
自由度が増える分だけ手間が増えるし、後で仕様変更しようとかリファクタリング
しようと思った時に大変になるから、中長期的に見るとホントにメリットがあるかは
何とも言えんが。
0021デフォルトの名無しさん
NGNGC++を使ったときのメリットよりもデメリットの方が大きいし
パフォーマンス云々よりもむしろROMもRAMも小さくしたいし
3068より3067の方が安いし3052はもっと安いんだから
チープな言語に正義があると信じてるし。
0022デフォルトの名無しさん
NGNG> C++を使ったときのメリットよりもデメリットの方が大きいし
「C++ を使う」って意味が、ハッキリしないけど。
それこそ例外や iostream までフルに使うのか、EC++ のレベルで使うのかで
ぜんぜん話が違うっしょ。
0023デフォルトの名無しさん
NGNGだったら、アセンブラ使えば ?
0024デフォルトの名無しさん
NGNGC++に限らずOOP言語は重い・遅い・高価と言う事は事実。もしこれらを回避している
としたら市販のクラスライブラリを使用せず、言語外のルールを用いてC++の機能を
制限して使用していると考えられる。C++は多機能だし、実際使える機能はルール
無くば必ず使用される事になる。この辺がC++導入の難しい所だといえる。
実際プアなリソース（特にRAM）しか持たないCPUでC++を使用する場合、inlineや
staticの多用、仮想関数やRTTIの使用の回避、クラス数を最小にする工夫、等を
考慮しなければならない訳だが、これはOOPの目指す所とは真逆でデザインパターンの
実装も素直には行かない。heap領域のフラグメント化の問題もかなり深刻になる。
これらの問題を回避する為に500KByte程度のheap領域を奢る事ができるのならば、
H8を使用しているシステム設計は間違っているとしか言いようが無い。50円100円の差で
CPUのリプレースが検討される分野だけにOOPを使用するには根拠が居る。
OOPの使用を考えるのならば、もっと根本的な意識改革が必要。結局一番高いのは
人件費であり、OOPを用いれば開発費を下げる事が可能になり、結局は利がある
というような環境にすると良いかもね。
0025デフォルトの名無しさん
NGNGStroustrup が C++ の設計方針として...
「C 以上の時間とスペースに関するオーバーヘッドは、C++ では受け入れられないと思われる。」
と言ってんだけど。
0027デフォルトの名無しさん
NGNGheap の断片化というが、そもそもメモリが厳しい環境で動かす場合には
「必要な領域を用途毎に固定サイズで割り振ってしまい、それを static
にとって使い回す」のが常套手段だよね。
それなら operator new をオーバーロードして、事前に固定長で用意した
static 領域から確保するか、もしくは固定長の領域上で placement new
すれば良いだけ。
クラス数とメモリサイズの相関は、良く分からんなぁ。どうせ実行ファイル
にはシンボル名は残らんわけで、せいぜい vtbl と RTTI 関連の情報が
増えるぐらいじゃないの？ RTTI はたいていオプションで切り落とせるし、
そもそも RTTI に依存するのは OO 的にもマズイ設計だし。
仮想関数の使用に関して注意を払う必要があるのは、その通り。ただし
本当に仮想関数が必要な部分は、どうせ C で書いても switch - case
か関数ポインタの配列になるから、メリットないでしょ。
0028デフォルトの名無しさん
NGNGいや、Cで関数ポインタテーブル使うのと、C++で仮想関数使うんだったら効率はほぼ一緒。
switch-case は条件の数が多くなるとかえって効率悪い。
だいたい、C++だからといって即仮想関数呼び出しになるとは限らんだろ。
継承の予定のないメソッドは非バーチャルにすればいいし、
仮想関数でも、静的に型が特定できる場合は通常の関数呼び出しになる。
0029デフォルトの名無しさん
NGNG何でもかんでもOOPにするから重くなるんだって。
逆に、何でもかんでも非OOPで書くってのもどうかと思うし。
リスト処理とか、明らかにOOPで書いた方がいいし。
あと、C++非OOPな部分だけでも十分使用する価値あると思うぞ。
関数のオーバーロードとか // コメントとか inline とか。
↑
実際、// コメントは最近はCでも使えるようになってるし、
inline とかもコンパイラの独自拡張機能として使えるし。
0030デフォルトの名無しさん
NGNG> リスト処理とか、明らかにOOPで書いた方がいいし。
それはむしろ Generics 向きのような…
テンプレートはコードサイズ増大の可能性がある（しかもコンパイルオプションで
制御しづらい）から、リソース厳しい場合には扱い注意だけど。
0031デフォルトの名無しさん
NGNGいや、リストとかはオブジェクトなわけで、OOPの範疇だろ。
もちろん、Genericsあった方がいいけど。
あと、テンプレートのコードサイズ増加の問題は、
void* 使ったリスト書いて、値の読み出し時のキャストだけtemplate化することで避けれる。
Effective C++ かなんかに載ってたはず。
0032デフォルトの名無しさん
NGNG> いや、リストとかはオブジェクトなわけで、OOPの範疇だろ。
俺は OO 一歩手前の抽象データ型だと思うけどな。
OO は継承や関連をはじめとした「オブジェクト間の関係」に注目するパラダイムで、
単なるデータ隠蔽だけでは不十分だと認識してる。
（まー所詮は言葉の定義の問題だから、実態を把握してればどっちでも良いけど）
0033デフォルトの名無しさん
NGNGH8を使ったOOPという条件を除けば、反論の余地は有れど、同意。
しかし、H8がローコストなワンチップマイコンである事がメリットという事を
無視してないか？16KByte程度のRAMでOOPやるくらいだったらCで非OOPする方が
楽よ、と言う事。ケースバイケースだと言う事は認めるけれどね。
MCPを追加する位なら台湾ハブメーカーを使って、ARM7TDMIあたりをコアにした
ASICをおこした方がコストメリットがでるだろうに。
しかしながら、「それでもH8でC++を使用する事になったけれどどうすれば良いか？」
という議論はしても良いと思う。(>>29のスタンスはまさにこれだね。)
やってみれば判る事だが、operator new をオーバーロードして固定長メモリを
割り振るのは次善の策。普通はnew演算子やdelete演算子が内部でmallocとfreeを
callしている事を利用してmallocとfreeを書き換える。malloc内部ではRTOSの機能を
利用してタスク空間毎に割り振るheap領域を切り替える。これなら普通にnewできる。
使用する側は、newしたのと逆順にdeleteするようにシーケンスを考慮して
コーディングする。手間は増えるが、オーバーヘッドは最小になる。
>クラス数とメモリサイズの相関は、良く分からんなぁ。
インスタンスが何処に生成されるかを考えれば自明だと思うが…
プアな環境下でOOPやる場合、同時に生成されるインスタンスが占めるメモリが必ず
確保可能でなければならない。なら、クラスを増やしたり、メンバを増やす事は不利に
働く事になる。インスタンスはROM化したり、autoに確保する等、考慮しなくてはならない事はかなり多い。だから言語仕様外のルールが必要だと主張しているんだが…
0034デフォルトの名無しさん
NGNG確かに継承とかまで出来ないとOOPじゃないけど、
OOPの全機能使わないとプログラムかけないわけでもないでしょ。
抽象データ型はOOP言語使ったほうが表現しやすいってのは確かかと。
■ このスレッドは過去ログ倉庫に格納されています