Symbian OS ネイティブの API とアプリケーションプログラミング手順を見た後だと、POSIX 上の C++ を憎んでいたはずなのに、と思います。
まず、バッファオーバーランを防ぐために Windows や GCC ランタイムが防御機構を作ったところを、オーバーランしたらパニック(例外ではなくアプリ終了)を起こす独自クラス群「ディスクリプタ」を定義して、API がディスクリプタしか引数にとらないのでバイト配列を使うとかえって苦労するようにしました。
次に、C++ コンストラクタで他の C++ オブジェクトを作ってしまった後に例外を発生させてしまった場合のクリーンアップの問題を解決するために、コンストラクタでは malloc 相当の操作のみ行い、他の C++ オブジェクト等で初期化するのはユーティリティ関数で行い、ユーティリティ関数で例外が発生したらクラス標準のデストラクタ(その中にはインスタンス変数へのデストラクタ呼び出しもあります)でクリーンアップを行う「2フェーズ コンストラクション」を慣例にしました。
むー (スコア:5, 興味深い)
VXWorksなどの有料(と言うか高価な)組込みOSでは最初からスレッド周り以外完璧に互換のPOSIX互換ライブラリが最初からあったから、最悪中間に入るミドルウェアがタコ過ぎて使いものにならなくても、UI関係以外はPOSIX互換レイヤを使って逃げるという手段があったのですが(本当はやってはいけない場合が多いのですが、納期と実機テスト工数を盾に突っ張ったことがあります ^_^;)
…SYMBIANほどのメジャーなOSが未だに独自のAPIに拘っていた方がびっくりしています。
開発者が難儀すると言うレベルではなく、(特に携帯の開発で)余りに火を吹くので、ドコモに携帯出しているNECとかが組込みLinux系に移行して移植性を向上させたり、Auのようにカーネルやらランタイムやらタイムクリティカルなドライバの部分は(基本的にQuallcomm社やKDDIが中心になって)別途用意しておいて、メーカが書くアプリ層はBREWで書かせる様にして、問題の所在を明確にさせたりするようになった。と言うのもわかるような(;´Д`)
POSIX 上の C++ にダメ出しをした API だったのに (スコア:3, 興味深い)
Symbian OS ネイティブの API とアプリケーションプログラミング手順を見た後だと、POSIX 上の C++ を憎んでいたはずなのに、と思います。
まず、バッファオーバーランを防ぐために Windows や GCC ランタイムが防御機構を作ったところを、オーバーランしたらパニック(例外ではなくアプリ終了)を起こす独自クラス群「ディスクリプタ」を定義して、API がディスクリプタしか引数にとらないのでバイト配列を使うとかえって苦労するようにしました。
次に、C++ コンストラクタで他の C++ オブジェクトを作ってしまった後に例外を発生させてしまった場合のクリーンアップの問題を解決するために、コンストラクタでは malloc 相当の操作のみ行い、他の C++ オブジェクト等で初期化するのはユーティリティ関数で行い、ユーティリティ関数で例外が発生したらクラス標準のデストラクタ(その中にはインスタンス変数へのデストラクタ呼び出しもあります)でクリーンアップを行う「2フェーズ コンストラクション」を慣例にしました。
あと、例外発生時にデストラクタを呼ぶところも、ランタイムを小さく保つために独自クラスで行いました。
互換性を取るどころか、POSIX 上の C++ にダメ出しをした API でした。
参照記事でも触れられていますが、セキュリティとメモリリークで問題があると主張していたはずの POSIX でソフトを書けるようにするのは、幅が広がるのか自らの存在意義を失うのか、問題をはらんだ賭けに思えます。
Re:POSIX 上の C++ にダメ出しをした API だったのに (スコア:0)
Re:むー (スコア:1, 興味深い)
SymbianはAPIどころか、C++を使いながらtry/catch禁止ですから。(それ自体はSymbianなりのポリシーですが、障壁でもあるわけで)
まあ、それでも以前から一般的なiTRONよりは、相当ましにANSI C相当のプログラムが動作する位の環境はありましたよ。
ちなみに、下記は誤解ではないかと。
> NECとかが組込みLinux系に移行して移植性を向上させたり
> Auのようにカーネルやらランタイムやらタイムクリティカルなドライバの部分は(基本的にQuallcomm社やKDDIが中心になって)別途用意しておいて、メーカが書くアプリ層はBREWで書かせる様にして、問題の所在を明確にさせたりするようになった。と言うのもわかるような (;´Д`)
NEC/Panasonicが組み込みlinuxに行ったのは、他社との協業を見据えてのことだと思われますが。(Symbianは、開発を委託する相手もライセンス(もち有償)を持ってないとSDKも渡せないし。(NokiaのSDKは例外))
Brewに関しても、ITメディアの記事 [itmedia.co.jp]等を見る限り、BREWというのはQualcommのベースバンドチップに標準的に乗ってくるCPUアーキテクチャであって、その上の方のOSみたいな部分とメール/ブラウザあたりが共通化されている部分がKCPというAu共通のプラットフォームで、ドライバー等の下回りはOEM層となっているので、逆に各メーカーが作りこむんじゃないかと。(Qualcommチップの関係は当然Qualcomm自身が用意しているでしょうけど)
Re:むー (スコア:0)
前半はともかく、後半は「BREWはCPUアーキテクチャ」とかいってる段階で「ハァ?」な訳だけど、ちゃんと区別付いてる?
(というよりはAPI群のような気がするが。参考記事 [itmedia.co.jp])
Re:むー (スコア:1)
KCP にアプリなんて含まれませんよ。
あるのは KCP 対応アプリ。参考として挙げてる URL の所にもちゃんと書いてあるじゃないの。
Re:むー (スコア:1)
つまらん非互換性に泣くか.その泣き所さえ理解できない廉価なエンジニアの大量投入に頼って,新たな火種を抱えるか.
APIを替えたところで,ハードウェアの制約は変わらない.組込みに求められる素養ってのは,むしろ制約に対する工学的な理解なのでは?
APIが鍵ならば,組込みLinux採用現場の生産性や最終成果物の市場支持率は,他のOSに比べて有為に高いはず.
しかし(すくなくとも現時点では)生産性の高さを誰もが認めるほどでもなく,市場支持率も特筆には当たらないようね.
POSIXはどこにでも使える万能APIセットというわけではない.
Symbianの仕様って,古めのものを斜め読みしたくらいしかない(不勉強の至り)のだけれど,直感しては
他の人が書いているとおり,危険をはらんだ賭けのような気がするよ.私は.
from もなか
Re:むー (スコア:1, 参考になる)
Symbian OSの非同期に対するデザインが他のOSのAPIにマッピング可能だとでも?
ROM化可能でバッテリ駆動という環境用のOSなんだから、OSとアプリの境界線のありかたが違うのは当然。
携帯というか(正確には彼らのターゲットはスマートフォンだけど)というのは、単に小さいPCではないのです。WindowsMobileなんかはそんな事考えていないように見えるけど。
たとえばユーザプロセスのなかで制御を手放さないままループを回し続けると、他スレッドの反応が遅くなる以外にバッテリを使い続けるという大問題があります。X なんかのプログラムではためらいなくループでイベントウェイトしているものを見ることがありますが、あんなのはバッテリ駆動向けの環境では論外です。もちろんそんなプログラムを書いた人も、非同期がきちんと扱える(かつ、各種の事象が統一して待てる)環境があればそんなバカなデザインはしないでしょう。
つまりSymbian OSにあるAPIの独自さとは、環境の違いから必要とされる機能の違いをマジメに扱った結果でしかないと思う訳です。実際Symbian OSのAPIは、環境に対する仮定を受け入れてさえしまえば非常に整合性のある体系だと思います(だから今回のPOSIX対応なんていうのは、マーケティング上の意味しかないのかなと考えています)。
付け加えておくと、POSIXはPortable Operating System Interface for UNIXの略なので、あまねくすべてのOSが実装すべき標準だと思われないのですが。
Re:むー (スコア:0, オフトピック)
開発段階で炎上現象が観測されているなら、
リチウムイオン電池が原因 [google.co.jp]じゃないということか(違
OS X互換 (スコア:0)