タイトル通り、
『C/C++プログラミングの「迷信」と「誤解」』
は本日発売となります。すでに一部の書店では先行発売しているところ科tもあるようですが、今日から全国の書店およびネット書店での販売が始まるかと思います。見かけましたら、ぜひ中をのぞいてみてください。
2011-03-17(Thu) | 未分類 | comment : 0 | Trackback : 0
最近はすっかり更新しなくなってしまった当ブログですが、せめて新しい本が出たときぐらいはここでもアナウンスしておきたいと思います。
『プログラマーのためのソースコードを読む技術』
がそれで、建前上は今週の金曜日（6月11日）に発売の予定です。ただし、すでに先行発売しているところもあるようですので、書店で見かけた場合は少しぐらいページをめくってみてください。
できれば、年内にもう一度ぐらい新しい本が出ましたというアナウンスをしたいところですが、タイミング的にやや微妙なところではないかと考えています。
2010-06-06(Sun) | 雑 | comment : 0 | Trackback : 0
すでにネタが枯渇した状態で、一ヶ月以内に投稿するというのはかなり至難の業です。今回は保守のための投稿だけとし、近いうちにまともな記事を書きたいと思います。
2009-06-27(Sat) | 雑 | comment : 0 | Trackback : 0
TECSの仕様を検討している際に何度か話題に上がったのですが、クラス（というか構造体）のメンバのうち、一部をROMに、残りをRAMに配置する方法がないものでしょうか？ 今回はこれについて考えてみます。
C++には、メンバの一部をROMに、残りをRAMに配置するための直接的なシンタックスはありません。これはCの場合でも同じです。これを実現するには、通常次のようにしなければなりません。
struct rom_part
{
...
};
struct ram_part
{
rom_part const* p_rom;
...
};
static rom_part const rom = { ... };
ram_part ram = { &rom, ... };
あるいは、
struct ram_part
{
...
};
struct rom_part
{
ram_part const* p_ram;
...
};
static ram_part ram;
rom_part const rom = { &ram, ... };
のようにすることもできます。一般的には、ROMよりもRAMの方が高速ですので、前者の方が好まれますが、十分使いやすくなるのであれば、後者でもよいかもしれません。ただ、後者の場合、ROMに配置するクラスには明示的なコンストラクタやデストラクタを定義できませんので、使い勝手がよくなる可能性はそれほど高くありません。
［このエントリの全文を表示］
2009-05-27(Wed) | 実装技術 | comment : 0 | Trackback : 0
FC2ブログはすぐに「スポンサーサイト」にされてしまうので、保守の意味でも、今回はよく受ける質問から「C++で書いたHello, World!はなぜデカいか？」について書いてみることにします。
C++でstd::coutを使ったHello, World!を書くと、驚くほどプログラムサイズが大きくなってしまいます。リンカが出力するマップファイルをみるなどすれば分かりますが、使ってもいない関数が大量にリンクされていると思います。これは一体何なのでしょうか？
std::coutというか、std::basic_ostreamクラステンプレートでは、文字列を出力する際に、内部的にstd::codecvtファセットという機能を用います。これは、主に文字コードを変換するためのものです。例えば、プログラム内部ではUTF-8を使うけれども、外部に出力する際にはシフトJISにしないといけない場合には、ファセットの機能を用いて文字コードの変換を行うわけです。
また、数値と文字列の変換には、std::num_getやstd::num_putファセットが必要になります。その他にも、何種類かのファセットが定義されています。これらのファセットは、std::localeクラスおよびその派生クラスが持っているわけですが、ロケールの切り替えは動的に行うことを前提としているため、サポートしている全ロケールのコードがリンクされてしまうことになります。
これでは、ごくごく単純なHello, World!を出力するだけのプログラムであっても、サイズが非常に大きくなってしまいます。実際のところ、ロケールの機能を使いこなせる技術者はそう多くありませんし、使いこなせたとしても、本当に使いこなす機会はそう多くはありません。そう考えると、この機能はかなり冗長なものです。
ロケール周りを適切にカスタマイズしたストリームクラスを再実装するか、独自のストリームクラス群を定義することで、サイズの問題は大幅に改善する可能性があります。
2009-04-27(Mon) | 実装技術 | comment : 0 | Trackback : 0
