サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
www.kijineko.co.jp
Account Suspended This Account Has Been Suspended
ごく普通のナル終端文字列 "123" を整数値の 123 に変換するとき、あなたはどんな方法を用いるでしょうか？ 学校の課題でもないかぎり、1文字ずつ取り出して数字かどうかを判別し、数字なら取り出した文字から '0' を引いた値を元の値に 10 倍したものに加えていく...といった処理をわざわざ書くことはないでしょう（組込み用途のフリースタンディング処理系やライブラリ自体の開発の場合は別ですが）。 上記のような変換を行う場合、atoi 関数を使っていることが少なくないと思います。しかし、本当にそれでよいのでしょうか？ atoi というのは、元の文字列が正しい書式で、しかもオーバーフローが起きない場合にのみ正しく動作します。そうでない場合、エラー検出を行うことがまったくできません。特に、オーバーフロー発生時には未定義の動作を引き起こします。こんな危険な関数を使ってよいはずがありません。 この
よく見かけるコードですが、上のコードは、必ずしも期待した結果になるとは限りません。なぜなら、double 型やポインタ型は、これらを構成する全ビットが 0 になったとしても、オブジェクトの値が 0 になるかどうかは分からないからです。 確かに、ほとんどの処理系では上記のコードでも問題なく、そして期待通りに動作します。しかし、それはあくまでも"たまたま"動いているに過ぎません。そうした不安定な要素をなくすために行った初期化が、かえってコードを怪しくしてしまっているのです。 単に、集成体の全要素をゼロクリアしたいだけであれば、 とすれば十分です。こう書くと、おそらく次のような反論が返ってくることでしょう。「その方法では、構造体の詰め物がゼロクリアされない」と。しかし、構造体の詰め物にアクセスして、言語仕様上保証される結果を期待することには無理があります。 構造体の詰め物をゼロクリアしたい理由は
株式会社きじねこは大阪のソフトウェア開発会社です。組込み系・業務系のプログラム開発から電子回路の設計までおまかせください。 大抵の C/C++ の入門書の最初の方には、変数名や関数名などの識別子に使える文字として、アルファベットの大文字・小文字、数字、下線（アンダースコア、アンダーバー）だけが使えると書いていると思います。確かに以前の C の規格はそうでしたし、標準化前の C++ でもそうでした。しかし、現在の C/C++ の標準規格はそうはなっていません。 例えば C の場合、識別子の構文は次のようになっています。 identifier: identifier-nondigit identifier identifier-nondigit identifier digit identifier-nondigit: nondigit universal-character-name oth
株式会社きじねこは大阪のソフトウェア開発会社です。組込み系・業務系のプログラム開発から電子回路の設計までおまかせください。 今回のタイトルはやや分かりにくいかもしれません。「非局所オブジェクト」というのは、関数の外で宣言したオブジェクトのことです。いわゆる「グローバル変数」とほぼ同じと考えてください。 さて、関数の外で宣言された「非局所オブジェクト」ですが、static 記憶クラス指定子が付いていれば内部結合になることはいうまでもありません。今回話題にするのは、記憶クラス指定子が付いていないデフォルトの状態での結合がどうなるかです。 結論からいうと、非局所オブジェクトが外部結合になるか内部結合になるかは、C と C++ では異なります。これは、C と C++ の間の重要な非互換性のひとつです。 まず、C の場合には、明示的に static 記憶クラス指定子を付けない限り、非局所オブジェクト
スマートポインタ boost::shared_ptr は非常に便利であり、おそらく Boost C++ Libraries の中でもっとも多く使われている機能のひとつです。boost::shared_ptr は、普通は何も考えずにデフォルトのまま使っていても問題はないのですが、いざ効率のことを考え始めると、問題点が浮き上がってきます。 shared_ptr はスレッドセーフな設計がされており、参照カウンタの増減の際は当然排他制御が行われます。排他制御を行うかどうかは、Boost.Config で決定するわけですが、Visual C++ 2005 のようにシングルスレッドをサポートしない処理系では、常に排他制御が行われることになります。 しかし、現実には、シングルスレッドで十分なアプリケーションも多数ありますし、仮にマルチスレッドであったとしても、shared_ptr をスレッド間で共有する
C の場合、コンパイラが出力したオブジェクトファイルを逆アセンブルするか、コンパイラが出力したアセンブリ言語のソースを見ると、C のソースで書いた関数名などの識別子が、ほぼそのままラベルになっていることが分かります。処理系によっては、元の識別子の前に、アンダスコアなどの記号が付く場合もありますが、ほぼ元のままの名前がラベルになっているはずです。 一方、C++ の場合はどうかというと、必ずしもそんな単純なことにはなっていません。具体例を挙げた方が話が早いでしょう。 という C++ のコードを GCC でコンパイルすると、関数の入り口に相当するラベルは、__Z4funcv という名前になります。この名前の中ほどに、func という文字列は見つかりますが、C の場合に比べれば、かなり大掛かりに変形されています。 C の場合とは異なり、C++ では、同じ名前を持つ関数が複数存在することになります。
株式会社きじねこは大阪のソフトウェア開発会社です。組込み系・業務系のプログラム開発から電子回路の設計までおまかせください。 比較的有名なサイトで「コンストラクタからの例外送出」が「禁じ手」として紹介されていることもあり、また、最近ではその内容を再編集した書籍が出版されたこともあって、コンストラクタから例外を送出すべきではないと考える人は多いようです。 その根拠となっているのは、コンストラクタから例外を送出した場合、デストラクタが呼ばれないためにリソースリークにつながるというものです。これは、次のようなケースを想定しているものと思われます。 foo::foo() : a(new A), b(new B) { } 確かに、a または b のうち、後から初期化される側で例外が送出されると、他方が解放される機会が失われるため、リークにつながります。しかし、 void foo() { A* a =
Boost C++ Libraries を使っていると、意味不明の警告やエラーに遭遇することがあります。lexical_cast もそのひとつです。比較的よく使うライブラリなだけに厄介なのですが、まずはその原因から探ってみることにしましょう。 Visual C++ 2005 で <boost/lexical_cast.hpp> をインクルードすると、 warning C4819: ファイルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を防ぐために、ファイルを Unicode 形式で保存してください。 という警告が出ます。また、GCCで -finput-charset=cp932 などのオプションを付けてコンパイルしようとすると、 failure to convert cp932 to UTF-8 というエラーが発生してしまいます。いずれも、エラーや警告
Boost C++ Librariesに含まれるライブラリ要素の多くは、単にヘッダファイルをインクルードするだけで使用することができます。しかし、いくつかのライブラリ要素はライブラリをリンクしなければなりません。比較的よく利用する正規表現やファイルシステム関連もライブラリのリンクが必要です。 使用している処理系がVisual C++であれば、#pragma comment指令を用いて自動的にリンクしてくれるのでよいのですが、GCCなどでは、Makefileの中で明示的にライブラリを指定する必要があります。そこで問題になってくるのがライブラリ名です。 Boost C++ Librariesのライブラリ名は、おおむね次のような形式になっています。 ここで、[ ] で囲まれた部分は、ライブラリの種類によって有無が異なるものです。< > で囲まれた部分には適切な文字列が適用されます。 先頭の li
株式会社きじねこは大阪のソフトウェア開発会社です。組込み系・業務系のプログラム開発から電子回路の設計までおまかせください。 C の場合、タグ名だけでは型名になれず、struct, union, enum を付けなければなりません。そのため、使い勝手を向上するために typedef 名を付けることが多いのではないでしょうか？ 一方、C++ ではクラスや列挙体のタグ名だけで型名になりますので、そうした typedef 名はあまり使う機会がないかもしれません。 というわけで、C では次のような型定義がよく行われます。 typedef struct _FOO { ... } FOO; ところが、このコードの動作は未定義だということをご存知でしょうか？ _FOO のように、下線（アンダースコア、アンダーバー）で始まり、下線または大文字が続く識別子は「予約済み識別子」です。予約済み識別子というのは、規
C言語の整数型は処理系によってサイズが異なります。標準規格では、それぞれの整数型が少なくともどれだけの表現範囲を持っているか、そして、それぞれの整数型の間の表現範囲の大小関係だけが決められています。 整数型の中でも、int 型のサイズは 16 ビットと 32 ビットの処理系がそれなりに多く存在することもあり、入門書や解説書でも注意が促されることが多いようです。最近では long 型が 64 ビットの処理系もありますので、整数型のサイズを取り巻く状況はもう少し複雑になってきています。 そうした中、極力ソースコードの移植性を高めようということで、int 型のようにサイズがよくわからない型は使用せず、int16 型とか、int32 型のような型を定義して、「それらを使うべし」とするコーディング規約もよく見かけます。それで本当に、int 型のサイズに関する移植性の問題は解消されたのでしょうか？ 残
次のページ
このページを最初にブックマークしてみませんか？
『株式会社きじねこ | 大阪のソフトウェア開発会社』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
