Symbian OS ネイティブの API とアプリケーションプログラミング手順を見た後だと、POSIX 上の C++ を憎んでいたはずなのに、と思います。
まず、バッファオーバーランを防ぐために Windows や GCC ランタイムが防御機構を作ったところを、オーバーランしたらパニック(例外ではなくアプリ終了)を起こす独自クラス群「ディスクリプタ」を定義して、API がディスクリプタしか引数にとらないのでバイト配列を使うとかえって苦労するようにしました。
次に、C++ コンストラクタで他の C++ オブジェクトを作ってしまった後に例外を発生させてしまった場合のクリーンアップの問題を解決するために、コンストラクタでは malloc 相当の操作のみ行い、他の C++ オブジェクト等で初期化するのはユーティリティ関数で行い、ユーティリティ関数で例外が発生したらクラス標準のデストラクタ(その中にはインスタンス変数へのデストラクタ呼び出しもあります)でクリーンアップを行う「2フェーズ コンストラクション」を慣例にしました。
むー (スコア:5, 興味深い)
VXWorksなどの有料(と言うか高価な)組込みOSでは最初か
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)