Exceptional C++ 
H. Sutter, Addison-Wesley, 2000, ISBN 0-201-61562-2.

More C++ Gems (major contributor) 
R. Martin (ed.), SIGS Books / Cambridge University Press, 2000, ISBN 0-521-78618-5.

More Exceptional C++ 
H. Sutter, Addison-Wesley, 2002, ISBN 0-201-70434-X.

Exceptional C++ Style
H. Sutter, Addison-Wesley, 2004, ISBN 0-201-76042-8.

C++ Coding Standards 
H. Sutter and A. Alexandrescu, Addison-Wesley, 2005, ISBN 0-321-11358-6.

Effective Concurrency: Know When to Use an Active Object Instead of a Mutex
Dr. Dobb's Report, September 2010.

From the article: "Let’s say that your program has a shared log file object. The log file is likely to be a popular object; lots of different threads must be able to write to the file; and to avoid corruption, we need to ensure that only one thread may be writing to the file at any given time. Quick: How would you serialize access to the log file? Before reading on, please think about the question and pencil in some pseudocode to vet your design. More importantly, especially if you think this is an easy question with an easy answer, try to think of at least two completely different ways to satisfy the problem requirements, and jot down a bullet list of the advantages and disadvantages they trade off. Ready? Then let’s begin."

Effective Concurrency: Prefer Using Futures or Callbacks to Communicate Asynchronous Results
Dr. Dobb's Report, August 2010.

From the article: "This time, we’ll answer the following questions: How should we express return values and out parameters from an asynchronous function, including an active object method? How should we give back multiple partial results, such as partial computations or even just “percent done” progress information? Which mechanisms are suited to callers that want to “pull” results, as opposed to having the callee “push” the results back proactively? And how can “pull” be converted to “push” when we need it? Let’s dig in…"

Effective Concurrency: Prefer Using Active Objects Instead of Naked Threads
Dr. Dobb's Report, June 2010.

From the article: "Active objects dramatically improve our ability to reason about our thread’s code and operation by giving us higher-level abstractions and idioms that raise the semantic level of our program and let us express our intent more directly. As with all good patterns, we also get better vocabulary to talk about our design. Note that active objects aren’t a novelty: UML and various libraries have provided support for active classes. Some actor-based languages already have variations of this pattern baked into the language itself; but fortunately, we aren’t limited to using only such languages to get the benefits of active objects. This article will show how to implement the pattern, including a reusable helper to automate the common parts, in any of the popular mainstream languages and threading environments, including C++, C#/.NET, Java, and C/Pthreads."

Effective Concurrency: Associate Mutexes with Data to Prevent Races
Dr. Dobb's Report, May 2010.

From the article: "The holy grail of the Consistency pillar is to make a concurrent program race-free and deadlock-free by construction. … This article shows how to achieve the "race-free by construction" grail via sound engineering, with automatic and deterministic race identification at test time based on code coverage alone."

Effective Concurrency: Prefer Futures to Baked-In "Async APIs"
Dr. Dobb's Report, January 2010.

From the article: "When designing concurrent APIs, separate "what" from "how" Let’s say you have an existing synchronous API function [calledDoSomething]... Because DoSomething could take a long time to execute (whether it keeps a CPU core busy or not), and might be independent of other work the caller is doing, naturally the caller might want to execute DoSomething asynchronously. … The question is, how should we enable that? There is a simple and correct answer, but because many interfaces have opted for a more complex answer let’s consider that one first."

Effective Concurrency: Prefer Structured Lifetimes - Local, Nested, Bounded, Deterministic
Dr. Dobb's Report, November 2009.

From the article: "Where possible, prefer structured lifetimes: ones that are local, nested, bounded, and deterministic. This is true no matter what kind of lifetime we’re considering, including object lifetimes, thread or task lifetimes, lock lifetimes, or any other kind. ..."

Effective Concurrency: Avoid Exposing Concurrency – Hide It Inside Synchronous Methods
Dr. Dobb's Report, October 2009.

From the article: "You have a mass of existing code and want to add concurrency. Where do you start? Let’s say you need to migrate existing code to take advantage of concurrent execution or scale on parallel hardware. In that case, you’ll probably find yourself in one of these two common situations, which are actually more similar than different: Migrating an application: You’re an application developer, and you want to migrate your existing synchronous application to be able to benefit from concurrency. Migrating a library or framework: You’re a developer on a team that produces a library or framework used by other teams or external customers, and you want to let the library take advantage of concurrency on behalf of the application without requiring application code rewrites. You have a mountain of opportunities and obstacles before you. Where do you start?  ..."

Effective Concurrency: Design for Manycore Systems
Dr. Dobb's Report, August 2009.

From the article: "Why worry about “manycore” today? Dual- and quad-core computers are obviously here to stay for mainstream desktops and notebooks. But do we really need to think about "many-core" systems if we’re building a typical mainstream application right now? I find that, to many developers, "many-core" systems still feel fairly remote, and not an immediate issue to think about as they’re working on their current product. This column is about why it’s time right now for most of us to think about systems with lots of cores. In short: Software is the (only) gating factor; as that gate falls, hardware parallelism is coming more and sooner than many people yet believe. ..."

Effective Concurrency: The Power of "In Progress"
Dr. Dobb's Report, July 2009.

From the article: "Let’s look at the question from another angle, suggested by my colleague Terry Crowley: Instead of viewing partially-updated state with in-progress work as an ‘unfortunate’ special case to remember and recover from, what if we simply embrace it as the normal case? ..."

Effective Concurrency: Break Up and Interleave Work to Keep Threads Responsive
Dr. Dobb's Report, June 2009.

From the article: "What happens when this thread must remain responsive to new incoming messages that have to be handled quickly, even when we’re in the middle of servicing an earlier lower-priority message that may take a long time to process? If all the messages must be handled on this same thread, then we have a problem. Fortunately, we also have two good solutions..."

Effective Concurrency: Eliminate False Sharing
Dr. Dobb's Report, May 2009.

From the article: "... A number of readers have asked for more information and examples on where false sharing arises and how to deal with it. … This month, let’s consider a concrete example that shows an algorithm in extremis due to false sharing distress, how to use tools to analyze the problem, and the two coding techniques we can use to eliminate false sharing trouble…"

From the article: "... But the thread pool is a leaky abstraction. That is, the pool hides a lot of details from us, but to use it effectively we do need to be aware of some things a pool does under the covers so that we can avoid inadvertently hitting performance and correctness pitfalls. Here’s the summary up front: 1. Tasks should be small, but not too small, otherwise performance overheads will dominate. 2. Tasks should avoid blocking (waiting idly for other events, including inbound messages or contested locks), otherwise the pool won’t consistently utilize the hardware well — and, in the extreme worst case, the pool could even deadlock. Let’s see why. …"

From the article: "Explicit threads are undisciplined. They need some structure to keep them in line. In this column, we're going to see what that structure is, as we motivate and illustrate best practices for using threads -- techniques that will make our concurrent code easier to write correctly and to reason about with confidence. ..."

From the article: "... In this article, I’ll deliberately focus most of the examples on one important case, namely mutable (writable) shared objects in memory, which are an inherent bottleneck to scalability on multicore systems. But please don’t lose sight of the key point, namely that "sharing causes contention" is a general principle that is not limited to shared memory or even to computing. The Inherent Costs of Sharing Here’s the issue in one sentence: Sharing fundamentally requires waiting and demands answers to expensive questions. …"

From the article: "What does the volatile keyword mean? How should you use it? Confusingly, there are two common answers, because depending on the language you use volatile supports one or the other of two different programming techniques: lock-free programming, and dealing with ‘unusual’ memory. Adding to the confusion, these two different uses have overlapping requirements and impose overlapping restrictions, which makes them appear more similar than they are. Let’s define and understand them clearly, and see how to spell them correctly in C, C++, Java and C# — and not always as volatile. ..."

From the article: "How would you write a fast, internally synchronized queue, one that callers can use without any explicit external locking or other synchronization? Let us count the ways…or four of them, at least, and compare their performance. We’ll start with a baseline program and then successively apply three optimization techniques, each time stopping to measure each change’s relative performance for queue items of different sizes to see how much each trick really bought us.  …"

From the article: "Let’s say that we’ve slickly written our code to apply divide-and-conquer algorithms and concurrent data structures and parallel traversals and all our other cool tricks that make our code wonderfully scalable in theory. Question: How do we know how well we’ve actually succeeded? Do we really know, or did we just try a couple of tests on a quad-core that looked reasonable and call it good? What key factors must we measure to understand our code’s performance, and answer not only whether our code scales, but quantify how well under different circumstances and workloads? What costs of concurrency do we have to take into account? …"

From the article: "Last month, I showed code for a lock-free queue that supported the limited case of exactly two threads—one producer, and one consumer. That’s useful, but maybe not as exciting now that our first rush of lock-free coding glee has worn off. This month, let’s tackle the general problem of supporting multiple producers and multiple consumers with as much concurrency as possible. The code in this article uses four main design techniques: …"

From the article: "As we saw last month, lock-free coding is hard even for experts. There, I dissected a published lock-free queue implementation and examined why the code was quite broken. This month, let’s see how to do it right. …"

From the article: "[Lock-free code is] hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction. To illustrate, let’s dissect some peer-reviewed lock-free code that was published here in DDJ just two months ago …"

From the article: "… That’s the classic deadlock example from college. Of course, two isn’t a magic number. An improved definition of deadlock is: 'When N threads enter a locking cycle where each tries to take a lock the next already holds.' 'But wait,' someone might say. 'I once had a deadlock just like the code you just showed, but it didn’t involve locks at all—it involved messages.' …"

From the article: "A commenter asked: 'thread_local X tlsX; ?? Herb, I hope you aren’t backtracking on Hungarian Notation now that you work for Microsoft. Say it aint so!' It ain’t so. ..."

An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

From the article: "What is a high-performance data structure? To answer that question, we're used to applying normal considerations like Big-Oh complexity, and memory overhead, locality, and traversal order. All of those apply to both sequential and concurrent software. But in concurrent code, we need to consider two additional things to help us pick a data structure that is also sufficiently concurrency-friendly..."

From the article: "It’s worth making a stronger demarcation among: (a) type inference, which you can do in any language; (b) static vs. dynamic typing, which is completely orthogonal but all too often confused with inference; and (c) strong vs. weak typing, which is mostly orthogonal (e.g., C is statically typed because every variable has a statically known actual type, but also weakly typed because of its casts)."

From the article: "Want to kill your parallel application's scalability? Easy: Just add a dash of contention. ... Locality is no longer just about fitting well into cache and RAM, but also about avoiding scalability busters by keeping tightly coupled data physically close together and separately used data far, far apart."

From the article: "How do you stop a thread or task you longer need or want? Table 1 summarizes the four main ways, and how they are supported on several major platforms. Let's consider them in turn..."

From the article: "This month, we'll ... consider how to achieve superlinear speedups by harnessing more resources—quite literally, running on a bigger machine without any change in the hardware."

An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

From the article: "Under what circumstances can we use P cores to do work more than P times faster? There are two main ways to enter that rarefied realm: 1. Do disproportionately less work. 2. Harness disproportionately more resources. ..."

From the article: "Back in 1967, Gene Amdahl famously pointed out what seemed like a fundamental limit to how fast you can make your concurrent code... If Amdahl's Game is rigged, well then, to paraphrase a line from the movie WarGames: The only way to win is not to play."

From the article: "... The only way to eliminate such a potential deadlock is to make sure that all mutexes ever held at the same time are acquired in a consistent order. But how can we ensure this in a way that will be both usable and correct? For example, we could try to figure out which groups of mutexes might ever be held at the same time, and then try to define pairwise ordering rules that cover each possible combination. ... We can do better by directly exploiting the knowledge we already have about the structure of the program to regularize the mess and make it understandable."

From the article: "Don't walk blindly into a deadly embrace... Our world is built on modular, composable software. We routinely expect that we don't need to know about the internal implementation details of a library or plug-in to be able to use it correctly. The problem is that locks, and most other kinds of synchronization we use today, are not modular or composable. That is, given two separately authored modules, each of which is provably correct but uses a lock or similar synchronization internally, we generally can't combine them and know that the result is still correct and will not deadlock. There are only two ways to combine such a pair of lock-using modules safely: ..."

An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

From the article: "The critical section is our One True Tool for guaranteeing mutual exclusion on mutable shared variables. ... [but] must be applied consistently, and with the intended meanings. A program must ensure that every use of a mutable shared object is properly protected using exactly one of these mechanisms at any given point in its lifetime. Chaos can erupt if code tries to avoid or invert these meanings (e.g., trying to abuse taking a lock or reading an atomic variable as a "critical section exit" operation; see Example 3), or tries to use inconsistent synchronization techniques at the same time."

From the article: "Everyone knows the basics of how to use locks:

  mut.lock(); // acquire lock on x
  ... read/write x ...
  mut.unlock(); // release lock on x

"But why do locks, lock-free styles, and other synchronization techniques work at all, never mind interoperate well with each other and with aggressive optimizers that transform and reorder your program to make it run faster? Because every synchronization technique you've ever heard of must express, and every optimization that may ever be performed must respect and uphold, the common fundamental concept of a critical section."

An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

From the article: "In your application, how many independent pieces of work are ready to run at any given time? Put another way, how many cores (or hardware threads, or nodes) can your code harness to get its answers faster? And when should the answers to these questions not be 'as many as possible'?"

From the article: "Don't fall into the pit of thinking there's no pendulum, or that the pendulum can be nailed to one side. ... Neither the center nor the edge is going to go away. We're in an expanding computing universe: The question is not whether one will replace the other, but what balance they will be in at a given point. "

From the article: "Have you ever talked with another developer about concurrency, and felt as though you were somehow speaking completely different languages? If so, you're not alone. You can see the confusion in our vocabulary..."

From the article: "I recently received the following question in email ... The difference in behavior has nothing to do with the complexity of the inheritance hierarchy or with vtables or thunking. Rather, it has to do with name lookup (in this case, finding "Method_of_A") which in turn has to do whether the static type of the object has the function you want, or whether the compiler has to look further (into base classes) to find the name."

An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

Have you ever felt that all the cool stuff was already done back in the 1950s and 1960s, back when electronic computers were new? All the cool new toys of the past decade were invented then, including garbage collection (1958), objects (1967), and generic types (1967). Incidentally, 1967 was a banner year; it also saw the first design meetings for the ARPANET. What made these things "new" again more recently is that they have been popularized by being brought, with great effort and greater reward, smack dab into the mainstream of languages and tools.

Delegating Constructors (revision 2) (with Francis Glassborow),

A Modest Proposal: Fixing ADL (revision 1),

A Modest Proposal: Fixing ADL,

Strongly Typed Enums (revision 1) (with David Miller),

Trip Report: March 2004,
C/C++ Users Journal, 22(6), June 2004.
This month, an update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.

Getting Abstractions (with Jim Hyslop),
C/C++ Users Journal, 22(6), June 2004.
Are getter and setter functions inherently evil, or are they just a little misunderstood?

Much Ado About Nothing: A (True) Null Pointer Value for C++,
C/C++ Users Journal, 22(5), May 2004.
What is the type of 0? In C and C++, there is more than one answer. And that’s a problem, because it means that when you want to point to nothing, sometimes plain old 0 and NULL just won’t do…

Enumerations (with Jim Hyslop),
C/C++ Users Journal, 22(5), May 2004.
As Stroustrup himself once wrote: “C enumerations constitute a curiously half-baked concept.” And C++ enumerations are only slightly better…

Trips Report: October-December 2003,
C/C++ Users Journal, 22(4), April 2004.
An update on the most recent C, C++, and C++/CLI standards meetings, and the progress on the C++0x standard language and library. Convergence, cooperation, goodwill -- oh my! It wasn't long ago when there was some tension between C and C++, as each language, fiercely independent, appeared determined to remain free to pursue its own path and dreams. As the poet said, 'The times, they are a-changin'...'

Using Me (with Jim Hyslop),
C/C++ Users Journal, 22(4), April 2004.
The using directive is a contentious feature -- more contentious, in fact, than it needs to be. If you choose to use it, this article examines some rules and guidelines around its use.

Delegating Constructors (revision 1) (with Francis Glassborow),

Im-Paired Programming (with Jim Hyslop),
C/C++ Users Journal, 22(3), March 2004.
std::pair can make your life easier. But as with many things, moderation is the key: excessive use can lead to unmanageable code.

A Name For the Null Pointer: nullptr (revision 2) (with Bjarne Stroustrup),

Delegating Constructors (with Francis Glassborow),

Strongly Typed Enums (with David Miller),

Virtually Misbehavin' (with Jim Hyslop),
C/C++ Users Journal, 22(2), February 2004.
C++ implicit overriding at work.

Of Many Things (with Jim Hyslop),
C/C++ Users Journal, 22(1), January 2004.
“The time has come,” the Walrus said, “to talk of many things. Of std::string -- and magic numbers -- and constness in references.”

Reusing Streams (with Jim Hyslop),
C/C++ Users Journal, 21(12), December 2003.
There once was a stream reuse style / After close() to re-open() a while / And the questions grew hot: / “Will it open or not? / Is the style ‘clearly’ vile, or worthwhile?”

Pointing in the Right Direction (with Jim Hyslop),
C/C++ Users Journal, 21(11), November 2003.
What’s in a pointer? Not much, really. Raw pointers invite memory leaks – because they cannot tell the programmer how they should be handled.

Self-Sufficient Headers (with Jim Hyslop),
C/C++ Users Journal, 21(10), October 2003.
A good C++ (and C) coding standard is that every header file should be self-sufficient. But is it always so? This article looks at the coding standard, how it applies in the presence of templates and member templates, and how nonmember functions can improve modular dependencies in addition to encapsulation.

C++/CLI Overview,

Trip Report: April 2003,
C/C++ Users Journal, 21(10), October 2003.
With 10 new standard library extensions adopted, things are heating up in Standard C++.

Generalizing Observer,
C/C++ Users Journal, 21(9), September 2003.
The tr1::function facility, recently adopted by the C++ standards committee, provides a generalized way of working with arbitrary functions when all you know (or need to know) is their approximate signature. It turns out that this facility enables us to write, among other things, generalized implementations of important design patterns like Observer. Those generalized design patterns, in turn, motivate two small but important extensions to tr1::function itself.

A Name For the Null Pointer: nullptr (with Bjarne Stroustrup),

From C++ to Shining C (with Jim Hyslop),
C/C++ Users Journal, 21(9), September 2003.
So you have a C++ type, and you have a C program that wants to use it. Is it a case of “never the twain shall meet,” or can true objects be reasonably exposed to non-object oriented languages? The twain can indeed meet, and this article shows how.

Factory Redux, Part 2 (with Jim Hyslop),
C/C++ Users Journal, 21(8), August 2003.
Revisiting the Template Method factory, with a generic<twist> to it.

(Mostly) Private,
C/C++ Users Journal, 21(7), July 2003.
In C++, to what extent are the private parts of a class really truly private? In this month’s column, we see how private names are definitely not accessible from outside nonfriend code, and yet they do leak out of a class in small ways – some of which are well-known, others of which are not.

Factory Redux, Part 1 (with Jim Hyslop),
C/C++ Users Journal, 21(7), July 2003.
Revisiting the Template Method factory, with a generic<twist> to it.

Tuples,
C/C++ Users Journal, 21(6), June 2003.
Generalized tuple types are available in other languages, though not in Standard C++. One of the first two library extensions to be adopted by the standards committee since the first standard was closed was tuple types – and it is a testament to the power of C++, particularly the power of C++ templates, that this could be done well entirely as a library, without any changes to the core language.

Imagine (with Jim Hyslop),
C/C++ Users Journal, 21(6), June 2003.
If you want to write portable code, you're going to need a lot of conditional compilation -- #if this, #else that --, right? Imagine if that were not the case...

Delegating Constructors? (with Jim Hyslop),
C/C++ Users Journal, 21(5), May 2003.
Delegating constructors aren’t (yet) supported in the C++ Standard. This article demonstrates the common technique that gets us most of the way there in Standard C++, and its drawbacks. It also demonstrates that Standard C++ does allow two apparent “workarounds” that may look good at first, but which are bad and atrocious, respectively – one of them is a simple mistake, the other an outright appeal to Machiavelli.

Sharing Causes Contention (with Jim Hyslop),
C/C++ Users Journal, 21(4), April 2003.
Following up on themes introduced in the two preceding Conversations columns, the Guru demonstrates why needless sharing might be considered harmful.

Why We Can't Afford Export (with Tom Plum),

Once Is Not Enough (with Jim Hyslop),
C/C++ Users Journal, 21(3), March 2003.
Some reasons why the ubiquitous Singleton Pattern is, perhaps, a little too ubiquitous.

Points of Order (with Jim Hyslop),
C/C++ Users Journal, 21(2), February 2003.
Of shoes, socks, arguments, and locks: Why order is important in programming as in life.

Trip Report: October 2002,
C/C++ Users Journal, 21(2), February 2003.
This month, an update on the most recent C++ standards meeting, and why things are (finally) heating up.

Value Lessons (with Jim Hyslop),
C/C++ Users Journal, 21(1), January 2003.
When is an object not an object? When it is a value. Knowing when to use value types and when to use object types can simplify your design.

Befriending Templates,
C/C++ Users Journal, 21(1), January 2003.
If you want to declare a function template specialization as a friend, how do you do it? According to the C++ Standard, there are two legal syntaxes you can choose from. According to real-world compilers, however, one of the syntaxes is widely unsupported; the other works on all current versions of popular compilers… except one.

Typedef Templates,
C/C++ Users Journal, 20(12), December 2002.
Here's a detailed look at one of the proposed extensions in C++0x, which closes a small but annoying omission in the language.

Truth or Consequences (with Jim Hyslop),
C/C++ Users Journal, 20(11), November 2002.
What’s wrong with using bool as a parameter? There are usually better ways to express what you mean. This month we turn to an expert who died before Stroustrup was born.

Export Restrictions, Part 2,
C/C++ Users Journal, 20(11), November 2002.

Proposed Addition to C++: Typedef Templates (post-meeting revision incorporating EWG direction),

C and C++: Wedding Bells?,
C/C++ Users Journal, 20(10), October 2002.
For several years now, C and C++ have been following roughly parallel but slightly divergent evolutionary paths. Despite the hype surrounding other languages, C and C++ are still the most widely used commercial programming languages in the world, and they already share a de facto community -- most compiler vendors that support C++ also support C in the same compiler, and a large community of programmers uses both C and C++. But the existing divergences between the languages are worrisome, and if unaddressed could increase further in the up-and-coming versions of those standards, C0x and C++0x. The time is ripe, some influential experts believe, to seriously consider harmonizing Standard C and Standard C++ while still allowing each to address its own vision and strengths.

Proposed Addition to C++: Typedef Templates,

Contracts, Promises, and Mere Semantics (with Jim Hyslop),
C/C++ Users Journal, 20(10), October 2002.
What is a function saying when it takes a parameter by pointer, by reference, or by value? When interface idioms lie, sometimes there's no graceful way to avoid the surprises.

Baseless Exceptions (with Jim Hyslop),
C/C++ Users Journal, 20(9), September 2002.
Implicit conversion sequences can be quite useful. But there are... well... exceptions to when they are applied.

Standard C++ Meets Managed C++,
C/C++ Users Journal, 20(9), September 2002.
Where’s Microsoft going with C++, and where’s C++ going at Microsoft? This article surveys some of the major points of compatibility and incompatibility between Standard C++ and Microsoft’s extensions for C++ on .NET, and how the two might converge more in the future.

Export Restrictions, Part 1,
C/C++ Users Journal, 20(9), September 2002.

Smart(er) Pointers,
C/C++ Users Journal, 20(8), August 2002.
This time, we take a closer look at one of the proposed new standard C++ library features being considered in the C++ standards meetings: Smart pointers, particularly those in Boost and Loki. Along the way, we also get a sneak peek at the usefulness of a proposed C++0x feature: typedef templates.

A Midsummer Night's Madness (with Jim Hyslop),
C/C++ Users Journal, 20(8), August 2002.
What do you get when you add a pointer to a typedef and mix in const? The Guru puts in her thoughts on the matter.

A Pragmatic Look at Exception Specifications,
C/C++ Users Journal, 20(7), July 2002.
Now that the community has gained experience with exception specifications, it's time to reflect on when and how they should best be used. This article considers the usefulness, or lack thereof, of exception specifications, and how the answers can vary across real-world compilers.

Getting to the Point (with Jim Hyslop),
C/C++ Users Journal, 20(7), July 2002.
While the standard auto_ptr provides a safer alternative to raw pointers, it has its limitations, and some surprising behavior. The Guru helps out by giving the narrator a boost – library, that is. The Boost library has five smart pointers that provide a rich array [sic] of useful behaviors.

The Good, the Bad, and the Deprecated (with Jim Hyslop),
C/C++ Users Journal, 20(6), June 2002.
What can go wrong when your code gives you a bit too much... er... static.

Toward a Standard C++0x Library, Part 2: Namespaces and Library Versioning,
C/C++ Users Journal, 20(5), May 2002.
(How) can you use namespaces effectively to release new versions of a library that can live peacefully with older versions? This is precisely one of the challenges now facing the C++ standard library as work begins on a major round of extensions.

Making a Real Hash of Things (with Jim Hyslop),
C/C++ Users Journal, 20(5), May 2002.
Speed often does matter. But what kind of "speed" is important when it comes to associative containers?

The Group of Seven: Extensions Under Consideration for the C++ Standard Library,
C/C++ Users Journal, 20(4), April 2002.
At the October 2001 C++ standards meeting, we began to consider proposals for extensions to the C++ standard library. The first batch consisted mainly of seven particular facilities. This column gives an overview of these facilities; next time, we'll take a closer look at one in particular.

To Sleep, Perchance (with Jim Hyslop),
C/C++ Users Journal, 20(4), April 2002.
Just how many threading and streaming mistakes can arise in one poor little dozen-line function? Quite a few, and that's not even counting the magic...

Namespaces and Library Versioning,

Template Specializations, Default Parameters, and Other Fun Stuff (with Jim Hyslop),
C/C++ Users Journal, 20(3), March 2002.
Many people know how to partially specialize a template. But what happens when the base template has a template parameter with a default value? The answer may not be quite what Bob expected...

The New C++,
C/C++ Users Journal, 20(2), February 2002.
A new C++ Standard library and language are now in the making. This is a fitting time to introduce "The New C++," a new column dedicated to keeping you up to date with the latest status of the coming brand-new release of the C++ Standard.

New Bases, Part 2 (with Jim Hyslop),
C/C++ Users Journal, 20(2), February 2002.
Basic reading and writing from a standard stream sounds simple, but can harbor its share of little complexities. Here is a simple example, with notes about the kinds of complexity that can usually be deferred.

Toward a Standard C++0x Library, Part 1,
C/C++ Users Journal, 20(1), January 2002.
The C++ standard library is going to be extended, and work in that direction is now officially under way. This article outlines some of the issues and choices involved, and how they may affect you.

New Bases, Part 1 (with Jim Hyslop),
C/C++ Users Journal, 20(1), January 2002.
Converting a text-represented number from one base to another is pretty simple. But how extensible and reusable can the solution be to solve more than one problem, when there are also additional requirements?

I'd Hold Anything for You (with Jim Hyslop),
C/C++ Users Journal, 19(12), December 2001.
There are occasions when you have a variable whose type you don't know until run time. Thanks to the Boost library, there is a safe alternative to fragile union- or void*-based solutions.

vector<bool>: More Problems, Better Solutions,

vector<bool> Is Nonconforming, and Forces Optimization Choice,

1997 & prev.