You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Herb is the author of the bestselling and highly-acclaimed Exceptional C++ books, coauthor of the landmark C++ Coding Standards, and author of hundreds of articles in print and online media. Besides these, he has contributed to other books and articles.
Books
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.
Over 80 thought-provoking articles about C++ design and programming have been published on this website and on the newsgroup comp.lang.c++.moderated. A complete web archive of past problems and solutions is available here.
Articles, Columns, and Papers (most are available online below)
Over 200 more in-depth articles and papers about object-oriented software development and C++ design and programming have been published in C/C++ Users Journal, C++ Report, Dr. Dobb's Journal, Java Report, Visual C++ Developer's Journal, and other magazines, or as C++ standards committee papers.
Updated and expanded versions of many of these articles appear in Herb's books Exceptional C++ and More Exceptional C++. Those have been tagged below with and respectively. See the books for the updated material.
"Effective Concurrency" columns are identified as "EC #nn".
"Sutter's Mill" columns are identified as "Mill #nn".
"The New C++" columns are identified as "TNC++ #nn".
"Conversations" columns (coauthored with Jim Hyslop) are identified as "Conv #nn". See also the Conversations Archive for a separate listing showing just Conversations articles and summaries.
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."
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…"
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."
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."
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."
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. ..."
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? ..."
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. ..."
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? ..."
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..."
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. ..."
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."
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: ..."
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."
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."
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.
This is a wonderful time to be a software engineer because it's a new world again: For the first time in the history of computing, mainstream computers are not von Neumann machines and never will be again—they are parallel. We have largely succeeded with the quest to put a computer in every home and purse; now we're effectively going to put a Cray into every den and pocket. That makes this is a time of enormous opportunity, as usual along with a great deal of work, as our industry now undertakes to do for parallel programming what we have already done for generic types, objects, and garbage collection.
A Design Rationale for C++/CLI, February 2005.
This paper is an all-in-one-place summary of the design goals and rationale for C++/CLI, and captures a small but representative sample of the experience gained by a number of C++ experts who have worked on defining bindings between C++ and CLI. The paper considers the requirements and several major design alternatives for a number of specific features, chosen as representative examples that cover most CLI feature areas: 1. CLI types (e.g., ref class, value class): Why new type categories are needed, and considerations for choosing the right defaults for CLI types. 2. CLI type features (e.g., property): Why new abstractions are needed for some CLI features. 3. CLI heap (e.g., ^, gcnew): Why to add a new declarator and keyword. 4. CLI generics (generic): Why the new genericity feature is distinct from templates, but compatible and highly integrated with templates. 5. C++ features (e.g., template, const): Why and how these are made to work on CLI types. The paper also includes extensive answers to some frequently asked questions about C++/CLI.
Pointers and Iterators: Off the Deep End, C/C++ Users Journal, 23(11), November 2005.
Don’t even create invalid pointers or iterators; they are undefined and nonportable. Do get a checked STL, turn all the checking on, and use it daily and automatically at least in test builds. You’ll be glad you did.
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1893 = ANSI/NCITS J16 05-0153, October 2005.
Software and the Concurrency Revolution, ACM Queue, September 2005.
The concurrency revolution is primarily a software revolution. Soon all new machines will be multicore, and the difficult problem is programming this hardware so that mainstream applications benefit from the continued exponential growth in CPU performance.
Trip Report: April 2005, C/C++ Users Journal, 23(8), August 2005..
News and views from the spring 2005 C and C++ standards meetings in Lillehammer, Norway. The big news: The C++ evolution working group has set this fall is the deadline for new proposals, after which we'll be heads-down trying to finish most of the technical work next ISO C++ standard by 2007 so that the new standard can be published in 2009. (It would be nice if the "x" in "C++0x" didn't need to be a hexadecimal digit…) This column also summarizes the main changes you can expect to C++ and why they matter to you.
Graceful Exits(with Jim Hyslop), C/C++ Users Journal, 23(7), July 2005.
When you detect an error or invalid state in a function, what’s the best way to handle it: return an error code, throw an exception, or call assert()? Well, as is frequently the case, the answer is “that depends...”
Logically Shallow Views(with Jim Hyslop), C/C++ Users Journal, 23(5), May 2005. const is logical, not physical; shallow, not deep; and a promise on the view, not necessarily a promise on the object.
Polymorphic Exceptions(with Jim Hyslop), C/C++ Users Journal, 23(4), April 2005.
What do you do when you want to throw an exception, the exception object is a derived class, but all you have is a reference to the base class?
The Trouble With Locks, C/C++ Users Journal, 23(3), March 2005.
Many people believe they understand how to write correct concurrent programs, but may not yet fully comprehend just how subtle it really is. This article focuses on the mainstream status quo approach to concurrency, lock-based programming. We will see why lock-based programming is difficult even for experts to use correctly, and why it’s fundamentally flawed for building large programs.
Implicit Virtual(with Jim Hyslop), C/C++ Users Journal, 23(3), March 2005.
One person’s “bug” is another person’s “feature.” This month, we consider the implicit nature of virtual and how it can produce cool or unsettling results in your code, depending on your point of view.
The Concurrency Revolution, C/C++ Users Journal, 23(2), February 2005.
The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency. [Note: This is an abbreviated version of the March Dr. Dobb's article.]
Order, Order(with Jim Hyslop), C/C++ Users Journal, 23(2), February 2005.
Getting the order right for a standard associative container can take a bit of thought.
Trip Report: October 2004, C/C++ Users Journal, 23(1), January 2005.
This month, an update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Tagged Unions(with Jim Hyslop), C/C++ Users Journal, 23(1), January 2005.
Some of our C heritage is slim and fast—and fragile—in the name of performance. Unions are such a beast.
Alias(with Jim Hyslop), C/C++ Users Journal, 22(12), December 2004.
When are two variables really two variables? When the real problem can be aliasing, don’t be too quick to blame macros…
How to Provide (or Avoid) Points of Customization in Templates, C/C++ Users Journal, 22(11), November 2004.
This column, drawn from one of the Items in Herb's and Andrei's new book C++ Coding Standards, is about how to program intentionally when providing and when using template libraries.
Adaptations(with Jim Hyslop), C/C++ Users Journal, 22(11), November 2004.
Say you're using multiple inheritance and each of two base classes has a virtual function with the same name. You want to provide separate overrides for each function, to be called in the context of the specific override. How do you do it?
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1719 = ANSI/NCITS J16 04-0159, October 2004.
Book excerpt from C++ Coding Standards, C/C++ Users Journal, 22(10), October 2004. The goal of the new book C++ Coding Standards is to summarize tried-and-true guidelines in concise one- and two-page Items, with extensive references to further details in the C++ literature (there are nearly 200 citations of specific sections in Stroustrup's books alone). For this excerpt, we've selected the book's opening Item and two others that appear later in the book.
Friendly Nesting(with Jim Hyslop), C/C++ Users Journal, 22(10), October 2004. This month, we consider why nested classes should (but don't) have access to the members of their enclosing class, and what the committee is doing about it.
"Just Enough" Thread Safety, C/C++ Users Journal, 22(9), September 2004.
This article is about when "good enough" is exactly what you want, and why it really is good enough.
Typedefs and Iterators: If you've Got 'Em, Use 'Em(with Jim Hyslop), C/C++ Users Journal, 22(9), September 2004.
Typedefs do more than just reduce clutter and save keystrokes; they can help smooth the transition when requirements change. Iterators are an even more powerful tool for implementation hiding and reducing coupling due to container choices. But both techniques can only help if you actually use them!
When and How to Use Exceptions, C/C++ Users Journal, 22(8), August 2004.
A clear, objective, and measurable answer to the question: "When, for what, and how should you use exceptions?"
Collecting Shared Objects(with Jim Hyslop), C/C++ Users Journal, 22(8), August 2004.
Avoid using bald pointers. Avoid using auto_ptr, instead use shared_ptr which is widely available and being added to the standard library. Store only values and smart pointers in containers; specifically, use either a container<value_type> to hold objects directly by value and ensure that they really do have value semantics, or else use a container< some_refcounted_smart_ptr<any_type> >, preferably a container< shared_ptr<any_type> >. If you don't, you'll wish you had.
Function Types, C/C++ Users Journal, 22(7), July 2004.
Function types are a little-known but widely-supported and useful feature in C++. Using typedefs of function types offers an alternative to macros with a different set of advantages and drawbacks.
Delete This Thread?(with Jim Hyslop), C/C++ Users Journal, 22(7), July 2004. Are self-deleting objects a good idea? Could they be inherently thread-unsafe? As with many thread-safety issues, a careful analysis is needed, and in this case will reveal there is no problem but only a design decision. Bob, alas, is not known for careful analysis…
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.
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.
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.
Inline Redux, C/C++ Users Journal, 21(11), November 2003.
Quick: When is inlining performed? And is it possible to write a function that can be guaranteed to never be inlined? This month, we’ll consider the many and varied opportunities for inlining, including many that are likely to surprise you. The answers, stated simply, are: "It's never too late, and nothing is impossible..."
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.
Let's Ship (humor), C/C++ Users Journal, 21(10), October 2003.
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.
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.
Generalized Function Pointers, C/C++ Users Journal, 21(8), August 2003. The 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 signature. In fact, as it turns out, you don’t even need to know the target function’s exact signature – any target function with a compatible signature, meaning one where the parameter and return types are appropriately convertible, will work just fine.
(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.
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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1426 = ANSI/NCITS J16 03-0008, March 2003.
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.
Keywords That Aren't (or, Comments By Another Name), C/C++ Users Journal Experts Forum, 21(3), March 2003.
All keywords are equal (to the parser), but some are more equal than others. In this article, we see why reserving keywords is important, because keywords are important and special. But we'll also see two keywords that have absolutely no semantic impact on a C++ program.
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.
2002
Unmanaged Pointers in C++: Parameter Evaluation, auto_ptr, and Exception Safety, C/C++ Users Journal, 20(12), December 2002.
A second excerpt from More Exceptional C++ (Items 20 and 21, drawn from the section on Exception Safety Issues and Techniques). In this excerpt, we consider a subtle issue related to parameter evaluation, why just using a smart pointer like auto_ptr doesn’t entirely solve it, and what to do about it.
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.
Memory (humor), C/C++ Users Journal, 20(12), December 2002.
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.
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.
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.
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...
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...
Extensible Templates: Via Inheritance or Traits? C/C++ Users Journal, 20(2), February 2002. Excerpted from More Exceptional C++ (Item 4, drawn from the opening section on Generic Programming and the C++ Standard Library), a discussion of traits templates and some cool traits techniques.
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.
The Naming of Types (humor), C/C++ Users Journal, 20(2), February 2002.
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.
The String Formatters of Manor Farm, C/C++ Users Journal, 19(11), November 2001. An Orwellian look at the mysteries of sprintf(), snprintf(), std::stringstream, std::strstream, and boost::lexical_cast.
Hungarian wartHogs (with Jim Hyslop), C/C++ Users Journal, 19(11), November 2001.
What's in a name? Plenty, if you use Hungarian notation. Too much, if you use Hungarian notation.
Al-Go-Rithms (with Jim Hyslop), C/C++ Users Journal, 19(10), October 2001. The Standard C Library contains some functions that are still useful in C++. Sometimes, though, you need to find your own 'rithm - algorithm, that is.
Virtuality, C/C++ Users Journal, 19(9), September 2001. Why should interfaces be nonvirtual? Why should virtuals be private? And what's with the old and hoary advice about base class destructors, and is the old hoary advice really true?
Herb Sutter - Publications
https://ift.tt/352l6ct
via www.gotw.ca http://www.gotw.ca
January 17, 2022 at 05:51PM
Herb is the author of the bestselling and highly-acclaimed Exceptional C++ books, coauthor of the landmark C++ Coding Standards, and author of hundreds of articles in print and online media. Besides these, he has contributed to other books and articles.
Books
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.
Guru of the Week
Over 80 thought-provoking articles about C++ design and programming have been published on this website and on the newsgroup comp.lang.c++.moderated. A complete web archive of past problems and solutions is available here.
Articles, Columns, and Papers (most are available online below)
Over 200 more in-depth articles and papers about object-oriented software development and C++ design and programming have been published in C/C++ Users Journal, C++ Report, Dr. Dobb's Journal, Java Report, Visual C++ Developer's Journal, and other magazines, or as C++ standards committee papers.
Updated and expanded versions of many of these articles appear in Herb's books Exceptional C++ and More Exceptional C++. Those have been tagged below with
and 
respectively. See the books for the updated material.
"Effective Concurrency" columns are identified as "EC #nn".
"Sutter's Mill" columns are identified as "Mill #nn".
"The New C++" columns are identified as "TNC++ #nn".
"Conversations" columns (coauthored with Jim Hyslop) are identified as "Conv #nn". See also the Conversations Archive for a separate listing showing just Conversations articles and summaries.
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…"
Dr. Dobb's Report, April 2009.
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. …"
Dr. Dobb's Report, March 2009.
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. ..."
Dr. Dobb's Report, February 2009.
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. …"
Dr. Dobb's Journal, 34(2), February 2009.
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. ..."
Dr. Dobb's Journal, 34(1), January 2009.
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. …"
Dr. Dobb's Journal, 33(12), December 2008.
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? …"
Dr. Dobb's Journal, 33(11), November 2008.
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: …"
Dr. Dobb's Journal, 33(10), October 2008.
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. …"
Dr. Dobb's Journal, 33(9), September 2008.
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 …"
Dr. Dobb's Journal, 33(8), August 2008.
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.' …"
Sutter's Mill, July 2008.
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. ..."
Sutter's Mill, July 2008.
An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Dr. Dobb's Journal, 33(7), July 2008.
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..."
Sutter's Mill, June 2008.
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)."
Dr. Dobb's Journal, 33(6), June 2008.
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."
Dr. Dobb's Journal, 33(5), May 2008.
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..."
Dr. Dobb's Journal, 33(4), April 2008.
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."
Sutter's Mill, March 2008.
An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Dr. Dobb's Journal, 33(3), March 2008.
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. ..."
Dr. Dobb's Journal, 33(2), February 2008.
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."
Dr. Dobb's Journal, 33(1), January 2008.
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."
Dr. Dobb's Journal, 32(12), December 2007.
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: ..."
Sutter's Mill, November 2007.
An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Dr. Dobb's Journal, 32(11), November 2007.
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."
Dr. Dobb's Journal, 32(10), October 2007.
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."
Sutter's Mill, September 2007.
An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Dr. Dobb's Journal, 32(9), September 2007.
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'?"
Sutter's Mill, August 2007.
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. "
Dr. Dobb's Journal, 32(8), August 2007.
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..."
Sutter's Mill, July 2007.
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."
Sutter's Mill, May 2007.
An update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Dr. Dobb's Journal, 31(9), September 2006.
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.
This is a wonderful time to be a software engineer because it's a new world again: For the first time in the history of computing, mainstream computers are not von Neumann machines and never will be again—they are parallel. We have largely succeeded with the quest to put a computer in every home and purse; now we're effectively going to put a Cray into every den and pocket. That makes this is a time of enormous opportunity, as usual along with a great deal of work, as our industry now undertakes to do for parallel programming what we have already done for generic types, objects, and garbage collection.
February 2005.
This paper is an all-in-one-place summary of the design goals and rationale for C++/CLI, and captures a small but representative sample of the experience gained by a number of C++ experts who have worked on defining bindings between C++ and CLI. The paper considers the requirements and several major design alternatives for a number of specific features, chosen as representative examples that cover most CLI feature areas: 1. CLI types (e.g., ref class, value class): Why new type categories are needed, and considerations for choosing the right defaults for CLI types. 2. CLI type features (e.g., property): Why new abstractions are needed for some CLI features. 3. CLI heap (e.g., ^, gcnew): Why to add a new declarator and keyword. 4. CLI generics (generic): Why the new genericity feature is distinct from templates, but compatible and highly integrated with templates. 5. C++ features (e.g., template, const): Why and how these are made to work on CLI types. The paper also includes extensive answers to some frequently asked questions about C++/CLI.
C/C++ Users Journal, 23(11), November 2005.
Don’t even create invalid pointers or iterators; they are undefined and nonportable. Do get a checked STL, turn all the checking on, and use it daily and automatically at least in test builds. You’ll be glad you did.
Delegating Constructors (revision 2) (with Francis Glassborow),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1895 = ANSI/NCITS J16 05-0155, October 2005.
A Modest Proposal: Fixing ADL (revision 1),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1893 = ANSI/NCITS J16 05-0153, October 2005.
ACM Queue, September 2005.
The concurrency revolution is primarily a software revolution. Soon all new machines will be multicore, and the difficult problem is programming this hardware so that mainstream applications benefit from the continued exponential growth in CPU performance.
C/C++ Users Journal, 23(8), August 2005..
News and views from the spring 2005 C and C++ standards meetings in Lillehammer, Norway. The big news: The C++ evolution working group has set this fall is the deadline for new proposals, after which we'll be heads-down trying to finish most of the technical work next ISO C++ standard by 2007 so that the new standard can be published in 2009. (It would be nice if the "x" in "C++0x" didn't need to be a hexadecimal digit…) This column also summarizes the main changes you can expect to C++ and why they matter to you.
Conv #60
Graceful Exits (with Jim Hyslop),
C/C++ Users Journal, 23(7), July 2005.
When you detect an error or invalid state in a function, what’s the best way to handle it: return an error code, throw an exception, or call assert()? Well, as is frequently the case, the answer is “that depends...”
A Modest Proposal: Fixing ADL,
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1792 = ANSI/NCITS J16 05-0052, May 2005.
Conv #59
Logically Shallow Views (with Jim Hyslop),
C/C++ Users Journal, 23(5), May 2005.
const is logical, not physical; shallow, not deep; and a promise on the view, not necessarily a promise on the object.
Conv #58
Polymorphic Exceptions (with Jim Hyslop),
C/C++ Users Journal, 23(4), April 2005.
What do you do when you want to throw an exception, the exception object is a derived class, but all you have is a reference to the base class?
C/C++ Users Journal, 23(3), March 2005.
Many people believe they understand how to write correct concurrent programs, but may not yet fully comprehend just how subtle it really is. This article focuses on the mainstream status quo approach to concurrency, lock-based programming. We will see why lock-based programming is difficult even for experts to use correctly, and why it’s fundamentally flawed for building large programs.
Conv #57
Implicit Virtual (with Jim Hyslop),
C/C++ Users Journal, 23(3), March 2005.
One person’s “bug” is another person’s “feature.” This month, we consider the implicit nature of virtual and how it can produce cool or unsettling results in your code, depending on your point of view.
Dr. Dobb's Journal, 30(3), March 2005.
The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency.
C/C++ Users Journal, 23(2), February 2005.
The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency. [Note: This is an abbreviated version of the March Dr. Dobb's article.]
Conv #56
Order, Order (with Jim Hyslop),
C/C++ Users Journal, 23(2), February 2005.
Getting the order right for a standard associative container can take a bit of thought.
C/C++ Users Journal, 23(1), January 2005.
This month, an update on the most recent C++ standards meeting, and the progress on the C++0x standard language and library.
Conv #55
Tagged Unions (with Jim Hyslop),
C/C++ Users Journal, 23(1), January 2005.
Some of our C heritage is slim and fast—and fragile—in the name of performance. Unions are such a beast.
C/C++ Users Journal, 22(12), December 2004.
C++, the real world, and link and binary compatibility.
Conv #54
Alias (with Jim Hyslop),
C/C++ Users Journal, 22(12), December 2004.
When are two variables really two variables? When the real problem can be aliasing, don’t be too quick to blame macros…
C/C++ Users Journal, 22(11), November 2004.
This column, drawn from one of the Items in Herb's and Andrei's new book C++ Coding Standards, is about how to program intentionally when providing and when using template libraries.
Conv #53
Adaptations (with Jim Hyslop),
C/C++ Users Journal, 22(11), November 2004.
Say you're using multiple inheritance and each of two base classes has a virtual function with the same name. You want to provide separate overrides for each function, to be called in the context of the specific override. How do you do it?
Strongly Typed Enums (revision 1) (with David Miller),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1719 = ANSI/NCITS J16 04-0159, October 2004.
C/C++ Users Journal, 22(10), October 2004.
The goal of the new book C++ Coding Standards is to summarize tried-and-true guidelines in concise one- and two-page Items, with extensive references to further details in the C++ literature (there are nearly 200 citations of specific sections in Stroustrup's books alone). For this excerpt, we've selected the book's opening Item and two others that appear later in the book.
C/C++ Users Journal, 22(10), October 2004.
This month, we consider why nested classes should (but don't) have access to the members of their enclosing class, and what the committee is doing about it.
C/C++ Users Journal, 22(9), September 2004.
This article is about when "good enough" is exactly what you want, and why it really is good enough.
Conv #51
Typedefs and Iterators: If you've Got 'Em, Use 'Em (with Jim Hyslop),
C/C++ Users Journal, 22(9), September 2004.
Typedefs do more than just reduce clutter and save keystrokes; they can help smooth the transition when requirements change. Iterators are an even more powerful tool for implementation hiding and reducing coupling due to container choices. But both techniques can only help if you actually use them!
C/C++ Users Journal, 22(8), August 2004.
A clear, objective, and measurable answer to the question: "When, for what, and how should you use exceptions?"
Conv #50
Collecting Shared Objects (with Jim Hyslop),
C/C++ Users Journal, 22(8), August 2004.
Avoid using bald pointers. Avoid using auto_ptr, instead use shared_ptr which is widely available and being added to the standard library. Store only values and smart pointers in containers; specifically, use either a container<value_type> to hold objects directly by value and ensure that they really do have value semantics, or else use a container< some_refcounted_smart_ptr<any_type> >, preferably a container< shared_ptr<any_type> >. If you don't, you'll wish you had.
C/C++ Users Journal, 22(7), July 2004.
Function types are a little-known but widely-supported and useful feature in C++. Using typedefs of function types offers an alternative to macros with a different set of advantages and drawbacks.
Conv #49
Delete This Thread? (with Jim Hyslop),
C/C++ Users Journal, 22(7), July 2004.
Are self-deleting objects a good idea? Could they be inherently thread-unsafe? As with many thread-safety issues, a careful analysis is needed, and in this case will reveal there is no problem but only a design decision. Bob, alas, is not known for careful analysis…
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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1618 = ANSI/NCITS J16 04-0058, March 2004.
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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1601 = ANSI/NCITS J16 04-0041, February 2004.
Delegating Constructors (with Francis Glassborow),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1581 = ANSI/NCITS J16 04-0021, February 2004.
Strongly Typed Enums (with David Miller),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1579 = ANSI/NCITS J16 04-0019, February 2004.
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.
C/C++ Users Journal, 21(11), November 2003.
Quick: When is inlining performed? And is it possible to write a function that can be guaranteed to never be inlined? This month, we’ll consider the many and varied opportunities for inlining, including many that are likely to surprise you. The answers, stated simply, are: "It's never too late, and nothing is impossible..."
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/C++ Users Journal, 21(10), October 2003.
C++/CLI Overview,
ISO C++ committee presentation, ISO/IEC JTC1/SC22/WG21 N1557 = ANSI/NCITS J16 03-0140, October 2003.
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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1488 = ANSI/NCITS J16 03-0071, September 2003.
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.
Generalized Function Pointers,
C/C++ Users Journal, 21(8), August 2003.
The 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 signature. In fact, as it turns out, you don’t even need to know the target function’s exact signature – any target function with a compatible signature, meaning one where the parameter and return types are appropriately convertible, will work just fine.
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.
C/C++ Users Journal, 21(8), August 2003.
(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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1426 = ANSI/NCITS J16 03-0008, March 2003.
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.
Keywords That Aren't (or, Comments By Another Name),
C/C++ Users Journal Experts Forum, 21(3), March 2003.
All keywords are equal (to the parser), but some are more equal than others. In this article, we see why reserving keywords is important, because keywords are important and special. But we'll also see two keywords that have absolutely no semantic impact on a C++ program.
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.
C/C++ Users Journal, 20(12), December 2002.
A second excerpt from More Exceptional C++ (Items 20 and 21, drawn from the section on Exception Safety Issues and Techniques). In this excerpt, we consider a subtle issue related to parameter evaluation, why just using a smart pointer like auto_ptr doesn’t entirely solve it, and what to do about it.
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.
C/C++ Users Journal, 20(12), December 2002.
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),
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1406 = ANSI/NCITS J16 02-0064, October 2002.
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,
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1373 = ANSI/NCITS J16 02-0031, October 2002.
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...
C/C++ Users Journal, 20(4), April 2002.
My review of Andrei's landmark book.
C/C++ Users Journal, 20(4), April 2002.
Namespaces and Library Versioning,
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1344 = ANSI/NCITS J16 02-0002, March 2002.
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...
C/C++ Users Journal, 20(2), February 2002.
Excerpted from More Exceptional C++ (Item 4, drawn from the opening section on Generic Programming and the C++ Standard Library), a discussion of traits templates and some cool traits techniques.
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.
C/C++ Users Journal, 20(2), February 2002.
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.
C/C++ Users Journal, 19(11), November 2001.
An Orwellian look at the mysteries of sprintf(), snprintf(), std::stringstream, std::strstream, and boost::lexical_cast.
C/C++ Users Journal, 19(11), November 2001.
What's in a name? Plenty, if you use Hungarian notation. Too much, if you use Hungarian notation.
C/C++ Users Journal, 19(10), October 2001.
The Standard C Library contains some functions that are still useful in C++. Sometimes, though, you need to find your own 'rithm - algorithm, that is.
C/C++ Users Journal, 19(9), September 2001.
Why should interfaces be nonvirtual? Why should virtuals be private? And what's with the old and hoary advice about base class destructors, and is the old hoary advice really true?
C/C++ Users Journal, 19(9), September 2001.
C/C++ Users Journal, 19(8), August 2001.
C/C++ Users Journal, 19(7), July 2001.
C/C++ Users Journal, 19(7), July 2001.
C/C++ Users Journal, 19(6), June 2001.
C/C++ Users Journal, 19(5), May 2001.
C/C++ Users Journal, 19(5), May 2001.
C/C++ Users Journal, 19(4), April 2001.
C/C++ Users Journal, 19(4), April 2001.
C/C++ Users Journal, 19(3), March 2001.
C/C++ Users Journal, 19(3), March 2001.
C/C++ Users Journal, 19(2), February 2001.
C/C++ Users Journal, 19(1), January 2001.
C/C++ Users Journal, 19(1), January 2001.
C/C++ Users Journal, 18(12), December 2000.
C/C++ Users Journal, 18(11), November 2000.
C/C++ Users Journal, 18(11), November 2000.
Dr. Dobb's Journal, 25(10), October 2000.
C/C++ Users Journal, 18(9), September 2000.
Java Report, 5(7), July 2000; and
C++ Report, 12(7), July/August 2000.
C++ Report, 12(7), July/August 2000.
C++ Report, 12(6), June 2000.
C++ Report, 12(4), April 2000.
C++ Report, 12(3), March 2000.
Visual C++ Developers Journal, 2(1), January/February 2000.
C/C++ Users Journal, 17(10), October 1999.
vector<bool>: More Problems, Better Solutions,
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1211 = ANSI/NCITS J16 99-0035, October 1999.
C++ Report, 11(9), October 1999.
C++ Report, 11(7), July/August 1999.
C/C++ Users Journal, 17(6), June 1999.
C++ Report, 11(5), May 1999.
C++ Report, 11(3), March 1999.
vector<bool> Is Nonconforming, and Forces Optimization Choice,
ISO C++ committee paper, ISO/IEC JTC1/SC22/WG21 N1185 = ANSI/NCITS J16 99-0008, February 1999.
C++ Report, 11(1), January 1999.
C++ Report, 10(9), October 1998.
C++ Report, 10(9), October 1998.
C++ Report, 10(7), July/August 1998.
C++ Report, 10(5), May 1998.
C++ Report, 10(4), April 1998.
C++ Report, 10(3), March 1998.
C++ Report, 10(1), January 1998.
1997 & prev.
C++ Report, 9(10), November/December 1997.
C++ Report, 9(9), October 1997.
C++ Report, 9(8), September 1997.
The Computer Freelancer, 1995-1997.
The text was updated successfully, but these errors were encountered: