#constexpr

Hoy veremos un especificador para usar en lugar de un preprocesador. Espero les sea de utilidad buen inicio de semana y feliz año nuevo!

Bienvenidos sean a este post, hoy veremos un especificador. Este declara que el valor de la funcion es posible a evaluarlo en tiempo de compilacion, esto tambien aplica a las variables. Su nombre consiste de const y expresion. Su principal caracteristica es la capacidad de optimizar nuestro codigo al maximo. Vamos a analizar el siguiente ejemplo: #define NUMERO 42 #include <iostream> int…

[Click here for a PDF of this post with nicer formatting]

In [1] is a rather mysterious looking constant expression formula for an integer square root. This is a function that returns the smallest integer for which the square is less than the value to take the root of. Check out the black magic he used

// Stroustrup 10.4: constexpr capable integer square root function constexpr int…

const vs constexpr on variables

Is there a difference between the following definitions?

const double PI = 3.141592653589793; constexpr double PI = 3.141592653589793;

If not, which style is preferred in C++11?

Answer

I believe there is a difference. Let’s rename them so that we can talk about them more easily:

const double PI1 = 3.141592653589793; constexpr double PI2 = 3.141592653589793;

Both PI1 and PI2are…

How to: When should you use constexpr capability in C++11?

When should you use constexpr capability in C++11?

It seems to me that having a “function that always returns 5″ is breaking or diluting the meaning of “calling a function”. There must be a reason, or a need for this capability or it wouldn’t be in C++11. Why is it there?

// preprocessor. #define MEANING_OF_LIFE 42 // constants: const int MeaningOfLife = 42; // constexpr-function: constexpr int…

source: http://cpptruths.blogspot.com/2011/07/compile-time-regex-matcher-using.html

constexprにますます取り憑かれた私は、テンプテートメタプログラミングでは実現困難なことに使えないかと思うに至った。…コンパイル時正規表現マッチャーなどどうだろう…？幸い単純な正規表現マッチャーならRob Pikeがもう作っている。私はこれをconstexprを使って書きなおしてみた。すなわち、関数は単一のreturn文しか持たないように、引数に変更がないように、条件演算子(訳註：ternary operatorェェェ…)と再帰まみれに。さて、逝ってみようか…

constexpr int match_c(const char *regexp, const char *text); constexpr int matchhere_c(const char *regexp, const char *text); constexpr int matchstar_c(int c, const char *regexp, const char *text); constexpr int matchend_c(const char * regexp, const char * text); constexpr int matchend_c(const char * regexp, const char * text) { return matchhere_c(regexp, text) ? 1 : (*text == '\0') ? 0 : matchend_c(regexp, text+1); } constexpr int match_c(const char *regexp, const char *text) { return (regexp[0] == '^') ? matchhere_c(regexp+1, text) : matchend_c(regexp, text); } /* matchhere: テキストの先頭から regexp を探索する */ constexpr int matchhere_c(const char *regexp, const char *text) { return (regexp[0] == '\0') ? 1 : (regexp[1] == '*') ? matchstar_c(regexp[0], regexp+2, text) : (regexp[0] == '$' && regexp[1] == '\0') ? (*text == '\0') : (*text!='\0' && (regexp[0]=='.' || regexp[0]==*text)) ? matchhere_c(regexp+1, text+1) : 0; } /* matchstar: テキストの先頭から c と regexp を探索する*/ constexpr int matchstar_c(int c, const char * regexp, const char *text) { return matchhere_c(regexp, text) ? 1 : (*text != '\0' && (*text == c || c == '.')) ? matchstar_c(c, regexp, text+1) : 0; } #define TO_STR_IMPL(R) #R #define TO_STR(R) TO_STR_IMPL(R) int main(void) { static_assert(match_c(TO_STR(REGEX), TO_STR(TEXT)), "..."); return 0; }

現在これをコンパイルできるのはg++4.6以上だ。コンパイル前にREGEX と TEXT をマクロで定義しておこう。例えば、-D REGEX=o$ -D TEXT=Fooという風に。…よし通った!ktkr!!

TO_STR と To_STR_IMPL というマクロは、REGEX と TEXT マクロを文字列リテラルに変換するためのものだ。#R はマクロを文字列に変換する基本的なテクニックだ。訳あって TEXT の変換を行なう TO_STR マクロを二つに分割している。どうやらgccプリプロセッサはマクロ一つでこれを達成できないようなので…

source: http://cpptruths.blogspot.com/2011/07/want-speed-use-constexpr-meta.html

公的にC++11は二種のメタプログラミング方法を備えている。ひとつはtemplateベースで、もうひとつはconstexprである。(訳註：CPPどこいった…!) templateはC++03では広くメタプログラミングに用いられている。C++11ではもうひとつ選択肢が加わる。constexprを用いたコンパイルタイムメタプログラミングである。だが、これらは機能性・可用性の点で相違がある。

templateを利用したメタプログラミングはまったくの偶然から発見され、以来、種々多様なテクニックが発明されつづけてきた。これは、整数リテラルと型のコンパイル時操作が可能な一方で、浮動小数点数リテラルを扱えない純粋関数型言語として機能した。templateメタプログラミングの構文は、メタ関数を構造体、もしくは入れ子のtypedefで実装しなければならず、非常に見苦しいと感じる者が多かった。

汎化された定数式(以下 constexpr)はC++11に対応したコンパイラが、関数の(さらにはクラスの)実装を調べて、もし関数(とクラス)が定数(リテラル)のみを使っている場合に最適化できるようにする機能である。この場合、定数は整数リテラルでも浮動小数点数リテラルでも文字列リテラルでもよい。constexprがついた関数は普通のC++関数と同じように見えるが、関数本文は単一のreturn文しか許可されないという制限がある。それにしても、constexpr関数の構文はtemplateベースのメタ関数よりはるかにとっつきやすい。templateが導入されたときとは対照的に、汎化された定数式の設計者はそもそもそのメタプログラミング能力を十分理解していた。

思うに、constexprの瞠目すべき性質はその速度にある。constexpr関数はコンパイル時に電光石火のごとき速度で計算を行なう。パフォーマンスを比較するために、筆者はis_prime アルゴリズムを3種の方法で実装した。まず以下は通常のC++で実装したものである：

static bool IsPrime(size_t number) { if (number <= 1) return false; for (size_t i = 2; i*i <= number; ++i) if (number % i == 0) return false; return true; }

つぎに、同じアルゴリズムをtemplateで実装したものを示す。言うまでもなく、構造体を基本としたメタ関数のあつまりとして実装した。

struct false_type { typedef false_type type; enum { value = 0 }; }; struct true_type { typedef true_type type; enum { value = 1 }; }; template<bool condition, class T, class U> struct if_ { typedef U type; }; template <class T, class U> struct if_<true, T, U> { typedef T type; }; template<size_t N, size_t c> struct is_prime_impl { typedef typename if_<(c*c > N), true_type, typename if_<(N % c == 0), false_type, is_prime_impl<N, c+1> >::type >::type type; enum { value = type::value }; }; template<size_t N> struct is_prime { enum { value = is_prime_impl<N, 2>::type::value }; }; template <> struct is_prime<0> { enum { value = 0 }; }; template <> struct is_prime<1> { enum { value = 0 }; };

このメタプログラムは純粋関数型言語に則って再帰的実装を取っている。この is_prime_impleメタ関数が重要な仕事をすべてやっつけている。無限再帰を防ぐために、"怠惰なインスタンス化(lazy instatiation)"テクニックを用いている。思うに、きっと今読者はコードを凝視して理解に努めていることだろう。

…そう、それこそが狙いだ。要はC++03のメタプログラムはだいたい読みづらく、理解しづらいのだ。…時は来たれり! 以下は同じアルゴリズムをconstexprで実装したものである。

constexpr bool is_prime_recursive(size_t number, size_t c) { return (c*c > number) ? true : (number % c == 0) ? false : is_prime_recursive(number, c+1); } constexpr bool is_prime_func(size_t number) { return (number <= 1) ? false : is_prime_recursive(number, 2); }

えぇ。まぁ言いたいことは分かる。このヴァージョンでもまだそれほど読みやすいとは言えない。template版と同様、こちらも再帰を使っている。そこはあきらめて馴れましょう! C++のメタプログラミングにおいては、再帰は切っても切れない関係にあるので仕方ない。また、全ての関数は単一のreturn文しか持っておらず、素数を検出する際の条件分岐に条件演算子(訳註：原文ternary operatorェ…)が多用されている。

実引数が整数定数ならば、constexpr版は(もちろんC++11対応のコンパイラならば)コンパイル時に結果がでる。また、実引数がランタイムに決定される場合でも、同じ関数を使って実行時に計算し問題なく結果を出すことができる。つまり、コンパイルタイムとランタイム用に二つ同じことをするプログラムを書く必要がない。これひとつで全てが叶うのだ!

int main(void) { int i = is_prime_func(7); // Computed at compile-time int j = is_prime_func(i); // Computed at run-time }

さて、実装が終わったところで、パフォーマンスの話に移ろう。4256233を例として挙げよう。これは三万番目の素数だ。これが素数かどうか確認するのに、template版だとどのくらい掛るだろうか。…だがダメっ…! それ以前の問題で、g++4.7ではis_prime<4256233>::valueをコンパイルできない。というのは、再帰テンプレートインスタンス化の上限がデフォルトでは900回に縛られているからだ。気をとりなおして -ftemplate-depth-2100 を使って2100回まで再帰できるようにしてみよう。…イケるか…？ イケた! さぁどのくらい時間が掛っただろうか。…だいたい一秒だ! …まぁ悪くないね、と読者は思うかもしれない。ではconstexprではどうか。なんと脅威の0.154秒だ!

これだとそれほどtemplate版が遅いようには見えないかもしれない。大間違いだ。五千万個目の素数について考えてみよう。982451653だ。g++4.7では動作させることすらできなかった。8000回目あたりのテンプレートインスタンス化でg++はセグフォを吐いた。そりゃアンフェアだ! と思うかもしれない。8000+回の再帰テンプレートインスタンス化が？もっとマシな方法があるに違いない。

さて、ではconstexpr版で五千万個目の素数を判定してみよう… なんと0.154秒だった! 間違いない。typoもしていない! この巨大な素数を以ってすらコンパイル時間に与える影響はほとんどないも同然だった。いったいどういう訳だろう。まず、constexpr版にはテンプレートのインスタンス化が伴なわない。C++コンパイラはできる限りコンパイル時計算をやろうとする。constexprはユーザー定義の抽象化(user-defined abstractions)の機会を与え、関数の後ろに計算を隠しつつ、コンパイラから見通せるようになる。もうひとつこの電光石火のパフォーマンスがでそうな理由は、is_prime_funcは末尾再帰関数だという点だ。これは、優れたコンパイラならコンパイルタイムに再帰を完全に省いて単純なループに平板化できるという事を意味する。