January 21, 2021
Hot Topics:

What's New in C++00X?

  • By Victor Volkman
  • Send Email »
  • More Articles »

Template Aliasing

You can use template aliasing today only if you happen to have the complete parameter list defined by a typedef. Because you can't create an alias with undefined parameters per se, a lot of code that uses STL looks harder to read (and write) than it really should. You can work around this issue today mostly by clever use of default parameters or by encapsulating it through yet another template. In C++00X, you will first declare the aliasing just ONCE with the "using" keyword:

template< class T > using Vector = MyVector< T, MyAlloc<T> > ;

Then, when it comes time to actually instantiate a variable, you can use the much easier to understand:

Vector<int> int_vector ;

Instead of the usual gobbledy-gook:

MyVector<int, MyAlloc<int> > int_vector ;

Variadic Templates

In C and C++, there is always a fixed number of arguments that a function can take and these arguments have defined types. The exception is, of course, the odious printf() family of functions that use the old "varargs" method of argument passing. Variadic templates get around this problem by allowing a function to take an arbitrary number of arguments. A full discussion of variadic templates is outside the scope of what I can cover in this article, although others have done so.

Extern Templates

Every module that instantiates a template essentially creates a copy of it in the object code. Then, it's up to the linker to dispose of all of the redundant object code at the very last stage, thus slowing the critical edit-compile-link cycle that makes up a programmer's day (or sometimes daydreams). To short-circuit this object code garbage collection, a number of compiler vendors have already implemented an extern keyword that can go in front of templates. This is a case of standardization codifying existing industry practice (pun intended). In practice, this is implemented by sending a notice to the compiler basically to "not instantiate this here":

extern template class std::vector<MyClass>;

Strongly Typed Enums

Although all of us have been trained that enums are vastly superior to their predecessors (the ubiquitous #define), there are still a lot of shortcomings in everyday usage. In some sense, you get the worst of both worlds: Enums are not integers nor are they completely typesafe. The only practical protection you have is that you can't directly substitute one enum type for another, although any fool can cast it to an int. More insidious is that you have no control over the implementation of the enum type; it's generally as big as an int but your mileage may vary. Last, is the continual annoyance that two different enumerations in the same scope can't have any overlapping enum tokens in common. This rules out using intuitive names like "OK", "ERROR", and so on because there is always a risk it will collide with somebody's third-party library. C++0X solves all these issues neatly by creating a class-based enum whose base-type is well-defined, scope resolvable, and can never be cast away to an int. For example:

enum class Status : unsigned long
   WARNING = 100    // etc.

See N2347 for specifics.

What's Not Going in Yet

A language is not only defined by what goes in but also but what's not there whether by design or by default. In any standards update, probably a lot more goes overboard than goes into the final standard. Still, it provides valuable insights into the minds of the designers to know what didn't pass muster.

Because most computers shipped in 2008 will have at least two CPU "cores," the issue of how to put multithreading into the C++ standard has a lot of interest. You may be familiar, for example, with the Posix pThreads library, which is one such independent solution for C functions. A complete multithreading solution would have to account for many aspects of thread management including: parallel execution, asynchronous function calls, thread-local storage, atomic operations, and extending the use of the "volatile" keyword.

Currently, when a derived class is created from a base class, the derived class has an entirely separate set of constructors. The derived class may call base class constructors and forward parameters to them, but it's still up to the developer to create each constructor separately. As with life before delegating constructors, it doesn't require much thought and encourages cut-and-paste errors. This could be solved by inheriting constructors, although it is currently "under review" and not yet in the "working document" (see N2376).

What's More...?

In the space of this article, I've been able to touch only a few of the cutting edge aspects of C++0X. It is my hope that you've got some idea of what's ahead in these areas and how your libraries and apps could benefit from the new possible constructs. Stay tuned to this channel and I'll be providing more information in the weeks and months to come leading up to eventual ISO ratification in 2009.

About the Author

Victor Volkman has been writing for C/C++ Users Journal and other programming journals since the late 1980s. He is a graduate of Michigan Tech and a faculty advisor board member for Washtenaw Community College CIS department. Volkman is the editor of numerous books, including C/C++ Treasure Chest and is the owner of Loving Healing Press. He can help you in your quest for open source tools and libraries, just drop an e-mail to sysop@HAL9K.com.

Page 2 of 2

This article was originally published on August 27, 2007

Enterprise Development Update

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

Thanks for your registration, follow us on our social networks to keep up-to-date