ecos は立派な組込み OS の一つですが一部 C++ で書かれています(例えば packages/services/memalloc/common/v2_0b1/src/dlmalloc.cxx)。better C (C with Classes) として使っているけれどそれでも別にいいんでは。STL 使わないとたしかに C++ の魅力は大部減るというのには同感ですが、だから C++ ではないというのは少し極端。
by
Anonymous Coward
on 2004年02月16日 20時55分
(#496892)
まあ、なんというか比較の問題なのだけど。
例えば C でサイズの大きい構造体を call by value の引数にして関数呼出しすると、スタックに大きいデータを積む関係で、実行速度は遅くなりますよね。
C で書く場合には、ほんの幾つかの点に気をつけてれば上の例のような状況を避けて実行速度の速いコードを書けるのですが、C++ で書くと、このへんの見通しが極端に悪くなるので、かなり大変なんですよ。
C++ を使って、ちゃんとカプセル化して、実行速度の速いコードを書けるってかなりの上級者ではないかな。
Mona搭載・・・ (スコア:1)
・Mona搭載PC
・Mona搭載モバイル
・Mona搭載ケイタイ
・Mona搭載PSX
＃搭載する意味があるのか分からないがID
Re:Mona搭載・・・ (スコア:3, 参考になる)
Monaは基本的にC++で開発されているので、携帯等のプアな環境には向きません。
もっとも、最近の携帯は数世代前のPDAよりも強力になってきてますが。
Re:Mona搭載・・・ (スコア:2, おもしろおかしい)
Re:Mona搭載・・・ (スコア:1)
Re:Mona搭載・・・ (スコア:2)
# そういやOpenGL/ESなんてのもあるな。
trueOne
Re:Mona搭載・・・ (スコア:2, 参考になる)
・templateの使用
コンパイラにもよると思いますが、基本的に使われうる型の組み合わせの分だけ同じようなコードが生成されるのであっという間にサイズが肥大化する傾向があります。
・例外処理機構の使用
try文の中では、例外発生時にスタック等を巻き戻すのに備えてある種のチェックコードのようなものが埋め込まれて多少実行効率が落ちる、のかな？(ちょっと自信なし)
あとはまあ、いろんな処理をクラスにラップすることで見通しはよくなるが、コードのサイズでちょっと損をするという場合は往々にしてあるように思います。
Re:Mona搭載・・・ (スコア:1)
＞・例外処理機構の使用
もうふたつほど、
・クラスでオブジェクトを渡す際に値渡しでなく参照を用いる。int１個をただ渡すだけとかまで参照にしなくてもいいんですけど、ふだんから気をつけてないとクラスのメンバーが実は数百バイトとかになってるのを平気で値渡しで書いてくる人もおられますので。
・constやstaticにすべきところは面倒でも省略しない。
このふたつがいいかげんだとすぐ肥大化します。また逆にきちんと守っているだけで劇的にコードは小さく速くなります。デバッグモードでビルドした時にはコードおよびメモリ使用量の差は歴然です。
templateについては、その中身をよく理解してから使わないと巨大になったり非効率だったりしますね。特にイテレータ関連だと、配列を直で扱うクラスで１枚ラッピングした方が良かったりしますし。もちろんあくまで時と場合によりますのでtemplateはすべてダメとか言うわけではありません。
＃C++やJavaで True,False用途でtry,catch使う人がいますが、お願いだから勘弁して！ソースが見にくいだけでなく、アセンブラレベルでも追いにくい～！！
Re:Mona搭載・・・ (スコア:1)
これってまともなC++プログラマには常識かと思ってたんですがそうでもないんでしょうか。というかC++に限らずCでもでかい構造体の値渡しは褒められたもんではないですよね。
Re:Mona搭載・・・ (スコア:1)
これがまあ利点でもあり欠点でもあるでしょうね
O(n)表記のように抽象的なレベルの見通しは良くなるが、定数項の重さが見えにくくなる。
コンストラクタ・デストラクタ・コピー・オペレータオーバーロード等々暗黙にコードが入るので、
明示的に関数呼び出しを書くのに比べて呼び出しコストを意識しなくなりがち
Cだと暗黙にコードが入るのは構造体の代入（と関数への構造体値渡し・返し）くらいだが
C++だと気をつけるところが増える。
（Cでも気をつけるべきところは気をつけんと効率が落ちるのは他の人が述べているが）
あと、一般的なスタイル的に
Cでは（記述がめんどくさいがゆえに？）メモリの動的確保は極力さける、
C++では（記述が簡単なゆえに？）多用する、といった傾向があるような
C++で実行・メモリ効率を意識しながら貧乏くさく書けばプアな環境でもいけるだろうし
Cでも富豪的に書けばだめだろ。
Re:Mona搭載・・・ (スコア:0)
本来きっちり分けて考えるべきですが
スレッド全体を見る限り、それらを合わせて考えて
C++はheavyかどうかという話になっているようですね。
こういうときは「速い」「遅い」「小さい」「大きい」
という比較が出てくるべきであり、
「軽い」「重い」という
速度のことを言っているのかサイズのことを言っているのか
分からないような表現でお茶を濁しては
せっかくの議論が無駄になると思います。
> ・templateの使用
> コンパイラにもよると思いますが、基本的に使われうる型の組み合わせの
> 分だけ同じようなコードが生成さ
Re:Mona搭載・・・ (スコア:1)
だって楽ですから。面倒な部分もないわけじゃないですが。
＃ だからかみ合わないんじゃないですかね
＞また、一般的にtemplateでサイズ肥大化するのはinlineによる影響が大きいです。
inlineは指定を無視可能ですがマクロは強制的に展開されるのでC++の方がコンパクトになりますね（嘘）
テンプレートは発想がもともと富豪的なものですし、バイナリサイズに至ってはほとんど眼中にないと言っていいと思います。
＞ちなみに携帯電話の世界ではBREW等、C++による開発が 盛んに行なわれていますし、
BREWも組み込み系っぽい香りのする自称C++コンパイラですね。
（例外は起こさないように書けるとしても）STLが使えないC++なんて何かbetter-C以上のメリットがあるんでしょうか？
ひょっとして携帯でJavaが動くと言って、OOなプログラムが書かれているとでも思っていますか？
（今のところ）組み込みはやっぱり組み込みじゃないかと思う今日この頃です。
普通のC++を使える人は、組み込み環境でC++がサポートされているからといって組み込みのエンジニアになれるわけではありませんし、組み込みでC++のコンパイラを使っていたからといって普通のC++が書けるわけではないです。
＃ 普通のC++がちゃんと書ける人ならそのうち書けるようになるでしょうが…
僕なりの結論は
普通のC++だとコードサイズは大きくなり、実行速度もやや落ちる（書き方次第ではすごく落ちる）。
組み込みのコンパイラは大体ダメダメ（吐くコード以前に解釈に問題がある）。
Re:Mona搭載・・・ (スコア:0)
> が書かれているとでも思っていますか？
jarファイル10KBまでに制限されている環境と
jarファイル256KBまでに制限されている環境とを
ひっくるめて「携帯でJava」と表現し、
それに対して
「OOなプログラムが書かれているとでも思っているのかどうか」
を議論したいのでしょうか？
Re:Mona搭載・・・ (スコア:0)
Re:Mona搭載・・・ (スコア:1)
このインタビュー [vector.co.jp]に答えがあるかも。:-)
Re:Mona搭載・・・ (スコア:0)
Re:Mona搭載・・・ (スコア:1)
と言っていますし。
以下私見。
実行環境(バイナリサイズ、メモリ量)の他にもコンパイラ側の問題もあるような気がします。
C++はコンパイラを作るのが大変なので(Cすらまともなコンパイラのない環境が多いのに…)サポートするのは無理。templateなんて言わずもがな。割とメジャーと思われるPalmでもまともにSTLが使えるような環境ではありません…。
Re:Mona搭載・・・ (スコア:1)
そう言ってカトラー氏はC++のコードをCで書き直したとか。
初代NT開発時の逸話ですから、当時とはコンパイラの最適化周り等
事情は多分に異なるでしょうが、一般PCでは気にならないことも
プアな環境では大きく響いてくることはお分かりかと思います。
私の主観ではありますが、まだ資源の限られた状況で気ままに
走らせられるとは思いません。
Re:Mona搭載・・・ (スコア:3, 参考になる)
しかし、かつて同じようにCのバイナリはあまりにも効率が悪く使いものにならないとMC68000で大量のアセンブラコードが書かれた事がありましたが、今では「gccの吐く68000コードはあまりにも効率が良く人間がいじる余地がない」という声を聞きますよね。また、かつてBe-OSは当時の環境 (今のPDAよりプアだったように思います) で高いパフォーマンスを見せていたように記憶しています。
コンパイラと設計次第だったりはしませんかね。いや、「使っちゃいけないC++の重要な機能」なんてのがあれば本質的な弱点なのでしょうけど…。
Re:Mona搭載・・・ (スコア:1, 参考になる)
例えば C でサイズの大きい構造体を call by value の引数にして関数呼出しすると、スタックに大きいデータを積む関係で、実行速度は遅くなりますよね。
C で書く場合には、ほんの幾つかの点に気をつけてれば上の例のような状況を避けて実行速度の速いコードを書けるのですが、C++ で書くと、このへんの見通しが極端に悪くなるので、かなり大変なんですよ。
C++ を使って、ちゃんとカプセル化して、実行速度の速いコードを書けるってかなりの上級者ではないかな。
同じように実行速度が必要なGUIの場合はクラスライブラリ化した方がメリットがあるから、頑張って高速化したけど、OSの場合はそこまでやるメリットがあるかどうかもポイントなんじゃないですかね。
Re:Mona搭載・・・ (スコア:1)
納得しました。高パフォーマンスは可能だけどそれなりの労力が必要って事ですね。ありがとうございます。
Re:Mona搭載・・・ (スコア:0)
・クラスメソッドで名前空間がすっきり
・関数のオーバーロードにより、同機能のAPIは同名の関数で呼び出せる
ぐらいのベターCとして使えば、
Cと比べて効率は落ちず、しかも、読みやすいものになるんじゃないかと思うんですがどう
Re:ベターC (スコア:0)
まぁMozillaはあらゆるプラットフォームの C++コンパイラを通すために使い方を厳しく取り決めているという理由もあるんですが。
Re:Mona搭載・・・ (スコア:0)
>余地がない」という声を聞きますよね。
稀にそういう話も聞きますが、大概の場合、C かアセンブリ、あるい
は両方に精通されてない場合が大概ですな。
Re:Mona搭載・・・ (スコア:0)
携帯電話用のOSであるSymbianOSはC++で書かれている [symbian.com]のだが。
Re:Mona搭載・・・ (スコア:0)
ホント?
リンク先見たけど、Symbian OSでC++が使えるって事はわかるけど、Symbian OSがC++で書かれてるとは書いてないです。
たまたまその本が手元にあったので中を見てみたけど、や