アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
Mona搭載・・・ (スコア:1)
・Mona搭載PC
・Mona搭載モバイル
・Mona搭載ケイタイ
・Mona搭載PSX
#搭載する意味があるのか分からないがID
Re:Mona搭載・・・ (スコア:3, 参考になる)
Monaは基本的にC++で開発されているので、携帯等のプアな環境には向きません。
もっとも、最近の携帯は数世代前のPDAよりも強力になってきてますが。
Re:Mona搭載・・・ (スコア:1)
Re:Mona搭載・・・ (スコア:2, 参考になる)
・templateの使用
コンパイラにもよると思いますが、基本的に使われうる型の組み合わせの分だけ同じようなコードが生成されるのであっという間にサイズが肥大化する傾向があります。
・例外処理機構の使用
try文の中では、例外発生時にスタック等を巻き戻すのに備えてある種のチェックコードのようなものが埋め込まれて多少実行効率が落ちる、のかな?(ちょっと自信なし)
あとはまあ、いろんな処理をクラスにラップすることで見通しはよくなるが、コードのサイズでちょっと損をするという場合は往々にしてあるように思います。
Re:Mona搭載・・・ (スコア:1)
>・例外処理機構の使用
もうふたつほど、
・クラスでオブジェクトを渡す際に値渡しでなく参照を用いる。int1個をただ渡すだけとかまで参照にしなくてもいいんですけど、ふだんから気をつけてないとクラスのメンバーが実は数百バイトとかになってるのを平気で値渡しで書いてくる人もおられますので。
・constやstaticにすべきところは面倒でも省略しない。
このふたつがいいかげんだとすぐ肥大化します。また逆にきちんと守っているだけで劇的にコードは小さく速くなります。デバッグモードでビルドした時にはコードおよびメモリ使用量の差は歴然です。
templateについては、その中身をよく理解してから使わないと巨大になったり非効率だったりしますね。特にイテレータ関連だと、配列を直で扱うクラスで1枚ラッピングした方が良かったりしますし。もちろんあくまで時と場合によりますので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)