June 24, 2018
Hot Topics:

Peeking Further into C++00X

  • October 1, 2007
  • By Victor Volkman
  • Send Email »
  • More Articles »

Expanding the Scope of C++!

In last month's installment, you covered the context of C++ standards development, TR1, and the rationale for expanding the scope of C++. The next C++ standard, code-named "C++00X", is heading down the home stretch towards ratification. Currently, it is expected to be named C++09 as of the latest report (N2336) released in July 2007. In this article, you peek further into what C++00X means to the average C++ programmer in the trenches. Because there are dozens of WG21 proposals on the table as of this writing, I will focus this article solely on proposals that were greenlighted at the July 2007 meeting, rather than discussing features that have been integrated in past months' or years' work.

Generalized Constant Expressions

Recently integrated into the working paper, Generalized Constant Expression represents the fourth iteration of attempts to normalize the working of constants in the C++ language. Although constants are everywhere in C++ programs (including const and enum), their participation in expressions has a certain degree of ambiguity under current rules. N2335 addresses all of these concerns in four specific categories:

  • Improving type-safety and portability for code requiring compile time evaluation
  • Improving support for systems programming, library building, generic programming
  • Simplifying the language definition in the area of constant expression to match existing practice
  • Removing embarassments from existing Standard Library components (namely #include limits)

Fixing the Bitmask

One problem this fixes is the bitmask type when it's implemented by an enum with overloaded operators. This is just one of three allowable implementations by the compiler; when it's used, the bitmask is no longer constant in the sense that it can be evaluated at compile time. The new constexpr keyword addresses this and many other things that allow for compile-time optimization of things that formerly were deferred until execution time.

When const Isn't

It is possible to be surprised by expressions that (to someone) "look const" but are not. For example, consider

   struct S {
      static const int size;

const int limit = 2 * S::size;    // dynamic initialization
const int S::size = 256;
// dynamic initialization
const int z = numeric_limits<int>::max();

Here, S::size is indeed initialized with a constant expression, but that initialization comes "too late" to make S::size a constant expression; consequently, limit may be dynamically initialized. Again, constexpr will come to the rescue.

Constant-Expression Functions

The new distinction Constant-Expression Function marries the best attributes of #define macro functions with the type safety, predictability of const, and guaranteed compile-time evaluation. In particular, a function is a constant-expression function if and only if it satisfies these criteria:

  • It returns a value (in other words, not void);
  • Its body consists only of a single statement of the form.
  • return expr;

    and every single thing that combines to produce expr is also constant.

  • It is declared with the keyword constexpr.
  • It cannot be called before it is defined, thus recursion is not allowed.

Interestingly, a constant-expression function may be called with non-constant expressions (for example, variables). In that case, there is no requirement that the resulting value be evaluated at compile-time.

Here are some examples:

constexpr int square(int x)
   { return x * x; }    // legal

constexpr int abs(int x)
   { return x < 0 ? -x : x; }    // legal

constexpr int next(int x)
   { return ++x; }    // error: increment cannot be evaluated at
                      // compile time

constexpr int g(int n)    // error: body not just ''return expr''
   int r = n;
   while (--n > 1) r *= n;
   return r;

constexpr int fac(int x)
   { return x > 2 ? x * fac(x - 1) : 1; }    // error: fac() not
                                             // defined before use

C99 Compatibility : __func__ and Predeclared Identifiers

The 1999 revision of the C standard introduced the concept of 'a predeclared identifier'. N1970 carries that concept forward into C++ in the name of upward compatability, an attribute that the standards committee holds dear. In the past, the role of these diagnostic aids was a part of the macro preprocessor, a mechanism that the standards committee tries to relegate as much as possible. Basically, these predeclared identifiers allow you to construct intelligent error messages that point out the line number, file name, and function name where a problem is taking place. __func__ is the equivalent of a local declaration like:

static const char __func__[] = "function-name";

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date