C/C++

仮想関数を持たずに仮想関数テーブルを持つ

あんどちん — Tue, 27 Aug 2013 00:22:00 GMT

C++11では、=deleteで関数の定義を削除できます。この機能を利用すると、以下のように仮想関数を持たないクラスに仮想関数テーブルを作成できます。

struct S {
virtual void f() = delete;
};

仮想関数テーブルを持てるということは、RTTIが使用できるので、何かに使えそうです。

ただ、使い道が思い浮かばないっていう…

C++ポケットリファレンス発売されました

あんどちん — Wed, 15 May 2013 00:30:00 GMT

先行発売書店では既に発売開始したみたいです。

先行発売店舗は以下の通りです。

紀伊國屋書店新宿本店
紀伊國屋書店新宿南店
書泉ブックタワー
三省堂神田神保町本店
有隣堂ヨドバシAKIBA店
ジュンク堂書店池袋本店
丸善丸の内本店
八重洲ブックセンター本店

先行発売店舗以外では５月１８日からの発売となります。

C++ポケットリファレンス

あんどちん — Thu, 25 Apr 2013 01:15:00 GMT

ぼくも執筆に協力したC++ポケットリファレンスがようやく発売の運びとなりました。

中々カコイイ表紙です。

Amazonにもページできました。来月発売なのに結構いい順位になってたりして、びっくりしてます。

あと、技術評論社の書籍紹介ページを見ても、tweet数やfacebookの「いいね！」が結構な数になっていてびっくりです。

世の中のC++に対する反応っていうのは僕が思っている以上に凄いですね。

本の内容ですが、リファレンス本なので、「これやりたいんだけど」とか、「どう書くんだっけ？」といった場合に使う本で、所謂入門書とは違います。ただ、C++の入門書を読んだ人や、CやC#やJavaなどの言語を使ったことのある人がC++11でプログラムを書くことになった時には役に立つと思います。

# リファレンス本じゃなくて、C++11対応の入門書が欲しい人は…然るべき方に「書いて」って言いましょうｗ。

この本の最大の売りは、C++11対応でしょう。日本人が日本語で書いたC++本でC++11をここまで盛り込んでいる本は今のところ無いと思います。文法も標準ライブラリも一通り網羅していて、C++11対応。日本で出ているC++本に対する印象からすると、よくこれを出させてくれたなって思います。技術評論社さんに感謝です。

528ページというページ数で色々な反応がありますが、僕自身C言語ポケットリファレンスやJavaポケットリファレンス、Linuxコマンドポケットリファレンスを持っているポケリストですが、それらの本と大体同じくらいの厚さ。オーバーオールのポケットやダウンジャケットの大きめのポケットなら（たぶん）入るサイズです。鈍器と呼ぶのは1000ページ超えてからにしましょう。

それから、この本は電子書籍版も同時発売となります。電子書籍なら重さは気にならないですね！

VC11のrange-based forサポートとinitializer-list

あんどちん — Fri, 31 Aug 2012 02:38:00 GMT

ここに書かれているVC11のC++11サポート状況をみると、range-based for-loopがYesになっており、きちんとサポートされているように見えるのですが、「あれ？」と思ったんですね。

規格のrange-based for-loopのところをみるとrange-based for-loopには以下の形式もあります

for ( for-range-declaration : braced-init-list ) statement

initializer-listをサポートしていないVCでこれが通るんでしょうか？しかし、この書式が受け付けられなければYesではなく、Partialと書いてありそうな気がします。

そこで、以下のコードを試してみたのですが、コンパイルエラーになりました。

for(auto v : { 0, 1, 2, 3 }) cout << v << endl;

うぅん…予想できたこととはいえ、ちょっと残念

CとC++におけるUniversal Character Nameの違い

あんどちん — Wed, 08 Aug 2012 00:58:00 GMT

CとC++では、\uNNNNもしくは\UNNNNNNNNのフォーマットでUniversal Character Nameを扱えますが、使える文字に違いがあります。

C言語では、N1124の6.4.3章によると0024,0040,0060を除く00A0未満の値及びD800-DFFFはUniversal Character Nameで使用禁止となっています。

C++では、ISO14882:2011の2.3章によると0000-001Fと007F-009F、そして基本ソース文字セットとD800-DFFFはUniversal Character Nameで使用禁止となっています。

なんでこんな違いがあるんでしょうね？

gcc-4.7におけるinline namespaceとnamespaceの混在

あんどちん — Wed, 23 May 2012 00:10:00 GMT

C++11にはインラインネームスペースという機能があります。インラインネームスペース内は透過的にアクセスすることが可能です。

inline namespace name {
void foo();
}

この場合fooはname::foo();でもfoo();でも呼び出せます。

そんなinline namespace。gccでも実装されているのですが、同名のinline namespaceとnamespaceを作るとどちらもinline namespaceとして扱われてしまうというバグが存在しています。

namespace name {
void func1() {}
}

inline namespace name {
void func2() {}
}

上記のように同じ名前空間をinline namespace/namespace両方でで宣言すると、どちらに含まれる識別子も名前修飾なしで透過的にアクセスできてしまいます。

そもそも同名名前空間のinlineと非インラインの混在がダメなような気がしますが、それができて、その通り機能してくれたらライブラリ屋さん的には便利かも？と思います。

gcc-4.7におけるnon-satatic data member initializer とthis

あんどちん — Sat, 14 Apr 2012 12:16:00 GMT

C++11ではnon-static data member initializerが導入され、クラスの初期値設定をよりわかりやすく行うことが出来るようになっています。

struct X {
int a = 10; // Xの初期値は10
X() : a(10) /* これと同じ */ {}
};

この初期化子ではthisを使用することもできます。

struct X {
size_t sz = sizeof(*this); // これは可能
int arr[sizeof(*this)]; // でもこれは不可
};

さて、gcc-4.7では以下のコードのコンパイルが通ってしまいます。

struct X {
void f() {
    struct Y {
      size_t sz = sizeof(*this); // Yのサイズ
      int arr[sizeof(*this)]; // エラーのはずだが…
};
};

この時Y::szにはYのサイズが、Y::arrの要素数にはXのサイズが適用されています。バグでしょうね。

なお、Clangではエラーを出力してくれます。

tupleのネスト

あんどちん — Wed, 04 Apr 2012 01:31:00 GMT

利用用途があるかどうかはともかく…

tuple<char, tuple<short, long>> val;
auto elem = get<1>(val);

このコードはgccでもVCでも問題なくコンパイルできます。

但し、

struct A{};
struct B{};
struct C{};
//…
tuple<A,tuple<B,C>>val;
auto elem = get<1>(val);

このコードはVCだと通りますが、gccだとエラーになります。

コードが悪いのか、gccが悪いのか、はたまたVCが悪いのか。

ラムダ式の関数ポインタを返すラムダ式

あんどちん — Thu, 08 Mar 2012 02:40:00 GMT

stateless lambda

を見て、

「へぇ、ラムダ式を関数ポインタに入れられるんだ」

と感心していたんですが、

「ラムダ式の関数ポインタを返すラムダ式って書けるのかな？」

という疑問が。

#include <iostream>
#include <vector>

int main()
{
using namespace std;

void(*(*f)())() = []()->void (*)() { return []{cout << "hello\n";}; };
void(*f1)() = f();
f1();
[]()->void (*)() { return []{cout << "hello\n";};}()();

vector<void(*)()> fv = {{[]{cout<<"1\n";}}, {[]{cout<<"2\n";}} };
for(void(*a)() : fv) a();
}

これの実行結果が

hello
hello
1
2

fにラムダ式の関数ポインタを返すラムダ式の関数ポインタを入れ、その実行結果をf1に。そしてf1を呼べば”hello”と表示されます。

その下の行は同じラムダ式を直接実行。

そして

「vectorにだって入れられるよね？」

と疑問に思ったから試してみたのがその下。

このプログラムはgcc-4.7.0 RC (2012/3/2版)で試しました。

FizzBuzzと貧乏性

あんどちん — Tue, 19 Oct 2010 23:44:00 GMT

良く見るプログラムの課題、FizzBuzz。問題の内容は以下の通り。

３で割り切れる数字の場合Fizzと言う
５で割り切れる数字の場合Buzzと言う
３でも５でも割り切れる数字の場合Fizz Buzzと言う
上記以外（３でも５でも割り切れない）であれば数値を出力

さて、このプログラムを素直に書いてみると

string fizz_buzzer(int value)
{
    string result;

    if(value % 3 == 0) result = "Fizz";
    if(value % 5 == 0) result = "Buzz";
    if(value % 3 == 0 && value % 5 == 0) result = "FizzBuzz";
    if(value % 3 != 0 && value % 5 != 0) result = lexical_cast<string>(value);

    return result;
}

こんな感じでしょうか。
「でもちょっと無駄があるなぁ…」
こう考えてしまうのが性。ぱっと見思い浮かぶのが
5で割り切れる時Buzzを代入するのではなく連結すれば1行減らせる
です。するとプログラムはこうなります。

string fizz_buzzer(int value)
{
    string result;

    if(value % 3 == 0) result = "Fizz";
    if(value % 5 == 0) result += "Buzz";
    if(value % 3 != 0 && value % 5 != 0) result = lexical_cast<string>(value);

    return result;
}

しかし、一度判定している３もしくは５で割った余りを再度計算するのが面白くないです。
「そうだ、フラグを追加しよう」
するとプログラムはこうなります。

string fizz_buzzer(int value)
{
    string result;
    bool fizz_or_buzz = false;

    if(value % 3 == 0) { result = "Fizz"; fizz_or_buzz = true; }
    if(value % 5 == 0) { result += "Buzz"; fizz_or_buzz = true; };
    if(!fizz_or_buzz) result = lexical_cast<string>(value);

    return result;
}

冗長な判定が無くなりいい感じになりました。しかし、フラグ用の変数を追加したのが面白くない。
そこで次の点に着目します。
「FizzでもBuzzでもなければresultの長さは0で数値代入になるじゃないか」
するとプログラムはこうなります。

string fizz_buzzer(int value)
{
    string result;

    if(value % 3 == 0) result = "Fizz";
    if(value % 5 == 0) result += "Buzz";
    if(result.size() == 0) result = lexical_cast<string>(value);

    return result;
}

「短くなって良かった。最初のプログラムと違いFizz/Buzzの条件が変わっても修正個所は１か所で済むし。」

そう思っていたんです。しかし、ある人の言葉でこれにも問題があることに気付きました。

「このプログラムは命題通りのプログラムになっているか？」

与えられた値に対する出力は要求通りです。しかし、このプログラムを見て最初の要求がわかるか？と言われれば確かにわかりにくいです。

FizzBuzzのように単純なプログラムであれば問題は無いですが、仕様をプログラマが脳内で最適化してコードに落とすと結果は合っていてもプログラムを見た時にその要求を満たしているかすぐわからないという問題が起きうるんですね。