C++ FAQ

Welcome to the C++ Super-FAQ!

What’s “Super” about this FAQ? In part it’s because this is a merger of two great FAQs:
Marshall Cline’s C++ FAQs, and Bjarne Stroustrup’s C++ FAQ. And in part it’s because this is a
wiki being continuously updated for modern C++. There are some FAQ topics not yet updated; if
you spot one, suggest an improvement using the link on the bar for that FAQ.
We would like to gratefully acknowledge Pearson Education (Addison-Wesley), Marshall
Cline, Bjarne Stroustrup, Herb Sutter, and Andrei Alexandrescu for launching this FAQ by freely
contributing the contents of Marshall Cline’s online C++ FAQ Lite, Bjarne Stroustrup’s online C+
+ and C++11 FAQs, and in the near future material from their books C++ FAQs Second Edition by
Marshall Cline, Greg Lomow, and Mike Girou, and C++ Coding Standards by Herb Sutter and
Andrei Alexandrescu.

C++ FAQ Sections

Overview Topics

 Big Picture Issues

 Newbie Questions & Answers
 Learning OO/C++
 Coding Standards
Starting From Another Language

 Learning C++ if you already know Objective-C

 Learning C++ if you already know C# or Java
 Learning C++ if you already know C
 How to mix C and C++
General Topics

 Built-in / Intrinsic / Primitive Data Types

 Input/output via <iostream> and <cstdio>
 Const Correctness
 References
 Memory Management
Classes and Inheritance

 Classes and Objects

 Constructors
 Destructors
 Assignment Operators
 Operator Overloading
 Friends
 Inheritance — Basics
 Inheritance — virtual functions
 Inheritance — Proper Inheritance and Substitutability
 Inheritance — Abstract Base Classes (ABCs)
 Inheritance — What your mother never told you
 Inheritance — private and protected inheritance
 Inheritance — Multiple and Virtual Inheritance
Beyond Classes

 Templates
 Container Classes
 Class Libraries
 Exceptions and Error Handling
 Reference and Value Semantics
 Inline Functions
 Pointers to Member Functions
 Serialization and Unserialization
C++11

 C++11 Overview
 C++11 Language Extensions — General Features
 C++11 Language Extensions — Classes
 C++11 Language Extensions — Other Types
 C++11 Language Extensions — Templates
 C++11 Language Extensions — Concurrency
 C++11 Language Extensions — Miscellaneous Language Features
 C++11 Library Extensions — General Libraries
 C++11 Library Extensions — Containers and Algorithms
 C++11 Library Extensions — Concurrency
C++14

 C++14 Overview
 C++14 Language Extensions
 C++14 Library Extensions
Miscellaneous Q&A

 Compiler Dependencies
 Miscellaneous Technical Issues
 Miscellaneous Environmental Issues
 Miscellaneous Style Issues
 C++0x Concepts — Historical FAQs
 Myths and Urban Legends About C++
 Partial List of ISO C++ Committee Members

Big Picture Issues

Contents of this section:

 What is C++?
 Is C++ a practical language?
 Is C++ a perfect language?
 What is the zero-overhead principle?
 What’s so great about classes?
 What’s the big deal with OO?
 What’s the big deal with generic programming?
 What is multiparadigm programming?
 Is C++ better than Java? (or C#, C, Objective-C, JavaScript, Ruby, Perl, PHP, Haskell,
FORTRAN, Pascal, Ada, Smalltalk, or any other language?)
 Why is C++ so big?
 Who uses C++?
 How long does it take to learn C++?
 What’s the best way to improve my C++ programs?
 Does it matter which programming language I use?
 What are some features of C++ from a business perspective?
 Are virtual functions (dynamic binding) central to OO/C++?
 I’m from Missouri. Can you give me a simple reason why virtual functions (dynamic
binding, dynamic polymorphism) and templates (static polymorphism) make a big difference?
 Is C++ backward compatible with ANSI/ISO C?
 Why is C++ (almost) compatible with C?
 When was C++ invented?
 Why was C++ invented?
 Where did the name C++ come from?
 Why does C++ allow unsafe code?
 Why are some things left undefined in C++?
 Why is portability considered so important?
 Is C++ standardized?
 Who is on the standardization committee?
 Where can I get a copy of the C++ standard?
 What is the difference between C++98 and C++03?
 What is the difference between C++98 and C++0x?
 What is the difference between C++98 and C++11?
 What is the difference between C++11 and C++14?
 What are some “interview questions” I could ask that would let me know if candidates really
know their stuff?
 What does the FAQ mean by “such and such is evil”?
 Will I sometimes use any so-called “evil” constructs?
 Is it important to know the technical definition of “good OO”? Of “good class design”?
 What should I tell people who complain that the word “FAQ” is misleading, that it
emphasizes the questions rather than the answers, and that we should all start using a different
acronym?
 How can I help make the C++ FAQ even better??!??
What is C++?
C++ is a general-purpose programming language with a bias towards systems programming that
 is a better C
 supports data abstraction (e.g., classes)
 supports object-oriented programming (e.g., inheritance)
 supports generic programming (e.g., reusable generic containers and algorithms)
 supports functional programming (e.g., template metaprogramming, lambda
functions, constexpr)
It is defined by an ISO standard, offers stability over decades, and has a large and lively user
community. See also The C++ Programming Language and Evolving a language in and for the real
world: C++ 1991-2006.
See also when and why C++ was invented.
 Is C++ a practical language?
Yes.
C++ is a practical tool. It’s not perfect, but it’s useful.
In the world of industrial software, C++ is viewed as a solid, mature, mainstream tool. It has
widespread industry support which makes it “good” from an overall business perspective.
Is C++ a perfect language?
Nope.
C++ wasn’t designed to demonstrate what a perfect language looks like. It was designed to be a
practical tool for solving real world problems. It has a few warts, as do all practical programming
tools, but the only place where it’s appropriate to keep fiddling with something until it’s perfect is in
a pure academic setting. That wasn’t C++’s goal.

What is the zero-overhead principle?

The zero-overhead principle is a guiding principle for the design of C++. It states that: What you
don’t use, you don’t pay for (in time or space) and further: What you do use, you couldn’t hand code any
better.
In other words, no feature should be added to C++ which would make any existing code (not using
the new feature) larger or slower, nor should any feature be added for which the compiler would
generate code that is not as good as a programmer would create without using the feature.

What’s so great about classes?

Classes are there to help you organize your code and to reason about your programs. You could
roughly equivalently say that classes are there to help you avoid making mistakes and to help you
find bugs after you do make a mistake. In this way, classes significantly help maintenance.
A class is the representation of an idea, a concept, in the code. An object of a class represents a
particular example of the idea in the code. Without classes, a reader of the code would have to guess
about the relationships among data items and functions – classes make such relationships explicit
and “understood” by compilers. With classes, more of the high-level structure of your program is
reflected in the code, not just in the comments.
A well-designed class presents a clean and simple interface to its users, hiding its representation and
saving its users from having to know about that representation. If the representation shouldn’t be
hidden – say, because users should be able to change any data member any way they like – you can
think of that class as “just a plain old data structure”; for example:
1. struct Pair {
2. Pair(const string& n, const string& v) : name(n), value(v) { }
3. string name, value;
4. };
Note that even data structures can benefit from auxiliary functions, such as constructors. When
designing a class, it is often useful to consider what’s true for every object of the class and at all
times. Such a property is called an invariant. For example, the invariant of a vector could be that
(a) its representation consists of a pointer to a number of elements and (b) that number of elements
is stored in an integer. It is the job of every constructor to establish the class invariant, so that every
member function can rely on it. Every member function must leave the invariant valid upon exit.
This kind of thinking is particularly useful for classes that manage resources such as locks, sockets,
and files. For example, a file handle class will have the invariant that it holds a pointer to an open
 file. The file handle constructor opens the file. Destructors free resources acquired by constructors.
For example, the destructor for a file handle closes the file opened by the constructor:
1. class File_handle {
2. public:
3. File_handle(const char* n, const char* rw)
4. { f = fopen(n,rw); if (f==nullptr) throw Open_failure(n); }
5. ~File_handle() { fclose(f); } // destructor
6. // ...
7. private:
8. FILE* f;
9. };
If you haven’t programmed with classes, you will find parts of this explanation obscure and you’ll
underestimate the usefulness of classes. Look for examples. Like all good textbooks, TC++PL has
lots of examples; for example, see A Tour of the Standard Library. Most modern C++ libraries
consist (among other things) of classes and a library tutorial is one of the best places to look for
examples of useful classes.
What’s the big deal with OO?
Object-oriented techniques using classes and virtual functions are an important way to develop
large, complex software applications and systems. So are generic programming techniques using
templates. Both are important ways to express polymorphism – at run time and at compile time,
respectively. And they work great together in C++.
There are lots of definitions of “object oriented”, “object-oriented programming”, and “object-
oriented programming languages”. For a longish explanation of what Stroustrup thinks of as “object
oriented”, read Why C++ isn’t just an object-oriented programming language. That said, object-
oriented programming is a style of programming originating with Simula (about 40 years ago!)
relying on encapsulation, inheritance, and polymorphism. In the context of C++ (and of many other
languages with their roots in Simula), it means programming using class hierarchies and virtual
functions to allow manipulation of objects of a variety of types through well-defined interfaces and
to allow a program to be extended incrementally through derivation.
See whats so great about classes for an idea about what’s great about “plain classes”. The point
about arranging classes into a class hierarchy is to express hierarchical relationships among classes
and to use those relationships to simplify code.
To really understand OOP, look for some examples. For example, you might have two (or more)
device drivers with a common interface:
1. class Driver { // common driver interface
2. public:
3. virtual int read(char* p, int n) = 0; // read max n characters from device to p
4. // return the number of characters read
5. virtual bool reset() = 0; // reset device
6. virtual Status check() = 0; // read status
7. };
This Driver is simply an interface. It is defined with no data members and a set of pure virtual
functions. A Driver can be used through this interface and many different kinds of drivers can
implement this interface:
1. class Driver1 : public Driver { // a driver
2. public:
3. Driver1(Register); // constructor
4. int read(char*, int n) override;
5. bool reset() override;
6. Status check() override;
7. private:
8. // implementation details, including representation
9. };
10.
11. class Driver2 : public Driver { // another driver
12. public:
13. Driver2(Register);
14. int read(char*, int n) override;
15. bool reset() override;
16. Status check() override;
17. private:
18. // implementation details, including representation
19. };
Note that these drivers hold data (state) and objects of them can be created. They implement the
functions defined in Driver. We can imagine a driver being used like this:
1. void f(Driver& d) // use driver
2. {
3. Status old_status = d.check();
4. // ...
5. d.reset();
6. char buf[512];
7. int x = d.read(buf,512);
8. // ...
9. }
The key point here is that f() doesn’t need to know which kind of driver it uses; all it needs to
know is that it is passed a Driver; that is, an interface to many different kinds of drivers. We could
invoke f() like this:
1. void g()
2. {
3. Driver1 d1(Register(0xf00)); // create a Driver1 for device
4. // with device register at address 0xf00
5.
6. Driver2 d2(Register(0xa00)); // create a Driver2 for device
7. // with device register at address 0xa00
8. // ...
9. int dev;
10. cin >> dev;
11.
12. if (dev==1)
13. f(d1); // use d1
14. else
15. f(d2); // use d2
16. // ...
17. }
Note that when f() uses a Driver the right kind of operations are implicitly chosen at run time.
For example, when f() is passed d1, d.read() uses Driver1::read(), whereas when f() is
passed d2, d.read() uses Driver2::read(). This is sometimes called run-time dispatch or
dynamic dispatch. In this case there is no way that f() could know the kind of device it is called
with because we choose it based on an input.
Please note that object-oriented programming is not a panacea. “OOP” does not simply mean
“good” – if there are no inherent hierarchical relationships among the fundamental concepts in your
problem then no amount of hierarchy and virtual functions will improve your code. The strength of
OOP is that there are many problems that can be usefully expressed using class hierarchies – the
main weakness of OOP is that too many people try to force too many problems into a hierarchical
mold. Not every program should be object-oriented. As alternatives, consider plain classes, generic
programming, and free-standing functions (as in math, C, and Fortran).
If you’re still wondering “why OO?”, consider also business reasons:
 The software industry is succeeding at automating many of life’s functions that used to be manual.
In addition, software is improving the flexibility of devices that were previously automated, for
example, transforming the internal implementation of many previously existing devices from
mechanical to software (clocks, automobile ignition systems, etc.) or from being controlled by
electrical circuitry to software (TVs, kitchen appliances, etc.). And, of course, software is integrated
into every aspect of our daily business lives — originally software was limited to Accounting and
Finance, but it is now embedded in Operations, Marketing, Sales, and Management — software is
nearly everywhere.
This incredible success has constantly stressed the ability of the software development organizations
to keep up. As an industry, software development has continuously failed to meet the demands for
large, complex software systems. Yes, this failure is actually due to the success of software’s ability
to bring perceived value — it is actually caused because demand is greater than our ability to satisfy
that demand. And while it is possible for us software people to sit around and pat ourselves on the
back for that demand, innovators and thought leaders in this and every other discipline are marked
by one undeniable characteristic: they/we are not satisfied. As an industry, we must do better.
A lot better. Uber better.
Our past successes have propelled users to ask for more. We created a market hunger that Structured
Analysis, Design and Programming techniques have not been able to satisfy. This required us to
create a better paradigm. Several, in fact.
C++ supports OO programming. C++ can also be used as a traditional, imperative programming
language (“as a better C”) or using the generic programming approach. Naturally each of these
approaches has its pros and cons; don’t expect the benefits of one technique while using another.
(Most common case of misunderstanding: don’t expect to get the benefits of object-oriented
programming if you’re using C++ as a better C.)
C++ also supports the generic programming approach. And most recently C++ is starting to support
(as opposed to merely allow) the functional programming approach. The best programmers are able
to decide which approach fits best in which situation, rather than trying to shove a single approach
(“my favorite approach”) at every problem everywhere in every industry irrespective of the business
context or the sponsor’s goals.
Most importantly, sometimes the best solution is achieved by using a combination of features from
Object-Oriented, Generic and Functional programming styles, whereas trying to restrict oneself to
one particular approach may lead to a suboptimal solution.

What’s the big deal with generic programming?

Generic programming techniques using templates are an important way to develop large, complex
software applications and systems. So are object oriented techniques. Both are important ways to
express polymorphism – at compile time and at run time, respectively. And they work great together
in C++.
C++ supports generic programming. Generic programming is a way of developing software that
maximizes code reuse in a way that does not sacrifice performance. (The “performance” part isn’t
strictly necessary, but it is highly desirable.)
Generic programming is programming based on parameterization: You can parameterize a type with
another (such as a vector with its element types) and an algorithm with another (such as a sort
function with a comparison function). The aim of generic programming is to generalize a useful
algorithm or data structure to its most general and useful form. For example, a vector of integers is
fine and so is a function that finds the largest value in a vector of integers. However, a better
generic find function will be able to find an element in a vector of any type or better still in any
sequence of elements described with a pair of iterators:
1. auto p = find(begin(vs), end(vs), "Grail"s); // vector<string> vs; p is vector<string>::iterator
2.
3. auto q = find(begin(vi), end(vi), 42); // vector<int> vi; q is vector<int>::iterator
4.
5. auto r = find(begin(ld), end(ld), 1.2); // list<double> ld; r is list<double>::iterator
6.
7. auto s = find(begin(ar), end(ar), 10); // int ar[10]; s is int *
These examples are from the STL (the containers and algorithms part of the ISO C++ standard
library); for a brief introduction, see A Tour of the Standard Library from TC++PL.
Generic programming is in some ways more flexible than object-oriented programming. In
particular, it does not depend on hierarchies. For example, there is no hierarchical relationship
between an int and a string. Generic programming is generally more structured than OOP; in
fact, a common term used to describe generic programming is “parametric polymorphism”, with “ad
hoc polymorphism” being the corresponding term for object-oriented programming. In the context
of C++, generic programming resolves all names at compile time; it does not involve dynamic (run-
time) dispatch. This has led generic programming to become dominant in areas where run-time
performance is important.
Please note that generic programming is not a panacea. There are many parts of a program that need
no parameterization and many examples where run-time dispatch (OOP) is more approriate.
Generic components are pretty easy to use, at least if they’re designed well, and they tend to hide a
lot of complexity. The other interesting feature is that they tend to make your code faster,
particularly if you use them more. This creates a pleasant non-tradeoff: when you use the
components to do the nasty work for you, your code gets smaller and simpler, you have less chance
of introducing errors, and your code will often run faster.
Most developers are not cut out to create these generic components, but most can use them.
Fortunately generic components are, um, generic, so your organization does not often need to create
a lot of them. There are many off-the-shelf libraries of generic components. STL is one such
library. Boost has a bunch more.
What is multiparadigm programming?
In short: The same as just “programming,” using different features (notably OO and generic styles)
in combination as needed.
Back when having OO and generic programming in the same language was still new,
“multiparadigm programming” was originally a fancy way of saying “programming using more
than one programming style, each to its best effect.” For example, using object-oriented
programming when run-time resolution between different object types is required and generic
programming when static type safety and run-time performance is at a premium. Naturally, the main
strength of multiparadigm programming is in programs where more than one paradigm
(programming style) is used, so that it would be hard to get the same effect by composing a system
out of parts written in languages supporting different paradigms. The most compelling cases for
multiparadigm programming are found where techniques from different paradigms are used in close
collaboration to write code that is more elegant and more maintainable than would be possible
within a single paradigm. A simple example is the traversal of a statically typed container of objects
of a polymorphic type:
1. void draw_all(vector<Shape*>& vs) // draw each element of a standard vector
2. {
3. for_each(vs.begin(),vs.end(),[](Shape* p){ p->draw(); });
4. }
Here, Shape will be an abstract base class defining the interface to a hierarchy of geometric shapes.
This example easily generalizes to any standard library container:
1. template<class C>
2. void draw_all(C& cs) // draw each element of a standard container
3. {
4. for_each(cs.begin(),cs.end(),[](Shape* p){ p->draw(); });
5. }
Is this OOP, GP, functional, or conventional structured programming? All of the above: It’s a
function template (GP) with a procedural body (conventional structured) that uses a generic
algorithm (GP again) and a lambda (functional) that takes a pointer to a base class and invokes a
virtual function (OO). The key point is that this is all just “programming.”
So today instead of “multiparadigm programming” we should simply say “programming.” It’s all
programming, just using the right language features together in combination as usual.

Is C++ better than Java? (or C#, C, Objective-C,

JavaScript, Ruby, Perl, PHP, Haskell, FORTRAN, Pascal,
Ada, Smalltalk, or any other language?)
Stop. This question generates much much more heat than light. Please read the following before
posting some variant of this question.
In 99% of the cases, programming language selection is dominated by business
considerations, not by technical considerations. Things that really end up mattering are things like
availability of a programming environment for the development machine, availability of runtime
environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or
development environments, availability of trained developers, availability of consulting services,
and corporate culture/politics. These business considerations generally play a much greater role than
compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic
binding, etc.
Those who ignore the (dominant!) business criteria when evaluating programming language
tradeoffs expose themselves to criticism for having poor judgment. Be technical, but don’t be a
techie weenie. Business issues really do dominate technical issues, and those who don’t realize that
is destined to make decisions that have terrible business consequences — they are dangerous to their
employer.
The most widely circulated comparisons tend to be those written by proponents of some language,
Z, to prove that Z is better that other languages. Given its wide use, C++ is often top of the list of
languages that the proponents of Z wants to prove inferior. Often, such papers are “published” or
distributed by a company that sells Z as part of a marketing campaign. Surprisingly, many seem to
take an unreviewed paper written by people working for a company selling Z “proving” that Z is
best seriously. One problem is that there are always grains of truth in such comparisons. After all,
no language is better than every other in all possible ways. C++ certainly isn’t perfect, but selective
truth can be most seductive and occasionally completely misleading. When looking at a language
comparison consider who wrote it, consider carefully if the descriptions are factual and fair, and
also if the comparison criteria are themselves fair for all languages considered. This is not easy.
Stroustrup refuses to compare C++ to other languages for these reasons given in The Design and
Evolution of C++:
“Several reviewers asked me to compare C++ to other languages. This I have decided against doing.
Thereby, I have reaffirmed a long-standing and strongly held view: Language comparisons are
rarely meaningful and even less often fair. A good comparison of major programming languages
requires more effort than most people are willing to spend, experience in a wide range of application
areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not
have the time, and as the designer of C++, my impartiality would never be fully credible.
 I also worry about a phenomenon I have repeatedly observed in honest attempts at language
comparisons. The authors try hard to be impartial, but are hopelessly biased by focusing on a single
application, a single style of programming, or a single culture among programmers. Worse, when
one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in
the well-known language are deemed minor and simple workarounds are presented, whereas similar
flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the
less-well-known languages are simply unknown to the people doing the comparison or deemed
unsatisfactory because they would be unworkable in the more familiar language.
Similarly, information about the well-known language tends to be completely up-to-date, whereas
for the less-known language, the authors rely on several-year-old information. For languages that
are worth comparing, a comparison of language X as defined three years ago vs. language Y as it
appears in the latest experimental implementation is neither fair nor informative. Thus, I restrict my
comments about languages other than C++ to generalities and to very specific comments.”
That said, C++ is considered to be the best choice in programming language for a wide variety of
people and applications.

Why is C++ so big?

C++ is not a tiny language designed to be a minimal language for teaching, but neither are the
languages people most often compare it to, such as C, Java, C#. They too are huge compared to say,
Pascal as Dr. Wirth originally defined it – for good reasons. The programming world is far more
complex today than it was 30 years ago, and modern programming languages reflect that.
C++ isn’t as big as some people imagine. By word count, the size of the language specifications
(excluding standard libraries) for C++, C#, and Java are currently within a few percentage points of
each other. This reflects that they are general-purpose mainstream languages that have grown
similar features – auto/var type deduction, range for loops, lambda functions, various levels of
support for generic programming, and so on. It also reflects what design theorists call “essential
complexity in the problem domain” – the complexity in the real world and that a serious language
has to expose, everything from fundamental OS differences to calling C++ libraries.
In some cases C++ directly supports (i.e., in the language) what some other languages support
through libraries, so the language part will be relatively larger. On the other hand, if you want to
write a “typical modern application”, you need to consider operating system interfaces, GUI,
databases, web interfaces, etc. the sum of language features, libraries, and programming
conventions and standards that you must become familiar with dwarf the programming language.
Here, C++’s size can be an advantage as far as it better supports good libraries.
Finally, the days where a novice programmer can know all of a language are gone, at least for the
languages in widespread industrial use. Few people know “all of C” or “all of Java” either and none
of those are novices. It follows that nobody should have to apologize for the fact that novices do not
know all of C++. What you must do - in any language – is to pick a subset, get working writing
code, and gradually learn more of the language, its libraries, and its tools. For my suggestion on
how beginners can approach C++, see Programming: Principles and Practice using C++.
Who uses C++?
Lots and lots of companies and government sites. Lots. And if you’re using a compiler or runtime of
another language, such as Java, chances are good that it too is implemented in C++.
There are too many C++ users to effectively count them, but the number is in the millions. C++ is
supported by all major vendors. The large number of developers (and therefore the large amount of
available support infrastructure including vendors, tools, training, etc.) is one of several critical
features of C++.
 During 1980-1991, the number of users doubled every seven and a half months (see The Design and
Evolution of C++). The current growth rate is steady and positive. IDC’s 2001 estimate of the
number of C++ programmers was “about 3 million”; their 2004 number was “more than 3 million.”
That seems plausible and indicates a continued growth. Especially since about 2010 there is a
renewed growth in C++ as both mobile and datacenter applications value “performance per Watt” as
a new mainstream metric.
How long does it take to learn C++?
That depends on what you mean by “learning.” If you are a C programmer you can learn enough C+
+ to make you more effective at C-style programming in a day.
The book Programming: Principles and Practice using C++ has been used to get thousands of
freshmen (1st year students) through the fundamentals of C++ and the programming techniques it
supports (notably object-oriented programming and generic programming) in a semester.
On the other hand, if you want to be fully comfortable with all the major C++ language constructs,
with data abstraction, Object-Oriented programming, generic programming, Object-Oriented design,
etc., you can easily spend a year or two – if you aren’t already acquainted with those techniques
(say, from Java or C#).
Is that then the time it takes to learn C++? Maybe, but then again, that is the timescale we have to
consider to become better designers and programmers. If a dramatic change of the way we work and
think about building systems isn’t our aim, then why bother to learn a new language? Compared to
the time required to learn to play the piano well or to become fluent in a foreign (natural) language,
learning a new and different programming language and programming style is easy.
For more observations about learning C++ see D&E or a note Bjarne Stroustrup wrote some time
ago.
Companies successfully teach standard industry “short courses,” where a university semester course
is compressed into one 40 hour work week. But regardless of where you get your training, make
sure the courses have a hands-on element, since most people learn best when they have projects to
help the concepts “gel.” But even if they have the best training, they’re not ready yet.
It takes 6-12 months to become broadly proficient in C++, especially if you haven’t done OO or
generic programming before. It takes less time for developers who have easy access to a “local”
body of experts, more if there isn’t a “good” general purpose C++ class library available. To
become one of these experts who can mentor others takes around 3 years.
Some people never make it. You don’t have a chance unless you are teachable and have personal
drive. As a bare minimum on “teachability,” you have to be able to admit when you’ve been wrong.
As a bare minimum on “drive,” you must be willing to put in some extra hours. Remember: it’s
a lot easier to learn some new facts than it is to change your paradigm, i.e., to change the way you
think; to change your notion of goodness; to change your mental models.
Two things you should do:
 Get your people two books: one to tell them what is legal, another to tell them what is moral
 Consider bringing in a “mentor”
Two things you should not do:
 You should not bother having your people trained in C as a stepping-stone to learning
OO/C++
 You should not bother having your people trained in Objective-C as a stepping-stone to
learning OO/C++
What’s the best way to improve my C++ programs?
That depends on how you use it. Most people underestimate abstract classes and templates.
Conversely, most people seriously overuse casts and macros. Have a look at one of
 Stroustrup’s papers or books for ideas. One way of thinking of abstract classes and templates is as
interfaces that allow a more clean and logical presentation of services than is easy to provide
through functions or single-rooted class hierarchies. See other sections of this FAQ for some
specific examples and ideas.
Does it matter which programming language I use?
Yes, but don’t expect miracles. Some people seem to believe that a programming language can or at
least should solve most of their problems with system building. They are condemned to search
forever for the perfect programming language and become repeatedly disappointed. Others dismiss
programming languages as unimportant “implementation details” and put their money into
development processes and design methods. They are condemned to program in COBOL, C, and
proprietary design languages forever. A good language – such as C++ – can do a lot for a designer
and a programmer, as long as its strengths and limitations are clearly understood and respected.

What are some features of C++ from a business

perspective?
Here are a few features of OO/C++ from a business perspective:
 C++ has a huge installed base, which means you’ll have multi-vendor support for tools,
environments, consulting services, etc., plus you’ll have a very valuable line-item on your resumé
 C++ lets developers provide simplified interfaces to software chunks, which improves the
defect-rate when those chunks are (re)used
 C++ lets you exploit developer’s intuition through operator overloading, which reduces the
learning curve for (re)users
 C++ localizes access to a software chunk, which reduces the cost of changes.
 C++ reduces the safety-vs.-usability tradeoff, which improves the cost of (re)using a chunk of
software.
 C++ reduces the safety-vs.-speed tradeoff, which improves defect rates without degrading
performance.
 C++ gives you inheritance and dynamic binding which let old code call new code, making it
possible to quickly extend/adapt your software to hit narrow market windows.
Are virtual functions (dynamic binding) central to OO/C+
+?
Yes and no! OO-style dynamic polymorphism, which you get by calling virtual functions, is one of
the two major ways C++ offers to achieve polymorphism, and the one you should use for things that
can’t be known at compile time. The other is generic-programming-style static polymorphism,
which you get by using templates, and you should often use for things that are known at compile
time. They’re two great tastes that taste great together.
Without virtual functions, C++ wouldn’t be object-oriented. Operator overloading and non-
virtual member functions are great, but they are, after all, just syntactic sugar for the more typical
C notion of passing a pointer to a struct to a function. The standard library contains numerous
templates that illustrate “generic programming” techniques, which are also great,
but virtual functions are still at the heart of object-oriented programming using C++.
From a business perspective, there is very little reason to switch from straight C to C++
without virtual functions (for now we’ll ignore generic programming and the standard library).
Technical people often think that there is a large difference between C and non-OO C++, but
without OO, the difference usually isn’t enough to justify the cost of training developers, new tools,
etc. In other words, if I were to advise a manager regarding whether to switch from C to non-OO C+
+ (i.e., to switch languages but not paradigms), I’d probably discourage him or her unless there were
 compelling tool-oriented reasons. From a business perspective, OO can help make systems
extensible and adaptable, but just the syntax of C++ classes without OO may not even reduce the
maintenance cost, and it surely adds to the training cost significantly.
Bottom line: C++ without virtual is not OO. Programming with classes but without dynamic
binding is called “object based,” but not “object oriented.” Throwing out virtual functions is the
same as throwing out OO. All you have left is object-based programming, similar to the original
Ada language (the updated Ada language, by the way, supports true OO rather than just object-
based programming).
Note: you don’t need virtual functions for generic programming. Among other things, this means
you can’t tell which paradigm you’ve used simply by counting the number of virtual functions
you have.
I’m from Missouri. Can you give me a simple reason
why virtual functions (dynamic binding, dynamic
polymorphism) and templates (static polymorphism) make
a big difference?
They can improve reuse by letting old code call new code provided at run time (virtual functions) or
compile time (templates).
Before OO and generic programming came along, reuse was accomplished by having new code call
old code. For example, a programmer might write some code that called some reusable code such
as printf().
With OO and generic programming, reuse can also be accomplished by having old code
call new code. For example, a programmer might write some code that is called by a framework that
was written by their great, great grandfather. There’s no need to change great-great-grandpa’s code.
In fact, for dynamic binding with virtual functions, it doesn’t even need to be recompiled. Even if all
you have left is the object file and the source code that great-great-grandpa wrote was lost 25 years
ago, that ancient object file will call the new extension without anything falling apart.
That is extensibility, and that is OO and generic programming for powerful reusable abstraction.

Is C++ backward compatible with ANSI/ISO C?

Almost. See also is C a subset of C++.
C++ is as close as possible to compatible with C, but no closer. In practice, the major difference is
that C++ requires prototypes, and that f() declares a function that takes no parameters (in C, a
function declared using f() can be passed an arbitrary number of parameters of arbitrary types).
There are some very subtle differences as well, like sizeof('x') is equal to sizeof(char) in
C++ but is equal to sizeof(int) in C. Also, C++ puts structure “tags” in the same namespace as
other names, whereas C requires an explicit struct (e.g., the typedef struct Fred
Fred; technique still works, but is redundant in C++).
Why is C++ (almost) compatible with C?
When Stroustrup invented C++, he wanted C++ to be compatible with a complete language with
sufficient performance and flexibility for even the most demanding systems programming. He “had
a perfect dread of producing yet-another pretty language with unintentional limitations.” See
Section 2.7 of The Design and Evolution of C++ for historical details.
At the time, Stroustrup considered C the best systems programming language available. That was
not as obvious then (1979) as it later became, but Stroustrup had experts such as Dennis Ritchie,
Steve Johnson, Sandy Fraser, Greg Chesson, Doug McIlroy, and Brian Kernighan down the corridor
from whom he could learn and get feedback. Without their help and advice, and without C, C++
would have been stillborn.
 Contrary to repeated rumors, Stroustrup was never told that he had to use C; nor was he ever told
not to use C. In fact, the first C++ manual grew from troff source of the C manual contributed by
Dennis Ritchie. Many new languages were designed at Bell labs; in “Research” at least, there were
no rules enforcing language bigotry.

When was C++ invented?

Bjarne Stroustrup started work on what became C++ in 1979. The initial version was called “C with
Classes”. The first version of C++ was used internally in AT&T in August 1983. The name “C++”
was used late that year. The first commercial implementation was released October 1985 at the same
time as the publication of the first edition of The C++ Programming Language. Templates and
exception handling were included later in the 1980’s and documented in The Annotated C++
Reference Manual and The C++ Programming Language (2nd Edition).
The current definition of C++ is the ISO C++ Standard and is described in The C++ Programming
Language (4th Edition).
You can find a more complete timeline and more detailed explanations in The Design and Evolution
of C++ and A History of C++: 1979-1991.
Why was C++ invented?
Stroustrup wanted to write efficient systems programs in the styles encouraged by Simula67. To do
that, he added facilities for better type checking, data abstraction, and object-oriented programming
to C. The more general aim was to design a language in which developers could write programs that
were both efficient and elegant. Many languages force you to choose between those two
alternatives.
The specific tasks that caused Stroustrup to start designing and implementing C++ (initially called
“C with Classes”) had to do with distributing operating system facilities across a network.
You can find more detailed explanations in The Design and Evolution of C++. See also A History
of C++: 1979-1991 and Evolving a language in and for the real world: C++ 1991-2006.
Where did the name C++ come from?
In Chapter 3 of D&E, Stroustrup wrote:
I picked C++ because it was short, had nice interpretations, and wasn’t of the form “adjective C.”
In C, ++ can, depending on context, be read as “next,” “successor,” or “increment,” though it is
always pronounced “plus plus.” The name C++ and its runner up ++C are fertile sources for jokes
and puns – almost all of which were known and appreciated before the name was chosen. The name
C++ was suggested by Rick Mascitti. It was first used in December of 1983 when it was edited into
the final copies of [Stroustrup,1984] and [Stroustrup,1984c].
In chapter 1 of TC++PL, Stroustrup wrote:
The name C++ (pronounced “see plus plus”) was coined by Rick Mascitti in the summer of 1983.
The name signifies the evolutionary nature of the changes from C; “++” is the C increment operator.
The slightly shorter name “C+” is a syntax error; it has also been used as the name of an unrelated
language. Connoisseurs of C semantics find C++ inferior to ++C. The language is not called D,
because it is an extension of C, and it does not attempt to remedy problems by removing features.
For yet another interpretation of the name C++, see the appendix of [Orwell,1949].
The “C” in C++ has a long history. Naturally, it is the name of the language Dennis Ritchie
designed. C’s immediate ancestor was an interpreted descendant of BCPL called B designed by Ken
Thompson. BCPL was designed and implemented by Martin Richards from Cambridge University
while visiting MIT in the other Cambridge. BCPL in turn was Basic CPL, where CPL is the name of
a rather large (for its time) and elegant programming language developed jointly by the universities
of Cambridge and London. Before the London people joined the project “C” stood for Cambridge.
 Later, “C” officially stood for Combined. Unofficially, “C” stood for Christopher because
Christopher Strachey was the main power behind CPL.

Why does C++ allow unsafe code?

That is, why does C++ support operations that can be used to violate the rules of static (compile-
time) type safety?
 to access hardware directly (e.g. to treat an integer as a pointer to (address of) a device
register)
 to achieve optimal run-time and space performance (e.g. unchecked access to elements of an
array and unchecked access to an object through a pointer)
 to be compatible with C
That said, it is a good idea to avoid unsafe code like the plague whenever you don’t actually need
one of those three features:
 don’t use casts
 keep C-style [] arrays out of interfaces (hide them in the innards of high-performance
functions and classes where they are needed and write the rest of the program using
proper strings, vectors, etc.)
 avoid void* (keep them inside low-level functions and data structures if you really need
them and present type safe interfaces, usually templates, to your users)
 avoid unions
 if you have any doubts about the validity of a pointer, use a smart pointer instead
 don’t use “naked” new and delete (use containers, resource handles, etc., instead)
 don’t use ...-style variadic functions (“printf style”)
 avoid macros except for #include guards
Almost all C++ code can follow these simple rules. Please don’t be confused by the fact that you
cannot follow these rules if you write C code or C-style code in C++.

Why are some things left undefined in C++?

Because machines differ and because C left many things undefined. For details, including
definitions of the terms “undefined”, “unspecified”, “implementation defined”, and “well-formed”;
see the ISO C++ standard. Note that the meaning of those terms differ from their definition of the
ISO C standard and from some common usage. You can get wonderfully confused discussions when
people don’t realize that not everybody shares definitions.
This is a correct, if unsatisfactory, answer. Like C, C++ is meant to exploit hardware directly and
efficiently. This implies that C++ must deal with hardware entities such as bits, bytes, words,
addresses, integer computations, and floating-point computations the way they are on a given
machine, rather than how we might like them to be. Note that many “things” that people refer to as
“undefined” are in fact “implementation defined”, so that we can write perfectly specified code as
long as we know which machine we are running on. Sizes of integers and the rounding behavior of
floating-point computations fall into that category.
Consider what is probably the the best known and most infamous example of undefined behavior:
1. int a[10];
2. a[100] = 0; // range error
3. int* p = a;
4. // ...
5. p[100] = 0; // range error (unless we gave p a better value before that assignment)
 The C++ (and C) notion of array and pointer are direct representations of a machine’s notion of
memory and addresses, provided with no overhead. The primitive operations on pointers map
directly onto machine instructions. In particular, no range checking is done. Doing range checking
would impose a cost in terms of run time and code size. C was designed to outcompete assembly
code for operating systems tasks, so that was a necessary decision. Also, C – unlike C++ – has no
reasonable way of reporting a violation had a compiler decided to generate code to detect it: There
are no exceptions in C. C++ followed C for reasons of compatibility and because C++ also compete
directly with assembler (in OS, embedded systems, and some numeric computation areas). If you
want range checking, use a suitable checked class (vector, smart pointer, string, etc.). A good
compiler could catch the range error for a[100] at compile time, catching the one for p[100] is far
more difficult, and in general it is impossible to catch every range error at compile time.
Other examples of undefined behavior stems from the compilation model. A compiler cannot detect
an inconsistent definition of an object or a function in separately-compiled translation units. For
example:
1. // file1.c:
2. struct S { int x,y; };
3. int f(struct S* p) { return p->x; }
4.
5. // file2.c:
6. struct S { int y,x; }
7. int main()
8. {
9. struct S s;
10. s.x = 1;
11. int x = f(&s); // x!=s.x !!
12. return 2;
13. }
Compiling file1.c and file2.c and linking the results into the same program is illegal in both C
and C++. A linker could catch the inconsistent definition of S, but is not obliged to do so (and most
don’t). In many cases, it can be quite difficult to catch inconsistencies between separately compiled
translation units. Consistent use of header files helps minimize such problems and there are some
signs that linkers are improving. Note that C++ linkers do catch almost all errors related to
inconsistently declared functions.
Finally, we have the apparently unnecessary and rather annoying undefined behavior of individual
expressions. For example:
1. void out1() { cout << 1; }
2. void out2() { cout << 2; }
3.
4. int main()
5. {
6. int i = 10;
7. int j = ++i + i++; // value of j unspecified
8. f(out1(),out2()); // prints 12 or 21
9. }
The value of j is unspecified to allow compilers to produce optimal code. It is claimed that the
difference between what can be produced giving the compiler this freedom and requiring “ordinary
left-to-right evaluation” can be significant. Leading experts are unconvinced, but with innumerable
compilers “out there” taking advantage of the freedom and some people passionately defending that
freedom, a change would be difficult and could take decades to penetrate to the distant corners of
the C and C++ worlds. It is disappointing that not all compilers warn against code such as ++i+i+
+. Similarly, the order of evaluation of arguments is unspecified.
 There is a sentiment that too many “things” are left undefined, unspecified, implementation-defined,
etc. To address this, the ISO C++ committee has created Study Group 12 to review and recommend
wide-ranging tightening-up to reduce undefined, unspecified, and implementation-defined behavior.

Why is portability considered so important?

Successful software is long-lived; life-spans of decades are not uncommon. A good
application/program often outlives the hardware it was designed for, the operating system it was
written for, the data base system it initially used, etc. Often, a good piece of software outlives the
companies that supplied the basic technologies used to build it.
Often a successful application/program have customers/users who prefer a variety of platforms. The
set of desirable platforms change as the user population changes. Being tied to a single platform or
single vendor, limits the application/program’s potential use.
Obviously, complete platform independence is incompatible with the ability to use all platform
specific facilities. However, you can often approximate platform independence for an application by
accessing platform facilities through a “thin interface” representing the application’s view of its
environment as a library.

Is C++ standardized?
Yes.
The C++ standard was finalized and adopted by ISO (International Organization for
Standardization) as well as several national standards organizations such as INCITS (the U.S.
National Committee for Information Technology Standards), BSI (the British Standards Institute),
DIN (the German national standards organization). The ISO standard was finalized and adopted by
unanimous vote in November 1997, with minor updates in 2003 and now significant and valuable
updates in 2011. Another set of updates is expected to be published in 2014.
The U.S. C++ committee is called “PL22.16”. The ISO C++ standards group is called “WG21”. The
major players in the C++ standards process have included just about everyone: representatives from
Australia, Canada, Denmark, Finland, France, Germany, Ireland, Japan, the Netherlands, New
Zealand, Sweden, the UK, and the USA, along with representatives from about a hundred
companies and many interested individuals. Major players have included AT&T, Ericsson, Digital,
Borland, Hewlett Packard, IBM, Intel, Mentor Graphics, Microsoft, NVidia, Silicon Graphics, Sun
Microsystems, and Siemens.
For further information see the ISO C++ standardization pages, including but not limited to
 the committee page
 the meetings and participation page
 the ISO/IEC JTC1 procedures summary
Who is on the standardization committee?
See also the committee page.
The committee consists of a large number of people (about 200) out of whom about 100 turn up at
the week-long meetings two or three times a year. In addition there are national standards groups
and meetings in several countries. Most members contribute either by attending meetings, by taking
part in email discussions, or by submitting papers for committee consideration. Most members have
friends and colleagues who help them. From day #1, the committee has had members from many
countries and at every meeting people from half a dozen to a dozen countries attend. The final votes
are done by about 20 national standards bodies. Thus, the ISO C++ standardization is a fairly
massive effort, not a small coherent group of people working to create a perfect language for
 “people just like themselves.” The standard is what this group of volunteers can agree on as being
the best they can produce that all can live with.
Naturally, many (but not all) of these volunteers have day jobs focused on C++: They include
compiler writers, tool builders, library writers, application builders, researchers, book authors,
consultants, test-suite builders, and more.
Here is a very-partial list of some major organizations involved: Adobe, Apple, Boost, Bloomberg,
EDG, Google, HP, IBM, Intel, Microsoft, Oracle, Red Hat.
Here is a short list of names of members who you may have encountered in the literature or on the
web: Dave Abrahams, Matt Austern, Pete Becker, Hans Boehm, Steve Clamage, Lawrence Crowl,
Beman Dawes, Francis Glassborow, Doug Gregor, Pablo Halpern, Howard Hinnant, Jaakko Jarvi,
John Lakos, Alisdair Meredith, Jens Maurer, Jason Merrill, Sean Parent, P.J. Plauger, Tom Plum,
Gabriel Dos Reis, Bjarne Stroustrup, Herb Sutter, David Vandevoorde, Michael Wong. Apologies
to the 200+ current and past members that we couldn’t list. Also, please note the author lists on the
various papers: a standard is written by (many) individuals, not by an anonymous committee.
You can get a better impression of the breath and depth of expertise involved by examining the
authors listed in the WG21 papers archive, but please remember there are major contributors to the
standards effort who do not write a lot.
Where can I get a copy of the C++ standard?
See isocpp.org’s The Standard page.
What is the difference between C++98 and C++03?
From a programmer’s view there is none. The C++03 revision of the standard was a bug fix release
for implementers to ensure greater consistency and portability. In particular, tutorial and reference
material describing C++98 and C++03 can be used interchangeably by all except compiler writers
and standards gurus.

What is the difference between C++98 and C++0x?

The same as the difference between C++98 and C++11, because C++0x ended up being C++11.
The x C++0x went hexadecimal; we have C++0xB. :)
What is the difference between C++98 and C++11?
See what’s new in C++11.
Note that the C++ language will remain stable because compatibility is always a major concern. The
committee tries hard not to break your (standard conforming) code. Except for some corner cases
you’re unlikely to notice, all valid C++98 code is valid C++11 and C++14 code.

What is the difference between C++11 and C++14?

See what’s new in C++14.
Note that the C++ language will remain stable because compatibility is always a major concern. The
committee tries hard not to break your (standard conforming) code. Except for some corner cases
you’re unlikely to notice, all valid C++98 code is valid C++14 code.

What are some “interview questions” I could ask that

would let me know if candidates really know their stuff?
 This answer is primarily for non-technical managers and HR folks who are trying to do a good job
at interviewing C++ candidates. If you’re a C++ programmer about to be interviewed, and if you’re
lurking in this FAQ hoping to know the questions they’ll ask you ahead of time so you can avoid
having to really learn C++, shame on you: spend your time becoming technically competent and you
won’t have to try to “cheat” your way through life!
Back to the non-technical manager / HR person: obviously you are eminently qualified to judge
whether a candidate is a good “fit” with your company’s culture. However there are enough
charlatans, wannabes, and posers out there that you really need to team up with someone who is
technically competent in order to make sure the candidate has the right level of technical skill. A lot
of companies have been burned by hiring nice but incompetent duds — people who were
incompetent in spite of the fact that they knew the answers to a few obscure questions. The only
way to smoke out the posers and wannabes is to get someone in with you who can ask penetrating
technical questions. You have no hope whatsoever of doing that yourself. Even if I gave you a
bunch of “tricky questions,” they wouldn’t smoke out the bad guys.
Your technical sidekick might not be (and often isn’t) qualified to judge the candidate on
personality or soft skills, so please don’t abdicate your role as the final arbiter in the decision
making process. But please don’t think you can ask a half dozen C++ questions and have the
slightest clue if the candidate really knows what they’re talking about from a technical perspective.
Having said all that, if you’re technical enough to read the C++ FAQ, you can dig up a lot of good
interview questions here. The FAQ has a lot of goodies that will separate the wheat from the chaff.
The FAQ focuses on what programmers should do, as opposed to merely what the compiler will let
them do. There are things that can be done in C++ but shouldn’t be done. The FAQ helps people
separate those two.
What does the FAQ mean by “such and such is evil”?
It means such and such is something you should avoid most of the time, but not something you
should avoid all the time. For example, you will end up using these “evil” things whenever they are
“the least evil of the evil alternatives.” It’s a joke, okay? Don’t take it too seriously.
The real purpose of the term (“Ah ha,” I hear you saying, “there really is a hidden motive!”; you’re
right: there is) is to shake new C++ programmers free from some of their old thinking. For example,
C programmers who are new to C++ often use pointers, arrays and/or #define more than they
should. The FAQ lists those as “evil” to give new C++ programmers a vigorous (and droll!) shove
in the right direction. The goal of farcical things like “pointers are evil” is to convince new C++
programmers that C++ really isn’t “just like C except for those silly // comments.”
Now let’s get real here. I’m not suggesting macros or arrays or pointers are right up there with
murder or kidnapping. Well, maybe pointers. (Just kidding!) So don’t get all hyper about the word
“evil”: it’s supposed to sound a little outrageous. And don’t look for a technically precise definition
of exactly when something is or isn’t “evil”: there isn’t one.
Items labeled as “evil” (macros, arrays, pointers, etc.) aren’t always bad in all situations. When they
are the “least bad” of the alternatives, use them!
Will I sometimes use any so-called “evil” constructs?
Of course you will!
One size does not fit all. Stop. Right now, take out a fine-point marker and write on the inside of
your glasses: Software Development Is Decision Making. “Think” is not a four-letter word. There are
very few “never…” and “always…” rules in software — rules that you can apply without thinking
— rules that always work in all situations in all markets — one-size-fits-all rules.
In plain English, you will have to make decisions, and the quality of your decisions will affect
the business value of your software. Software development is not mostly about slavishly following
rules; it is a matter of thinking and making tradeoffs and choosing. And sometimes you will have to
 choose between a bunch of bad options. When that happens, the best you can hope for is to choose
the least bad of the alternatives, the lesser of the “evils.”
You will occasionally use approaches and techniques labeled as “evil.” If that makes you
uncomfortable, mentally change the word “evil” to “frequently undesirable” (but don’t quit your day
job to become an author: milquetoast terms like that put people to sleep :-)
Is it important to know the technical definition of “good
OO”? Of “good class design”?
You might not like this, but the short answer is, “No.” (With the caveat that this answer is directed
to practitioners, not theoreticians.)
Mature software designers evaluate situations based on business criteria (time, money and risk) in
addition to technical criteria like whether something is or is not “good OO” or “good class design.”
This is a lot harder since it involves business issues (schedule, skill of the people, finding out where
the company wants to go so we know where to design flexibility into the software, willingness to
factor in the likelihood of future changes - changes that are likely rather than merely theoretically
possible, etc.) in addition to technical issues. However it results in decisions that are a lot more
likely to bring good business results.
As a developer, you have a fiduciary responsibility to your employer to invest only in ways that
have a reasonable expectation for a return on that investment. If you don’t ask the business
questions in addition to the technical questions, you will make decisions that have random and
unpredictable business consequences.
Like it or not, what that means in practice is that you’re probably better off leaving terms like “good
class design” and “good OO” undefined. In fact I believe precise, pure-technical definitions of those
terms can be dangerous and can cost companies money, ultimately perhaps even costing people
their jobs. That sounds bizarre, but there’s a really good reason: if these terms are defined in precise,
pure-technical terms, well-meaning developers tend to ignore business considerations in their desire
to fulfill these pure-technical definitions of “good.”
Any purely technical definition of “good,” such as “good OO” or “good design” or anything else that
can be evaluated without regard to schedule, business objectives (so we know where to invest),
expected future changes, corporate culture with respect to a willingness to invest in the future, skill
levels of the team that will be doing the maintenance, etc., is dangerous. It is dangerous because it
deceives programmers into thinking they are making “right” decisions when in reality they might be
making decisions that have terrible consequences. Or those decisions might not have terrible
business consequences, but that’s the point: when you ignore business considerations while making
decisions, the business consequences will be random and somewhat unpredicatable. That’s bad.
It is a simple fact that business issues dominate technical issues, and any definition of “good” that
fails to acknowledge that fact is bad.

What should I tell people who complain that the word

“FAQ” is misleading, that it emphasizes the questions
rather than the answers, and that we should all start
using a different acronym?
Tell them to grow up.
Some people want to change the word “FAQ” to a different acronym, such as something
emphasizing the answers rather than the questions. However a word or phrase is defined by its
usage. Multitudes of people already understand “FAQ” as a word in its own right. Think of it as a
 moniker for an idea rather than an acronym. As a word, “FAQ” already means a list of common
questions and answers.
Do not take this as an encouragement to use words sloppily. Quite the opposite. The point is that
clear communication involves using words that everybody already understands. Getting into a
contest over whether we should change the word “FAQ” is silly and a waste of time. It would be
one thing if the word wasn’t already well known, but it no longer makes sense after so many people
already understand it.
An (imperfect) analogy: the character '\n' is almost universally known as the linefeed character,
yet very few programmers today work with computers equipped with a teletype that actually does a
“line feed.” Nobody cares anymore; it’s a linefeed character; get over it. And '\r' is the carriage
return, even though your computer might not have a carriage that returns. Live with it.
Another (imperfect) analogy is RAII. Thanks to the excellent work of Andy Koenig, Bjarne
Stroustrup, and others, the name “RAII” has become very widely known in the C++ community.
“RAII” represents a very valuable concept and you ought to use it regularly. However, if you dissect
“RAII” as an acronym, and if you look (too?) closely at the words making up that acronym, you will
realize that the words are not a perfect match for the concept. Who cares?!? The concept is what’s
important; “RAII” is merely a moniker used as a handle for that concept.
Details: If you dissect the words of the RAII acronym (Resource Acquisition Is Initialization), you
will think RAII is about acquiring resources during initialization. However the power of RAII
comes not from tying acquisition to initialization, but from tying reclamation to destruction. A more
precise acronym might be RRID (Resource Reclamation Is Destruction), perhaps DIRR
(Destruction Is Resource Reclamation), but since so many people already understand RAII, using it
properly is far more important than complaining about the term. RAII is a moniker for an idea; its
precision as an acronym is secondary.
(What’s really important in acronyms is how cool they sound. Clearly “RRID” and “DIRR” are
therefore better! Just kidding.)
So treat the word “FAQ” as a moniker that already has a well established, well known meaning. A
word is defined by its usage.

How can I help make the C++ FAQ even better??!??

Please send material with suggestions, or even that you want to volunteer to be approved as a FAQ
maintainer to make contributions yourself as you have time. Qualified volunteers are appreciated.
If you want to help, here are some specifics:
1. Don’t expect to get paid.
This is a non-paying labor of love — for me, and, if you choose to help, for you.
Giving back is A Good Thing. Technology has been good to me, and I expect it’s been good to
you.
2. A worked-out solution (FAQ-like question + answer) will get integrated more quickly than a
one-liner suggestion for someone else to write up.
 "Editors, here is a new question + answer on ...." ← Preferred!
 "Editors, YOU should write a new question + answer
on ...." ← Will take longer!
We will try (and always have have tried) to get to the latter, though we have only so much time.
3. Don’t worry if you suck at writing. Send your ideas anyway. We will gladly wordsmith what
you send, both to make it “fit” with the rest of the FAQ and to make it easy for you.
 So send in your suggestions, even if you’re not confident in your writing ability!!
4. Dead external links. Sigh. There are too many of them. If you find one, it would
be very helpful (to the entire C++ community!!) if you’d send the correct, updated URL.
Obviously we appreciate any help, even if the only thing you tell us is that the link is dead.
However if you do that, be advised that the link will merely be removed — it probably won’t get
corrected.
Remember: you’re helping the entire world-wide C++ community.

Newbie Questions & Answers

Contents of this section:

 What is this “newbie section” all about?

 Where do I start?
 How do I read a string from input?
 How do I write this very simple program?
 How do I convert an integer to a string?
 How do I convert a string to an integer?
 Should I use void main() or int main()?
 Should I use f(void) or f()?
 What are the criteria for choosing between short / int / long data types?
 What the heck is a const variable? Isn’t that a contradiction in terms?
 Why would I use a const variable / const identifier as opposed to #define?
 Are you saying that the preprocessor is evil?
 What is the “standard library”? What is included / excluded from it?
 How should I lay out my code? When should I use spaces, tabs, and/or newlines in my code?
 Is it okay if a lot of numbers appear in my code?
 What’s the point of the L, U and f suffixes on numeric literals?
 I can understand the and (&&) and or (||) operators, but what’s the purpose of the not (!)
operator?
 Is !(a < b) logically the same as a >= b?
 What is this NaN thing?
 Why is floating point so inaccurate? Why doesn’t this print 0.43?
 Why doesn’t my floating-point comparison work?
 Why is cos(x) != cos(y) even though x == y? (Or sine or tangent or log or just about
any other floating point computation)
 What is the type of an enumeration such as enum Color? Is it of type int?
 If an enumeration type is distinct from any other type, what good is it? What can you do with
it?
 What other “newbie” guides are there for me?
What is this “newbie section” all about?
 It’s a randomly ordered collection containing a few questions newbies might ask.
 This section doesn’t pretend to be organized. Think of it as random. In truth, think of it as a
hurried, initial cut by a busy guy.
 This section doesn’t pretend to be complete. Think of it as offering a little help to a few
people. It won’t help everyone and it might not help you.
Hopefully someday we’ll be able to improve this section, but for now, it is incomplete and
unorganized. If that bothers you, my suggestion is to click that little x on the extreme upper right of
your browser window :-).
Where do I start?
Read the FAQ, especially the section on learning C++, and read books plural.
But if everything still seems too hard, if you’re feeling bombarded with mysterious terms and
concepts, if you’re wondering how you’ll ever grasp anything, do this:
1. Type in some C++ code from any of the sources listed above.
2. Get it to compile and run.
3. Repeat.
That’s it. Just practice and play. Hopefully that will give you a foothold.
Here are some places you can get “sample problems” (in alphabetical order):
 The British Informatics Olympiad
 The Dictionary of Algorithms and Data Structures
 The University of Valladolid Programming Contest Site
How do I read a string from input?
You can read a single, whitespace terminated word like this:
1. #include<iostream>
2. #include<string>
3. using namespace std;
4.
5. int main()
6. {
7. cout << "Please enter a word:\n";
8.
9. string s;
10. cin>>s;
11.
12. cout << "You entered " << s << '\n';
13. }
Note that there is no explicit memory management and no fixed-sized buffer that you could possibly
overflow.
If you really need a whole line (and not just a single word) you can do this:
1. #include<iostream>
2. #include<string>
3. using namespace std;
4.
5. int main()
6. {
7. cout << "Please enter a line:\n";
8.
9. string s;
10. getline(cin,s);
11.
12. cout << "You entered " << s << '\n';
13. }
For a brief introduction to standard library facilities, such as iostream and string, see Chapter 3
of TC++PL3 (available online). For a detailed comparison of simple uses of C and C++ I/O, see
“Learning Standard C++ as a New Language”, which you can download from
Stroustrup’s publications list.
How do I write this very simple program?
Often, especially at the start of semesters, there is a small flood of questions about how to write very
simple programs. Typically, the problem to be solved is to read in a few numbers, do something
with them, and write out an answer. Here is a sample program that does that:
1. #include <iostream>
2. #include <vector>
3. #include <algorithm>
4. using namespace std;
5.
6. int main()
7. {
8. vector<double> v;
9.
10. double d;
11. while(cin>>d) v.push_back(d); // read elements
12. if (!cin.eof()) { // check if input failed
13. cerr << "format error\n";
14. return 1; // error return
15. }
16.
17. cout << "read " << v.size() << " elements\n";
18.
19. reverse(v.begin(),v.end());
20. cout << "elements in reverse order:\n";
21. for (int i = 0; i<v.size(); ++i) cout << v[i] << '\n';
22.
23. return 0; // success return
24. }
Here are a few observations about this program:
 This is a Standard ISO C++ program using the standard library. Standard library facilities are
declared in namespace std in headers without a .h suffix.
 If you want to compile this on a Windows machine, you need to compile it as a “console
application”. Remember to give your source file the .cpp suffix or the compiler might think that it
is C (not C++) source.
 Yes, main() returns an int.
 Reading into a standard vector guarantees that you don’t overflow some arbitrary buffer.
Reading into an array without making a “silly error” is beyond the ability of complete novices –
by the time you get that right, you are no longer a complete novice. If you doubt this claim, read
Stroustrup’s paper “Learning Standard C++ as a New Language”, which you can download here.
 The !cin.eof() is a test of the stream’s format. Specifically, it tests whether the loop
ended by finding end-of-file (if not, you didn’t get input of the expected type/format). For more
information, look up “stream state” in your C++ textbook.
 A vector knows its size, so I don’t have to count elements.
  Yes, you could declare i to be a vector<double>::size_type rather than plain int to
quiet warnings from some hyper-suspicious compilers, but in this case,I consider that too pedantic
and distracting.
 This program contains no explicit memory management, and it does not leak memory.
A vector keeps track of the memory it uses to store its elements. When a vector needs more
memory for elements, it allocates more; when a vector goes out of scope, it frees that memory.
Therefore, the user need not be concerned with the allocation and deallocation of memory
for vector elements.
 For reading in strings, see How do I read a string from input?.
 The program ends reading input when it sees “end of file”. If you run the program from the
keybord on a Unix machine “end of file” is Ctrl-D. If you are on a Windows machine that because
of a bug doesn’t recognize an end-of-file character, you might prefer this slightly more
complicated version of the program that terminates input with the word “end”:
1. #include <iostream>
2. #include <vector>
3. #include <algorithm>
4. #include <string>
5. using namespace std;
6.
7. int main()
8. {
9. vector<double> v;
10.
11. double d;
12. while(cin>>d) v.push_back(d); // read elements
13. if (!cin.eof()) { // check if input failed
14. cin.clear(); // clear error state
15. string s;
16. cin >> s; // look for terminator string
17. if (s != "end") {
18. cerr << "format error\n";
19. return 1; // error return
20. }
21. }
22.
23. cout << "read " << v.size() << " elements\n";
24.
25. reverse(v.begin(),v.end());
26. cout << "elements in reverse order:\n";
27. for (int i = 0; i<v.size(); ++i) cout << v[i] << '\n';
28.
29. return 0; // success return
30. }
For more examples of how to use the standard library to do simple things simply, see Parts 3 and 4
of the Tour of C++.
How do I convert an integer to a string?
Call to_string. This is new in C++11, widely available, and as of this writing widely not-noticed.
:)
1. int i = 127;
2. string s = to_string(i);

How do I convert a string to an integer?

Call stoi:
1. string s = "127";
2. int i = stoi(s);
The related functions stol and strtoll will convert a string to a long or a long long,
respectively.
Should I use void main() or int main()?
int main()
main() must return int. Some compilers accept void main(), but that is non-standard and
shouldn’t be used. Instead use int main(). As to the specific return value, if you don’t know what
else to return just say return 0;
The definition
1. void main() { /* ... */ }
is not and never has been C++, nor has it even been C. See the ISO C++ standard 3.6.1[2] or the
ISO C standard 5.1.2.2.1. A conforming implementation accepts
1. int main() { /* ... */ }
and
1. int main(int argc, char* argv[]) { /* ... */ }
A conforming implementation may provide more versions of main(), but they must all have return
type int. The int returned by main() is a way for a program to return a value to “the system” that
invokes it. On systems that doesn’t provide such a facility the return value is ignored, but that
doesn’t make void main() legal C++ or legal C. Even if your compiler accepts void main(),
avoid it, or risk being considered ignorant by C and C++ programmers.
In C++, main() need not contain an explicit return statement. In that case, the value returned
is 0, meaning successful execution. For example:
1. #include<iostream>
2.
3. int main()
4. {
5. std::cout << "This program returns the integer value 0\n";
6. }
Note also that neither ISO C++ nor C99 allows you to leave the type out of a declaration. That is, in
contrast to C89 and ARM C++, int is not assumed where a type is missing in a declaration.
Consequently:
1. #include<iostream>
2.
3. main() { /* ... */ }
is an error because the return type of main() is missing.
Should I use f(void) or f()?
f()
C programmers often use f(void) when declaring a function that takes no parameters, however in
C++ that is considered bad style. In fact, the f(void) style has been called an “abomination” by
Bjarne Stroustrup, the creator of C++, Dennis Ritchie, the co-creator of C, and Doug McIlroy, head
of the research department where Unix was born.
If you’re writing C++ code, you should use f(). The f(void) style is legal in C++, but only to
make it easier to compile C code.
This C++ code shows the best way to declare a function that takes no parameters:
1. void f(); // declares (not defines) a function that takes no parameters
This C++ code both declares and defines a function that takes no parameters:
1. void f() // declares and defines a function that takes no parameters
2. {
3. // ...
4. }
The following C++ code also declares a function that takes no parameters, but it uses the less
desirable (some would say “abomination”) style, f(void):
1. void f(void); // undesirable style for C++; use void f() instead
Actually this f() thing is all you need to know about C++. That and using those new
fangled // comments. Once you know those two things, you can claim to be a C++ expert. Go for
it: type those magical “++” marks on your resumé. Who cares about all that OO stuff — why should
you bother changing the way you think? After all, the really important thing isn’t thinking; it’s
typing in function declarations and comments. (Sigh; I wish nobody actually thought that way.)
What are the criteria for choosing
between short / int / long data types?
Other related questions: If a short int is the same size as an int on my particular
implementation, why choose one or the other? If I start taking the actual size in bytes of the
variables into account, won’t I be making my code unportable (since the size in bytes may differ
from implementation to implementation)? Or should I simply go with sizes much larger than I
actually need, as a sort of safety buffer?
Answer: It’s usually a good idea to write code that can be ported to a different operating system
and/or compiler. After all, if you’re successful at what you do, someone else might want to use it
somewhere else. This can be a little tricky with built-in types like int and short, since C++
doesn’t give guaranteed sizes. However C++ gives you two things that might help:
guaranteed minimum sizes, and that will usually be all you need to know, and a standard C header
that provides typedefs for sized integers.
C++ guarantees a char is exactly one byte which is at least 8 bits, short is at least 16 bits, int is
at least 16 bits, and long is at least 32 bits. It also guarantees the unsigned version of each of
these is the same size as the original, for example, sizeof(unsigned short) ==
sizeof(short).
When writing portable code, you shouldn’t make additional assumptions about these sizes. For
example, don’t assume int has 32 bits. If you have an integral variable that needs at least 32 bits,
use a long or unsigned long even if sizeof(int) == 4 on your particular implementation.
On the other hand, if you have an integral variable quantity that will always fit within 16 bits and if
you want to minimize the use of data memory, use a short or unsigned short even if you
know sizeof(int) == 2 on your particular implementation.
The other option is to use the following standard C header (which may or may not be provided by
your C++ compiler vendor):
1. #include <stdint.h> /* not part of the C++ standard */
That header defines typedefs for things like int32_t and uint16_t, which are a signed 32-bit
integer and an unsigned 16-bit integer, respectively. There are other goodies in there, as well. My
recommendation is that you use these “sized” integral types only where they are actually needed.
Some people worship consistency, and they are sorely tempted to use these sized
integers everywhere simply because they were needed somewhere. Consistency is good, but it is not
the greatest good, and using these typedefs everywhere can cause some headaches and even possible
performance issues. Better to use common sense, which often leads you to use the normal
keywords, e.g., int, unsigned, etc. where you can, and use of the explicitly sized integer types,
e.g., int32_t, etc. where you must.
Note that there are some subtle tradeoffs here. In some cases, your computer might be able to
manipulate smaller things faster than bigger things, but in other cases it is exactly the
opposite: int arithmetic might be faster than short arithmetic on some implementations. Another
 tradeoff is data-space against code-space: int arithmetic might generate less binary code
than short arithmetic on some implementations. Don’t make simplistic assumptions. Just because
a particular variable can be declared as short doesn’t necessarily mean it should, even if you’re
trying to save space.
Note that the C standard
doesn’t guarantee that <stdint.h> defines intn_t and uintn_t specifically for n = 8, 16, 32 or
64. However if the underlying implementation provides integers with any of those
sizes, <stdint.h> is required to contain the corresponding typedefs. Furthermore you are
guaranteed to have typedefs for sizes n = 8, 16 and 32 if your implementation is POSIX compliant.
Put all that together and it’s fair to say that the vast majority of implementations, though not all
implementations, will have typedefs for those typical sizes.
What the heck is a const variable? Isn’t that a
contradiction in terms?
If it bothers you, call it a “const identifier” instead.
The main issue is to figure out what it is; we can figure out what to call it later. For example,
consider the symbol max in the following function:
1. void f()
2. {
3. const int max = 107;
4. // ...
5. float array[max];
6. // ...
7. }
It doesn’t matter whether you call max a const variable or a const identifier. What matters is that
you realize it is like a normal variable in some ways (e.g., you can take its address or pass it by
const-reference), but it is unlike a normal variable in that you can’t change its value.
Here is another even more common example:
1. class Fred {
2. public:
3. // ...
4. private:
5. static const int max_ = 107;
6. // ...
7. };
In this example, you would need to add the line int Fred::max_; in exactly one .cpp file,
typically in Fred.cpp.
It is generally considered good programming practice to give each “magic number” (like 107) a
symbolic name and use that name rather than the raw magic number.
Why would I use a const variable / const identifier as
opposed to #define?
const identifiers are often better than #define because:
 they obey the language’s scoping rules
 you can see them in the debugger
 you can take their address if you need to
 you can pass them by const-reference if you need to
 they don’t create new “keywords” in your program.
In short, const identifiers act like they’re part of the language because they are part of the
language. The preprocessor can be thought of as a language layered on top of C++. You can
imagine that the preprocessor runs as a separate pass through your code, which would mean your
 original source code would be seen only by the preprocessor, not by the C++ compiler itself. In
other words, you can imagine the preprocessor sees your original source code and replaces
all #define symbols with their values, then the C++ compiler proper sees the modified source
code after the original symbols got replaced by the preprocessor.
There are cases where #define is needed, but you should generally avoid it when you have the
choice. You should evaluate whether to use const vs. #define based on business value: time,
money, risk. In other words, one size does not fit all. Most of the time you’ll use const rather
than #define for constants, but sometimes you’ll use #define. But please remember to wash your
hands afterwards.
Are you saying that the preprocessor is evil?
Yes, that’s exactly what I’m saying: the preprocessor is evil.
Every #define macro effectively creates a new keyword in every source file and every scope until
that symbol is #undefd. The preprocessor lets you create a #define symbol that is always replaced
independent of the {...} scope where that symbol appears.
Sometimes we need the preprocessor, such as the #ifndef/#define wrapper within each header
file, but it should be avoided when you can. “Evil” doesn’t mean “never use.” You will use evil
things sometimes, particularly when they are “the lesser of two evils.” But they’re still evil :-)
What is the “standard library”? What is included / excluded
from it?
Most (not all) implementations have a “standard include” directory, sometimes directories plural. If
your implementation is like that, the headers in the standard library are probably a subset of the files
in those directories. For example, iostream and string are part of the standard library, as
is cstring and cstdio. There are a bunch of .h files that are also part of the standard library, but
not every .h file in those directories is part of the standard library. For example, stdio.h is
but windows.h is not.
You include headers from the standard library like this:
1. #include <iostream>
2.
3. int main()
4. {
5. std::cout << "Hello world!\n";
6. // ...
7. }

How should I lay out my code? When should I use spaces,

tabs, and/or newlines in my code?
The short answer is: Just like the rest of your team. In other words, the team should use a consistent
approach to whitespace, but otherwise please don’t waste a lot of time worrying about it.
Here are a few details:
There is no universally accepted coding standard when it comes to whitespace. There are a few
popular whitespace standards, such as the “one true brace” style, but there is a lot of contention over
certain aspects of any given coding standard.
Most whitespace standards agree on a few points, such as putting a space around infix operators
like x * y or a - b. Most (not all) whitespace standards do not put spaces around
the [ or ] in a[i], and similar comments for ( and ) in f(x). However there is a great deal of
 contention over vertical whitespace, particularly when it comes to { and }. For example, here are a
few of the many ways to lay out if (foo()) { bar(); baz(); }:
1. if (foo()) {
2. bar();
3. baz();
4. }
1. if (foo())
2. {
3. bar();
4. baz();
5. }
1. if (foo())
2. {
3. bar();
4. baz();
5. }
1. if (foo())
2. {
3. bar();
4. baz();
5. }
1. if (foo()) {
2. bar();
3. baz();
4. }
…and others…
IMPORTANT: Do NOT email me with reasons your whitespace approach is better than the others.
I don’t care. Plus I won’t believe you. There is no objective standard of “better” when it comes to
whitespace so your opinion is just that: your opinion. If you write me an email in spite of this
paragraph, I will consider you to be a hopeless geek who focuses on nits. Don’t waste your time
worrying about whitespace: as long as your team uses a consistent whitespace style, get on with
your life and worry about more important things.
For example, things you should be worried about include design issues like when ABCs should be
used, whether inheritance should be an implementation or specification technique, what testing and
inspection strategies should be used, whether interfaces should uniformly have
a get() and/or set() member function for each data member, whether interfaces should be
designed from the outside-in or the inside-out, whether errors be handled by try/catch/throw or
by return codes, etc. Read the FAQ for some opinions on those important questions, but please don’t
waste your time arguing over whitespace. As long as the team is using a consistent whitespace
strategy, drop it.
Is it okay if a lot of numbers appear in my code?
Probably not.
In many (not all) cases, it’s best to name your numbers so each number appears only once in your
code. That way, when the number changes there will only be one place in the code that has to
change.
For example, suppose your program is working with shipping crates. The weight of an empty crate
is 5.7. The expression 5.7 + contentsWeight probably means the weight of the crate including
its contents, meaning the number 5.7 probably appears many times in the software. All these
occurrences of the number 5.7 will be difficult to find and change when (not if) somebody changes
the style of crates used in this application. The solution is to make sure the
value 5.7 appears exactly once, usually as the initializer for a const identifier. Typically this will
 be something like const double crateWeight = 5.7;. After that, 5.7 +
contentsWeight would be replaced by crateWeight + contentsWeight.
Now that’s the general rule of thumb. But unfortunately there is some fine print.
Some people believe one should never have numeric literals scattered in the code. They
believe all numeric values should be named in a manner similar to that described above. That rule,
however noble in intent, just doesn’t work very well in practice. It is too tedious for people to
follow, and ultimately it costs companies more than it saves them. Remember: the goal of all
programming rules is to reduce time, cost and risk. If a rule actually makes things worse, it is a bad
rule, period.
A more practical rule is to focus on those values that are likely to change. For example, if a numeric
literal is likely to change, it should appear only once in the software, usually as the initializer of
a const identifier. This rule lets unchanging values, such as some occurrences of 0, 1, -1, etc., get
coded directly in the software so programmers don’t have to search for the one true definition
of one or zero. In other words, if a programmer wants to loop over the indices of a vector, he can
simply write for (int i = 0; i < v.size(); ++i). The “extremist” rule described earlier
would require the programmer to poke around asking if anybody else has defined a const identifier
initialized to 0, and if not, to define his own const int zero = 0; then replace the loop
with for (int i = zero; i < v.size(); ++i). This is all a waste of time since the loop
will always start with 0. It adds cost without adding any value to compensate for that cost.
Obviously people might argue over exactly which values are “likely to change,” but that kind of
judgment is why you get paid the big bucks: do your job and make a decision. Some people are so
afraid of making a wrong decision that they’ll adopt a one-size-fits-all rule such as “give a name
to every number.” But if you adopt rules like that, you’re guaranteed to have made the wrong
decision: those rules cost your company more than they save. They are bad rules.
The choice is simple: use a flexible rule even though you might make a wrong decision, or use a
one-size-fits-all rule and be guaranteed to make a wrong decision.
There is one more piece of fine print: where the const identifier should be defined. There are three
typical cases:
 If the const identifier is used only within a single function, it can be local to that function.
 If the const identifier is used throughout a class and no where else, it can be static within
the private part of that class.
 If the const identifier is used in numerous classes, it can be static within the public part
of the most appropriate class, or perhaps private in that class with a public static access
method.
As a last resort, make it static within a namespace or perhaps put it in the unnamed namespace.
Try very hard to avoid using #define since the preprocessor is evil. If you need to
use #define anyway, wash your hands when you’re done. And please ask some friends if they
know of a better alternative.
(As used throughout the FAQ, “evil” doesn’t mean “never use it.” There are times when you will use
something that is “evil” since it will be, in those particular cases, the lesser of two evils.)
What’s the point of the L, U and f suffixes on numeric
literals?
You should use these suffixes when you need to force the compiler to treat the numeric literal as if it
were the specified type. For example, if x is of type float, the expression x + 5.7 is of type
double: it first promotes the value of x to a double, then performs the arithmetic using double-
precision instructions. If that is what you want, fine; but if you really wanted it to do the arithmetic
using single-precision instructions, you can change that code to x + 5.7f. Note: it is even better to
 “name” your numeric literals, particularly those that are likely to change. That would require you to
say x + crateWeight where crateWeight is a const float that is initialized to 5.7f.
The U suffix is similar. It’s probably a good idea to use unsigned integers for variables that are
always >= 0. For example, if a variable represents an index into an array, that variable would
typically be declared as an unsigned. The main reason for this is it requires less code, at least if
you are careful to check your ranges. For example, to check if a variable is both >= 0 and < max
requires two tests if everything is signed: if (n >= 0 && n < max), but can be done with a
single comparison if everything is unsigned: if (n < max).
If you end up using unsigned variables, it is generally a good idea to force your numeric literals to
also be unsigned. That makes it easier to see that the compiler will generate “unsigned arithmetic”
instructions. For example: if (n < 256U) or if ((n & 255u) < 32u). Mixing signed and
unsigned values in a single arithmetic expression is often confusing for programmers — the
compiler doesn’t always do what you expect it should do.
The L suffix is not as common, but it is occasionally used for similar reasons as above: to make it
obvious that the compiler is using long arithmetic.
The bottom line is this: it is a good discipline for programmers to force all numeric operands to be
of the right type, as opposed to relying on the C++ rules for promoting/demoting numeric
expressions. For example, if x is of type int and y is of type unsigned, it is a good idea to
change x + y so the next programmer knows whether you intended to use unsigned arithmetic,
e.g., unsigned(x) + y, or signed arithmetic: x + int(y). The other possibility is long
arithmetic: long(x) + long(y). By using those casts, the code is more explicit and that’s good
in this case, since a lot of programmers don’t know all the rules for implicit promotions.
I can understand the and (&&) and or (||) operators, but
what’s the purpose of the not (!) operator?
Some people are confused about the ! operator. For example, they think that !true is the same
as false, or that !(a < b) is the same as a >= b, so in both cases the ! operator doesn’t seem to
add anything.
Answer: The ! operator is useful in boolean expressions, such occur in an if or while statement.
For example, let’s assume A and B are boolean expressions, perhaps simple method-calls that return
a bool. There are all sorts of ways to combine these two expressions:
1. if ( A && B) /*...*/ ;
2. if (!A && B) /*...*/ ;
3. if ( A && !B) /*...*/ ;
4. if (!A && !B) /*...*/ ;
5. if (!( A && B)) /*...*/ ;
6. if (!(!A && B)) /*...*/ ;
7. if (!( A && !B)) /*...*/ ;
8. if (!(!A && !B)) /*...*/ ;
Along with a similar group formed using the || operator.
Note: boolean algebra can be used to transform each of the &&-versions into an equivalent ||-
version, so from a truth-table standpoint there are only 8 logically distinct if statements. However,
since readability is so important in software, programmers should consider both the &&-version and
the logically equivalent ||-version. For example, programmers should choose between !A && !
B and !(A || B) based on which one is more obvious to whoever will be maintaining the code. In
that sense there really are 16 different choices.
The point of all this is simple: the ! operator is quite useful in boolean expressions. Sometimes it is
used for readability, and sometimes it is used because expressions like !(a < b) actually
are not equivalent to a >= b in spite of what your grade school math teacher told you.
Is !(a < b) logically the same as a >= b?
 No!
Despite what your grade school math teacher taught you, these equivalences don’t always work in
software, especially with floating point expressions or user-defined types.
Example: if a is a floating point NaN, then both a < b and a >= b will be false. That means !(a
< b) will be true and a >= b will be false.
Example: if a is an object of class Foo that has overloaded operator< and operator>=, then it is
up to the creator of class Foo if these operators will have opposite semantics. They
probably should have opposite semantics, but that’s up to whoever wrote class Foo.
What is this NaN thing?
NaN means “not a number,” and is used for floating point operations.
There are lots of floating point operations that don’t make sense, such as dividing by zero, taking
the log of zero or a negative number, taking the square root of a negative number, etc. Depending on
your compiler, some of these operations may produce special floating point values such as infinity
(with distinct values for positive vs. negative infinity) and the not a number value, NaN.
If your compiler produces a NaN, it has the unusual property that it is not equal to any value,
including itself. For example, if a is NaN, then a == a is false. In fact, if a is NaN, then a will be
neither less than, equal to, nor greater than any value including itself. In other words, regardless of
the value of b, a < b, a <= b, a > b, a >= b, and a == b will all return false.
Here’s how to check if a value is NaN:
1. #include <cmath>
2.
3. void funct(double x)
4. {
5. if (isnan(x)) { // Though see caveat below
6. // x is NaN
7. // ...
8. } else {
9. // x is a normal value
10. // ...
11. }
12. }
Note: although isnan() is part of the latest C standard library, your C++ compiler vendor might
not supply it. For example, Microsoft Visual C++.NET does not supply isnan() (though it does
supply _isnan() defined in <float.h>). If your vendor does not supply any variant of isnan(),
define this function:
1. inline bool my_isnan(double x)
2. {
3. return x != x;
4. }
In any case, DO NOT WRITE ME just to say that your compiler does/does not support isnan().
Why is floating point so inaccurate? Why doesn’t this print
0.43?
1. #include <iostream>
2.
3. int main()
4. {
5. float a = 1000.43;
6. float b = 1000.0;
7. std::cout << a - b << '\n';
8. // ...
9. }
(On one C++ implementation, this prints 0.429993)
Disclaimer: Frustration with rounding/truncation/approximation isn’t really a C++ issue; it’s a
computer science issue. However, people keep asking about it on comp.lang.c++, so what
follows is a nominal answer.
Answer: Floating point is an approximation. The IEEE standard for 32 bit float supports 1 bit of
sign, 8 bits of exponent, and 23 bits of mantissa. Since a normalized binary-point mantissa always
has the form 1.xxxxx… the leading 1 is dropped and you get effectively 24 bits of mantissa. The
number 1000.43 (and many, many others, including some really common ones like 0.1) is not
exactly representable in float or double format. 1000.43 is actually represented as the following
bitpattern (the “s” shows the position of the sign bit, the “e“s show the positions of the exponent
bits, and the “m“s show the positions of the mantissa bits):
1. seeeeeeeemmmmmmmmmmmmmmmmmmmmmmm
2. 01000100011110100001101110000101
The shifted mantissa is 1111101000.01101110000101 or 1000 + 7045/16384. The fractional part is
0.429992675781. With 24 bits of mantissa you only get about 1 part in 16M of precision for float.
The double type provides more precision (53 bits of mantissa).
Why doesn’t my floating-point comparison work?
Because floating point arithmetic is different from real number arithmetic.
Bottom line: Never use == to compare two floating point numbers.
Here’s a simple example:
1. double x = 1.0 / 10.0;
2. double y = x * 10.0;
3. if (y != 1.0)
4. std::cout << "surprise: " << y << " != 1\n";
The above “surprise” message will appear on some (but not all) compilers/machines. But even if
your particular compiler/machine doesn’t cause the above “surprise” message (and if you write me
telling me whether it does, you’ll show you’ve missed the whole point of this FAQ), floating point
will surprise you at some point. So read this FAQ and you’ll know what to do.
The reason floating point will surprise you is that float and double values are normally
represented using a finite precision binary format. In other words, floating point numbers are not
real numbers. For example, in your machine’s floating point format it might be impossible to
exactly represent the number 0.1. By way of analogy, it’s impossible to exactly represent the
number one third in decimal format (unless you use an infinite number of digits).
To dig a little deeper, let’s examine what the decimal number 0.625 means. This number has a 6 in
the “tenths” place, a 2 in the “hundreths” place, and a 5 in the “thousanths” place. In other words,
we have a digit for each power of 10. But in binary, we might, depending on the details of your
machine’s floating point format, have a bit for each power of 2. So the fractional part might have a
“halves” place, a “quarters” place, an “eighths” place, “sixteenths” place, etc., and each of these
places has a bit.
Let’s pretend your machine represents the fractional part of floating point numbers using the above
scheme (it’s normally more complicated than that, but if you already know exactly how floating
point numbers are stored, chances are you don’t need this FAQ to begin with, so look at this as a
good starting point). On that pretend machine, the bits of the fractional part of 0.625 would be 101:
1 in the ½-place, 0 in the ¼-place, and 1 in the ⅛-place. In other words, 0.625 is ½ + ⅛.
 But on this pretend machine, 0.1 cannot be represented exactly since it cannot be formed as a sum of
a finite number of powers of 2. You can get close but you can’t represent it exactly. In particular
you’d have a 0 in the ½-place, a 0 in the ¼-place, a 0 in the ⅛-place, and finally a 1 in the
“sixteenths” place, leaving a remainder of 1/10 - 1/16 = 3/80. Figuring out the other bits is left as an
exercise (hint: look for a repeating bit-pattern, analogous to trying to represent 1/3 or 1/7 in decimal
format).
The message is that some floating point numbers cannot always be represented exactly, so
comparisons don’t always do what you’d like them to do. In other words, if the computer actually
multiplies 10.0 by 1.0/10.0, it might not exactly get 1.0 back.
That’s the problem. Now here’s the solution: be very careful when comparing floating point
numbers for equality (or when doing other things with floating point numbers; e.g., finding the
average of two floating point numbers seems simple but to do it right requires an if/else with at
least three cases).
Here’s the wrong way to do it:
1. void dubious(double x, double y)
2. {
3. // ...
4. if (x == y) // Dubious!
5. foo();
6. // ...
7. }
If what you really want is to make sure they’re “very close” to each other (e.g., if
variable a contains the value 1.0 / 10.0 and you want to see if (10*a == 1)), you’ll
probably want to do something fancier than the above:
1. void smarter(double x, double y)
2. {
3. // ...
4. if (isEqual(x, y)) // Smarter!
5. foo();
6. // ...
7. }
There are many ways to define the isEqual() function, including:
1. #include <cmath> /* for std::abs(double) */
2.
3. inline bool isEqual(double x, double y)
4. {
5. const double epsilon = /* some small number such as 1e-5 */;
6. return std::abs(x - y) <= epsilon * std::abs(x);
7. // see Knuth section 4.2.2 pages 217-218
8. }
Note: the above solution is not completely symmetric, meaning it is possible for isEqual(x,y) !
= isEqual(y,x). From a practical standpoint, does not usually occur when the magnitudes
of x and y are significantly larger than epsilon, but your mileage may vary.
For other useful functions, check out the following (listed alphabetically):
 Isaacson, E. and Keller, H., Analysis of Numerical Methods, Dover.
 Kahan, W., http.cs.berkeley.edu/~wkahan/.
 Knuth, Donald E., The Art of Computer Programming, Volume II: Seminumerical
Algorithms, Addison-Wesley, 1969.
 LAPACK: Linear Algebra Subroutine Library, www.siam.org
 NETLIB: the collected algorithms from ACM Transactions on Mathematical Software,
which have all been refereed, plus a great many other algorithms that have withstood somewhat
less formal scrutiny from peers, www.netlib.org
  Numerical Recipes, by Press et al. Although note some negative reviews, such
as amath.colorado.edu/computing/Fortran/numrec.html
 Ralston and Rabinowitz, A First Course in Numerical Analysis: Second Edition, Dover.
 Stoer, J. and Bulirsch, R., Introduction to Numerical Analysis, Springer Verlag, in German.
Double-check your assumptions, including “obvious” things like how to compute averages, how to
solve quadratic equations, etc., etc. Do not assume the formulas you learned in High School will
work with floating point numbers!
For insights on the underlying ideas and issues of floating point computation, start with David
Goldberg’s paper, What Every Computer-Scientist Should Know About Floating Point Arithmetic or here
in PDF format. You might also want to read this supplement by Doug Priest. The combined paper +
supplement is also available. You might also want to go here for links to other floating-point topics.
Why is cos(x) != cos(y) even though x == y? (Or sine or
tangent or log or just about any other floating point
computation)
I know it’s hard to accept, but floating point arithmetic simply does not work like most people
expect. Worse, some of the differences are dependent on the details of your particular computer’s
floating point hardware and/or the optimization settings you use on your particular compiler. You
might not like that, but it’s the way it is. The only way to “get it” is to set aside your assumptions
about how things ought to behave and accept things as they actually do behave.
Let’s work a simple example. Turns out that on some installations, cos(x) != cos(y) even
though x == y. That’s not a typo; read it again if you’re not shocked: the cosine of something can
be unequal to the cosine of the same thing. (Or the sine, or the tangent, or the log, or just about any
other floating point computation.)
1. #include <iostream>
2. #include <cmath>
3.
4. void foo(double x, double y)
5. {
6. if (std::cos(x) != std::cos(y)) {
7. std::cout << "Huh?!?\n"; // You might end up here when x == y!!
8. }
9. }
10.
11. int main()
12. {
13. foo(1.0, 1.0);
14. return 0;
15. }
On many (not all) computers, you will end up in the if block even when x == y. If that doesn’t
shock you, you’re asleep; read it again. If you want, try it on your particular computer. Some of you
will end up in the if block, some will not, and for some it will depend on the details of your
particular compiler or options or hardware or the phase of the moon.
Why, you ask, can that happen? Good question; thanks for asking. Here’s the answer (with
emphasis on the word “often”; the behavior depends on your hardware, compiler, etc.): floating
point calculations and comparisons are often performed by special hardware that often contain
special registers, and those registers often have more bits than a double. That means that
intermediate floating point computations often have more bits than sizeof(double), and when a
floating point value is written to RAM, it often gets truncated, often losing some bits of precision.
Said another way, intermediate calculations are often more precise (have more bits) than when those
same values get stored into RAM. Think of it this way: storing a floating point result into RAM
requires some bits to get discarded, so comparing a (truncated) value in RAM with an (untruncated)
 value within a floating-point register might not do what you expect. Suppose your code
computes cos(x), then truncates that result and stores it into a temporary variable, say tmp. It
might then compute cos(y), and (drum roll please) compare the untruncated result
of cos(y) with tmp, that is, with the truncated result of cos(x). Expressed in an imaginary
assembly language, the expression cos(x) != cos(y) might get compiled into this:
1. // Imaginary assembly language
2. fp_load x // load a floating-point register with the value of parameter x
3. call _cos // call cos(double), using the floating point register for param and result
4. fp_store tmp // truncate the floating-point result and store into temporary local var, tmp
5.
6. fp_load y // load a floating-point register with the value of parameter y
7. call _cos // call cos(double), using the floating point register for param ans result
8. fp_cmp tmp // compare the untruncated result (in the register) with the truncated value in tmp
9. // ...
Did you catch that? Your particular installation might store the result of one of the cos() calls out
into RAM, truncating it in the process, then later compare that truncated value with
the untruncated result of the second cos() call. Depending on lots of details, those two values might
not be equal.
It gets worse; better sit down. Turns out that the behavior can depend on how many instructions are
between the cos() calls and the != comparison. In other words, if you
put cos(x) and cos(y) into locals, then later compare those variables, the result of the
comparison can depend on exactly what, if anything, your code does after storing the results into
locals and comparing the variables. Gulp.
1. void foo(double x, double y)
2. {
3. double cos_x = cos(x);
4. double cos_y = cos(y);
5. // the behavior might depend on what's in here
6. if (cos_x != cos_y) {
7. std::cout << "Huh?!?\n"; // You might end up here when x == y!!
8. }
9. }
Your mouth should be hanging open by now. If not, you either learned pretty quickly from the
above or you are still asleep. Read it again. When x == y, you can still end up in the if block
depending on, among other things, how much code is in the ... line. Wow.
Reason: if the compiler can prove that you’re not messing with any floating point registers in
the ... line, it might not actually store cos(y) into cos_y, instead leaving it in the register and
comparing the untruncated register with the truncated variable cos_x. In this case, you might end
up in the if block. But if you call a function between the two lines, such as printing one or both
variables, or if you do something else that messes with the floating point registers, the compiler will
(might) need to store the result of cos(y) into variable cos_y, after which it will be comparing
two truncated values. In that case you won’t end up in the if block.
If you didn’t hear anything else in this whole discussion, just remember this: floating point
comparisons are tricky and subtle and fraught with danger. Be careful. The way floating
point actually works is different from the way most programmers tend to think it ought to work. If
you intend to use floating point, you need to learn how it actually works.
What is the type of an enumeration such as enum Color? Is
it of type int?
An enumeration such as enum Color { red, white, blue }; is its own type. It is not of
type int.
 When you create an object of an enumeration type, e.g., Color x;, we say that the object x is of
type Color. Object x isn’t of type “enumeration,” and it’s not of type int.
An expression of an enumeration type can be converted to a temporary int. An analogy may help
here. An expression of type float can be converted to a temporary double, but that doesn’t
mean float is a subtype of double. For example, after the declaration float y;, we say that y is
of type float, and the expression y can be converted to a temporary double. When that happens,
a brand new, temporary double is created by copying something out of y. In the same way,
a Color object such as x can be converted to a temporary int, in which case a brand new,
temporary int is created by copying something out of x. (Note: the only purpose of
the float / double analogy in this paragraph is to help explain how expressions of an enumeration
type can be converted to temporary ints; do not try to use that analogy to imply any other
behavior!)
The above conversion is very different from a subtype relationship, such as the relationship between
derived class Car and its base class Vehicle. For example, an object of class Car, such as Car
z;, actually is an object of class Vehicle, therefore you can bind a Vehicle& to that object,
e.g., Vehicle& v = z;. Unlike the previous paragraph, the object z is not copied to a temporary;
reference v binds to z itself. So we say an object of class Car is a Vehicle, but an object of class
“Color” simply can be copied/converted into a temporary int. Big difference.
Final note, especially for C programmers: the C++ compiler will not automatically convert
an int expression to a temporary Color. Since that sort of conversion is unsafe, it requires a cast,
e.g., Color x = Color(2);. But be sure your integer is a valid enumeration value. If you go
provide an illegal value, you might end up with something other than what you expect. The
compiler doesn’t do the check for you; you must do it yourself.
If an enumeration type is distinct from any other type,
what good is it? What can you do with it?
Let’s consider this enumeration type: enum Color { red, white, blue };.
The best way to look at this (C programmers: hang on to your seats!!) is that the values of this type
are red, white, and blue, as opposed to merely thinking of those names as constant int values.
The C++ compiler provides an automatic conversion from Color to int, and the converted values
will be, in this case, 0, 1, and 2 respectively. But you shouldn’t think of blue as a fancy name for
2. blue is of type Color and there is an automatic conversion from blue to 2, but the inverse
conversion, from int to Color, is not provided automatically by the C++ compiler.
Here is an example that illustrates the conversion from Color to int:
1. enum Color { red, white, blue };
2.
3. void f()
4. {
5. int n;
6. n = red; // change n to 0
7. n = white; // change n to 1
8. n = blue; // change n to 2
9. }
The following example also demonstrates the conversion from Color to int:
1. void f()
2. {
3. Color x = red;
4. Color y = white;
5. Color z = blue;
6.
7. int n;
8. n = x; // change n to 0
9. n = y; // change n to 1
10. n = z; // change n to 2
11. }
However the inverse conversion, from int to Color, is not automatically provided by the C++
compiler:
1. void f()
2. {
3. Color x;
4. x = blue; // change x to blue
5. x = 2; // compile-time error: can't convert int to Color
6. }
The last line above shows that enumeration types are not ints in disguise. You can think of them
as int types if you want to, but if you do, you must remember that the C++ compiler will not
implicitly convert an int to a Color. If you really want that, you can use a cast:
1. void f()
2. {
3. Color x;
4. x = red; // change x to red
5. x = Color(1); // change x to white
6. x = Color(2); // change x to blue
7. x = 2; // compile-time error: can't convert int to Color
8. }
There are other ways that enumeration types are unlike int. For example, enumeration types don’t
have a ++ operator:
1. void f()
2. {
3. int n = red; // change n to 0
4. Color x = red; // change x to red
5.
6. n++; // change n to 1
7. x++; // compile-time error: can't ++ an enumeration (though see caveat below)
8. }
Caveat on the last line: it is legal to provide an overloaded operator that would make that line legal,
such as definining operator++(Color& x).
What other “newbie” guides are there for me?
An excellent place to start is this site’s Get Started page.

Learning C++
Save to:
InstapaperPocketReadability
Contents of this section:

 What is mentoring?
 Should I learn C before I learn C++?
 Should I learn Objective-C or another OO language before I learn C++?
 How do I start learning C++?
 What is the best book to learn C++ from?
 Should I buy one book, or several?
 What are some best-of-breed C++ morality guides?
 What are some best-of-breed C++ legality guides?
 What are some best-of-breed C++ programming-by-example guides?
 Are there other books that are relevant to C++?
 Will someone here help me with my homework?
 Where can I get a free C++ compiler?
What is mentoring?
It’s the most important tool in learning a new technology.
Object-oriented and generic thinking is caught, not just taught. Get cozy with someone
who really knows what they’re talking about, and try to get inside their head and watch them solve
problems. Listen. Learn by emulating.
If you’re working for a company, get them to bring someone in who can act as a mentor and guide.
We’ve seen gobs and gobs of money wasted by companies who “saved money” by simply buying
their employees a book (“Here’s a book; read it over the weekend; on Monday you’ll be an
OO/generic developer”).

Should I learn C before I learn C++?

Don’t bother.
The common subset of C and C++ is easier to learn than C. There will be less type errors to catch
manually (the C++ type system is stricter and more expressive), fewer tricks to learn (C++ allows
you to express more things without circumlocution), and better libraries available. The best initial
subset of C++ to learn is not “all of C”.
The go-to book to learn C++ is Stroustrup’s A Tour of C++. Run, don’t walk, to read and
recommend this core overview.
If you want additional options: See Stroustrup’s Learning Standard C++ as a New Language for a
discussion of the choice of C++ constructs, techniques, and libraries for early learning. For an
example of books that takes that approach systematically, see Stroustrup’s Programming: Principles
and Practice using C++ and Koenig & Moo’ Accelerated C++ from Addison Wesley’s C++ In
Depth series.
If your ultimate goal is to learn C++ and you don’t already know C, reading books or taking courses
in C will not only waste your time, but it will teach you a bunch of things that you’ll explicitly have
to un-learn when you finally get back on track and learn C++
(e.g., malloc(), printf(), unnecessary use of switch statements, error-code exception
handling, unnecessary use of #define macros, etc.).
If you want to learn C++, learn C++. Taking time out to learn C will waste your time and confuse
you.

Should I learn Objective-C or another OO language before I

learn C++?
Don’t bother.
Learning something new is almost always a good idea. However, each language is different and has
its own styles and quirks. Code written in some supposedly “pure” OO style modeled on some other
language (quirks and all) is often sub-optimal and frustrating when too literally transcribed into C+
+. Also, “writing just pure Object-oriented code” is not one of C++’s ideals; see Stroustrup’s
OOPSLA keynote Why C++ isn’t just an Object-Oriented Programming Language. If you want to
become a good C++ programmer and don’t have a few months to spare, concentrate on C++ and the
concepts it embodies.
If your ultimate goal is to learn C++ and you don’t already know Objective-C, reading books or
taking courses in Objective-C will not only waste your time, but it will teach you a bunch of things
 that you’ll explicitly have to un-learn when you finally get back on track and learn C++
(e.g., dynamic typing, non-subtyping inheritance, error-code exception handling, etc.).
Knowing a “pure” OO language doesn’t make the transition to OO/C++ any easier. This is not a
theory; we have trained and mentored literally thousands of software professionals in OO. In fact,
Objective-C experience can make it harder for some people: they need to unlearn some rather deep
notions about typing and inheritance in addition to needing to learn new syntax and idioms. This
unlearning process is especially painful and slow for those who cling to Objective-C with religious
zeal (“C++ is not like Objective-C, therefore C++ is evil”).
If you want to learn C++, learn C++. Taking time out to learn Objective-C will waste your time and
confuse you.

How do I start learning C++?

Quick answer: Read Stroustrup’s A Tour of C++.
Naturally, that strongly depends on what you already know and your reasons for learning C++. If
you are a novice at programming, we strongly recommend that you find an experienced programmer
to help you. Otherwise, the inevitable mistakes about language concepts and practical problems with
the implementation you use can magnify into serious frustrations.
You’ll need a textbook for learning C++. This is the case even when your implementation comes
with ample on-line documentation. The reason is that language and library documentation together
with sample code are not good teachers of concepts. Typically such sources are silent about why
things are the way they are and what benefits you can expect (and which you shouldn’t expect) from
a technique. Focus on concepts and techniques rather than language-technical details.
When choosing a book, look for one that presents Standard C++ and uses the standard library
facilities in an integrated manner from the start. For example, reading a string from input should
look something like
1. string s; // Standard C++ style
2. cin >> s;
and not like this
1. char s[MAX]; /* Standard C style */
2. scanf("%s",s);
Look for book recommendations from programmers with solid C++ experience.
For a gentle introduction suitable even for people who have never programmed before, a great book
is Programming: Principles and Practice using C++, but remember that no one book is the best for
everyone. Have a look at the book reviews on the ACCU (The Association of C and C++ Users)
site.
Aim to write idiomatic C++: Avoid simply writing code in the style of your previous language using
C++ syntax. There is little to be gained from simply changing syntax.

What is the best book to learn C++ from?

See also why to buy several books.
If you are new to programming (have never programmed before), consider Programming: Principles
and Practice using C++. This is the book Bjarne Stroustrup wrote for a freshman (1st year university
students) programming class and it has benefited from three years of classroom use.
Otherwise, the go-to book to learn C++ is Stroustrup’s A Tour of C++. Run, don’t walk, to read and
recommend this core overview.
If you want additional options: See Stroustrup’s Learning Standard C++ as a New Language for a
discussion of the choice of C++ constructs, techniques, and libraries for early learning. For an
example of books that takes that approach systematically, see Stroustrup’s Programming: Principles
 and Practice using C++ and Koenig & Moo’ Accelerated C++ from Addison Wesley’s C++ In
Depth series.
When looking for a second or third book, it depends what you’re looking for and on your learning
style. There are quite a few excellent books on C++. Have a look at the ACCU (The Association of
C and C++ Users) site. This is one of the best sites for book recommendations by experienced
programmers who are not afraid to speak their mind (booksellers tend to give rosy reviews, and
reviews of the form “This book is perfect, I love it, I have read almost three chapters, and can’t wait
to read more” are worse than useless – why anyone would take advice on how to learn C++ from
someone who completely lacks C++ experience beats me). The ACCU rates books for level of
experience required and overall quality.
For people who are programmers and willing to learn new concepts and techniques from a classical
textbook, we recommend The C++ Programming Language (4th edition). See a note about the
structure, contents, and aims of “The C++ Programming Language (3rd edition)”: The book is
aimed at programmers with some experience and a wish to master C++. It is not aimed at non-
programmers trying to learn their first programming language or casual programmers trying to gain
a superficial understanding of C++ as fast as possible. Consequently, this book focuses on concepts
and techniques and goes to some pain to be complete and precise. It describes “pure C++,” that is,
the language independently of any particular software development environment or foundation
library (except the standard library, of course).
If you want to know why C++ is the way it is, have a look at The Design and Evolution of C++
(D&E). Understanding the design criteria and constraints helps writing better programs.
Should I buy one book, or several?
At least three.
There are three categories of insight and knowledge in OO programming using C++. You should get
a great book from each category, not an okay book that tries to do an okay job at everything. The
three OO/C++ programming categories are:
 C++ legality guides — what you can and can’t do in C++.
 C++ morality guides — what you should and shouldn’t do in C++.
 Programming-by-example guides — show lots of examples, normally making liberal use of
the C++ standard library.
Legality guides describe all language features with roughly the same level of emphasis; morality
guides focus on those language features that you will use most often in typical programming tasks.
Legality guides tell you how to get a given feature past the compiler; morality guides tell you
whether or not to use that feature in the first place.
Meta comments:
 Don’t trade off these categories against each other. You shouldn’t argue in favor of one
category over the other. They dove-tail.
 The “legality” and “morality” categories are both required. You must have a good grasp of
both what can be done and what should be done.
In addition to these (emphasis on “addition”), you should consider at least one book in each of two
other categories: at least one book on OO Design plus at least one book on coding standards. Design
books give you ideas and guidelines for thinking at a higher level with objects, and coding standard
books establish best practices across your organization, plus help make sure everybody can read
each others’ code (e.g., so you can move people around if one of the teams falls behind).
What are some best-of-breed C++ morality guides?
Here’s a subjective and selective short-list of must-read C++ morality guides, alphabetically by
author:
 Cline, Lomow, and Girou, C++ FAQs, Second Edition, 587 pgs, Addison-Wesley, 1999,
ISBN 0-201-30983-1. Covers around 500 topics in a FAQ-like Q&A format.
 Meyers, Effective C++, Third Edition, 320 pgs, Addison-Wesley, 2005, ISBN 0321334876.
Covers 55 topics in a short essay format. Also C++98.
 Meyers, Effective Modern C++, 336 pgs, O’Reilly Media, 2014, ISBN 1491903996. Covers
42 topics in a short essay format. C++14.
 Meyers, More Effective C++, 336 pgs, Addison-Wesley, 1996, ISBN 0-201-63371-X.
Covers 35 topics in a short essay format. Also C++98.
Similarities: All three books are extensively illustrated with code examples. All three are excellent,
insightful, useful, gold plated books. All three have excellent sales records. Of these, only Effective
Modern C++ covers C++11 and C++14. The others cover C++98.
Differences: Cline/Lomow/Girou’s examples are complete, working programs rather than code
fragments or standalone classes. Meyers contains numerous line-drawings that illustrate the points.
What are some best-of-breed C++ legality guides?
As before, the go-to book to learn C++ is Stroustrup’s A Tour of C++. This takes you “around
modern C++ in 180 pages.”
Beyond that, here is a subjective and selective short-list of must-read C++ legality guides,
alphabetically by author:
 Lippman, Lajoie and Moo, C++ Primer, Fifth Edition, 976 pgs, Addison-Wesley, 2012,
ISBN 978-0321714114. Very readable/approachable, and covers C++11.
 Stroustrup, The C++ Programming Language, Fourth Edition, 1368 pgs, Addison-Wesley,
2013, ISBN 978-0321563842. Covers a lot of ground and the definitive reference for C++11.
Both books are excellent overviews of almost every language feature. They’re both top notch, gold
plated, excellent books. Both have excellent sales records.

What are some best-of-breed C++ programming-by-

example guides?
Here’s a subjective and selective short-list of must-read C++ programming-by-example guides:
 Koenig and Moo, Accelerated C++, 336 pgs, Addison-Wesley, 2000, ISBN 0-201-70353-X.
Lots of examples using the standard C++ library. Truly a programming-by-example book.
 Musser and Saini, STL Tutorial and Reference Guide, Second Edition, Addison-Wesley,
2001, ISBN 0-201-037923-6. Lots of examples showing how to use the STL portion of the
standard C++ library, plus lots of nitty gritty detail.
Are there other books that are relevant to C++?
Yes! Tons!
The morality, legality, and by-example categories listed above were for programming. The areas of
analysis and design are also relevant, and have their own best-of-breed books.
There are tons and tons of good books in these other areas. The seminal book on design patterns is
(in my personal, subjective and selective, opinion) a must-read book: Gamma et al., Design
Patterns, 395 pgs, Addison-Wesley, 1995, ISBN 0-201-63361-2. Describes “patterns” that
commonly show up in good designs. You must read this book if you intend to do OO and generic
design work.
Will someone here help me with my homework?
No. Sorry. We don’t do (other people’s) homework. We get too many requests for help with
homework and help with finding bugs in student programs to be able to find the time. Anyway,
 having a distant expert fix your programs is not the best way to learn. Try finding a local person
with C++ experience that you can ask for guidance. A good mentor is the best help a student can
have; maybe that’s why they are not easy to find.
Also, no, we will not suggest “a good project for a student to work on”. Our experience is that
learning enough about a student and his/her course to know what level of difficulty is required and
what kind of project is of interest takes time. To think of a good project is then non-trivial, and to
explain exactly what the project is and how to approach it can take several messages and several
hours. We just don’t have that kind of time. Remember, these request come at least weekly. Finally,
some students seem to have the idea that if we suggest a project, we are morally obliged to provide
quite detailed help in its completion.
Ideas: Look at the exercises in TC++PL4 or other good textbooks. Many of those exercises are
designed to keep a student busy for several days, and reading those exercises can inspire an
enterprising student to so something similar. Or look at the non-computer-science part of your
world: Maybe a biology project could use support for a new measurement device or a friend
studying history could use an improved database interface. Many of the best projects and the best
uses of computers are outside traditional computer science!
See also Stroustrup’s C++ style and techniques FAQ. Real novices facing their first “read some
data, do something to it, and produce some output” exercise might be interested in a very simple
program or a program reading a string from input.
Where can I get a free C++ compiler?
From lots of places; see isocpp.org’s Get Started page.

Coding Standards
Save to:
InstapaperPocketReadability
Contents of this section:

 What are some good C++ coding standards?

 Are coding standards necessary? Are they sufficient?
 Should our organization determine coding standards from our C experience?
 What’s the difference between <cxxx> and <xxx.h> headers?
 Should I use using namespace std in my code?
 Is the ?: operator evil since it can be used to create unreadable code?
 Should I declare locals in the middle of a function or at the top?
 What source-file-name convention is best? foo.cpp? foo.C? foo.cc?
 What header-file-name convention is best? foo.H? foo.hh? foo.hpp?
 Are there any lint-like guidelines for C++?
 Why do people worry so much about pointer casts and/or reference casts?
 Which is better: identifier names that_look_like_this or identifier
names thatLookLikeThis?
 Are there any other sources of coding standards?
 Should I use “unusual” syntax?
 What’s a good coding standard for using global variables?
What are some good C++ coding standards?
Thank you for reading this answer rather than just trying to set your own coding standards.
The main point of a C++ coding standard is to provide a set of rules for using C++ for a particular
purpose in a particular environment. It follows that there cannot be one coding standard for all uses
 and all users. For a given application (or company, application area, etc.), a good coding standard is
better than no coding standard. On the other hand, we have seen many examples that demonstrate
that a bad coding standard is worse than no coding standard. Please choose your rules with care and
with solid knowledge of your application area. Some of the worst coding standards (we won’t
mention names “to protect the guilty”) were written by people without solid knowledge of C++
together with a relative ignorance of the application area (they were “experts” rather than
developers) and a misguided conviction that more restrictions are necessarily better than fewer. The
counter example to that last misconception is that some features exist to help programmers having
to use even worse features. Anyway, please remember that safety, productivity, etc. is the sum of all
parts of the design and development process – and not of individual language features, or even of
whole languages.
With those caveats, we recommend four things:
 Look at the C++ Core Guidelines. They’re a collaborative effort led by Bjarne Stroustrup,
much like the C++ language itself. They are the result of many person-years of discussion and
design across a number of organizations. Their design encourages general applicability and broad
adoption but they can be freely copied and modified to meet your organization’s needs.
 Look at Sutter and Alexandrescu: “C++ Coding Standards”. It provides 101 rules, guidelines
and best practices. The authors and editors produced some solid material, then did an unusually
good job of energizing the peer-review team. All of this improved the book. Buy it. It has good
specific rules, but won’t cover every rule that might apply to your team. So also view it as an
exemplar and guide to what a good, more specific, set of coding rules should look like. If you are
writing a coding standard, you ignore this book at your peril.
 Look at the JSF air vehicle C++ coding standards. Stroustrup considers it a pretty good set of
rules for safety critical and performance critical code. If you do embedded systems programming,
you should consider it. If you don’t build hard-real time systems or safety critical systems, you’ll
find these rules overly restrictive – because then those rules are not for you (at least not all of
those rules).
 Don’t use C coding standards (even if slightly modified for C++) and don’t use ten-year-old
C++ coding standards (even if good for their time). C++ isn’t (just) C and Standard C++ is not
(just) pre-standard C++.
A word of warning: Nearly every software engineer has, at some point, been exploited by someone
who used coding standards as a “power play.” Dogmatism over minutiae is the purview of the
intellectually weak. Don’t be like them. These are those who can’t contribute in any meaningful
way, who can’t actually improve the value of the software product, so instead of exposing their
incompetence through silence, they blather with zeal about nits. They can’t add value in
the substance of the software, so they argue over form. Just because “they” do that doesn’t mean
coding standards are bad, however.
Another emotional reaction against coding standards is caused by coding standards set by
individuals with obsolete skills. For example, someone might set today’s standards based on what
programming was like N decades ago when the standards setter was writing code. Such impositions
generate an attitude of mistrust for coding standards. As above, if you have been forced to endure an
unfortunate experience like this, don’t let it sour you to the whole point and value of coding
standards. It doesn’t take a very large organization to find there is value in having consistency, since
different programmers can edit the same code without constantly reorganizing each others’ code in a
tug-of-war over the “best” coding standard.
Are coding standards necessary? Are they sufficient?
Coding standards do not make non-OO programmers into OO programmers; only training and
experience do that. If coding standards have merit, it is that they discourage the petty fragmentation
that occurs when large organizations coordinate the activities of diverse groups of programmers.
 But you really want more than a coding standard. The structure provided by coding standards gives
neophytes one less degree of freedom to worry about, which is good. However, pragmatic
guidelines should go well beyond pretty-printing standards. Organizations need a
consistent philosophy of design and implementation. E.g., strong or weak typing? references or
pointers in interfaces? stream I/O or stdio? should C++ code call C code? vice versa? how
should ABCs be used? should inheritance be used as an implementation technique or as a
specification technique? what testing strategy should be employed? inspection strategy? should
interfaces uniformly have a get() and/or set() member function for each data member? should
interfaces be designed from the outside-in or the inside-out? should errors be handled
by try/catch/throw or by return codes? etc.
What is needed is a “pseudo standard” for detailed design. I recommend a three-pronged approach
to achieving this standardization: training, mentoring, and libraries. Training provides “intense
instruction,” mentoring allows OO to be caught rather than just taught, and high quality C++ class
libraries provide “long term instruction.” There is a thriving commercial market for all three kinds
of “training.” Advice by organizations who have been through the mill is consistent: Buy, Don’t
Build. Buy libraries, buy training, buy tools, buy consulting. Companies who have attempted to
become a self-taught tool-shop as well as an application/system shop have found success difficult.
Few argue that coding standards are “ideal,” or even “good,” however they are necessary in the kind
of organizations/situations described above.
The following FAQs provide some basic guidance in conventions and styles.

Should our organization determine coding standards from

our C experience?
No!
No matter how vast your C experience, no matter how advanced your C expertise, being a good C
programmer does not make you a good C++ programmer. Converting from C to C++ is more than
just learning the syntax and semantics of the ++ part of C++. Organizations who want the promise
of OO, but who fail to put the “OO” into “OO programming”, are fooling themselves; the balance
sheet will show their folly.
C++ coding standards should be tempered by C++ experts. Asking comp.lang.c++ is a start. Seek
out experts who can help guide you away from pitfalls. Get training. Buy libraries and see if “good”
libraries pass your coding standards. Do not set standards by yourself unless you have considerable
experience in C++. Having no standard is better than having a bad standard, since improper
“official” positions “harden” bad brain traces. There is a thriving market for both C++ training and
libraries from which to pull expertise.
One more thing: whenever something is in demand, the potential for charlatans increases. Look
before you leap. Also ask for student-reviews from past companies, since not even expertise makes
someone a good communicator. Finally, select a practitioner who can teach, not a full time teacher
who has a passing knowledge of the language/paradigm.

What’s the difference

between <cxxx> and <xxx.h> headers?
The headers in ISO Standard C++ don’t have a .h suffix. This is something the standards
committee changed from former practice. The details are different between headers that existed in C
and those that are specific to C++.
The C++ standard library is guaranteed to have 18 standard headers from the C language. These
headers come in two standard flavors, <cxxx> and <xxx.h> (where xxx is the basename of the
 header, such as stdio, stdlib, etc). These two flavors are identical except the <cxxx> versions
provide their declarations in the std namespace only, and the <xxx.h> versions make them
available both in std namespace and in the global namespace. The committee did it this way so that
existing C code could continue to be compiled in C++. However the <xxx.h> versions are
deprecated, meaning they are standard now but might not be part of the standard in future revisions.
(See clause D.5 of the ISO C++ standard.)
The C++ standard library is also guaranteed to have 32 additional standard headers that have no
direct counterparts in C, such as <iostream>, <string>, and <new>. You may see things
like #include <iostream.h> and so on in old code, and some compiler vendors
offer .h versions for that reason. But be careful: the .h versions, if available, may differ from the
standard versions. And if you compile some units of a program with, for
example, <iostream> and others with <iostream.h>, the program may not work.
For new projects, use only the <cxxx> headers, not the <xxx.h> headers.
When modifying or extending existing code that uses the old header names, you should probably
follow the practice in that code unless there’s some important reason to switch to the standard
headers (such as a facility available in standard <iostream> that was not available in the
vendor’s <iostream.h>). If you need to standardize existing code, make sure to change all C++
headers in all program units including external libraries that get linked in to the final executable.
All of this affects the standard headers only. You’re free to use a different naming convention on
your own headers.
Should I use using namespace std in my code?
Probably not.
People don’t like typing std:: over and over, and they discover that using namespace std lets
the compiler see any std name, even if unqualified. The fly in that ointment is that it lets the
compiler see any std name, even the ones you didn’t think about. In other words, it can create
name conflicts and ambiguities.
For example, suppose your code is counting things and you happen to use a variable or function
named count. But the std library also uses the name count (it’s one of the std algorithms),
which could cause ambiguities.
Look, the whole point of namespaces is to prevent namespace collisions between two independently
developed piles of code. The using-directive (that’s the technical name for using namespace
XYZ) effectively dumps one namespace into another, which can subvert that goal. The using-
directive exists for legacy C++ code and to ease the transition to namespaces, but you probably
shouldn’t use it on a regular basis, at least not in your new C++ code.
If you really want to avoid typing std::, then you can either use something else called a using-
declaration, or get over it and just type std:: (the un-solution):
 Use a using-declaration, which brings in specific, selected names. For example, to allow
your code to use the name cout without a std:: qualifier, you could insert using
std::cout into your code. This is unlikely to cause confusion or ambiguity because the names
you bring in are explicit.
1. #include <vector>
2. #include <iostream>
3.
4. void f(const std::vector<double>& v)
5. {
6. using std::cout; // ← a using-declaration that lets you use cout without qualification
7.
8. cout << "Values:";
9. for (auto value : v)
10. cout << ' ' << value;
 11. cout << '\n';
12. }
 Get over it and just type std:: (the un-solution):
1. #include <vector>
2. #include <iostream>
3.
4. void f(const std::vector<double>& v)
5. {
6. std::cout << "Values:";
7. for (auto value : v)
8. std::cout << ' ' << value;
9. std::cout << '\n';
10. }
I personally find it’s faster to type “std::” than to decide, for each distinct std name, whether or
not to include a using-declaration and if so, to find the best scope and add it there. But either way is
fine. Just remember that you are part of a team, so make sure you use an approach that is consistent
with the rest of your organization.
Is the ?: operator evil since it can be used to create
unreadable code?
No, but as always, remember that readability is one of the most important things.
Some people feel the ?: ternary operator should be avoided because they find it confusing at times
compared to the good old if statement. In many cases ?: tends to make your code more difficult to
read (and therefore you should replace those usages of ?: with if statements), but there are times
when the ?: operator is clearer since it can emphasize what’s really happening, rather than the fact
that there’s an if in there somewhere.
Let’s start with a really simple case. Suppose you need to print the result of a function call. In that
case you should put the real goal (printing) at the beginning of the line, and bury the function call
within the line since it’s relatively incidental (this left-right thing is based on the intuitive notion that
most developers think the first thing on a line is the most important thing):
1. // Preferred (emphasizes the major goal — printing):
2. std::cout << funct();
3.
4. // Not as good (emphasizes the minor goal — a function call):
5. functAndPrintOn(std::cout);
Now let’s extend this idea to the ?: operator. Suppose your real goal is to print something, but you
need to do some incidental decision logic to figure out what should be printed. Since the printing is
the most important thing conceptually, we prefer to put it first on the line, and we prefer to bury the
incidental decision logic. In the example code below, variable n represents the number of senders of
a message; the message itself is being printed to std::cout:
1. int n = /*...*/; // number of senders
2.
3. // Preferred (emphasizes the major goal — printing):
4. std::cout << "Please get back to " << (n==1 ? "me" : "us") << " soon!\n";
5.
6. // Not as good (emphasizes the minor goal — a decision):
7. std::cout << "Please get back to ";
8. if (n == 1)
9. std::cout << "me";
10. else
11. std::cout << "us";
12. std::cout << " soon!\n";
 All that being said, you can get pretty outrageous and unreadable code (“write only code”) using
various combinations of ?:, &&, ||, etc. For example,
1. // Preferred (obvious meaning):
2. if (f())
3. g();
4.
5. // Not as good (harder to understand):
6. f() && g();
Personally I think if (f()) g() is clearer than f() && g() since the first emphasizes the major
thing that’s going on (a decision based on the result of calling f()) rather than the minor thing
(calling f()). In other words, the use of if here is good for precisely the same reason that it
was bad above: we want to major on the majors and minor on the minors.
In any event, don’t forget that readability is the goal (at least it’s one of the goals). Your goal
should not be to avoid certain syntactic constructs such as ?: or && or || or if — or even goto. If
you sink to the level of a “Standards Bigot,” you’ll ultimately embarass yourself since there are
always counterexamples to any syntax-based rule. If on the other hand you emphasize broad goals
and guidelines (e.g., “major on the majors,” or “put the most important thing first on the line,” or
even “make sure your code is obvious and readable”), you’re usually much better off.
Code must be written to be read, not by the compiler, but by another human being.

Should I declare locals in the middle of a function or at

the top?
Declare near first use.
An object is initialized (constructed) the moment it is declared. If you don’t have enough
information to initialize an object until half way down the function, you should create it half way
down the function when it can be initialized correctly. Don’t initialize it to an “empty” value at the
top then “assign” it later. The reason for this is runtime performance. Building an object correctly is
faster than building it incorrectly and remodeling it later. Simple examples show a factor of 350%
speed hit for simple classes like String. Your mileage may vary; surely the overall system
degradation will be less that 350%, but there will be degradation. Unnecessary degradation.
A common retort to the above is: “we’ll provide set() member functions for every datum in our
objects so the cost of construction will be spread out.” This is worse than the performance overhead,
since now you’re introducing a maintenance nightmare. Providing a set() member function for
every datum is tantamount to public data: you’ve exposed your implementation technique to the
world. The only thing you’ve hidden is the physical names of your member objects, but the fact that
you’re using a List and a String and a float, for example, is open for all to see.
Bottom line: Locals should be declared near their first use. Sorry that this isn’t familiar to C experts,
but new doesn’t necessarily mean bad.

What source-file-name convention is

best? foo.cpp? foo.C? foo.cc?
If you already have a convention, use it. If not, consult your compiler to see what the compiler
expects. Typical answers are: .cpp, .C, .cc, or .cxx (naturally the .C extension assumes a case-
sensitive file system to distinguish .C from .c).
We’ve often used .cpp for our C++ source files, and we have also used .C. In the latter case, when
porting to case-insensitive file systems you need to tell the compiler to treat .c files as if they were
C++ source files (e.g., -Tdp for IBM CSet++, -cpp for Zortech C++, -P for Borland C++, etc.).
 The point is that none of these filename extensions are uniformly superior to the others. We
generally use whichever technique is preferred by our customer (again, these issues are dominated
by business considerations, not by technical considerations).

What header-file-name convention is

best? foo.H? foo.hh? foo.hpp?
If you already have a convention, use it. If not, and if you don’t need your editor to distinguish
between C and C++ files, simply use .h. Otherwise use whatever the editor wants, such as .H, .hh,
or .hpp.
We’ve tended to use either .h or .hpp for our C++ header files.
Are there any lint-like guidelines for C++?
Yes, there are some practices which are generally considered dangerous. However none of these are
universally “bad,” since situations arise when even the worst of these are needed:
 A class Fred’s assignment operator should return *this as a Fred& (allows chaining
of assignments)
 A class with any virtual functions ought to have a virtual destructor
 A class with any of {destructor, copy assignment operator, copy constructor, move
assignment operator, move constructor} generally needs all 5
 A class Fred’s copy constructor and assignment operator should have const in the
parameter: respectively Fred::Fred(const Fred&) and Fred& Fred::operator=
(const Fred&)
 When initializing an object’s member objects in the constructor, always use initialization lists
rather than assignment. The performance difference for user-defined classes can be substantial
(3x!)
 Assignment operators should make sure that self assignment does nothing, otherwise you
may have a disaster. In some cases, this may require you to add an explicit test to your assignment
operators.
 When you overload operators, abide by the guidelines. For example, in classes that define
both += and +, a += b and a = a + b should generally do the same thing; ditto for the other
identities of built-in/intrinsic types (e.g., a += 1 and ++a; p[i] and *(p+i); etc). This can be
enforced by writing the binary operations using the op= forms. E.g.,
1. Fred operator+ (const Fred& a, const Fred& b)
2. {
3. Fred ans = a;
4. ans += b;
5. return ans;
6. }
This way the “constructive” binary operators don’t even need to be friends. But it is sometimes
possible to more efficiently implement common operations (e.g., if class Fred is
actually std::string, and += has to reallocate/copy string memory, it may be better to know
the eventual length from the beginning).
Why do people worry so much about pointer casts and/or
reference casts?
Because they’re evil! (Which means you should use them sparingly and with great care.)
For some reason, programmers are sloppy in their use of pointer casts. They cast this to that all over
the place, then they wonder why things don’t quite work right. Here’s the worst thing: when the
 compiler gives them an error message, they add a cast to “shut the compiler up,” then they “test it”
to see if it seems to work. If you have a lot of pointer casts or reference casts, read on.
The compiler will often be silent when you’re doing pointer-casts and/or reference casts. Pointer-
casts (and reference-casts) tend to shut the compiler up. I think of them as a filter on error messages:
the compiler wants to complain because it sees you’re doing something stupid, but it also sees that
it’s not allowed to complain due to your pointer-cast, so it drops the error message into the bit-
bucket. It’s like putting duct tape on the compiler’s mouth: it’s trying to tell you something
important, but you’ve intentionally shut it up.
A pointer-cast says to the compiler, “Stop thinking and start generating code; I’m smart, you’re
dumb; I’m big, you’re little; I know what I’m doing so just pretend this is assembly language and
generate the code.” The compiler pretty much blindly generates code when you start casting — you
are taking control (and responsibility!) for the outcome. The compiler and the language reduce (and
in some cases eliminate!) the guarantees you get as to what will happen. You’re on your own.
By way of analogy, even if it’s legal to juggle chainsaws, it’s stupid. If something goes wrong, don’t
bother complaining to the chainsaw manufacturer — you did something they didn’t guarantee
would work. You’re on your own.
(To be completely fair, the language does give you some guarantees when you cast, at least in a
limited subset of casts. For example, it’s guaranteed to work as you’d expect if the cast happens to
be from an object-pointer (a pointer to a piece of data, as opposed to a pointer-to-function or
pointer-to-member) to type void* and back to the same type of object-pointer. But in a lot of cases
you’re on your own.)
Which is better: identifier names that_look_like_this or
identifier names thatLookLikeThis?
It’s a precedent thing. If you have a Java background, youProbablyUseLowerCamelCase like
this; if your background is C#, YouProbablyUseUpperCamelCase like this. Ada
programmers Typically_Use_A_Lot_Of_Underscores, Microsoft Windows/C programmers
tend to prefer “Hungarian” style
(jkuidsPrefixing vndskaIdentifiers ncqWith ksldjfTheir nmdsadType), and folks
with a Unix/C
background abbr evthng n sght, usng vry shrt idntfr nms. AND THE FORTRN PRGMRS WHO
LIMIT EVRYTH TO SIX CAPITL LETTRS.
So there is no universal standard. If your project team has a particular coding standard for identifier
names, use it. But starting another war over this will create a lot more heat than light. From a
business perspective, there are only two things that matter: The code should be generally readable,
and everyone on the team should use the same style.
Other than that, th difs r minr.
One more thing: don’t import a coding style onto platform-specific code where it is foreign. For
example, a coding style that seems natural while using a Microsoft library might look bizarre and
random while using a UNIX library. Don’t do it. Allow different styles for different platforms. (Just
in case someone out there isn’t reading carefully, don’t send me email about the case of common
code that is designed to be used/ported to several platforms, since that code wouldn’t be platform-
specific, so the above “allow different styles” guideline doesn’t even apply.)
One more. This time I mean it. Really. Don’t fight the coding styles used by automatically
generated code (e.g., by tools that generate code). Some people treat coding standards with religious
zeal, and they try to get tools to generate code in their local style. Forget it: if a tool generates code
 in a different style, don’t worry about it. Remember money and time?!? This whole coding standard
thing was supposed to save money and time; don’t turn it into a “money pit.”
Are there any other sources of coding standards?
Yep, there are several.
In my opinion, the best source is Sutter and Alexandrescu, C++ Coding Standards, 220 pgs,
Addison-Wesley, 2005, ISBN 0-321-11358-6. I had the privilege of serving as an advisor on that
book, and the authors did a great job of energizing the pool of advisors. Everyone collaborated with
an intensity and depth that I have not seen previously, and the book is better for it.
Here are a few other sources that you can use as starting points for developing your organization’s
coding standards (in random order) (some are out of date, some might even be bad; I’m not
endorsing any; caveat emptor):
 www.codingstandard.com/
 cdfsga.fnal.gov/computing/coding_guidelines/CodingGuidelines.html
 www.nfra.nl/~seg/cppStdDoc.html
 www.cs.umd.edu/users/cml/resources/cstyle
 www.cs.rice.edu/~dwallach/CPlusPlusStyle.html
 cpptips.hyperformix.com/conventions/cppconventions_1.html
 www.objectmentor.com/resources/articles/naming.htm
 www.arcticlabs.com/codingstandards/
 www.possibility.com/cpp/CppCodingStandard.html
 www.cs.umd.edu/users/cml/cstyle/Wildfire-C++Style.html
 The Ellemtel coding guidelines are available at
 membres.lycos.fr/pierret/cpp2.htm
 www.cs.umd.edu/users/cml/cstyle/Ellemtel-rules.html
 www.doc.ic.ac.uk/lab/cplus/c++.rules/
 www.mgl.co.uk/people/kirit/cpprules.html
Notes:
 The Ellemtel guide is dated, but is listed because of its seminal place: it was the first widely
distributed and widely adopted set of coding guidelines for C++. It was also the first to castigate
the use of protected data.
 Industrial Strength C++ is also dated, but was the first widely published place to mention the
use of protected non-virtual destructors in base classes.
Should I use “unusual” syntax?
Only when there is a compelling reason to do so. In other words, only when there is no “normal”
syntax that will produce the same end-result.
Software decisions should be made based on money. Unless you’re in an ivory tower somewhere,
when you do something that increases costs, increases risks, increases time, or, in a constrained
environment, increases the product’s space/speed costs, you’ve done something “bad.” In your mind
you should translate all these things into money.
Because of this pragmatic, money-oriented view of software, programmers should avoid non-
mainstream syntax whenever there exists a “normal” syntax that would be equivalent. If a
programmer does something obscure, other programmers are confused; that costs money. These
other programmers will probably introduce bugs (costs money), take longer to maintain the thing
(money), have a harder time changing it (missing market windows = money), have a harder time
optimizing it (in a constrained environment, somebody will have to spend money for more memory,
a faster CPU, and/or a bigger battery), and perhaps have angry customers (money). It’s a risk-
 reward thing: using abnormal syntax carries a risk, but when an equivalent, “normal” syntax would
do the same thing, there is no “reward” to ameliorate that risk.
For example, the techniques used in the Obfuscated C Code Contest are, to be polite, non-normal.
Yes many of them are legal, but not everything that is legal is moral. Using strange techniques will
confuse other programmers. Some programmers love to “show off” how far they can push the
envelope, but that puts their ego above money, and that’s unprofessional. Frankly anybody who
does that ought to be fired. (And if you think I’m being “mean” or “cruel,” I suggest you get an
attitude adjustment. Remember this: your company hired you to help it, not to hurt it, and anybody
who puts their own personal ego-trips above their company’s best interest simply ought to be shown
the door.)
As an example of non-mainstream syntax, it’s not “normal” to use the ?: operator as a statement.
(Some people don’t even like it as an expression, but everyone must admit that there are a lot of
uses of ?: out there, so it is “normal” (as an expression) whether people like it or not.) Here is an
example of using using ?: as a statement:
1. blah();
2. blah();
3. xyz() ? foo() : bar(); // should replace with if/else
4. blah();
5. blah();
Same goes with using || and && as if they are “if-not” and “if” statements, respectively. Yes,
those are idioms in Perl, but C++ is not Perl and using these as replacements for if statements (as
opposed to using them as expressions) is just not “normal” in C++. Example:
1. foo() || bar(); // should replace with if (!foo()) bar();
2. foo() && bar(); // should replace with if (foo()) bar();
Here’s another example that seems to work and may even be legal, but it’s certainly not normal:
1. void f(const& MyClass x) // use const MyClass& x instead
2. {
3. // ...
4. }

What’s a good coding standard for using global

variables?
The names of global variables should start with //.
Here’s the ideal way to use a global variable:
1. void mycode()
2. {
3. // do_something_with(xyz);
4. ↑↑ // The leading "//" improves this global variable
5. }
It’s a joke.
Sort of.
The truth is that there are cases when global variables are less evil than the alternatives — when
globals are the lesser of the evils. But they’re still evil. So wash your hands after using them. Twice.
Instead of using a global variable, you should seriously consider if there are ways to limit the
variable’s visibility and/or lifetime, and if multiple threads are involved, either limit the visibility to
a single thread or do something else to protect the system against race cases.
 Note: if you wish to limit the visibility but neither lifetime nor thread safety, two of the many
approaches are to either move the variable into a class as a static data member or to use an
unnamed namespace. Here is how to move the variable into a class as a static data member:
1. class Foo {
2. // ...
3. static int xyz; // See the Construct Members On First Use Idiom
4. // ...
5. }
Here is how to use an unnamed namespace:
1. namespace {
2. // ...
3. int xyz; // See the Construct On First Use Idiom for non-members
4. // ...
5. }
Repeat: there are three major considerations: visibility, lifetime, and thread safety. The above
examples address only one of those three considerations.

Learning C++ if you already know Objective-

C
Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the difference between C++ and Objective-C?

 What is “static typing,” and how is it similar/dissimilar to Objective-C?
 Which is a better fit for C++: “static typing” or “dynamic typing”?
 How do you use inheritance in C++, and is that different from Objective-C?
 What are the practical consequences of differences in Objective-C/C++ inheritance?
What’s the difference between C++ and Objective-C?
Both fully support the OO paradigm. Neither is categorically and universally “better” than the other.
But there are differences. The most important differences are:
 Static typing vs. dynamic typing
 Whether inheritance must be used only for subtyping
 Value vs. reference semantics
Note: If you have a Objective-C background, this section will tell you the most important things you
need to effectively use C++. Please don’t get the notion that either language is somehow “inferior”
or “bad”, or that this section is promoting one language over the other. I am not a language bigot,
having served on both the ANSI C++ and ANSI Smalltalk standardization committees, and I don’t
recommend language bigotry. Instead, this section is designed to help you understand (and
embrace!) the differences.
What is “static typing,” and how is it similar/dissimilar to
Objective-C?
Static typing says the compiler checks the type safety of every operation statically (at compile-time),
rather than to generate code which will check things at run-time. For example, with static typing, the
signature matching for function arguments is checked at compile time, not at run-time. An improper
match is flagged as an error by the compiler, not by the run-time system.
In OO code, the most common “typing mismatch” is invoking a member function against an object
which isn’t prepared to handle the operation. E.g., if class Fred has member function f() but
 not g(), and fred is an instance of class Fred, then fred.f() is legal and fred.g() is illegal.
C++ (statically typed) catches the error at compile time, and the @dynamic part@ of Objective-C
(dynamically typed) catches the error at run-time. (Technically speaking, C++ is like Pascal —
pseudo statically typed— since pointer casts and unions can be used to violate the typing system;
which reminds me: use pointer casts and unions only as often as you use gotos).
Which is a better fit for C++: “static typing” or “dynamic
typing”?
[For context, please read the previous FAQ].
If you want to use C++ most effectively, use it as a statically typed language.
C++ is flexible enough that you can (via pointer casts, unions, and #define macros) make it “look”
like Objective-C. But don’t. Which reminds me: try to avoid #define: it is evil in 4 different
ways: evil#1, evil#2, evil#3, and evil#4.
There are places where pointer casts and unions are necessary and even wholesome, but they should
be used carefully and sparingly. A pointer cast tells the compiler to believe you. An incorrect
pointer cast might corrupt your heap, scribble into memory owned by other objects, call nonexistent
member functions, and cause general failures. It’s not a pretty sight. If you avoid these and related
constructs, you can make your C++ code both safer and faster, since anything that can be checked at
compile time is something that doesn’t have to be done at run-time.
If you’re interested in using a pointer cast, use the new style pointer casts. The most common
example of these is to change old-style pointer casts such as (X*)p into new-style dynamic casts
such as dynamic_cast<X*>(p), where p is a pointer and X is a type. In addition
to dynamic_cast, there is static_cast and const_cast, but dynamic_cast is the one that
simulates most of the advantages of dynamic typing (the other is the typeid() construct; for
example, typeid(*p).name() will return the name of the type of *p).
How do you use inheritance in C++, and is that different
from Objective-C?
Some people believe that the purpose of inheritance is code reuse. In C++, this is wrong. Stated
plainly, “inheritance is not for code reuse.”
The purpose of inheritance in C++ is to express interface compliance (subtyping), not to get code
reuse. In C++, code reuse usually comes via composition rather than via inheritance. In other words,
inheritance is mainly a specification technique rather than an implementation technique.
This is a major difference with Objective-C, where there is only one form of inheritance (C++
provides private inheritance to mean “share the code but don’t conform to the interface”,
and public inheritance to mean “kind-of”). The Objective-C language proper (as opposed to
coding practice) allows you to have the effect of “hiding” an inherited method by providing an
override that calls the “does not understand” method. Furthermore Objective-C allows a conceptual
“is-a” relationship to exist apart from the inheritance hierarchy (subtypes don’t have to be derived
classes; e.g., you can make something that is-a Stack yet doesn’t inherit from class Stack).
In contrast, C++ is more restrictive about inheritance: there’s no way to make a “conceptual is-a”
relationship without using inheritance (the C++ work-around is to separate interface from
implementation via ABCs). The C++ compiler exploits the added semantic information associated
with public inheritance to provide static typing.
What are the practical consequences of differences in
Objective-C/C++ inheritance?
[For context, please read the previous FAQ].
 Objective-C lets you make a subtype that isn’t a derived class, and allows you to make a derived
class that isn’t a subtype. This allows Objective-C programmers to be very carefree in putting data
(bits, representation, data structure) into a class (e.g., you might put a linked list
into class Stack). After all, if someone wants an array-based-Stack, they don’t have to inherit
from Stack; they could inherit such a class from Array if desired, even though
an ArrayBasedStack is not a kind-of Array!
In C++, you can’t be nearly as carefree. Only mechanism (member function code), but not
representation (data bits) can be overridden in derived classes. Therefore you’re usually better
off not putting the data structure in a class. This leads to a stronger reliance on abstract base classes.
I like to think of the difference between an ATV and a Maserati. An ATV (all terrain vehicle) is
more fun, since you can “play around” by driving through fields, streams, sidewalks, and the like. A
Maserati, on the other hand, gets you there faster, but it forces you to stay on the road. My advice to
C++ programmers is simple: stay on the road. Even if you’re one of those people who like the
“expressive freedom” to drive through the bushes, don’t do it in C++; it’s not a good fit.

Learning C++ if you already know C# or Java

Save to:
InstapaperPocketReadability
Contents of this section:

 Note: This section needs more material

 What’s the difference between C++ and C#/Java?
 Why doesn’t C++ have a universal class Object?
 Is “generics” what templates should have been?
Note: This section needs more material
This section contains initial information but needs additional FAQs. If you can supply a common
question asked by C# or Java programmers coming to C++, please hover over any FAQ title and
click the icon for “recommend an improvement.” (If you can also supply a sketch of an answer
along with the question, that would be great but is optional.)

What’s the difference between C++ and C#/Java?

All three languages fully support the OO paradigm. Neither is categorically and universally “better”
than the other. But there are differences. The most important differences are:
 Value vs. reference semantics
Why doesn’t C++ have a universal class Object?
 We don’t need one: Generic programming provides statically type safe alternatives in most
cases. Other cases are handled using multiple inheritance.
 There is no useful universal class: A truly universal carries no semantics of its own.
 A “universal” class encourages sloppy thinking about types and interfaces and leads to
excess run-time checking.
 Using a universal base class implies cost: Objects must be heap-allocated to be polymorphic;
that implies memory and access cost. Heap objects don’t naturally support copy semantics. Heap
objects don’t support simple scoped behavior (which complicates resource management). A
universal base class encourages use of dynamic_cast and other run-time checking.
Yes, the above simplifies the arguments. This is a FAQ, not an academic paper.

Is “generics” what templates should have been?

 No. C++ templates support a strict superset of C# and Java generics – everything you can do in C#
or Java, you can do in C++, and a lot more. This FAQ summarizes those capabilities.
Generics in Java and C# are primarily syntactic sugar for abstract classes and virtual function calls;
that is, with generics (whether Java or C# generics), you program against precisely defined
interfaces and typically pay the cost of virtual function calls and/or dynamic casts to use arguments.
You can do the same in C++, by using container<InterfacePtr> where InterfacePtr can
be any appropriate raw or smart pointer type, for example vector<Base*> that doesn’t own its
objects or list<unique_ptr<Base>> that does own its objects and will destroy and free them
promptly and deterministically.
But templates go beyond that, and support generic programming, template metaprogramming, etc.
through a combination of features such as integer template arguments, specialization, and uniform
treatment of built-in and user-defined types. You can write special case code for when your template
is instantiated with a specific type or a subset of types. You can use class types just as easily as
built-in types. You can pass non-type parameters, like integers with compile-time information like
the fixed size of an array (e.g., std::array<widget,10> is a fixed-size array of 10 objects of
type widget). And more… The result is flexibility, generality, and performance unmatched by
“generics”. The STL is the prime example.
So the “generics” features of C# and Java are fully supported, but as just one narrow special case or
a much more general, expressive, and high-performance feature. As a simple example, but a real
one that matters a lot for performance, C++ supports vector<AnyType> with true contiguous
storage no matter what type AnyType is, which is not possible in C# and Java where contiguous
storage is only for the built-in types and in C#’s case also structs, not for class types which are the
vast majority of types.
For balance, note that a less desirable result of C++’s template flexibility is late detection of errors
and horrendously bad error messages. This is currently being addressed indirectly with constraints
classes, and soon directly by the upcoming Concepts language feature that directly targets this
problem.

Learning C++ if you already know C

Save to:
InstapaperPocketReadability
Contents of this section:

 Is it easy to migrate from C to C++?

 What’s the difference between C++ and C?
 Is C a subset of C++?
 Why use sort() when we have good old qsort()?
 Why must I use a cast to convert from void*?
Is it easy to migrate from C to C++?
Yes! C++ is nearly exactly a superset of Standard C95 (C90 and the 1995 Amendment 1). With very
few exceptions, every valid C95 program is also a valid C++ program with the same meaning.
A great first step is to simply use C++ as “a better C,” which means that you can program in the C
subset of C++ and find the experience better than in C because C++ provides extra type-checking
and sometimes extra performance even for plain C code.
Of course, C++ also provides much more! Once you start compiling your existing C code as C++,
you can just start selectively using C++ features tactically here and there as you’re comfortable –
and start seeing benefits right away in each line of code.
 What’s the difference between C++ and C?
C++ is a direct descendant of C95 (C90 plus an Amendment) that retains almost all of C95 as a
subset. C++ provides stronger type checking than C and directly supports a wider range of
programming styles than C. C++ is “a better C” in the sense that it supports the styles of
programming done using C with better type checking and more notational support (without loss of
efficiency). In the same sense, ANSI C90/C95 is a better C than K&R C. In addition, C++ supports
data abstraction, object-oriented programming, and generic programming (see The C++
Programming Language; Appendix B discussing compatibility issues is available for downloading).
We have never seen a program that could be expressed better in C95 than in C++ (and we don’t
think such a program could exist – every construct in C95 has an obvious C++ equivalent).
However, there still exist a few environments where the support for C++ is so weak that there is an
advantage to using C instead. There aren’t all that many of those left, though; see Stroustrup’s
(incomplete) compilers list.
For a discussion of the design of C++ including a discussion of its relationship with C see The
Design and Evolution of C++.
Please note that “C” in the paragraphs above refers to Classic C and C95 (C90 with an
Amendment). C++ is not a descendant of C99; rather, both are derived from C95. C++11 adopted
all of C99’s preprocessor extensions and library extensions, but not C99’s new language features, so
language features like the restrict keyword that were added in C99 are generally not part of ISO
C++. Here is a description of the differences between C++98 and C99.
Is C a subset of C++?
In the strict mathematical sense, C isn’t a subset of C++. There are programs that are valid C but not
valid C++ and even a few ways of writing code that has a different meaning in C and C++.
However, C++ supports every programming technique supported by C95 (C90 plus an Amendment)
and earlier. Every such C program can be written in essentially the same way in C++ with the same
run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of
ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of C95 as C95 is a superset
of K&R C and as much as ISO C++ is a superset of C++ as it existed in 1985.
Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie:
“The C Programming Language (2nd Edition)” is also a C++ program.
Examples of C/C++ compatibility problems:
1. int main()
2. {
3. double sq2 = sqrt(2); /* Not C++: call undeclared function */
4. int s = sizeof('a'); /* silent difference: 1 in C++ sizeof(int) in C */
5. }
Calling an undeclared function is poor style in C and illegal in C++. So is passing arguments to a
function using a declaration that doesn’t list argument types:
1. void f(); /* argument types not mentioned */
2.
3. void g()
4. {
5. f(2); /* poor style C. Not C++ */
6. }
In C, a void* can be implicitly converted to any pointer type, and free-store allocation is typically
done using malloc() which has no way of checking if “enough” memory is requested:
1. void* malloc(size_t);
2.
3. void f(int n)
4. {
5. int* p = malloc(n*sizeof(char)); /* not C++. In C++, allocate using `new' */
6. char c;
7. void* pv = &c;
8. int* pi = pv; /* implicit conversion of void* to int*. Not in C++ */
9. }
Note the potential alignment error caused by the implicit conversion of the void* to an int*.
See the C++ alternative to void* and malloc().
When converting from C to C++, beware that C++ has more keywords than C:
1. int class = 2; /* ok in C. Syntax error in C++ */
2. int virtual = 3; /* ok in C. Syntax error in C++ */
Except for a few examples such as the ones shown above (and listed in detail in the C++ standard
and in Appendix B of The C++ Programming Language (3rd Edition)), C++ is a superset of C.
(Appendix B is available for downloading).
Please note that “C” in the paragraphs above refers to Classic C and C95 (C90 with an
Amendment). C++ is not a descendant of C99; rather, both are derived from C95. C++11 adopted
all of C99’s preprocessor extensions and library extensions, but not C99’s new language features, so
language features like the restrict keyword that were added in C99 are generally not part of ISO
C++. Here is a description of the differences between C++98 and C99.
Why use sort() when we have good old qsort()?
To a novice,
1. qsort(array,asize,sizeof(elem),elem_compare);
looks pretty weird, and is harder to understand than
1. sort(vec.begin(),vec.end());
To an expert, the fact that sort() tends to be faster than qsort() for the same elements and the
same comparison criteria is often significant. Also, sort() is generic, so that it can be used for any
reasonable combination of container type, element type, and comparison criterion. For example:
1. struct Record {
2. string name;
3. // ...
4. };
5.
6. struct name_compare { // compare Records using "name" as the key
7. bool operator()(const Record& a, const Record& b) const
8. { return a.name<b.name; }
9. };
10.
11. void f(vector<Record>& vs)
12. {
13. sort(vs.begin(), vs.end(), name_compare());
14. // ...
15. }
If you have a compiler supporting C++14, this gets even simpler:
1. struct Record {
2. string name;
3. // ...
4. };
5.
6. void f(vector<Record>& vs)
7. {
8. sort(vs.begin(), vs.end(), [](auto &a, auto &b) { return a.name < b.name; });
9. // ...
10. }
In addition, most people appreciate that sort() is type safe, that no casts are required to use it, and
that they don’t have to write a compare() function for standard types.
For a more detailed explanation, see Stroustrup’s paper “Learning C++ as a New language”, which
can be downloaded from his publications list.
The primary reason that sort() tends to outperform qsort() is that the comparison inlines better.
Why must I use a cast to convert from void*?
In C, you can implicitly convert a void* to a T*. This is unsafe. Consider:
1. #include<stdio.h>
2.
3. int main()
4. {
5. char i = 0;
6. char j = 0;
7. char* p = &i;
8. void* q = p;
9. int* pp = q; /* unsafe, legal C, not C++ */
10.
11. printf("%d %d\n",i,j);
12. *pp = -1; /* overwrite memory starting at &i */
13. printf("%d %d\n",i,j);
14. }
The effects of using a T* that doesn’t point to a T can be disastrous. Consequently, in C++, to get
a T* from a void* you need an explicit cast. For example, to get the undesirable effects of the
program above, you have to write:
1. int* pp = (int*)q;
or, using a new style cast to make the unchecked type conversion operation more visible:
1. int* pp = static_cast<int*>(q);
Casts are best avoided.
One of the most common uses of this unsafe conversion in C is to assign the result of malloc() to
a suitable pointer. For example:
1. int* p = malloc(sizeof(int));
In C++, use the typesafe new operator:
1. int* p = new int;
Incidentally, the new operator offers additional advantages over malloc():
 new can’t accidentally allocate the wrong amount of memory,
 new implicitly checks for memory exhaustion, and
 new provides for initialization
For example:
1. typedef std::complex<double> cmplx;
2.
3. /* C style: */
4. cmplx* p = (cmplx*)malloc(sizeof(int)); /* error: wrong size */
5. /* forgot to test for p==0 */
6. if (*p == 7) { /* ... */ } /* oops: forgot to initialize *p */
7.
8. // C++ style:
9. cmplx* q = new cmplx(1,2); // will throw bad_alloc if memory is exhausted
10. if (*q == 7) { /* ... */ }
 How to mix C and C++
Save to:
InstapaperPocketReadability
Contents of this section:

 What do I need to know when mixing C and C++ code?

 How do I call a C function from C++?
 How do I call a C++ function from C?
 How can I include a standard C header file in my C++ code?
 How can I include a non-system C header file in my C++ code?
 How can I modify my own C header files so it’s easier to #include them in C++ code?
 How can I call a non-system C function f(int,char,float) from my C++ code?
 How can I create a C++ function f(int,char,float) that is callable by my C code?
 Why is the linker giving errors for C/C++ functions being called from C++/C functions?
 How can I pass an object of a C++ class to/from a C function?
 Can my C function directly access data in an object of a C++ class?
 Why do I feel like I’m “further from the machine” in C++ as opposed to C?
What do I need to know when mixing C and C++ code?
Here are some high points (though some compiler-vendors might not require all these; check with
your compiler-vendor’s documentation):
 You must use your C++ compiler when compiling main() (e.g., for static initialization)
 Your C++ compiler should direct the linking process (e.g., so it can get its special libraries)
 Your C and C++ compilers probably need to come from the same vendor and have
compatible versions (e.g., so they have the same calling conventions)
In addition, you’ll need to read the rest of this section to find out how to make your C functions
callable by C++ and/or your C++ functions callable by C.
BTW there is another way to handle this whole thing: compile all your code (even your C-style
code) using a C++ compiler. That pretty much eliminates the need to mix C and C++, plus it will
cause you to be more careful (and possibly —hopefully!— discover some bugs) in your C-style
code. The down-side is that you’ll need to update your C-style code in certain ways, basically
because the C++ compiler is more careful/picky than your C compiler. The point is that the effort
required to clean up your C-style code may be less than the effort required to mix C and C++, and as
a bonus you get cleaned up C-style code. Obviously you don’t have much of a choice if you’re not
able to alter your C-style code (e.g., if it’s from a third-party).
How do I call a C function from C++?
Just declare the C function extern "C" (in your C++ code) and call it (from your C or C++ code).
For example:
1. // C++ code
2.
3. extern "C" void f(int); // one way
4.
5. extern "C" { // another way
6. int g(double);
7. double h();
8. };
9.
10. void code(int i, double d)
11. {
12. f(i);
13. int ii = g(d);
14. double dd = h();
15. // ...
16. }
The definitions of the functions may look like this:
1. /* C code: */
2.
3. void f(int i)
4. {
5. /* ... */
6. }
7.
8. int g(double d)
9. {
10. /* ... */
11. }
12.
13. double h()
14. {
15. /* ... */
16. }
Note that C++ type rules, not C rules, are used. So you can’t call function declared extern
"C" with the wrong number of arguments. For example:
1. // C++ code
2.
3. void more_code(int i, double d)
4. {
5. double dd = h(i,d); // error: unexpected arguments
6. // ...
7. }

How do I call a C++ function from C?

Just declare the C++ function extern "C" (in your C++ code) and call it (from your C or C++
code). For example:
1. // C++ code:
2.
3. extern "C" void f(int);
4.
5. void f(int i)
6. {
7. // ...
8. }
Now f() can be used like this:
1. /* C code: */
2.
3. void f(int);
4.
5. void cc(int i)
6. {
7. f(i);
8. /* ... */
9. }
Naturally, this works only for non-member functions. If you want to call member functions (incl.
virtual functions) from C, you need to provide a simple wrapper. For example:
1. // C++ code:
2.
3. class C {
4. // ...
5. virtual double f(int);
6. };
7.
8. extern "C" double call_C_f(C* p, int i) // wrapper function
9. {
10. return p->f(i);
11. }
Now C::f() can be used like this:
1. /* C code: */
2.
3. double call_C_f(struct C* p, int i);
4.
5. void ccc(struct C* p, int i)
6. {
7. double d = call_C_f(p,i);
8. /* ... */
9. }
If you want to call overloaded functions from C, you must provide wrappers with distinct names for
the C code to use. For example:
1. // C++ code:
2.
3. void f(int);
4. void f(double);
5.
6. extern "C" void f_i(int i) { f(i); }
7. extern "C" void f_d(double d) { f(d); }
Now the f() functions can be used like this:
1. /* C code: */
2.
3. void f_i(int);
4. void f_d(double);
5.
6. void cccc(int i,double d)
7. {
8. f_i(i);
9. f_d(d);
10. /* ... */
11. }
Note that these techniques can be used to call a C++ library from C code even if you cannot (or do
not want to) modify the C++ headers.

How can I include a standard C header file in my C++

code?
To #include a standard header file (such as <cstdio>), you don’t have to do anything unusual.
E.g.,
1. // This is C++ code
2.
3. #include <cstdio> // Nothing unusual in #include line
4.
5. int main()
6. {
7. std::printf("Hello world\n"); // Nothing unusual in the call either
8. // ...
9. }
The std:: part of the std::printf() call may look unusual if you’re coming from C, but this is
the correct way to write it in C++.
If you are compiling C code using your C++ compiler, you don’t want to have to tweak all these
calls from printf() to std::printf(). Fortunately in this case the C code will use the old-style
header <stdio.h> rather than the new-style header <cstdio>, and the magic of namespaces will
take care of everything else:
1. /* This is C code that I'm compiling using a C++ compiler */
2.
3. #include <stdio.h> /* Nothing unusual in #include line */
4.
5. int main()
6. {
7. printf("Hello world\n"); /* Nothing unusual in the call either */
8. // ...
9. }
Final comment: if you have C headers that are not part of the standard library, we have somewhat
different guidelines for you. There are two cases: either you can’t change the header, or
you can change the header.
How can I include a non-system C header file in my C++
code?
If you are including a C header file that isn’t provided by the system, you may need to wrap
the #include line in an extern "C" { /*...*/ } construct. This tells the C++ compiler that
the functions declared in the header file are C functions.
1. // This is C++ code
2.
3. extern "C" {
4. // Get declaration for f(int i, char c, float x)
5. #include "my-C-code.h"
6. }
7.
8. int main()
9. {
10. f(7, 'x', 3.14); // Note: nothing unusual in the call
11. // ...
12. }
Note: Somewhat different guidelines apply for C headers provided by the system (such
as <cstdio>) and for C headers that you can change.
How can I modify my own C header files so it’s easier
to #include them in C++ code?
If you are including a C header file that isn’t provided by the system, and if you are able to change
the C header, you should strongly consider adding the extern "C" {...} logic inside the header
to make it easier for C++ users to #include it into their C++ code. Since a C compiler won’t
understand the extern "C" construct, you must wrap the extern "C" { and } lines in
an #ifdef so they won’t be seen by normal C compilers.
Step #1: Put the following lines at the very top of your C header file (note: the
symbol __cplusplus is #defined if/only-if the compiler is a C++ compiler):
1. #ifdef __cplusplus
2. extern "C" {
3. #endif
Step #2: Put the following lines at the very bottom of your C header file:
1. #ifdef __cplusplus
2. }
3. #endif
Now you can #include your C header without any extern "C" nonsense in your C++ code:
1. // This is C++ code
2.
3. // Get declaration for f(int i, char c, float x)
4. #include "my-C-code.h" // Note: nothing unusual in #include line
5.
6. int main()
7. {
8. f(7, 'x', 3.14); // Note: nothing unusual in the call
9. // ...
10. }
Note: Somewhat different guidelines apply for C headers provided by the system (such
as <cstdio>) and for C headers that you can’t change.
Note: #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. But they’re
still useful sometimes. Just wash your hands after using them.
How can I call a non-system C
function f(int,char,float) from my C++ code?
If you have an individual C function that you want to call, and for some reason you don’t have or
don’t want to #include a C header file in which that function is declared, you can declare the
individual C function in your C++ code using the extern "C" syntax. Naturally you need to use
the full function prototype:
1. extern "C" void f(int i, char c, float x);
A block of several C functions can be grouped via braces:
1. extern "C" {
2. void f(int i, char c, float x);
3. int g(char* s, const char* s2);
4. double sqrtOfSumOfSquares(double a, double b);
5. }
After this you simply call the function just as if it were a C++ function:
1. int main()
2. {
3. f(7, 'x', 3.14); // Note: nothing unusual in the call
4. // ...
5. }

How can I create a C++ function f(int,char,float) that is

callable by my C code?
The C++ compiler must know that f(int,char,float) is to be called by a C compiler using
the extern "C" construct:
1. // This is C++ code
2.
3. // Declare f(int,char,float) using extern "C":
4. extern "C" void f(int i, char c, float x);
5.
6. // ...
7.
8. // Define f(int,char,float) in some C++ module:
9. void f(int i, char c, float x)
10. {
11. // ...
12. }
The extern "C" line tells the compiler that the external information sent to the linker should use
C calling conventions and name mangling (e.g., preceded by a single underscore). Since name
overloading isn’t supported by C, you can’t make several overloaded functions simultaneously
callable by a C program.
Why is the linker giving errors for C/C++ functions being
called from C++/C functions?
If you didn’t get your extern "C" right, you’ll sometimes get linker errors rather than compiler
errors. This is due to the fact that C++ compilers usually “mangle” function names (e.g., to support
function overloading) differently than C compilers.
See the previous two FAQs on how to use extern "C".
How can I pass an object of a C++ class to/from a C
function?
Here’s an example (for info on extern "C", see the previous two FAQs).
Fred.h:
1. /* This header can be read by both C and C++ compilers */
2. #ifndef FRED_H
3. #define FRED_H
4.
5. #ifdef __cplusplus
6. class Fred {
7. public:
8. Fred();
9. void wilma(int);
10. private:
11. int a_;
12. };
13. #else
14. typedef
15. struct Fred
16. Fred;
17. #endif
18.
19. #ifdef __cplusplus
20. extern "C" {
21. #endif
22.
23. #if defined(__STDC__) || defined(__cplusplus)
24. extern void c_function(Fred*); /* ANSI C prototypes */
25. extern Fred* cplusplus_callback_function(Fred*);
26. #else
27. extern void c_function(); /* K&R style */
28. extern Fred* cplusplus_callback_function();
29. #endif
30.
31. #ifdef __cplusplus
32. }
33. #endif
34.
35. #endif /*FRED_H*/
Fred.cpp:
1. // This is C++ code
2.
3. #include "Fred.h"
4.
5. Fred::Fred() : a_(0) { }
6.
7. void Fred::wilma(int a) { }
8.
9. Fred* cplusplus_callback_function(Fred* fred)
10. {
11. fred->wilma(123);
12. return fred;
13. }
main.cpp:
1. // This is C++ code
2.
3. #include "Fred.h"
4.
5. int main()
6. {
7. Fred fred;
8. c_function(&fred);
9. // ...
10. }
c-function.c:
1. /* This is C code */
2.
3. #include "Fred.h"
4.
5. void c_function(Fred* fred)
6. {
7. cplusplus_callback_function(fred);
8. }
Unlike your C++ code, your C code will not be able to tell that two pointers point at the same object
unless the pointers are exactly the same type. For example, in C++ it is easy to check if
a Derived* called dp points to the same object as is pointed to by a Base* called bp: just say if
(dp == bp) .... The C++ compiler automatically converts both pointers to the same type, in this
case to Base*, then compares them. Depending on the C++ compiler’s implementation details, this
conversion sometimes changes the bits of a pointer’s value.
(Technical aside: Most C++ compilers use a binary object layout that causes this conversion to
happen with multiple inheritance and/or virtual inheritance. However the C++ language does not
impose that object layout so in principle a conversion could also happen even with non-virtual
single inheritance.)
The point is simple: your C compiler will not know how to do that pointer conversion, so the
conversion from Derived* to Base*, for example, must take place in code compiled with a C++
compiler, not in code compiled with a C compiler.
NOTE: you must be especially careful when converting both to void* since that conversion will
not allow either the C or C++ compiler to do the proper pointer adjustments! The comparison (x
== y) might be false even if (b == d) is true:
1. void f(Base* b, Derived* d)
2. {
3. if (b == d) { ☺ Validly compares a Base* to a Derived*
4. // ...
5. }
6.
7. void* x = b;
8. void* y = d;
9. if (x == y) { ☹ BAD FORM! DO NOT DO THIS!
10. // ...
11. }
12. }
As stated above, the above pointer conversions will typically happen with multiple and/or virtual
inheritance, but please do not look at that as an exhaustive list of the only times when the pointer
conversions will happen.
You have been warned.
If you really want to use void* pointers, here is the safe way to do it:
1. void f(Base* b, Derived* d)
2. {
3. void* x = b;
4. void* y = static_cast<Base*>(d); // If conversion is needed, it will happen in the static_cast<>
5. if (x == y) { // ☺ Validly compares a Base* to a Derived*
6. // ...
7. }
8. }

Can my C function directly access data in an object of a

C++ class?
Sometimes.
(For basic info on passing C++ objects to/from C functions, read the previous FAQ).
You can safely access a C++ object’s data from a C function if the C++ class:
 Has no virtual functions (including inherited virtual functions)
 Has all its data in the same access-level section (private/protected/public)
 Has no fully-contained subobjects with virtual functions
If the C++ class has any base classes at all (or if any fully contained subobjects have base classes),
accessing the data will technically be non-portable, since class layout under inheritance isn’t
imposed by the language. However in practice, all C++ compilers do it the same way: the base class
object appears first (in left-to-right order in the event of multiple inheritance), and member objects
follow.
Furthermore, if the class (or any base class) contains any virtual functions, almost all C++
compilers put a void* into the object either at the location of the first virtual function or at the
very beginning of the object. Again, this is not required by the language, but it is the way
“everyone” does it.
If the class has any virtual base classes, it is even more complicated and less portable. One
common implementation technique is for objects to contain an object of the virtual base class (V)
last (regardless of where V shows up as a virtual base class in the inheritance hierarchy). The rest
of the object’s parts appear in the normal order. Every derived class that has V as a virtual base
class actually has a pointer to the V part of the final object.
Why do I feel like I’m “further from the machine” in C++ as
opposed to C?
 Because you are.
As an OO programming language, C++ allows you to model the problem domain itself, which
allows you to program in the language of the problem domain rather than in the language of the
solution domain.
One of C’s great strengths is the fact that it has “no hidden mechanism”: what you see is what you
get. You can read a C program and “see” every clock cycle. This is not the case in C++; old line C
programmers (such as many of us once were) are often ambivalent (can you say, “hostile”?) about
this feature. However after they’ve made the transition to OO thinking, they often realize that
although C++ hides some mechanism from the programmer, it also provides a level of abstraction
and economy of expression which lowers maintenance costs without destroying run-time
performance.
Naturally you can write bad code in any language; C++ doesn’t guarantee any particular level of
quality, reusability, abstraction, or any other measure of “goodness.”
C++ doesn’t try to make it impossible for bad programmers to write bad programs; it enables
reasonable developers to create superior software.

Built-in / Intrinsic / Primitive Data Types

Save to:
InstapaperPocketReadability
Contents of this section:

 Can sizeof(char) be 2 on some machines? For example, what about double-byte

characters?
 What are the units of sizeof?
 Whoa, but what about machines or compilers that support multibyte characters. Are you
saying that a “character” and a char might be different?!?
 But, but, but what about machines where a char has more than 8 bits? Surely you’re not
saying a C++ byte might have more than 8 bits, are you?!?
 Okay, I could imagine a machine with 9-bit bytes. But surely not 16-bit bytes or 32-bit bytes,
right?
 I’m sooooo confused. Would you please go over the rules about bytes, chars, and characters
one more time?
 What is a “POD type”?
 When initializing non-static data members of built-in / intrinsic / primitive types, should I use
the “initialization list” or assignment?
 When initializing static data members of built-in / intrinsic / primitive types, should I worry
about the “static initialization order fiasco”?
 Can I define an operator overload that works with built-in / intrinsic / primitive types?
 When I delete an array of some built-in / intrinsic / primitive type, why can’t I just
say delete a instead of delete[] a?
 How can I tell if an integer is a power of two without looping?
 What should be returned from a function?
Can sizeof(char) be 2 on some machines? For example,
what about double-byte characters?
No, sizeof(char) is always 1. Always. It is never 2. Never, never, never.
 Even if you think of a “character” as a multi-byte thingy, char is not. sizeof(char) is always
exactly 1. No exceptions, ever.
Look, I know this is going to hurt your head, so please, please just read the next few FAQs in
sequence and hopefully the pain will go away by sometime next week.
What are the units of sizeof?
Bytes.
For example, if sizeof(Fred) is 8, the distance between two Fred objects in an array of Freds
will be exactly 8 bytes.
As another example, this means sizeof(char) is one byte. That’s right: one byte. One, one, one,
exactly one byte, always one byte. Never two bytes. No exceptions.
Whoa, but what about machines or compilers that support
multibyte characters. Are you saying that a “character”
and a char might be different?!?
Yes that’s right: the thing commonly referred to as a “character” might be different from the thing
C++ calls a char.
I’m really sorry if that hurts, but believe me, it’s better to get all the pain over with at once. Take a
deep breath and repeat after me: “character and char might be different.” There, doesn’t that feel
better? No? Well keep reading — it gets worse.
But, but, but what about machines where a char has
more than 8 bits? Surely you’re not saying a C++ byte
might have more than 8 bits, are you?!?
Yep, that’s right: a C++ byte might have more than 8 bits.
The C++ language guarantees a byte must always have at least 8 bits. But there are implementations
of C++ that have more than 8 bits per byte.
Okay, I could imagine a machine with 9-bit bytes. But
surely not 16-bit bytes or 32-bit bytes, right?
Wrong.
I have heard of one implementation of C++ that has 64-bit “bytes.” You read that right: a byte on
that implementation has 64 bits. 64 bits per byte. 64. As in 8 times 8.
And yes, you’re right, combining with the above would mean that a char on that implementation
would have 64 bits.
I’m sooooo confused. Would you please go over the rules
about bytes, chars, and characters one more time?
Here are the rules:
 The C++ language gives the programmer the impression that memory is laid out as a
sequence of something C++ calls “bytes.”
 Each of these things that the C++ language calls a byte has at least 8 bits, but might have
more than 8 bits.
 The C++ language guarantees that a char* (char pointers) can address individual bytes.
 The C++ language guarantees there are no bits between two bytes. This means every bit in
memory is part of a byte. If you grind your way through memory via a char*, you will be able to
see every bit.
 The C++ language guarantees there are no bits that are part of two distinct bytes. This means
a change to one byte will never cause a change to a different byte.
 The C++ language gives you a way to find out how many bits are in a byte in your particular
implementation: include the header <climits>, then the actual number of bits per byte will be
given by the CHAR_BIT macro.
Let’s work an example to illustrate these rules. The PDP-10 has 36-bit words with no hardware
facility to address anything within one of those words. That means a pointer can point only at things
on a 36-bit boundary: it is not possible for a pointer to point 8 bits to the right of where some other
pointer points.
One way to abide by all the above rules is for a PDP-10 C++ compiler to define a “byte” as 36 bits.
Another valid approach would be to define a “byte” as 9 bits, and simulate a char* by two words
of memory: the first could point to the 36-bit word, the second could be a bit-offset within that
word. In that case, the C++ compiler would need to add extra instructions when compiling code
using char* pointers. For example, the code generated for *p = 'x' might read the word into a
register, then use bit-masks and bit-shifts to change the appropriate 9-bit byte within that word.
An int* could still be implemented as a single hardware pointer, since C++
allows sizeof(char*) != sizeof(int*).
Using the same logic, it would also be possible to define a PDP-10 C++ “byte” as 12-bits or 18-bits.
However the above technique wouldn’t allow us to define a PDP-10 C++ “byte” as 8-bits, since 8×4
is 32, meaning every 4th byte we would skip 4 bits. A more complicated approach could be used for
those 4 bits, e.g., by packing nine bytes (of 8-bits each) into two adjacent 36-bit words. The
important point here is that memcpy() has to be able to see every bit of memory: there can’t be any
bits between two adjacent bytes.
Note: one of the popular non-C/C++ approaches on the PDP-10 was to pack 5 bytes (of 7-bits each)
into each 36-bit word. However this won’t work in C or C++ since 5×7 is 35, meaning
using char*s to walk through memory would “skip” a bit every fifth byte (and also because C++
requires bytes to have at least 8 bits).
What is a “POD type”?
A type that consists of nothing but Plain Old Data.
A POD type is a C++ type that has an equivalent in C, and that uses the same rules as C uses for
initialization, copying, layout, and addressing.
As an example, the C declaration struct Fred x; does not initialize the members of
the Fred variable x. To make this same behavior happen in C++, Fred would need to not have any
constructors. Similarly to make the C++ version of copying the same as the C version, the C+
+ Fred must not have overloaded the assignment operator. To make sure the other rules match, the
C++ version must not have virtual functions, base classes, non-static members that
are private or protected, or a destructor. It can, however, have static data members, static
member functions, and non-static non-virtual member functions.
The actual definition of a POD type is recursive and gets a little gnarly. Here’s a slightly simplified
definition of POD: a POD type’s non-static data members must be public and can be of any of
these types: bool, any numeric type including the various char variants, any enumeration type, any
data-pointer type (that is, any type convertible to void*), any pointer-to-function type, or any POD
type, including arrays of any of these. Note: data-pointers and pointers-to-function are okay,
but pointers-to-member are not. Also note that references are not allowed. In addition, a POD type
can’t have constructors, virtual functions, base classes, or an overloaded assignment operator.
 When initializing non-static data members of built-in /
intrinsic / primitive types, should I use the “initialization
list” or assignment?
For symmetry, it is usually best to initialize all non-static data members in the constructor’s
“initialization list,” even those that are of a built-in / intrinsic / primitive type. The FAQ shows you
why and how.
When initializing static data members of built-in /
intrinsic / primitive types, should I worry about the
“static initialization order fiasco”?
Yes, if you initialize your built-in / intrinsic / primitive variable by an expression that the compiler
doesn’t evaluate solely at compile-time. The FAQ provides several solutions for this (subtle!)
problem.
Can I define an operator overload that works with built-in /
intrinsic / primitive types?
No, the C++ language requires that your operator overloads take at least one operand of a “class
type” or enumeration type. The C++ language will not let you define an operator all of whose
operands / parameters are of primitive types.
For example, you can’t define an operator== that takes two char*s and uses string comparison.
That’s good news because if s1 and s2 are of type char*, the expression s1 == s2 already has a
well defined meaning: it compares the two pointers, not the two strings pointed to by those
pointers. You shouldn’t use pointers anyway. Use std::string instead of char*.
If C++ let you redefine the meaning of operators on built-in types, you wouldn’t ever know what 1
+ 1 is: it would depend on which headers got included and whether one of those headers redefined
addition to mean, for example, subtraction.
When I delete an array of some built-in / intrinsic /
primitive type, why can’t I just say delete a instead
of delete[] a?
Because you can’t.
Look, please don’t write me an email asking me why C++ is what it is. It just is. If you really want a
rationale, buy Bjarne Stroustrup’s excellent book, “Design and Evolution of C++” (Addison-Wesley
publishers). But if your real goal is to write some code, don’t waste too much time figuring
out why C++ has these rules, and instead just abide by its rules.
So here’s the rule: if a points to an array of thingies that was allocated via new T[n], then you
must, must, must delete it via delete[] a. Even if the elements in the array are built-in types.
Even if they’re of type char or int or void*. Even if you don’t understand why.
How can I tell if an integer is a power of two without
looping?
1. inline bool isPowerOf2(int i)
2. {
3. return i > 0 && (i & (i - 1)) == 0;
4. }
What should be returned from a function?
In practice, there are a lot of cases. Here are a few of them in random order:
 void — if you don’t need a return value, don’t return one.
 local by value — it’s the simplest, and with a little care NRVO maximizes performance.
 local by pointer or reference — NOT!. Please don’t do this.
 data member by value — excellent choice if the function is a non-static member function,
and if the data member can be copied relatively quickly, e.g., int. If the data member is
something that is slow to copy, this has a performance penalty if you call this member function in
the inner loop of a CPU-bound application.
 data member by pointer — okay, but make sure you don’t want to return it by reference, and
make sure you use const Foo* or Foo const* if you don’t want the caller to modify the data
member. Since callers might store the pointer rather than copy the data member, you should warn
callers in the member function’s “contract” that they must not use the returned pointer after
the this-object dies.
 data member by reference-to-nonconst — okay, but this allows the caller to make changes to
your object’s data member without your class “seeing” the change. If you have a “set” method
that changes this data member, use either a reference-to-const or by-value instead. Another thing:
since callers might store the reference rather than copy the data member, you should warn callers
in the member function’s “contract” that they must not use the returned reference after the this-
object dies.
 data member by reference-to-const — okay, but it does allow your users to see the data type
of your member variables. That means if you ever need to change the type of your member
variables, the change might break the code that uses your class, and that’s one of the main points
of encapsulation. You can ameliorate that risk by exposing a public typedef for the type of
that member variable (and therefore the type of the reference-to-const return value), and by
warning your users that they should use the typedef rather than the raw, underlying type.
Another reality is that if the caller captures this reference, as opposed to copying the object, then
the underlying referent might change “under the caller’s nose,” even though the type is reference-
to-const. Because a lot of programmers are surprised by that, it’s smart to warn callers in the
member function’s “contract.” You should also warn callers to discard the returned reference once
the this-object has died.
 shared_ptr to a member that was allocated via new — this has tradeoffs that are very
similar to those of returning a member by pointer or by reference; see those bullets for the
tradeoffs. The advantage is that callers can legitimately hold onto and use the returned pointer
after the this-object dies.
 local unique_ptr or shared_ptr to freestore-allocated copy of the datum. This is useful
for polymorphic objects, since it lets you have the effect of return-by-value yet without the
“slicing” problem. The performance needs to be evaluated on a case-by-case basis.
 others — this list is by way of example and not by way of exclusion. In other words, this is
just a starting point, not an ending point.
Murphy’s Law basically guarantees that your particular needs will fall under the last bullet, rather
than any of the earlier bullets .

Input/output via <iostream> and <cstdio>

Save to:
InstapaperPocketReadability
Contents of this section:
 Why should I use <iostream> instead of the traditional <cstdio>?
 Why does my program go into an infinite loop when someone enters an invalid input
character?
 How can I get std::cin to skip invalid input characters?
 How does that funky while (std::cin >> foo) syntax work?
 Why does my input seem to process past the end of file?
 Why is my program ignoring my input request after the first iteration?
 Should I end my output lines with std::endl or '\n'?
 How can I provide printing for my class Fred?
 But shouldn’t I always use a printOn() method rather than a friend function?
 How can I provide input for my class Fred?
 How can I provide printing for an entire hierarchy of classes?
 How can I open a stream in binary mode?
 How can I “reopen” std::cin and std::cout in binary mode?
 How can I write/read objects of my class to/from a data file?
 How can I send objects of my class to another computer (e.g., via a socket, TCP/IP, FTP,
email, a wireless link, etc.)?
 Why can’t I open a file in a different directory such as "..\test.dat"?
 How can I tell (if a key, which key) was pressed before the user presses the ENTER key?
 How can I make it so keys pressed by users are not echoed on the screen?
 How can I move the cursor around on the screen?
 How can I clear the screen? Is there something like clrscr()?
 How can I change the colors on the screen?
 How can I print a char as a number? How can I print a char* so the output shows the
pointer’s numeric value?
Why should I use <iostream> instead of the
traditional <cstdio>?
Increase type safety, reduce errors, allow extensibility, and provide inheritability.
printf() is arguably not broken, and scanf() is perhaps livable despite being error prone,
however both are limited with respect to what C++ I/O can do. C++ I/O (using << and >>) is,
relative to C (using printf() and scanf()):
 More type-safe: With <iostream>, the type of object being I/O’d is known statically by the
compiler. In contrast, <cstdio> uses "%" fields to figure out the types dynamically.
 Less error prone: With <iostream>, there are no redundant "%" tokens that have to be
consistent with the actual objects being I/O’d. Removing redundancy removes a class of errors.
 Extensible: The C++ <iostream> mechanism allows new user-defined types to be I/O’d
without breaking existing code. Imagine the chaos if everyone was simultaneously adding new
incompatible "%" fields to printf() and scanf()?!
 Inheritable: The C++ <iostream> mechanism is built from real classes such
as std::ostream and std::istream. Unlike <cstdio>’s FILE*, these are real classes and
hence inheritable. This means you can have other user-defined things that look and act like
streams, yet that do whatever strange and wonderful things you want. You automatically get to
use the zillions of lines of I/O code written by users you don’t even know, and they don’t need to
know about your “extended stream” class.
Why does my program go into an infinite loop when
someone enters an invalid input character?
For example, suppose you have the following code that reads integers from std::cin:
1. #include <iostream>
2.
3. int main()
4. {
5. std::cout << "Enter numbers separated by whitespace (use -1 to quit): ";
6. int i = 0;
7. while (i != -1) {
8. std::cin >> i; // BAD FORM — See comments below
9. std::cout << "You entered " << i << '\n';
10. }
11. // ...
12. }
The problem with this code is that it lacks any checking to see if someone entered an invalid input
character. In particular, if someone enters something that doesn’t look like an integer (such as an
‘x’), the stream std::cin goes into a “failed state,” and all subsequent input attempts return
immediately without doing anything. In other words, the program enters an infinite loop; if 42 was
the last number that was successfully read, the program will print the message You entered
42 over and over.
An easy way to check for invalid input is to move the input request from the body of
the while loop into the control-expression of the while loop. E.g.,
1. #include <iostream>
2.
3. int main()
4. {
5. std::cout << "Enter a number, or -1 to quit: ";
6. int i = 0;
7. while (std::cin >> i) { // GOOD FORM
8. if (i == -1) break;
9. std::cout << "You entered " << i << '\n';
10. }
11. // ...
12. }
This will cause the while loop to exit either when you hit end-of-file, or when you enter a bad
integer, or when you enter -1.
(Naturally you can eliminate the break by changing the while loop expression from while
(std::cin >> i) to while ((std::cin >> i) && (i != -1)), but that’s not really the
point of this FAQ since this FAQ has to do with iostreams rather than generic structured
programming guidelines.)
How can I get std::cin to skip invalid input
characters?
Use std::cin.clear() and std::cin.ignore().
1. #include <iostream>
2. #include <limits>
3.
4. int main()
5. {
6. int age = 0;
7.
8. while ((std::cout << "How old are you? ")
9. && !(std::cin >> age)) {
10. std::cout << "That's not a number; ";
11. std::cin.clear();
12. std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
13. }
14.
15. std::cout << "You are " << age << " years old\n";
16. // ...
17. }
Of course you can also print the error message when the input is out of range. For example, if you
wanted the age to be between 1 and 200, you could change the while loop to:
1. // ...
2. while ((std::cout << "How old are you? ")
3. && (!(std::cin >> age) || age < 1 || age > 200)) {
4. std::cout << "That's not a number between 1 and 200; ";
5. std::cin.clear();
6. std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
7. }
8. // ...
Here’s a sample run:
1. How old are you? foo
2. That's not a number between 1 and 200; How old are you? bar
3. That's not a number between 1 and 200; How old are you? -3
4. That's not a number between 1 and 200; How old are you? 0
5. That's not a number between 1 and 200; How old are you? 201
6. That's not a number between 1 and 200; How old are you? 2
7. You are 2 years old

How does that funky while (std::cin >> foo) syntax

work?
See the previous FAQ for an example of the “funky while (std::cin >> foo) syntax.”
The expression (std::cin >> foo) calls the appropriate operator>> (for example, it calls
the operator>> that takes an std::istream on the left and, if foo is of type int, an int& on
the right). The std::istream operator>> functions return their left argument by convention,
which in this case means it will return std::cin. Next the compiler notices that the
returned std::istream is in a boolean context, so it converts that std::istream into a boolean.
To convert an std::istream into a boolean, the compiler calls a member function
called std::istream::operator void*(). This returns a void* pointer, which is in turn
converted to a boolean (NULL becomes false, any other pointer becomes true). So in this case the
compiler generates a call to std::cin.operator void*(), just as if you had casted it explicitly
such as (void*) std::cin.
The operator void*() cast operator returns some non-NULL pointer if the stream is in a good
state, or NULL if it’s in a failed state. For example, if you read one too many times (e.g., if you’re
already at end-of-file), or if the actual info on the input stream isn’t valid for the type of foo (e.g.,
if foo is an int and the data is an ‘x’ character), the stream will go into a failed state and the cast
operator will return NULL.
The reason operator>> doesn’t simply return a bool (or void*) indicating whether it succeeded
or failed is to support the “cascading” syntax:
1. std::cin >> foo >> bar;
The operator>> is left-associative, which means the above is parsed as:
1. (std::cin >> foo) >> bar;
In other words, if we replace operator>> with a normal function name such as readFrom(), this
becomes the expression:
1. readFrom( readFrom(std::cin, foo), bar);
As always, we begin evaluating at the innermost expression. Because of the left-associativity
of operator>>, this happens to be the left-most expression, std::cin >> foo. This expression
 returns std::cin (more precisely, it returns a reference to its left-hand argument) to the next
expression. The next expression also returns (a reference to) std::cin, but this second reference is
ignored since it’s the outermost expression in this “expression statement.”
Why does my input seem to process past the end of
file?
Because the eof state may not get set until after a read is attempted past the end of file. That is,
reading the last byte from a file might not set the eof state. E.g., suppose the input stream is mapped
to a keyboard — in that case it’s not even theoretically possible for the C++ library to predict
whether or not the character that the user just typed will be the last character.
For example, the following code might have an off-by-one error with the count i:
1. int i = 0;
2. while (! std::cin.eof()) { // WRONG! (not reliable)
3. std::cin >> x;
4. ++i;
5. // Work with x ...
6. }
What you really need is:
1. int i = 0;
2. while (std::cin >> x) { // RIGHT! (reliable)
3. ++i;
4. // Work with x ...
5. }

Why is my program ignoring my input request after the

first iteration?
Because the numerical extractor leaves non-digits behind in the input buffer.
If your code looks like this:
1. char name[1000];
2. int age;
3.
4. for (;;) {
5. std::cout << "Name: ";
6. std::cin >> name;
7. std::cout << "Age: ";
8. std::cin >> age;
9. }
What you really want is:
1. for (;;) {
2. std::cout << "Name: ";
3. std::cin >> name;
4. std::cout << "Age: ";
5. std::cin >> age;
6. std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
7. }
Of course you might want to change the for (;;) statement to while (std::cin), but don’t
confuse that with skipping the non-numeric characters at the end of the loop via the
line: std::cin.ignore(...);.
Should I end my output lines with std::endl or '\n'?
 Using std::endl flushes the output buffer after sending a '\n', which means std::endl is
more expensive in performance. Obviously if you need to flush the buffer after sending a '\n',
then use std::endl; but if you don’t need to flush the buffer, the code will run faster if you use '\
n'.
This code simply outputs a '\n':
1. void f()
2. {
3. std::cout << /*...stuff...*/ << '\n';
4. }
This code outputs a '\n', then flushes the output buffer:
1. void g()
2. {
3. std::cout << /*...stuff...*/ << std::endl;
4. }
This code simply flushes the output buffer:
1. void h()
2. {
3. std::cout << /*...stuff...*/ << std::flush;
4. }
Note: all three of the above examples require #include <iostream>
How can I provide printing for my class Fred?
Use operator overloading to provide a friend left-shift operator, operator<<.
1. #include <iostream>
2.
3. class Fred {
4. public:
5. friend std::ostream& operator<< (std::ostream& o, const Fred& fred);
6. // ...
7. private:
8. int i_; // Just for illustration
9. };
10.
11. std::ostream& operator<< (std::ostream& o, const Fred& fred)
12. {
13. return o << fred.i_;
14. }
15.
16. int main()
17. {
18. Fred f;
19. std::cout << "My Fred object: " << f << "\n";
20. // ...
21. }
We use a non-member function (a friend in this case) since the Fred object is the right-hand
operand of the << operator. If the Fred object was supposed to be on the left hand side of
the << (that is, myFred << std::cout rather than std::cout << myFred), we could have
used a member function named operator<<.
Note that operator<< returns the stream. This is so the output operations can be cascaded.
But shouldn’t I always use a printOn() method rather
than a friend function?
No.
 The usual reason people want to always use a printOn() method rather than a friend function is
because they wrongly believe that friends violate encapsulation and/or that friends are evil. These
beliefs are naive and wrong: when used properly, friends can actually enhance encapsulation.
This is not to say that the printOn() method approach is never useful. For example, it is useful
when providing printing for an entire hierarchy of classes. But if you use a printOn() method, it
should normally be protected, not public.
For completeness, here is “the printOn() method approach.” The idea is to have a member
function, often called printOn(), that does the actual printing, then have operator<< call
that printOn() method. When it is done wrongly, the printOn() method
is public so operator<< doesn’t have to be a friend — it can be a simple top-level function
that is neither a friend nor a member of the class. Here’s some sample code:
1. #include <iostream>
2.
3. class Fred {
4. public:
5. void printOn(std::ostream& o) const;
6. // ...
7. };
8.
9. // operator<< can be declared as a non-friend [NOT recommended!]
10. std::ostream& operator<< (std::ostream& o, const Fred& fred);
11.
12. // The actual printing is done inside the printOn() method [NOT recommended!]
13. void Fred::printOn(std::ostream& o) const
14. {
15. // ...
16. }
17.
18. // operator<< calls printOn() [NOT recommended!]
19. std::ostream& operator<< (std::ostream& o, const Fred& fred)
20. {
21. fred.printOn(o);
22. return o;
23. }
People wrongly assume that this reduces maintenance cost “since it avoids having a friend
function.” This is a wrong assumption because:
1. The member-called-by-top-level-function approach has zero benefit in terms of
maintenance cost. Let’s say it takes N lines of code to do the actual printing. In the case of
a friend function, those N lines of code will have direct access to the
class’s private/protected parts, which means whenever someone changes the
class’s private/protected parts, those N lines of code will need to be scanned and possibly
modified, which increases the maintenance cost. However using the printOn() method doesn’t
change this at all: we still have N lines of code that have direct access to the
class’s private/protected parts. Thus moving the code from a friend function into a
member function does not reduce the maintenance cost at all. Zero reduction. No benefit in
maintenance cost. (If anything it’s a bit worse with the printOn() method since you now
have more lines of code to maintain since you have an extra function that you didn’t have before.)
2. The member-called-by-top-level-function approach makes the class harder to use,
particularly by programmers who are not also class designers. The approach exposes
a public method that programmers are not supposed to call. When a programmer reads
the public methods of the class, they’ll see two ways to do the same thing. The documentation
would need to say something like, “This does exactly the same as that, but don’t use this; instead
 use that.” And the average programmer will say, “Huh? Why make the method public if I’m not
supposed to use it?” In reality the only reason the printOn() method is public is to avoid
granting friendship status to operator<<, and that is a notion that is somewhere between subtle
and incomprehensible to a programmer who simply wants to use the class.
Net: the member-called-by-top-level-function approach has a cost but no benefit. Therefore it is, in
general, a bad idea.
Note: if the printOn() method is protected or private, the second objection doesn’t apply.
There are cases when that approach is reasonable, such as when providing printing for an entire
hierarchy of classes. Note also that when the printOn() method is non-
public, operator<< needs to be a friend.
How can I provide input for my class Fred?
Use operator overloading to provide a friend right-shift operator, operator>>. This is similar
to the output operator, except the parameter doesn’t have a const: “Fred&” rather than “const
Fred&”.
1. #include <iostream>
2.
3. class Fred {
4. public:
5. friend std::istream& operator>> (std::istream& i, Fred& fred);
6. // ...
7. private:
8. int i_; // Just for illustration
9. };
10.
11. std::istream& operator>> (std::istream& i, Fred& fred)
12. {
13. return i >> fred.i_;
14. }
15.
16. int main()
17. {
18. Fred f;
19. std::cout << "Enter a Fred object: ";
20. std::cin >> f;
21. // ...
22. }
Note that operator>> returns the stream. This is so the input operations can be cascaded and/or
used in a while loop or if statement.
How can I provide printing for an entire hierarchy of
classes?
Provide a friend operator<< that calls a protected virtual function:
1. class Base {
2. public:
3. friend std::ostream& operator<< (std::ostream& o, const Base& b);
4. // ...
5. protected:
6. virtual void printOn(std::ostream& o) const = 0; // Or plain virtual; see below
7. };
8.
9. inline std::ostream& operator<< (std::ostream& o, const Base& b)
10. {
11. b.printOn(o);
12. return o;
13. }
14.
15. class Derived : public Base {
16. public:
17. // ...
18. protected:
19. virtual void printOn(std::ostream& o) const;
20. };
21.
22. void Derived::printOn(std::ostream& o) const
23. {
24. // ...
25. }
The end result is that operator<< acts as if it were dynamically bound, even though it’s
a friend function. This is called the Virtual Friend Function Idiom.
Note that derived classes override printOn(std::ostream&) const. In particular, they
do not provide their own operator<<.
As to whether Base::printOn() is plain virtual or pure virtual, consider making it a plain virtual
(without the “= 0”) if you can implement that function with code that would otherwise be repeated
in two or more derived classes. However if Base is a ABC with little or no member data, you might
not be able to provide a meaningful definition for Base::printOn() and you should make it pure
virtual. If you’re not sure, make it pure virtual, at least until you get a better handle on the derived
classes.
How can I open a stream in binary mode?
Use std::ios::binary.
Some operating systems differentiate between text and binary modes. In text mode, end-of-line
sequences and possibly other things are translated; in binary mode, they are not. For example, in
text mode under Windows, "\r\n" is translated into "\n" on input, and the reverse on output.
To read a file in binary mode, use something like this:
1. #include <string>
2. #include <iostream>
3. #include <fstream>
4.
5. void readBinaryFile(const std::string& filename)
6. {
7. std::ifstream input(filename.c_str(), std::ios::in | std::ios::binary);
8. char c;
9. while (input.get(c)) {
10. // ...do something with c here...
11. }
12. }
Note: input >> c discards leading whitespace, so you won’t normally use that when reading
binary files.
How can I “reopen” std::cin and std::cout in binary
mode?
This is implementation dependent. Check with your compiler’s documentation.
For example, suppose you want to do binary I/O using std::cin and std::cout.
 Unfortunately there is no standard way to cause std::cin, std::cout, and/or std::cerr to be
opened in binary mode. Closing the streams and attempting to reopen them in binary mode might
have unexpected or undesirable results.
On systems where it makes a difference, the implementation might provide a way to make them
binary streams, but you would have to check the implementation specifics to find out.
How can I write/read objects of my class to/from a data
file?
Read the section on object serialization.
How can I send objects of my class to another computer
(e.g., via a socket, TCP/IP, FTP, email, a wireless link,
etc.)?
Read the section on object serialization.
Why can’t I open a file in a different directory such
as "..\test.dat"?
Because "\t" is a tab character.
You should use forward slashes in your filenames, even on operating systems that use backslashes
(DOS, Windows, OS/2, etc.). For example:
1. #include <iostream>
2. #include <fstream>
3.
4. int main()
5. {
6. #if 1
7. std::ifstream file("../test.dat"); // RIGHT!
8. #else
9. std::ifstream file("..\test.dat"); // WRONG!
10. #endif
11.
12. // ...
13. }
Remember, the backslash ("\") is used in string literals to create special characters: "\n" is a
newline, "\b" is a backspace, and "\t" is a tab, "\a" is an “alert”, "\v" is a vertical-tab, etc.
Therefore the file name "\version\next\alpha\beta\test.dat" is interpreted as a bunch of
very funny characters. To be safe, use "/version/next/alpha/beta/test.dat" instead, even
on systems that use a "\" as the directory separator. This is because the library routines on these
operating systems handle "/" and "\" interchangeably.
Of course you could use "\\version\\next\\alpha\\beta\\test.dat", but that might hurt
you (there’s a non-zero chance you’ll forget one of the "\"s, a rather subtle bug since most people
don’t notice it) and it can’t help you (there’s no benefit for using "\\" over "/"). Besides "/" is
more portable since it works on all flavors of Unix, Plan 9, Inferno, all Windows, OS/2, etc.,
but "\\" works only on a subset of that list. So "\\" costs you something and gains you nothing:
use "/" instead.
How can I tell (if a key, which key) was pressed before the
user presses the ENTER key?
 This is not a standard C++ feature — C++ doesn’t even require your system to have a keyboard!.
That means every operating system and vendor does it somewhat differently.
Please read the documentation that came with your compiler for details on your particular
installation.
(By the way, the process on UNIX typically has two steps: first set the terminal to single-character
mode, then use either select() or poll() to test if a key was pressed. You might be able to
adapt this code.)
How can I make it so keys pressed by users are not
echoed on the screen?
This is not a standard C++ feature — C++ doesn’t even require your system to have a keyboard or a
screen. That means every operating system and vendor does it somewhat differently.
Please read the documentation that came with your compiler for details on your particular
installation.

How can I move the cursor around on the screen?

This is not a standard C++ feature — C++ doesn’t even require your system to have a screen. That
means every operating system and vendor does it somewhat differently.
Please read the documentation that came with your compiler for details on your particular
installation.

How can I clear the screen? Is there something

like clrscr()?
This is not a standard C++ feature — C++ doesn’t even require your system to have a screen. That
means every operating system and vendor does it somewhat differently.
Please read the documentation that came with your compiler for details on your particular
installation.

How can I change the colors on the screen?

This is not a standard C++ feature — C++ doesn’t even require your system to have a screen. That
means every operating system and vendor does it somewhat differently.
Please read the documentation that came with your compiler for details on your particular
installation.

How can I print a char as a number? How can I print

a char* so the output shows the pointer’s numeric
value?
Cast it.
C++ streams do what most programmers expect when printing a char. If you print a character, it
prints as the actual character, not the numeric value of the character:
1. #include <iostream>
2. #include <string>
3.
4. void f()
5. {
6. char c = 'x';
7. std::string s = "Now is";
8. const char* t = "the time";
9. std::cout << c; // Prints a character, in this case, x
10. std::cout << 'y'; // Prints a character, in this case, y
11. std::cout << s[2]; // Prints a character, in this case, w
12. std::cout << t[2]; // Prints a character, in this case, e
13. }
C++ streams also do the right thing when printing a char*: it prints the string, which must be
terminated by '\0'.
1. #include <iostream>
2. #include <string>
3.
4. void f()
5. {
6. const char* s = "xyz";
7. std::cout << s; // Prints the string, in this case, xyz
8. std::cout << "pqr"; // Prints the string, in this case, pqr
9. }
These seem obvious only because they are intuitive, but in fact there is some pretty wonderful
functionality going on in there. C++ streams interpret the values of your chars into actual human
readable symbols according to your current locale, plus they know that if you give them a character-
pointer, you probably meant to print the C-like string. The only problem is when you do not want
the code to behave this way.
Imagine you have a structure that stores peoples’ age as an unsigned char. If you wanted to print
that structure, it would not make much sense to say that a person’s is 'A'. Or if for some reason you
wanted to print the address of that age variable, the stream would start at that address and would
interpret every subsequent byte (bytes of your struct or class or even of the stack!) as a character,
stopping finally when it reaches the first byte containing '\0'.
1. // Variable 'age' stores the person's age
2. unsigned char age = 65;
3.
4. // Our goal here is to print the person's age:
5. std::cout << age; // Whoops! Prints 'A', not the numeric age
6.
7. // Our next goal is to print the age variable's location, that is, its address:
8. std::cout << &age; // Whoops! Prints garbage, and might crash
This is not what was desired. The simplest, and usually recommended, solution is to cast
the char or char* to a type your compiler does not interpret as characters, respectively an int or
a void*:
1. // Variable 'age' stores the person's age
2. unsigned char age = 65;
3.
4. // Our goal here is to print the person's age:
5. std::cout << static_cast<unsigned>(age); // Good: prints 65
6.
7. // Our next goal is to print the age variable's location, that is, its address:
8. std::cout << static_cast<const void*>(&age); // Good: prints the variable's address
That works great for explicitly specified types, such as unsigned char shown above. But if you
are creating a template, where the type unsigned char above is simply known as some numeric
type T, you don’t want to assume the proper numeric type is unsigned or anything else. In this
case, you want to convert your T object to the proper numeric type, whatever that is.
 For example, your type T might be anything from char to int to long or long long (if your
compiler supports that already). Or your type T might even be an abstract numeric class that does
not even provide a cast to any built-in integer
(think safe_integer, ranged_integer or big_num classes, for example).
One way to handle this is through traits or template specialization, but there is a much simpler
solution that works for char types without jeopardizing these other types. So long as
type T provides a unary + operator with ordinary semantics[*footnote], which is provided for all
built-in numeric types, everything will work fine:
1. template <typename T>
2. void my_super_function(T x)
3. {
4. // ...
5. std::cout << +x << '\n'; // promotes x to a type printable as a number, regardless of type
6. // ...
7. }
Works like magic. The worst you have to worry about now is that it might be a bit cryptic to other
developers. If you are thinking to yourself, “Self, I should probably create a function
called promote_to_printable_integer_type() to make my code self-documenting.”
Unfortunately, C++ currently lacks Type Inference, so writing such a function would require code
so complex it would probably bring more bugs than the (potential) ones you would prevent. So short
term, the best solution is to just bite the bullet, use operator+ and comment your code.
When your organization gets access to C++11, you can start enjoying the convenience of type
inference:
1. template <typename T>
2. auto promote_to_printable_integer_type(T i) -> decltype(+i)
3. {
4. return +i;
5. }
Without going into detail, the return type is “the same type as the type of +i”. It might look weird,
but like most generic templates, what counts is the ease of use, not the beauty of the template
definition itself. Here is a sample use:
1. void f()
2. {
3. unsigned char age = 65;
4. std::cout << promote_to_printable_integer_type(age); // Prints 65
5. }
6.
7. template <typename T>
8. void g(T x)
9. {
10. // ...
11. std::cout << promote_to_printable_integer_type(x); // Works for any T that provides unary +
12. // ...
13. }
This answer will be updated due to C++11 type inference. Watch this space for updates in the near
future!!
[*footnote] If you are defining a class that represents a number, to provide a unary + operator with
canonical semantics, create an operator+() that simply returns *this either by value or by
reference-to-const.

Const Correctness
Save to:
 InstapaperPocketReadability
Contents of this section:

 What is “const correctness”?

 How is “const correctness” related to ordinary type safety?
 Should I try to get things const correct “sooner” or “later”?
 What does “const X* p” mean?
 What’s the difference between “const X* p”, “X* const p” and “const X* const
p”?
 What does “const X& x” mean?
 What do “X const& x” and “X const* p” mean?
 Does “X& const x” make any sense?
 What is a “const member function”?
 What is the relationship between a return-by-reference and a const member function?
 What’s the deal with “const-overloading”?
 How can it help me design better classes if I distinguish logical state from physical state?
 Should the constness of my public member functions be based on what the method does
to the object’s logical state, or physical state?
 What do I do if I want a const member function to make an “invisible” change to a data
member?
 Does const_cast mean lost optimization opportunities?
 Why does the compiler allow me to change an int after I’ve pointed at it with a const
int*?
 Does “const Fred* p” mean that *p can’t change?
 Why am I getting an error converting a Foo** → const Foo**?
What is “const correctness”?
A good thing. It means using the keyword const to prevent const objects from getting mutated.
For example, if you wanted to create a function f() that accepted a std::string, plus you want
to promise callers not to change the caller’s std::string that gets passed to f(), you can
have f() receive its std::string parameter…
 void f1(const std::string& s); // Pass by reference-to-const
 void f2(const std::string* sptr); // Pass by pointer-to-const
 void f3(std::string s); // Pass by value
In the pass by reference-to-const and pass by pointer-to-const cases, any attempts to change the
caller’s std::string within the f() functions would be flagged by the compiler as an error at
compile-time. This check is done entirely at compile-time: there is no run-time space or speed cost
for the const. In the pass by value case (f3()), the called function gets a copy of the
caller’s std::string. This means that f3() can change its local copy, but the copy is destroyed
when f3() returns. In particular f3() cannot change the caller’s std::string object.
As an opposite example, suppose you wanted to create a function g() that accepted
a std::string, but you want to let callers know that g() might change the
caller’s std::string object. In this case you can have g() receive its std::string parameter…
 void g1(std::string& s); // Pass by reference-to-non-const
 void g2(std::string* sptr); // Pass by pointer-to-non-const
The lack of const in these functions tells the compiler that they are allowed to (but are not required
to) change the caller’s std::string object. Thus they can pass their std::string to any of
the f() functions, but only f3() (the one that receives its parameter “by value”) can pass
its std::string to g1() or g2(). If f1() or f2() need to call either g() function, a local copy
 of the std::string object must be passed to the g() function; the parameter
to f1() or f2() cannot be directly passed to either g() function. E.g.,
1. void g1(std::string& s);
2.
3. void f1(const std::string& s)
4. {
5. g1(s); // Compile-time Error since s is const
6.
7. std::string localCopy = s;
8. g1(localCopy); // Okay since localCopy is not const
9. }
Naturally in the above case, any changes that g1() makes are made to the localCopy object that is
local to f1(). In particular, no changes will be made to the const parameter that was passed by
reference to f1().
How is “const correctness” related to ordinary type
safety?
Declaring the const-ness of a parameter is just another form of type safety.
If you find ordinary type safety helps you get systems correct (it does; especially in large systems),
you’ll find const correctness helps also.
The benefit of const correctness is that it prevents you from inadvertently modifying something you
didn’t expect would be modified. You end up needing to decorate your code with a few extra
keystrokes (the const keyword), with the benefit that you’re telling the compiler and other
programmers some additional piece of important semantic information — information that the
compiler uses to prevent mistakes and other programmers use as documentation.
Conceptually you can imagine that const std::string, for example, is a different class than
ordinary std::string, since the const variant is conceptually missing the various mutative
operations that are available in the non-const variant. For example, you can conceptually imagine
that a const std::string simply doesn’t have an assignment operator += or any other mutative
operations.
Should I try to get things const correct “sooner” or
“later”?
At the very, very, very beginning.
Back-patching const correctness results in a snowball effect: every const you add “over here”
requires four more to be added “over there.”
Add const early and often.
What does “const X* p” mean?
It means p points to an object of class X, but p can’t be used to change that X object
(naturally p could also be NULL).
Read it right-to-left: “p is a pointer to an X that is constant.”
For example, if class X has a const member function such as inspect() const, it is okay to
say p->inspect(). But if class X has a non-const member function called mutate(), it is an
error if you say p->mutate().
Significantly, this error is caught by the compiler at compile-time — no run-time tests are done.
That means const doesn’t slow down your program and doesn’t require you to write extra test-
cases to check things at runtime — the compiler does the work at compile-time.
 What’s the difference between “const X* p”, “X* const p”
and “const X* const p”?
Read the pointer declarations right-to-left.
 const X* p means “p points to an X that is const”: the X object can’t be changed via p.
 X* const p means “p is a const pointer to an X that is non-const”: you can’t change the
pointer p itself, but you can change the X object via p.
 const X* const p means “p is a const pointer to an X that is const”: you can’t change
the pointer p itself, nor can you change the X object via p.
And, oh yea, did I mention to read your pointer declarations right-to-left?

What does “const X& x” mean?

It means x aliases an X object, but you can’t change that X object via x.
Read it right-to-left: “x is a reference to an X that is const.”
For example, if class X has a const member function such as inspect() const, it is okay to
say x.inspect(). But if class X has a non-const member function called mutate(), it is an
error if you say x.mutate().
This is entirely symmetric with pointers to const, including the fact that the compiler does all the
checking at compile-time, which means const doesn’t slow down your program and doesn’t
require you to write extra test-cases to check things at runtime.
What do “X const& x” and “X const* p” mean?
X const& x is equivalent to const X& x, and X const* x is equivalent to const X* x.
Some people prefer the const-on-the-right style, calling it “consistent const” or, using a term
coined by Simon Brand, “East const.” Indeed the “East const” style can be more consistent than
the alternative: the “East const” style always puts the const on the right of what it constifies,
whereas the other style sometimes puts the const on the left and sometimes on the right
(for const pointer declarations and const member functions).
With the “East const” style, a local variable that is const is defined with the const on the
right: int const a = 42;. Similarly a static variable that is const is defined as static
double const x = 3.14;. Basically every const ends up on the right of the thing it constifies,
including the const that is required to be on the right: const pointer declarations and with
a const member function.
The “East const” style is also less confusing when used with type aliases: Why
do foo and bar have different types here?
1. using X_ptr = X*;
2.
3. const X_ptr foo;
4. const X* bar;
Using the “East const” style makes this clearer:
1. using X_ptr = X*;
2.
3. X_ptr const foo;
4. X* const foobar;
5. X const* bar;
It is clearer here that foo and foobar are the same type and that bar is a different type.
The “East const” style is also more consistent with pointer declarations. Contrast the traditional
style:
1. const X** foo;
2. const X* const* bar;
3. const X* const* const baz;
with the “East const” style
1. X const** foo;
2. X const* const* bar;
3. X const* const* const baz;
Despite these benefits, the const-on-the-right style is not yet popular, so legacy code tends to have
the traditional style.
Does “X& const x” make any sense?
No, it is nonsense.
To find out what the above declaration means, read it right-to-left: “x is a const reference to a X”.
But that is redundant — references are always const, in the sense that you can never reseat a
reference to make it refer to a different object. Never. With or without the const.
In other words, “X& const x” is functionally equivalent to “X& x”. Since you’re gaining nothing
by adding the const after the &, you shouldn’t add it: it will confuse people — the const will
make some people think that the X is const, as if you had said “const X& x”.
What is a “const member function”?
A member function that inspects (rather than mutates) its object.
A const member function is indicated by a const suffix just after the member function’s
parameter list. Member functions with a const suffix are called “const member functions” or
“inspectors.” Member functions without a const suffix are called “non-const member functions”
or “mutators.”
1. class Fred {
2. public:
3. void inspect() const; // This member promises NOT to change *this
4. void mutate(); // This member function might change *this
5. };
6.
7. void userCode(Fred& changeable, const Fred& unchangeable)
8. {
9. changeable.inspect(); // Okay: doesn't change a changeable object
10. changeable.mutate(); // Okay: changes a changeable object
11.
12. unchangeable.inspect(); // Okay: doesn't change an unchangeable object
13. unchangeable.mutate(); // ERROR: attempt to change unchangeable object
14. }
The attempt to call unchangeable.mutate() is an error caught at compile time. There is no
runtime space or speed penalty for const, and you don’t need to write test-cases to check it at
runtime.
The trailing const on inspect() member function should be used to mean the method won’t
change the object’s abstract (client-visible) state. That is slightly different from saying the method
won’t change the “raw bits” of the object’s struct. C++ compilers aren’t allowed to take the
“bitwise” interpretation unless they can solve the aliasing problem, which normally can’t be solved
(i.e., a non-const alias could exist which could modify the state of the object). Another (important)
insight from this aliasing issue: pointing at an object with a pointer-to-const doesn’t guarantee that
the object won’t change; it merely promises that the object won’t change via that pointer.
What is the relationship between a return-by-reference
and a const member function?
 If you want to return a member of your this object by reference from an inspector method, you
should return it using reference-to-const (const X& inspect() const) or by value (X
inspect() const).
1. class Person {
2. public:
3. const std::string& name_good() const; // Right: the caller can't change the Person's name
4. std::string& name_evil() const; // Wrong: the caller can change the Person's name
5. int age() const; // Also right: the caller can't change the Person's age
6. // ...
7. };
8.
9. void myCode(const Person& p) // myCode() promises not to change the Person object...
10. {
11. p.name_evil() = "Igor"; // But myCode() changed it anyway!!
12. }
The good news is that the compiler will often catch you if you get this wrong. In particular, if you
accidentally return a member of your this object by non-const reference, such as
in Person::name_evil() above, the compiler will often detect it and give you a compile-time
error while compiling the innards of, in this case, Person::name_evil().
The bad news is that the compiler won’t always catch you: there are some cases where the compiler
simply won’t ever give you a compile-time error message.
Translation: you need to think. If that scares you, find another line of work; “think” is not a four-
letter word.
Remember the “const philosophy” spread throughout this section: a const member function must
not change (or allow a caller to change) the this object’s logical state (AKA abstract state
AKA meaningwise state). Think of what an object means, not how it is internally implemented. A
Person’s age and name are logically part of the Person, but the Person’s neighbor and employer are
not. An inspector method that returns part of the this object’s logical / abstract / meaningwise
state must not return a non-const pointer (or reference) to that part, independent of whether that
part is internally implemented as a direct data-member physically embedded within the this object
or some other way.
What’s the deal with “const-overloading”?
const overloading helps you achieve const correctness.
const overloading is when you have an inspector method and a mutator method with the same
name and the same number of and types of parameters. The two distinct methods differ only in that
the inspector is const and the mutator is non-const.
The most common use of const overloading is with the subscript operator. You should generally
try to use one of the standard container templates, such as std::vector, but if you need to create
your own class that has a subscript operator, here’s the rule of thumb: subscript operators often
come in pairs.
1. class Fred { /*...*/ };
2.
3. class MyFredList {
4. public:
5. const Fred& operator[] (unsigned index) const; // Subscript operators often come in pairs
6. Fred& operator[] (unsigned index); // Subscript operators often come in pairs
7. // ...
8. };
The const subscript operator returns a const-reference, so the compiler will prevent callers from
inadvertently mutating/changing the Fred. The non-const subscript operator returns a non-
const reference, which is your way of telling your callers (and the compiler) that your callers are
allowed to modify the Fred object.
 When a user of your MyFredList class calls the subscript operator, the compiler selects which
overload to call based on the constness of their MyFredList. If the caller has a MyFredList
a or MyFredList& a, then a[3] will call the non-const subscript operator, and the caller will
end up with a non-const reference to a Fred:
For example, suppose class Fred has an inspector-method inspect() const and a mutator-
method mutate():
1. void f(MyFredList& a) // The MyFredList is non-const
2. {
3. // Okay to call methods that inspect (look but not mutate/change) the Fred at a[3]:
4. Fred x = a[3]; // Doesn't change to the Fred at a[3]: merely makes a copy of that Fred
5. a[3].inspect(); // Doesn't change to the Fred at a[3]: inspect() const is an inspector-method
6.
7. // Okay to call methods that DO change the Fred at a[3]:
8. Fred y;
9. a[3] = y; // Changes the Fred at a[3]
10. a[3].mutate(); // Changes the Fred at a[3]: mutate() is a mutator-method
11. }
However if the caller has a const MyFredList a or const MyFredList& a, then a[3] will
call the const subscript operator, and the caller will end up with a const reference to a Fred. This
allows the caller to inspect the Fred at a[3], but it prevents the caller from inadvertently
mutating/changing the Fred at a[3].
1. void f(const MyFredList& a) // The MyFredList is const
2. {
3. // Okay to call methods that DON'T change the Fred at a[3]:
4. Fred x = a[3];
5. a[3].inspect();
6.
7. // Compile-time error (fortunately!) if you try to mutate/change the Fred at a[3]:
8. Fred y;
9. a[3] = y; // Fortunately(!) the compiler catches this error at compile-time
10. a[3].mutate(); // Fortunately(!) the compiler catches this error at compile-time
11. }
Const overloading for subscript- and funcall-operators is illustrated here, here, here, here, and here.
You can, of course, also use const-overloading for things other than the subscript operator.
How can it help me design better classes if I
distinguish logical state from physical state?
Because that encourages you to design your classes from the outside-in rather than from the inside-
out, which in turn makes your classes and objects easier to understand and use, more intuitive, less
error prone, and faster. (Okay, that’s a slight over-simplification. To understand all the if’s and’s
and but’s, you’ll just have to read the rest of this answer!)
Let’s understand this from the inside-out — you will (should) design your classes from the outside-
in, but if you’re new to this concept, it’s easier to understand from the inside-out.
On the inside, your objects have physical (or concrete or bitwise) state. This is the state that’s easy
for programmers to see and understand; it’s the state that would be there if the class were just a C-
style struct.
On the outside, your objects have users of your class, and these users are restricted to using
only public member functions and friends. These external users also perceive the object as
having state, for example, if the object is of class Rectangle with
methods width(), height() and area(), your users would say that those three are all part of the
object’s logical (or abstract or meaningwise) state. To an external user, the Rectangle object
actually has an area, even if that area is computed on the fly (e.g., if the area() method returns the
 product of the object’s width and height). In fact, and this is the important point, your users don’t
know and don’t care how you implement any of these methods; your users still perceive, from their
perspective, that your object logically has a meaningwise state of width, height, and area.
The area() example shows a case where the logical state can contain elements that are not directly
realized in the physical state. The opposite is also true: classes sometimes intentionally hide part of
their objects’ physical (concrete, bitwise) state from users — they intentionally do not provide
any public member functions or friends that would allow users to read or write or even know
about this hidden state. That means there are bits in the object’s physical state that have no
corresponding elements in the object’s logical state.
As an example of this latter case, a collection-object might cache its last lookup in hopes of
improving the performance of its next lookup. This cache is certainly part of the object’s physical
state, but there it is an internal implementation detail that will probably not be exposed to users — it
will probably not be part of the object’s logical state. Telling what’s what is easy if you think from
the outside-in: if the collection-object’s users have no way to check the state of the cache itself, then
the cache is transparent, and is not part of the object’s logical state.
Should the constness of my public member functions be
based on what the method does to the object’s logical state,
or physical state?
Logical.
There’s no way to make this next part easy. It is going to hurt. Best recommendation is to sit down.
And please, for your safety, make sure there are no sharp implements nearby.
Let’s go back to the collection-object example. Remember: there’s a lookup method that caches the
last lookup in hopes to speed up future lookups.
Let’s state what is probably obvious: assume that the lookup method makes no changes to any of the
collection-object’s logical state.
So… the time has come to hurt you. Are you ready?
Here comes: if the lookup method does not make any change to any of the collection-object’s
logical state, but it does change the collection-object’s physical state (it makes a very real change to
the very real cache), should the lookup method be const?
The answer is a resounding Yes. (There are exceptions to every rule, so “Yes” should really have an
asterisk next to it, but the vast majority of the time, the answer is Yes.)
This is all about “logical const” over “physical const.” It means the decision about whether to
decorate a method with const should hinge primarily on whether that method leaves
the logical state unchanged, irrespective (are you sitting down?) (you might want to sit
down) irrespective of whether the method happens to make very real changes to the object’s very
real physical state.
In case that didn’t sink in, or in case you are not yet in pain, let’s tease it apart into two cases:
 If a method changes any part of the object’s logical state, it logically is a mutator; it should
not be const even if (as actually happens!) the method doesn’t change any physical bits of the
object’s concrete state.
 Conversely, a method is logically an inspector and should be const if it never changes any
part of the object’s logical state, even if (as actually happens!) the method changes physical bits
of the object’s concrete state.
If you’re confused, read it again.
 If you’re not confused but are angry, good: you may not like it yet, but at least you understand it.
Take a deep breath and repeat after me: “The constness of a method should makes sense from outside
the object.”
If you’re still angry, repeat this three times: “The constness of a method must make sense to the object’s
users, and those users can see only the object’s logical state.”
If you’re still angry, sorry, it is what it is. Suck it up and live with it. Yes, there will be exceptions;
every rule has them. But as a rule, in the main, this logical const notion is good for you and good
for your software.
One more thing. This is going to get inane, but let’s be precise about whether a method changes the
object’s logical state. If you are outside the class — you are a normal user, every experiment you
could perform (every method or sequence of methods you call) would have the same results (same
return values, same exceptions or lack of exceptions) irrespective of whether you first called that
lookup method. If the lookup function changed any future behavior of any future method (not just
making it faster but changed the outcome, changed the return value, changed the exception), then
the lookup method changed the object’s logical state — it is a mutuator. But if the lookup method
changed nothing other than perhaps making some things faster, then it is an inspector.
What do I do if I want a const member function to make
an “invisible” change to a data member?
Use mutable (or, as a last resort, use const_cast).
A small percentage of inspectors need to make changes to an object’s physical state that cannot be
observed by external users — changes to the physical but not logical state.
For example, the collection-object discussed earlier cached its last lookup in hopes of improving the
performance of its next lookup. Since the cache, in this example, cannot be directly observed by any
part of the collection-object’s public interface (other than timing), its existence and state is not part
of the object’s logical state, so changes to it are invisible to external users. The lookup method is an
inspector since it never changes the object’s logical state, irrespective of the fact that, at least for the
present implementation, it changes the object’s physical state.
When methods change the physical but not logical state, the method should generally be marked
as const since it really is an inspector-method. That creates a problem: when the compiler sees
your const method changing the physical state of the this object, it will complain — it will give
your code an error message.
The C++ compiler language uses the mutable keyword to help you embrace
this logical const notion. In this case, you would mark the cache with the mutable keyword, that
way the compiler knows it is allowed to change inside a const method or via any
other const pointer or reference. In our lingo, the mutable keyword marks those portions of the
object’s physical state which are not part of the logical state.
The mutable keyword goes just before the data member’s declaration, that is, the same place
where you could put const. The other approach, not preferred, is to cast away the const‘ness of
the this pointer, probably via the const_cast keyword:
1. Set* self = const_cast<Set*>(this);
2. // See the NOTE below before doing this!
After this line, self will have the same bits as this, that is, self == this, but self is
a Set* rather than a const Set* (technically this is a const Set* const, but the right-
most const is irrelevant to this discussion). That means you can use self to modify the object
pointed to by this.
NOTE: there is an extremely unlikely error that can occur with const_cast. It only happens when
three very rare things are combined at the same time: a data member that ought to
be mutable (such as is discussed above), a compiler that doesn’t support the mutable keyword
and/or a programmer who doesn’t use it, and an object that was originally defined to be const (as
 opposed to a normal, non-const object that is pointed to by a pointer-to-const). Although this
combination is so rare that it may never happen to you, if it ever did happen, the code may not work
(the Standard says the behavior is undefined).
If you ever want to use const_cast, use mutable instead. In other words, if you ever need to
change a member of an object, and that object is pointed to by a pointer-to-const, the safest and
simplest thing to do is add mutable to the member’s declaration. You can use const_cast if you
are sure that the actual object isn’t const (e.g., if you are sure the object is declared something like
this: Set s;), but if the object itself might be const (e.g., if it might be declared like: const Set
s;), use mutable rather than const_cast.
Please don’t write saying version X of compiler Y on machine Z lets you change a non-
mutable member of a const object. I don’t care — it is illegal according to the language and your
code will probably fail on a different compiler or even a different version (an upgrade) of the same
compiler. Just say no. Use mutable instead. Write code that is guaranteed to work, not code
that doesn’t seem to break.
Does const_cast mean lost optimization opportunities?
In theory, yes; in practice, no.
Even if the language outlawed const_cast, the only way to avoid flushing the register cache
across a const member function call would be to solve the aliasing problem (i.e., to prove that
there are no non-const pointers that point to the object). This can happen only in rare cases (when
the object is constructed in the scope of the const member function invocation, and when all the
non-const member function invocations between the object’s construction and the const member
function invocation are statically bound, and when every one of these invocations is also inlined,
and when the constructor itself is inlined, and when any member functions the constructor calls
are inline).
Why does the compiler allow me to change an int after
I’ve pointed at it with a const int*?
Because “const int* p” means “p promises not to change the *p,” not “*p promises not to
change.”
Causing a const int* to point to an int doesn’t const-ify the int. The int can’t be changed
via the const int*, but if someone else has an int* (note: no const) that points to (“aliases”)
the same int, then that int* can be used to change the int. For example:
1. void f(const int* p1, int* p2)
2. {
3. int i = *p1; // Get the (original) value of *p1
4. *p2 = 7; // If p1 == p2, this will also change *p1
5. int j = *p1; // Get the (possibly new) value of *p1
6. if (i != j) {
7. std::cout << "*p1 changed, but it didn't change via pointer p1!\n";
8. assert(p1 == p2); // This is the only way *p1 could be different
9. }
10. }
11.
12. int main()
13. {
14. int x = 5;
15. f(&x, &x); // This is perfectly legal (and even moral!)
16. // ...
17. }
 Note that main() and f(const int*,int*) could be in different compilation units that are
compiled on different days of the week. In that case there is no way the compiler can possibly detect
the aliasing at compile time. Therefore there is no way we could make a language rule that prohibits
this sort of thing. In fact, we wouldn’t even want to make such a rule, since in general it’s
considered a feature that you can have many pointers pointing to the same thing. The fact that one
of those pointers promises not to change the underlying “thing” is just a promise made by
the pointer; it’s not a promise made by the “thing”.
Does “const Fred* p” mean that *p can’t change?
No! (This is related to the FAQ about aliasing of int pointers.)
“const Fred* p” means that the Fred can’t be changed via pointer p, but there might be other
ways to get at the object without going through a const (such as an aliased non-const pointer
such as a Fred*). For example, if you have two pointers “const Fred* p” and “Fred* q” that
point to the same Fred object (aliasing), pointer q can be used to change the Fred object but
pointer p cannot.
1. class Fred {
2. public:
3. void inspect() const; // A const member function
4. void mutate(); // A non-const member function
5. };
6.
7. int main()
8. {
9. Fred f;
10. const Fred* p = &f;
11. Fred* q = &f;
12.
13. p->inspect(); // Okay: No change to *p
14. p->mutate(); // Error: Can't change *p via p
15.
16. q->inspect(); // Okay: q is allowed to inspect the object
17. q->mutate(); // Okay: q is allowed to mutate the object
18.
19. f.inspect(); // Okay: f is allowed to inspect the object
20. f.mutate(); // Okay: f is allowed to mutate the object
21.
22. // ...
23. }

Why am I getting an error converting a Foo** → const

Foo**?
Because converting Foo** → const Foo** would be invalid and dangerous.
C++ allows the (safe) conversion Foo* → Foo const*, but gives an error if you try to implicitly
convert Foo** → const Foo**.
The rationale for why that error is a good thing is given below. But first, here is the most common
solution: simply change const Foo** to const Foo* const*:
1. class Foo { /* ... */ };
2.
3. void f(const Foo** p);
4. void g(const Foo* const* p);
5.
6. int main()
7. {
8. Foo** p = /*...*/;
9. // ...
10. f(p); // ERROR: it's illegal and immoral to convert Foo** to const Foo**
11. g(p); // Okay: it's legal and moral to convert Foo** to const Foo* const*
12. // ...
13. }
The reason the conversion from Foo** → const Foo** is dangerous is that it would let you
silently and accidentally modify a const Foo object without a cast:
1. class Foo {
2. public:
3. void modify(); // make some modification to the this object
4. };
5.
6. int main()
7. {
8. const Foo x;
9. Foo* p;
10. const Foo** q = &p; // q now points to p; this is (fortunately!) an error
11. *q = &x; // p now points to x
12. p->modify(); // Ouch: modifies a const Foo!!
13. // ...
14. }
If the q = &p line were legal, q would be pointing at p. The next line, *q = &x, changes p itself
(since *q is p) to point at x. That would be a bad thing, since we would have lost
the const qualifier: p is a Foo* but x is a const Foo. The p->modify() line exploits p’s ability
to modify its referent, which is the real problem, since we ended up modifying a const Foo.
By way of analogy, if you hide a criminal under a lawful disguise, he can then exploit the trust
given to that disguise. That’s bad.
Thankfully C++ prevents you from doing this: the line q = &p is flagged by the C++ compiler as a
compile-time error. Reminder: please do not pointer-cast your way around that compile-time error
message. Just Say No!
(Note: there is a conceptual similarity between this and the prohibition against
converting Derived** to Base**.)

References
Save to:
InstapaperPocketReadability
Contents of this section:

 What is a reference?
 What happens if you assign to a reference?
 What happens if you return a reference?
 What does object.method1().method2() mean?
 How can you reseat a reference to make it refer to a different object?
 Why does C++ have both pointers and references?
 When should I use references, and when should I use pointers?
 What does it mean that a reference must refer to an object, not a dereferenced null pointer?
 What is a handle to an object? Is it a pointer? Is it a reference? Is it a pointer-to-a-pointer?
What is it?
 Should I use call-by-value or call-by-reference?
 Why is this not a reference?
What is a reference?
An alias (an alternate name) for an object.

References are frequently used for pass-by-reference:

1. void swap(int& i, int& j)

2. {
3. int tmp = i;
4. i = j;
5. j = tmp;
6. }
7.
8. int main()
9. {
10. int x, y;
11. // ...
12. swap(x,y);
13. // ...
14. }
Here i and j are aliases for main’s x and y respectively. In other words, i is x — not a pointer to x,
nor a copy of x, but x itself. Anything you do to i gets done to x, and vice versa. This includes
taking the address of it. The values of &i and &x are identical.
That’s how you should think of references as a programmer. Now, at the risk of confusing you by
giving you a different perspective, here’s how references are implemented. Underneath it all, a
reference i to object x is typically the machine address of the object x. But when the programmer
says i++, the compiler generates code that increments x. In particular, the address bits that the
compiler uses to find x are not changed. A C programmer will think of this as if you used the C
style pass-by-pointer, with the syntactic variant of (1) moving the & from the caller into the callee,
and (2) eliminating the *s. In other words, a C programmer will think of i as a macro for (*p),
where p is a pointer to x (e.g., the compiler automatically dereferences the underlying pointer; i+
+ is changed to (*p)++; i = 7 is automatically changed to *p = 7).
Important note: Even though a reference is often implemented using an address in the underlying
assembly language, please do not think of a reference as a funny looking pointer to an object. A
reference is the object, just with another name. It is neither a pointer to the object, nor a copy of the
object. It is the object. There is no C++ syntax that lets you operate on the reference itself separate
from the object to which it refers.

What happens if you assign to a reference?

You change the state of the referent (the referent is the object to which the reference refers).

Remember: the reference is the referent, so changing the reference changes the state of the referent.
In compiler writer lingo, a reference is an “lvalue” (something that can appear on the left hand side
of an assignment operator).

What happens if you return a reference?

The function call can appear on the left hand side of an assignment operator.
This ability may seem strange at first. For example, no one thinks the expression f() = 7 makes
sense. Yet, if a is an object of class Array, most people think that a[i] = 7 makes sense even
though a[i] is really just a function call in disguise (it calls Array::operator[](int), which
is the subscript operator for class Array).
1. class Array {
2. public:
3. int size() const;
4. float& operator[] (int index);
5. // ...
6. };
7.
8. int main()
9. {
10. Array a;
11. for (int i = 0; i < a.size(); ++i)
12. a[i] = 7; // This line invokes Array::operator[](int)
13. // ...
14. }

What does object.method1().method2() mean?

It chains these method calls, which is why this is called method chaining.
The first thing that gets executed is object.method1(). This returns some object, which might be
a reference to object (i.e., method1() might end with return *this;), or it might be some
other object. Let’s call the returned object objectB. Then objectB becomes the this object
of method2().
The most common use of method chaining is in the iostream library. E.g., cout << x <<
y works because cout << x is a function that returns cout.
A less common, but still rather slick, use for method chaining is in the Named Parameter Idiom.

How can you reseat a reference to make it refer to a

different object?
No way.

You can’t separate the reference from the referent.

Unlike a pointer, once a reference is bound to an object, it can not be “reseated” to another object.
The reference isn’t a separate object. It has no identity. Taking the address of a reference gives you
the address of the referent. Remember: the reference is its referent.
In that sense, a reference is similar to a const pointer such as int* const p (as opposed to
a pointer to const such as const int* p). But please don’t confuse references with pointers;
they’re very different from the programmer’s standpoint.

Why does C++ have both pointers and references?

C++ inherited pointers from C, so they couldn’t be removed without causing serious compatibility
problems. References are useful for several things, but the direct reason they were introduced in C+
+ was to support operator overloading. For example:

1. void f1(const complex* x, const complex* y) // without references

2. {
3. complex z = *x+*y; // ugly
4. // ...
5. }
6.
7. void f2(const complex& x, const complex& y) // with references
8. {
9. complex z = x+y; // better
10. // ...
11. }
 More generally, if you want to have both the functionality of pointers and the functionality of
references, you need either two different types (as in C++) or two different sets of operations on a
single type. For example, with a single type you need both an operation to assign to the object
referred to and an operation to assign to the reference/pointer. This can be done using separate
operators (as in Simula). For example:

1. Ref<My_type> r :- new My_type;

2. r := 7; // assign to object
3. r :- new My_type; // assign to reference
Alternatively, you could rely on type checking (overloading). For example:

1. Ref<My_type> r = new My_type;

2. r = 7; // assign to object
3. r = new My_type; // assign to reference

When should I use references, and when should I use

pointers?
Use references when you can, and pointers when you have to.

References are usually preferred over pointers whenever you don’t need “reseating”. This usually
means that references are most useful in a class’s public interface. References typically appear on
the skin of an object, and pointers on the inside.
The exception to the above is where a function’s parameter or return value needs a “sentinel”
reference — a reference that does not refer to an object. This is usually best done by
returning/taking a pointer, and giving the nullptr value this special significance (references must
always alias objects, not a dereferenced null pointer).
Note: Old line C programmers sometimes don’t like references since they provide reference
semantics that isn’t explicit in the caller’s code. After some C++ experience, however, one quickly
realizes this is a form of information hiding, which is an asset rather than a liability. E.g.,
programmers should write code in the language of the problem rather than the language of the
machine.

What does it mean that a reference must refer to an

object, not a dereferenced null pointer?
It means this is illegal:

1. T* p = nullptr;
2. T& r = *p; // illegal
NOTE: Please do not email us saying the above works on your particular version of your particular
compiler. It’s still illegal. The C++ language, as defined by the C++ standard, says it’s illegal; that
makes it illegal. The C++ standard does not require a diagnostic for this particular error, which
means your particular compiler is not obliged to notice that p is nullptr or to give an error
message, but it’s still illegal. The C++ language also does not require the compiler to generate code
that would blow up at runtime. In fact, your particular version of your particular compiler may, or
may not, generate code that you think makes sense if you do the above. But that’s the point: since
the compiler is not required to generate sensible code, you don’t know what the compiler will do.
So please do not email us saying your particular compiler generates good code; we don’t care. It’s
still illegal. See the C++ standard for more, for example, C++ 2014 section 8.3.2 [dcl.ref] p5.
 By way of example and not by way of limitation, some compilers do optimize nullptr tests since
they “know” all references refer to real objects — that references are never (legally) a
dereferenced nullptr. That can cause a compiler to optimize away the following test:
1. // ...the above code...
2. T* p2 = &r;
3. if (p2 == nullptr) {
4. // ...
5. }
As stated above, this is just an example of the sort of thing your compiler might do based on the
language rule that says a reference must refer to a valid object. Do not limit your thinking to the
above example; the message of this FAQ is that the compiler is not required to do something
sensible if you violate the rules. So don’t violate the rules.
Patient: “Doctor, doctor, my eye hurts when I poke it with a spoon.”
Doctor: “Don’t poke it, then.”

What is a handle to an object? Is it a pointer? Is it a

reference? Is it a pointer-to-a-pointer? What is it?
The term handle is used to mean any technique that lets you get to another object — a generalized
pseudo-pointer. The term is (intentionally) ambiguous and vague.
Ambiguity is actually an asset in certain cases. For example, during early design you might not be
ready to commit to a specific representation for the handles. You might not be sure whether you’ll
want simple pointers vs. references vs. pointers-to-pointers vs. references-to-pointers vs. integer
indices into an array vs. strings (or other key) that can be looked up in a hash-table (or other data
structure) vs. database keys vs. some other technique. If you merely know that you’ll need some sort
of thingy that will uniquely identify and get to an object, you call the thingy a Handle.

So if your ultimate goal is to enable a glop of code to uniquely identify/look-up a specific object of
some class Fred, you need to pass a Fred handle into that glop of code. The handle might be a
string that can be used as a key in some well-known lookup table (e.g., a key in
a std::map<std::string,Fred> or a std::map<std::string,Fred*>), or it might be an
integer that would be an index into some well-known array (e.g., Fred* array = new
Fred[maxNumFreds]), or it might be a simple Fred*, or it might be something else.
Novices often think in terms of pointers, but in reality there are downside risks to using raw
pointers. E.g., what if the Fred object needs to move? How do we know when it’s safe
to delete the Fred objects? What if the Fred object needs to (temporarily) get serialized on disk?
etc., etc. Most of the time we add more layers of indirection to manage situations like these. For
example, the handles might be Fred**, where the pointed-to Fred* pointers are guaranteed to
never move but when the Fred objects need to move, you just update the pointed-
to Fred* pointers. Or you make the handle an integer then have the Fred objects (or pointers to
the Fred objects) looked up in a table/array/whatever. Or whatever.
The point is that we use the word Handle when we don’t yet know the details of what we’re going
to do.

Another time we use the word Handle is when we want to be vague about what we’ve already done
(sometimes the term magic cookie is used for this as well, as in, “The software passes around
a magic cookie that is used to uniquely identify and locate the appropriate Fred object”). The
reason we (sometimes) want to be vague about what we’ve already done is to minimize the ripple
effect if/when the specific details/representation of the handle change. E.g., if/when someone
changes the handle from a string that is used in a lookup table to an integer that is looked up in an
array, we don’t want to go and update a zillion lines of code.
 To further ease maintenance if/when the details/representation of a handle changes (or to generally
make the code easier to read/write), we often encapsulate the handle in a class. This class
often overloads operators operator-> and operator* (since the handle acts like a pointer, it
might as well look like a pointer).

Should I use call-by-value or call-by-reference?

(Note: This FAQ needs to be updated for C++11.)

That depends on what you are trying to achieve:

 If you want to change the object passed, call by reference or use a pointer; e.g., void
f(X&); or void f(X*);.
 If you don’t want to change the object passed and it is big, call by const reference; e.g., void
f(const X&);.
 Otherwise, call by value; e.g. void f(X);.
What does “big” mean? Anything larger than a couple of words.
Why would you want to change an argument? Well, often we have to, but often we have an
alternative: produce a new value. Consider:
1. void incr1(int& x); // increment
2. int incr2(int x); // increment
3.
4. int v = 2;
5. incr1(v); // v becomes 3
6. v = incr2(v); // v becomes 4
For a reader, incr2() is likely easier to understand. That is, incr1() is more likely to lead to
mistakes and errors. So, we should prefer the style that returns a new value over the one that
modifies a value as long as the creation and copy of a new value isn’t expensive.
What if you do want to change the argument, should you use a pointer or use a reference? If
passing “not an object” (e.g., a null pointer) is acceptable, using a pointer makes sense. One style is
to use a pointer when you want to modify an object because in some contexts that makes it easier to
spot that a modification is possible.
Note also that a call of a member function is essentially a call-by-reference on the object, so we
often use member functions when we want to modify the value/state of an object.

Why is this not a reference?

Because this was introduced into C++ (really into C with Classes) before references were added.
Also, Stroustrup chose this to follow Simula usage, rather than the (later) Smalltalk use of self.

Memory Management
Save to:
InstapaperPocketReadability
Contents of this section:

 How do I deal with memory leaks?

 Can I use new just as in Java?
 Should I use NULL or 0 or nullptr?
 Does delete p delete the pointer p, or the pointed-to-data *p?
 Is it safe to delete the same pointer twice?
  Can I free() pointers allocated with new? Can I delete pointers allocated
with malloc()?
 What is the difference between new and malloc()?
 Why should I use new instead of trustworthy old malloc()?
 Can I use realloc() on pointers allocated via new?
 Why doesn’t C++ have an equivalent to realloc()?
 Do I need to check for null after p = new Fred()?
 How can I convince my (older) compiler to automatically check new to see if it returns null?
 Do I need to check for null before delete p?
 What are the two steps that happen when I say delete p?
 Why doesn’t delete null out its operand?
 Why isn’t the destructor called at the end of scope?
 In p = new Fred(), does the Fred memory “leak” if the Fred constructor throws an
exception?
 How do I allocate / unallocate an array of things?
 What if I forget the [] when deleteing an array allocated via new T[n]?
 Can I drop the [] when deleteing an array of some built-in type (char, int, etc)?
 After p = new Fred[n], how does the compiler know there are n objects to be destructed
during delete[] p?
 Is it legal (and moral) for a member function to say delete this?
 How do I allocate multidimensional arrays using new?
 But the previous FAQ’s code is SOOOO tricky and error prone! Isn’t there a simpler way?
 But the above Matrix class is specific to Fred! Isn’t there a way to make it generic?
 What’s another way to build a Matrix template?
 Does C++ have arrays whose length can be specified at run-time?
 How can I force objects of my class to always be created via new rather than as local,
namespace-scope, global, or static?
 How do I do simple reference counting?
 How do I provide reference counting with copy-on-write semantics?
 How do I provide reference counting with copy-on-write semantics for a hierarchy of
classes?
 Can I absolutely prevent people from subverting the reference counting mechanism, and if
so, should I?
 Can I use a garbage collector in C++?
 What are the two kinds of garbage collectors for C++?
 Where can I get more info on garbage collectors for C++?
 What is an auto_ptr and why isn’t there an auto_array?
How do I deal with memory leaks?
By writing code that doesn’t have any. Clearly, if your code
has new operations, delete operations, and pointer arithmetic all over the place, you are going to
mess up somewhere and get leaks, stray pointers, etc. This is true independently of how
conscientious you are with your allocations: eventually the complexity of the code will overcome
the time and effort you can afford.
It follows that successful techniques rely on hiding allocation and deallocation inside more
manageable types: For single objects, prefer make_unique or make_shared. For multiple objects,
prefer using standard containers like vector and unordered_map as they manage memory for
their elements better than you could without disproportionate effort. Consider writing this without
the help of string and vector:
1. #include<vector>
2. #include<string>
3. #include<iostream>
4. #include<algorithm>
5. using namespace std;
6.
7. int main() // small program messing around with strings
8. {
9. cout << "enter some whitespace-separated words:\n";
10. vector<string> v;
11. string s;
12. while (cin>>s) v.push_back(s);
13.
14. sort(v.begin(),v.end());
15.
16. string cat;
17. for (auto & str : v) cat += str+"+";
18. cout << cat << '\n';
19. }
What would be your chance of getting it right the first time? And how would you know you didn’t
have a leak?
Note the absence of explicit memory management, macros, casts, overflow checks, explicit size
limits, and pointers. By using a function object and a standard algorithm, the code could
additionally have eliminated the pointer-like use of the iterator, but that seemed overkill for such a
tiny program.
These techniques are not perfect and it is not always easy to use them systematically. However, they
apply surprisingly widely and by reducing the number of explicit allocations and deallocations you
make the remaining examples much easier to keep track of. As early as 1981, Stroustrup pointed out
that by reducing the number of objects that he had to keep track of explicitly from many tens of
thousands to a few dozens, he had reduced the intellectual effort needed to get the program right
from a Herculean task to something manageable, or even easy.
If your application area doesn’t have libraries that make programming that minimizes explicit
memory management easy, then the fastest way of getting your program complete and correct might
be to first build such a library.
Templates and the standard libraries make this use of containers, resource handles, etc., much easier
than it was even a few years ago. The use of exceptions makes it close to essential.
If you cannot handle allocation/deallocation implicitly as part of an object you need in your
application anyway, you can use a resource handle to minimize the chance of a leak. Here is an
example where you need to return an object allocated on the free store from a function. This is an
opportunity to forget to delete that object. After all, we cannot tell just looking at pointer whether it
needs to be deallocated and if so who is responsible for that. Using a resource handle, here the
standard library unique_ptr, makes it clear where the responsibility lies:
1. #include<memory>
2. #include<iostream>
3. using namespace std;
4.
5. struct S {
6. S() { cout << "make an S\n"; }
7. ~S() { cout << "destroy an S\n"; }
8. S(const S&) { cout << "copy initialize an S\n"; }
9. S& operator=(const S&) { cout << "copy assign an S\n"; }
10. };
11.
12. S* f()
13. {
14. return new S; // who is responsible for deleting this S?
15. };
16.
17. unique_ptr<S> g()
18. {
19. return make_unique<S>(); // explicitly transfer responsibility for deleting this S
20. }
21.
22. int main()
23. {
24. cout << "start main\n";
25. S* p = f();
26. cout << "after f() before g()\n";
27. // S* q = g(); // this error would be caught by the compiler
28. unique_ptr<S> q = g();
29. cout << "exit main\n";
30. // leaks *p
31. // implicitly deletes *q
32. }
Think about resources in general, rather than simply about memory.
If systematic application of these techniques is not possible in your environment (you have to use
code from elsewhere, part of your program was written by Neanderthals, etc.), be sure to use a
memory leak detector as part of your standard development procedure, or plug in a garbage
collector.

Can I use new just as in Java?

Sort of, but don’t do it blindly, if you do want it prefer to spell it
as make_unique or make_shared, and there are often superior alternatives that are simpler and
more robust than any of that. Consider:
1. void compute(cmplx z, double d)
2. {
3. cmplx z2 = z+d; // c++ style
4. z2 = f(z2); // use z2
5.
6. cmplx& z3 = *new cmplx(z+d); // Java style (assuming Java could overload +)
7. z3 = f(z3);
8. delete &z3;
9. }
The clumsy use of new for z3 is unnecessary and slow compared with the idiomatic use of a local
variable (z2). You don’t need to use new to create an object if you also delete that object in the
same scope; such an object should be a local variable.
Should I use NULL or 0 or nullptr?
You should use nullptr as the null pointer value. The others still work for backward compatibility
with older code.
A problem with both NULL and 0 as a null pointer value is that 0 is a special “maybe an integer
value and maybe a pointer” value. Use 0 only for integers, and that confusion disappears.
Does delete p delete the pointer p, or the pointed-to-
data *p?
The pointed-to-data.
 The keyword should really be delete_the_thing_pointed_to_by. The same abuse of English
occurs when freeing the memory pointed to by a pointer in C: free(p) really
means free_the_stuff_pointed_to_by(p).
Is it safe to delete the same pointer twice?
No! (Assuming you didn’t get that pointer back from new in between.)
For example, the following is a disaster:
1. class Foo { /*...*/ };
2.
3. void yourCode()
4. {
5. Foo* p = new Foo();
6. delete p;
7. delete p; // DISASTER!
8. // ...
9. }
That second delete p line might do some really bad things to you. It might, depending on the
phase of the moon, corrupt your heap, crash your program, make arbitrary and bizarre changes to
objects that are already out there on the heap, etc. Unfortunately these symptoms can appear and
disappear randomly. According to Murphy’s law, you’ll be hit the hardest at the worst possible
moment (when the customer is looking, when a high-value transaction is trying to post, etc.).
Note: some runtime systems will protect you from certain very simple cases of double delete.
Depending on the details, you might be okay if you happen to be running on one of those
systems and if no one ever deploys your code on another system that handles things differently and
if you are deleting something that doesn’t have a destructor and if you don’t do anything significant
between the two deletes and if no one ever changes your code to do something significant between
the two deletes and if your thread scheduler (over which you likely have no control!) doesn’t
happen to swap threads between the two deletes and if, and if, and if. So back to Murphy: since it
can go wrong, it will, and it will go wrong at the worst possible moment.
Do NOT email me saying you tested it and it doesn’t crash. Get a clue. A non-crash doesn’t prove
the absence of a bug; it merely fails to prove the presence of a bug.
Trust me: double-delete is bad, bad, bad. Just say no.
Can I free() pointers allocated with new? Can
I delete pointers allocated with malloc()?
No! In brief, conceptually malloc and new allocate from different heaps, so
can’t free or delete each other’s memory. They also operate at different levels – raw memory vs.
constructed objects.
You can use malloc() and new in the same program. But you cannot allocate an object
with malloc() and free it using delete. Nor can you allocate
with new and delete with free() or use realloc() on an array allocated by new.
The C++ operators new and delete guarantee proper construction and destruction; where
constructors or destructors need to be invoked, they are. The C-style
functions malloc(), calloc(), free(), and realloc() don’t ensure that. Furthermore, there is
no guarantee that the mechanism used by new and delete to acquire and release raw memory is
compatible with malloc() and free(). If mixing styles works on your system, you were simply
“lucky” – for now.
If you feel the need for realloc() – and many do – then consider using a standard
library vector. For example
1. // read words from input into a vector of strings:
2.
3. vector<string> words;
4. string s;
5. while (cin>>s && s!=".") words.push_back(s);
The vector expands as needed.
See also the examples and discussion in “Learning Standard C++ as a New Language”, which you
can download from Stroustrup’s publications list.
What is the difference between new and malloc()?
First, make_unique (or make_shared) are nearly always superior to both new and malloc() and
completely eliminate delete and free().
Having said that, here’s the difference between those two:
malloc() is a function that takes a number (of bytes) as its argument; it returns a void* pointing
to unitialized storage. new is an operator that takes a type and (optionally) a set of initializers for
that type as its arguments; it returns a pointer to an (optionally) initialized object of its type. The
difference is most obvious when you want to allocate an object of a user-defined type with non-
trivial initialization semantics. Examples:
1. class Circle : public Shape {
2. public:
3. Circle(Point c, int r);
4. // no default constructor
5. // ...
6. };
7.
8. class X {
9. public:
10. X(); // default constructor
11. // ...
12. };
13.
14. void f(int n)
15. {
16. void* p1 = malloc(40); // allocate 40 (uninitialized) bytes
17.
18. int* p2 = new int[10]; // allocate 10 uninitialized ints
19. int* p3 = new int(10); // allocate 1 int initialized to 10
20. int* p4 = new int(); // allocate 1 int initialized to 0
21. int* p4 = new int; // allocate 1 uninitialized int
22.
23. Circle* pc1 = new Circle(Point(0,0),10); // allocate a Circle constructed
24. // with the specified argument
25. Circle* pc2 = new Circle; // error no default constructor
26.
27. X* px1 = new X; // allocate a default constructed X
28. X* px2 = new X(); // allocate a default constructed X
29. X* px2 = new X[10]; // allocate 10 default constructed Xs
30. // ...
31. }
Note that when you specify a initializer using the “(value)” notation, you get initialization with that
value. Often, a vector is a better alternative to a free-store-allocated array (e.g., consider exception
safety).
Whenever you use malloc() you must consider initialization and conversion of the return pointer
to a proper type. You will also have to consider if you got the number of bytes right for your use.
There is no performance difference between malloc() and new when you take initialization into
account.
 malloc() reports memory exhaustion by returning 0. new reports allocation and initialization
errors by throwing exceptions (bad_alloc).
Objects created by new are destroyed by delete. Areas of memory allocated by malloc() are
deallocated by free().
Why should I use new instead of trustworthy
old malloc()?
First, make_unique (or make_shared) are nearly always superior to both new and malloc() and
completely eliminate delete and free().
Having said that, benefits of using new instead of malloc are: Constructors/destructors, type safety,
overridability.
 Constructors/destructors: unlike malloc(sizeof(Fred)), new Fred() calls Fred’s
constructor. Similarly, delete p calls *p’s destructor.
 Type safety: malloc() returns a void* which isn’t type safe. new Fred() returns a
pointer of the right type (a Fred*).
 Overridability: new is an operator that can be overridden by a class, while malloc() is
not overridable on a per-class basis.
Can I use realloc() on pointers allocated via new?
No!
When realloc() has to copy the allocation, it uses a bitwise copy operation, which will tear many
C++ objects to shreds. C++ objects should be allowed to copy themselves. They use their own copy
constructor or assignment operator.
Besides all that, the heap that new uses may not be the same as the heap
that malloc() and realloc() use!
Why doesn’t C++ have an equivalent to realloc()?
If you want to, you can of course use realloc(). However, realloc() is only guaranteed to
work on arrays allocated by malloc() (and similar functions) containing objects without user-
defined copy constructors. Also, please remember that contrary to naive
expectations, realloc() occasionally does copy its argument array.
In C++, a better way of dealing with reallocation is to use a standard library container, such
as vector, and let it grow naturally.
Do I need to check for null after p = new Fred()?
No! (But if you have an ancient, stone-age compiler, you may have to force the new operator
to throw an exception if it runs out of memory.)
It turns out to be a real pain to always write explicit nullptr tests after every new allocation. Code
like the following is very tedious:
1. Fred* p = new Fred();
2. if (nullptr == p) // Only needed if your compiler is from the Stone Age!
3. throw std::bad_alloc();
If your compiler doesn’t support (or if you refuse to use) exceptions, your code might be even more
tedious:
1. Fred* p = new Fred();
2. if (nullptr == p) { // Only needed if your compiler is from the Stone Age!
3. std::cerr << "Couldn't allocate memory for a Fred" << std::endl;
4. abort();
5. }
 Take heart. In C++, if the runtime system cannot allocate sizeof(Fred) bytes of memory
during p = new Fred(), a std::bad_alloc exception will be thrown.
Unlike malloc(), new never returns null!
Therefore you should simply write:
1. Fred * p = new Fred(); // No need to check if p is null
On the second thought. Scratch that. You should simply write:
1. auto p = make_unique<Fred>(); // No need to check if p is null
There, there… Much better now!
However, if your compiler is ancient, it may not yet support this. Find out by checking your
compiler’s documentation under “new”. If it is ancient, you may have to force the compiler to have
this behavior.
How can I convince my (older) compiler to automatically
check new to see if it returns null?
Eventually your compiler will.
If you have an old compiler that doesn’t automagically perform the null test, you can force the
runtime system to do the test by installing a “new handler” function. Your “new handler” function
can do anything you want, such as throw an exception, delete some objects and return (in which
case operator new will retry the allocation), print a message and abort() the program, etc.
Here’s a sample “new handler” that prints a message and throws an exception. The handler is
installed using std::set_new_handler():
1. #include <new> // To get std::set_new_handler
2. #include <cstdlib> // To get abort()
3. #include <iostream> // To get std::cerr
4.
5. class alloc_error : public std::exception {
6. public:
7. alloc_error() : exception() { }
8. };
9.
10. void myNewHandler()
11. {
12. // This is your own handler. It can do anything you want.
13. throw alloc_error();
14. }
15.
16. int main()
17. {
18. std::set_new_handler(myNewHandler); // Install your "new handler"
19. // ...
20. }
After the std::set_new_handler() line is executed, operator new will call
your myNewHandler() if/when it runs out of memory. This means that new will never return null:
1. Fred* p = new Fred(); // No need to check if p is null
Note: If your compiler doesn’t support exception handling, you can, as a last resort, change the
line throw …; to:
1. std::cerr << "Attempt to allocate memory failed!" << std::endl;
2. abort();
Note: If some namespace-scope / global / static object’s constructor uses new, it might not use
the myNewHandler() function since that constructor often gets called before main() begins.
 Unfortunately there’s no convenient way to guarantee that the std::set_new_handler() will be
called before the first use of new. For example, even if you put
the std::set_new_handler() call in the constructor of a global object, you still don’t know if
the module (“compilation unit”) that contains that global object will be elaborated first or last or
somewhere inbetween. Therefore you still don’t have any guarantee that your call
of std::set_new_handler() will happen before any other namespace-scope / global’s
constructor gets invoked.
Do I need to check for null before delete p?
No!
The C++ language guarantees that delete p will do nothing if p is null. Since you might get the
test backwards, and since most testing methodologies force you to explicitly test every branch point,
you should not put in the redundant if test.
Wrong:
1. if (p != nullptr) // or just "if (p)"
2. delete p;
Right:
1. delete p;

What are the two steps that happen when I say delete
p?
delete p is a two-step process: it calls the destructor, then releases the memory. The code
generated for delete p is functionally similar to this (assuming p is of type Fred*):
1. // Original code: delete p;
2. if (p) { // or "if (p != nullptr)"
3. p->~Fred();
4. operator delete(p);
5. }
The statement p->~Fred() calls the destructor for the Fred object pointed to by p.
The statement operator delete(p) calls the memory deallocation primitive, void operator
delete(void* p). This primitive is similar in spirit to free(void* p). (Note, however, that
these two are not interchangeable; e.g., there is no guarantee that the two memory deallocation
primitives even use the same heap!)
Why doesn’t delete null out its operand?
First, you should normally be using smart pointers, so you won’t care – you won’t be
writing delete anyway.
For those rare cases where you really are doing manual memory management and so do care,
consider:
1. delete p;
2. // ...
3. delete p;
If the ... part doesn’t touch p then the second delete p; is a serious error that a C++
implementation cannot effectively protect itself against (without unusual precautions). Since
deleting a null pointer is harmless by definition, a simple solution would be for delete p; to do
a p=nullptr; after it has done whatever else is required. However, C++ doesn’t guarantee that.
One reason is that the operand of delete need not be an lvalue. Consider:
1. delete p+1;
2. delete f(x);
 Here, the implementation of delete does not have a pointer to which it can null out. These
examples may be rare, but they do imply that it is not possible to guarantee that “any pointer to a
deleted object is null.” A simpler way of bypassing that “rule” is to have two pointers to an object:
1. T* p = new T;
2. T* q = p;
3. delete p;
4. delete q; // ouch!
C++ explicitly allows an implementation of delete to null out an lvalue operand, but that idea
doesn’t seem to have become popular with implementers.
If you consider zeroing out pointers important, consider using a destroy function:
1. template<class T> inline void destroy(T*& p) { delete p; p = 0; }
Consider this yet-another reason to minimize explicit use of new and delete by relying on
standard library smart pointers, containers, handles, etc.
Note that passing the pointer as a reference (to allow the pointer to be nulled out) has the added
benefit of preventing destroy() from being called for an rvalue:
1. int* f();
2. int* p;
3. // ...
4. destroy(f()); // error: trying to pass an rvalue by non-const reference
5. destroy(p+1); // error: trying to pass an rvalue by non-const reference

Why isn’t the destructor called at the end of scope?

The simple answer is “of course it is!”, but have a look at the kind of example that often accompany
that question:
1. void f()
2. {
3. X* p = new X;
4. // use p
5. }
That is, there was some (mistaken) assumption that the object created by new would be destroyed at
the end of a function.
Basically, you should only use heap allocation if you want an object to live beyond the lifetime of
the scope you create it in. Even then, you should normally use make_unique or make_shared. In
those rare cases where you do want heap allocation and you opt to use new, you need to
use delete to destroy the object. For example:
1. X* g(int i) { /* ... */ return new X(i); } // the X outlives the call of g()
2.
3. void h(int i)
4. {
5. X* p = g(i);
6. // ...
7. delete p; // caveat: not exception safe
8. }
If you want an object to live in a scope only, don’t use heap allocation at all but simply define a
variable:
1. {
2. ClassName x;
3. // use x
4. }
The variable is implicitly destroyed at the end of the scope.
 Code that creates an object using new and then deletes it at the end of the same scope is ugly,
error-prone, inefficient, and usually not exception-safe. For example:
1. void very_bad_func() // ugly, error-prone, and inefficient
2. {
3. X* p = new X;
4. // use p
5. delete p; // not exception-safe
6. }

In p = new Fred(), does the Fred memory “leak” if

the Fred constructor throws an exception?
No.
If an exception occurs during the Fred constructor of p = new Fred(), the C++ language
guarantees that the memory sizeof(Fred) bytes that were allocated will automagically be
released back to the heap.
Here are the details: new Fred() is a two-step process:
1. sizeof(Fred) bytes of memory are allocated using the primitive void* operator
new(size_t nbytes). This primitive is similar in spirit to malloc(size_t nbytes). (Note,
however, that these two are not interchangeable; e.g., there is no guarantee that the two memory
allocation primitives even use the same heap!).
2. It constructs an object in that memory by calling the Fred constructor. The pointer returned
from the first step is passed as the this parameter to the constructor. This step is wrapped in
a try … catch block to handle the case when an exception is thrown during this step.
Thus the actual generated code is functionally similar to:
1. // Original code: Fred* p = new Fred();
2. Fred* p;
3. void* tmp = operator new(sizeof(Fred));
4. try {
5. new(tmp) Fred(); // Placement new
6. p = (Fred*)tmp; // The pointer is assigned only if the ctor succeeds
7. }
8. catch (...) {
9. operator delete(tmp); // Deallocate the memory
10. throw; // Re-throw the exception
11. }
The statement marked “Placement new” calls the Fred constructor. The pointer p becomes
the this pointer inside the constructor, Fred::Fred().
How do I allocate / unallocate an array of things?
Use p = new T[n] and delete[] p:
1. Fred* p = new Fred[100];
2. // ...
3. delete[] p;
Any time you allocate an array of objects via new (usually with the [n] in the new expression),
you must use [] in the delete statement. This syntax is necessary because there is no syntactic
difference between a pointer to a thing and a pointer to an array of things (something we inherited
from C).
What if I forget the [] when deleteing an array allocated
via new T[n]?
All life comes to a catastrophic end.
 It is the programmer’s —not the compiler’s— responsibility to get the connection between new
T[n] and delete[] p correct. If you get it wrong, neither a compile-time nor a run-time error
message will be generated by the compiler. Heap corruption is a likely result. Or worse. Your
program will probably die.
Can I drop the [] when deleteing an array of some built-
in type (char, int, etc)?
No!
Sometimes programmers think that the [] in the delete[] p only exists so the compiler will call
the appropriate destructors for all elements in the array. Because of this reasoning, they assume that
an array of some built-in type such as char or int can be deleted without the []. E.g., they
assume the following is valid code:
1. void userCode(int n)
2. {
3. char* p = new char[n];
4. // ...
5. delete p; // ← ERROR! Should be delete[] p !
6. }
But the above code is wrong, and it can cause a disaster at runtime. In particular, the code that’s
called for delete p is operator delete(void*), but the code that’s called for delete[]
p is operator delete[](void*). The default behavior for the latter is to call the former, but
users are allowed to replace the latter with a different behavior (in which case they would normally
also replace the corresponding new code in operator new[](size_t)). If they replaced
the delete[] code so it wasn’t compatible with the delete code, and you called the wrong one
(i.e., if you said delete p rather than delete[] p), you could end up with a disaster at runtime.
After p = new Fred[n], how does the compiler know there
are n objects to be destructed during delete[] p?
Short answer: Magic.
Long answer: The run-time system stores the number of objects, n, somewhere where it can be
retrieved if you only know the pointer, p. There are two popular techniques that do this. Both these
techniques are in use by commercial-grade compilers, both have tradeoffs, and neither is perfect.
These techniques are:
 Over-allocate the array and put n just to the left of the first Fred object.
 Use an associative array with p as the key and n as the value.
Is it legal (and moral) for a member function to say delete
this?
As long as you’re careful, it’s okay (not evil) for an object to commit suicide (delete this).
Here’s how I define “careful”:
1. You must be absolutely 100% positively sure that this object was allocated via new (not
by new[], nor by placement new, nor a local object on the stack, nor a namespace-scope / global,
nor a member of another object; but by plain ordinary new).
2. You must be absolutely 100% positively sure that your member function will be the last
member function invoked on this object.
3. You must be absolutely 100% positively sure that the rest of your member function (after
the delete this line) doesn’t touch any piece of this object (including calling any other
member functions or touching any data members). This includes code that will run in destructors
for any objects allocated on the stack that are still alive.
 4. You must be absolutely 100% positively sure that no one even touches the this pointer
itself after the delete this line. In other words, you must not examine it, compare it with
another pointer, compare it with nullptr, print it, cast it, do anything with it.
Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when
you don’t have a virtual destructor.
How do I allocate multidimensional arrays using new?
There are many ways to do this, depending on how flexible you want the array sizing to be. On one
extreme, if you know all the dimensions at compile-time, you can allocate multidimensional arrays
statically (as in C):
1. class Fred { /*...*/ };
2. void someFunction(Fred& fred);
3.
4. void manipulateArray()
5. {
6. const unsigned nrows = 10; // Num rows is a compile-time constant
7. const unsigned ncols = 20; // Num columns is a compile-time constant
8. Fred matrix[nrows][ncols];
9.
10. for (unsigned i = 0; i < nrows; ++i) {
11. for (unsigned j = 0; j < ncols; ++j) {
12. // Here's the way you access the (i,j) element:
13. someFunction( matrix[i][j] );
14.
15. // You can safely "return" without any special delete code:
16. if (today == "Tuesday" && moon.isFull())
17. return; // Quit early on Tuesdays when the moon is full
18. }
19. }
20.
21. // No explicit delete code at the end of the function either
22. }
More commonly, the size of the matrix isn’t known until run-time but you know that it will be
rectangular. In this case you need to use the heap (“freestore”), but at least you are able to allocate
all the elements in one freestore chunk.
1. void manipulateArray(unsigned nrows, unsigned ncols)
2. {
3. Fred* matrix = new Fred[nrows * ncols];
4.
5. // Since we used a simple pointer above, we need to be VERY
6. // careful to avoid skipping over the delete code.
7. // That's why we catch all exceptions:
8. try {
9.
10. // Here's how to access the (i,j) element:
11. for (unsigned i = 0; i < nrows; ++i) {
12. for (unsigned j = 0; j < ncols; ++j) {
13. someFunction( matrix[i*ncols + j] );
14. }
15. }
16.
17. // If you want to quit early on Tuesdays when the moon is full,
18. // make sure to do the delete along ALL return paths:
19. if (today == "Tuesday" && moon.isFull()) {
20. delete[] matrix;
21. return;
22. }
23.
24. // ...code that fiddles with the matrix...
25.
26. }
27. catch (...) {
28. // Make sure to do the delete when an exception is thrown:
29. delete[] matrix;
30. throw; // Re-throw the current exception
31. }
32.
33. // Make sure to do the delete at the end of the function too:
34. delete[] matrix;
35. }
Finally at the other extreme, you may not even be guaranteed that the matrix is rectangular. For
example, if each row could have a different length, you’ll need to allocate each row individually. In
the following function, ncols[i] is the number of columns in row number i, where i varies
between 0 and nrows-1 inclusive.
1. void manipulateArray(unsigned nrows, unsigned ncols[])
2. {
3. typedef Fred* FredPtr;
4.
5. // There will not be a leak if the following throws an exception:
6. FredPtr* matrix = new FredPtr[nrows];
7.
8. // Set each element to null in case there is an exception later.
9. // (See comments at the top of the try block for rationale.)
10. for (unsigned i = 0; i < nrows; ++i)
11. matrix[i] = nullptr;
12.
13. // Since we used a simple pointer above, we need to be
14. // VERY careful to avoid skipping over the delete code.
15. // That's why we catch all exceptions:
16. try {
17.
18. // Next we populate the array. If one of these throws, all
19. // the allocated elements will be deleted (see catch below).
20. for (unsigned i = 0; i < nrows; ++i)
21. matrix[i] = new Fred[ ncols[i] ];
22.
23. // Here's how to access the (i,j) element:
24. for (unsigned i = 0; i < nrows; ++i) {
25. for (unsigned j = 0; j < ncols[i]; ++j) {
26. someFunction( matrix[i][j] );
27. }
28. }
29.
30. // If you want to quit early on Tuesdays when the moon is full,
31. // make sure to do the delete along ALL return paths:
32. if (today == "Tuesday" && moon.isFull()) {
33. for (unsigned i = nrows; i > 0; --i)
34. delete[] matrix[i-1];
35. delete[] matrix;
36. return;
37. }
38.
39. // ...code that fiddles with the matrix...
40.
41. }
42. catch (...) {
43. // Make sure to do the delete when an exception is thrown:
44. // Note that some of these matrix[...] pointers might be
45. // null, but that's okay since it's legal to delete null.
46. for (unsigned i = nrows; i > 0; --i)
47. delete[] matrix[i-1];
48. delete[] matrix;
49. throw; // Re-throw the current exception
50. }
51.
52. // Make sure to do the delete at the end of the function too.
53. // Note that deletion is the opposite order of allocation:
54. for (unsigned i = nrows; i > 0; --i)
55. delete[] matrix[i-1];
56. delete[] matrix;
57. }
Note the funny use of matrix[i-1] in the deletion process. This prevents wrap-around of
the unsigned value when i goes one step below zero.
Finally, note that pointers and arrays are evil. It is normally much better to encapsulate your pointers
in a class that has a safe and simple interface. The following FAQ shows how to do this.
But the previous FAQ’s code is SOOOO tricky and error
prone! Isn’t there a simpler way?
Yep.
The reason the code in the previous FAQ was so tricky and error prone was that it used pointers,
and we know that pointers and arrays are evil. The solution is to encapsulate your pointers in a class
that has a safe and simple interface. For example, we can define a Matrix class that handles a
rectangular matrix so our user code will be vastly simplified when compared to the the rectangular
matrix code from the previous FAQ:
1. // The code for class Matrix is shown below...
2. void someFunction(Fred& fred);
3.
4. void manipulateArray(unsigned nrows, unsigned ncols)
5. {
6. Matrix matrix(nrows, ncols); // Construct a Matrix called matrix
7.
8. for (unsigned i = 0; i < nrows; ++i) {
9. for (unsigned j = 0; j < ncols; ++j) {
10. // Here's the way you access the (i,j) element:
11. someFunction( matrix(i,j) );
12.
13. // You can safely "return" without any special delete code:
14. if (today == "Tuesday" && moon.isFull())
15. return; // Quit early on Tuesdays when the moon is full
16. }
17. }
18.
19. // No explicit delete code at the end of the function either
20. }
 The main thing to notice is the lack of clean-up code. For example, there aren’t
any delete statements in the above code, yet there will be no memory leaks, assuming only that
the Matrix destructor does its job correctly.
Here’s the Matrix code that makes the above possible:
1. class Matrix {
2. public:
3. Matrix(unsigned nrows, unsigned ncols);
4. // Throws a BadSize object if either size is zero
5. class BadSize { };
6.
7. // Based on the Law Of The Big Three:
8. ~Matrix();
9. Matrix(const Matrix& m);
10. Matrix& operator= (const Matrix& m);
11.
12. // Access methods to get the (i,j) element:
13. Fred& operator() (unsigned i, unsigned j); // Subscript operators often come in pairs
14. const Fred& operator() (unsigned i, unsigned j) const; // Subscript operators often come in pairs
15. // These throw a BoundsViolation object if i or j is too big
16. class BoundsViolation { };
17.
18. private:
19. unsigned nrows_, ncols_;
20. Fred* data_;
21. };
22.
23. inline Fred& Matrix::operator() (unsigned row, unsigned col)
24. {
25. if (row >= nrows_ || col >= ncols_) throw BoundsViolation();
26. return data_[row*ncols_ + col];
27. }
28.
29. inline const Fred& Matrix::operator() (unsigned row, unsigned col) const
30. {
31. if (row >= nrows_ || col >= ncols_) throw BoundsViolation();
32. return data_[row*ncols_ + col];
33. }
34.
35. Matrix::Matrix(unsigned nrows, unsigned ncols)
36. : nrows_ (nrows)
37. , ncols_ (ncols)
38. //, data_ ← initialized below after the if...throw statement
39. {
40. if (nrows == 0 || ncols == 0)
41. throw BadSize();
42. data_ = new Fred[nrows * ncols];
43. }
44.
45. Matrix::~Matrix()
46. {
47. delete[] data_;
48. }
Note that the above Matrix class accomplishes two things: it moves some tricky memory
management code from the user code (e.g., main()) to the class, and it reduces the overall bulk of
program. The latter point is important. For example, assuming Matrix is even mildly reusable,
moving complexity from the users [plural] of Matrix into Matrix itself [singular] is equivalent to
 moving complexity from the many to the few. Anyone who has seen Star Trek 2 knows that the good
of the many outweighs the good of the few… or the one.
But the above Matrix class is specific to Fred! Isn’t there
a way to make it generic?
Yep; just use templates:
Here’s how this can be used:
1. #include "Fred.h" // To get the definition for class Fred
2.
3. // The code for Matrix<T> is shown below...
4. void someFunction(Fred& fred);
5.
6. void manipulateArray(unsigned nrows, unsigned ncols)
7. {
8. Matrix<Fred> matrix(nrows, ncols); // Construct a Matrix<Fred> called matrix
9.
10. for (unsigned i = 0; i < nrows; ++i) {
11. for (unsigned j = 0; j < ncols; ++j) {
12. // Here's the way you access the (i,j) element:
13. someFunction( matrix(i,j) );
14.
15. // You can safely "return" without any special delete code:
16. if (today == "Tuesday" && moon.isFull())
17. return; // Quit early on Tuesdays when the moon is full
18. }
19. }
20.
21. // No explicit delete code at the end of the function either
22. }
Now it’s easy to use Matrix<T> for things other than Fred. For example, the following uses
a Matrix of std::string (where std::string is the standard string class):
1. #include <string>
2.
3. void someFunction(std::string& s);
4.
5. void manipulateArray(unsigned nrows, unsigned ncols)
6. {
7. Matrix<std::string> matrix(nrows, ncols); // Construct a Matrix<std::string>
8.
9. for (unsigned i = 0; i < nrows; ++i) {
10. for (unsigned j = 0; j < ncols; ++j) {
11. // Here's the way you access the (i,j) element:
12. someFunction( matrix(i,j) );
13.
14. // You can safely "return" without any special delete code:
15. if (today == "Tuesday" && moon.isFull())
16. return; // Quit early on Tuesdays when the moon is full
17. }
18. }
19.
20. // No explicit delete code at the end of the function either
21. }
You can thus get an entire family of classes from a template. For
example, Matrix<Fred>, Matrix<std::string>, Matrix< Matrix<std::string>>, etc.
Here’s one way that the template can be implemented:
1. template<typename T> // See section on templates for more
2. class Matrix {
3. public:
4. Matrix(unsigned nrows, unsigned ncols);
5. // Throws a BadSize object if either size is zero
6. class BadSize { };
7.
8. // Based on the Law Of The Big Three:
9. ~Matrix();
10. Matrix(const Matrix<T>& m);
11. Matrix<T>& operator= (const Matrix<T>& m);
12.
13. // Access methods to get the (i,j) element:
14. T& operator() (unsigned i, unsigned j); // Subscript operators often come in pairs
15. const T& operator() (unsigned i, unsigned j) const; // Subscript operators often come in pairs
16. // These throw a BoundsViolation object if i or j is too big
17. class BoundsViolation { };
18.
19. private:
20. unsigned nrows_, ncols_;
21. T* data_;
22. };
23.
24. template<typename T>
25. inline T& Matrix<T>::operator() (unsigned row, unsigned col)
26. {
27. if (row >= nrows_ || col >= ncols_) throw BoundsViolation();
28. return data_[row*ncols_ + col];
29. }
30.
31. template<typename T>
32. inline const T& Matrix<T>::operator() (unsigned row, unsigned col) const
33. {
34. if (row >= nrows_ || col >= ncols_)
35. throw BoundsViolation();
36. return data_[row*ncols_ + col];
37. }
38.
39. template<typename T>
40. inline Matrix<T>::Matrix(unsigned nrows, unsigned ncols)
41. : nrows_ (nrows)
42. , ncols_ (ncols)
43. //, data_ ← initialized below after the if...throw statement
44. {
45. if (nrows == 0 || ncols == 0)
46. throw BadSize();
47. data_ = new T[nrows * ncols];
48. }
49.
50. template<typename T>
51. inline Matrix<T>::~Matrix()
52. {
53. delete[] data_;
54. }

What’s another way to build a Matrix template?

Use the standard vector template, and make a vector of vector.
 The following uses a std::vector<std::vector<T>>.
1. #include <vector>
2.
3. template<typename T> // See section on templates for more
4. class Matrix {
5. public:
6. Matrix(unsigned nrows, unsigned ncols);
7. // Throws a BadSize object if either size is zero
8. class BadSize { };
9.
10. // No need for any of The Big Three!
11.
12. // Access methods to get the (i,j) element:
13. T& operator() (unsigned i, unsigned j); // Subscript operators often come in pairs
14. const T& operator() (unsigned i, unsigned j) const; // Subscript operators often come in pairs
15. // These throw a BoundsViolation object if i or j is too big
16. class BoundsViolation { };
17.
18. unsigned nrows() const; // #rows in this matrix
19. unsigned ncols() const; // #columns in this matrix
20.
21. private:
22. std::vector<std::vector<T>> data_;
23. };
24.
25. template<typename T>
26. inline unsigned Matrix<T>::nrows() const
27. { return data_.size(); }
28.
29. template<typename T>
30. inline unsigned Matrix<T>::ncols() const
31. { return data_[0].size(); }
32.
33. template<typename T>
34. inline T& Matrix<T>::operator() (unsigned row, unsigned col)
35. {
36. if (row >= nrows() || col >= ncols()) throw BoundsViolation();
37. return data_[row][col];
38. }
39.
40. template<typename T>
41. inline const T& Matrix<T>::operator() (unsigned row, unsigned col) const
42. {
43. if (row >= nrows() || col >= ncols()) throw BoundsViolation();
44. return data_[row][col];
45. }
46.
47. template<typename T>
48. Matrix<T>::Matrix(unsigned nrows, unsigned ncols)
49. : data_ (nrows)
50. {
51. if (nrows == 0 || ncols == 0)
52. throw BadSize();
53. for (unsigned i = 0; i < nrows; ++i)
54. data_[i].resize(ncols);
55. }
 Note how much simpler this is than the previous: there is no explicit new in the constructor, and
there is no need for any of The Big Three (destructor, copy constructor or assignment operator).
Simply put, your code is a lot less likely to have memory leaks if you use std::vector than if you
use explicit new T[n] and delete[] p.
Note also that std::vector doesn’t force you to allocate numerous chunks of memory. If you
prefer to allocate only one chunk of memory for the entire matrix, as was done in the previous, just
change the type of data_ to std::vector<T> and add member variables nrows_ and ncols_.
You’ll figure out the rest: initialize data_ using data_(nrows * ncols), change operator()
() to return data_[row*ncols_ + col];, etc.
Does C++ have arrays whose length can be specified at
run-time?
Yes, in the sense that the standard library has a std::vector template that provides this behavior.
No, in the sense that built-in array types need to have their length specified at compile time.
Yes, in the sense that even built-in array types can specify the first index bounds at run-time. E.g.,
comparing with the previous FAQ, if you only need the first array dimension to vary then you can
just ask new for an array of arrays, rather than an array of pointers to arrays:
1. const unsigned ncols = 100; // ncols = number of columns in the array
2.
3. class Fred { /*...*/ };
4.
5. void manipulateArray(unsigned nrows) // nrows = number of rows in the array
6. {
7. Fred (*matrix)[ncols] = new Fred[nrows][ncols];
8. // ...
9. delete[] matrix;
10. }
You can’t do this if you need anything other than the first dimension of the array to change at run-
time.
But please, don’t use arrays unless you have to. Arrays are evil. Use some object of some class if
you can. Use arrays only when you have to.
How can I force objects of my class to always be created
via new rather than as local, namespace-scope, global,
or static?
Use the Named Constructor Idiom.
As usual with the Named Constructor Idiom, the constructors are all private or protected, and
there are one or more public static create() methods (the so-called “named constructors”),
one per constructor. In this case the create() methods allocate the objects via new. Since the
constructors themselves are not public, there is no other way to create objects of the class.
1. class Fred {
2. public:
3. // The create() methods are the "named constructors":
4. static Fred* create() { return new Fred(); }
5. static Fred* create(int i) { return new Fred(i); }
6. static Fred* create(const Fred& fred) { return new Fred(fred); }
7. // ...
8.
9. private:
10. // The constructors themselves are private or protected:
11. Fred();
12. Fred(int i);
13. Fred(const Fred& fred);
14. // ...
15. };
Now the only way to create Fred objects is via Fred::create():
1. int main()
2. {
3. Fred* p = Fred::create(5);
4. // ...
5. delete p;
6. // ...
7. }
Make sure your constructors are in the protected section if you expect Fred to have derived
classes.
Note also that you can make another class Wilma a friend of Fred if you want to allow
a Wilma to have a member object of class Fred, but of course this is a softening of the original
goal, namely to force Fred objects to be allocated via new.
How do I do simple reference counting?
If all you want is the ability to pass around a bunch of pointers to the same object, with the feature
that the object will automagically get deleted when the last pointer to it disappears, you can use
something like the following “smart pointer” class:
1. // Fred.h
2.
3. class FredPtr;
4.
5. class Fred {
6. public:
7. Fred() : count_(0) /*...*/ { } // All ctors set count_ to 0 !
8. // ...
9. private:
10. friend class FredPtr; // A friend class
11. unsigned count_;
12. // count_ must be initialized to 0 by all constructors
13. // count_ is the number of FredPtr objects that point at this
14. };
15.
16. class FredPtr {
17. public:
18. Fred* operator-> () { return p_; }
19. Fred& operator* () { return *p_; }
20. FredPtr(Fred* p) : p_(p) { ++p_->count_; } // p must not be null
21. ~FredPtr() { if (--p_->count_ == 0) delete p_; }
22. FredPtr(const FredPtr& p) : p_(p.p_) { ++p_->count_; }
23. FredPtr& operator= (const FredPtr& p)
24. { // DO NOT CHANGE THE ORDER OF THESE STATEMENTS!
25. // (This order properly handles self-assignment)
26. // (This order also properly handles recursion, e.g., if a Fred contains FredPtrs)
27. Fred* const old = p_;
28. p_ = p.p_;
29. ++p_->count_;
30. if (--old->count_ == 0) delete old;
31. return *this;
32. }
33. private:
34. Fred* p_; // p_ is never NULL
35. };
Naturally you can use nested classes to rename FredPtr to Fred::Ptr.
Note that you can soften the “never NULL” rule above with a little more checking in the constructor,
copy constructor, assignment operator, and destructor. If you do that, you might as well put a p_ !=
NULL check into the “*” and “->” operators (at least as an assert()). I would recommend against
an operator Fred*() method, since that would let people accidentally get at the Fred*.
One of the implicit constraints on FredPtr is that it must only point to Fred objects which have
been allocated via new. If you want to be really safe, you can enforce this constraint by making all
of Fred’s constructors private, and for each constructor have
a public (static) create() method which allocates the Fred object via new and returns
a FredPtr (not a Fred*). That way the only way anyone could create a Fred object would be to
get a FredPtr (“Fred* p = new Fred()” would be replaced by “FredPtr p =
Fred::create()”). Thus no one could accidentally subvert the reference counting mechanism.
For example, if Fred had a Fred::Fred() and a Fred::Fred(int i, int j), the changes
to class Fred would be:
1. class Fred {
2. public:
3. static FredPtr create(); // Defined below class FredPtr {...};
4. static FredPtr create(int i, int j); // Defined below class FredPtr {...};
5. // ...
6. private:
7. Fred();
8. Fred(int i, int j);
9. // ...
10. };
11.
12. class FredPtr { /* ... */ };
13.
14. inline FredPtr Fred::create() { return new Fred(); }
15. inline FredPtr Fred::create(int i, int j) { return new Fred(i,j); }
The end result is that you now have a way to use simple reference counting to provide “pointer
semantics” for a given object. Users of your Fred class explicitly use FredPtr objects, which act
more or less like Fred* pointers. The benefit is that users can make as many copies of
their FredPtr “smart pointer” objects, and the pointed-to Fred object will automagically
get deleted when the last such FredPtr object vanishes.
If you’d rather give your users “reference semantics” rather than “pointer semantics,” you can
use reference counting to provide “copy on write”.
How do I provide reference counting with copy-on-write
semantics?
Reference counting can be done with either pointer semantics or reference semantics. The previous
FAQ shows how to do reference counting with pointer semantics. This FAQ shows how to do
reference counting with reference semantics.
The basic idea is to allow users to think they’re copying your Fred objects, but in reality the
underlying implementation doesn’t actually do any copying unless and until some user actually tries
to modify the underlying Fred object.
Class Fred::Data houses all the data that would normally go into
the Fred class. Fred::Data also has an extra data member, count_, to manage the reference
counting. Class Fred ends up being a “smart reference” that (internally) points to a Fred::Data.
1. class Fred {
2. public:
3.
4. Fred(); // A default constructor
5. Fred(int i, int j); // A normal constructor
6.
7. Fred(const Fred& f);
8. Fred& operator= (const Fred& f);
9. ~Fred();
10.
11. void sampleInspectorMethod() const; // No changes to this object
12. void sampleMutatorMethod(); // Change this object
13.
14. // ...
15.
16. private:
17.
18. class Data {
19. public:
20. Data();
21. Data(int i, int j);
22. Data(const Data& d);
23.
24. // Since only Fred can access a Fred::Data object,
25. // you can make Fred::Data's data public if you want.
26. // But if that makes you uncomfortable, make the data private
27. // and make Fred a friend class via friend class Fred;
28.
29. // ...your data members are declared here...
30.
31. unsigned count_;
32. // count_ is the number of Fred objects that point at this
33. // count_ must be initialized to 1 by all constructors
34. // (it starts as 1 since it is pointed to by the Fred object that created it)
35. };
36.
37. Data* data_;
38. };
39.
40. Fred::Data::Data() : count_(1) /*init other data*/ { }
41. Fred::Data::Data(int i, int j) : count_(1) /*init other data*/ { }
42. Fred::Data::Data(const Data& d) : count_(1) /*init other data*/ { }
43.
44. Fred::Fred() : data_(new Data()) { }
45. Fred::Fred(int i, int j) : data_(new Data(i, j)) { }
46.
47. Fred::Fred(const Fred& f)
48. : data_(f.data_)
49. {
50. ++data_->count_;
51. }
52.
53. Fred& Fred::operator= (const Fred& f)
54. {
55. // DO NOT CHANGE THE ORDER OF THESE STATEMENTS!
56. // (This order properly handles self-assignment)
57. // (This order also properly handles recursion, e.g., if a Fred::Data contains Freds)
58. Data* const old = data_;
59. data_ = f.data_;
60. ++data_->count_;
61. if (--old->count_ == 0) delete old;
62. return *this;
63. }
64.
65. Fred::~Fred()
66. {
67. if (--data_->count_ == 0) delete data_;
68. }
69.
70. void Fred::sampleInspectorMethod() const
71. {
72. // This method promises ("const") not to change anything in *data_
73. // Other than that, any data access would simply use "data_->..."
74. }
75.
76. void Fred::sampleMutatorMethod()
77. {
78. // This method might need to change things in *data_
79. // Thus it first checks if this is the only pointer to *data_
80. if (data_->count_ > 1) {
81. Data* d = new Data(*data_); // Invoke Fred::Data's copy ctor
82. --data_->count_;
83. data_ = d;
84. }
85. assert(data_->count_ == 1);
86.
87. // Now the method proceeds to access "data_->..." as normal
88. }
If it is fairly common to call Fred’s default constructor, you can avoid all those new calls by
sharing a common Fred::Data object for all Freds that are constructed via Fred::Fred(). To
avoid static initialization order problems, this shared Fred::Data object is created “on first
use” inside a function. Here are the changes that would be made to the above code (note that the
shared Fred::Data object’s destructor is never invoked; if that is a problem, either hope you don’t
have any static initialization order problems, or drop back to the approach described above):
1. class Fred {
2. public:
3. // ...
4. private:
5. // ...
6. static Data* defaultData();
7. };
8.
9. Fred::Fred()
10. : data_(defaultData())
11. {
12. ++data_->count_;
13. }
14.
15. Fred::Data* Fred::defaultData()
16. {
17. static Data* p = nullptr;
18. if (p == nullptr) {
19. p = new Data();
20. ++p->count_; // Make sure it never goes to zero
21. }
22. return p;
23. }
 Note: You can also provide reference counting for a hierarchy of classes if your Fred class would
normally have been a base class.
How do I provide reference counting with copy-on-write
semantics for a hierarchy of classes?
The previous FAQ presented a reference counting scheme that provided users with reference
semantics, but did so for a single class rather than for a hierarchy of classes. This FAQ extends the
previous technique to allow for a hierarchy of classes. The basic difference is that Fred::Data is
now the root of a hierarchy of classes, which probably cause it to have some virtual functions.
Note that class Fred itself will still not have any virtual functions.
The Virtual Constructor Idiom is used to make copies of the Fred::Data objects. To select which
derived class to create, the sample code below uses the Named Constructor Idiom, but other
techniques are possible (a switch statement in the constructor, etc). The sample code assumes two
derived classes: Der1 and Der2. Methods in the derived classes are unaware of the reference
counting.
1. class Fred {
2. public:
3.
4. static Fred create1(const std::string& s, int i);
5. static Fred create2(float x, float y);
6.
7. Fred(const Fred& f);
8. Fred& operator= (const Fred& f);
9. ~Fred();
10.
11. void sampleInspectorMethod() const; // No changes to this object
12. void sampleMutatorMethod(); // Change this object
13.
14. // ...
15.
16. private:
17.
18. class Data {
19. public:
20. Data() : count_(1) { }
21. Data(const Data& d) : count_(1) { } // Do NOT copy the 'count_' member!
22. Data& operator= (const Data&) { return *this; } // Do NOT copy the 'count_' member!
23. virtual ~Data() { assert(count_ == 0); } // A virtual destructor
24. virtual Data* clone() const = 0; // A virtual constructor
25. virtual void sampleInspectorMethod() const = 0; // A pure virtual function
26. virtual void sampleMutatorMethod() = 0;
27. private:
28. unsigned count_; // count_ doesn't need to be protected
29. friend class Fred; // Allow Fred to access count_
30. };
31.
32. class Der1 : public Data {
33. public:
34. Der1(const std::string& s, int i);
35. virtual void sampleInspectorMethod() const;
36. virtual void sampleMutatorMethod();
37. virtual Data* clone() const;
38. // ...
39. };
40.
41. class Der2 : public Data {
42. public:
43. Der2(float x, float y);
44. virtual void sampleInspectorMethod() const;
45. virtual void sampleMutatorMethod();
46. virtual Data* clone() const;
47. // ...
48. };
49.
50. Fred(Data* data);
51. // Creates a Fred smart-reference that owns *data
52. // It is private to force users to use a createXXX() method
53. // Requirement: data must not be NULL
54.
55. Data* data_; // Invariant: data_ is never NULL
56. };
57.
58. Fred::Fred(Data* data) : data_(data) { assert(data != nullptr); }
59.
60. Fred Fred::create1(const std::string& s, int i) { return Fred(new Der1(s, i)); }
61. Fred Fred::create2(float x, float y) { return Fred(new Der2(x, y)); }
62.
63. Fred::Data* Fred::Der1::clone() const { return new Der1(*this); }
64. Fred::Data* Fred::Der2::clone() const { return new Der2(*this); }
65.
66. Fred::Fred(const Fred& f)
67. : data_(f.data_)
68. {
69. ++data_->count_;
70. }
71.
72. Fred& Fred::operator= (const Fred& f)
73. {
74. // DO NOT CHANGE THE ORDER OF THESE STATEMENTS!
75. // (This order properly handles self-assignment)
76. // (This order also properly handles recursion, e.g., if a Fred::Data contains Freds)
77. Data* const old = data_;
78. data_ = f.data_;
79. ++data_->count_;
80. if (--old->count_ == 0) delete old;
81. return *this;
82. }
83.
84. Fred::~Fred()
85. {
86. if (--data_->count_ == 0) delete data_;
87. }
88.
89. void Fred::sampleInspectorMethod() const
90. {
91. // This method promises ("const") not to change anything in *data_
92. // Therefore we simply "pass the method through" to *data_:
93. data_->sampleInspectorMethod();
94. }
95.
96. void Fred::sampleMutatorMethod()
97. {
98. // This method might need to change things in *data_
99. // Thus it first checks if this is the only pointer to *data_
100. if (data_->count_ > 1) {
101. Data* d = data_->clone(); // The Virtual Constructor Idiom
102. --data_->count_;
103. data_ = d;
104. }
105. assert(data_->count_ == 1);
106.
107. // Now we "pass the method through" to *data_:
108. data_->sampleMutatorMethod();
109. }
Naturally the constructors and sampleXXX methods for Fred::Der1 and Fred::Der2 will need
to be implemented in whatever way is appropriate.
Can I absolutely prevent people from subverting the
reference counting mechanism, and if so, should I?
No, and (normally) no.
There are two basic approaches to subverting the reference counting mechanism:
1. The scheme could be subverted if someone got a Fred* (rather than being forced to use
a FredPtr). Someone could get a Fred* if class FredPtr has an operator*() that returns
a Fred&: FredPtr p = Fred::create(); Fred* p2 = &*p;. Yes it’s bizarre and
unexpected, but it could happen. This hole could be closed in two ways:
overload Fred::operator&() so it returns a FredPtr, or change the return type
of FredPtr::operator*() so it returns a FredRef (FredRef would be a class that simulates
a reference; it would need to have all the methods that Fred has, and it would need to forward all
those method calls to the underlying Fred object; there might be a performance penalty for this
second choice depending on how good the compiler is at inlining methods). Another way to fix
this is to eliminate FredPtr::operator*() — and lose the corresponding ability to get and
use a Fred&. But even if you did all this, someone could still generate a Fred* by explicitly
calling operator->(): FredPtr p = Fred::create(); Fred* p2 = p.operator-
>();.
2. The scheme could be subverted if someone had a leak and/or dangling pointer to a FredPtr.
Basically what we’re saying here is that Fred is now safe, but we somehow want to prevent
people from doing stupid things with FredPtr objects. (And if we could solve that
via FredPtrPtr objects, we’d have the same problem again with them). One hole here is if
someone created a FredPtr using new, then allowed the FredPtr to leak (worst case this is a
leak, which is bad but is usually a little better than a dangling pointer). This hole could be plugged
by declaring FredPtr::operator new() as private, thus preventing someone from
saying new FredPtr(). Another hole here is if someone creates a local FredPtr object, then
takes the address of that FredPtr and passed around the FredPtr*. If that FredPtr* lived
longer than the FredPtr, you could have a dangling pointer — shudder. This hole could be
plugged by preventing people from taking the address of a FredPtr (by
overloading FredPtr::operator&() as private), with the corresponding loss of
functionality. But even if you did all that, they could still create a FredPtr& which is almost as
dangerous as a FredPtr*, simply by doing this: FredPtr p; ... FredPtr& q = p; (or by
passing the FredPtr& to someone else).
And even if we closed all those holes, C++ has those wonderful pieces of syntax called pointer
casts. Using a pointer cast or two, a sufficiently motivated programmer can normally create a hole
that’s big enough to drive a proverbial truck through. (By the way, pointer casts are evil.)
 So the lessons here seem to be: (a) you can’t prevent espionage no matter how hard you try, and (b)
you can easily prevent mistakes.
So I recommend settling for the “low hanging fruit”: use the easy-to-build and easy-to-use
mechanisms that prevent mistakes, and don’t bother trying to prevent espionage. You won’t
succeed, and even if you do, it’ll (probably) cost you more than it’s worth.
So if we can’t use the C++ language itself to prevent espionage, are there other ways to do it? Yes. I
personally use old fashioned code reviews for that. And since the espionage techniques usually
involve some bizarre syntax and/or use of pointer-casts and unions, you can use a tool to point out
most of the “hot spots.”

Can I use a garbage collector in C++?

Yes.
If you want automatic garbage collection, there are good commercial and public-domain garbage
collectors for C++. For applications where garbage collection is suitable, C++ is an excellent
garbage collected language with a performance that compares favorably with other garbage
collected languages. See The C++ Programming Language (4th Edition) for a discussion of
automatic garbage collection in C++. See also, Hans-J. Boehm’s site for C and C++ garbage
collection.
Also, C++ supports programming techniques that allows memory management to be safe and
implicit without a garbage collector. Garbage collection is useful for specific needs, such as inside
the implementation of lock-free data structures to avoid ABA issues, but not as a general-purpose
default way of handling for resource management. We are not saying that GC is not useful, just that
there are better approaches in many situations.
C++11 offers a GC ABI.
Compared with the “smart pointer” techniques, the two kinds of garbage collector techniques are:
 less portable
 usually more efficient (especially when the average object size is small or in multithreaded
environments)
 able to handle “cycles” in the data (reference counting techniques normally “leak” if the data
structures can form a cycle)
 sometimes leak other objects (since the garbage collectors are necessarily conservative, they
sometimes see a random bit pattern that appears to be a pointer into an allocation, especially if the
allocation is large; this can allow the allocation to leak)
 work better with existing libraries (since smart pointers need to be used explicitly, they may
be hard to integrate with existing libraries)
What are the two kinds of garbage collectors for C++?
In general, there seem to be two flavors of garbage collectors for C++:
1. Conservative garbage collectors. These know little or nothing about the layout of the stack or
of C++ objects, and simply look for bit patterns that appear to be pointers. In practice they seem
to work with both C and C++ code, particularly when the average object size is small. Here are
some examples, in alphabetical order:
 Boehm-Demers-Weiser collector
 Geodesic Systems collector
2. Hybrid garbage collectors. These usually scan the stack conservatively, but require the
programmer to supply layout information for heap objects. This requires more work on the
programmer’s part, but may result in improved performance. Here are some examples, in
alphabetical order:
  Attardi and Flagella’s CMM
 Bartlett’s mostly copying collector
Since garbage collectors for C++ are normally conservative, they can sometimes leak if a bit pattern
“looks like” it might be a pointer to an otherwise unused block. Also they sometimes get confused
when pointers to a block actually point outside the block’s extent (which is illegal, but some
programmers simply must push the envelope; sigh) and (rarely) when a pointer is hidden by a
compiler optimization. In practice these problems are not usually serious, however providing the
collector with hints about the layout of the objects can sometimes ameliorate these issues.
Where can I get more info on garbage collectors for C+
+?
For more information, see the Garbage Collector FAQ.
What is an auto_ptr and why isn’t there an auto_array?
It’s now spelled unique_ptr, which supports both single objects and arrays.
auto_ptr is an old standard smart pointer that has been deprecated, and is only being kept in the
standard for backward compatibility with older code. It should not be used in new code.

Classes and Objects

Save to:
InstapaperPocketReadability
Contents of this section:

 What is a class?
 What is an object?
 When is an interface “good”?
 What is encapsulation?
 How does C++ help with the tradeoff of safety vs. usability?
 How can I prevent other programmers from violating encapsulation by seeing
the private parts of my class?
 Can a method directly access the non-public members of another instance of its class?
 Is Encapsulation a Security device?
 What’s the difference between the keywords struct and class?
 How do I define an in-class constant?
 Why do I have to put the data in my class declarations?
 How are C++ objects laid out in memory?
 Why is the size of an empty class not zero?
What is a class?
The fundamental building block of OO software.
A class defines a data type, much like a struct would be in C. In a computer science sense, a
type consists of both a set of states and a set of operations which transition between those states.
Thus int is a type because it has both a set of states and it has operations like i + j or i++, etc. In
exactly the same way, a class provides a set of (usually public) operations, and a set of (usually
non-public) data bits representing the abstract values that instances of the type can have.
You can imagine that int is a class that has member functions called operator++, etc.
(int isn’t really a class, but the basic analogy is this: a class is a type, much like int is a type.)
Note: a C programmer can think of a class as a C struct whose members default to private.
But if that’s all you think of a class, then you probably need to experience a personal paradigm
shift.
What is an object?
A region of storage with associated semantics.
After the declaration int i; we say that “i is an object of type int.” In OO/C++, “object” usually
means “an instance of a class.” Thus a class defines the behavior of possibly many objects
(instances).
When is an interface “good”?
When it provides a simplified view of a chunk of software, and it is expressed in the vocabulary of a
user (where a “chunk” is normally a class or a tight group of classes, and a “user” is another
developer rather than the ultimate customer).
 The “simplified view” means unnecessary details are intentionally hidden. This reduces the
user’s defect-rate.
 The “vocabulary of users” means users don’t need to learn a new set of words and concepts.
This reduces the user’s learning curve.
What is encapsulation?
Preventing unauthorized access to some piece of information or functionality.
The key money-saving insight is to separate the volatile part of some chunk of software from the
stable part. Encapsulation puts a firewall around the chunk, which prevents other chunks from
accessing the volatile parts; other chunks can only access the stable parts. This prevents the other
chunks from breaking if (when!) the volatile parts are changed. In context of OO software, a
“chunk” is normally a class or a tight group of classes.
The “volatile parts” are the implementation details. If the chunk is a single class, the volatile part is
normally encapsulated using the private and/or protected keywords. If the chunk is a tight
group of classes, encapsulation can be used to deny access to entire classes in that
group. Inheritance can also be used as a form of encapsulation.
The “stable parts” are the interfaces. A good interface provides a simplified view in the vocabulary
of a user, and is designed from the outside-in (here a “user” means another developer, not the end-
user who buys the completed application). If the chunk is a single class, the interface is simply the
class’s public member functions and friend functions. If the chunk is a tight group of classes,
the interface can include several of the classes in the chunk.
Designing a clean interface and separating that interface from its
implementation merely allows users to use the interface. But encapsulating (putting “in a capsule”)
the implementation forces users to use the interface.
How does C++ help with the tradeoff of safety vs.
usability?
In C, encapsulation was accomplished by making things static in a compilation unit or module.
This prevented another module from accessing the static stuff. (By the way, static data at file-
scope is now deprecated in C++: don’t do that.)
Unfortunately this approach doesn’t support multiple instances of the data, since there is no direct
support for making multiple instances of a module’s static data. If multiple instances were
needed in C, programmers typically used a struct. But unfortunately C structs don’t
support encapsulation. This exacerbates the tradeoff between safety (information hiding) and
usability (multiple instances).
In C++, you can have both multiple instances and encapsulation via a class. The public part of a
class contains the class’s interface, which normally consists of the class’s public member
 functions and its friend functions. The private and/or protected parts of a class contain the
class’s implementation, which is typically where the data lives.
The end result is like an “encapsulated struct.” This reduces the tradeoff between safety
(information hiding) and usability (multiple instances).
How can I prevent other programmers from violating
encapsulation by seeing the private parts of my class?
Not worth the effort — encapsulation is for code, not people.
It doesn’t violate encapsulation for a programmer to see the private and/or protected parts of
your class, so long as they don’t write code that somehow depends on what they saw. In other
words, encapsulation doesn’t prevent people from knowing about the inside of a class; it prevents
the code they write from becoming dependent on the insides of the class. Your company doesn’t
have to pay a “maintenance cost” to maintain the gray matter between your ears; but it does have to
pay a maintenance cost to maintain the code that comes out of your finger tips. What you know as a
person doesn’t increase maintenance cost, provided the code you write depends on the interface
rather than the implementation.
Besides, this is rarely if ever a problem. I don’t know any programmers who have intentionally tried
to access the private parts of a class. “My recommendation in such cases would be to change the
programmer, not the code” [James Kanze; used with permission].
Can a method directly access the non-public members of
another instance of its class?
Yes.
The name this is not special. Access is granted or denied based on the class of the
reference/pointer/object, not based on the name of the reference/pointer/object. (See below for the
fine print.)
The fact that C++ allows a class’ methods and friends to access the non-public parts of all its
objects, not just the this object, seems at first to weaken encapsulation. However the opposite is
true: this rule preserves encapsulation. Here’s why.
Without this rule, most non-public members would need a public get method, because many
classes have at least one method or friend that takes an explicit argument (i.e., an argument not
called this) of its own class.
Huh? (you ask). Let’s kill the mumbo jumbo and work out an example:
Consider assignment operator Foo::operator=(const Foo& x). This assignment operator will
probably change the data members in the left-hand argument, *this, based on the data members in
the right-hand argument, x. Without the C++ rule being discussed here, the only way for that
assignment operator to access the non-public members of x would be for class Foo to provide
a public get method for every non-public datum. That would suck bigtime. (NB: “suck bigtime”
is a precise, sophisticated, technical term; and I am writing this on April 1.)
The assignment operator isn’t the only one that would weaken encapsulation were it not for this
rule. Here is a partial(!) list of others:
 Copy constructor.
 Comparison operators: ==, !=, <=, <, >=, >.
 Binary arithmetic operators: x+y, x-y, x*y, x/y, x%y.
 Binary bitwise operators: x^y, x&y, x|y.
 Static methods that accepts an instance of the class as a parameter.
 Static methods that creates/manipulates an instance of the class.
  etc.
Conclusion: encapsulation would be shredded without this beneficial rule: most non-
public members of most classes would end up having a public get method.
The Fine Print: There is another rule that is related to the above: methods and friends of a derived
class can access the protected base class members of any of its own objects (any objects of its
class or any derived class of its class), but not others. Since that is hopelessly opaque, here’s an
example: suppose classes D1 and D2 inherit directly from class B, and base
class B has protected member x. The compiler will let D1’s members and friends directly access
the x member of any object it knows to be at least a D1, such as via a D1* pointer, a D1& reference,
a D1 object, etc. However the compiler will give a compile-time error if a D1 member or friend tries
to directly access the x member of anything it does not know is at least a D1, such as via
a B* pointer, a B& reference, a B object, a D2* pointer, a D2& reference, a D2 object, etc. By way of
(imperfect!!) analogy, you are allowed to pick your own pockets, but you are not allowed to pick
your father’s pockets nor your brother’s pockets.
Is Encapsulation a Security device?
No.
Encapsulation != security.
Encapsulation prevents mistakes, not espionage.

What’s the difference between the

keywords struct and class?
The members and base classes of a struct are public by default, while in class, they default
to private. Note: you should make your base classes explicitly public, private,
or protected, rather than relying on the defaults.
struct and class are otherwise functionally equivalent.
Enough of that squeaky clean techno talk. Emotionally, most developers make a strong distinction
between a class and a struct. A struct simply feels like an open pile of bits with very little in
the way of encapsulation or functionality. A class feels like a living and responsible member of
society with intelligent services, a strong encapsulation barrier, and a well defined interface. Since
that’s the connotation most people already have, you should probably use the struct keyword if
you have a class that has very few methods and has public data (such things do exist in well
designed systems!), but otherwise you should probably use the class keyword.
How do I define an in-class constant?
If you want a constant that you can use in a compile time constant expression, say as an array
bound, use constexpr if your compiler supports that C++11 feature, otherwise you have two other
choices:
1. class X {
2. constexpr int c1 = 42; // preferred
3. static const int c2 = 7;
4. enum { c3 = 19 };
5.
6. array<char,c1> v1;
7. array<char,c2> v2;
8. array<char,c3> v3;
9.
10. // ...
11. };
You have more flexibility if the constant isn’t needed for use in a compile time constant expression:
1. class Z {
2. static char* p; // initialize in definition
3. const int i; // initialize in constructor
4. public:
5. Z(int ii) :i(ii) { }
6. };
7.
8. char* Z::p = "hello, there";
You can bind a reference to a static data member, or take its address, if (and only if) it has an out-of-
class definition:
1. class AE {
2. // ...
3. public:
4. static const int c6 = 7;
5. static const int c7 = 31;
6. };
7.
8. const int AE::c7; // definition
9.
10. void byref(const int&);
11.
12. int f()
13. {
14. byref(AE::c6); // error: c6 not an lvalue
15. byref(AE::c7); // ok
16. const int* p1 = &AE::c6; // error: c6 not an lvalue
17. const int* p2 = &AE::c7; // ok
18. // ...
19. }

Why do I have to put the data in my class declarations?

You don’t. If you don’t want data in an interface, don’t put it in the class that defines the interface.
Put it in derived classes instead. See, Why do my compiles take so long?.
Sometimes, you do want to have representation data in a class. Consider class complex:
1. template<class Scalar> class complex {
2. public:
3. complex() : re(0), im(0) { }
4. complex(Scalar r) : re(r), im(0) { }
5. complex(Scalar r, Scalar i) : re(r), im(i) { }
6. // ...
7.
8. complex& operator+=(const complex& a)
9. { re+=a.re; im+=a.im; return *this; }
10. // ...
11. private:
12. Scalar re, im;
13. };
This type is designed to be used much as a built-in type and the representation is needed in the
declaration to make it possible to create genuinely local objects (i.e. objects that are allocated on the
stack and not on a heap) and to ensure proper inlining of simple operations. Genuinely local objects
and inlining is necessary to get the performance of complex close to what is provided in languages
with a built-in complex type.

How are C++ objects laid out in memory?

 Like C, C++ doesn’t define layouts, just semantic constraints that must be met. Therefore different
implementations do things differently. One good explanation is in a book that is otherwise outdated
and doesn’t describe any current C++ implementation: The Annotated C++ Reference
Manual (usually called the ARM). It has diagrams of key layout examples. There is a very brief
explanation in Chapter 2 of TC++PL3.
Basically, C++ constructs objects simply by concatenating sub objects. Thus
1. struct A { int a,b; };
is represented by two ints next to each other, and
1. struct B : A { int c; };
is represented by an A followed by an int; that is, by three ints next to each other.
Virtual functions are typically implemented by adding a pointer (the “vptr”) to each object of a class
with virtual functions. This pointer points to the appropriate table of functions (the “vtbl”). Each
class has its own vtbl shared by all objects of that class.

Why is the size of an empty class not zero?

To ensure that the addresses of two different objects will be different. For the same
reason, new always returns pointers to distinct objects. Consider:
1. class Empty { };
2.
3. void f()
4. {
5. Empty a, b;
6. if (&a == &b) cout << "impossible: report error to compiler supplier";
7.
8. Empty* p1 = new Empty;
9. Empty* p2 = new Empty;
10. if (p1 == p2) cout << "impossible: report error to compiler supplier";
11. }
There is an interesting rule that says that an empty base class need not be represented by a separate
byte:
1. struct X : Empty {
2. int a;
3. // ...
4. };
5.
6. void f(X* p)
7. {
8. void* p1 = p;
9. void* p2 = &p->a;
10. if (p1 == p2) cout << "nice: good optimizer";
11. }
This optimization is safe and can be most useful. It allows a programmer to use empty classes to
represent very simple concepts without overhead. Some current compilers provide this “empty base
class optimization”.
Moreover, “empty base class optimization” is no longer an optional optimization but a mandatory
requirement on class layout as of C++11. Go beat up on your compiler vendor if it does not
implement it properly.

Constructors
Save to:
 InstapaperPocketReadability
Contents of this section:

 What’s the deal with constructors?

 Is there any difference between List x; and List x();?
 Can one constructor of a class call another constructor of the same class to initialize
the this object?
 Is the default constructor for Fred always Fred::Fred()?
 Which constructor gets called when I create an array of Fred objects?
 Should my constructors use “initialization lists” or “assignment”?
 How should initializers be ordered in a constructor’s initialization list?
 Is it moral for one member object to be initialized using another member object in the
initializer expression?
 What if one member object has to be initialized using another member object?
 Should you use the this pointer in the constructor?
 What is the “Named Constructor Idiom”?
 Does return-by-value mean extra copies and extra overhead?
 What about returning a local variable by value? Does the local exist as a separate object, or
does it get optimized away?
 Why can’t I initialize my static member data in my constructor’s initialization list?
 Why are classes with static data members getting linker errors?
 Can I add = initializer; to the declaration of a class-scope static const data member?
 What’s the “static initialization order ‘fiasco’ (problem)”?
 How do I prevent the “static initialization order problem”?
 Why doesn’t the Construct On First Use Idiom use a static object instead of
a static pointer?
 What is a technique to guarantee both static initialization and static deinitialization?
 How do I prevent the “static initialization order problem” for my static data members?
 Do I need to worry about the “static initialization order problem” for variables of
built-in/intrinsic types?
 How can I handle a constructor that fails?
 What is the “Named Parameter Idiom”?
 Why am I getting an error after declaring a Foo object via Foo x(Bar())?
 What is the purpose of the explicit keyword?
 Why doesn’t my constructor work right?
What’s the deal with constructors?
Constructors build objects from dust.
Constructors are like “init functions”. They turn a pile of arbitrary bits into a living object.
Minimally they initialize internally used fields. They may also allocate resources (memory, files,
semaphores, sockets, etc).
“ctor” is a typical abbreviation for constructor.

Is there any difference between List x; and List

x();?
A big difference!
Suppose that List is the name of some class. Then function f() declares a local List object
called x:
1. void f()
2. {
3. List x; // Local object named x (of class List)
4. // ...
5. }
But function g() declares a function called x() that returns a List:
1. void g()
2. {
3. List x(); // Function named x (that returns a List)
4. // ...
5. }

Can one constructor of a class call another constructor of

the same class to initialize the this object?
The answer below applies to Classic (pre-11) C++. This question covers the C++11 feature of
constructors that call same-type constructors.
Nope.
Let’s work an example. Suppose you want your constructor Foo::Foo(char) to call another
constructor of the same class, say Foo::Foo(char,int), in order
that Foo::Foo(char,int) would help initialize the this object. Unfortunately there’s no way to
do this in Classic C++.
Some people do it anyway. Unfortunately it doesn’t do what they want. For example, the
line Foo(x, 0); does not call Foo::Foo(char,int) on the this object. Instead it
calls Foo::Foo(char,int) to initialize a temporary, local object (not this), then it immediately
destructs that temporary when control flows over the ;.
1. class Foo {
2. public:
3. Foo(char x);
4. Foo(char x, int y);
5. // ...
6. };
7.
8. Foo::Foo(char x)
9. {
10. // ...
11. Foo(x, 0); // Does NOT help initialize the this object!!
12. // ...
13. }
You can sometimes combine two constructors via a default parameter:
1. class Foo {
2. public:
3. Foo(char x, int y = 0); // Has the effect of combining the two constructors
4. // ...
5. };
If that doesn’t work, e.g., if there isn’t an appropriate default parameter that combines the two
constructors, sometimes you can share their common code in a private init() member function:
1. class Foo {
2. public:
3. Foo(char x);
4. Foo(char x, int y);
5. // ...
6. private:
7. void init(char x, int y);
8. };
9.
10. Foo::Foo(char x)
11. {
12. init(x, int(x) + 7);
13. // ...
14. }
15.
16. Foo::Foo(char x, int y)
17. {
18. init(x, y);
19. // ...
20. }
21.
22. void Foo::init(char x, int y)
23. {
24. // ...
25. }
BTW do NOT try to achieve this via placement new. Some people think they can say new(this)
Foo(x, int(x)+7) within the body of Foo::Foo(char). However that is bad, bad, bad. Please
don’t write me and tell me that it seems to work on your particular version of your particular
compiler; it’s bad. Constructors do a bunch of little magical things behind the scenes, but that bad
technique steps on those partially constructed bits. Just say no.
Is the default constructor
for Fred always Fred::Fred()?
No.
A “default constructor” is a constructor that can be called with no arguments. One example of this is
a constructor that takes no parameters:
1. class Fred {
2. public:
3. Fred(); // Default constructor: can be called with no args
4. // ...
5. };
Another example of a “default constructor” is one that can take arguments, provided they are given
default values:
1. class Fred {
2. public:
3. Fred(int i=3, int j=5); // Default constructor: can be called with no args
4. // ...
5. };

Which constructor gets called when I create an array

of Fred objects?
Fred’s default constructor (except as discussed below).
1. class Fred {
2. public:
3. Fred();
4. // ...
5. };
6.
7. int main()
8. {
9. Fred a[10]; // Calls the default constructor 10 times
10. Fred* p = new Fred[10]; // Calls the default constructor 10 times
11. // ...
12. }
If your class doesn’t have a default constructor, you’ll get a compile-time error when you attempt to
create an array using the above simple syntax:
1. class Fred {
2. public:
3. Fred(int i, int j); // Assume there is no default constructor
4. // ...
5. };
6.
7. int main()
8. {
9. Fred a[10]; // ERROR: Fred doesn't have a default constructor
10. Fred* p = new Fred[10]; // ERROR: Fred doesn't have a default constructor
11. // ...
12. }
However, even if your class already has a default constructor, you should try to
use std::vector<Fred> rather than an array (arrays are evil). std::vector lets you decide to
use any constructor, not just the default constructor:
1. #include <vector>
2.
3. int main()
4. {
5. std::vector<Fred> a(10, Fred(5,7)); // The 10 Fred objects in std::vector a will be initialized with
Fred(5,7)
6. // ...
7. }
Even though you ought to use a std::vector rather than an array, there are times when an array
might be the right thing to do, and for those, you might need the “explicit initialization of arrays”
syntax. Here’s how:
1. class Fred {
2. public:
3. Fred(int i, int j); // Assume there is no default constructor
4. // ...
5. };
6.
7. int main()
8. {
9. Fred a[10] = {
10. Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), // The 10 Fred objects are
11. Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7) // initialized using Fred(5,7)
12. };
13. // ...
14. }
Of course you don’t have to do Fred(5,7) for every entry — you can put in any numbers you
want, even parameters or other variables.
Finally, you can use placement-new to manually initialize the elements of the array. Warning: it’s
ugly: the raw array can’t be of type Fred, so you’ll need a bunch of pointer-casts to do things like
compute array index operations. Warning: it’s compiler- and hardware-dependent: you’ll need to
make sure the storage is aligned with an alignment that is at least as strict as is required for objects
of class Fred. Warning: it’s tedious to make it exception-safe: you’ll need to manually destruct the
elements, including in the case when an exception is thrown part-way through the loop that calls the
constructors. But if you really want to do it anyway, read up on placement-new. (BTW placement-
 new is the magic that is used inside of std::vector. The complexity of getting everything right is
yet another reason to use std::vector.)
By the way, did I ever mention that arrays are evil? Or did I mention that you ought to use
a std::vector unless there is a compelling reason to use an array?
Should my constructors use “initialization lists” or
“assignment”?
Initialization lists. In fact, constructors should initialize as a rule all member objects in the
initialization list. One exception is discussed further down.
Watch this space for discussion of Non Static Data Member Initialization in C++11
1. // Here is the taste of standard C++ NSDMI
2. struct Point {
3. int X = 0; // Look at that!!!
4. int Y = 0; //
5. };
Consider the following constructor that initializes member object x_ using an initialization
list: Fred::Fred() : x_(whatever) { }. The most common benefit of doing this is improved
performance. For example, if the expression whatever is the same type as member variable x_, the
result of the whatever expression is constructed directly inside x_ — the compiler does not make a
separate copy of the object. Even if the types are not the same, the compiler is usually able to do a
better job with initialization lists than with assignments.
The other (inefficient) way to build constructors is via assignment, such as: Fred::Fred() { x_
= whatever; }. In this case the expression whatever causes a separate, temporary object to be
created, and this temporary object is passed into the x_ object’s assignment operator. Then that
temporary object is destructed at the ;. That’s inefficient.
As if that wasn’t bad enough, there’s another source of inefficiency when using assignment in a
constructor: the member object will get fully constructed by its default constructor, and this might,
for example, allocate some default amount of memory or open some default file. All this work could
be for naught if the whatever expression and/or assignment operator causes the object to close that
file and/or release that memory (e.g., if the default constructor didn’t allocate a large enough pool of
memory or if it opened the wrong file).
Conclusion: All other things being equal, your code will run faster if you use initialization lists
rather than assignment.
Note: There is no performance difference if the type of x_ is some built-in/intrinsic type, such
as int or char* or float. But even in these cases, my personal preference is to set those data
members in the initialization list rather than via assignment for consistency. Another symmetry
argument in favor of using initialization lists even for built-in/intrinsic types: non-static const and
non-static reference data members can’t be assigned a value in the constructor, so for symmetry it
makes sense to initialize everything in the initialization list.
Now for the exceptions. Every rule has exceptions (hmmm; does “every rule has exceptions” have
exceptions? reminds me of Gödel’s Incompleteness Theorems), and there are a couple of exceptions
to the “use initialization lists” rule. Bottom line is to use common sense: if it’s cheaper, better,
faster, etc. to not use them, then by all means, don’t use them. This might happen when your class
has two constructors that need to initialize the this object’s data members in different orders. Or it
might happen when two data members are self-referential. Or when a data-member needs a
reference to the this object, and you want to avoid a compiler warning about using
the this keyword prior to the { that begins the constructor’s body (when your particular compiler
happens to issue that particular warning). Or when you need to do an if…throw test on a
variable (parameter, global, etc.) prior to using that variable to initialize one of your this members.
 This list is not exhaustive; please don’t write me asking me to add another “Or when…”. The point
is simply this: use common sense.
How should initializers be ordered in a constructor’s
initialization list?
Immediate base classes (left to right), then member objects (top to bottom).
In other words, the order of the initialization list should mimic the order in which initializations will
take place. This guideline discourages a particularly subtle class of order dependency errors by
giving an obvious, visual clue. For example, the following contains a hideous error.
1. #include <iostream>
2.
3. class Y {
4. public:
5. Y();
6. void f();
7. };
8.
9. Y::Y() { std::cout << "Initializing Y\n"; }
10. void Y::f() { std::cout << "Using Y\n"; }
11.
12. class X {
13. public:
14. X(Y& y);
15. };
16.
17. X::X(Y& y) { y.f(); }
18.
19. class Z {
20. public:
21. Z();
22. protected:
23. X x_;
24. Y y_;
25. };
26.
27. Z::Z() throw()
28. : y_()
29. , x_(y_)
30. ↑↑ // Bad: should have listed x_ before y_
31. {}
32.
33. int main()
34. {
35. Z z;
36. return 0;
37. }
The output of this program follows.
1. Using Y
2. Initializing Y
Note that y_ is used (Y::f()) before it is initialized (Y::Y()). If instead the programmer had read
and abided by the guideline in this FAQ, the error would be more obvious: the initialization list
of Z::Z() would have read x_(y_), y_(), visually indicating that y_ was being used before
being initialized.
 Not all compilers issue diagnostic messages for these cases. You have been warned.

Is it moral for one member object to be initialized using

another member object in the initializer expression?
Yes, but use care and do that only when it adds value.
In a constructor’s initialization list, it is easiest and safest to avoid using one member object
from this object in the initialization expression of a subsequent initializer for this object. This
guideline prevents subtle order-dependency errors if someone reorganizes the layout of member
objects within the class.
Because of this guideline, the constructor that follows uses s.len_ + 1u rather than len_ + 1u,
even though they are otherwise equivalent. The s. prefix avoids an unnecessary and avoidable
order dependency.
1. #include <memory>
2.
3. class MyString {
4. public:
5. MyString();
6. ~MyString();
7. MyString(const MyString& s); // copy constructor
8. MyString& operator= (const MyString& s); // assignment
9. // ...
10. protected:
11. unsigned len_;
12. char* data_;
13. };
14.
15. MyString::MyString()
16. : len_(0u)
17. , data_(new char[1])
18. {
19. data_[0] = '\0';
20. }
21.
22. MyString::~MyString()
23. { delete[] data_; }
24.
25. MyString::MyString(const MyString& s)
26. : len_ (s.len_)
27. , data_(new char[s.len_ + 1u]) <--Not {tt{new char[len_+1]}tt}
28. { ↑↑↑↑↑↑ // not len_
29. memcpy(data_, s.data_, len_ + 1u);
30. } ↑↑↑↑ // no issue using len_ in ctor's {body}
31.
32. int main()
33. {
34. MyString a; // default ctor; zero length MyString ("")
35. MyString b = a; // copy constructor
36. return 0;
37. }
An unnecessary order dependency on the class layout of len_ and data_ would have been
introduced if the constructor’s initialization of data_ had used len_ + 1u rather than s.len_ +
1u. However using len_ within a constructor body ({...}) is okay. No order dependency is
 introduced since the entire initialization list is guaranteed to finish before the constructor body
begins executing.
What if one member object has to be initialized using
another member object?
Comment the declaration of the effected data members with //ORDER DEPENDENCY.
If a constructor initializes a member object of this object using another member object
of this object, rearranging the data members of the class could break the constructor. This
important maintenance constraint should be documented in the class body.
For example, in the constructor below, the initializer for data_ uses len_ to avoid a redundant call
to std::strlen(s), which introduces an order dependency in the class body.
1. #include <memory>
2.
3. class MyString {
4. public:
5. MyString(const char* s); // promote const char*
6. MyString(const MyString& s); // copy constructor
7. MyString& operator= (const MyString&); // assignment
8. ~MyString();
9. // ...
10. protected:
11. unsigned len_; // ORDER DEPENDENCY
12. char* data_; // ORDER DEPENDENCY
13. };
14.
15. MyString::MyString(const char* s)
16. : len_ (std::strlen(s))
17. , data_(new char[len_ + 1u])
18. {
19. std::memcpy(data_, s, len_ + 1u);
20. }
21.
22. MyString::~MyString()
23. {
24. delete[] data_;
25. }
26.
27. int main()
28. {
29. MyString s = "xyzzy";
30. return 0;
31. }
Note that the //ORDER DEPENDENCY comment is listed with the effected data members in the class
body, not with the constructor initialization list where the order dependency was actually created.
That is because the order of member objects in the class body is critical; the order of initializers in
the constructor initialization list is irrelevant.
Should you use the this pointer in the constructor?
Some people feel you should not use the this pointer in a constructor because the object is not
fully formed yet. However you can use this in the constructor (in the {body} and even in
the initialization list) if you are careful.
Here is something that always works: the {body} of a constructor (or a function called from the
constructor) can reliably access the data members declared in a base class and/or the data members
 declared in the constructor’s own class. This is because all those data members are guaranteed to
have been fully constructed by the time the constructor’s {body} starts executing.
Here is something that never works: the {body} of a constructor (or a function called from the
constructor) cannot get down to a derived class by calling a virtual member function that is
overridden in the derived class. If your goal was to get to the overridden function in the derived
class, you won’t get what you want. Note that you won’t get to the override in the derived class
independent of how you call the virtual member function: explicitly using the this pointer
(e.g., this->method()), implicitly using the this pointer (e.g., method()), or even calling some
other function that calls the virtual member function on your this object. The bottom line is
this: even if the caller is constructing an object of a derived class, during the constructor of the base
class, your object is not yet of that derived class. You have been warned.
Here is something that sometimes works: if you pass any of the data members in this object to
another data member’s initializer, you must make sure that the other data member has already been
initialized. The good news is that you can determine whether the other data member has (or has not)
been initialized using some straightforward language rules that are independent of the particular
compiler you’re using. The bad news is that you have to know those language rules (e.g., base class
sub-objects are initialized first (look up the order if you have multiple
and/or virtual inheritance!), then data members defined in the class are initialized in the order in
which they appear in the class declaration). If you don’t know these rules, then don’t pass any data
member from the this object (regardless of whether or not you explicitly use the this keyword)
to any other data member’s initializer! And if you do know the rules, please be careful.
What is the “Named Constructor Idiom”?
A technique that provides more intuitive and/or safer construction operations for users of your class.
The problem is that constructors always have the same name as the class. Therefore the only way to
differentiate between the various constructors of a class is by the parameter list. But if there are lots
of constructors, the differences between them become somewhat subtle and error prone.
With the Named Constructor Idiom, you declare all the class’s constructors in
the private or protected sections, and you provide public static methods that return an
object. These static methods are the so-called “Named Constructors.” In general there is one
such static method for each different way to construct an object.
For example, suppose we are building a Point class that represents a position on the X-Y plane.
Turns out there are two common ways to specify a 2-space coordinate: rectangular coordinates
(X+Y), polar coordinates (Radius+Angle). (Don’t worry if you can’t remember these; the point isn’t
the particulars of coordinate systems; the point is that there are several ways to create
a Point object.) Unfortunately the parameters for these two coordinate systems are the same:
two floats. This would create an ambiguity error in the overloaded constructors:
1. class Point {
2. public:
3. Point(float x, float y); // Rectangular coordinates
4. Point(float r, float a); // Polar coordinates (radius and angle)
5. // ERROR: Overload is Ambiguous: Point::Point(float,float)
6. };
7.
8. int main()
9. {
10. Point p = Point(5.7, 1.2); // Ambiguous: Which coordinate system?
11. // ...
12. }
One way to solve this ambiguity is to use the Named Constructor Idiom:
1. #include <cmath> // To get std::sin() and std::cos()
2.
3. class Point {
4. public:
5. static Point rectangular(float x, float y); // Rectangular coord's
6. static Point polar(float radius, float angle); // Polar coordinates
7. // These static methods are the so-called "named constructors"
8. // ...
9. private:
10. Point(float x, float y); // Rectangular coordinates
11. float x_, y_;
12. };
13.
14. inline Point::Point(float x, float y)
15. : x_(x), y_(y) { }
16.
17. inline Point Point::rectangular(float x, float y)
18. { return Point(x, y); }
19.
20. inline Point Point::polar(float radius, float angle)
21. { return Point(radius*std::cos(angle), radius*std::sin(angle)); }
Now the users of Point have a clear and unambiguous syntax for creating Points in either
coordinate system:
1. int main()
2. {
3. Point p1 = Point::rectangular(5.7, 1.2); // Obviously rectangular
4. Point p2 = Point::polar(5.7, 1.2); // Obviously polar
5. // ...
6. }
Make sure your constructors are in the protected section if you expect Point to have derived
classes.
The Named Constructor Idiom can also be used to make sure your objects are always created
via new.
Note that the Named Constructor Idiom, at least as implemented above, is just as fast as directly
calling a constructor — modern compilers will not make any extra copies of your object.
Does return-by-value mean extra copies and extra
overhead?
Not necessarily.
All(?) commercial-grade compilers optimize away the extra copy, at least in cases as illustrated
in the previous FAQ.
To keep the example clean, let’s strip things down to the bare essentials. Suppose
function caller() calls rbv() (“rbv” stands for “return by value”) which returns a Foo object by
value:
1. class Foo { /*...*/ };
2.
3. Foo rbv();
4.
5. void caller()
6. {
7. Foo x = rbv(); // The return-value of rbv() goes into x
8. // ...
9. }
 Now the question is, How many Foo objects will there be? Will rbv() create a
temporary Foo object that gets copy-constructed into x? How many temporaries? Said another way,
does return-by-value necessarily degrade performance?
The point of this FAQ is that the answer is No, commercial-grade C++ compilers implement return-
by-value in a way that lets them eliminate the overhead, at least in simple cases like those shown in
the previous FAQ. In particular, all(?) commercial-grade C++ compilers will optimize this case:
1. Foo rbv()
2. {
3. // ...
4. return Foo(42, 73); // Suppose Foo has a ctor Foo::Foo(int a, int b)
5. }
Certainly the compiler is allowed to create a temporary, local Foo object, then copy-construct that
temporary into variable x within caller(), then destruct the temporary. But all(?) commercial-
grade C++ compilers won’t do that: the return statement will directly construct x itself. Not a
copy of x, not a pointer to x, not a reference to x, but x itself.
You can stop here if you don’t want to genuinely understand the previous paragraph, but if you
want to know the secret sauce (so you can, for example, reliably predict when the compiler can and
cannot provide that optimization for you), the key is to know that compilers usually implement
return-by-value using pass-by-pointer. When caller() calls rbv(), the compiler secretly passes a
pointer to the location where rbv() is supposed to construct the “returned” object. It might look
something like this (it’s shown as a void* rather than a Foo* since the Foo object has not yet been
constructed):
1. // Pseudo-code
2. void rbv(void* put_result_here) // Original C++ code: Foo rbv()
3. {
4. // ...code that initializes (not assigns to) the variable pointed to by put_result_here
5. }
6.
7. // Pseudo-code
8. void caller()
9. {
10. // Original C++ code: Foo x = rbv()
11. struct Foo x; // Note: x does not get initialized prior to calling rbv()
12. rbv(&x); // Note: rbv() initializes a local variable defined in caller()
13. // ...
14. }
So the first ingredient in the secret sauce is that the compiler (usually) transforms return-by-value
into pass-by-pointer. This means that commercial-grade compilers don’t bother creating a
temporary: they directly construct the returned object in the location pointed to
by put_result_here.
The second ingredient in the secret sauce is that compilers typically implement constructors using a
similar technique. This is compiler-dependent and somewhat idealized (I’m intentionally ignoring
how to handle new and overloading), but compilers typically implement Foo::Foo(int a, int
b) using something like this:
1. // Pseudo-code
2. void Foo_ctor(Foo* this, int a, int b) // Original C++ code: Foo::Foo(int a, int b)
3. {
4. // ...
5. }
Putting these together, the compiler might implement the return statement in rbv() by simply
passing put_result_here as the constructor’s this pointer:
1. // Pseudo-code
2. void rbv(void* put_result_here) // Original C++ code: Foo rbv()
3. {
4. // ...
5. Foo_ctor((Foo*)put_result_here, 42, 73); // Original C++ code: return Foo(42,73);
6. return;
7. }
So caller() passes &x to rbv(), and rbv() in turn passes &x to the constructor (as
the this pointer). That means constructor directly constructs x.
In the early 90s I did a seminar for IBM’s compiler group in Toronto, and one of their engineers
told me that they found this return-by-value optimization to be so fast that you get it even if you
don’t compile with optimization turned on. Because the return-by-value optimization causes the
compiler to generate less code, it actually improves compile-times in addition to making your
generated code smaller and faster. The point is that the return-by-value optimization is almost
universally implemented, at least in code cases like those shown above.
Final thought: this discussion was limited to whether there will be any extra copies of the returned
object in a return-by-value call. Don’t confuse that with other things that could happen
in caller(). For example, if you changed caller() from Foo x = rbv(); to Foo x; x =
rbv(); (note the ; after the declaration), the compiler is required to use Foo’s assignment
operator, and unless the compiler can prove that Foo’s default constructor followed by assignment
operator is exactly the same as its copy constructor, the compiler is required by the language to put
the returned object into an unnamed temporary within caller(), use the assignment operator to
copy the temporary into x, then destruct the temporary. The return-by-value optimization still plays
its part since there will be only one temporary, but by changing Foo x = rbv(); to Foo x; x =
rbv();, you have prevented the compiler from eliminating that last temporary.
What about returning a local variable by value? Does the
local exist as a separate object, or does it get optimized
away?
When your code returns a local variable by value, your compiler might optimize away the local
variable completely - zero space-cost and zero time-cost - the local variable never actually exists as
a distinct object from the caller’s target variable (see below for specifics about exactly what this
means). Other compilers do not optimize it away.
These are some(!) of the compilers that optimize away the local variable completely:
 GNU C++ (g++) since at least version 3.3.3
 (Others need to be added; need more info)
These are some(!) of the compilers that do not optimize away the local variable:
 Microsoft Visual C++.NET 2003
 (Others need to be added; need more info)
Here is an example showing what we mean in this FAQ:
1. class Foo {
2. public:
3. Foo(int a, int b);
4. void some_method();
5. // ...
6. };
7.
8. void do_something_with(Foo& z);
9.
10. Foo rbv()
11. {
12. Foo y = Foo(42, 73);
13. y.some_method();
14. do_something_with(y);
15. return y;
16. }
17.
18. void caller()
19. {
20. Foo x = rbv();
21. // ...
22. }
The question addressed in this FAQ is this: How many Foo objects actually get created in the
runtime system? Conceptually there could be as many as three distinct objects: the temporary
created by Foo(42, 73), variable y (in rbv()), and variable x (in caller()). However as we
saw earlier most compilers merge Foo(42, 73) and variable y into the same object, reducing the
total number of objects from 3 to 2. But this FAQ pushes it one step further: does y (in rbv())
show up as a distinct, runtime object from x (in caller())?
Some compilers, including but not limited to those listed above, completely optimize away local
variable y. In those compilers, there is only one Foo object in the above code: caller()’s
variable x is exactly identically the same object as rbv()’s variable y.
They do this the same way as described earlier: the return-by-value in function rbv() is
implemented as pass-by-pointer, where the pointer points to the location where the returned object
is to be initialized.
So instead of constructing y as a local object, these compilers simply
construct *put_result_here, and everytime they see variable y used in the original source code,
they substitute *put_result_here instead. Then the line return y; becomes
simply return; since the returned object has already been constructed in the location designated by
the caller.
Here is the resulting (pseudo)code:
1. // Pseudo-code
2. void rbv(void* put_result_here) // Original C++ code: Foo rbv()
3. {
4. Foo_ctor((Foo*)put_result_here, 42, 73); // Original C++ code: Foo y = Foo(42,73);
5. Foo_some_method(*(Foo*)put_result_here); // Original C++ code: y.some_method();
6. do_something_with((Foo*)put_result_here); // Original C++ code: do_something_with(y);
7. return; // Original C++ code: return y;
8. }
9.
10. void caller()
11. {
12. struct Foo x; // Note: x is not initialized here!
13. rbv(&x); // Original C++ code: Foo x = rbv();
14. // ...
15. }
Caveat: this optimization can be applied only when all a function’s return statements return the
same local variable. If one return statement in rbv() returned local variable y but another
returned something else, such as a global or a temporary, the compiler could not alias the local
variable into the caller’s destination, x. Verifying that all the function’s return statements return the
same local variable requires extra work on the part of the compiler writers, which is usually why
some compilers fail to implement that return-local-by-value optimization.
Final thought: this discussion was limited to whether there will be any extra copies of the returned
object in a return-by-value call. Don’t confuse that with other things that could happen
in caller(). For example, if you changed caller() from Foo x = rbv(); to Foo x; x =
 rbv(); (note the ; after the declaration), the compiler is required to use Foo’s assignment
operator, and unless the compiler can prove that Foo’s default constructor followed by assignment
operator is exactly the same as its copy constructor, the compiler is required by the language to put
the returned object into an unnamed temporary within caller(), use the assignment operator to
copy the temporary into x, then destruct the temporary. The return-by-value optimization still plays
its part since there will be only one temporary, but by changing Foo x = rbv(); to Foo x; x =
rbv();, you have prevented the compiler from eliminating that last temporary.
Why can’t I initialize my static member data in my
constructor’s initialization list?
Because you must explicitly define your class’s static data members.
Fred.h:
1. class Fred {
2. public:
3. Fred();
4. // ...
5. private:
6. int i_;
7. static int j_;
8. };
Fred.cpp (or Fred.C or whatever):
1. Fred::Fred()
2. : i_(10) // Okay: you can (and should) initialize member data this way
3. , j_(42) // Error: you cannot initialize static member data like this
4. {
5. // ...
6. }
7.
8. // You must define static data members this way:
9. int Fred::j_ = 42;
Note: in some cases, the definition of Fred::j_ might not contain the = initializer part. For details,
see here and here.
Why are classes with static data members getting linker
errors?
Because static data members must be explicitly defined in exactly one compilation unit. If you
didn’t do this, you’ll probably get an "undefined external" linker error. For example:
1. // Fred.h
2.
3. class Fred {
4. public:
5. // ...
6. private:
7. static int j_; // Declares static data member Fred::j_
8. // ...
9. };
The linker will holler at you ("Fred::j_ is not defined") unless you define (as opposed to
merely declare) Fred::j_ in (exactly) one of your source files:
1. // Fred.cpp
2.
3. #include "Fred.h"
4.
5. int Fred::j_ = some_expression_evaluating_to_an_int;
6.
7. // Alternatively, if you wish to use the implicit 0 value for static ints:
8. // int Fred::j_;
The usual place to define static data members of class Fred is file Fred.cpp (or Fred.C or
whatever source file extension you use).
Note: in some cases, you can add = initializer; to the declaration of class-
scope static declarations, however if you ever use the data member, you still need to explicitly
define it in exactly one compilation unit. In this case you don’t include an = initializer in the
definition. A separate FAQ covers this topic.
Can I add = initializer; to the declaration of a class-
scope static const data member?
Yes, though with some important caveats.
Before going through the caveats, here is a simple example that is allowed:
1. // Fred.h
2.
3. class Fred {
4. public:
5. static const int maximum = 42;
6. // ...
7. };
And, just like other static data members, it must be defined in exactly one compilation unit,
though this time without the = initializer part:
1. // Fred.cpp
2.
3. #include "Fred.h"
4.
5. const int Fred::maximum;
6.
7. // ...
The caveats are that you may do this only with integral or enumeration types, and that
the initializer expression must be an expression that can be evaluated at compile-time: it must only
contain other constants, possibly combined with built-in operators. For example, 3*4 is a compile-
time constant expression, as is a*b provided a and b are compile-time constants. After the
declaration above, Fred::maximum is also a compile-time constant: it can be used in other
compile-time constant expressions.
If you ever take the address of Fred::maximum, such as passing it by reference or explicitly
saying &Fred::maximum, the compiler will make sure it has a unique address. If
not, Fred::maximum won’t even take up space in your process’s static data area.
What’s the “static initialization order ‘fiasco’
(problem)”?
A subtle way to crash your program.
The static initialization order problem is a very subtle and commonly misunderstood aspect of C+
+. Unfortunately it’s very hard to detect — the errors often occur before main() begins.
In short, suppose you have two static objects x and y which exist in separate source files,
say x.cpp and y.cpp. Suppose further that the initialization for the y object (typically
the y object’s constructor) calls some method on the x object.
That’s it. It’s that simple.
 The tough part is that you have a 50%-50% chance of corrupting the program. If the compilation
unit for x.cpp happens to get initialized first, all is well. But if the compilation unit for y.cpp get
initialized first, then y’s initialization will get run before x’s initialization, and you’re toast. E.g., y’s
constructor could call a method on the x object, yet the x object hasn’t yet been constructed.
For how to address the problem, see the next FAQ.
Note: The static initialization order problem can also, in some cases, apply to built-in/intrinsic types.
How do I prevent the “static initialization order
problem”?
To prevent the static initialization order problem, use the Construct On First Use Idiom, described
below.
The basic idea of the Construct On First Use Idiom is to wrap your static object inside a function.
For example, suppose you have two classes, Fred and Barney. There is a namespace-scope /
global Fred object called x, and a namespace-scope / global Barney object called y. Barney’s
constructor invokes the goBowling() method on the x object. The file x.cpp defines the x object:
1. // File x.cpp
2. #include "Fred.h"
3. Fred x;
The file y.cpp defines the y object:
1. // File y.cpp
2. #include "Barney.h"
3. Barney y;
For completeness the Barney constructor might look something like this:
1. // File Barney.cpp
2. #include "Barney.h"
3.
4. Barney::Barney()
5. {
6. // ...
7. x.goBowling();
8. // ...
9. }
You would have a static initialization disaster if y got constructed before x. As written above,
this disaster would occur roughly 50% of the time, since the two objects are declared in different
source files and those source files give no hints to the compiler or linker as to the order of static
initialization.
There are many solutions to this problem, but a very simple and completely portable solution is
the Construct On First Use Idiom: replace the namespace-scope / global Fred object x with a
namespace-scope / global function x() that returns the Fred object by reference.
1. // File x.cpp
2.
3. #include "Fred.h"
4.
5. Fred& x()
6. {
7. static Fred* ans = new Fred();
8. return *ans;
9. }
Since static local objects are constructed the first time control flows over their declaration (only),
the above new Fred() statement will only happen once: the first time x() is called. Every
subsequent call will return the same Fred object (the one pointed to by ans). Then all you do is
change your usages of x to x():
1. // File Barney.cpp
2. #include "Barney.h"
3.
4. Barney::Barney()
5. {
6. // ...
7. x().goBowling();
8. // ...
9. }
This is called the Construct On First Use Idiom because it does just that: the (logically namespace-
scope / global) Fred object is constructed on its first use.
The downside of this approach is that the Fred object is never destructed. If the Fred object has a
destructor with important side effects, there is another technique that answers this concern; but it
needs to be used with care since it creates the possibility of another (equally nasty) problem.
Note: The static initialization order problem can also, in some cases, apply to built-in/intrinsic types.
Why doesn’t the Construct On First Use Idiom use
a static object instead of a static pointer?
Short answer: it’s possible to use a static object rather than a static pointer, but doing so opens up
another (equally subtle, equally nasty) problem.
Long answer: sometimes people worry about the fact that the previous solution “leaks.” In many
cases, this is not a problem, but it is a problem in some cases. Note: even though the object pointed
to by ans in the previous FAQ is never deleted, the memory doesn’t actually “leak” when the
program exits since the operating system automatically reclaims all the memory in a program’s heap
when that program exits. In other words, the only time you’d need to worry about this is when the
destructor for the Fred object performs some important action (such as writing something to a file)
that must occur sometime while the program is exiting.
In those cases where the construct-on-first-use object (the Fred, in this case) needs to eventually get
destructed, you might consider changing function x() as follows:
1. // File x.cpp
2.
3. #include "Fred.h"
4.
5. Fred& x()
6. {
7. static Fred ans; // was static Fred* ans = new Fred();
8. return ans; // was return *ans;
9. }
However there is (or rather, may be) a rather subtle problem with this change. To understand this
potential problem, let’s remember why we’re doing all this in the first place: we need to make 100%
sure our static object (a) gets constructed prior to its first use and (b) doesn’t get destructed until
after its last use. Obviously it would be a disaster if any static object got used either before
construction or after destruction. The message here is that you need to worry about two situations
(static initialization and static deinitialization), not just one.
By changing the declaration from static Fred* ans = new Fred(); to static Fred
ans;, we still correctly handle the initialization situation but we no longer handle the
deinitialization situation. For example, if there are 3 static objects, say a, b and c, that
use ans during their destructors, the only way to avoid a static deinitialization disaster is if ans is
destructed after all three.
The point is simple: if there are any other static objects whose destructors might
use ans after ans is destructed, bang, you’re dead. If the constructors of a, b and c use ans,
you should normally be okay since the runtime system will, during static deinitialization,
 destruct ans after the last of those three objects is destructed. However if a and/or b and/or c fail to
use ans in their constructors and/or if any code anywhere gets the address of ans and hands it to
some other static object, all bets are off and you have to be very, very careful.
There is a third approach that handles both the static initialization and static deinitialization
situations, but it has other non-trivial costs.
What is a technique to guarantee
both static initialization and static deinitialization?
Short answer: use the Nifty Counter Idiom (but make sure you understand the non-trivial tradeoffs!).
Motivation:
 The Construct On First Use Idiom uses a pointer and intentionally leaks the object. That is
often innocuous, since the operating system will typically clean up a process’s memory when the
process terminates. However if the object has a non-trivial destructor with important side effects,
such as writing to a file or some other non-volatile action, then you need more.
 That’s where the second version of the Construct On First Use Idiom came in: it doesn’t leak
the object, but it does not control the order of static deinitialization, so it is (very!) unsafe to use
the object during static deinitialization, that is, from a destructor of another statically declared
object.
 If you need to control the order of both static initialization and static deinitialization,
meaning if you wish to access a statically allocated object from both constructors and destructors
of other static objects, then keep reading.
 Otherwise run away.
TODO: WRITE THIS UP
TODO: WRITE UP TRADEOFFS — now that you know how to use the Nifty Counter Idiom, be sure
you understand both when and (especially!) when not to use it! One size does not fit all.
How do I prevent the “static initialization order problem”
for my static data members?
Use the Construct Members On First Use Idiom, which is basically the same as the regular Construct
On First Use Idiom, or perhaps one of its variants, but it uses a static member function instead of
a namespace-scope / global function.
Suppose you have a class X that has a static Fred object:
1. // File X.h
2.
3. class X {
4. public:
5. // ...
6.
7. private:
8. static Fred x_;
9. };
Naturally this static member is initialized separately:
1. // File X.cpp
2.
3. #include "X.h"
4.
5. Fred X::x_;
Naturally also the Fred object will be used in one or more of X’s methods:
1. void X::someMethod()
2. {
3. x_.goBowling();
4. }
But now the “disaster scenario” is if someone somewhere somehow calls this method before
the Fred object gets constructed. For example, if someone else creates a static X object and invokes
its someMethod() method during static initialization, then you’re at the mercy of the compiler
as to whether the compiler will construct X::x_ before or after the someMethod() is called. (Note
that the ANSI/ISO C++ committee is working on this problem, but compilers aren’t yet generally
available that handle these changes; watch this space for an update in the future.)
In any event, it’s always portable and safe to change the X::x_ static data member into
a static member function:
1. // File X.h
2.
3. class X {
4. public:
5. // ...
6.
7. private:
8. static Fred& x();
9. };
Naturally this static member is initialized separately:
1. // File X.cpp
2.
3. #include "X.h"
4.
5. Fred& X::x()
6. {
7. static Fred* ans = new Fred();
8. return *ans;
9. }
Then you simply change any usages of x_ to x():
1. void X::someMethod()
2. {
3. x().goBowling();
4. }
If you’re super performance sensitive and you’re concerned about the overhead of an extra function
call on each invocation of X::someMethod() you can set up a static Fred& instead. As you
recall, static local are only initialized once (the first time control flows over their declaration), so
this will call X::x() only once: the first time X::someMethod() is called:
1. void X::someMethod()
2. {
3. static Fred& x = X::x();
4. x.goBowling();
5. }
Note: The static initialization order problem can also, in some cases, apply to built-in/intrinsic types.
Do I need to worry about the “static initialization order
problem” for variables of built-in/intrinsic types?
Yes.
If you initialize your built-in/intrinsic type using a function call, the static initialization order
problem is able to kill you just as bad as with user-defined/class types. For example, the following
code shows the failure:
1. #include <iostream>
2.
3. int f(); // forward declaration
4. int g(); // forward declaration
5.
6. int x = f();
7. int y = g();
8.
9. int f()
10. {
11. std::cout << "using 'y' (which is " << y << ")\n";
12. return 3*y + 7;
13. }
14.
15. int g()
16. {
17. std::cout << "initializing 'y'\n";
18. return 5;
19. }
The output of this little program will show that it uses y before initializing it. The solution, as
before, is the Construct On First Use Idiom:
1. #include <iostream>
2.
3. int f(); // forward declaration
4. int g(); // forward declaration
5.
6. int& x()
7. {
8. static int ans = f();
9. return ans;
10. }
11.
12. int& y()
13. {
14. static int ans = g();
15. return ans;
16. }
17.
18. int f()
19. {
20. std::cout << "using 'y' (which is " << y() << ")\n";
21. return 3*y() + 7;
22. }
23.
24. int g()
25. {
26. std::cout << "initializing 'y'\n";
27. return 5;
28. }
Of course you might be able to simplify this by moving the initialization code for x and y into their
respective functions:
1. #include <iostream>
2.
3. int& y(); // forward declaration
4.
5. int& x()
6. {
7. static int ans;
8.
9. static bool firstTime = true;
10. if (firstTime) {
11. firstTime = false;
12. std::cout << "using 'y' (which is " << y() << ")\n";
13. ans = 3*y() + 7;
14. }
15.
16. return ans;
17. }
18.
19. int& y()
20. {
21. static int ans;
22.
23. static bool firstTime = true;
24. if (firstTime) {
25. firstTime = false;
26. std::cout << "initializing 'y'\n";
27. ans = 5;
28. }
29.
30. return ans;
31. }
And, if you can get rid of the print statements you can further simplify these to something really
simple:
1. int& y(); // forward declaration
2.
3. int& x()
4. {
5. static int ans = 3*y() + 7;
6. return ans;
7. }
8.
9. int& y()
10. {
11. static int ans = 5;
12. return ans;
13. }
Furthermore, since y is initialized using a constant expression, it no longer needs its wrapper
function — it can be a simple variable again.
How can I handle a constructor that fails?
Throw an exception. For details, see here.
What is the “Named Parameter Idiom”?
It’s a fairly useful way to exploit method chaining.
The fundamental problem solved by the Named Parameter Idiom is that C++ only
supports positional parameters. For example, a caller of a function isn’t allowed to say, “Here’s the
value for formal parameter xyz, and this other thing is the value for formal parameter pqr.” All you
can do in C++ (and C and Java) is say, “Here’s the first parameter, here’s the second parameter,
etc.” The alternative, called named parameters and implemented in the language Ada, is especially
useful if a function takes a large number of mostly default-able parameters.
Over the years people have cooked up lots of workarounds for the lack of named parameters in C
and C++. One of these involves burying the parameter values in a string parameter then parsing this
string at run-time. This is what’s done in the second parameter of fopen(), for example. Another
 workaround is to combine all the boolean parameters in a bit-map, then the caller or’s a bunch of
bit-shifted constants together to produce the actual parameter. This is what’s done in the second
parameter of open(), for example. These approaches work, but the following technique produces
caller-code that’s more obvious, easier to write, easier to read, and is generally more elegant.
The idea, called the Named Parameter Idiom, is to change the function’s parameters to methods of a
newly created class, where all these methods return *this by reference. Then you simply rename
the main function into a parameterless “do-it” method on that class.
We’ll work an example to make the previous paragraph easier to understand.
The example will be for the “open a file” concept. Let’s say that concept logically requires a
parameter for the file’s name, and optionally allows parameters for whether the file should be
opened read-only vs. read-write vs. write-only, whether or not the file should be created if it doesn’t
already exist, whether the writing location should be at the end (“append”) or the beginning
(“overwrite”), the block-size if the file is to be created, whether the I/O is buffered or non-buffered,
the buffer-size, whether it is to be shared vs. exclusive access, and probably a few others. If we
implemented this concept using a normal function with positional parameters, the caller code would
be very difficult to read: there’d be as many as 8 positional parameters, and the caller would
probably make a lot of mistakes. So instead we use the Named Parameter Idiom.
Before we go through the implementation, here’s what the caller code might look like, assuming
you are willing to accept all the function’s default parameters:
1. File f = OpenFile("foo.txt");
That’s the easy case. Now here’s what it might look like if you want to change a bunch of the
parameters.
1. File f = OpenFile("foo.txt")
2. .readonly()
3. .createIfNotExist()
4. .appendWhenWriting()
5. .blockSize(1024)
6. .unbuffered()
7. .exclusiveAccess();
Notice how the “parameters”, if it’s fair to call them that, are in random order (they’re not
positional) and they all have names. So the programmer doesn’t have to remember the order of the
parameters, and the names are (hopefully) obvious.
So here’s how to implement it: first we create a class (OpenFile) that houses all the parameter
values as private data members. The required parameters (in this case, the only required
parameter is the file’s name) is implemented as a normal, positional parameter on OpenFile’s
constructor, but that constructor doesn’t actually open the file. Then all the optional parameters
(readonly vs. readwrite, etc.) become methods. These methods
(e.g., readonly(), blockSize(unsigned), etc.) return a reference to their this object so the
method calls can be chained.
1. class File;
2.
3. class OpenFile {
4. public:
5. OpenFile(const std::string& filename);
6. // sets all the default values for each data member
7. OpenFile& readonly(); // changes readonly_ to true
8. OpenFile& readwrite(); // changes readonly_ to false
9. OpenFile& createIfNotExist();
10. OpenFile& blockSize(unsigned nbytes);
11. // ...
12. private:
13. friend class File;
14. std::string filename_;
15. bool readonly_; // defaults to false [for example]
16. bool createIfNotExist_; // defaults to false [for example]
17. // ...
18. unsigned blockSize_; // defaults to 4096 [for example]
19. // ...
20. };
21.
22. inline OpenFile::OpenFile(const std::string& filename)
23. : filename_ (filename)
24. , readonly_ (false)
25. , createIfNotExist_ (false)
26. , blockSize_ (4096u)
27. {}
28.
29. inline OpenFile& OpenFile::readonly()
30. { readonly_ = true; return *this; }
31.
32. inline OpenFile& OpenFile::readwrite()
33. { readonly_ = false; return *this; }
34.
35. inline OpenFile& OpenFile::createIfNotExist()
36. { createIfNotExist_ = true; return *this; }
37.
38. inline OpenFile& OpenFile::blockSize(unsigned nbytes)
39. { blockSize_ = nbytes; return *this; }
The only other thing to do is make the constructor for class File to take an OpenFile object:
1. class File {
2. public:
3. File(const OpenFile& params);
4. // ...
5. };
This constructor gets the actual parameters from the OpenFile object, then actually opens the file:
1. File::File(const OpenFile& params)
2. {
3. // ...
4. }
Note that OpenFile declares File as its friend, that way OpenFile doesn’t need a bunch of
(otherwise useless) public: get methods.
Since each member function in the chain returns a reference, there is no copying of objects and the
chain is highly efficient. Furthermore, if the various member functions are inline, the generated
object code will probably be on par with C-style code that sets various members of a struct. Of
course if the member functions are not inline, there may be a slight increase in code size and a
slight decrease in performance (but only if the construction occurs on the critical path of a CPU-
bound program; this is a can of worms I’ll try to avoid opening), so it may, in this case, be a tradeoff
for making the code more reliable.
Why am I getting an error after declaring a Foo object
via Foo x(Bar())?
Because that doesn’t create a Foo object - it declares a non-member function
that returns a Foo object. The term “Most Vexing Parse” was coined by Scott Myers to describe this
situation.
 This is really going to hurt; you might want to sit down.
First, here’s a better explanation of the problem. Suppose there is a class called Bar that has a
default ctor. This might even be a library class such as std::string, but for now we’ll just call
it Bar:
1. class Bar {
2. public:
3. Bar();
4. // ...
5. };
Now suppose there’s another class called Foo that has a ctor that takes a Bar. As before, this might
be defined by someone other than you.
1. class Foo {
2. public:
3. Foo(const Bar& b); // or perhaps Foo(Bar b)
4. // ...
5. void blah();
6. // ...
7. };
Now you want to create a Foo object using a temporary Bar. In other words, you want to create an
object via Bar(), and pass that to the Foo ctor to create a local Foo object called x:
1. void yourCode()
2. {
3. Foo x(Bar()); // You think this creates a Foo object called x...
4. x.blah(); // ...But it doesn't, so this line gives you a bizarre error message
5. // ...
6. }
It’s a long story, but one solution (hope you’re sitting down!) is to add an extra pair of ()s around
the Bar() part:
1. void yourCode()
2. {
3. Foo x((Bar()));
4. ↑ ↑ // These parens save the day
5.
6. x.blah();
7. ↑↑↑↑↑↑↑↑ // Ahhhh, this now works: no more error messages
8.
9. // ...
10. }
Another solution is to use = in your declaration (see the fine print below):
1. void yourCode()
2. {
3. Foo x = Foo(Bar()); // Yes, Virginia, that thar syntax works; see below for fine print
4. x.blah(); // Ahhhh, this now works: no more error messages
5. // ...
6. }
Note: The above solution requires yourCode() to be able to access the Foo copy constructor. In
most situations that means the Foo copy constructor needs to be public, though it needn’t
be public in the less common case where yourCode() is a friend of class Foo. If you’re not
sure what any of that means, try it: if your code compiles, you passed the test.
Here’s another solution (more fine print below):
1. void yourCode()
2. {
3. Foo x = Bar(); // Usually works; see below for fine print on "usually"
4. x.blah();
5. // ...
6. }
Note: The word “usually” in the above means this: the above fails only when Foo::Foo(const
Bar&) constructor is explicit, or when Foo’s copy constructor is inaccessible (typically when it
is private or protected, and your code is not a friend). If you’re not sure what any of that
means, take 60 seconds and compile it. You are guaranteed to find out whether it works or fails at
compile-time, so if it compiles cleanly, it will work at runtime.
However, the best solution, the creation of which was at least partially motivated by the fact that this
FAQ exists, is to use uniform initialization, which replaces the () around the Bar() call
with {} instead.
1. void yourCode()
2. {
3. Foo x{Bar()};
4. x.blah(); // Ahhhh, this now works: no more error messages
5. // ...
6. }
That’s the end of the solutions; the rest of this is about why this is needed (this is optional; you can
skip this section if you don’t care enough about your career to actually understand what’s going on;
ha ha): When the compiler sees Foo x(Bar()), it thinks that the Bar() part is declaring a non-
member function that returns a Bar object, so it thinks you are declaring the existence of
a function called x that returns a Foo and that takes as a single parameter of type “non-member
function that takes nothing and returns a Bar.”
Now here’s the sad part. In fact it’s pathetic. Some mindless drone out there is going to skip that last
paragraph, then they’re going to impose a bizarre, incorrect, irrelevant, and just plain stupid coding
standard that says something like, “Never create temporaries using a default constructor” or
“Always use = in all initializations” or something else equally inane. If that’s you, please fire
yourself before you do any more damage. Those who don’t understand the problem shouldn’t tell
others how to solve it. Harumph.
(That was mostly tongue in cheek. But there’s a grain of truth in it. The real problem is that people
tend to worship consistency, and they tend to extrapolate from the obscure to the common. That’s
not wise.)

What is the purpose of the explicit keyword?

The explicit keyword is an optional decoration for constructors and conversion operators to tell
the compiler that a certain constructor or conversion operator may not be used to implicitly cast an
expression to its class type.
For example, without the explicit keyword the following code is valid:
1. class Foo {
2. public:
3. Foo(int x);
4. operator int();
5. };
6.
7. class Bar {
8. public:
9. Bar(double x);
10. operator double();
11. };
12.
13. void yourCode()
14. {
15. Foo a = 42; // Okay: calls Foo::Foo(int) passing 42 as an argument
16. Foo b(42); // Okay: calls Foo::Foo(int) passing 42 as an argument
17. Foo c = Foo(42); // Okay: calls Foo::Foo(int) passing 42 as an argument
18. Foo d = (Foo)42; // Okay: calls Foo::Foo(int) passing 42 as an argument
19. int e = d; // Okay: calls Foo::operator int()
20.
21. Bar x = 3.14; // Okay: calls Bar::Bar(double) passing 3.14 as an argument
22. Bar y(3.14); // Okay: calls Bar::Bar(double) passing 3.14 as an argument
23. Bar z = Bar(3.14); // Okay: calls Bar::Bar(double) passing 3.14 as an argument
24. Bar w = (Bar)3.14; // Okay: calls Bar::Bar(double) passing 3.14 as an argument
25. double v = w; // Okay: calls Bar::operator double()
26. }
But sometimes you want to prevent this sort of implicit promotion or implicit type conversion. For
example, if Foo is really an array-like container and 42 is the initial size, you might want to let your
users say, Foo x(42); or perhaps Foo x = Foo(42);, but not just Foo x = 42;. If that’s the
case, you should use the explicit keyword:
1. class Foo {
2. public:
3. explicit Foo(int x);
4. explicit operator int();
5. };
6.
7. class Bar {
8. public:
9. explicit Bar(double x);
10. explicit operator double();
11. };
12.
13. void yourCode()
14. {
15. Foo a = 42; // Compile-time error: can't convert 42 to an object of type Foo
16. Foo b(42); // Okay: calls Foo::Foo(int) passing 42 as an argument
17. Foo c = Foo(42); // Okay: calls Foo::Foo(int) passing 42 as an argument
18. Foo d = (Foo)42; // Okay: calls Foo::Foo(int) passing 42 as an argument
19. int e = d; // Compile-time error: can't convert d to an integer
20. int f = int(d); // Okay: calls Foo::operator int()
21.
22. Bar x = 3.14; // Compile-time error: can't convert 3.14 to an object of type Bar
23. Bar y(3.14); // Okay: calls Bar::Bar(double) passing 3.14 as an argument
24. Bar z = Bar(3.14); // Okay: calls Bar::Bar(double) passing 3.14 as an argument
25. Bar w = (Bar)3.14; // Okay: calls Bar::Bar(double) passing 3.14 as an argument
26. double v = w; // Compile-time error: can't convert w to a double
27. double u = double(w); // Okay: calls Bar::operator double()
28. }
You can mix explicit and non-explicit constructors and conversion operators in the same
class. For example, this class has an explicit constructor taking a bool but a non-
explicit constructor taking a double, and can be implicitly converted to double, but only
explicitly converted to bool:
1. #include <iostream>
2.
3. class Foo {
4. public:
5. Foo(double x) { std::cout << "Foo(double)\n"; }
6. explicit Foo(bool x) { std::cout << "Foo(bool)\n"; }
7. operator double() { std::cout << "operator double()\n"; }
8. explicit operator bool() { std::cout << "operator bool()\n"; }
9. };
10.
11. void yourCode()
12. {
13. Foo a = true; // Okay: implicitly promotes true to (double)1.0, then calls Foo::Foo(double)
14. Foo b = Foo(true); // Okay: explicitly calls Foo::Foo(bool)
15. double c = b; // Okay: implicitly calls Foo::operator double()
16. bool d = b; // Okay: calls Foo::operator double() and implicitly converts to bool
17. if(b) {} // Okay, explicitly calls Foo::operator bool()
18. }
The above code will print the following:
1. Foo(double)
2. Foo(bool)
3. operator double()
4. operator double()
5. operator bool()
Variable a is initialized using the Foo(double) constructor because Foo(bool) cannot be used in
an implicit cast, but true can be interpreted as a (double)true, that is, as 1.0, and implicitly
cast to Foo using Foo::Foo(double). This may or may not be what you intended, but this is what
happens.
Why doesn’t my constructor work right?
This is a question that comes in many forms. Such as:
 Why does the compiler copy my objects when I don’t want it to?
 How do I turn off copying?
 How do I stop implicit conversions?
 How did my int turn into a complex number?
By default a class is given a copy constructor and a copy assignment that copy all elements, and a
move constructor and a move assignment that move all elements. For example:
1. struct Point {
2. int x,y;
3. Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
4. };
5.
6. Point p1(1,2);
7. Point p2 = p1;
Here we get p2.x==p1.x and p2.y==p1.y. That’s often exactly what you want (and essential for
C compatibility), but consider:
1. class Handle {
2. private:
3. string name;
4. X* p;
5. public:
6. Handle(string n)
7. :name(n), p(0) { /* acquire X called "name" and let p point to it */ }
8. ~Handle() { delete p; /* release X called "name" */ }
9. // ...
10. };
11.
12. void f(const string& hh)
13. {
14. Handle h1(hh);
15. Handle h2 = h1; // leads to disaster!
16. // ...
17. }
 Here, the default copy gives us h2.name==h1.name and h2.p==h1.p. This leads to disaster:
when we exit f() the destructors for h1 and h2 are invoked and the object pointed to
by h1.p and h2.p is deleted twice.
How do we avoid this? The simplest solution is to mark the operations that copy as deleted:
1. class Handle {
2. private:
3. string name;
4. X* p;
5.
6. Handle(const Handle&) = delete; // prevent copying
7. Handle& operator=(const Handle&) = delete;
8. public:
9. Handle(string n)
10. :name(n), p(0) { /* acquire the X called "name" and let p point to it */ }
11. ~Handle() { delete p; /* release X called "name" */ }
12. // ...
13. };
14.
15. void f(const string& hh)
16. {
17. Handle h1(hh);
18. Handle h2 = h1; // error (reported by compiler)
19. // ...
20. }
If we need to copy or move, we can of course define the proper initializers and assignments to
provide the desired semantics.
Now return to Point. For Point the default copy semantics is fine, the problem is the constructor:
1. struct Point {
2. int x,y;
3. Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
4. };
5.
6. void f(Point);
7.
8. void g()
9. {
10. Point orig; // create orig with the default value (0,0)
11. Point p1(2); // create p1 with the default y-coordinate 0
12. f(2); // calls Point(2,0);
13. }
People provide default arguments to get the convenience used for orig and p1. Then, some are
surprised by the conversion of 2 to Point(2,0) in the call of f(). This constructor defines a
conversion. By default that’s an implicit conversion. To require such a conversion to be explicit,
declare the constructor explicit:
1. struct Point {
2. int x,y;
3. explicit Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
4. };
5.
6. void f(Point);
7.
8. void g()
9. {
10. Point orig; // create orig with the default value (0,0)
11. Point p1(2); // create p1 with the default y-coordinate 0
12. // that's an explicit call of the constructor
13. f(2); // error (attempted implicit conversion)
14. Point p2 = 2; // error (attempted implicit conversion)
15. Point p3 = Point(2); // ok (explicit conversion)
16. }

Destructors
Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the deal with destructors?

 What’s the order that local objects are destructed?
 What’s the order that objects in an array are destructed?
 What’s the order that sub-objects of an object are destructed?
 Can I overload the destructor for my class?
 Should I explicitly call a destructor on a local variable?
 What if I want a local to “die” before the close } of the scope in which it was created? Can I
call a destructor on a local if I really want to?
 Okay, okay, already; I won’t explicitly call the destructor of a local; but how do I handle the
situation from the previous FAQ?
 What if I can’t wrap the local in an artificial block?
 But can I explicitly call a destructor if I’ve allocated my object with new?
 What is “placement new” and why would I use it?
 Is there a placement delete?
 When I write a destructor, do I need to explicitly call the destructors for my member objects?
 When I write a derived class’s destructor, do I need to explicitly call the destructor for my
base class?
 Should my destructor throw an exception when it detects a problem?
 Is there a way to force new to allocate memory from a specific memory area?
What’s the deal with destructors?
A destructor gives an object its last rites.
Destructors are used to release any resources allocated by the object. E.g., class Lock might lock
a semaphore, and the destructor will release that semaphore. The most common example is when
the constructor uses new, and the destructor uses delete.
Destructors are a “prepare to die” member function. They are often abbreviated “dtor”.

What’s the order that local objects are destructed?

In reverse order of construction: First constructed, last destructed.
In the following example, b’s destructor will be executed first, then a’s destructor:
1. void userCode()
2. {
3. Fred a;
4. Fred b;
5. // ...
6. }
 What’s the order that objects in an array are
destructed?
In reverse order of construction: First constructed, last destructed.
In the following example, the order for destructors will be a[9], a[8], …, a[1], a[0]:
1. void userCode()
2. {
3. Fred a[10];
4. // ...
5. }

What’s the order that sub-objects of an object are

destructed?
In reverse order of construction: First constructed, last destructed.
The body of an object’s destructor is executed, followed by the destructors of the object’s data
members (in reverse order of their appearance in the class definition), followed by the destructors of
the object’s base classes (in reverse order of their appearance in the class definition).
In the following example, the order for destructor calls when d goes out of scope will
be ~local1(), ~local0(), ~member1(), ~member0(), ~base1(), ~base0():
1. struct base0 { ~base0(); };
2. struct base1 { ~base1(); };
3. struct member0 { ~member0(); };
4. struct member1 { ~member1(); };
5. struct local0 { ~local0(); };
6. struct local1 { ~local1(); };
7.
8. struct derived: base0, base1
9. {
10. member0 m0_;
11. member1 m1_;
12.
13. ~derived()
14. {
15. local0 l0;
16. local1 l1;
17. }
18. }
19.
20. void userCode()
21. {
22. derived d;
23. }

Can I overload the destructor for my class?

No.
You can have only one destructor for a class Fred. It’s always called Fred::~Fred(). It never
takes any parameters, and it never returns anything.
You can’t pass parameters to the destructor anyway, since you never explicitly call a
destructor (well, almost never).
Should I explicitly call a destructor on a local variable?
 No!
The destructor will get called again at the close } of the block in which the local was created. This is
a guarantee of the language; it happens automagically; there’s no way to stop it from happening. But
you can get really bad results from calling a destructor on the same object a second time! Bang!
You’re dead!
What if I want a local to “die” before the close } of the
scope in which it was created? Can I call a destructor on
a local if I really want to?
No! [For context, please read the previous FAQ].
Suppose the (desirable) side effect of destructing a local File object is to close the File. Now
suppose you have an object f of a class File and you want File f to be closed before the end of
the scope (i.e., the }) of the scope of object f:
1. void someCode()
2. {
3. File f;
4. // ...code that should execute when f is still open...
5. ← We want the side-effect of f's destructor here!
6. // ...code that should execute after f is closed...
7. }
There is a simple solution to this problem. But in the mean time, remember: Do not explicitly call the
destructor!

Okay, okay, already; I won’t explicitly call the destructor

of a local; but how do I handle the situation from the
previous FAQ?
[For context, please read the previous FAQ].
Simply wrap the extent of the lifetime of the local in an artificial block {...}:
1. void someCode()
2. {
3. {
4. File f;
5. // ...code that should execute when f is still open...
6. }
7. ↑ // f's destructor will automagically be called here!
8.
9. // ...code that should execute after f is closed...
10. }

What if I can’t wrap the local in an artificial block?

Most of the time, you can limit the lifetime of a local by wrapping the local in an artificial block
({...}). But if for some reason you can’t do that, add a member function that has a similar effect
as the destructor. But do not call the destructor itself!
For example, in the case of class File, you might add a close() method. Typically the
destructor will simply call this close() method. Note that the close() method will need to mark
the File object so a subsequent call won’t re-close an already-closed File. E.g., it might set
the fileHandle_ data member to some nonsensical value such as -1, and it might check at the
beginning to see if the fileHandle_ is already equal to -1:
1. class File {
2. public:
3. void close();
4. ~File();
5. // ...
6. private:
7. int fileHandle_; // fileHandle_ >= 0 if/only-if it's open
8. };
9.
10. File::~File()
11. {
12. close();
13. }
14.
15. void File::close()
16. {
17. if (fileHandle_ >= 0) {
18. // ...code that calls the OS to close the file...
19. fileHandle_ = -1;
20. }
21. }
Note that the other File methods may also need to check if the fileHandle_ is -1 (i.e., check if
the File is closed).
Note also that any constructors that don’t actually open a file should set fileHandle_ to -1.
But can I explicitly call a destructor if I’ve allocated my
object with new?
Probably not.
Unless you used placement new, you should simply delete the object rather than explicitly calling
the destructor. For example, suppose you allocated the object via a typical new expression:
1. Fred* p = new Fred();
Then the destructor Fred::~Fred() will automagically get called when you delete it via:
1. delete p; // Automagically calls p->~Fred()
You should not explicitly call the destructor, since doing so won’t release the memory that was
allocated for the Fred object itself. Remember: delete p does two things: it calls the destructor
and it deallocates the memory.
What is “placement new” and why would I use it?
There are many uses of placement new. The simplest use is to place an object at a particular location
in memory. This is done by supplying the place as a pointer parameter to the new part of
a new expression:
1. #include <new> // Must #include this to use "placement new"
2. #include "Fred.h" // Declaration of class Fred
3.
4. void someCode()
5. {
6. char memory[sizeof(Fred)]; // Line #1
7. void* place = memory; // Line #2
8.
9. Fred* f = new(place) Fred(); // Line #3 (see "DANGER" below)
10. // The pointers f and place will be equal
11.
12. // ...
13. }
Line #1 creates an array of sizeof(Fred) bytes of memory, which is big enough to hold
a Fred object. Line #2 creates a pointer place that points to the first byte of this memory
 (experienced C programmers will note that this step was unnecessary; it’s there only to make the
code more obvious). Line #3 essentially just calls the constructor Fred::Fred().
The this pointer in the Fred constructor will be equal to place. The returned pointer f will
therefore be equal to place.
ADVICE: Don’t use this “placement new” syntax unless you have to. Use it only when you really
care that an object is placed at a particular location in memory. For example, when your hardware
has a memory-mapped I/O timer device, and you want to place a Clock object at that memory
location.
DANGER: You are taking sole responsibility that the pointer you pass to the
“placement new” operator points to a region of memory that is big enough and is properly aligned
for the object type that you’re creating. Neither the compiler nor the run-time system make any
attempt to check whether you did this right. If your Fred class needs to be aligned on a 4 byte
boundary but you supplied a location that isn’t properly aligned, you can have a serious disaster on
your hands (if you don’t know what “alignment” means, please don’t use the
placement new syntax). You have been warned.
You are also solely responsible for destructing the placed object. This is done by explicitly calling
the destructor:
1. void someCode()
2. {
3. char memory[sizeof(Fred)];
4. void* p = memory;
5. Fred* f = new(p) Fred();
6. // ...
7. f->~Fred(); // Explicitly call the destructor for the placed object
8. }
This is about the only time you ever explicitly call a destructor.
Note: there is a much cleaner but more sophisticated way of handling the destruction / deletion
situation.
Is there a placement delete?
No, but if you need one you can write your own.
Consider placement new used to place objects in a set of arenas:
1. class Arena {
2. public:
3. void* allocate(size_t);
4. void deallocate(void*);
5. // ...
6. };
7.
8. void* operator new(size_t sz, Arena& a)
9. {
10. return a.allocate(sz);
11. }
12.
13. Arena a1(some arguments);
14. Arena a2(some arguments);
Given that, we can write
1. X* p1 = new(a1) X;
2. Y* p2 = new(a1) Y;
3. Z* p3 = new(a2) Z;
4. // ...
 But how can we later delete those objects correctly? The reason that there is no built-in
“placement delete” to match placement new is that there is no general way of assuring that it
would be used correctly. Nothing in the C++ type system allows us to deduce that p1 points to an
object allocated in Arena a1. A pointer to any X allocated anywhere can be assigned to p1.
However, sometimes the programmer does know, and there is a way:
1. template<class T> void destroy(T* p, Arena& a)
2. {
3. if (p) {
4. p->~T(); // explicit destructor call
5. a.deallocate(p);
6. }
7. }
Now, we can write:
1. destroy(p1,a1);
2. destroy(p2,a2);
3. destroy(p3,a3);
If an Arena keeps track of what objects it holds, you can even write destroy() to defend itself
against mistakes.
It is also possible to define matching operator new() and operator delete() pairs for a
class hierarchy TC++PL(SE) 15.6. See also D&E 10.4 and TC++PL(SE) 19.4.5.
When I write a destructor, do I need to explicitly call the
destructors for my member objects?
No. You never need to explicitly call a destructor (except with placement new).
A class’s destructor (whether or not you explicitly define one) automagically invokes the destructors
for member objects. They are destroyed in the reverse order they appear within the declaration for
the class.
1. class Member {
2. public:
3. ~Member();
4. // ...
5. };
6.
7. class Fred {
8. public:
9. ~Fred();
10. // ...
11. private:
12. Member x_;
13. Member y_;
14. Member z_;
15. };
16.
17. Fred::~Fred()
18. {
19. // Compiler automagically calls z_.~Member()
20. // Compiler automagically calls y_.~Member()
21. // Compiler automagically calls x_.~Member()
22. }

When I write a derived class’s destructor, do I need to

explicitly call the destructor for my base class?
 No. You never need to explicitly call a destructor (except with placement new).
A derived class’s destructor (whether or not you explicitly define one) automagically invokes the
destructors for base class subobjects. Base classes are destructed after member objects. In the event
of multiple inheritance, direct base classes are destructed in the reverse order of their appearance in
the inheritance list.
1. class Member {
2. public:
3. ~Member();
4. // ...
5. };
6.
7. class Base {
8. public:
9. virtual ~Base(); // A virtual destructor
10. // ...
11. };
12.
13. class Derived : public Base {
14. public:
15. ~Derived();
16. // ...
17. private:
18. Member x_;
19. };
20.
21. Derived::~Derived()
22. {
23. // Compiler automagically calls x_.~Member()
24. // Compiler automagically calls Base::~Base()
25. }
Note: Order dependencies with virtual inheritance are trickier. If you are relying on order
dependencies in a virtual inheritance hierarchy, you’ll need a lot more information than is in this
FAQ.
Should my destructor throw an exception when it detects
a problem?
Beware!!! See this FAQ for details.
Is there a way to force new to allocate memory from a
specific memory area?
Yes. The good news is that these “memory pools” are useful in a number of situations. The bad
news is that I’ll have to drag you through the mire of how it works before we discuss all the uses.
But if you don’t know about memory pools, it might be worthwhile to slog through this FAQ — you
might learn something useful!
First of all, recall that a memory allocator is simply supposed to return uninitialized bits of memory;
it is not supposed to produce “objects.” In particular, the memory allocator is not supposed to set the
virtual-pointer or any other part of the object, as that is the job of the constructor which runs after
the memory allocator. Starting with a simple memory allocator function, allocate(), you would
use placement new to construct an object in that memory. In other words, the following is morally
equivalent to new Foo():
1. void* raw = allocate(sizeof(Foo)); // line 1
2. Foo* p = new(raw) Foo(); // line 2
 Assuming you’ve used placement new and have survived the above two lines of code, the next step
is to turn your memory allocator into an object. This kind of object is called a “memory pool” or a
“memory arena.” This lets your users have more than one “pool” or “arena” from which memory
will be allocated. Each of these memory pool objects will allocate a big chunk of memory using
some specific system call (e.g., shared memory, persistent memory, stack memory, etc.; see below),
and will dole it out in little chunks as needed. Your memory-pool class might look something like
this:
1. class Pool {
2. public:
3. void* alloc(size_t nbytes);
4. void dealloc(void* p);
5. private:
6. // ...data members used in your pool object...
7. };
8.
9. void* Pool::alloc(size_t nbytes)
10. {
11. // ...your algorithm goes here...
12. }
13.
14. void Pool::dealloc(void* p)
15. {
16. // ...your algorithm goes here...
17. }
Now one of your users might have a Pool called pool, from which they could allocate objects like
this:
1. Pool pool;
2. // ...
3. void* raw = pool.alloc(sizeof(Foo));
4. Foo* p = new(raw) Foo();
Or simply:
1. Foo* p = new(pool.alloc(sizeof(Foo))) Foo();
The reason it’s good to turn Pool into a class is because it lets users create N different pools of
memory rather than having one massive pool shared by all users. That allows users to do lots of
funky things. For example, if they have a chunk of the system that allocates memory like crazy then
goes away, they could allocate all their memory from a Pool, then not even bother doing
any deletes on the little pieces: just deallocate the entire pool at once. Or they could set up a
“shared memory” area (where the operating system specifically provides memory that is shared
between multiple processes) and have the pool dole out chunks of shared memory rather than
process-local memory. Another angle: many systems support a non-standard function often
called alloca() which allocates a block of memory from the stack rather than the heap. Naturally
this block of memory automatically goes away when the function returns, eliminating the need for
explicit deletes. Someone could use alloca() to give the Pool its big chunk of memory, then
all the little pieces allocated from that Pool act like they’re local: they automatically vanish when
the function returns. Of course the destructors don’t get called in some of these cases, and if the
destructors do something nontrivial you won’t be able to use these techniques, but in cases where
the destructor merely deallocates memory, these sorts of techniques can be useful.
Assuming you survived the 6 or 8 lines of code needed to wrap your allocate function as a method
of a Pool class, the next step is to change the syntax for allocating objects. The goal is to change
from the rather clunky syntax new(pool.alloc(sizeof(Foo))) Foo() to the simpler
syntax new(pool) Foo(). To make this happen, you need to add the following two lines of code
just below the definition of your Pool class:
1. inline void* operator new(size_t nbytes, Pool& pool)
2. {
3. return pool.alloc(nbytes);
4. }
Now when the compiler sees new(pool) Foo(), it calls the above operator new and
passes sizeof(Foo) and pool as parameters, and the only function that ends up using the
funky pool.alloc(nbytes) method is your own operator new.
Now to the issue of how to destruct/deallocate the Foo objects. Recall that the brute force approach
sometimes used with placement new is to explicitly call the destructor then explicitly deallocate the
memory:
1. void sample(Pool& pool)
2. {
3. Foo* p = new(pool) Foo();
4. // ...
5. p->~Foo(); // explicitly call dtor
6. pool.dealloc(p); // explicitly release the memory
7. }
This has several problems, all of which are fixable:
1. The memory will leak if Foo::Foo() throws an exception.
2. The destruction/deallocation syntax is different from what most programmers are used to, so
they’ll probably screw it up.
3. Users must somehow remember which pool goes with which object. Since the code that
allocates is often in a different function from the code that deallocates, programmers will have to
pass around two pointers (a Foo* and a Pool*), which gets ugly fast (example, what if they had
an array of Foos each of which potentially came from a different Pool; ugh).
We will fix them in the above order.
Problem #1: plugging the memory leak. When you use the “normal” new operator, e.g., Foo* p =
new Foo(), the compiler generates some special code to handle the case when the constructor
throws an exception. The actual code generated by the compiler is functionally similar to this:
1. // This is functionally what happens with Foo* p = new Foo()
2.
3. Foo* p;
4.
5. // don't catch exceptions thrown by the allocator itself
6. void* raw = operator new(sizeof(Foo));
7.
8. // catch any exceptions thrown by the ctor
9. try {
10. p = new(raw) Foo(); // call the ctor with raw as this
11. }
12. catch (...) {
13. // oops, ctor threw an exception
14. operator delete(raw);
15. throw; // rethrow the ctor's exception
16. }
The point is that the compiler deallocates the memory if the ctor throws an exception. But in the
case of the “new with parameter” syntax (commonly called “placement new”), the compiler won’t
know what to do if the exception occurs so by default it does nothing:
1. // This is functionally what happens with Foo* p = new(pool) Foo():
2.
3. void* raw = operator new(sizeof(Foo), pool);
4. // the above function simply returns "pool.alloc(sizeof(Foo))"
5.
6. Foo* p = new(raw) Foo();
7. // if the above line "throws", pool.dealloc(raw) is NOT called
So the goal is to force the compiler to do something similar to what it does with the
global new operator. Fortunately it’s simple: when the compiler sees new(pool) Foo(), it looks
for a corresponding operator delete. If it finds one, it does the equivalent of wrapping the ctor
call in a try block as shown above. So we would simply provide an operator delete with the
following signature (be careful to get this right; if the second parameter has a different type from the
second parameter of the operator new(size_t, Pool&), the compiler doesn’t complain; it
simply bypasses the try block when your users say new(pool) Foo()):
1. void operator delete(void* p, Pool& pool)
2. {
3. pool.dealloc(p);
4. }
After this, the compiler will automatically wrap the ctor calls of your new expressions in
a try block:
1. // This is functionally what happens with Foo* p = new(pool) Foo()
2.
3. Foo* p;
4.
5. // don't catch exceptions thrown by the allocator itself
6. void* raw = operator new(sizeof(Foo), pool);
7. // the above simply returns "pool.alloc(sizeof(Foo))"
8.
9. // catch any exceptions thrown by the ctor
10. try {
11. p = new(raw) Foo(); // call the ctor with raw as this
12. }
13. catch (...) {
14. // oops, ctor threw an exception
15. operator delete(raw, pool); // that's the magical line!!
16. throw; // rethrow the ctor's exception
17. }
In other words, the one-liner function operator delete(void* p, Pool& pool) causes the
compiler to automagically plug the memory leak. Of course that function can be, but doesn’t have to
be, inline.
Problems #2 (“ugly therefore error prone”) and #3 (“users must manually associate pool-pointers with the
object that allocated them, which is error prone”) are solved simultaneously with an additional 10-20
lines of code in one place. In other words, we add 10-20 lines of code in one place
(your Pool header file) and simplify an arbitrarily large number of other places (every piece of code
that uses your Pool class).
The idea is to implicitly associate a Pool* with every allocation. The Pool* associated with the
global allocator would be NULL, but at least conceptually you could say every allocation has an
associated Pool*. Then you replace the global operator delete so it looks up the
associated Pool*, and if non-NULL, calls that Pool’s deallocate function. For example, if(!) the
normal deallocator used free(), the replacment for the global operator delete would look
something like this:
1. void operator delete(void* p)
2. {
3. if (p != NULL) {
4. Pool* pool = /* somehow get the associated 'Pool*' */;
5. if (pool == NULL)
6. free(p);
7. else
8. pool->dealloc(p);
9. }
10. }
If you’re not sure if the normal deallocator was free(), the easiest approach is also replace the
global operator new with something that uses malloc(). The replacement for the
global operator new would look something like this (note: this definition ignores a few details
such as the new_handler loop and the throw std::bad_alloc() that happens if we run out of
memory):
1. void* operator new(size_t nbytes)
2. {
3. if (nbytes == 0)
4. nbytes = 1; // so all alloc's get a distinct address
5. void* raw = malloc(nbytes);
6. // ...somehow associate the NULL 'Pool*' with 'raw'...
7. return raw;
8. }
The only remaining problem is to associate a Pool* with an allocation. One approach, used in at
least one commercial product, is to use a std::map<void*,Pool*>. In other words, build a look-
up table whose keys are the allocation-pointer and whose values are the associated Pool*. For
reasons I’ll describe in a moment, it is essential that you insert a key/value pair into the
map only in operator new(size_t,Pool&). In particular, you must not insert a key/value pair
from the global operator new (e.g., you must not say, poolMap[p] = NULL in the
global operator new). Reason: doing that would create a nasty chicken-and-egg problem —
since std::map probably uses the global operator new, it ends up inserting a new entry every
time inserts a new entry, leading to infinite recursion — bang you’re dead.
Even though this technique requires a std::map look-up for each deallocation, it seems to have
acceptable performance, at least in many cases.
Another approach that is faster but might use more memory and is a little trickier is to prepend
a Pool* just before all allocations. For example, if nbytes was 24, meaning the caller was asking
to allocate 24 bytes, we would allocate 28 (or 32 if you think the machine requires 8-byte alignment
for things like doubles and/or long longs), stuff the Pool* into the first 4 bytes, and return the
pointer 4 (or 8) bytes from the beginning of what you allocated. Then your global operator
delete backs off the 4 (or 8) bytes, finds the Pool*, and if NULL, uses free() otherwise
calls pool->dealloc(). The parameter passed to free() and pool->dealloc() would be the
pointer 4 (or 8) bytes to the left of the original parameter, p. If(!) you decide on 4 byte alignment,
your code would look something like this (although as before, the following operator new code
elides the usual out-of-memory handlers):
1. void* operator new(size_t nbytes)
2. {
3. if (nbytes == 0)
4. nbytes = 1; // so all alloc's get a distinct address
5. void* ans = malloc(nbytes + 4); // overallocate by 4 bytes
6. *(Pool**)ans = NULL; // use NULL in the global new
7. return (char*)ans + 4; // don't let users see the Pool*
8. }
9.
10. void* operator new(size_t nbytes, Pool& pool)
11. {
12. if (nbytes == 0)
13. nbytes = 1; // so all alloc's get a distinct address
14. void* ans = pool.alloc(nbytes + 4); // overallocate by 4 bytes
15. *(Pool**)ans = &pool; // put the Pool* here
16. return (char*)ans + 4; // don't let users see the Pool*
17. }
18.
19. void operator delete(void* p)
20. {
21. if (p != NULL) {
22. p = (char*)p - 4; // back off to the Pool*
23. Pool* pool = *(Pool**)p;
24. if (pool == NULL)
25. free(p); // note: 4 bytes left of the original p
26. else
27. pool->dealloc(p); // note: 4 bytes left of the original p
28. }
29. }
Naturally the last few paragraphs of this FAQ are viable only when you are allowed to change the
global operator new and operator delete. If you are not allowed to change these global
functions, the first three quarters of this FAQ is still applicable.

Assignment Operators
Save to:
InstapaperPocketReadability
Contents of this section:

 What is “self assignment”?

 Why should I worry about “self assignment”?
 Okay, okay, already; I’ll handle self-assignment. How do I do it?
 I’m creating a derived class; should my assignment operators call my base class’s assignment
operators?
What is “self assignment”?
Self assignment is when someone assigns an object to itself. For example,
1. #include "Fred.h" // Defines class Fred
2.
3. void userCode(Fred& x)
4. {
5. x = x; // Self-assignment
6. }
Obviously no one ever explicitly does a self assignment like the above, but since more than one
pointer or reference can point to the same object (aliasing), it is possible to have self assignment
without knowing it:
1. #include "Fred.h" // Defines class Fred
2.
3. void userCode(Fred& x, Fred& y)
4. {
5. x = y; // Could be self-assignment if &x == &y
6. }
7.
8. int main()
9. {
10. Fred z;
11. userCode(z, z);
12. // ...
13. }
This is only valid for copy assignment. Self-assignment is not valid for move assignment.
 Why should I worry about “self assignment”?
If you don’t worry about self assignment, you’ll expose your users to some very subtle bugs that
have very subtle and often disastrous symptoms. For example, the following class will cause a
complete disaster in the case of self-assignment:
1. class Wilma { };
2.
3. class Fred {
4. public:
5. Fred() : p_(new Wilma()) {}
6. Fred(const Fred& f) : p_(new Wilma(*f.p_)) { }
7. ~Fred() { delete p_; }
8. Fred& operator= (const Fred& f)
9. {
10. // Bad code: Doesn't handle self-assignment!
11. delete p_; // Line #1
12. p_ = new Wilma(*f.p_); // Line #2
13. return *this;
14. }
15. private:
16. Wilma* p_;
17. };
If someone assigns a Fred object to itself, line #1 deletes both this-
>p_ and f.p_ since *this and f are the same object. But line #2 uses *f.p_, which is no longer a
valid object. This will likely cause a major disaster.
The bottom line is that you the author of class Fred are responsible to make sure self-assignment on
a Fred object is innocuous. Do not assume that users won’t ever do that to your objects. It
is your fault if your object crashes when it gets a self-assignment.
Aside: the above Fred::operator= (const Fred&) has a second problem: If an exception is
thrown while evaluating new Wilma(*f.p_) (e.g., an out-of-memory exception or an exception
in Wilma’s copy constructor), this->p_ will be a dangling pointer — it will point to memory that
is no longer valid. This can be solved by allocating the new objects before deleting the old objects.
This is only valid for copy assignment. Self-assignment is not valid for move assignment.

Okay, okay, already; I’ll handle self-assignment. How do I

do it?
You should worry about self assignment every time you create a class. This does not mean that you
need to add extra code to all your classes: as long as your objects gracefully handle self assignment,
it doesn’t matter whether you had to add extra code or not.
We will illustrate the two cases using the assignment operator in the previous FAQ:
1. If self-assignment can be handled without any extra code, don’t add any extra code. But do
add a comment so others will know that your assignment operator gracefully handles self-
assignment:
Example 1a:
1. Fred& Fred::operator= (const Fred& f)
2. {
3. // This gracefully handles self assignment
4. *p_ = *f.p_;
5. return *this;
6. }
Example 1b:
 7. Fred& Fred::operator= (const Fred& f)
8. {
9. // This gracefully handles self assignment
10. Wilma* tmp = new Wilma(*f.p_); // No corruption if this line threw an exception
11. delete p_;
12. p_ = tmp;
13. return *this;
14. }
2. If you need to add extra code to your assignment operator, here’s a simple and effective
technique:
1. Fred& Fred::operator= (const Fred& f)
2. {
3. if (this == &f) return *this; // Gracefully handle self assignment
4. // Put the normal assignment duties here...
5. return *this;
6. }
Or equivalently:
7. Fred& Fred::operator= (const Fred& f)
8. {
9. if (this != &f) { // Gracefully handle self assignment
10. // Put the normal assignment duties here...
11. }
12. return *this;
13. }
By the way: the goal is not to make self-assignment fast. If you don’t need to explicitly test for self-
assignment, for example, if your code works correctly (even if slowly) in the case of self-
assignment, then do not put an if test in your assignment operator just to make the self-assignment
case fast. The reason is simple: self-assignment is almost always rare, so it merely needs to be
correct - it does not need to be efficient. Adding the unnecessary if statement would make a rare
case faster by adding an extra conditional-branch to the normal case, punishing the many to benefit
the few.
In this case, however, you should add a comment at the top of your assignment operator indicating
that the rest of the code makes self-assignment is benign, and that is why you didn’t explicitly test
for it. That way future maintainers will know to make sure self-assignment stays benign, or if not,
they will need to add the if test.
This is only valid for copy assignment. Self-assignment is not valid for move assignment.

I’m creating a derived class; should my assignment

operators call my base class’s assignment operators?
Yes (if you need to define assignment operators in the first place).
If you define your own assignment operators, the compiler will not automatically call your base
class’s assignment operators for you. Unless your base class’s assignment operators themselves are
broken, you should call them explicitly from your derived class’s assignment operators (again,
assuming you create them in the first place).
However if you do not create your own assignment operators, the ones that the compiler create for
you will automatically call your base class’s assignment operators.
Example:
1. class Base {
2. // ...
3. };
4.
5. class Derived : public Base {
6. public:
7. // ...
8. Derived& operator= (const Derived& d);
9. Derived& operator= (Derived&& d);
10. // ...
11. };
12.
13. Derived& Derived::operator= (const Derived& d)
14. {
15. // Make sure self-assignment is benign
16. Base::operator= (d);
17.
18. // Do the rest of your assignment operator here...
19. return *this;
20. }
21.
22. Derived& Derived::operator= (Derived&& d)
23. {
24. // self-assignment is not allowed in move assignment
25. Base::operator= (std::move(d));
26.
27. // Do the rest of your assignment operator here...
28. return *this;
29. }

Operator Overloading
Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the deal with operator overloading?

 What are the benefits of operator overloading?
 What are some examples of operator overloading?
 But operator overloading makes my class look ugly; isn’t it supposed to make my code
clearer?
 What operators can/cannot be overloaded?
 Why can’t I overload . (dot), ::, sizeof, etc.?
 Can I define my own operators?
 Can I overload operator== so it lets me compare two char[] using a string comparison?
 Can I create a operator** for “to-the-power-of” operations?
 The previous FAQs tell me which operators I can override; but which operators should I
override?
 What are some guidelines / “rules of thumb” for overloading operators?
 How do I create a subscript operator for a Matrix class?
 Why shouldn’t my Matrix class’s interface look like an array-of-array?
 I still don’t get it. Why shouldn’t my Matrix class’s interface look like an array-of-array?
 Should I design my classes from the outside (interfaces first) or from the inside (data first)?
 How can I overload the prefix and postfix forms of operators ++ and --?
 Which is more efficient: i++ or ++i?
What’s the deal with operator overloading?
 It allows you to provide an intuitive interface to users of your class, plus makes it possible
for templates to work equally well with classes and built-in/intrinsic types.
Operator overloading allows C/C++ operators to have user-defined meanings on user-defined types
(classes). Overloaded operators are syntactic sugar for function calls:
1. class Fred {
2. public:
3. // ...
4. };
5.
6. #if 0
7.
8. // Without operator overloading:
9. Fred add(const Fred& x, const Fred& y);
10. Fred mul(const Fred& x, const Fred& y);
11.
12. Fred f(const Fred& a, const Fred& b, const Fred& c)
13. {
14. return add(add(mul(a,b), mul(b,c)), mul(c,a)); // Yuk...
15. }
16.
17. #else
18.
19. // With operator overloading:
20. Fred operator+ (const Fred& x, const Fred& y);
21. Fred operator* (const Fred& x, const Fred& y);
22.
23. Fred f(const Fred& a, const Fred& b, const Fred& c)
24. {
25. return a*b + b*c + c*a;
26. }
27.
28. #endif

What are the benefits of operator overloading?

By overloading standard operators on a class, you can exploit the intuition of the users of that class.
This lets users program in the language of the problem domain rather than in the language of the
machine.
The ultimate goal is to reduce both the learning curve and the defect rate.

What are some examples of operator overloading?

Here are a few of the many examples of operator overloading:
 myString + yourString might concatenate two std::string objects
 myDate++ might increment a Date object
 a * b might multiply two Number objects
 a[i] might access an element of an Array object
 x = *p might dereference a “smart pointer” that “points” to a disk record — it could seek to
the location on disk where p “points” and return the appropriate record into x
But operator overloading makes my class look ugly; isn’t
it supposed to make my code clearer?
Operator overloading makes life easier for the users of a class, not for the developer of the class!
 Consider the following example.
1. class Array {
2. public:
3. int& operator[] (unsigned i); // Some people don't like this syntax
4. // ...
5. };
6.
7. inline
8. int& Array::operator[] (unsigned i) // Some people don't like this syntax
9. {
10. // ...
11. }
Some people don’t like the keyword operator or the somewhat funny syntax that goes with it in
the body of the class itself. But the operator overloading syntax isn’t supposed to make life easier
for the developer of a class. It’s supposed to make life easier for the users of the class:
1. int main()
2. {
3. Array a;
4. a[3] = 4; // User code should be obvious and easy to understand...
5. // ...
6. }
Remember: in a reuse-oriented world, there will usually be many people who use your class, but
there is only one person who builds it (yourself); therefore you should do things that favor the many
rather than the few.

What operators can/cannot be overloaded?

Most can be overloaded. The only C operators that can’t be are . and ?: (and sizeof, which is
technically an operator). C++ adds a few of its own operators, most of which can be overloaded
except :: and .*.
Here’s an example of the subscript operator (it returns a reference). First
without operator overloading:
1. class Array {
2. public:
3. int& elem(unsigned i) { if (i > 99) error(); return data[i]; }
4. private:
5. int data[100];
6. };
7.
8. int main()
9. {
10. Array a;
11. a.elem(10) = 42;
12. a.elem(12) += a.elem(13);
13. // ...
14. }
Now the same logic is presented with operator overloading:
1. class Array {
2. public:
3. int& operator[] (unsigned i) { if (i > 99) error(); return data[i]; }
4. private:
5. int data[100];
6. };
7.
8. int main()
9. {
10. Array a;
11. a[10] = 42;
12. a[12] += a[13];
13. // ...
14. }

Why can’t I overload . (dot), ::, sizeof, etc.?

Most operators can be overloaded by a programmer. The exceptions are
1. . (dot) :: ?: sizeof
There is no fundamental reason to disallow overloading of ?:. So far the committee just hasn’t seen
the need to introduce the special case of overloading a ternary operator. Note that a function
overloading expr1?expr2:expr3 would not be able to guarantee that only one
of expr2 and expr3 was executed.
sizeof cannot be overloaded because built-in operations, such as incrementing a pointer into an
array implicitly depends on it. Consider:
1. X a[10];
2. X* p = &a[3];
3. X* q = &a[3];
4. p++; // p points to a[4]
5. // thus the integer value of p must be
6. // sizeof(X) larger than the integer value of q
Thus, sizeof(X) could not be given a new and different meaning by the programmer without
violating basic language rules.
What about ::? In N::m neither N nor m are expressions with values; N and m are names known to
the compiler and :: performs a (compile time) scope resolution rather than an expression
evaluation. One could imagine allowing overloading of x::y where x is an object rather than a
namespace or a class, but that would – contrary to first appearances – involve introducing new
syntax (to allow expr::expr). It is not obvious what benefits such a complication would bring.
operator. (dot) could in principle be overloaded using the same technique as used for ->.
However, doing so can lead to questions about whether an operation is meant for the object
overloading . or an object referred to by .. For example:
1. class Y {
2. public:
3. void f();
4. // ...
5. };
6.
7. class X { // assume that you can overload .
8. Y* p;
9. Y& operator.() { return *p; }
10. void f();
11. // ...
12. };
13.
14. void g(X& x)
15. {
16. x.f(); // X::f or Y::f or error?
17. }
This problem can be solved in several ways. So far in standardization, it has not been obvious which
way would be best. For more details, see D&E.
Can I define my own operators?
 Sorry, no. The possibility has been considered several times, but each time it was decided that the
likely problems outweighed the likely benefits.
It’s not a language-technical problem. Even when Stroustrup first considered it in 1983, he knew
how it could be implemented. However, the experience has been that when we go beyond the most
trivial examples people seem to have subtly different opinions of “the obvious” meaning of uses of
an operator. A classical example is a**b**c. Assume that ** has been made to mean
exponentiation. Now should a**b**c mean (a**b)**c or a**(b**c)? Experts have thought the
answer was obvious and their friends agreed – and then found that they didn’t agree on which
resolution was the obvious one. Such problems seem prone to lead to subtle bugs.
Can I overload operator== so it lets me compare
two char[] using a string comparison?
No: at least one operand of any overloaded operator must be of some user-defined type (most of
the time that means a class).
But even if C++ allowed you to do this, which it doesn’t, you wouldn’t want to do it anyway since
you really should be using a std::string-like class rather than an array of char in the first
place since arrays are evil.
Can I create a operator** for “to-the-power-of”
operations?
Nope.
The names of, precedence of, associativity of, and arity of operators is fixed by the language. There
is no operator** in C++, so you cannot create one for a class type.
If you’re in doubt, consider that x ** y is the same as x * (*y) (in other words, the compiler
assumes y is a pointer). Besides, operator overloading is just syntactic sugar for function calls.
Although this particular syntactic sugar can be very sweet, it doesn’t add anything fundamental. I
suggest you overload pow(base,exponent) (a double precision version is in <cmath>).
By the way, operator^ can work for to-the-power-of, except it has the wrong precedence and
associativity.
The previous FAQs tell me which operators I can override;
but which operators should I override?
Bottom line: don’t confuse your users.
Remember the purpose of operator overloading: to reduce the cost and defect rate in code that uses
your class. If you create operators that confuse your users (because they’re cool, because they make
the code faster, because you need to prove to yourself that you can do it; doesn’t really matter why),
you’ve violated the whole reason for using operator overloading in the first place.

What are some guidelines / “rules of thumb” for

overloading operators?
Here are a few guidelines / rules of thumb (but be sure to read the previous FAQ before reading this
list):
1. Use common sense. If your overloaded operator makes life easier and safer for your users, do
it; otherwise don’t. This is the most important guideline. In fact it is, in a very real sense, the only
guideline; the rest are just special cases.
2. If you define arithmetic operators, maintain the usual arithmetic identities. For example, if
your class defines x + y and x - y, then x + y - y ought to return an object that is
behaviorally equivalent to x. The term behaviorally equivalent is defined in the bullet on x ==
y below, but simply put, it means the two objects should ideally act like they have the same state.
This should be true even if you decide not to define an == operator for objects of your class.
3. You should provide arithmetic operators only when they make logical sense to users.
Subtracting two dates makes sense, logically returning the duration between those dates, so you
might want to allow date1 - date2 for objects of your Date class (provided you have a
reasonable class/type to represent the duration between two Date objects). However adding two
dates makes no sense: what does it mean to add July 4, 1776 to June 5, 1959? Similarly it makes
no sense to multiply or divide dates, so you should not define any of those operators.
4. You should provide mixed-mode arithmetic operators only when they make logical sense to
users. For example, it makes sense to add a duration (say 35 days) to a date (say July 4, 1776), so
you might define date + duration to return a Date. Similarly date - duration could also
return a Date. But duration - date does not make sense at the conceptual level (what does it
mean to subtract July 4, 1776 from 35 days?) so you should not define that operator.
5. If you provide constructive operators, they should return their result by value. For example, x
+ y should return its result by value. If it returns by reference, you will probably run into lots of
problems figuring out who owns the referent and when the referent will get destructed. Doesn’t
matter if returning by reference is more efficient; it is probably wrong. See the next bullet for more
on this point.
6. If you provide constructive operators, they should not change their operands. For example, x
+ y should not change x. For some crazy reason, programmers often define x + y to be logically
the same as x += y because the latter is faster. But remember, your users expect x + y to make a
copy. In fact they selected the + operator (over, say, the += operator) precisely because
they wanted a copy. If they wanted to modify x, they would have used whatever is equivalent to x
+= y instead. Don’t make semantic decisions for your users; it’s their decision, not yours,
whether they want the semantics of x + y vs. x += y. Tell them that one is faster if you want,
but then step back and let them make the final decision — they know what they’re trying to
achieve and you do not.
7. If you provide constructive operators, they should allow promotion of the left-hand operand
(at least in the case where the class has a single-parameter ctor that is not marked
with the explicit keyword). For example, if your class Fraction supports promotion
from int to Fraction (via the non-explicit ctor Fraction::Fraction(int)), and if you
allow x - y for two Fraction objects, you should also allow 42 - y. In practice that simply
means that your operator-() should not be a member function of Fraction. Typically you
will make it a friend, if for no other reason than to force it into the public: part of the class, but
even if it is not a friend, it should not be a member.
8. In general, your operator should change its operand(s) if and only if the operands get changed
when you apply the same operator to intrinsic types. x == y and x << y should not change
either operand; x *= y and x <<= y should (but only the left-hand operand).
9. If you define x++ and ++x, maintain the usual identities. For example, x++ and ++x should
have the same observable effect on x, and should differ only in what they return. ++x should
return x by reference; x++ should either return a copy (by value) of the original state of x or
should have a void return-type. You’re usually better off returning a copy of the original state
of x by value, especially if your class will be used in generic algorithms. The easy way to do that
is to implement x++ using three lines: make a local copy of *this, call ++x (i.e., this-
>operator++()), then return the local copy. Similar comments for x-- and --x.
10. If you define ++x and x += 1, maintain the usual identities. For example, these expressions
should have the same observable behavior, including the same result. Among other things, that
means your += operator should return x by reference. Similar comments for --x and x -= 1.
11. If you define *p and p[0] for pointer-like objects, maintain the usual identities. For
example, these two expressions should have the same result and neither should change p.
12. If you define p[i] and *(p+i) for pointer-like objects, maintain the usual identities. For
example, these two expressions should have the same result and neither should change p. Similar
comments for p[-i] and *(p-i).
13. Subscript operators generally come in pairs; see on const-overloading.
14. If you define x == y, then x == y should be true if and only if the two objects are
behaviorally equivalent. In this bullet, the term “behaviorally equivalent” means the observable
behavior of any operation or sequence of operations applied to x will be the same as when applied
to y. The term “operation” means methods, friends, operators, or just about anything else you can
do with these objects (except, of course, the address-of operator). You won’t always be able to
achieve that goal, but you ought to get close, and you ought to document any variances (other
than the address-of operator).
15. If you define x == y and x = y, maintain the usual identities. For example, after an
assignment, the two objects should be equal. Even if you don’t define x == y, the two objects
should be behaviorally equivalent (see above for the meaning of that phrase) after an assignment.
16. If you define x == y and x != y, you should maintain the usual identities. For example,
these expressions should return something convertible to bool, neither should change its
operands, and x == y should have the same result as !(x != y), and vice versa.
17. If you define inequality operators like x <= y and x < y, you should maintain the usual
identities. For example, if x < y and y < z are both true, then x < z should also be true, etc.
Similar comments for x >= y and x > y.
18. If you define inequality operators like x < y and x >= y, you should maintain the usual
identities. For example, x < y should have the result as !(x >= y). You can’t always do that,
but you should get close and you should document any variances. Similar comments for x >
y and !(x <= y), etc.
19. Avoid overloading short-circuiting operators: x || y or x && y. The overloaded versions
of these do not short-circuit — they evaluate both operands even if the left-hand operand
“determines” the outcome, so that confuses users.
20. Avoid overloading the comma operator: x, y. The overloaded comma operator does not
have the same ordering properties that it has when it is not overloaded, and that confuses users.
21. Don’t overload an operator that is non-intuitive to your users. This is called the Doctrine of
Least Surprise. For example, although C++ uses std::cout << x for printing, and although
printing is technically called inserting, and although inserting sort of sounds like what happens
when you push an element onto a stack, don’t overload myStack << x to push an element onto
a stack. It might make sense when you’re really tired or otherwise mentally impaired, and a few
of your friends might think it’s “kewl,” but just say No.
22. Use common sense. If you don’t see “your” operator listed here, you can figure it out. Just
remember the ultimate goals of operator overloading: to make life easier for your users, in
particular to make their code cheaper to write and more obvious.
Caveat: the list is not exhaustive. That means there are other entries that you might consider
“missing.” I know.
Caveat: the list contains guidelines, not hard and fast rules. That means almost all of the entries have
exceptions, and most of those exceptions are not explicitly stated. I know.
Caveat: please don’t email me about the additions or exceptions. I’ve already spent way too much
time on this particular answer.
 How do I create a subscript operator for
a Matrix class?
Use operator() rather than operator[].
When you have multiple subscripts, the cleanest way to do it is with operator() rather than
with operator[]. The reason is that operator[] always takes exactly one parameter,
but operator() can take any number of parameters (in the case of a rectangular matrix, two
parameters are needed).
For example:
1. class Matrix {
2. public:
3. Matrix(unsigned rows, unsigned cols);
4. double& operator() (unsigned row, unsigned col); // Subscript operators often come in pairs
5. double operator() (unsigned row, unsigned col) const; // Subscript operators often come in pairs
6. // ...
7. ~Matrix(); // Destructor
8. Matrix(const Matrix& m); // Copy constructor
9. Matrix& operator= (const Matrix& m); // Assignment operator
10. // ...
11. private:
12. unsigned rows_, cols_;
13. double* data_;
14. };
15.
16. inline
17. Matrix::Matrix(unsigned rows, unsigned cols)
18. : rows_ (rows)
19. , cols_ (cols)
20. //, data_ ← initialized below after the if...throw statement
21. {
22. if (rows == 0 || cols == 0)
23. throw BadIndex("Matrix constructor has 0 size");
24. data_ = new double[rows * cols];
25. }
26.
27. inline
28. Matrix::~Matrix()
29. {
30. delete[] data_;
31. }
32.
33. inline
34. double& Matrix::operator() (unsigned row, unsigned col)
35. {
36. if (row >= rows_ || col >= cols_)
37. throw BadIndex("Matrix subscript out of bounds");
38. return data_[cols_*row + col];
39. }
40.
41. inline
42. double Matrix::operator() (unsigned row, unsigned col) const
43. {
44. if (row >= rows_ || col >= cols_)
45. throw BadIndex("const Matrix subscript out of bounds");
46. return data_[cols_*row + col];
47. }
Then you can access an element of Matrix m using m(i,j) rather than m[i][j]:
1. int main()
2. {
3. Matrix m(10,10);
4. m(5,8) = 106.15;
5. std::cout << m(5,8);
6. // ...
7. }
See the next FAQ for more detail on the reasons to use m(i,j) vs. m[i][j].
Why shouldn’t my Matrix class’s interface look like an
array-of-array?
Here’s what this FAQ is really all about: Some people build a Matrix class that has
an operator[] that returns a reference to an Array object (or perhaps to a raw array, shudder),
and that Array object has an operator[] that returns an element of the Matrix (e.g., a reference
to a double). Thus they access elements of the matrix using syntax like m[i][j] rather
than syntax like m(i,j).
The array-of-array solution obviously works, but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can be done with
the operator() approach that are more difficult in the [][] approach, and therefore the []
[] approach is more likely to lead to bad performance, at least in some cases.
For example, the easiest way to implement the [][] approach is to use a physical layout of the
matrix as a dense matrix that is stored in row-major form (or is it column-major; I can’t ever
remember). In contrast, the operator() approach totally hides the physical layout of the matrix,
and that can lead to better performance in some cases.
Put it this way: the operator() approach is never worse than, and sometimes better than, the []
[] approach.
 The operator() approach is never worse because it is easy to implement the dense, row-
major physical layout using the operator() approach, so when that configuration happens to be
the optimal layout from a performance standpoint, the operator() approach is just as easy as
the [][] approach (perhaps the operator() approach is a tiny bit easier, but I won’t quibble
over minor nits).
 The operator() approach is sometimes better because whenever the optimal layout for a
given application happens to be something other than dense, row-major, the implementation is
often significantly easier using the operator() approach compared to the [][] approach.
As an example of when a physical layout makes a significant difference, a recent project happened
to access the matrix elements in columns (that is, the algorithm accesses all the elements in one
column, then the elements in another, etc.), and if the physical layout is row-major, the accesses can
“stride the cache”. For example, if the rows happen to be almost as big as the processor’s cache size,
the machine can end up with a “cache miss” for almost every element access. In this particular
project, we got a 20% improvement in performance by changing the mapping from the logical
layout (row,column) to the physical layout (column,row).
Of course there are many examples of this sort of thing from numerical methods, and sparse
matrices are a whole other dimension on this issue. Since it is, in general, easier to implement a
sparse matrix or swap row/column ordering using the operator() approach,
the operator() approach loses nothing and may gain something — it has no down-side and a
potential up-side.
Use the operator() approach.
I still don’t get it. Why shouldn’t my Matrix class’s
interface look like an array-of-array?
The same reasons you encapsulate your data structures, and the same reason you check parameters
to make sure they are valid.
A few people use [][] despite its limitations, arguing that [][] is better because it is faster or
because it uses C-syntax. The problem with the “it’s faster” argument is that it’s not — at least not
on the latest version of two of the world’s best known C++ compilers. The problem with the “uses
C-syntax” argument is that C++ is not C. Plus, oh yea, the C-syntax makes it harder to change the
data structure and harder to check parameter values.
The point of the previous two FAQs is that m(i,j) gives you a clean, simple way to check all the
parameters and to hide (and therefore, if you want to, change) the internal data structure. The world
already has way too many exposed data structures and way too many out-of-bounds parameters, and
those cost way too much money and cause way too many delays and way too many defects.
Now everybody knows that you are different. You are clairvoyant with perfect knowledge of the
future, and you know that no one will ever find any benefit from changing your matrix’s internal
data structure. Plus you are a good programmer, unlike those slobs out there that occasionally pass
wrong parameters, so you don’t need to worry about pesky little things like parameter checking. But
even though you don’t need to worry about maintenance costs (no one ever needs to change your
code), there might be one or two other programmers who aren’t quite perfect yet. For them,
maintenance costs are high, defects are real, and requirements change. Believe it or not, every once
in a while they need to (better sit down) change their code.
Admittedly my thongue wath in my theek. But there was a point. The point was that encapsulation
and parameter-checking are not crutches for the weak. It’s smart to use techniques that make
encapsulation and/or parameter checking easy. The m(i,j) syntax is one of those techniques.
Having said all that, if you find yourself maintaining a billion-line app where the original team
used m[i][j], or even if you are writing a brand new app and you just plain want to use m[i][j],
you can still encapsulate the data structure and/or check all your parameters. It’s not even that hard.
However it does require a level of sophistication that, like it or not, average C++ programmers fear.
Fortunately you are not average, so read on.
If you merely want to check parameters, just make sure the outer operator[] returns an object
rather than a raw array, then that object’s operator[] can check its parameter in the usual way.
Beware that this can slow down your program. In particular, if these inner array-like objects end up
allocating their own block of memory for their row of the matrix, the performance overhead for
creating / destroying your matrix objects can grow dramatically. The theoretical cost is still
O(rows × cols), but in practice, the overhead of the memory allocator (new or malloc) can
be much larger than anything else, and that overhead can swamp the other costs. For instance, on
two of the world’s best known C++ compilers, the separate-allocation-per-row technique was 10x
slower than the one-allocation-for-the-entire-matrix technique. 10% is one thing, 10x is another.
If you want to check the parameters without the above overhead and/or if you want to encapsulate
(and possibly change) the matrix’s internal data structure, follow these steps:
1. Add operator()(unsigned row, unsigned col) to the Matrix class.
2. Create nested class Matrix::Row. It should have a ctor with parameters (Matrix&
matrix, unsigned row), and it should store those two values in its this object.
3. Change Matrix::operator[](unsigned row) so it returns an object of
class Matrix::Row, e.g., { return Row(*this,row); }.
4. Class Matrix::Row then defines its own operator[](unsigned col) which turns
around and calls, you guessed it, Matrix::operator()(unsigned row, unsigned col).
If the Matrix::Row data members are called Matrix& matrix_ and unsigned row_, the
 code for Matrix::Row::operator[](unsigned col) will be { return matrix_(row_,
col); }
Next you will enable const overloading by repeating the above steps. You will create
the const version of the various methods, and you will create a new nested class, probably
called Matrix::ConstRow. Don’t forget to use const Matrix& instead of Matrix&.
Final step: find the joker who failed to read the previous FAQ and thonk him in the noggin.
If you have a decent compiler and if you judiciously use inlining, the compiler should optimize
away the temporary objects. In other words, the operator[]-approach above will hopefully not be
slower than what it would have been if you had directly called Matrix::operator()(unsigned
row, unsigned col) in the first place. Of course you could have made your life simpler and
avoided most of the above work by directly calling Matrix::operator()(unsigned row,
unsigned col) in the first place. So you might as well directly call Matrix::operator()
(unsigned row, unsigned col) in the first place.
Should I design my classes from the outside (interfaces
first) or from the inside (data first)?
From the outside!
A good interface provides a simplified view that is expressed in the vocabulary of a user. In the case
of OO software, the interface is normally the set of public methods of either a single class or a tight
group of classes.
First think about what the object logically represents, not how you intend to physically build it. For
example, suppose you have a Stack class that will be built by containing a LinkedList:
1. class Stack {
2. public:
3. // ...
4. private:
5. LinkedList list_;
6. };
Should the Stack have a get() method that returns the LinkedList? Or a set() method that
takes a LinkedList? Or a constructor that takes a LinkedList? Obviously the answer
is No, since you should design your interfaces from the outside-in. I.e., users of Stack objects don’t
care about LinkedLists; they care about pushing and popping.
Now for another example that is a bit more subtle. Suppose class LinkedList is built using a
linked list of Node objects, where each Node object has a pointer to the next Node:
1. class Node { /*...*/ };
2.
3. class LinkedList {
4. public:
5. // ...
6. private:
7. Node* first_;
8. };
Should the LinkedList class have a get() method that will let users access the first Node?
Should the Node object have a get() method that will let users follow that Node to the
next Node in the chain? In other words, what should a LinkedList look like from the outside? Is
a LinkedList really a chain of Node objects? Or is that just an implementation detail? And if it is
just an implementation detail, how will the LinkedList let users access each of the elements in
the LinkedList one at a time?
The key insight is the realization that a LinkedList is not a chain of Nodes. That may be how it is
built, but that is not what it is. What it is is a sequence of elements. Therefore
the LinkedList abstraction should provide a LinkedListIterator class as well, and
 that LinkedListIterator might have an operator++ to go to the next element, and it might
have a get()/set() pair to access its value stored in the Node (the value in the Node element is
solely the responsibility of the LinkedList user, which is why there is a get()/set() pair that
allows the user to freely manipulate that value).
Starting from the user’s perspective, we might want our LinkedList class to support operations
that look similar to accessing an array using pointer arithmetic:
1. void userCode(LinkedList& a)
2. {
3. for (LinkedListIterator p = a.begin(); p != a.end(); ++p)
4. std::cout << *p << '\n';
5. }
To implement this interface, LinkedList will need a begin() method and an end() method.
These return a LinkedListIterator object. The LinkedListIterator will need a method to
go forward, ++p; a method to access the current element, *p; and a comparison operator, p !=
a.end().
The code follows. The important thing to notice is that LinkedList does not have any methods
that let users access Nodes. Nodes are an implementation technique that is completely buried. This
makes the LinkedList class safer (no chance a user will mess up the invariants and linkages
between the various nodes), easier to use (users don’t need to expend extra effort keeping the node-
count equal to the actual number of nodes, or any other infrastructure stuff), and more flexible (by
changing a single typedef, users could change their code from using LinkedList to some other
list-like class and the bulk of their code would compile cleanly and hopefully with improved
performance characteristics).
1. #include <cassert> // Poor man's exception handling
2.
3. class LinkedListIterator;
4. class LinkedList;
5.
6. class Node {
7. // No public members; this is a "private class"
8. friend class LinkedListIterator; // A friend class
9. friend class LinkedList;
10. Node* next_;
11. int elem_;
12. };
13.
14. class LinkedListIterator {
15. public:
16. bool operator== (LinkedListIterator i) const;
17. bool operator!= (LinkedListIterator i) const;
18. void operator++ (); // Go to the next element
19. int& operator* (); // Access the current element
20. private:
21. LinkedListIterator(Node* p);
22. Node* p_;
23. friend class LinkedList; // so LinkedList can construct a LinkedListIterator
24. };
25.
26. class LinkedList {
27. public:
28. void append(int elem); // Adds elem after the end
29. void prepend(int elem); // Adds elem before the beginning
30. // ...
31. LinkedListIterator begin();
32. LinkedListIterator end();
33. // ...
34. private:
35. Node* first_;
36. };
Here are the methods that are obviously inlinable (probably in the same header file):
1. inline bool LinkedListIterator::operator== (LinkedListIterator i) const
2. {
3. return p_ == i.p_;
4. }
5.
6. inline bool LinkedListIterator::operator!= (LinkedListIterator i) const
7. {
8. return p_ != i.p_;
9. }
10.
11. inline void LinkedListIterator::operator++()
12. {
13. assert(p_ != NULL); // or if (p_==NULL) throw ...
14. p_ = p_->next_;
15. }
16.
17. inline int& LinkedListIterator::operator*()
18. {
19. assert(p_ != NULL); // or if (p_==NULL) throw ...
20. return p_->elem_;
21. }
22.
23. inline LinkedListIterator::LinkedListIterator(Node* p)
24. : p_(p)
25. {}
26.
27. inline LinkedListIterator LinkedList::begin()
28. {
29. return first_;
30. }
31.
32. inline LinkedListIterator LinkedList::end()
33. {
34. return NULL;
35. }
Conclusion: The linked list had two different kinds of data. The values of the elements stored in the
linked list are the responsibility of the user of the linked list (and only the user; the linked list itself
makes no attempt to prohibit users from changing the third element to 5), and the linked list’s
infrastructure data (next pointers, etc.), whose values are the responsibility of the linked list
(and only the linked list; e.g., the linked list does not let users change (or even look at!) the
various next pointers).
Thus the only get()/set() methods were to get and set the elements of the linked list, but not the
infrastructure of the linked list. Since the linked list hides the infrastructure pointers/etc., it is able to
make very strong promises regarding that infrastructure (e.g., if it were a doubly linked list, it might
guarantee that every forward pointer was matched by a backwards pointer from the next Node).
So, we see here an example of where the values of some of a class’s data is the responsibility
of users (in which case the class needs to have get()/set() methods for that data) but the data that
the class wants to control does not necessarily have get()/set() methods.
Note: the purpose of this example is not to show you how to write a linked-list class. In fact you
should not “roll your own” linked-list class since you should use one of the “container classes”
 provided with your compiler. Ideally you’ll use one of the standard container classes such as
the std::list<T> template.
How can I overload the prefix and postfix forms of
operators ++ and --?
Via a dummy parameter.
Since the prefix and postfix ++ operators can have two definitions, the C++ language gives us two
different signatures. Both are called operator++(), but the prefix version takes no parameters and
the postfix version takes a dummy int. (Although this discussion revolves around the ++ operator,
the -- operator is completely symmetric, and all the rules and guidelines that apply to one also
apply to the other.)
1. class Number {
2. public:
3. Number& operator++ (); // prefix ++
4. Number operator++ (int); // postfix ++
5. };
Note the different return types: the prefix version returns by reference, the postfix version by value.
If that’s not immediately obvious to you, it should be after you see the definitions (and after you
remember that y = x++ and y = ++x set y to different things).
1. Number& Number::operator++ ()
2. {
3. // ...
4. return *this;
5. }
6.
7. Number Number::operator++ (int)
8. {
9. Number ans = *this;
10. ++(*this); // or just call operator++()
11. return ans;
12. }
The other option for the postfix version is to return nothing:
1. class Number {
2. public:
3. Number& operator++ ();
4. void operator++ (int);
5. };
6.
7. Number& Number::operator++ ()
8. {
9. // ...
10. return *this;
11. }
12.
13. void Number::operator++ (int)
14. {
15. ++(*this); // or just call operator++()
16. }
However you must not make the postfix version return the this object by reference; you have been
warned.
Here’s how you use these operators:
1. Number x = /* ... */;
2. ++x; // calls Number::operator++(), i.e., calls x.operator++()
3. x++; // calls Number::operator++(int), i.e., calls x.operator++(0)
Assuming the return types are not ‘void’, you can use them in larger expressions:
1. Number x = /* ... */;
2. Number y = ++x; // y will be the new value of x
3. Number z = x++; // z will be the old value of x

Which is more efficient: i++ or ++i?

++i is sometimes faster than, and is never slower than, i++.
For intrinsic types like int, it doesn’t matter: ++i and i++ are the same speed. For class types like
iterators or the previous FAQ’s Number class, ++i very well might be faster than i++ since the
latter might make a copy of the this object.
The overhead of i++, if it is there at all, won’t probably make any practical difference unless your
app is CPU bound. For example, if your app spends most of its time waiting for someone to click a
mouse, doing disk I/O, network I/O, or database queries, then it won’t hurt your performance to
waste a few CPU cycles. However it’s just as easy to type ++i as i++, so why not use the former
unless you actually need the old value of i.
So if you’re writing i++ as a statement rather than as part of a larger expression, why not just
write ++i instead? You never lose anything, and you sometimes gain something. Old line C
programmers are used to writing i++ instead of ++i. E.g., they’ll say, for (i = 0; i < 10; i+
+) .... Since this uses i++ as a statement, not as a part of a larger expression, then you might
want to use ++i instead. For symmetry, I personally advocate that style even when it doesn’t
improve speed, e.g., for intrinsic types and for class types with postfix operators that return void.
Obviously when i++ appears as a part of a larger expression, that’s different: it’s being used
because it’s the only logically correct solution, not because it’s an old habit you picked up while
programming in C.

Friends
Save to:
InstapaperPocketReadability
Contents of this section:

 What is a friend?
 Do friends violate encapsulation?
 What are some advantages/disadvantages of using friend functions?
 What does it mean that “friendship isn’t inherited, transitive, or reciprocal”?
 Should my class declare a member function or a friend function?
What is a friend?
Something to allow your class to grant access to another class or function.
Friends can be either functions or other classes. A class grants access privileges to its friends.
Normally a developer has political and technical control over both the friend and member
functions of a class (else you may need to get permission from the owner of the other pieces when
you want to update your own class).
Do friends violate encapsulation?
No! If they’re used properly, they enhance encapsulation.
“Friend” is an explicit mechanism for granting access, just like membership. You cannot (in a
standard conforming program) grant yourself access to a class without modifying its source. For
example:
1. class X {
2. int i;
3. public:
4. void m(); // grant X::m() access
5. friend void f(X&); // grant f(X&) access
6. // ...
7. };
8.
9. void X::m() { i++; /* X::m() can access X::i */ }
10.
11. void f(X& x) { x.i++; /* f(X&) can access X::i */ }
For a description on the C++ protection model, see D&E sec 2.10 and TC++PL sec 11.5, 15.3, and
C.11.
You often need to split a class in half when the two halves will have different numbers of instances
or different lifetimes. In these cases, the two halves usually need direct access to each other (the two
halves used to be in the same class, so you haven’t increased the amount of code that needs direct
access to a data structure; you’ve simply reshuffled the code into two classes instead of one). The
safest way to implement this is to make the two halves friends of each other.
If you use friends like just described, you’ll keep private things private. People who don’t
understand this often make naive efforts to avoid using friendship in situations like the above, and
often they actually destroy encapsulation. They either use public data (grotesque!), or they make
the data accessible between the halves via public get() and set() member functions. Having
a public get() and set() member function for a private datum is okay only when
the private datum “makes sense” from outside the class (from a user’s perspective). In many
cases, these get()/set() member functions are almost as bad as public data: they hide (only)
the name of the private datum, but they don’t hide the existence of the private datum.
Similarly, if you use friend functions as a syntactic variant of a class’s public access functions,
they don’t violate encapsulation any more than a member function violates encapsulation. In other
words, a class’s friends don’t violate the encapsulation barrier: along with the class’s member
functions, they are the encapsulation barrier.
(Many people think of a friend function as something outside the class. Instead, try thinking of a
friend function as part of the class’s public interface. A friend function in the class declaration
doesn’t violate encapsulation any more than a public member function violates encapsulation: both
have exactly the same authority with respect to accessing the class’s non-public parts.)

What are some advantages/disadvantages of

using friend functions?
They provide a degree of freedom in the interface design options.
Member functions and friend functions are equally privileged (100% vested). The major
difference is that a friend function is called like f(x), while a member function is called
like x.f(). Thus the ability to choose between member functions (x.f()) and friend functions
(f(x)) allows a designer to select the syntax that is deemed most readable, which lowers
maintenance costs.
The major disadvantage of friend functions is that they require an extra line of code when you
want dynamic binding. To get the effect of a virtual friend, the friend function should call a
hidden (usually protected) virtual member function. This is called the Virtual Friend Function
Idiom. For example:
1. class Base {
2. public:
3. friend void f(Base& b);
4. // ...
5. protected:
6. virtual void do_f();
7. // ...
8. };
9.
10. inline void f(Base& b)
11. {
12. b.do_f();
13. }
14.
15. class Derived : public Base {
16. public:
17. // ...
18. protected:
19. virtual void do_f(); // "Override" the behavior of f(Base& b)
20. // ...
21. };
22.
23. void userCode(Base& b)
24. {
25. f(b);
26. }
The statement f(b) in userCode(Base&) will invoke b.do_f(), which is virtual. This means
that Derived::do_f() will get control if b is actually a object of class Derived. Note
that Derived overrides the behavior of the protected virtual member function do_f(); it
does not have its own variation of the friend function, f(Base&).
What does it mean that “friendship isn’t inherited,
transitive, or reciprocal”?
Just because I grant you friendship access to me doesn’t automatically grant your kids access to me,
doesn’t automatically grant your friends access to me, and doesn’t automatically grant me access to
you.
 I don’t necessarily trust the kids of my friends. The privileges of friendship aren’t inherited.
Derived classes of a friend aren’t necessarily friends. If class Fred declares that class Base is
a friend, classes derived from Base don’t have any automatic special access rights
to Fred objects.
 I don’t necessarily trust the friends of my friends. The privileges of friendship aren’t
transitive. A friend of a friend isn’t necessarily a friend. If class Fred declares class Wilma as
a friend, and class Wilma declares class Betty as a friend, class Betty doesn’t necessarily
have any special access rights to Fred objects.
 You don’t necessarily trust me simply because I declare you my friend. The privileges of
friendship aren’t reciprocal. If class Fred declares that class Wilma is a friend, Wilma objects
have special access to Fred objects but Fred objects do not automatically have special access
to Wilma objects.
Should my class declare a member function or
a friend function?
Use a member when you can, and a friend when you have to.
Sometimes friends are syntactically better (e.g., in class Fred, friend functions allow
the Fred parameter to be second, while members require it to be first). Another good use
of friend functions are the binary infix arithmetic operators. E.g., aComplex +
 aComplex should be defined as a friend rather than a member if you want to allow aFloat +
aComplex as well (member functions don’t allow promotion of the left hand argument, since that
would change the class of the object that is the recipient of the member function invocation).
In other cases, choose a member function over a friend function.

Inheritance — Basics
Save to:
InstapaperPocketReadability
Contents of this section:

 Is inheritance important to C++?

 When would I use inheritance?
 How do you express inheritance in C++?
 Is it okay to convert a pointer from a derived class to its base class?
 What’s the difference between public, private, and protected?
 Why can’t my derived class access private things from my base class?
 How can I protect derived classes from breaking when I change the internal parts of the base
class?
 I’ve been told to never use protected data, and instead to always use private data with
protected access functions. Is that a good rule?
 Okay, so exactly how should I decide whether to build a “protected interface”?
Is inheritance important to C++?
Yep.
Some who champion OO programming, believe that inheritance is what separates abstract data type
(ADT) programming from OO programming.
Those who consider OO programming philosophically unsound, still find inheritance useful to take
advantage of empty base optimization when constructing a class by inheriting from mixin classes
that donate data or behavior to the resulting class or to facilitate tag dispatch in template meta-
programming.
When would I use inheritance?
If you follow the OO paradigm, use it as a specification device.
Human beings abstract things on two dimensions: part-of and kind-of. A Ford Taurus is-a-kind-of-a
Car, and a Ford Taurus has-a Engine, Tires, etc. The part-of hierarchy has been a part of software
since the ADT style became relevant; inheritance adds “the other” major dimension of
decomposition.
If you don’t follow the OO paradigm, use inheritance to mix-in behavior and data from donor
classes and help with tag dispatch.

How do you express inheritance in C++?

By the : public syntax:
1. class Car : public Vehicle {
2. public:
3. // ...
4. };
We state the above relationship in several ways:
  Car is “a kind of a” Vehicle
 Car is “derived from” Vehicle
 Car is “a specialized” Vehicle
 Car is a “subclass” of Vehicle
 Car is a “derived class” of Vehicle
 Vehicle is the “base class” of Car
 Vehicle is the “superclass” of Car (this not as common in the C++ community)
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
Is it okay to convert a pointer from a derived class to its
base class?
Yes.
An object of a derived class is a kind of the base class. Therefore the conversion from a derived
class pointer to a base class pointer is perfectly safe, and happens all the time. For example, if I am
pointing at a car, I am in fact pointing at a vehicle, so converting a Car* to a Vehicle* is perfectly
safe and normal:
1. void f(Vehicle* v);
2. void g(Car* c) { f(c); } // Perfectly safe; no cast
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
What’s the difference between public, private,
and protected?
 A member (either data member or member function) declared in a private section of a
class can only be accessed by member functions and friends of that class
 A member (either data member or member function) declared in a protected section of a
class can only be accessed by member functions and friends of that class, and by member
functions and friends of derived classes
 A member (either data member or member function) declared in a public section of a class
can be accessed by anyone
Why can’t my derived class access private things from
my base class?
To protect you from future changes to the base class.
Derived classes do not get access to private members of a base class. This effectively “seals off”
the derived class from any changes made to the private members of the base class.
How can I protect derived classes from breaking when I
change the internal parts of the base class?
A class has two distinct interfaces for two distinct sets of clients:
 It has a public interface that serves unrelated classes
 It has a protected interface that serves derived classes
Unless you expect all your derived classes to be built by your own team, you should declare your
base class’s data members as private and use protected inline access functions by which
derived classes will access the private data in the base class. This way the private data
 declarations can change, but the derived class’s code won’t break (unless you change
the protected access functions).
I’ve been told to never use protected data, and instead to
always use private data with protected access functions.
Is that a good rule?
Nope.
Whenever someone says to you, “You should always make data private,” stop right there — it’s an
“always” or “never” rule, and those rules are what I call one-size-fits-all rules. The real world isn’t
that simple.
Here’s the way I say it: if I expect derived classes, I should ask this question: who will create them?
If the people who will create them will be outside your team, or if there are a huge number of
derived classes, then and only then is it worth creating a protected interface and using private data.
If I expect the derived classes to be created by my own team and to be reasonable in number, it’s
just not worth the trouble: use protected data. And hold your head up, don’t be ashamed: it’s
the right thing to do!
The benefit of protected access functions is that you won’t break your derived classes as often as
you would if your data was protected. Put it this way: if you believe your users will be outside your
team, you should do a lot more than just provide get/set methods for your private data. You should
actually create another interface. You have a public interface for one set of users, and a protected
interface for another set of users. But they both need an interface that is carefully designed —
designed for stability, usability, performance, etc. And at the end of the day, the real benefit of
privatizing your data (including providing an interface that is coherent and, as much as possible,
opaque) is to avoid breaking your derived classes when you change that data structure.
But if your own team is creating the derived classes, and there are a reasonably small number of
them, it’s simply not worth the effort: use protected data. Some purists (translation: people who’ve
never stepped foot in the real world, people who’ve spent their entire lives in an ivory tower, people
who don’t understand words like “customer” or “schedule” or “deadline” or “ROI”) think
that everything ought to be reusable and everything ought to have a clean, easy to use interface.
Those kinds of people are dangerous: they often make your project late, since they make everything
equally important. They’re basically saying, “We have 100 tasks, and I have carefully prioritized
them: they are all priority 1.” They make the notion of priority meaningless.
You simply will not have enough time to make life easy for everyone, so the very best you can do is
make life easy for a subset of the world. Prioritize. Select the people that matter most and spend
time making stable interfaces for them. You may not like this, but everyone is not created equal;
some people actually do matter more than others. We have a word for those important people. We
call them “customers.”
Okay, so exactly how should I decide whether to build a
“protected interface”?
Three keys: ROI, ROI and ROI.
Every interface you build has a cost and a benefit. Every reusable component you build has a cost
and a benefit. Every test case, every cleanly structured thing-a-ma-bob, every investment of any
sort. You should never invest any time or any money in any thing if there is not a positive return on
that investment. If it costs your company more than it saves, don’t do it!
Not everyone agrees with me on this; they have a right to be wrong. For example, people who live
sufficiently far from the real world act like every investment is good. After all, they reason, if you
wait long enough, it might someday save somebody some time. Maybe. We hope.
 That whole line of reasoning is unprofessional and irresponsible. You don’t have infinite time, so
invest it wisely. Sure, if you live in an ivory tower, you don’t have to worry about those pesky
things called “schedules” or “customers.” But in the real world, you work within a schedule, and
you must therefore invest your time only where you’ll get good pay-back.
Back to the original question: when should you invest time in building a protected interface?
Answer: when you get a good return on that investment. If it’s going to cost you an hour, make sure
it saves somebody more than an hour, and make sure the savings isn’t “someday over the rainbow.”
If you can save an hour within the current project, it’s a no-brainer: go for it. If it’s going to save
some other project an hour someday maybe we hope, then don’t do it. And if it’s in between, your
answer will depend on exactly how your company trades off the future against the present.
The point is simple: do not do something that could damage your schedule. (Or if you do, make sure
you never work with me; I’ll have your head on a platter.) Investing is good if there’s a pay-back for
that investment. Don’t be naive and childish; grow up and realize that some investments are bad
because they, in balance, cost more than they return.

Inheritance — virtual functions

Save to:
InstapaperPocketReadability
Contents of this section:

 What is a “virtual member function”?

 Why are member functions not virtual by default?
 How can C++ achieve dynamic binding yet also static typing?
 What is a pure virtual function?
 What’s the difference between how virtual and non-virtual member functions are
called?
 What happens in the hardware when I call a virtual function? How many layers of indirection
are there? How much overhead is there?
 How can a member function in my derived class call the same function from its base class?
 I have a heterogeneous list of objects, and my code needs to do class-specific things to the
objects. Seems like this ought to use dynamic binding but can’t figure it out. What should I do?
 When should my destructor be virtual?
 Why are destructors not virtual by default?
 What is a “virtual constructor”?
 Why don’t we have virtual constructors?
What is a “virtual member function”?
Virtual member functions are key to the object-oriented paradigm, such as making it easy for old
code to call new code.
A virtual function allows derived classes to replace the implementation provided by the base
class. The compiler makes sure the replacement is always called whenever the object in question is
actually of the derived class, even if the object is accessed by a base pointer rather than a derived
pointer. This allows algorithms in the base class to be replaced in the derived class, even if users
don’t know about the derived class.
The derived class can either fully replace (“override”) the base class member function, or the
derived class can partially replace (“augment”) the base class member function. The latter is
accomplished by having the derived class member function call the base class member function, if
desired.
 Why are member functions not virtual by default?
Because many classes are not designed to be used as base classes. For example, see class complex.
Also, objects of a class with a virtual function require space needed by the virtual function call
mechanism - typically one word per object. This overhead can be significant, and can get in the way
of layout compatibility with data from other languages (e.g. C and Fortran).
See The Design and Evolution of C++ for more design rationale.
How can C++ achieve dynamic binding yet also static
typing?
When you have a pointer to an object, the object may actually be of a class that is derived from the
class of the pointer (e.g., a Vehicle* that is actually pointing to a Car object; this is called
“polymorphism”). Thus there are two types: the (static) type of the pointer (Vehicle, in this case),
and the (dynamic) type of the pointed-to object (Car, in this case).
Static typing means that the legality of a member function invocation is checked at the earliest
possible moment: by the compiler at compile time. The compiler uses the static type of the pointer
to determine whether the member function invocation is legal. If the type of the pointer can handle
the member function, certainly the pointed-to object can handle it as well. E.g., if Vehicle has a
certain member function, certainly Car also has that member function since Car is a kind-
of Vehicle.
Dynamic binding means that the address of the code in a member function invocation is determined
at the last possible moment: based on the dynamic type of the object at run time. It is called
“dynamic binding” because the binding to the code that actually gets called is accomplished
dynamically (at run time). Dynamic binding is a result of virtual functions.
What is a pure virtual function?
A pure virtual function is a function that must be overridden in a derived class and need not be
defined. A virtual function is declared to be “pure” using the curious =0 syntax. For example:
1. class Base {
2. public:
3. void f1(); // not virtual
4. virtual void f2(); // virtual, not pure
5. virtual void f3() = 0; // pure virtual
6. };
7.
8. Base b; // error: pure virtual f3 not overridden
Here, Base is an abstract class (because it has a pure virtual function), so no objects of
class Base can be directly created: Base is (explicitly) meant to be a base class. For example:
1. class Derived : public Base {
2. // no f1: fine
3. // no f2: fine, we inherit Base::f2
4. void f3();
5. };
6.
7. Derived d; // ok: Derived::f3 overrides Base::f3
Abstract classes are immensely useful for defining interfaces. In fact, a class with no data and where
all functions are pure virtual functions is often called an interface.
You can provide a definition for a pure virtual function:
1. Base::f3() { /* ... */ }
 This is very occasionally useful (to provide some simple common implementation detail for derived
classes), but Base::f3() must still be overridden in some derived class. If you don’t override a
pure virtual function in a derived class, that derived class becomes abstract:
1. class D2 : public Base {
2. // no f1: fine
3. // no f2: fine, we inherit Base::f2
4. // no f3: fine, but D2 is therefore still abstract
5. };
6.
7. D2 d; // error: pure virtual Base::f3 not overridden

What’s the difference between how virtual and non-

virtual member functions are called?
Non-virtual member functions are resolved statically. That is, the member function is selected
statically (at compile-time) based on the type of the pointer (or reference) to the object.
In contrast, virtual member functions are resolved dynamically (at run-time). That is, the member
function is selected dynamically (at run-time) based on the type of the object, not the type of the
pointer/reference to that object. This is called “dynamic binding.” Most compilers use some variant
of the following technique: if the object has one or more virtual functions, the compiler puts a
hidden pointer in the object called a “virtual-pointer” or “v-pointer.” This v-pointer points to a
global table called the “virtual-table” or “v-table.”
The compiler creates a v-table for each class that has at least one virtual function. For example, if
class Circle has virtual functions for draw() and move() and resize(), there would be
exactly one v-table associated with class Circle, even if there were a gazillion Circle objects,
and the v-pointer of each of those Circle objects would point to the Circle v-table. The v-table
itself has pointers to each of the virtual functions in the class. For example, the Circle v-table
would have three pointers: a pointer to Circle::draw(), a pointer to Circle::move(), and a
pointer to Circle::resize().
During a dispatch of a virtual function, the run-time system follows the object’s v-pointer to the
class’s v-table, then follows the appropriate slot in the v-table to the method code.
The space-cost overhead of the above technique is nominal: an extra pointer per object (but only for
objects that will need to do dynamic binding), plus an extra pointer per method (but only for virtual
methods). The time-cost overhead is also fairly nominal: compared to a normal function call,
a virtual function call requires two extra fetches (one to get the value of the v-pointer, a second to
get the address of the method). None of this runtime activity happens with non-virtual functions,
since the compiler resolves non-virtual functions exclusively at compile-time based on the type
of the pointer.
Note: the above discussion is simplified considerably, since it doesn’t account for extra structural
things like multiple inheritance, virtual inheritance, RTTI, etc., nor does it account for
space/speed issues such as page faults, calling a function via a pointer-to-function, etc. If you want
to know about those other things, please ask comp.lang.c++; PLEASE DO NOT SEND E-MAIL
TO ME!
What happens in the hardware when I call a virtual
function? How many layers of indirection are there? How
much overhead is there?
This is a drill-down of the previous FAQ. The answer is entirely compiler-dependent, so your
mileage may vary, but most C++ compilers use a scheme similar to the one presented here.
Let’s work an example. Suppose class Base has 5 virtual functions: virt0() through virt4().
1. // Your original C++ source code
2.
3. class Base {
4. public:
5. virtual arbitrary_return_type virt0( /*...arbitrary params...*/ );
6. virtual arbitrary_return_type virt1( /*...arbitrary params...*/ );
7. virtual arbitrary_return_type virt2( /*...arbitrary params...*/ );
8. virtual arbitrary_return_type virt3( /*...arbitrary params...*/ );
9. virtual arbitrary_return_type virt4( /*...arbitrary params...*/ );
10. // ...
11. };
Step #1: the compiler builds a static table containing 5 function-pointers, burying that table into
static memory somewhere. Many (not all) compilers define this table while compiling the .cpp that
defines Base’s first non-inline virtual function. We call that table the v-table; let’s pretend its
technical name is Base::__vtable. If a function pointer fits into one machine word on the target
hardware platform, Base::__vtable will end up consuming 5 hidden words of memory. Not 5
per instance, not 5 per function; just 5. It might look something like the following pseudo-code:
1. // Pseudo-code (not C++, not C) for a static table defined within file Base.cpp
2.
3. // Pretend FunctionPtr is a generic pointer to a generic member function
4. // (Remember: this is pseudo-code, not C++ code)
5. FunctionPtr Base::__vtable[5] = {
6. &Base::virt0, &Base::virt1, &Base::virt2, &Base::virt3, &Base::virt4
7. };
Step #2: the compiler adds a hidden pointer (typically also a machine-word) to each object of
class Base. This is called the v-pointer. Think of this hidden pointer as a hidden data member, as if
the compiler rewrites your class to something like this:
1. // Your original C++ source code
2.
3. class Base {
4. public:
5. // ...
6. FunctionPtr* __vptr; // Supplied by the compiler, hidden from the programmer
7. // ...
8. };
Step #3: the compiler initializes this->__vptr within each constructor. The idea is to cause each
object’s v-pointer to point at its class’s v-table, as if it adds the following instruction in each
constructor’s init-list:
1. Base::Base( /*...arbitrary params...*/ )
2. : __vptr(&Base::__vtable[0]) // Supplied by the compiler, hidden from the programmer
3. // ...
4. {
5. // ...
6. }
Now let’s work out a derived class. Suppose your C++ code defines class Der that inherits from
class Base. The compiler repeats steps #1 and #3 (but not #2). In step #1, the compiler creates a
hidden v-table, keeping the same function-pointers as in Base::__vtable but replacing those
slots that correspond to overrides. For instance, if Der overrides virt0() through virt2() and
inherits the others as-is, Der’s v-table might look something like this (pretend Der doesn’t add any
new virtuals):
1. // Pseudo-code (not C++, not C) for a static table defined within file Der.cpp
2.
3. // Pretend FunctionPtr is a generic pointer to a generic member function
4. // (Remember: this is pseudo-code, not C++ code)
5. FunctionPtr Der::__vtable[5] = {
6. &Der::virt0, &Der::virt1, &Der::virt2, &Base::virt3, &Base::virt4
7. ↑↑↑↑ ↑↑↑↑ // Inherited as-is
8. };
In step #3, the compiler adds a similar pointer-assignment at the beginning of each of Der’s
constructors. The idea is to change each Der object’s v-pointer so it points at its class’s v-table.
(This is not a second v-pointer; it’s the same v-pointer that was defined in the base class, Base;
remember, the compiler does not repeat step #2 in class Der.)
Finally, let’s see how the compiler implements a call to a virtual function. Your code might look
like this:
1. // Your original C++ code
2.
3. void mycode(Base* p)
4. {
5. p->virt3();
6. }
The compiler has no idea whether this is going to call Base::virt3() or Der::virt3() or
perhaps the virt3() method of another derived class that doesn’t even exist yet. It only knows for
sure that you are calling virt3() which happens to be the function in slot #3 of the v-table. It
rewrites that call into something like this:
1. // Pseudo-code that the compiler generates from your C++
2.
3. void mycode(Base* p)
4. {
5. p->__vptr[3](p);
6. }
On typical hardware, the machine-code is two ‘load’s plus a call:
1. The first load gets the v-pointer, storing it into a register, say r1.
2. The second load gets the word at r1 + 3*4 (pretend function-pointers are 4-bytes long,
so r1 + 12 is the pointer to the right class’s virt3() function). Pretend it puts that word into
register r2 (or r1 for that matter).
3. The third instruction calls the code at location r2.
Conclusions:
 Objects of classes with virtual functions have only a small space-overhead compared to those
that don’t have virtual functions.
 Calling a virtual function is fast — almost as fast as calling a non-virtual function.
 You don’t get any additional per-call overhead no matter how deep the inheritance gets. You
could have 10 levels of inheritance, but there is no “chaining” — it’s always the same — fetch,
fetch, call.
Caveat: I’ve intentionally ignored multiple inheritance, virtual inheritance and RTTI. Depending on
the compiler, these can make things a little more complicated. If you want to know about these
things, DO NOT EMAIL ME, but instead ask comp.lang.c++.
Caveat: Everything in this FAQ is compiler-dependent. Your mileage may vary.
How can a member function in my derived class call the
same function from its base class?
Use Base::f();
Let’s start with a simple case. When you call a non-virtual function, the compiler obviously doesn’t
use the virtual-function mechanism. Instead it calls the function by name, using the fully qualified
name of the member function. For instance, the following C++ code…
1. void mycode(Fred* p)
2. {
3. p->goBowling(); // Pretend Fred::goBowling() is non-virtual
4. }
…might get compiled into something like this C-like code (the p parameter becomes
the this object within the member function):
1. void mycode(Fred* p)
2. {
3. __Fred__goBowling(p); // Pseudo-code only; not real
4. }
The actual name-mangling scheme is more involved than the simple one implied above, but you get
the idea. The point is that there is nothing strange about this particular case — it resolves to a
normal function more-or-less like printf().
Now for the case being addressed in the question above: When you call a virtual function using its
fully-qualified name (the class-name followed by “::”), the compiler does not use the virtual call
mechanism, but instead uses the same mechanism as if you called a non-virtual function. Said
another way, it calls the function by name rather than by slot-number. So if you want code within
derived class Der to call Base::f(), that is, the version of f() defined in its base class Base, you
should write:
1. void Der::f()
2. {
3. Base::f(); // Or, if you prefer, this->Base::f();
4. }
The complier will turn that into something vaguely like the following (again using an overly
simplistic name-mangling scheme):
1. void __Der__f(Der* this) // Pseudo-code only; not real
2. {
3. __Base__f(this); // Pseudo-code only; not real
4. }

I have a heterogeneous list of objects, and my code needs

to do class-specific things to the objects. Seems like this
ought to use dynamic binding but can’t figure it out. What
should I do?
It’s surprisingly easy.
Suppose there is a base class Vehicle with derived classes Car and Truck. The code traverses a
list of Vehicle objects and does different things depending on the type of Vehicle. For example
it might weigh the Truck objects (to make sure they’re not carrying too heavy of a load) but it
might do something different with a Car object — check the registration, for example.
The initial solution for this, at least with most people, is to use an if statement. E.g., “if the object
is a Truck, do this, else if it is a Car, do that, else do a third thing”:
1. typedef std::vector<Vehicle*> VehicleList;
2.
3. void myCode(VehicleList& v)
4. {
5. for (VehicleList::iterator p = v.begin(); p != v.end(); ++p) {
6. Vehicle& v = **p; // just for shorthand
7.
8. // generic code that works for any vehicle...
9. // ...
10.
11. // perform the "foo-bar" operation.
12. // note: the details of the "foo-bar" operation depend
13. // on whether we're working with a car or a truck.
14. if (v is a Car) {
15. // car-specific code that does "foo-bar" on car v
16. // ...
17. } else if (v is a Truck) {
18. // truck-specific code that does "foo-bar" on truck v
19. // ...
20. } else {
21. // semi-generic code that does "foo-bar" on something else
22. // ...
23. }
24.
25. // generic code that works for any vehicle...
26. // ...
27. }
28. }
The problem with this is what I call “else-if-heimer’s disease” (say it fast and you’ll understand).
The above code gives you else-if-heimer’s disease because eventually you’ll forget to add an else
if when you add a new derived class, and you’ll probably have a bug that won’t be detected until
run-time, or worse, when the product is in the field.
The solution is to use dynamic binding rather than dynamic typing. Instead of having (what I call)
the live-code dead-data metaphor (where the code is alive and the car/truck objects are relatively
dead), we move the code into the data. This is a slight variation of Bertrand Meyer’s Law of
Inversion.
The idea is simple: use the description of the code within the {...} blocks of each if (in this case
it is “the foo-bar operation”; obviously your name will be different). Just pick up this descriptive
name and use it as the name of a new virtual member function in the base class (in this case we’ll
add a fooBar() member function to class Vehicle).
1. class Vehicle {
2. public:
3. // performs the "foo-bar" operation
4. virtual void fooBar() = 0;
5. };
Then you remove the whole if...else if… block and replace it with a simple call to
this virtual function:
1. typedef std::vector<Vehicle*> VehicleList;
2.
3. void myCode(VehicleList& v)
4. {
5. for (VehicleList::iterator p = v.begin(); p != v.end(); ++p) {
6. Vehicle& v = **p; // just for shorthand
7.
8. // generic code that works for any vehicle...
9. // ...
10.
11. // perform the "foo-bar" operation.
12. v.fooBar();
13.
14. // generic code that works for any vehicle...
15. // ...
16. }
17. }
Finally you move the code that used to be in the {...} block of each if into
the fooBar() member function of the appropriate derived class:
1. class Car : public Vehicle {
2. public:
3. virtual void fooBar();
4. };
5.
6. void Car::fooBar()
7. {
8. // car-specific code that does "foo-bar" on 'this'
9. // this is the code that was in {...} of if (v is a Car)
10. }
11.
12. class Truck : public Vehicle {
13. public:
14. virtual void fooBar();
15. };
16.
17. void Truck::fooBar()
18. {
19. // truck-specific code that does "foo-bar" on 'this'
20. // this is the code that was in {...} of if (v is a Truck)
21. }
If you actually have an else block in the original myCode() function (see above for the “semi-
generic code that does the ‘foo-bar’ operation on something other than a Car or Truck”),
change Vehicle’s fooBar() from pure virtual to plain virtual and move the code into that
member function:
1. class Vehicle {
2. public:
3. // performs the "foo-bar" operation
4. virtual void fooBar();
5. };
6.
7. void Vehicle::fooBar()
8. {
9. // semi-generic code that does "foo-bar" on something else
10. // this is the code that was in {...} of the else
11. // you can think of this as "default" code...
12. }
That’s it!
The point, of course, is that we try to avoid decision logic with decisions based on the kind-of
derived class you’re dealing with. In other words, you’re trying to avoid if the object is a
car do xyz, else if it's a truck do pqr, etc., because that leads to else-if-heimer’s disease.
When should my destructor be virtual?
When someone will delete a derived-class object via a base-class pointer.
In particular, here’s when you need to make your destructor virtual:
 if someone will derive from your class,
 and if someone will say new Derived, where Derived is derived from your class,
 and if someone will say delete p, where the actual object’s type is Derived but the
pointer p’s type is your class.
Confused? Here’s a simplified rule of thumb that usually protects you and usually doesn’t cost you
anything: make your destructor virtual if your class has any virtual functions. Rationale:
 that usually protects you because most base classes have at least one virtual function.
 that usually doesn’t cost you anything because there is no added per-object space-cost for the
second or subsequent virtual in your class. In other words, you’ve already paid all the per-
object space-cost that you’ll ever pay once you add the first virtual function, so
 the virtual destructor doesn’t add any additional per-object space cost. (Everything in this
bullet is theoretically compiler-specific, but in practice it will be valid on almost all compilers.)
Note: in a derived class, if your base class has a virtual destructor, your own destructor is
automatically virtual. You might need an explicitly defined destructor for other reasons, but
there’s no need to redeclare a destructor simply to make sure it is virtual. No matter whether you
declare it with the virtual keyword, declare it without the virtual keyword, or don’t declare it
at all, it’s still virtual.
By the way, if you’re interested, here are the mechanical details of why you need
a virtual destructor when someone says delete using a Base pointer that’s pointing at
a Derived object. When you say delete p, and the class of p has a virtual destructor, the
destructor that gets invoked is the one associated with the type of the object *p, not necessarily the
one associated with the type of the pointer. This is A Good Thing. In fact, violating that rule makes
your program undefined. The technical term for that is, “Yuck.”
Why are destructors not virtual by default?
Because many classes are not designed to be used as base classes. Virtual functions make sense only
in classes meant to act as interfaces to objects of derived classes (typically allocated on a heap and
accessed through pointers or references).
So when should I declare a destructor virtual? Whenever the class has at least one virtual function.
Having virtual functions indicate that a class is meant to act as an interface to derived classes, and
when it is, an object of a derived class may be destroyed through a pointer to the base. For example:
1. class Base {
2. // ...
3. virtual ~Base();
4. };
5.
6. class Derived : public Base {
7. // ...
8. ~Derived();
9. };
10.
11. void f()
12. {
13. Base* p = new Derived;
14. delete p; // virtual destructor used to ensure that ~Derived is called
15. }
Had Base’s destructor not been virtual, Derived’s destructor would not have been called – with
likely bad effects, such as resources owned by Derived not being freed.
What is a “virtual constructor”?
An idiom that allows you to do something that C++ doesn’t directly support.
You can get the effect of a virtual constructor by a virtual clone() member function (for
copy constructing), or a virtual create() member function (for the default constructor).
1. class Shape {
2. public:
3. virtual ~Shape() { } // A virtual destructor
4. virtual void draw() = 0; // A pure virtual function
5. virtual void move() = 0;
6. // ...
7. virtual Shape* clone() const = 0; // Uses the copy constructor
8. virtual Shape* create() const = 0; // Uses the default constructor
9. };
10.
11. class Circle : public Shape {
12. public:
13. Circle* clone() const; // Covariant Return Types; see below
14. Circle* create() const; // Covariant Return Types; see below
15. // ...
16. };
17.
18. Circle* Circle::clone() const { return new Circle(*this); }
19. Circle* Circle::create() const { return new Circle(); }
In the clone() member function, the new Circle(*this) code calls Circle’s copy
constructor to copy the state of this into the newly created Circle object. (Note:
unless Circle is known to be final (AKA a leaf), you can reduce the chance of slicing by making
its copy constructor protected.) In the create() member function, the new Circle() code
calls Circle’s default constructor.
Users use these as if they were “virtual constructors”:
1. void userCode(Shape& s)
2. {
3. Shape* s2 = s.clone();
4. Shape* s3 = s.create();
5. // ...
6. delete s2; // You need a virtual destructor here
7. delete s3;
8. }
This function will work correctly regardless of whether the Shape is a Circle, Square, or some
other kind-of Shape that doesn’t even exist yet.
Note: The return type of Circle’s clone() member function is intentionally different from the
return type of Shape’s clone() member function. This is called Covariant Return Types, a feature
that was not originally part of the language. If your compiler complains at the declaration
of Circle* clone() const within class Circle (e.g., saying “The return type is different” or
“The member function’s type differs from the base class virtual function by return type alone”), you
have an old compiler and you’ll have to change the return type to Shape*.
Why don’t we have virtual constructors?
A virtual call is a mechanism to get work done given partial information. In
particular, virtual allows us to call a function knowing only an interfaces and not the exact type
of the object. To create an object you need complete information. In particular, you need to know
the exact type of what you want to create. Consequently, a “call to a constructor” cannot be virtual.
Techniques for using an indirection when you ask to create an object are often referred to as
“Virtual constructors”. For example, see TC++PL3 15.6.2.
For example, here is a technique for generating an object of an appropriate type using an abstract
class:
1. struct F { // interface to object creation functions
2. virtual A* make_an_A() const = 0;
3. virtual B* make_a_B() const = 0;
4. };
5.
6. void user(const F& fac)
7. {
8. A* p = fac.make_an_A(); // make an A of the appropriate type
9. B* q = fac.make_a_B(); // make a B of the appropriate type
10. // ...
11. }
12.
13. struct FX : F {
14. A* make_an_A() const { return new AX(); } // AX is derived from A
15. B* make_a_B() const { return new BX(); } // BX is derived from B
16. };
17.
18. struct FY : F {
19. A* make_an_A() const { return new AY(); } // AY is derived from A
20. B* make_a_B() const { return new BY(); } // BY is derived from B
21. };
22.
23. int main()
24. {
25. FX x;
26. FY y;
27. user(x); // this user makes AXs and BXs
28. user(y); // this user makes AYs and BYs
29.
30. user(FX()); // this user makes AXs and BXs
31. user(FY()); // this user makes AYs and BYs
32. // ...
33. }
This is a variant of what is often called “the factory pattern”. The point is that user() is completely
isolated from knowledge of classes such as AX and AY.

Inheritance — Proper Inheritance and

Substitutability
Save to:
InstapaperPocketReadability
Contents of this section:

 Should I hide member functions that were public in my base class?

 Converting Derived* → Base* works okay; why doesn’t Derived** → Base** work?
 Is a parking-lot-of-Car a kind-of parking-lot-of-Vehicle?
 Is an array of Derived a kind-of array of Base?
 Does array-of-Derived is-not-a-kind-of array-of-Base mean arrays are bad?
 Is a Circle a kind-of an Ellipse?
 Are there other options to the “Circle is/isnot kind-of Ellipse” dilemma?
 But I have a Ph.D. in Mathematics, and I’m sure a Circle is a kind of an Ellipse! Does this
mean Marshall Cline is stupid? Or that C++ is stupid? Or that OO is stupid?
 Perhaps Ellipse should inherit from Circle then?
 But my problem doesn’t have anything to do with circles and ellipses, so what good is that
silly example to me?
 How could “it depend”??!? Aren’t terms like “Circle” and “Ellipse” defined mathematically?
 If SortedList has exactly the same public interface as List, is SortedList a kind-
of List?
Should I hide member functions that were public in my
base class?
Never, never, never do this. Never. Never!
 Attempting to hide (eliminate, revoke, privatize) inherited public member functions is an all-too-
common design error. It usually stems from muddy thinking.
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
Converting Derived* → Base* works okay; why
doesn’t Derived** → Base** work?
Because converting Derived** → Base** would be invalid and dangerous.
C++ allows the conversion Derived* → Base*, since a Derived object is a kind of
a Base object. However trying to convert Derived** → Base** is flagged as an error. Although
this error may not be obvious, it is nonetheless a good thing. For example, if you could
convert Car** → Vehicle**, and if you could similarly
convert NuclearSubmarine** → Vehicle**, you could assign those two pointers and end up
making a Car* point at a NuclearSubmarine:
1. class Vehicle {
2. public:
3. virtual ~Vehicle() { }
4. virtual void startEngine() = 0;
5. };
6.
7. class Car : public Vehicle {
8. public:
9. virtual void startEngine();
10. virtual void openGasCap();
11. };
12.
13. class NuclearSubmarine : public Vehicle {
14. public:
15. virtual void startEngine();
16. virtual void fireNuclearMissile();
17. };
18.
19. int main()
20. {
21. Car car;
22. Car* carPtr = &car;
23. Car** carPtrPtr = &carPtr;
24. Vehicle** vehiclePtrPtr = carPtrPtr; // This is an error in C++
25. NuclearSubmarine sub;
26. NuclearSubmarine* subPtr = &sub;
27. *vehiclePtrPtr = subPtr;
28. // This last line would have caused carPtr to point to sub !
29. carPtr->openGasCap(); // This might call fireNuclearMissile()!
30. // ...
31. }
In other words, if it were legal to convert Derived** → Base**, the Base** could be
dereferenced (yielding a Base*), and the Base* could be made to point to an object of
a different derived class, which could cause serious problems for national security (who knows what
would happen if you invoked the openGasCap() member function on what you thought was
a Car, but in reality it was a NuclearSubmarine!!). Try the above code out and see what it does
— on most compilers it will call NuclearSubmarine::fireNuclearMissile()!
(BTW you’ll need to use a pointer cast to get it to compile. Suggestion: try to compile it without a
pointer cast to see what the compiler does. If you’re really quiet when the error message appears on
the screen, you should be able to hear the muffled voice of your compiler pleading with you,
 “Please don’t use a pointer cast! Pointer casts prevent me from telling you about errors in your code,
but they don’t make your errors go away! Pointer casts are evil!” At least that’s what my compiler
says.)
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
(Note: there is a conceptual similarity between this and the prohibition against
converting Foo** to const Foo**.)
Is a parking-lot-of-Car a kind-of parking-lot-of-Vehicle?
Nope.
I know it sounds strange, but it’s true. You can think of this as a direct consequence of the previous
FAQ, or you can reason it this way: if the kind-of relationship were valid, then someone could point
a parking-lot-of-Vehicle pointer at a parking-lot-of-Car, which would allow someone to
add any kind of Vehicle to a parking-lot-of-Car (assuming parking-lot-of-Vehicle has a member
function like add(Vehicle&)). In other words, you could park a Bicycle, SpaceShuttle, or
even a NuclearSubmarine in a parking-lot-of-Car. Certainly it would be surprising if someone
accessed what they thought was a Car from the parking-lot-of-Car, only to find that it is actually
a NuclearSubmarine. Gee, I wonder what the openGasCap() method would do??
Perhaps this will help: a container of Thing is not a kind-of container of Anything even if
a Thing is a kind-of an Anything. Swallow hard; it’s true.
You don’t have to like it. But you do have to accept it.
One last example which we use in our OO/C++ training courses: “A Bag-of-Apple is not a kind-
of Bag-of-Fruit.” If a Bag-of-Apple could be passed as a Bag-of-Fruit, someone could put
a Banana into the Bag, even though it is supposed to only contain Apples!
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
Is an array of Derived a kind-of array of Base?
Nope.
This is a corollary of the previous FAQ. Unfortunately this one can get you into a lot of hot water.
Consider this:
1. class Base {
2. public:
3. virtual void f(); // 1
4. };
5.
6. class Derived : public Base {
7. public:
8. // ...
9. private:
10. int i_; // 2
11. };
12.
13. void userCode(Base* arrayOfBase)
14. {
15. arrayOfBase[1].f(); // 3
16. }
17.
18. int main()
19. {
20. Derived arrayOfDerived[10]; // 4
21. userCode(arrayOfDerived); // 5
22. // ...
23. }
The compiler thinks this is perfectly type-safe. Line 5 converts a Derived* to a Base*. But in
reality it is horrendously evil: since Derived is larger than Base, the pointer arithmetic done on
line 3 is incorrect: the compiler uses sizeof(Base) when computing the address
for arrayOfBase[1], yet the array is an array of Derived, which means the address computed on
line 3 (and the subsequent invocation of member function f()) isn’t even at the beginning of any
object! It’s smack in the middle of a Derived object. Assuming your compiler uses the usual
approach to virtual functions, this will reinterpret the int i_ of the first Derived as if it
pointed to a virtual table, it will follow that “pointer” (which at this point means we’re digging stuff
out of a random memory location), and grab one of the first few words of memory at that location
and interpret them as if they were the address of a C++ member function, then load that (random
memory location) into the instruction pointer and begin grabbing machine instructions from that
memory location. The chances of this crashing are very high.
The root problem is that C++ can’t distinguish between a pointer-to-a-thing and a pointer-to-an-
array-of-things. Naturally C++ “inherited” this feature from C.
NOTE: If we had used an array class (e.g., std::array<Derived, 10> from the standard
library) instead of using a raw array, this problem would have been properly trapped as an error at
compile time rather than a run-time disaster.
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
Does array-of-Derived is-not-a-kind-of array-of-Base mean
arrays are bad?
Yes, arrays are evil. (only half kidding).
Seriously, arrays are very closely related to pointers, and pointers are notoriously difficult to deal
with. But if you have a complete grasp of why the above few FAQs were a problem from a design
perspective (e.g., if you really know why a container of Thing is not a kind-of container
of Anything), and if you think everyone else who will be maintaining your code also has a full
grasp on these OO design truths, then you should feel free to use arrays. But if you’re like most
people, you should use a template container class such as std::array<T, N> from the standard
library rather than fixed size raw arrays.
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
Is a Circle a kind-of an Ellipse?
Depends. But not if Ellipse guarantees it can change its size asymmetrically.
For example, if Ellipse has a setSize(x,y) member function that promises the
object’s width() will be x and its height() will be y, Circle can’t be a kind-of Ellipse.
Simply put, if Ellipse can do something Circle can’t, then Circle can’t be a kind of Ellipse.
This leaves two valid relationships between Circle and Ellipse:
 Make Circle and Ellipse completely unrelated classes
 Derive Circle and Ellipse from a base class representing “Ellipses that
can’t necessarily perform an unequal-setSize() operation”
In the first case, Ellipse could be derived from class AsymmetricShape,
and setSize(x,y) could be introduced in AsymmetricShape. However Circle could be
derived from SymmetricShape which has a setSize(size) member function.
 In the second case, class Oval could only have setSize(size) which sets both
the width() and the height() to size. Ellipse and Circle could both inherit
from Oval. Ellipse —but not Circle— could add the setSize(x,y) operation (but beware of
the hiding rule if the same member function name setSize() is used for both operations).
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
(Note: setSize(x,y) isn’t sacred. Depending on your goals, it may be okay to prevent users from
changing the dimensions of an Ellipse, in which case it would be a valid design choice to not
have a setSize(x,y) method in Ellipse. However this series of FAQs discusses what to do
when you want to create a derived class of a pre-existing base class that has an “unacceptable”
method in it. Of course the ideal situation is to discover this problem when the base class doesn’t yet
exist. But life isn’t always ideal…)
Are there other options to the “Circle is/isnot kind-
of Ellipse” dilemma?
If you claim that all Ellipses can be squashed asymmetrically, and you claim that Circle is a
kind-of Ellipse, and you claim that Circle can’t be squashed asymmetrically, clearly you’ve got
to revoke one of your claims. You can get rid of Ellipse::setSize(x,y), get rid of the
inheritance relationship between Circle and Ellipse, or admit that your Circles aren’t
necessarily circular. You can also get rid of Circle completely, where circleness is just a
temporary state of an Ellipse object rather than a permanent quality of the object.
Here are the two most common traps new OO/C++ programmers regularly fall into. They attempt to
use coding hacks to cover up a broken design, e.g., they might
redefine Circle::setSize(x,y) to throw an exception, call abort(), choose the average of the
two parameters, or to be a no-op. Unfortunately all these hacks will surprise users, since users are
expecting width() == x and height() == y. The one thing you must not do is surprise your
users.
If it is important to you to retain the “Circle is a kind-of Ellipse” inheritance relationship, you
can weaken the promise made by Ellipse’s setSize(x,y). E.g., you could change the promise
to, “This member function might set width() to x and/or it might set height() to y, or it might
do nothing”. Unfortunately this dilutes the contract into dribble, since the user can’t rely on any
meaningful behavior. The whole hierarchy therefore begins to be worthless (it’s hard to convince
someone to use an object if you have to shrug your shoulders when asked what the object does for
them).
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
(Note: setSize(x,y) isn’t sacred. Depending on your goals, it may be okay to prevent users from
changing the dimensions of an Ellipse, in which case it would be a valid design choice to not
have a setSize(x,y) method in Ellipse. However this series of FAQs discusses what to do
when you want to create a derived class of a pre-existing base class that has an “unacceptable”
method in it. Of course the ideal situation is to discover this problem when the base class doesn’t yet
exist. But life isn’t always ideal…)
But I have a Ph.D. in Mathematics, and I’m sure a Circle is
a kind of an Ellipse! Does this mean Marshall Cline is
stupid? Or that C++ is stupid? Or that OO is stupid?
Actually, it doesn’t mean any of these things. But I’ll tell you what it does mean — you may not
like what I’m about to say: it means your intuitive notion of “kind of” is leading you to make bad
 inheritance decisions. Your tummy is lying to you about what good inheritance really means — stop
believing those lies.
Look, I have received and answered dozens of passionate e-mail messages about this subject. I have
taught it hundreds of times to thousands of software professionals all over the place. I know it goes
against your intuition. But trust me; your intuition is wrong, where “wrong” means “will cause you
to make bad inheritance decisions in OO design/programming.”
Here’s how to make good inheritance decisions in OO design/programming: recognize that the
derived class objects must be substitutable for the base class objects. That means objects of the
derived class must behave in a manner consistent with the promises made in the base class’ contract.
Once you believe this, and I fully recognize that you might not yet but you will if you work at it
with an open mind, you’ll see that setSize(x,y) violates this substitutability.
There are three ways to fix this problem:
1. Soften the promises made by setSize(x,y) in base class Ellipse, or perhaps remove
that method completely, at the risk of breaking existing code that calls setSize(x,y).
2. Strengthen the promises made by setSize(x,y) in the derived class Circle, which really
means allowing a Circle to have a different height than width — an asymmetrical circle;
hmmm.
3. Drop the inheritance relationship, possibly getting rid of class Circle completely (in which
case circleness would simply be a temporary state of an Ellipse rather than a permanent
constraint on the object).
Sorry, but there simply are no other choices.
You must make the base class weaker (weaken Ellipse to the point that it no longer guarantees
you can set its width and height to different values), make the derived class stronger (empower
a Circle with the ability to be both symmetric and, ahem, asymmetric), or admit that a Circle is
not substitutable for Ellipse.
Important: there really are no other choices than the above three. In particular:
1. PLEASE don’t write me and tell me that a fourth option is to derive
both Circle and Ellipse from a third common base class. That’s not a fourth solution. That’s
just a repackaging of solution #3: it works precisely because it removes the inheritance
relationship between Circle and Ellipse.
2. PLEASE don’t write me and tell me that a fourth option is to prevent users from changing the
dimensions of an “Ellipse.” That is not a fourth solution. That’s just a repackaging of solution #1:
it works precisely because it removes that guarantee that setSize(x,y) actually sets the width
and height.
3. PLEASE don’t write me and tell me that you’ve decided one of these three is “the best”
solution. Doing that would show you had missed the whole point of this FAQ, specifically that
bad inheritance is subtle but fortunately you have three (not one; not two; but three) possible ways
to dig yourself out. So when you run into bad inheritance, please try all three of these techniques
and select the best, perhaps “least bad,” of the three. Don’t throw out two of these tools ahead of
time: try them all.
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
(Note: some people correctly point out that a constant Circle is substitutable for
a constant Ellipse. That’s true, but it’s really not a fourth option: it’s really just a special case of
option #1, since it works precisely because a constant Ellipse doesn’t have
a setSize(x,y) method.)
Perhaps Ellipse should inherit from Circle then?
If Circle is the base class and Ellipse is the derived class, then you run into a whole new set of
problems. For example, suppose Circle has a radius() method. Then Ellipse will also need to
have a radius() method, but that doesn’t make much sense: what does it even mean for a possibly
assymetric ellipse to have a radius?
If you get over that hurdle, such as by having Ellipse::radius() return the average of the
major and minor axes or whatever, then there is a problem with the relationship
between radius() and area(). Suppose Circle has an area() method that promises to
return pi times the square of whatever radius() returns. Then either Ellipse::area() will not
return the true area of the ellipse, or you’ll have to stand on your head to get radius() to return
something that matches the above formula.
Even if you get past that one, such as by having Ellipse::radius() return the square root of the
ellipse’s area divided by pi, you’ll get stuck by the circumference() method.
Suppose Circle has a circumference() method that promises to return two times pi times
whatever is returned by radius(). Now you’re stuck: there’s no way to make all those constraints
work out for Ellipse: the Ellipse class will have to lie about its area, its circumference, or both.
Bottom line: you can make anything inherit from anything provided the methods in the derived class
abide by the promises made in the base class. But you ought not to use inheritance just because you
feel like it, or just because you want to get code reuse. You should use inheritance (a) only if the
derived class’s methods can abide by all the promises made in the base class, and (b) only if you
don’t think you’ll confuse your users, and (c) only if there’s something to be gained by using the
inheritance — some real, measurable improvement in time, money or risk.
But my problem doesn’t have anything to do with circles
and ellipses, so what good is that silly example to me?
Ahhh, there’s the rub. You think the Circle/Ellipse example is just a silly example. But in
reality, your problem is an isomorphism to that example.
I don’t care what your inheritance problem is, but all —yes all— bad inheritances boil down to
the Circle-is-not-a-kind-of-Ellipse example.
Here’s why: Bad inheritances always have a base class with an extra capability (often an extra
member function or two; sometimes an extra promise made by one or a combination of member
functions) that a derived class can’t satisfy. You’ve either got to make the base class weaker, make
the derived class stronger, or eliminate the proposed inheritance relationship. I’ve seen lots and lots
and lots of these bad inheritance proposals, and believe me, they all boil down to
the Circle/Ellipse example.
Therefore, if you truly understand the Circle/Ellipse example, you’ll be able to recognize bad
inheritance everywhere. If you don’t understand what’s going on with
the Circle/Ellipse problem, the chances are high that you’ll make some very serious and very
expensive inheritance mistakes.
Sad but true.
(Note: this FAQ has to do with public inheritance; private and protected inheritance are
different.)
How could “it depend”??!? Aren’t terms like “Circle” and
“Ellipse” defined mathematically?
It’s irrelevant that those terms are defined mathematically. That irrelevance is why “it depends.”
The first step in any rational discussion is to define terms. In this case, the first step is to define the
terms Circle and Ellipse. Believe it or not, most heated disagreements over whether
class Circle should/shouldn’t inherit from class Ellipse are caused by incompatible definitions
of those terms.
The key insight is to forget mathematics and “the real world,” and instead accept as final the only
definitions that are relevant for answering the question: the classes themselves. Take Ellipse. You
created a class with that name, so the one and only final arbiter of what you meant by that term is
your class. People who try to mix “the real world” into the discussion get hopelessly confused, and
often get into heated (and, sadly, meaningless) arguments.
Since so many people just don’t get it, here’s an example. Suppose your program says class
Foo : public Bar { ... }. This defines what you mean by the term Foo: the one, final,
unambiguous, precise definition of Foo is given by unioning the public parts of Foo with the public
parts of its base class, Bar. Now suppose you decide to
rename Bar to Ellipse and Foo to Circle. This means that you (yes you; not “mathematics”; not
“history”; not “precedence” nor Euclid nor Euler nor any other famous mathematician; little old
you) have defined the meaning of the term Circle within your program. If you defined it in a way
that didn’t correspond to people’s intuitive notion of circles, then you probably should have chosen
a better label for your class, but nonetheless your definition is the one, final, unambiguous, precise
definition of the term Circle in your program. If somebody else outside your program defines the
same term differently, that other definition is irrelevant to questions about your program, even if the
“somebody else” is Euclid. Within your program, you define the terms, and the term Circle is
defined by your class named Circle.
Simply put, when we are asking questions about words defined in your program, we must
use your definitions of those terms, not Euclid’s. That is why the ultimate answer to the question is
“it depends.” It depends because the answer to whether the thing your program calls Circle is
properly substitutable for the thing your program calls Ellipse depends on exactly
how your program defines those terms. It’s ridiculous and misleading to use Euclid’s definition
when trying to answer questions about your classes in your program; we must use your definitions.
When someone gets heated about this, I always suggest changing the labels to terms that have no
predetermined connotations, such as Foo and Bar. Since those terms do not evoke any
mathematical relationships, people naturally go to the class definition to find out exactly what the
programmer had in mind. But as soon as we rename the class from Foo to Circle, some people
suddenly think they can control the meaning of the term; they’re wrong and silly. The definition of
the term is still spelled out exclusively by the class itself, not by any outside entity.
Next insight: inheritance means “is substitutable for.” It does not mean “is a” (since that is ill
defined) and it does not mean “is a kind of” (also ill defined). Substitutability is well defined: to be
substitutable, the derived class is allowed (not required) to add (not remove) public methods, and for
each public method inherited from the base class, the derived class is allowed (not required) to
weaken preconditions and/or strengthen postconditions (not the other way around). Further the
derived class is allowed to have completely different constructors, static methods, and non-public
methods.
Back to Ellipse and Circle: if you define the term Ellipse to mean something that can be
resized asymmetrically (e.g., its methods let you change the width and height
independently and guarantee that the width and height will actually change to the specified values),
then that is the final, precise definition of the term Ellipse. If you define the thing
called Circle as something that cannot be resized asymmetrically, then that is also your
prerogative, and it is the final, precise definition of the term Circle. If you defined those terms in
that way, then obviously the thing you called Circle is not substitutable for the thing you
called Ellipse, therefore the inheritance would be improper. QED.
 So the answer is always “it depends.” In particular, it depends on the behaviors of the base and
derived classes. It does not depend on the name of the base and derived classes, since those are
arbitrary labels. (I’m not advocating sloppy names; I am, however, saying that you must not use
your intuitive connotation of a name to assume you know what a class does. A class does what it
does, not what you think it ought to do based on its name.)
It bothers (some) people that the thing you called Circle might not be substitutable for the thing
you called Ellipse, and to those people I have only two things to say: (a) get over it, and (b)
change the labels of the classes if that makes you feel more comfortable. For example,
rename Ellipse to ThingThatCanBeResizedAssymetrically and Circle to ThingThatCa
nnotBeResizedAssymetrically.
Unfortunately I honestly believe that people who feel better after renaming the things are missing
the point. The point is this: in OO, a thing is defined by how it behaves, not by the label used to
name it. Obviously it’s important to choose good names, but even so, the name chosen does not
define the thing. The definition of the thing is specified by the public methods, including the
contracts (preconditions and postconditions) of those methods. Inheritance is proper or improper
based on the classes’ behaviors, not their names.
If SortedList has exactly the same public interface
as List, is SortedList a kind-of List?
Probably not.
The most important insight is that the answer depends on the details of the base class’s contract. It is
not enough to know that the public interfaces / method signatures are compatible; one also needs to
know if the contracts / behaviors are compatible.
The important part of the previous sentence are the words “contracts / behaviors.” That phrase goes
well beyond the public interface = method signatures = method names and parameter types
and constness. A method’s contract means its advertised behavior = advertised requirements and
promises = advertised preconditions and postconditions. So if the base class has a method void
insert(const Foo& x), the contract of that method includes the signature (meaning the
name insert and the parameter const Foo&), but goes well beyond that to include the method’s
advertised preconditions and postconditions.
The other important word is advertised. The intention here is to differentiate between the code inside
the method (assuming the base class’s method has code; i.e., assuming it’s not an unimplemented
pure virtual function) and the promises made outside the method. This is where things get tricky.
Suppose List::insert(const Foo& x) inserts a copy of x at the end of this List, and the
override of that method in SortedList inserts x in the proper sort-order. Even though the override
behaves in a way that is incompatible with the base class’s code, the inheritance might still be
proper if the base class makes a “weak” or “adaptable” promise. For example, if the advertised
promise of List::insert(const Foo& x) is something vague like, “Promises a copy of x will
be inserted somewhere within this List,” then the inheritance is probably okay since the override
abides by the advertised behavior even though it is incompatible with the implemented behavior.
The derived class must do what the base class promises, not what it actually does.
The key is that we’ve separated the advertised behavior (“specification”) from implemented
behavior (“implementation”), and we rely on the specification rather than the implementation. This
is very important because in a large percentage of the cases the base class’s method is an
unimplemented pure virtual — the only thing that can be relied on is the specification — there
simply is no implementation on which to rely.
Back to SortedList and List: it seems likely that List has one or more methods that have
contracts which guarantee order, and therefore SortedList is probably not a kind-of List. For
 example, if List has a method that lets you reorder things, prepend things, append things, or
change the ith element, and if those methods make the typical advertised promise,
then SortedList would need to violate that advertised behavior and the inheritance would be
improper. But it all depends on what the base class advertises — on the base class’s contract.

Inheritance — Abstract Base Classes (ABCs)

Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the big deal of separating interface from implementation?

 How do I separate interface from implementation in C++ (like Modula-2)?
 What is an ABC?
 What is a “pure virtual” member function?
 How do you define a copy constructor or assignment operator for a class that contains a
pointer to a (abstract) base class?
What’s the big deal of separating interface from
implementation?
Interfaces are a company’s most valuable resources. Designing an interface takes longer than
whipping together a concrete class which fulfills that interface. Furthermore interfaces require the
time of more expensive people.
Since interfaces are so valuable, they should be protected from being tarnished by data structures
and other implementation artifacts. Thus you should separate interface from implementation.

How do I separate interface from implementation in C++

(like Modula-2)?
Use an ABC.
What is an ABC?
An abstract base class.
At the design level, an abstract base class (ABC) corresponds to an abstract concept. If you asked a
mechanic if he repaired vehicles, he’d probably wonder what kind-of vehicle you had in mind.
Chances are he doesn’t repair space shuttles, ocean liners, bicycles, or nuclear submarines. The
problem is that the term “vehicle” is an abstract concept (e.g., you can’t build a “vehicle” unless you
know what kind of vehicle to build). In C++, class Vehicle would be an ABC,
with Bicycle, SpaceShuttle, etc, being derived classes (an OceanLiner is-a-kind-of-
a Vehicle). In real-world OO, ABCs show up all over the place.
At the programming language level, an ABC is a class that has one or more pure virtual member
functions. You cannot make an object (instance) of an ABC.
What is a “pure virtual” member function?
A member function declaration that turns a normal class into an abstract class (i.e., an ABC). You
normally only implement it in a derived class.
Some member functions exist in concept; they don’t have any reasonable definition. E.g., suppose I
asked you to draw a Shape at location (x,y) that has size 7. You’d ask me “what kind of shape
should I draw?” (circles, squares, hexagons, etc, are drawn differently). In C++, we must indicate
 the existence of the draw() member function (so users can call it when they have a Shape* or
a Shape&), but we recognize it can (logically) be defined only in derived classes:
1. class Shape {
2. public:
3. virtual void draw() const = 0; // = 0 means it is "pure virtual"
4. // ...
5. };
This pure virtual function makes Shape an ABC. If you want, you can think of the “= 0;” syntax
as if the code were at the NULL pointer. Thus Shape promises a service to its users, yet Shape isn’t
able to provide any code to fulfill that promise. This forces any actual object created from a
[concrete] class derived from Shape to have the indicated member function, even though the base
class doesn’t have enough information to actually define it yet.
Note that it is possible to provide a definition for a pure virtual function, but this usually confuses
novices and is best avoided until later.

How do you define a copy constructor or

assignment operator for a class that contains a pointer to
a (abstract) base class?
If the class “owns” the object pointed to by the (abstract) base class pointer, use the Virtual
Constructor Idiom in the (abstract) base class. As usual with this idiom, we declare
a pure virtual clone() method in the base class:
1. class Shape {
2. public:
3. // ...
4. virtual Shape* clone() const = 0; // The Virtual (Copy) Constructor
5. // ...
6. };
Then we implement this clone() method in each derived class. Here is the code for derived
class Circle:
1. class Circle : public Shape {
2. public:
3. // ...
4. virtual Circle* clone() const;
5. // ...
6. };
7.
8. Circle* Circle::clone() const
9. {
10. return new Circle(*this);
11. }
(Note: the return type in the derived class is intentionally different from the one in the base class.)
Here is the code for derived class Square:
1. class Square : public Shape {
2. public:
3. // ...
4. virtual Square* clone() const;
5. // ...
6. };
7.
8. Square* Square::clone() const
9. {
10. return new Square(*this);
11. }
 Now suppose that each Fred object “has-a” Shape object. Naturally the Fred object doesn’t know
whether the Shape is Circle or a Square or … Fred’s copy constructor and
assignment operator will invoke Shape’s clone() method to copy the object:
1. class Fred {
2. public:
3. // p must be a pointer returned by new; it must not be NULL
4. Fred(Shape* p)
5. : p_(p) { assert(p != NULL); }
6. ~Fred()
7. { delete p_; }
8. Fred(const Fred& f)
9. : p_(f.p_->clone()) { }
10. Fred& operator= (const Fred& f)
11. {
12. if (this != &f) { // Check for self-assignment
13. Shape* p2 = f.p_->clone(); // Create the new one FIRST...
14. delete p_; // ...THEN delete the old one
15. p_ = p2;
16. }
17. return *this;
18. }
19. // ...
20. private:
21. Shape* p_;
22. };

Inheritance — What your mother never told

you
Save to:
InstapaperPocketReadability
Contents of this section:

 How can I set up my class so it won’t be inherited from?

 How can I set up my member function so it won’t be overridden in a derived class?
 Is it okay for a non-virtual function of the base class to call a virtual function?
 That last FAQ confuses me. Is it a different strategy from the other ways to
use virtual functions? What’s going on?
 Should I use protected virtuals instead of public virtuals?
 When should someone use private virtuals?
 When my base class’s constructor calls a virtual function on its this object, why doesn’t
my derived class’s override of that virtual function get invoked?
 Okay, but is there a way to simulate that behavior as if dynamic binding worked on
the this object within my base class’s constructor?
 I’m getting the same thing with destructors: calling a virtual on my this object from my
base class’s destructor ends up ignoring the override in the derived class; what’s going on?
 Should a derived class redefine (“override”) a member function that is non-virtual in a
base class?
 What’s the meaning of, Warning: Derived::f(char) hides Base::f(double) ?
 Why doesn’t overloading work for derived classes?
 What does it mean that the “virtual table” is an unresolved external?
 How can I set up my class so it won’t be inherited from?
Just declare the class final.
But also ask yourself why you want to? There are two common answers:
 For efficiency: to avoid your function calls being virtual.
 For safety: to ensure that your class is not used as a base class (for example, to be sure that
you can copy objects without fear of slicing).
In today’s usual implementations, calling a virtual function entails fetching the “vptr” (i.e. the
pointer to the virtual table) from the object, indexing into it via a constant, and calling the function
indirectly via the pointer to function found at that location. A regular call is most often a direct call
to a literal address. Although a virtual call seems to be a lot more work, the right way to judge costs
is in comparison to the work actually carried by the function. If that work is significant, the cost of
the call itself is negligible by comparison and often cannot be measured. If, however, the function
body is simple (i.e. an accessor or a forward), the cost of a virtual call can be measurable and
sometimes significant.
The virtual function call mechanism is typically used only when calling through a pointer or a
reference. When calling a function directly for a named object (e.g. one allocated on the stack of the
caller), the compiler inserts code for a regular call. Note, however, that frequent such use may
indicate other problems with the design - virtual functions work only in tandem with polymorphism
and indirect use (pointers and references). Such cases may warrant a design review for overuse
of virtual.
How can I set up my member function so it won’t be
overridden in a derived class?
Just declare the function final.
But again, ask yourself why you want to. See the reasons under given for final classes.
Is it okay for a non-virtual function of the base class to
call a virtual function?
Yes. It’s sometimes (not always!) a great idea. For example, suppose all Shape objects have a
common algorithm for printing, but this algorithm depends on their area and they all have a
potentially different way to compute their area. In this case Shape’s area() member function
would necessarily have to be virtual (probably pure virtual) but Shape::print() could, if
we were guaranteed no derived class wanted a different algorithm for printing, be a non-
virtual defined in the base class Shape.
1. #include "Shape.h"
2.
3. void Shape::print() const
4. {
5. float a = this->area(); // area() is pure virtual
6. // ...
7. }

That last FAQ confuses me. Is it a different strategy from

the other ways to use virtual functions? What’s going
on?
Yes, it is a different strategy. Yes, there really are two different basic ways to
use virtual functions:
 1. Suppose you have the situation described in the previous FAQ: you have a member function
whose overall structure is the same for each derived class, but has little pieces that are different in
each derived class. So the algorithm is the same, but the primitives are different. In this case
you’d write the overall algorithm in the base class as a public member function (that’s
sometimes non-virtual), and you’d write the little pieces in the derived classes. The little pieces
would be declared in the base class (they’re often protected, they’re often pure virtual, and
they’re certainly virtual), and they’d ultimately be defined in each derived class. The most critical
question in this situation is whether or not the public member function containing the overall
algorithm should be virtual. The answer is to make it virtual if you think that some derived
class might need to override it.
2. Suppose you have the exact opposite situation from the previous FAQ, where you have a
member function whose overall structure is different in each derived class, yet it has little pieces
that are the same in most (if not all) derived classes. In this case you’d put the overall algorithm in
a public virtual that’s ultimately defined in the derived classes, and the little pieces of
common code can be written once (to avoid code duplication) and stashed somewhere
(anywhere!). A common place to stash the little pieces is in the protected part of the base class,
but that’s not necessary and it might not even be best. Just find a place to stash them and you’ll be
fine. Note that if you do stash them in the base class, you should normally make
them protected, since normally they do things that public users don’t need/want to do.
Assuming they’re protected, they probably shouldn’t be virtual: if the derived class doesn’t
like the behavior in one of them, it doesn’t have to call that member function.
For emphasis, the above list is a both/and situation, not an either/or situation. In other words, you
don’t have to choose between these two strategies on any given class. It’s perfectly normal to have
member function f() correspond to strategy #1 while member function g() corresponds to strategy
#2. In other words, it’s perfectly normal to have both strategies working in the same class.
Should I use protected virtuals instead of public
virtuals?
Sometimes yes, sometimes no.
First, stay away from always/never rules, and instead use whichever approach is the best fit for the
situation. There are at least two good reasons to use protected virtuals (see below), but just because
you are sometimes better off with protected virtuals does not mean you should always use them.
Consistency and symmetry are good up to a point, but at the end of the day the most important
metrics are cost + schedule + risk, and unless an idea materially improves cost and/or schedule
and/or risk, it’s just symmetry for symmetry’s sake (or consistency for consistency’s sake, etc.).
The cheapest + fastest + lowest risk approach in my experience ends up resulting in most virtuals
being public, with protected virtuals being used whenever you have either of these two cases: the
situation discussed in the previous FAQ or the situation discussed in relation to the hiding rule.
The latter deserves some additional commentary. Pretend you have a base class with a set of
overloaded virtuals. To make the example easy, pretend there are just two: virtual void
f(int) and virtual void f(double). The idea of the Public Overloaded Non-Virtuals Call
Protected Non-Overloaded Virtuals idiom is to change the public overloaded member functions to
non-virtuals, and make those call protected non-overloaded virtuals.
Code using public overloaded virtuals:
1. class Base {
2. public:
3. virtual void f(int x); // May or may not be pure virtual
4. virtual void f(double x); // May or may not be pure virtual
5. };
 Improving this via the Public Overloaded Non-Virtuals Call Protected Non-Overloaded Virtuals idiom:
1. class Base {
2. public:
3. void f(int x) { f_int(x); } // Non-virtual
4. void f(double x) { f_dbl(x); } // Non-virtual
5. protected:
6. virtual void f_int(int);
7. virtual void f_dbl(double);
8. };
Here’s an overview of the original code:

Member function Public? Inline? Virtual? Overloaded?

f(int) & f(double) Yes No Yes Yes
Here’s an overview of the improved code that uses the Public Overloaded Non-Virtuals Call
Protected Non-Overloaded Virtuals idiom:
Member function Public? Inline? Virtual? Overloaded?
f(int) & f(double) Yes Yes No Yes
f_int(int) & f_dbl(double) No No Yes No
The reason I and others use this idiom is to make life easier and less error-prone for the developers
of the derived classes. Remember the goals stated above: schedule + cost + risk? Let’s evaluate this
Idiom in light of those goals. From a cost/schedule standpoint, the base class (singular) is slightly
larger but the derived classes (plural) are slightly smaller, for a net (small) improvement in schedule
and cost. The more signicant improvement is in risk: the idiom packs the complexity of properly
managing the hiding rule into the base class (singular). This means the derived classes (plural)
more-or-less automatically handle the hiding rule, so the various developers who produce those
derived classes can remain almost completely focused on the details of the derived classes
themselves — they need not concern themselves with the (subtle and often misunderstood) hiding
rule. This greatly reduces the chance that the writers of the derived classes will screw up the hiding-
rule.
With apologies to Mr. Spock, the needs of the many (the derived classes (plural)) outweigh the
needs of the one (the base class (singular)).
(Read up on the Hiding Rule for why you need to be careful about overriding some-but-not-all of a
set of overloaded member functions, and therefore why the above makes life easier on derived
classes.)
When should someone use private virtuals?
When you need to make specific behavior in a base class customizable in derived classes, while
protecting the semantics of the interface (and/or the base algorithm therein), which is defined in
public member functions that call private virtual member functions.
One case where private virtuals show up is when implementing the Template Method design
pattern. Some experts, e.g., Herb Sutter’s C/C++ Users Journal article Virtuality, advocate it as a
best practice to always define virtual functions private, unless there is a good reason to make them
protected. Virtual functions, in their view, should never be public, because they define the class’
interface, which must remain consistent in all derived classes. Protected and private virtuals define
the class’ customizable behavior, and there is no need to make them public. A public virtual
function would define both interface and a customization point, a duality that could reflect weak
design.
By the way, it confuses most novice C++ programmers that private virtuals can be overridden, let
alone are valid at all. We were all taught that private members in a base class are not accessible in
classes derived from it, which is correct. However this inaccessibility by the derived class does not
 have anything to do with the virtual call mechanism, which is to the derived class. Since that might
confuse novices, the C++ FAQ formerly recommended using protected virtuals rather than private
virtuals. However the private virtual approach is now common enough that confusion of novices is
less of a concern.
You might ask, What good is a function that the derived class can’t call? Even though the derived
class can’t call it in the base class, the base class can call it which effectively calls down to the
(appropriate) derived class. And that’s what the Template Method pattern is all about.
Think of “Back to the Future.” Assume the base class is written last year, and you are about to
create a new derived class later today. The base class’ member functions, which might have been
compiled and stuck into a library months ago, will call the private (or protected) virtual, and that
will effectively “call into the future” - the code which was compiled months ago will call code that
doesn’t even exist yet - code you are about to write in the next few minutes. You can’t access
private members of the base class - you can’t reach into the past, but the past can reach into the
future and call your member functions which you haven’t even written yet.
Here is what that Template Method pattern looks like:
1. class MyBaseClass {
2. public:
3. void myOp();
4.
5. private:
6. virtual void myOp_step1() = 0;
7. virtual void myOp_step2();
8. };
9.
10. void MyBaseClass::myOp()
11. {
12. // Pre-processing...
13.
14. myOp_step1(); // call into the future - call the derived class
15. myOp_step2(); // optionally the future - this one isn't pure virtual
16.
17. // Post-processing...
18. }
19.
20. void MyBaseClass::myOp_step2()
21. {
22. // this is "default" code - it can optionally be customized by a derived class
23. }
In this example, public member function MyBaseClass::myOp() implements the interface and
basic algorithm to perform some operation. The pre- and post-processing, as well as the sequence of
step 1 and step 2, are intentionally fixed and cannot be customized by a derived class.
If MyBaseClass::myOp() was virtual, the integrity of that algorithm would be seriously
compromised. Instead, customization is restricted to specific “pieces” of the algorithm, implemented
in the two private virtual functions. This enforces better compliance of derived classes to the
original intent embodied in the base class, and also makes customization easier - the derived class’
author needs to write less code.
If MyBaseClass::myOp_step2() might need to be called by the derived class, for example, if
the derived class might need (or want) to use that code to simplify its own code, then that can be
promoted from a private virtual to a protected virtual. If that is not possible because the base class
belongs to a different organization, as a band-aid the code can be copied.
(At this point I can almost read your thoughts: “What? Copy code??!? Are you KIDDING??!? That
would increase maintenance cost and duplicate bugs!! Are you CRAZY??!?” Whether I’m crazy
 remains to be seen, but I am experienced enough to realize life sometimes paints you into a corner.
If the base class can’t be modified, sometimes the “least bad” of the bad alternatives is to copy some
code. Remember, one size does not fit all, and “think” is not a four-letter word. So hold your nose
and do whatever is the least bad thing. Then shower. Twice. But if you risk the team’s success
because you are waiting for some third party to change their base class, or if you use #define to
change the meaning of private, you might have chosen a worse evil. And oh yea, if you copy the
code, mark it with a big fat comment so I won’t come along and think you are crazy!! .)
On the other hand, if you are creating the base class and if you aren’t sure whether derived class’s
might want to call MyBaseClass::myOp_step2(), you can declare it protected just in case. And
in that case, you’d better put a big fat comment next to it so Herb doesn’t come along and think
you’re crazy! Either way, somebody is going to think you’re crazy.
When my base class’s constructor calls
a virtual function on its this object, why doesn’t my
derived class’s override of that virtual function get
invoked?
Because that would be very dangerous, and C++ is protecting you from that danger.
The rest of this FAQ gives a rationale for why C++ needs to protect you from that danger, but
before we start that, be advised that you can get the effect as if dynamic binding worked on
the this object even during a constructor via The Dynamic Binding During Initialization Idiom.
You can call a virtual function in a constructor, but be careful. It may not do what you expect. In a
constructor, the virtual call mechanism is disabled because overriding from derived classes hasn’t
yet happened. Objects are constructed from the base up, “base before derived”.
Consider:
1. #include<string>
2. #include<iostream>
3. using namespace std;
4.
5. class B {
6. public:
7. B(const string& ss) { cout << "B constructor\n"; f(ss); }
8. virtual void f(const string&) { cout << "B::f\n";}
9. };
10.
11. class D : public B {
12. public:
13. D(const string & ss) :B(ss) { cout << "D constructor\n";}
14. void f(const string& ss) { cout << "D::f\n"; s = ss; }
15. private:
16. string s;
17. };
18.
19. int main()
20. {
21. D d("Hello");
22. }
the program compiles and produce
1. B constructor
2. B::f
3. D constructor
 Note not D::f. Consider what would happen if the rule were different so that D::f() was called
from B::B(): Because the constructor D::D() hadn’t yet been run, D::f() would try to assign its
argument to an uninitialized string s. The result would most likely be an immediate crash. So
fortunately the C++ language doesn’t let this happen: it makes sure any call to this->f() that
occurs while control is flowing through B’s constructor will end up invoking B::f(), not the
override D::f().
Destruction is done “derived class before base class”, so virtual functions behave as in constructors:
Only the local definitions are used – and no calls are made to overriding functions to avoid touching
the (now destroyed) derived class part of the object.
For more details see D&E 13.2.4.2 or TC++PL3 15.4.3.
It has been suggested that this rule is an implementation artifact. It is not so. In fact, it would be
noticeably easier to implement the unsafe rule of calling virtual functions from constructors exactly
as from other functions. However, that would imply that no virtual function could be written to rely
on invariants established by base classes. That would be a terrible mess.

Okay, but is there a way to simulate that behavior as

if dynamic binding worked on the this object within my
base class’s constructor?
Yes: the Dynamic Binding During Initialization idiom (AKA Calling Virtuals During Initialization).
To clarify, we’re talking about the situation when Base’s constructor calls virtual functions on
its this object:
1. class Base {
2. public:
3. Base();
4. // ...
5. virtual void foo(int n) const; // often pure virtual
6. virtual double bar() const; // often pure virtual
7. // if you don't want outsiders calling these, make them protected
8. };
9.
10. Base::Base()
11. {
12. // ...
13. foo(42); // Warning: does NOT dynamically bind to the derived class
14. bar(); // (ditto)
15. // ...
16. }
17.
18. class Derived : public Base {
19. public:
20. // ...
21. virtual void foo(int n) const;
22. virtual double bar() const;
23. };
This FAQ shows some ways to simulate dynamic binding as if the calls made in Base’s constructor
dynamically bound to the this object’s derived class. The ways we’ll show have tradeoffs, so
choose the one that best fits your needs, or make up another.
The first approach is a two-phase initialization. In Phase I, someone calls the actual constructor; in
Phase II, someone calls an “init” function on the object. Dynamic binding on the this object works
fine during Phase II, and Phase II is conceptually part of construction, so we simply move some code
from the original Base::Base() into Base::init().
1. class Base {
2. public:
3. void init(); // may or may not be virtual
4. // ...
5. virtual void foo(int n) const; // often pure virtual
6. virtual double bar() const; // often pure virtual
7. };
8.
9. void Base::init()
10. {
11. // Almost identical to the body of the original Base::Base()
12. // ...
13. foo(42);
14. bar();
15. // ...
16. }
17.
18. class Derived : public Base {
19. public:
20. // ...
21. virtual void foo(int n) const;
22. virtual double bar() const;
23. };
The only remaining issues are determining where to call Phase I and where to call Phase II. There are
many variations on where these calls can live; we will consider two.
The first variation is simplest initially, though the code that actually wants to create objects requires
a tiny bit of programmer self-discipline, which in practice means you’re doomed. Seriously, if there
are only one or two places that actually create objects of this hierarchy, the programmer self-
discipline is quite localized and shouldn’t cause problems.
In this variation, the code that is creating the object explicitly executes both phases. When executing
Phase I, the code creating the object either knows the object’s exact class (e.g., new Derived() or
perhaps a local Derived object), or doesn’t know the object’s exact class (e.g., the virtual
constructor idiom or some other factory). The “doesn’t know” case is strongly preferred when you
want to make it easy to plug-in new derived classes.
Note: Phase I often, but not always, allocates the object from the heap. When it does, you should
store the pointer in some sort of managed pointer, such as a std::unique_ptr, a reference
counted pointer, or some other object whose destructor deletes the allocation. This is the best way
to prevent memory leaks when Phase II might throw exceptions. The following example assumes
Phase I allocates the object from the heap.
1. #include <memory>
2.
3. void joe_user()
4. {
5. std::unique_ptr<Base> p( /*...somehow create a Derived object via new...*/ );
6. p->init();
7. // ...
8. }
The second variation is to combine the first two lines of the joe_user function into
some create function. That’s almost always the right thing to do when there are lots
of joe_user-like functions. For example, if you’re using some kind of factory, such as a registry
and the virtual constructor idiom, you could move those two lines into a static member function
called Base::create():
1. #include <memory>
2.
3. class Base {
4. public:
5. // ...
6. using Ptr = std::unique_ptr<Base>; // type aliases simplify the code
7. static Ptr create();
8. // ...
9. };
10.
11. Base::Ptr Base::create()
12. {
13. Ptr p( /*...use a factory to create a Derived object via new...*/ );
14. p->init();
15. return p;
16. }
This simplifies all the joe_user-like functions (a little), but more importantly, it reduces the
chance that any of them will create a Derived object without also calling init() on it.
1. void joe_user()
2. {
3. Base::Ptr p = Base::create();
4. // ...
5. }
If you’re sufficiently clever and motivated, you can even eliminate the chance that someone could
create a Derived object without also calling init() on it. An important step in achieving that goal
is to make Derived’s constructors, including its copy constructor, protected or private..
The next approach does not rely on a two-phase initialization, instead using a second hierarchy
whose only job is to house member functions foo() and bar(). This approach doesn’t always
work, and in particular it doesn’t work in cases when foo() and bar() need to access the instance
data declared in Derived, but it is conceptually quite simple and clean and is commonly used.
Let’s call the base class of this second hierarchy Helper, and its derived
classes Helper1, Helper2, etc. The first step is to move foo() and bar() into this second
hierarchy:
1. class Helper {
2. public:
3. virtual void foo(int n) const = 0;
4. virtual double bar() const = 0;
5. };
6.
7. class Helper1 : public Helper {
8. public:
9. virtual void foo(int n) const;
10. virtual double bar() const;
11. };
12.
13. class Helper2 : public Helper {
14. public:
15. virtual void foo(int n) const;
16. virtual double bar() const;
17. };
Next, remove init() from Base (since we’re no longer using the two-phase approach),
remove foo() and bar() from Base and Derived (foo() and bar() are now in
the Helper hierarchy), and change the signature of Base’s constructor so it takes a Helper by
reference:
1. class Base {
2. public:
3. Base(const Helper& h);
4. // Remove init() since not using two-phase this time
5. // Remove foo() and bar() since they're in Helper
6. };
7.
8. class Derived : public Base {
9. public:
10. // Remove foo() and bar() since they're in Helper
11. };
We then define Base::Base(const Helper&) so it calls h.foo(42) and h.bar() in exactly
those places that init() used to call this->foo(42) and this->bar():
1. Base::Base(const Helper& h)
2. {
3. // Almost identical to the body of the original Base::Base()
4. // except for the insertion of h.
5.
6. // ...
7. h.foo(42);
8. h.bar();
9. ↑↑ // The h. occurrences are new
10. // ...
11. }
Finally we change Derived’s constructor to pass a (perhaps temporary) object of an
appropriate Helper derived class to Base’s constructor (using the init list syntax). For
example, Derived would pass an instance of Helper2 if it happened to contain the behaviors
that Derived wanted for functions foo() and bar():
1. Derived::Derived()
2. : Base(Helper2()) // ← the magic happens here
3. {
4. // ...
5. }
Note that Derived can pass values into the Helper derived class’s constructor, but it must not pass
any data members that actually live inside the this object. While we’re at it, let’s explicitly say
that Helper::foo() and Helper::bar() must not access data members of the this object,
particularly data members declared in Derived. (Think about when those data members are
initialized and you’ll see why.)
Of course the choice of which Helper derived class could be made out in the joe_user-like
function, in which case it would be passed into the Derived ctor and then up to the Base ctor:
1. Derived::Derived(const Helper& h)
2. : Base(h)
3. {
4. // ...
5. }
If the Helper objects don’t need to hold any data, that is, if each is merely a collection of its
member functions, then you can simply pass static member functions instead. This might be
simpler since it entirely eliminates the Helper hierarchy.
1. class Base {
2. public:
3. using FooFn = void (*)(int); // type aliases simplify
4. using BarFn = double (*)(); // the rest of the code
5. Base(FooFn foo, BarFn bar);
6. // ...
7. };
8.
9. Base::Base(FooFn foo, BarFn bar)
10. {
11. // Almost identical to the body of the original Base::Base()
12. // except the calls are made via function pointers.
13.
14. // ...
15. foo(42);
16. bar();
17. // ...
18. }
The Derived class is also easy to implement:
1. class Derived : public Base {
2. public:
3. Derived();
4. static void foo(int n); // the static is important!
5. static double bar(); // the static is important!
6. // ...
7. };
8.
9. Derived::Derived()
10. : Base(foo, bar) // ← pass the function-ptrs into Base's ctor
11. {
12. // ...
13. }
As before, the functionality for foo() and/or bar() can be passed in from the joe_user-like
functions. In that case, Derived’s ctor just accepts them and passes them up into Base’s ctor:
1. Derived::Derived(FooFn foo, BarFn bar)
2. : Base(foo, bar)
3. {
4. // ...
5. }
A final approach is to use templates to “pass” the functionality into the derived classes. This is
similar to the case where the joe_user-like functions choose the initializer-function or
the Helper derived class, but instead of using function pointers or dynamic binding, it wires the
code into the classes via templates.
I’m getting the same thing with destructors: calling
a virtual on my this object from my base class’s
destructor ends up ignoring the override in the derived
class; what’s going on?
C++ is protecting you from yourself. What you are trying to do is very dangerous, and if the
compiler did what you wanted, you’d be in worse shape.
For rationale of why C++ needs to protect you from that danger, make sure you understand what
happens when a constructor calls virtuals on its this object. The situation during a destructor is
analogous to that during the constructor. In particular, within the {body} of Base::~Base(), an
object that was originally of type Derived has already been demoted (devolved, if you will) to an
object of type Base. If you call a virtual function that has been overridden in class Derived, the
call will resolve to Base::virt(), not to the override Derived::virt(). Same goes for
using typeid on the this object: the this object really has been demoted to type Base; it is no
longer an object of type Derived.
Reminder to also read this.
 Should a derived class redefine (“override”) a member
function that is non-virtual in a base class?
It’s legal, but it ain’t moral.
Experienced C++ programmers will sometimes redefine a non-virtual function for efficiency
(e.g., if the derived class implementation can make better use of the derived class’s resources) or to
get around the hiding rule. However the client-visible effects must be identical, since non-
virtual functions are dispatched based on the static type of the pointer/reference rather than the
dynamic type of the pointed-to/referenced object.
What’s the meaning of, Warning: Derived::f(char) hides
Base::f(double)?
It means you’re going to die.
Here’s the mess you’re in: if Base declares a member function f(double x),
and Derived declares a member function f(char c) (same name but different parameter types
and/or constness), then the Base f(double x) is “hidden” rather than “overloaded” or
“overridden” (even if the Base f(double x) is virtual).
1. class Base {
2. public:
3. void f(double x); // Doesn't matter whether or not this is virtual
4. };
5.
6. class Derived : public Base {
7. public:
8. void f(char c); // Doesn't matter whether or not this is virtual
9. };
10.
11. int main()
12. {
13. Derived* d = new Derived();
14. Base* b = d;
15. b->f(65.3); // Okay: passes 65.3 to f(double x)
16. d->f(65.3); // Bizarre: converts 65.3 to a char ('A' if ASCII) and passes it to f(char c); does NOT call
f(double x)!!
17. delete d;
18. return 0;
19. }
Here’s how you get out of the mess: Derived must have a using declaration of the hidden
member function. For example,
1. class Base {
2. public:
3. void f(double x);
4. };
5.
6. class Derived : public Base {
7. public:
8. using Base::f; // This un-hides Base::f(double x)
9. void f(char c);
10. };
If the using syntax isn’t supported by your compiler, redefine the hidden Base member
function(s), even if they are non-virtual. Normally this re-definition merely calls the
hidden Base member function using the :: syntax. E.g.,
1. class Derived : public Base {
2. public:
3. void f(double x) { Base::f(x); } // The redefinition merely calls Base::f(double x)
4. void f(char c);
5. };
Note: the hiding problem also occurs if class Base declares a member function f(char).
Note: warnings are not part of the standard, so your compiler may or may not give the above
warning.
Note: nothing gets hidden when you have a base-pointer. Think about it: what a derived class does
or does not do is irrelevant when the compiler is dealing with a base-pointer. The compiler might
not even know that the particular derived class exists. Even if it knows of the existence of some
particular derived class, it cannot assume that a specific base-pointer necessarily points at an object
of that particular derived class. Hiding takes place when you have a derived pointer, not when you
have a base pointer.

Why doesn’t overloading work for derived classes?

That question (in many variations) are usually prompted by an example like this:
1. #include<iostream>
2. using namespace std;
3.
4. class B {
5. public:
6. int f(int i) { cout << "f(int): "; return i+1; }
7. // ...
8. };
9.
10. class D : public B {
11. public:
12. double f(double d) { cout << "f(double): "; return d+1.3; }
13. // ...
14. };
15.
16. int main()
17. {
18. D* pd = new D;
19.
20. cout << pd->f(2) << '\n';
21. cout << pd->f(2.3) << '\n';
22.
23. delete pd;
24. }
which will produce:
1. f(double): 3.3
2. f(double): 3.6
rather than the
1. f(int): 3
2. f(double): 3.6
that some people (wrongly) guessed.
In other words, there is no overload resolution between D and B. Overload resolution conceptually
happens in one scope at a time: The compiler looks into the scope of D, finds the single
function double f(double), and calls it. Because it found a match, it never bothers looking
 further into the (enclosing) scope of B. In C++, there is no overloading across scopes – derived class
scopes are not an exception to this general rule. (See D&E or TC++PL4 for details).
But what if I want to create an overload set of all my f() functions from my base and derived
class? That’s easily done using a using-declaration, which asks to bring the functions into the
scope:
1. class D : public B {
2. public:
3. using B::f; // make every f from B available
4. double f(double d) { cout << "f(double): "; return d+1.3; }
5. // ...
6. };
Given that modification, the output will be:
1. f(int): 3
2. f(double): 3.6
That is, overload resolution was applied to B’s f() and D’s f() to select the most
appropriate f() to call.
What does it mean that the “virtual table” is an unresolved
external?
If you get a link error of the form “Error: Unresolved or undefined symbols
detected: virtual table for class Fred,” you probably have an
undefined virtual member function in class Fred.
The compiler typically creates a magical data structure called the “virtual table” for classes that
have virtual functions (this is how it handles dynamic binding). Normally you don’t have to
know about it at all. But if you forget to define a virtual function for class Fred, you will
sometimes get this linker error.
Here’s the nitty gritty: Many compilers put this magical “virtual table” in the compilation unit that
defines the first non-inline virtual function in the class. Thus if the first non-
inline virtual function in Fred is wilma(), the compiler will put Fred’s virtual table in the
same compilation unit where it sees Fred::wilma(). Unfortunately if you accidentally forget to
define Fred::wilma(), rather than getting a Fred::wilma() is undefined, you may get a
“Fred’s virtual table is undefined”. Sad but true.

Inheritance
— private and protected inheritance
Save to:
InstapaperPocketReadability
Contents of this section:

 How do you express “private inheritance”?

 How are “private inheritance” and “composition” similar?
 Which should I prefer: composition or private inheritance?
 Should I pointer-cast from a private derived class to its base class?
 How is protected inheritance related to private inheritance?
 What are the access rules with private and protected inheritance?
How do you express “private inheritance”?
When you use : private instead of : public. E.g.,
1. class Foo : private Bar {
2. public:
3. // ...
4. };

How are “private inheritance” and “composition”

similar?
private inheritance is a syntactic variant of composition (AKA aggregation and/or has-a).
E.g., the “Car has-a Engine” relationship can be expressed using simple composition:
1. class Engine {
2. public:
3. Engine(int numCylinders);
4. void start(); // Starts this Engine
5. };
6.
7. class Car {
8. public:
9. Car() : e_(8) { } // Initializes this Car with 8 cylinders
10. void start() { e_.start(); } // Start this Car by starting its Engine
11. private:
12. Engine e_; // Car has-a Engine
13. };
The “Car has-a Engine” relationship can also be expressed using private inheritance:
1. class Car : private Engine { // Car has-a Engine
2. public:
3. Car() : Engine(8) { } // Initializes this Car with 8 cylinders
4. using Engine::start; // Start this Car by starting its Engine
5. };
There are several similarities between these two variants:
 In both cases there is exactly one Engine member object contained in every Car object
 In neither case can users (outsiders) convert a Car* to an Engine*
 In both cases the Car class has a start() method that calls the start() method on the
contained Engine object.
There are also several distinctions:
 The simple-composition variant is needed if you want to contain several Engines per Car
 The private-inheritance variant can introduce unnecessary multiple inheritance
 The private-inheritance variant allows members of Car to convert a Car* to an Engine*
 The private-inheritance variant allows access to the protected members of the base
class
 The private-inheritance variant allows Car to override Engine’s virtual functions
 The private-inheritance variant makes it slightly simpler (20 characters compared to 28
characters) to give Car a start() method that simply calls through to
the Engine’s start() method
Note that private inheritance is usually used to gain access into the protected members of the
base class, but this is usually a short-term solution (translation: a band-aid).
Which should I prefer: composition or private
inheritance?
Use composition when you can, private inheritance when you have to.
Normally you don’t want to have access to the internals of too many other classes,
and private inheritance gives you some of this extra power (and responsibility).
 But private inheritance isn’t evil; it’s just more expensive to maintain, since it increases the
probability that someone will change something that will break your code.
A legitimate, long-term use for private inheritance is when you want to build a class Fred that
uses code in a class Wilma, and the code from class Wilma needs to invoke member functions
from your new class, Fred. In this case, Fred calls non-virtuals in Wilma, and Wilma calls
(usually pure virtuals) in itself, which are overridden by Fred. This would be much harder to do
with composition.
1. class Wilma {
2. protected:
3. void fredCallsWilma()
4. {
5. std::cout << "Wilma::fredCallsWilma()\n";
6. wilmaCallsFred();
7. }
8. virtual void wilmaCallsFred() = 0; // A pure virtual function
9. };
10.
11. class Fred : private Wilma {
12. public:
13. void barney()
14. {
15. std::cout << "Fred::barney()\n";
16. Wilma::fredCallsWilma();
17. }
18. protected:
19. virtual void wilmaCallsFred()
20. {
21. std::cout << "Fred::wilmaCallsFred()\n";
22. }
23. };

Should I pointer-cast from a private derived class to its

base class?
Generally, No.
From a member function or friend of a privately derived class, the relationship to the base class is
known, and the upward conversion
from PrivatelyDer* to Base* (or PrivatelyDer& to Base&) is safe; no cast is needed or
recommended.
However users of PrivatelyDer should avoid this unsafe conversion, since it is based on
a private decision of PrivatelyDer, and is subject to change without notice.
How is protected inheritance related
to private inheritance?
Similarities: both allow overriding virtual functions in the private/protected base class,
neither claims the derived is a kind-of its base.
Dissimilarities: protected inheritance allows derived classes of derived classes to know about the
inheritance relationship. Thus your grand kids are effectively exposed to your implementation
details. This has both benefits (it allows derived classes of the protected derived class to exploit
the relationship to the protected base class) and costs (the protected derived class can’t change
the relationship without potentially breaking further derived classes).
Protected inheritance uses the : protected syntax:
1. class Car : protected Engine {
2. public:
3. // ...
4. };

What are the access rules

with private and protected inheritance?
Take these classes as examples:
1. class B { /*...*/ };
2. class D_priv : private B { /*...*/ };
3. class D_prot : protected B { /*...*/ };
4. class D_publ : public B { /*...*/ };
5. class UserClass { B b; /*...*/ };
None of the derived classes can access anything that is private in B. In D_priv,
the public and protected parts of B are private. In D_prot,
the public and protected parts of B are protected. In D_publ, the public parts
of B are public and the protected parts of B are protected (D_publ is-a-kind-of-
a B). class UserClass can access only the public parts of B, which “seals
off” UserClass from B.
To make a public member of B public in D_priv or D_prot, state the name of the member
with a B:: prefix. E.g., to make member B::f(int,float) public in D_prot, you would say:
1. class D_prot : protected B {
2. public:
3. using B::f; // Note: Not using B::f(int,float)
4. };

Inheritance — Multiple and Virtual

Inheritance
Save to:
InstapaperPocketReadability
Contents of this section:

 How is this section organized?

 Do we really need multiple inheritance?
 I’ve been told that I should never use multiple inheritance. Is that right?
 So there are times when multiple inheritance isn’t bad?!??
 What are some disciplines for using multiple inheritance?
 Can you provide an example that demonstrates the above guidelines?
 Is there a simple way to visualize all these tradeoffs?
 Can you give another example to illustrate the above disciplines?
 What is the “dreaded diamond”?
 Where in a hierarchy should I use virtual inheritance?
 What does it mean to “delegate to a sister class” via virtual inheritance?
 What special considerations do I need to know about when I use virtual inheritance?
 What special considerations do I need to know about when I inherit from a class that uses
virtual inheritance?
 What special considerations do I need to know about when I use a class that uses virtual
inheritance?
 One more time: what is the exact order of constructors in a multiple and/or virtual inheritance
situation?
 What is the exact order of destructors in a multiple and/or virtual inheritance situation?
How is this section organized?
This section covers a wide spectrum of questions/answers, ranging from the high-level / strategy /
design issues, going all the way down to low-level / tactical / programming issues. We cover them
in that order.
Please make sure you understand the high-level / strategy / design issues. Too many programmers
worry about getting “it” to compile without first deciding whether they really want “it” in the first
place. So please read the first several FAQs in this section before worrying about the (important)
mechanical details in the last several FAQs.
Do we really need multiple inheritance?
Not really. We can do without multiple inheritance by using workarounds, exactly as we can do
without single inheritance by using workarounds. We can even do without classes by using
workarounds. C is a proof of that contention. However, every modern language with static type
checking and inheritance provides some form of multiple inheritance. In C++, abstract classes often
serve as interfaces and a class can have many interfaces. Other languages – often deemed “not MI”
– simply have a separate name for their equivalent to a pure abstract class: an interface. The reason
languages provide inheritance (both single and multiple) is that language-supported inheritance is
typically superior to workarounds (e.g. use of forwarding functions to sub-objects or separately
allocated objects) for ease of programming, for detecting logical problems, for maintainability, and
often for performance.

I’ve been told that I should never use multiple inheritance.

Is that right?
Grrrrrrrrr.
It really bothers me when people think they know what’s best for your problem even though they’ve
never seen your problem!! How can anybody possibly know that multiple inheritance won’t
help you accomplish your goals without knowing your goals?!?!?!?!!!
Next time somebody tells you that you should never use multiple inheritance, look them straight in
the eye and say, “One size does not fit all.” If they respond with something about their bad
experience on their project, look them in the eye and repeat, slower this time, “One size does not fit
all.”
People who spout off one-size-fits-all rules presume to make your design decisions without
knowing your requirements. They don’t know where you’re going but know how you should get
there.
Don’t trust an answer from someone who doesn’t know the question.

So there are times when multiple inheritance isn’t

bad?!??
Of course there are!
You won’t use it all the time. You might not even use it regularly. But there are some situations
where a solution with multiple inheritance is cheaper to build, debug, test, optimize, and maintain
than a solution without multiple inheritance. If multiple inheritance cuts your costs, improves your
schedule, reduces your risk, and performs well, then please use it.
On the other hand, just because it’s there doesn’t mean you should use it. Like any tool, use the
right tool for the job. If MI (multiple inheritance) helps, use it; if not, don’t. And if you have a bad
 experience with it, don’t blame the tool. Take responsibility for your mistakes, and say, “I used the
wrong tool for the job; it was my fault.” Do not say, “Since it didn’t help my problem, it’s bad for
all problems in all industries across all time.” Good workmen never blame their tools.
What are some disciplines for using multiple
inheritance?
M.I. rule of thumb #1: Use inheritance only if doing so will remove if / switch statements from
the caller code. Rationale: this steers people away from “gratuitous” inheritance (either of the single
or multiple variety), which is often a good thing. There are a few times when you’ll use inheritance
without dynamic binding, but beware: if you do that a lot, you may have been infected with wrong
thinking. In particular, inheritance is not for code-reuse. You sometimes get a little code reuse via
inheritance, but the primary purpose for inheritance is dynamic binding, and that is for flexibility.
Composition is for code reuse, inheritance is for flexibility. This rule of thumb isn’t specific to MI,
but is generic to all usages of inheritance.
M.I. rule of thumb #2: Try especially hard to use ABCs when you use MI. In particular, most
classes above the join class (and often the join class itself) should be ABCs. In this context, “ABC”
doesn’t simply mean “a class with at least one pure virtual function”; it actually means a pure ABC,
meaning a class with as little data as possible (often none), and with most (often all) its methods
being pure virtual. Rationale: this discipline helps you avoid situations where you need to inherit
data or code along two paths, plus it encourages you to use inheritance properly. This second goal is
subtle but is extremely powerful. In particular, if you’re in the habit of using inheritance for code
reuse (dubious at best; see above), this rule of thumb will steer you away from MI and perhaps
(hopefully!) away from inheritance-for-code-reuse in the first place. In other words, this rule of
thumb tends to push people toward inheritance-for-interface-substitutability, which is always safe,
and away from inheritance-just-to-help-me-write-less-code-in-my-derived-class, which is often (not
always) unsafe.
M.I. rule of thumb #3: Consider the “bridge” pattern or nested generalization as possible
alternatives to multiple inheritance. This does not imply that there is something “wrong” with MI; it
simply implies that there are at least three alternatives, and a wise designer checks out all the
alternatives before choosing which is best.
Can you provide an example that demonstrates the above
guidelines?
Suppose you have land vehicles, water vehicles, air vehicles, and space vehicles. (Forget the whole
concept of amphibious vehicles for this example; pretend they don’t exist for this illustration.)
Suppose we also have different power sources: gas powered, wind powered, nuclear powered, pedal
powered, etc. We could use multiple inheritance to tie everything together, but before we do, we
should ask a few tough questions:
1. Will the users of LandVehicle need to have a Vehicle& that refers to
a LandVehicle object? In particular, will the users call methods on a Vehicle-reference and
expect the actual implementation of those methods to be specific to LandVehicles?
2. Ditto for GasPoweredVehicles: will the users want a Vehicle reference that refers to
a GasPoweredVehicle object, and in particular will they want to call methods on
that Vehicle reference and expect the implementations to get overridden
by GasPoweredVehicle?
If both answers are “yes,” multiple inheritance is probably the best way to go. But before you close
the door on the alternatives, here are a few more “decision criteria.” Suppose there are N
geographies (land, water, air, space, etc.) and M power sources (gas, nuclear, wind, pedal, etc.).
There are at least three choices for the overall design: the bridge pattern, nested generalization, and
multiple inheritance. Each has its pros/cons:
 With the bridge pattern, you create two distinct hierarchies: ABC Vehicle has derived
classes LandVehicle, WaterVehicle, etc., and ABC Engine has derived
classes GasPowered, NuclearPowered, etc. Then the Vehicle has an Engine* (that is,
an Engine-pointer), and users mix and match vehicles and engines at run-time. This has the
advantage that you only have to write N+M derived classes, which means things grow very
gracefully: when you add a new geography (incrementing N) or engine type (incrementing M),
you need add only one new derived class. However you have several disadvantages as well: you
only have N+M derived classes which means you only have at most N+M overrides and therefore
N+M concrete algorithms / data structures. If you ultimately want different algorithms and/or data
structures in the N×M combinations, you’ll have to work hard to make that happen, and you’re
probably better off with something other than a pure bridge pattern. The other thing the bridge
doesn’t solve for you is eliminating the nonsensical choices, such as pedal powered space
vehicles. You can solve that by adding extra checks when the users combine vehicles and engines
at run-time, but it requires a bit of skullduggery, something the bridge pattern doesn’t provide for
free. The bridge also restricts users since, although there is a common base class above all
geographies (meaning a user can pass any kind of vehicle as a Vehicle&), there is not a common
base class above, for example, all gas powered vehicles, and therefore users cannot pass any gas
powered vehicle as a GasPoweredVehicle&. Finally, the bridge has the advantage that it shares
code between the group of, for example, water vehicles as well as the group of, for example, gas
powered vehicles. In other words, the various gas powered vehicles share the code in derived
class GasPoweredEngine.
 With nested generalization, you pick one of the hierarchies as primary and the other as
secondary, and you have a nested hierarchy. For example, if you choose geography as
primary, Vehicle would have derived classes LandVehicle, WaterVehicle, etc., and those
would each have further derived classes, one per power source type. E.g., LandVehicle would
have derived
classes GasPoweredLandVehicle, PedalPoweredLandVehicle, NuclearPoweredLandVe
hicle, etc.; WaterVehicle would have a similar set of derived classes, etc. This requires you to
write roughly N×M different derived classes, which means things don’t grow gracefully when
you increment N or M, but it gives you the advantage over the bridge that you can have N×M
different algorithms and data structures. It also gives you fine granular control, since the user
cannot select nonsensical combinations, such as pedal powered space vehicles, since the user can
select only those combinations that a programmer has decided are reasonable. Unfortunately
nested generalization doesn’t improve the problem with passing any gas powered vehicle as a
common base class, since there is no common base class above the secondary hierarchy, e.g.,
there is no GasPoweredVehicle base class. And finally, it’s not obvious how to share code
between all vehicles that use the same power source, e.g., between all gas powered vehicles.
 With multiple inheritance, you have two distinct hierarchies, just like the bridge, but you
remove the Engine* from the bridge and instead create roughly N×M derived classes below both
the hierarchy of geographies and the hierarchy of power sources. It’s not as simple as this, since
you’ll need to change the concept of the Engine classes. In particular, you’ll want to rename the
classes in that hierarchy from, for example, GasPoweredEngine to GasPoweredVehicle; plus
you’ll need to make corresponding changes to the methods in the hierarchy. In any case,
class GasPoweredLandVehicle will multiply inherit
from GasPoweredVehicle and LandVehicle, and similarly
with GasPoweredWaterVehicle, NuclearPoweredWaterVehicle, etc. Like nested
generalization, you have to write roughly N×M classes, which doesn’t grow gracefully, but it does
give you fine granular control over both which algorithm and data structures to use in the various
derived classes as well as which combinations are deemed “reasonable,” meaning you simply
don’t create nonsensical choices like PedalPoweredSpaceVehicle. It solves a problem shared
 by both bridge and nested generalization, namely it allows a user to pass any gas powered vehicle
using a common base class. Finally it provides a solution to the code-sharing problem, a solution
that is at least as good as that of the bridge solution: it lets all gas powered vehicles share common
code when that is desired. We say this is “at least as good as the solution from the bridge” since,
unlike the bridge, the derived classes can share common code within gas powered vehicles, but
can also, unlike with the bridge, override and replace that code in cases where the shared code is
not ideal.
The most important point: there is no universally “best” answer. Perhaps you were hoping I
would tell you to always use one or the other of the above choices. I’d be happy to do that except
for one minor detail: it would be a lie. If exactly one of the above was always best, then one size
would fit all, and we know it does not.
So here’s what you have to do: T H I N K. You’ll have to make a decision. I’ll give you some
guidelines, but ultimately you will have to decide what is best (or perhaps “least bad”)
for your situation.
Is there a simple way to visualize all these tradeoffs?
Here are some of the “goodness criteria,” that is, qualities you might want. In this description, N is
the number of geographies and M is the number of power sources:
 Grow Gracefully: Does the size of the code-base grow gracefully when you add a new
geography or power source? If you add a new geography (going from N to N+1), do you need to
add one new chunk of code (best), M new chunks of code (worst), or something in between?
 Low Code Bulk: Is there a reasonably small amount of code bulk? This usually is
proportional to ongoing maintenance cost — the more code the more cost, all other things being
equal. It is also usually related to the “Grow Gracefully” criteria: in addition to the code bulk of
the framework proper, best case there would be N+M chunks of code, worst case there would
be N×M chunks of code.
 Fine Grained Control: Do you have fine granular control over the algorithms and data
structures? For example, do you have the option of having a different algorithm and/or data
structure for any of the N×M possibilities, or are you stuck with using the same algorithm and/or
data structure for all, say, gas powered vehicles?
 Static Detect Bad Combos: Can you statically (“at compile time”) detect and prevent
invalid combinations. For example, suppose for the moment that there are no pedal-powered
space vehicles. If someone tries to create a pedal-powered space vehicle, can that be detected at
compile time (good), or do we need to detect it at run-time?
 Polymorphic on Both Sides: Does it let users treat either base class polymorphically? In
other words, can you create some user code f() that takes any and all, say, land vehicles (where
you can add a new kind of land vehicle without requiring any changes to f()), and also create
some other user code g() that takes any and all, say, gas powered vehicles (where you can add a
new kind of gas powered vehicle without requiring any changes to g())?
 Share Common Code: Does it let new combinations share common code from either side?
For example, when you create a new kind of gas powered land vehicle, can that new class choose
to optionally share code that is common to many gas-powered vehicles and choose to optionally
share code is common to many land vehicles?
This matrix shows techologies as rows and “goodness criteria” as columns. means the row’s
technology has the column’s goodness criteria, “—” means it does not.

Grow Low Fine Static Polymorphic Share

Gracefully? Code Grained Detect Bad on Both Common
Bulk? Control? Combos? Sides? Code?
Bridge — — —
(N+M
 Grow Low Fine Static Polymorphic Share
Gracefully? Code Grained Detect Bad on Both Common
Bulk? Control? Combos? Sides? Code?
chunks)
Nested — — — —
generalization (N×M
chunks)
Multiple — —
inheritance (N×M
chunks)
Important: do not be naive. Do not simply add up the number of s, choosing based on most good
or least bad. THINK!!
1. The first step is to think about whether your particular situation has other design options, that
is, additional rows.
 Recall that the “bridge” row is really a pair of rows — it has an assymetry that could
go in either direction. In other words, one could put an Engine* in Vehicle or
a Vehicle* in Engine (or both, or some other way to pair them up, such as a small object that
contains just a Vehicle* and an Engine*).
 Similar comments for the nested generalization row: it is actually a pair of rows
because it also has an assymetry, and that assymetry gives you an extra option: you could first
decompose by geography (land, water, etc.) or first by power source (gas, nuclear, etc.). These
two orders yield two distinct designs with distinct tradeoffs.
2. The second step in using the above matrix is to think about which column is most
important for your particular situation. This will let you give a “weight” or “importance” to each
column.
 For example, in your particular situation, the amount of code that must get written
(second column) may be more or less important than the fine grained control over
algorithms/data structures. Do not get caught up trying to figure out which column is more
important in some abstract, generic, one-size-fits-all view of the world, because one size does
not fit all!!
 Question: is code bulk (and therefore maintenance cost) more or less important than
fine grained control? Answer: Yes, code bulk (and therefore maintenance cost) is either more or
less important than fine grained control. That’s a joke; lighten up.
 But this part isn’t a joke: don’t trust anyone who thinks they know whether code bulk
(and therefore maintenance cost) is always more or always less important than fine grained
control. There’s no way to know until you look at all the requirements and constraints on your
particular situation! Far too many programmers think they know the answer before they are
familiar with the situation. That’s worse than dumb; it is unprofessional and dangerous. Their
one-size-fits-all answer will sometimes be right. Their one-size-fits-all answer might have been
right in every case they have ever seen in their limited range of experience. But if their past
success blinds them from asking the tough questions in the future, they are a danger to your
project and should get a thonk on the noggin (“thonk” and “noggin” are highly technical terms).
Your ultimate choice will be made by finding out which approach is best for your situation. One
size does not fit all — do not expect the answer in one project to be the same as the answer in
another project. Your past successes can become, if you are not careful, the seeds of your future
failure. Just because “it” was best on your previous project does not mean “it” will be best on your
next project.
 Can you give another example to illustrate the above
disciplines?
This second example is only slightly different from the previous since it is more obviously
symmetric. This symmetry tilts the scales slightly toward the multiple inheritance solution, but one
of the others still might be best in some situations.
In this example, we have only two categories of vehicles: land vehicles and water vehicles. Then
somebody points out that we need amphibious vehicles. Now we get to the good part: the questions.
1. Do we even need a distinct AmphibiousVehicle class? Is it also viable to use one of the
other classes with a “bit” indicating the vehicle can be both in water and on land? Just because
“the real world” has amphibious vehicles doesn’t mean we need to mimic that in software.
2. Will the users of LandVehicle need to use a LandVehicle& that refers to
an AmphibiousVehicle object? Will they need to call methods on the LandVehicle& and
expect the actual implementation of those methods to be specific to (“overridden
in”) AmphibiousVehicle?
3. Ditto for water vehicles: will the users want a WaterVehicle& that might refer to
an AmphibiousVehicle object, and in particular to call methods on that reference and expect
the implementation will get overridden by AmphibiousVehicle?
If we get three “yes” answers, multiple inheritance is probably the right choice. To be sure, you
should ask the other questions as well, e.g., the grow-gracefully issue, the granularity of control
issues, etc.

What is the “dreaded diamond”?

The “dreaded diamond” refers to a class structure in which a particular class appears more than once
in a class’s inheritance hierarchy. For example,
1. class Base {
2. public:
3. // ...
4. protected:
5. int data_;
6. };
7.
8. class Der1 : public Base { /*...*/ };
9.
10. class Der2 : public Base { /*...*/ };
11.
12. class Join : public Der1, public Der2 {
13. public:
14. void method()
15. {
16. data_ = 1; // Bad: this is ambiguous; see below
17. }
18. };
19.
20. int main()
21. {
22. Join* j = new Join();
23. Base* b = j; // Bad: this is ambiguous; see below
24. }
Forgive the ASCII-art, but the inheritance hierarchy looks something like this:
1. Base
2. / \
3. / \
4. / \
5. Der1 Der2
6. \ /
7. \ /
8. \ /
9. Join
Before we explain why the dreaded diamond is dreaded, it is important to note that C++ provides
techniques to deal with each of the “dreads.” In other words, this structure is often called the
dreaded diamond, but it really isn’t dreaded; it’s more just something to be aware of.
The key is to realize that Base is inherited twice, which means any data members declared in Base,
such as data_ above, will appear twice within a Join object. This can create ambiguities:
which data_ did you want to change? For the same reason the conversion from Join* to Base*,
or from Join& to Base&, is ambiguous: which Base class subobject did you want?
C++ lets you resolve the ambiguities. For example, instead of saying data_ = 1 you could
say Der2::data_ = 1, or you could convert from Join* to a Der1* and then to a Base*.
However please, Please, PLEASE think before you do that. That is almost always not the best
solution. The best solution is typically to tell the C++ compiler that only one Base subobject should
appear within a Join object, and that is described next.
Where in a hierarchy should I use virtual inheritance?
Just below the top of the diamond, not at the join-class.
To avoid the duplicated base class subobject that occurs with the “dreaded diamond”, you should
use the virtual keyword in the inheritance part of the classes that derive directly from the top of
the diamond:
1. class Base {
2. public:
3. // ...
4. protected:
5. int data_;
6. };
7.
8. class Der1 : public virtual Base {
9. ↑↑↑↑↑↑↑ // This is the key
10. public:
11. // ...
12. };
13.
14. class Der2 : public virtual Base {
15. ↑↑↑↑↑↑↑ // This is the key
16. public:
17. // ...
18. };
19.
20. class Join : public Der1, public Der2 {
21. public:
22. void method()
23. {
24. data_ = 1; // Good: this is now unambiguous
25. }
26. };
27.
28. int main()
29. {
30. Join* j = new Join();
31. Base* b = j; // Good: this is now unambiguous
32. }
Because of the virtual keyword in the base-class portion of Der1 and Der2, an instance
of Join will have only a single Base subobject. This eliminates the ambiguities. This is usually
better than using full qualification as described in the previous FAQ.
For emphasis, the virtual keyword goes in the hierarchy above Der1 and Der2. It doesn’t help to
put the virtual keyword in the Join class itself. In other words, you have to know that a join
class will exist when you are creating class Der1 and Der2.
1. Base
2. / \
3. / \
4. virtual / \ virtual
5. Der1 Der2
6. \ /
7. \ /
8. \ /
9. Join

What does it mean to “delegate to a sister class” via

virtual inheritance?
Consider the following example:
1. class Base {
2. public:
3. virtual void foo() = 0;
4. virtual void bar() = 0;
5. };
6.
7. class Der1 : public virtual Base {
8. public:
9. virtual void foo();
10. };
11.
12. void Der1::foo()
13. { bar(); }
14.
15. class Der2 : public virtual Base {
16. public:
17. virtual void bar();
18. };
19.
20. class Join : public Der1, public Der2 {
21. public:
22. // ...
23. };
24.
25. int main()
26. {
27. Join* p1 = new Join();
28. Der1* p2 = p1;
29. Base* p3 = p1;
30.
31. p1->foo();
32. p2->foo();
33. p3->foo();
34. }
Believe it or not, when Der1::foo() calls this->bar(), it ends up calling Der2::bar(). Yes,
that’s right: a class that Der1 knows nothing about will supply the override of a virtual function
invoked by Der1::foo(). This “cross delegation” can be a powerful technique for customizing the
behavior of polymorphic classes.
What special considerations do I need to know about
when I use virtual inheritance?
Generally, virtual base classes are most suitable when the classes that derive from the virtual base,
and especially the virtual base itself, are pure abstract classes. This means the classes above the
“join class” have very little if any data.
Note: even if the virtual base itself is a pure abstract class with no member data, you still probably
don’t want to remove the virtual inheritance within classes Der1 and Der2. You can use fully
qualified names to resolve any ambiguities that arise, and you might even be able to squeeze out a
few cycles in some cases, however the object’s address is somewhat ambiguous (there are still
two Base class subobjects in the Join object), so simple things like trying to find out if two
pointers point at the same instance might be tricky. Just be careful — very careful.
What special considerations do I need to know about
when I inherit from a class that uses virtual
inheritance?
Initialization list of most-derived-class’s ctor directly invokes the virtual base class’s ctor.
Because a virtual base class subobject occurs only once in an instance, there are special rules to
make sure the virtual base class’s constructor and destructor get called exactly once per instance.
The C++ rules say that virtual base classes are constructed before all non-virtual base classes. The
thing you as a programmer need to know is this: constructors for virtual base classes anywhere in
your class’s inheritance hierarchy are called by the “most derived” class’s constructor.
Practically speaking, this means that when you create a concrete class that has a virtual base class,
you must be prepared to pass whatever parameters are required to call the virtual base class’s
constructor. And, of course, if there are several virtual base classes anywhere in your classes
ancestry, you must be prepared to call all their constructors. This might mean that the most-derived
class’s constructor needs more parameters than you might otherwise think.
However, if the author of the virtual base class followed the guideline in the previous FAQ, then the
virtual base class’s constructor probably takes no parameters since it doesn’t have any data to
initialize. This means (fortunately!) the authors of the concrete classes that inherit eventually from
the virtual base class do not need to worry about taking extra parameters to pass to the virtual base
class’s ctor.
What special considerations do I need to know about
when I use a class that uses virtual inheritance?
No C-style downcasts; use dynamic_cast instead.
(Rest to be written.)

One more time: what is the exact order of constructors in

a multiple and/or virtual inheritance situation?
 The very first constructors to be executed are the virtual base classes anywhere in the hierarchy.
They are executed in the order they appear in a depth-first left-to-right traversal of the graph of base
classes, where left to right refer to the order of appearance of base class names.
After all virtual base class constructors are finished, the construction order is generally from base
class to derived class. The details are easiest to understand if you imagine that the very first thing
the compiler does in the derived class’s ctor is to make a hidden call to the ctors of its non-virtual
base classes (hint: that’s the way many compilers actually do it). So if class D inherits multiply from
B1 and B2, the constructor for B1 executes first, then the constructor for B2, then the constructor
for D. This rule is applied recursively; for example, if B1 inherits from B1a and B1b, and B2
inherits from B2a and B2b, then the final order is B1a, B1b, B1, B2a, B2b, B2, D.
Note that the order B1 and then B2 (or B1a then B1b) is determined by the order that the base
classes appear in the declaration of the class, not in the order that the initializer appears in the
derived class’s initialization list.
What is the exact order of destructors in a multiple and/or
virtual inheritance situation?
Short answer: the exact opposite of the constructor order.
Long answer: suppose the “most derived” class is D, meaning the actual object that was originally
created was of class D, and that D inherits multiply (and non-virtually) from B1 and B2. The sub-
object corresponding to most-derived class D runs first, followed by the dtors for its non-virtual
base classes in reverse declaration-order. Thus the destructor order will be D, B2, B1. This rule is
applied recursively; for example, if B1 inherits from B1a and B1b, and B2 inherits from B2a and
B2b, the final order is D, B2, B2b, B2a, B1, B1b, B1a.
After all this is finished, virtual base classes that appear anywhere in the hierarchy are handled. The
destructors for these virtual base classes are executed in the reverse order they appear in a depth-
first left-to-right traversal of the graph of base classes, where left to right refer to the order of
appearance of base class names. For instance, if the virtual base classes in that traversal order are
V1, V1, V1, V2, V1, V2, V2, V1, V3, V1, V2, the unique ones are V1, V2, V3, and the final-final
order is D, B2, B2b, B2a, B1, B1b, B1a, V3, V2, V1.
Reminder to make your base class’s destructor virtual, at least in the normal case. If you
don’t thoroughly understand the rules for why you make your base class’s destructor virtual, then
either learn the rationale or just trust me and make them virtual.

Templates
Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the idea behind templates?

 What’s the syntax / semantics for a “class template”?
 What’s the syntax / semantics for a “function template”?
 How do I explicitly select which version of a function template should get called?
 What is a “parameterized type”?
 What is “genericity”?
  My template function does something special when the template
type T is int or std::string; how do I write my template so it uses the special code when T is
one of those specific types?
 Huh? Can you provide an example of template specialization that doesn’t use foo and bar?
 But most of the code in my template function is the same; is there some way to get the
benefits of template specialization without duplicating all that source code?
 All those templates and template specializations must slow down my program, right?
 So templates are overloading, right?
 Why can’t I separate the definition of my templates class from its declaration and put it
inside a .cpp file?
 How can I avoid linker errors with my template functions?
 How does the C++ keyword export help with template linker errors?
 How can I avoid linker errors with my template classes?
 Why do I get linker errors when I use template friends?
 Why can’t I define constraints for my template parameters?
 How can any human hope to understand these overly verbose template-based error
messages?
 Why am I getting errors when my template uses a nested type?
 Why am I getting errors when my template-derived-class uses a nested type it inherits from
its template-base-class?
 Why am I getting errors when my template-derived-class uses a member it inherits from its
template-base-class?
 Can the previous problem hurt me silently? Is it possible that the compiler will silently
generate the wrong code?
 How can I create a container-template that allows my users to supply the type of the
underlying container that actually stores the values?
 Follow-up to previous: can I pass in the underlying structure and the element-type
separately?
 Related: all those proxies must negatively reflect on the speed of my program. Don’t they?
What’s the idea behind templates?
A template is a cookie-cutter that specifies how to cut cookies that all look pretty much the same
(although the cookies can be made of various kinds of dough, they’ll all have the same basic shape).
In the same way, a class template is a cookie cutter for a description of how to build a family of
classes that all look basically the same, and a function template describes how to build a family of
similar looking functions.
Class templates are often used to build type safe containers (although this only scratches the surface
for how they can be used).

What’s the syntax / semantics for a “class template”?

Consider a container class Array that acts like an array of integers:
1. // This would go into a header file such as "Array.h"
2. class Array {
3. public:
4. Array(int len=10) : len_(len), data_(new int[len]) { }
5. ~Array() { delete[] data_; }
6. int len() const { return len_; }
7. const int& operator[](int i) const { return data_[check(i)]; } // Subscript operators often come in pairs
8. int& operator[](int i) { return data_[check(i)]; } // Subscript operators often come in pairs
9. Array(const Array&);
10. Array& operator= (const Array&);
11. private:
12. int len_;
13. int* data_;
14. int check(int i) const
15. {
16. if (i < 0 || i >= len_)
17. throw BoundsViol("Array", i, len_);
18. return i;
19. }
20. };
Repeating the above over and over for Array of float, of char, of std::string, of Array-of-
std::string, etc, would become tedious. Instead, you add the template<typename T> before
the class definition (the T can be any identifier you want, T is just the most commonly used one,
especially in examples). Then, instead of using int or float or char where referring to the data
type, you use T instead. Also, instead of just referring to the class as Array, it’s Array<T> when
referring to the template, or Array<int>, Array<float>, etc. when referring to a specific
instantiation.
1. // This would go into a header file such as "Array.h"
2. template<typename T>
3. class Array {
4. public:
5. Array(int len=10) : len_(len), data_(new T[len]) { }
6. ~Array() { delete[] data_; }
7. int len() const { return len_; }
8. const T& operator[](int i) const { return data_[check(i)]; }
9. T& operator[](int i) { return data_[check(i)]; }
10. Array(const Array<T>&);
11. Array(Array<T>&&);
12. Array<T>& operator= (const Array<T>&);
13. Array<T>& operator= (Array<T>&&);
14. private:
15. int len_;
16. T* data_;
17. int check(int i) const {
18. assert(i >= 0 && i < len_);
19. return i;
20. }
21. };
Just as with a normal class, you can optionally define your methods outside the class:
1. template<typename T>
2. class Array {
3. public:
4. int len() const;
5. // ...
6. };
7.
8. template<typename T>
9. inline // See below if you want to make this non-inline
10. int Array<T>::len() const
11. {
12. // ...
13. }
Unlike template functions, template classes (instantiations of class templates) need to be explicit
about the parameters over which they are instantiating:
1. int main()
2. {
3. Array<int> ai;
4. Array<float> af;
5. Array<char*> ac;
6. Array<std::string> as;
7. Array<Array<int>> aai;
8. // ...
9. }
Note that prior to C++11, a space was required between the two >’s in the last example. Without
this space, the C++98/C++03 compiler would see a >> (right-shift) token instead of two >’s. Aren’t
you lucky that it is no longer the case in C++11?
What’s the syntax / semantics for a “function
template”?
Consider this function that swaps its two integer arguments:
1. void swap(int& x, int& y)
2. {
3. int tmp = x;
4. x = y;
5. y = tmp;
6. }
If we also had to swap floats, longs, Strings, Sets, and FileSystems, we’d get pretty tired of coding
lines that look almost identical except for the type. Mindless repetition is an ideal job for a
computer, hence a function template:
1. template<typename T>
2. void swap(T& x, T& y)
3. {
4. T tmp = x;
5. x = y;
6. y = tmp;
7. }
Every time we used swap() with a given pair of types, the compiler will go to the above definition
and will create yet another “template function” as an instantiation of the above. Unlike template
classes, template functions usually do not need to be explicit about the parameters over which they
are instantiating. The compiler can usually determine them automatically. E.g.,
1. int main()
2. {
3. int i,j; /*...*/ swap(i,j); // Instantiates a swap for int
4. float a,b; /*...*/ swap(a,b); // Instantiates a swap for float
5. char c,d; /*...*/ swap(c,d); // Instantiates a swap for char
6. std::string s,t; /*...*/ swap(s,t); // Instantiates a swap for std::string
7. // ...
8. }
Note: A “template function” is the instantiation of a “function template”.
Sometimes, you do want to be explicit about the types used.
How do I explicitly select which version of a function
template should get called?
When you call a function template, the compiler tries to deduce the template type. Most of the time
it can do that successfully, but every once in a while you may want to help the compiler deduce the
 right type — either because it cannot deduce the type at all, or perhaps because it would deduce the
wrong type.
For example, you might be calling a function template that doesn’t have any parameters of its
template argument types, or you might want to force the compiler to do certain promotions on the
arguments before selecting the correct function template. In these cases you’ll need to explicitly tell
the compiler which instantiation of the function template should be called.
Here is a sample function template where the template parameter T does not appear in the function’s
parameter list. In this case the compiler cannot deduce the template parameter types when the
function is called.
1. template<typename T>
2. void f()
3. {
4. // ...
5. }
To call this function with T being an int or a std::string, you could say:
1. #include <string>
2.
3. void sample()
4. {
5. f<int>(); // type T will be int in this call
6. f<std::string>(); // type T will be std::string in this call
7. }
Here is another function whose template parameters appear in the function’s list of formal
parameters (that is, the compiler can deduce the template type from the actual arguments):
1. template<typename T>
2. void g(T x)
3. {
4. // ...
5. }
Now if you want to force the actual arguments to be promoted before the compiler deduces the
template type, you can use the above technique. E.g., if you simply called g(42) you would
get g<int>(42), but if you wanted to pass 42 to g<long>(), you could say this: g<long>(42).
(Of course you could also promote the parameter explicitly, such as either g(long(42)) or
even g(42L), but that ruins the example.)
Similarly if you said g("xyz") you’d end up calling g<char*>(char*), but if you wanted to call
the std::string version of g<>() you could say g<std::string>("xyz"). (Again you could
also promote the argument, such as g(std::string("xyz")), but that’s another story.)
Another time when you must specify the types is when the function takes two parameters of the
same type, but you give it two different types.
1. template<typename T>
2. void g(T x, T y);
3.
4. int m = 0;
5. long n = 1;
6. g(m, n);
Since m and n have different types, the compiler can’t deduce what type to use for T, so you have to
tell it what to use:
1. template<typename T>
2. void g(T x, T y);
3.
4. int m = 0;
5. long n = 1;
6. g<int>(m, n);
 What is a “parameterized type”?
Another way to say, “class templates.”
A parameterized type is a type that is parameterized over another type or some value. List<int> is
a type (List) parameterized over another type (int).
What is “genericity”?
Yet another way to say, “class templates.”
Not to be confused with “generality” (which just means avoiding solutions which are overly
specific), “genericity” means class templates.

My template function does something special when the

template type T is int or std::string; how do I write my
template so it uses the special code when T is one of
those specific types?
Before showing how to do this, let’s make sure you’re not shooting yourself in the foot. Does the
function’s behavior appear different to your users? In other words, is the observable
behavior different in some substantive way? If so, you’re probably shooting yourself in the foot and
you will probably confuse your users — you’re probably better off using different functions with
different names — don’t use templates, don’t use overloading. For example, if the code
for int inserts something into a container and sorts the result, but the code
for std::string removes something from a container and does not sort the result, those two
functions ought not to be an overloaded pair — their observable behavior is different so they ought
to have different names.
However if the function’s observable behavior is consistent for all the T types with the differences
limited to implementation details, then you can proceed. Let’s proceed with an example of this
(conceptual only; not C++):
1. template<typename T>
2. void foo(const T& x)
3. {
4. switch (typeof(T)) { // Conceptual only; not C++
5. case int:
6. // ...implementation details when T is int
7. break;
8.
9. case std::string:
10. // ...implementation details when T is std::string
11. break;
12.
13. default:
14. // ...implementation details when T is neither int nor std::string
15. break;
16. }
17. }
One way to implement the above is via template specialization. Instead of a switch-statement, you
end up breaking up the code into separate functions. The first function is the default case — the
code to be used when T is anything other than int or std::string:
1. template<typename T>
2. void foo(const T& x)
3. {
4. // ...implementation details when T is neither int nor std::string
5. }
Next are the two specializations, first for the int case…
1. template<>
2. void foo<int>(const int& x)
3. {
4. // ...implementation details when T is int
5. }
…and next for the std::string case…
1. template<>
2. void foo<std::string>(const std::string& x)
3. {
4. // ...implementation details when T is std::string
5. }
That’s it; you’re done. The compiler will automagically select the correct specialization when it sees
which T you are using.
Huh? Can you provide an example of template
specialization that doesn’t use foo and bar?
Yes.
One of several ways I personally use template specialization is for stringification. I usually use a
template to stringify various objects of various types, but I often need to specialize the code for
stringifying certain specific types. For instance, when stringifying bools I
prefer "true" and "false" over "1" and "0" so I use std::boolalpha when T is bool. Also I
often prefer floating point output to contain all the digits (so I can see very small differences, etc.)
so I use std::setprecision when T is a floating point type. The end result usually looks
something like this:
1. #include <iostream>
2. #include <sstream>
3. #include <iomanip>
4. #include <string>
5. #include <limits>
6.
7. template<typename T> inline std::string stringify(const T& x)
8. {
9. std::ostringstream out;
10. out << x;
11. return out.str();
12. }
13.
14. template<> inline std::string stringify<bool>(const bool& x)
15. {
16. std::ostringstream out;
17. out << std::boolalpha << x;
18. return out.str();
19. }
20.
21. template<> inline std::string stringify<double>(const double& x)
22. {
23. const int sigdigits = std::numeric_limits<double>::digits10;
24. // or perhaps std::numeric_limits<double>::max_digits10 if that is available on your compiler
25. std::ostringstream out;
26. out << std::setprecision(sigdigits) << x;
27. return out.str();
28. }
29.
30. template<> inline std::string stringify<float>(const float& x)
31. {
32. const int sigdigits = std::numeric_limits<float>::digits10;
33. // or perhaps std::numeric_limits<float>::max_digits10 if that is available on your compiler
34. std::ostringstream out;
35. out << std::setprecision(sigdigits) << x;
36. return out.str();
37. }
38.
39. template<> inline std::string stringify<long double>(const long double& x)
40. {
41. const int sigdigits = std::numeric_limits<long double>::digits10;
42. // or perhaps std::numeric_limits<long_double>::max_digits10 if that is available on your compiler
43. std::ostringstream out;
44. out << std::setprecision(sigdigits) << x;
45. return out.str();
46. }
Conceptually they all do the same thing: stringify the parameter. That means the observable
behavior is consistent, therefore the specializations do not confuse callers. However the details for
implementing that observable behavior is slightly different for bool and floating point types, so
template specialization is a good approach.
But most of the code in my template function is the same;
is there some way to get the benefits of template
specialization without duplicating all that source code?
Yes.
For example, suppose your template function has a bunch of common code along with a relatively
small amount of T-specific code (conceptual only; not C++):
1. template<typename T>
2. void foo(const T& x)
3. {
4. // ... common code that works for all T types ...
5.
6. switch (typeof(T)) { // Conceptual only; not C++
7. case int:
8. // ... small amount of code used only when T is int ...
9. break;
10.
11. case std::string:
12. // ... small amount of code used only when T is std::string ...
13. break;
14.
15. default:
16. // ... small amount of code used when T is neither int nor std::string ...
17. break;
18. }
19.
20. // ... more common code that works for all T types ...
21. }
If you blindly applied the advice from the FAQ on template specialization, you would end up
duplicating all that code before and after the pseudo-switch statement. The way to get the best of
both worlds — to get the benefits of T-specific pieces without duplicating the entire function, is to
 extract the pseudo-switch statement portion into a separate function foo_part(), and use template
specialization on that separate function:
1. template<typename T> inline void foo_part(const T& x)
2. {
3. // ... small amount of code used when T is neither int nor std::string ...
4. }
5.
6. template<> inline void foo_part<int>(const int& x)
7. {
8. // ... small amount of code used only when T is int ...
9. }
10.
11. template<> inline void foo_part<std::string>(const std::string& x)
12. {
13. // ... small amount of code used only when T is std::string ...
14. }
The main foo() function would be a simple template — no specializations. Note that the pseudo-
switch statement has been replaced by a call to foo_part():
1. template<typename T>
2. void foo(const T& x)
3. {
4. // ... common code that works for all T types ...
5.
6. foo_part(x);
7.
8. // ... more common code that works for all T types ...
9. }
As you can see, the body of foo() now doesn’t mention any particular T. It all gets figured out
automatically. The compiler generates foo for you based on type T, and will generate the correctly
typed foo_part function based on the actual compile-time known type of the x argument. Proper
specializations of foo_part will be instantiated.
All those templates and template specializations must
slow down my program, right?
Wrong.
This is a quality-of-implementation issue so your results may vary. However there is usually no
slow-down at all. If anything, the templates might affect the speed of compilation slightly, but once
the types are resolved by the compiler at compile-time, it will typically generate code that is just as
fast as with non-template functions, including inline-expanding appropriate functions, etc.

So templates are overloading, right?

Yes and no.
Function templates participate in name resolution for overloaded functions, but the rules are
different. For a template to be considered in overload resolution, the type has to match exactly. If
the types do not match exactly, the conversions are not considered and the template is simply
dropped from the set of viable functions. That’s what is known as “SFINAE” — Substitution
Failure Is Not An Error. Example:
1. #include <iostream>
2. #include <typeinfo>
3.
4. template<typename T> void foo(T* x)
5. { std::cout << "foo<" << typeid(T).name() << ">(T*)\n"; }
6.
7. void foo(int x)
8. { std::cout << "foo(int)\n"; }
9.
10. void foo(double x)
11. { std::cout << "foo(double)\n"; }
12.
13. int main()
14. {
15. foo(42); // matches foo(int) exactly
16. foo(42.0); // matches foo(double) exactly
17. foo("abcdef"); // matches foo<T>(T*) with T = char
18. return 0;
19. }
In this example, foo<T> cannot be considered for the first or the second call to foo in the body
of main because neither 42 nor 42.0 gives the compiler any information to deduce T. The third call,
however, includes foo<T> with T = char and it wins.
Why can’t I separate the definition of my templates class
from its declaration and put it inside a .cpp file?
If all you want to know is how to fix this situation, read the next two FAQs. But in order to
understand why things are the way they are, first accept these facts:
1. A template is not a class or a function. A template is a “pattern” that the compiler uses to
generate a family of classes or functions.
2. In order for the compiler to generate the code, it must see both the template definition (not
just declaration) and the specific types/whatever used to “fill in” the template. For example, if
you’re trying to use a Foo<int>, the compiler must see both the Foo template and the fact that
you’re trying to make a specific Foo<int>.
3. Your compiler probably doesn’t remember the details of one .cpp file while it is compiling
another .cpp file. It could, but most do not and if you are reading this FAQ, it almost definitely
does not. BTW this is called the “separate compilation model.”
Now based on those facts, here’s an example that shows why things are the way they are. Suppose
you have a template Foo defined like this:
1. template<typename T>
2. class Foo {
3. public:
4. Foo();
5. void someMethod(T x);
6. private:
7. T x;
8. };
Along with similar definitions for the member functions:
1. template<typename T>
2. Foo<T>::Foo()
3. {
4. // ...
5. }
6.
7. template<typename T>
8. void Foo<T>::someMethod(T x)
9. {
10. // ...
11. }
 Now suppose you have some code in file Bar.cpp that uses Foo<int>:
1. // Bar.cpp
2.
3. void blah_blah_blah()
4. {
5. // ...
6. Foo<int> f;
7. f.someMethod(5);
8. // ...
9. }
Clearly somebody somewhere is going to have to use the “pattern” for the constructor definition and
for the someMethod() definition and instantiate those when T is actually int. But if you had put
the definition of the constructor and someMethod() into file Foo.cpp, the compiler would see the
template code when it compiled Foo.cpp and it would see Foo<int> when it compiled Bar.cpp,
but there would never be a time when it saw both the template code and Foo<int>. So by rule #2
above, it could never generate the code for Foo<int>::someMethod().
A note to the experts: I have obviously made several simplifications above. This was intentional so
please don’t complain too loudly. If you know the difference between a .cpp file and a compilation
unit, the difference between a class template and a template class, and the fact that templates really
aren’t just glorified macros, then don’t complain: this particular question/answer wasn’t aimed at
you to begin with. I simplified things so newbies would “get it,” even if doing so offends some
experts.
Reminder: Read the next two FAQs for some solutions to this problem.
How can I avoid linker errors with my template
functions?
This answer will be updated due to C++11 extern template. Watch this space for updates in the
near future!!
Tell your C++ compiler which instantiations to make while it is compiling your template
function’s .cpp file.
As an example, consider the header file foo.h which contains the following template function
declaration:
1. // File "foo.h"
2. template<typename T>
3. extern void foo();
Now suppose file foo.cpp actually defines that template function:
1. // File "foo.cpp"
2. #include <iostream>
3. #include "foo.h"
4.
5. template<typename T>
6. void foo()
7. {
8. std::cout << "Here I am!\n";
9. }
Suppose file main.cpp uses this template function by calling foo<int>():
1. // File "main.cpp"
2. #include "foo.h"
3.
4. int main()
5. {
6. foo<int>();
7. // ...
8. }
If you compile and (try to) link these two .cpp files, most compilers will generate linker errors.
There are two solutions for this. The first solution is to physically move the definition of the
template function into the .h file, even if it is not an inline function. This solution may (or may
not!) cause significant code bloat, meaning your executable size may increase dramatically (or, if
your compiler is smart enough, may not; try it and see).
The other solution is to leave the definition of the template function in the .cpp file and simply add
the line template void foo<int>(); to that file:
1. // File "foo.cpp"
2. #include <iostream>
3. #include "foo.h"
4.
5. template<typename T> void foo()
6. {
7. std::cout << "Here I am!\n";
8. }
9.
10. template void foo<int>();
If you can’t modify foo.cpp, simply create a new .cpp file such as foo-impl.cpp as follows:
1. // File "foo-impl.cpp"
2. #include "foo.cpp"
3.
4. template void foo<int>();
Notice that foo-impl.cpp #includes a .cpp file, not a .h file. If that’s confusing, click your heels
twice, think of Kansas, and repeat after me, “I will do it anyway even though it’s confusing.” You
can trust me on this one. But if you don’t trust me or are simply curious, the rationale is given
earlier.
How does the C++ keyword export help with template
linker errors?
This answer will be updated due to C++11 extern template. Watch this space for updates in the
near future!!
The C++ keyword export was originally designed to eliminate the need to include a template
definition (either by providing the definition in the header file or by including the implementation
file). However, only a few compilers ever supported this capability, such as Comeau C++ and Sun
Studio, and the general consensus was that it was not worth the trouble.
Because of that, in the C++11 standard, the export feature has been removed from the language. It
remains a reserved word but it no longer has any meaning.
If you are working with a compiler that supports the export keyword, it will probably continue to
support the keyword via some sort of compiler option or extension until its users migrate away from
it. If you already have code that uses export, you can use a fairly simple discipline to allow your
code to easily migrate if/when your compiler stops supporting it entirely. Just define your template
header-files like this:
1. // File Foo.h
2.
3. #ifdef USE_EXPORT_KEYWORD
4. export
5. #endif
6. template<typename T>
7. class Foo {
8. // ...
9. };
10.
11. #ifndef USE_EXPORT_KEYWORD
12. #include "Foo.cpp"
13. #endif
And define your non-inline functions in a source-file like this:
1. // File Foo.cpp
2.
3. #ifdef USE_EXPORT_KEYWORD
4. export
5. #endif
6. template<typename T> ...
Then compile with -DUSE_EXPORT_KEYWORD, or whatever equivalent compiler option lets you set
a preprocessor symbol like USE_COMPILER_KEYWORD, and if/when your compiler removes support
for export, just remove that compiler option.
How can I avoid linker errors with my template
classes?
This answer will be updated due to C++11 extern template. Watch this space for updates in the
near future!!
Tell your C++ compiler which instantiations to make while it is compiling your template
class’s .cpp file.
(If you’ve already read the previous FAQ, this answer is completely symmetric with that one, so
you can probably skip this answer.)
As an example, consider the header file Foo.h which contains the following template class. Note
that method Foo<T>::f() is inline and methods Foo<T>::g() and Foo<T>::h() are not.
1. // File "Foo.h"
2. template<typename T>
3. class Foo {
4. public:
5. void f();
6. void g();
7. void h();
8. };
9.
10. template<typename T>
11. inline
12. void Foo<T>::f()
13. {
14. // ...
15. }
Now suppose file Foo.cpp actually defines the non-
inline methods Foo<T>::g() and Foo<T>::h():
1. // File "Foo.cpp"
2. #include <iostream>
3. #include "Foo.h"
4.
5. template<typename T>
6. void Foo<T>::g()
7. {
8. std::cout << "Foo<T>::g()\n";
9. }
10.
11. template<typename T>
12. void Foo<T>::h()
13. {
14. std::cout << "Foo<T>::h()\n";
15. }
Suppose file main.cpp uses this template class by creating a Foo<int> and calling its methods:
1. // File "main.cpp"
2. #include "Foo.h"
3.
4. int main()
5. {
6. Foo<int> x;
7. x.f();
8. x.g();
9. x.h();
10. // ...
11. }
If you compile and (try to) link these two .cpp files, most compilers will generate linker errors.
There are two solutions for this. The first solution is to physically move the definition of the
template functions into the .h file, even if they are not inline functions. This solution may (or may
not!) cause significant code bloat, meaning your executable size may increase dramatically (or, if
your compiler is smart enough, may not; try it and see).
The other solution is to leave the definition of the template function in the .cpp file and simply add
the line template class Foo<int>; to that file:
1. // File "Foo.cpp"
2. #include <iostream>
3. #include "Foo.h"
4.
5. // ...definition of Foo<T>::f() is unchanged -- see above...
6. // ...definition of Foo<T>::g() is unchanged -- see above...
7.
8. template class Foo<int>;
If you can’t modify Foo.cpp, simply create a new .cpp file such as Foo-impl.cpp as follows:
1. // File "Foo-impl.cpp"
2. #include "Foo.cpp"
3.
4. template class Foo<int>;
Notice that Foo-impl.cpp #includes a .cpp file, not a .h file. If that’s confusing, click your heels
twice, think of Kansas, and repeat after me, “I will do it anyway even though it’s confusing.” You
can trust me on this one. But if you don’t trust me or are simply curious, the rationale is given
earlier.
If you are using Comeau C++, you probably want to learn about the export keyword.
Why do I get linker errors when I use template friends?
Ah, the intricacies of template friends. Here’s an example of what people often want to do:
1. #include <iostream>
2.
3. template<typename T>
4. class Foo {
5. public:
6. Foo(const T& value = T());
7. friend Foo<T> operator+ (const Foo<T>& lhs, const Foo<T>& rhs);
8. friend std::ostream& operator<< (std::ostream& o, const Foo<T>& x);
9. private:
10. T value_;
11. };
 Naturally the template will need to actually be used somewhere:
1. int main()
2. {
3. Foo<int> lhs(1);
4. Foo<int> rhs(2);
5. Foo<int> result = lhs + rhs;
6. std::cout << result;
7. // ...
8. }
And of course the various member and friend functions will need to be defined somewhere:
1. template<typename T>
2. Foo<T>::Foo(const T& value = T())
3. : value_(value)
4. {}
5.
6. template<typename T>
7. Foo<T> operator+ (const Foo<T>& lhs, const Foo<T>& rhs)
8. { return Foo<T>(lhs.value_ + rhs.value_); }
9.
10. template<typename T>
11. std::ostream& operator<< (std::ostream& o, const Foo<T>& x)
12. { return o << x.value_; }
The snag happens when the compiler sees the friend lines way up in the class definition proper.
At that moment it does not yet know the friend functions are themselves templates; it assumes
they are non-templates like this:
1. Foo<int> operator+ (const Foo<int>& lhs, const Foo<int>& rhs)
2. { /*...*/ }
3.
4. std::ostream& operator<< (std::ostream& o, const Foo<int>& x)
5. { /*...*/ }
When you call the operator+ or operator<< functions, this assumption causes the compiler to
generate a call to the non-template functions, but the linker will give you an “undefined external”
error because you never actually defined those non-template functions.
The solution is to convince the compiler while it is examining the class body proper that
the operator+ and operator<< functions are themselves templates. There are several ways to do
this; one simple approach is pre-declare each template friend function above the definition of
template class Foo:
1. template<typename T> class Foo; // pre-declare the template class itself
2. template<typename T> Foo<T> operator+ (const Foo<T>& lhs, const Foo<T>& rhs);
3. template<typename T> std::ostream& operator<< (std::ostream& o, const Foo<T>& x);
Also you add <> in the friend lines, as shown:
1. #include <iostream>
2.
3. template<typename T>
4. class Foo {
5. public:
6. Foo(const T& value = T());
7. friend Foo<T> operator+ <> (const Foo<T>& lhs, const Foo<T>& rhs);
8. friend std::ostream& operator<< <> (std::ostream& o, const Foo<T>& x);
9. private:
10. T value_;
11. };
 After the compiler sees that magic stuff, it will be better informed about the friend functions. In
particular, it will realize that the friend lines are referring to functions that are themselves
templates. That eliminates the confusion.
Another approach is to define the friend function within the class body at the same moment you
declare it to be a friend. For example:
1. #include <iostream>
2.
3. template<typename T>
4. class Foo {
5. public:
6. Foo(const T& value = T());
7.
8. friend Foo<T> operator+ (const Foo<T>& lhs, const Foo<T>& rhs)
9. {
10. // ...
11. }
12.
13. friend std::ostream& operator<< (std::ostream& o, const Foo<T>& x)
14. {
15. // ...
16. }
17.
18. private:
19. T value_;
20. };

Why can’t I define constraints for my template

parameters?
(Note: This FAQ is a bit dated and needs to be updated for static_assert.)
Well, you can, and it’s quite easy and general.
Consider:
1. template<class Container>
2. void draw_all(Container& c)
3. {
4. for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
5. }
If there is a type error, it will be in the resolution of the fairly complicated for_each() call. For
example, if the element type of the container is an int, then we get some kind of obscure error
related to the for_each() call (because we can’t invoke Shape::draw() for an int).
To catch such errors early, you can write:
1. template<class Container>
2. void draw_all(Container& c)
3. {
4. Shape* p = c.front(); // accept only containers of Shape*s
5.
6. for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
7. }
The initialization of the spurious variable p will trigger a comprehensible error message from most
current compilers. Tricks like this are common in all languages and have to be developed for all
novel constructs. In production code, you’d probably write something like:
1. template<class Container>
2. void draw_all(Container& c)
3. {
4. typedef typename Container::value_type T;
5. Can_copy<T,Shape*>(); // accept containers of only Shape*s
6.
7. for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
8. }
This makes it clear that you’re making an assertion. The Can_copy template can be defined like
this:
1. template<class T1, class T2> struct Can_copy {
2. static void constraints(T1 a, T2 b) { T2 c = a; b = a; }
3. Can_copy() { void(*p)(T1,T2) = constraints; }
4. };
Can_copy checks (at compile time) that a T1 can be assigned to
a T2. Can_copy<T,Shape*> checks that T is a Shape* or a pointer to a class publicly derived
from Shape or a type with a user-defined conversion to Shape*. Note that the definition is close to
minimal:
 one line to name the constraints to be checked and the types for which to check them
 one line to list the specific constraints checked (the constraints() function)
 one line to provide a way to trigger the check (the constructor)
Note also that the definition has the desirable properties that
 You can express constraints without declaring or copying variables, thus the writer of a
constraint doesn’t have to make assumptions about how a type is initialized, whether objects can
be copied, destroyed, etc. (unless, of course, those are the properties being tested by the
constraint)
 No code is generated for a constraint using current compilers
 No macros are needed to define or use constraints
Current compilers give acceptable error messages for a failed constraint, including the word
“constraints” (to give the reader a clue), the name of the constraints, and the specific error that
caused the failure (e.g. “cannot initialize Shape* by double*”)
So why is something like Can_copy() – or something even more elegant – not in the language? A
way to specify these constraints directly is being worked on as we speak – see Concepts Lite.
Until then, the above the idea is very general. After all, when we write a template we have the full
expressive power of C++ available. Consider:
1. template<class T, class B> struct Derived_from {
2. static void constraints(T* p) { B* pb = p; }
3. Derived_from() { void(*p)(T*) = constraints; }
4. };
5.
6. template<class T1, class T2> struct Can_copy {
7. static void constraints(T1 a, T2 b) { T2 c = a; b = a; }
8. Can_copy() { void(*p)(T1,T2) = constraints; }
9. };
10.
11. template<class T1, class T2 = T1> struct Can_compare {
12. static void constraints(T1 a, T2 b) { a==b; a!=b; a<b; }
13. Can_compare() { void(*p)(T1,T2) = constraints; }
14. };
15.
16. template<class T1, class T2, class T3 = T1> struct Can_multiply {
17. static void constraints(T1 a, T2 b, T3 c) { c = a*b; }
18. Can_multiply() { void(*p)(T1,T2,T3) = constraints; }
19. };
20.
21. struct B { };
22. struct D : B { };
23. struct DD : D { };
24. struct X { };
25.
26. int main()
27. {
28. Derived_from<D,B>();
29. Derived_from<DD,B>();
30. Derived_from<X,B>();
31. Derived_from<int,B>();
32. Derived_from<X,int>();
33.
34. Can_compare<int,float>();
35. Can_compare<X,B>();
36. Can_multiply<int,float>();
37. Can_multiply<int,float,double>();
38. Can_multiply<B,X>();
39.
40. Can_copy<D*,B*>();
41. Can_copy<D,B*>();
42. Can_copy<int,B*>();
43. }
44.
45. // the classical "elements must derived from Mybase*" constraint:
46.
47. template<class T> class Container : Derived_from<T,Mybase> {
48. // ...
49. };
Actually, Derived_from doesn’t check derivation, but conversion, but that’s often a better
constraint. Finding good names for constraints can be hard.
How can any human hope to understand these overly
verbose template-based error messages?
Compiler error messages have got much better in recent years, and show human-readable typedefs,
as well as highlighting where in the source-code the error occurred.
If you’re still using an older compiler, here’s a free tool that transforms error messages into
something more understandable. The tool is no longer being developed, but worked with the
following compilers: Comeau C++, Intel C++, CodeWarrior C++, GCC, Borland C++, Microsoft
Visual C++, and EDG C++.
Here’s an example showing some unfiltered GCC error messages:
1. rtmap.cpp: In function `int main()':
2. rtmap.cpp:19: invalid conversion from `int' to `
3. std::_Rb_tree_node<std::pair<const int, double> >*'
4. rtmap.cpp:19: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
5. _Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
6. std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
7. std::pair<const int, double>*]'
8. rtmap.cpp:20: invalid conversion from `int' to `
9. std::_Rb_tree_node<std::pair<const int, double> >*'
10. rtmap.cpp:20: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
11. _Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
12. std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
13. std::pair<const int, double>*]'
14. E:/GCC3/include/c++/3.2/bits/stl_tree.h: In member function `void
15. std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(_II,
16. _II) [with _InputIterator = int, _Key = int, _Val = std::pair<const int,
17. double>, _KeyOfValue = std::_Select1st<std::pair<const int, double> >,
18. _Compare = std::less<int>, _Alloc = std::allocator<std::pair<const int,
19. double> >]':
20. E:/GCC3/include/c++/3.2/bits/stl_map.h:272: instantiated from `void std::map<_
21. Key, _Tp, _Compare, _Alloc>::insert(_InputIterator, _InputIterator) [with _Input
22. Iterator = int, _Key = int, _Tp = double, _Compare = std::less<int>, _Alloc = st
23. d::allocator<std::pair<const int, double> >]'
24. rtmap.cpp:21: instantiated from here
25. E:/GCC3/include/c++/3.2/bits/stl_tree.h:1161: invalid type argument of `unary *
26. '
Here’s what the filtered error messages look like (note: you can configure the tool so it shows more
information; this output was generated with settings to strip things down to a minimum):
1. rtmap.cpp: In function `int main()':
2. rtmap.cpp:19: invalid conversion from `int' to `iter'
3. rtmap.cpp:19: initializing argument 1 of `iter(iter)'
4. rtmap.cpp:20: invalid conversion from `int' to `iter'
5. rtmap.cpp:20: initializing argument 1 of `iter(iter)'
6. stl_tree.h: In member function `void map<int,double>::insert_unique(_II, _II)':
7. [STL Decryptor: Suppressed 1 more STL standard header message]
8. rtmap.cpp:21: instantiated from here
9. stl_tree.h:1161: invalid type argument of `unary *'
Here is the source code to generate the above example:
1. #include <map>
2. #include <algorithm>
3. #include <cmath>
4.
5. const int values[] = { 1,2,3,4,5 };
6. const int NVALS = sizeof values / sizeof (int);
7.
8. int main()
9. {
10. using namespace std;
11.
12. typedef map<int, double> valmap;
13.
14. valmap m;
15.
16. for (int i = 0; i < NVALS; i++)
17. m.insert(make_pair(values[i], pow(values[i], .5)));
18.
19. valmap::iterator it = 100; // error
20. valmap::iterator it2(100); // error
21. m.insert(1,2); // error
22.
23. return 0;
24. }

Why am I getting errors when my template uses a nested

type?
Perhaps surprisingly, the following code is not valid C++, even though some compilers accept it:
1. template<typename Container, typename T>
2. bool contains(const Container& c, const T& val)
3. {
4. Container::iterator iter; // Error, "Container::iterator" is not a type
5. iter = std::find(c.begin(), c.end(), val);
6. return iter !=- c.end();
7. }
The reason is that in theory the function template could be called with a type that has a data member
or a member function called iterator. When the compiler is parsing the template contains it
doesn’t know anything about the types it will be passed by the code that comes later. This means
that until the compiler knows what Container is and what members it has, there’s no way to know
whether Container::iterator is a type or not. In fact, the rules of C++ say that until told
otherwise, the compiler must assume Container::iterator is not a type. The solution is to give
the compiler a hint via the typename keyword:
1. template<typename Container, typename T>
2. bool contains(const Container& c, const T& val)
3. {
4. typename Container::iterator iter;
5. iter = std::find(c.begin(), c.end(), val);
6. return iter !=- c.end();
7. }
This tells the compiler that when the function template is used later its argument will always be
something for which Container::iterator is a type. (And if you actually try to call it with a
type where iterator is a data member or something else, you will get an error).
Why am I getting errors when my template-derived-class
uses a nested type it inherits from its template-base-
class?
Perhaps surprisingly, the following code is not valid C++, even though some compilers accept it:
1. template<typename T>
2. class B {
3. public:
4. class Xyz { /*...*/ }; // Type nested in class B<T>
5. typedef int Pqr; // Type nested in class B<T>
6. };
7.
8. template<typename T>
9. class D : public B<T> {
10. public:
11. void g()
12. {
13. Xyz x; // Bad (even though some compilers erroneously (temporarily?) accept it)
14. Pqr y; // Bad (even though some compilers erroneously (temporarily?) accept it)
15. }
16. };
This might hurt your head; better if you sit down.
Within D<T>::g(), name Xyz and Pqr do not depend on template parameter T, so they are known
as a nondependent names. On the other hand, B<T> is dependent on template
parameter T so B<T> is called a dependent name.
Here’s the rule: the compiler does not look in dependent base classes (like B<T>) when looking up
nondependent names (like Xyz or Pqr). As a result, the compiler does not know they even exist let
alone are types.
At this point, programmers sometimes prefix them with B<T>::, such as:
1. template<typename T>
2. class D : public B<T> {
3. public:
4. void g()
5. {
6. B<T>::Xyz x; // Bad (even though some compilers erroneously (temporarily?) accept it)
7. B<T>::Pqr y; // Bad (even though some compilers erroneously (temporarily?) accept it)
8. }
9. };
Unfortunately this doesn’t work either because those names (are you ready? are you sitting down?)
are not necessarily types. “Huh?!?” you say. “Not types?!?” you exclaim. “That’s crazy; any fool
can SEE they are types; just look!!!” you protest. Sorry, the fact is that they might not be types. The
reason is that there can be a specialization of B<T>, say B<Foo>, where B<Foo>::Xyz is a data
member, for example. Because of this potential specialization, the compiler cannot assume
that B<T>::Xyz is a type until it knows T. The solution is to give the compiler a hint via
the typename keyword:
1. template<typename T>
2. class D : public B<T> {
3. public:
4. void g()
5. {
6. typename B<T>::Xyz x; // Good
7. typename B<T>::Pqr y; // Good
8. }
9. };

Why am I getting errors when my template-derived-class

uses a member it inherits from its template-base-class?
Perhaps surprisingly, the following code is not valid C++, even though some compilers accept it:
1. template<typename T>
2. class B {
3. public:
4. void f() { } // Member of class B<T>
5. };
6.
7. template<typename T>
8. class D : public B<T> {
9. public:
10. void g()
11. {
12. f(); // Bad (even though some compilers erroneously (temporarily?) accept it)
13. }
14. };
This might hurt your head; better if you sit down.
Within D<T>::g(), the name f does not depend on template parameter T, so f is known as
a nondependent name. On the other hand, B<T> is dependent on template parameter T so B<T> is
called a dependent name.
Here’s the rule: the compiler does not look in dependent base classes (like B<T>) when looking up
nondependent names (like f).
This doesn’t mean that inheritance doesn’t work. Class D<int> is still derived from class B<int>,
the compiler still lets you implicitly do the is-a conversions (e.g., D<int>* to B<int>*), dynamic
binding still works when virtual functions are invoked, etc. But there is an issue about how names
are looked up.
 Workarounds:
 Change the call from f() to this->f(). Since this is always implicitly dependent in a
template, this->f is dependent and the lookup is therefore deferred until the template is actually
instantiated, at which point all base classes are considered.
 Insert using B<T>::f; just prior to calling f().
 Change the call from f() to B<T>::f(). Note however that this might not give you what
you want if f() is virtual, since it inhibits the virtual dispatch mechanism.
Can the previous problem hurt me silently? Is it possible
that the compiler will silently generate the wrong code?
Yes.
Since non-dependent types and non-dependent members are not found in the dependent template
base-classes, the compiler will search the enclosing scope, such as the enclosing namespace. This
can cause it to silently(!) do the wrong thing.
For example:
1. class Xyz { /*...*/ }; // Global ("namespace scope") type
2. void f() { } // Global ("namespace scope") function
3.
4. template<typename T>
5. class B {
6. public:
7. class Xyz { /*...*/ }; // Type nested in class B<T>
8. void f() { } // Member of class B<T>
9. };
10.
11. template<typename T>
12. class D : public B<T> {
13. public:
14. void g()
15. {
16. Xyz x; // Suprise: you get the global Xyz!!
17. f(); // Suprise: you get the global f!!
18. }
19. };
The use of Xyz and f within D<T>::g() will silently(!) resolve to the global entities rather than
those inherited from class B<T>.
You have been warned.

How can I create a container-template that allows my

users to supply the type of the underlying container that
actually stores the values?
First, let’s clarify the question: the goal is to create a template Foo<>, but having the template
parameter-list include some particular type of std::vector<T> or std::list<T> or some other
(possibly non-standard) container to actually store the values.
Here’s one way to do that:
1. template<typename Underlying>
2. class Foo {
3. public:
4. // typename value_type is the type of the values within a Foo-container
5. typedef typename Underlying::value_type value_type;
6.
7. void insert(const typename value_type& x)
8. {
9. // ...code to insert x into data_...
10. }
11.
12. // ...
13. private:
14. Underlying data_;
15. };
16.
17. Foo<std::vector<int> > x;
18. Foo<std::list<double> > y;
If you want to allow your users to provide you with an underlying container that does not
necessarily have a value_type typedef (such as some container from a third party), you could
provide the value-type explicitly:
1. template<typename T, typename Underlying>
2. class Foo {
3. public:
4. // typename value_type is the type of the values within a Foo-container
5. typedef T value_type;
6.
7. void insert(const typename value_type& x)
8. {
9. // ...code to insert x into data_...
10. }
11.
12. // ...
13.
14. private:
15. Underlying data_;
16. };
17.
18. Foo<int, std::vector<int> > x;
19. Foo<double, std::list<double> > y;
However you cannot (yet) provide an unspecified template as a template parameter, such as this:
1. template<typename T, template<typename> class Underlying> // Conceptual only; not C++
2. class Foo {
3. public:
4. // ...
5. private:
6. Underlying<T> data_; // Conceptual only; not C++
7. };
8.
9. Foo<int, std::vector> x; // Conceptual only; not C++
10. Foo<double, std::list> y; // Conceptual only; not C++

Follow-up to previous: can I pass in the underlying

structure and the element-type separately?
Yes, with a “proxy” trick.
Here’s the problem: std::vector template can have, does have, more than one argument. You’re
required to make them match in the number, order, and nature — type/non-type, etc.
 It is possible, however, to “cheat” your way out of specifying all those arguments and use the
defaults. It’s called the “proxy template” technique:
1. #include <vector>
2. #include <list>
3.
4. template<typename T>
5. struct wrap_vector {
6. typedef std::vector<T> type;
7. };
8.
9. template<typename T>
10. struct wrap_list {
11. typedef std::list<T> type;
12. };
13.
14. template<typename T, template<typename> class C>
15. struct A {
16. typename C<T>::type data; // trick to use a proxy
17. };
18.
19. int main()
20. {
21. A<int,wrap_vector> avi;
22. A<double,wrap_list> adl;
23. // ...
24. }
You can also create a proxy if you actually have a template that takes only one argument:
1. template<typename T>
2. struct wrap_my1argtemplate {
3. typedef my1argtemplate<T> type;
4. };
The “template typedefs” proposal will allow redefining templates just like we do with types, which
will make the proxy-trick unnecessary. Until then, use something like the above.

Related: all those proxies must negatively reflect on the

speed of my program. Don’t they?
No.
They might require an extra microsecond to compile, but once all the types are resolved by the
compiler, the resulting code is just as fast as if you used them directly without any proxy templates
whatsoever.
Not only that, there are some techniques (template meta programming or TMP) that can, under the
right circumstances, improve the efficiency of the generated code. The basic notion is to get the
compiler to do more work at compile-time so less work has to be done at runtime.

Container Classes
Save to:
InstapaperPocketReadability
Contents of this section:

 Why should I use container classes rather than simple arrays?

 How can I make a perl-like associative array in C++?
  Is the storage for a std::vector<T> or a std::array<T,N> guaranteed to be
contiguous?
 Why doesn’t C++ provide heterogeneous containers?
 How can I build a heterogeneous <favorite container> of objects of different types?
 Why can’t I assign a vector<Apple*> to a vector<Fruit*>?
 How can I insert/access/change elements from a linked list/hashtable/etc?
 Can I have a container of smart pointers to my objects?
 Why are the standard containers so slow?
Why should I use container classes rather than simple
arrays?
In terms of time and space, a contiguous array of any kind is just about the optimal construct for
accessing a sequence of objects in memory, and if you are serious about performance in any
language you will “often” use arrays.
However, there are good arrays (e.g., containers with contiguous storage such
as std::array and std::vector) and there are bad arrays (e.g., C [] arrays). Simple
C [] arrays are evil because a C array is a very low level data structure with a vast potential for
misuse and errors and in essentially all cases there are better alternatives – where “better” means
easier to write, easier to read, less error prone, and as fast.
The two fundamental problems with C arrays are that
 a C array doesn’t know its own size
 the name of a C array converts to a pointer to its first element at the slightest provocation
Consider some examples:
1. void f(int a[], int s)
2. {
3. // do something with a; the size of a is s
4. for (int i = 0; i<s; ++i) a[i] = i;
5. }
6.
7. int arr1[20];
8. int arr2[10];
9.
10. void g()
11. {
12. f(arr1,20);
13. f(arr2,20);
14. }
The second call will scribble all over memory that doesn’t belong to arr2. Naturally, a programmer
usually gets the size right, but it’s extra work and every so often someone makes a mistake. You
should prefer the simpler and cleaner version using the standard library vector or array:
1. void f(vector<int>& v)
2. {
3. // do something with v
4. for (int i = 0; i<v.size(); ++i) v[i] = i;
5. }
6.
7. vector<int> v1(20);
8. vector<int> v2(10);
9.
10. void g()
11. {
12. f(v1);
13. f(v2);
14. }
1. template<size_t N> void f(array<int, N>& v)
2. {
3. // do something with v
4. for (int i = 0; i<N; ++i) v[i] = i;
5. }
6.
7. array<int, 20> v1;
8. array<int, 10> v2;
9.
10. void g()
11. {
12. f(v1);
13. f(v2);
14. }
Since a C array doesn’t know its size, there can be no array assignment:
1. void f(int a[], int b[], int size)
2. {
3. a = b; // not array assignment
4. memcpy(a,b,size); // a = b
5. // ...
6. }
Again, prefer vector or array:
1. // This one can result in a changing size
2. void g(vector<int>& a, vector<int>& b)
3. {
4. a = b;
5. // ...
6. }
7.
8. // In this one, a and b must be the same size
9. template<size_t N>
10. void g(array<int, N>& a, array<int, N>& b)
11. {
12. a = b;
13. // ...
14. }
Another advantage of vector here is that memcpy() is not going to do the right thing for elements
with copy constructors, such as strings.
1. void f(string a[], string b[], int size)
2. {
3. a = b; // not array assignment
4. memcpy(a,b,size); // disaster
5. // ...
6. }
7.
8. void g(vector<string>& a, vector<string>& b)
9. {
10. a = b;
11. // ...
12. }
A normal C array is of a fixed size determined at compile time (ignoring C99 VLAs, which
currently have no analog in ISO C++):
1. const int S = 10;
2.
3. void f(int s)
4. {
5. int a1[s]; // error
6. int a2[S]; // ok
7.
8. // if I want to extend a2, I'll have to change to an array
9. // allocated on free store using malloc() and use realloc()
10. // ...
11. }
To contrast:
1. const int S = 10;
2.
3. void g(int s)
4. {
5. vector<int> v1(s); // ok
6. vector<int> v2(S); // ok
7. v2.resize(v2.size()*2);
8. // ...
9. }
C99 allows variable array bounds for local arrays, but those VLAs have their own problems. The
way that array names “decay” into pointers is fundamental to their use in C and C++. However,
array decay interacts very badly with inheritance. Consider:
1. class Base { void fct(); /* ... */ };
2. class Derived : Base { /* ... */ };
3.
4. void f(Base* p, int sz)
5. {
6. for (int i=0; i<sz; ++i) p[i].fct();
7. }
8.
9. Base ab[20];
10. Derived ad[20];
11.
12. void g()
13. {
14. f(ab,20);
15. f(ad,20); // disaster!
16. }
In the last call, the Derived[] is treated as a Base[] and the subscripting no longer works
correctly when sizeof(Derived)!=sizeof(Base) – as will be the case in most cases of
interest. If we used vectors instead, the error would be caught at compile time:
1. void f(vector<Base>& v)
2. {
3. for (int i=0; i<v.size(); ++i) v[i].fct();
4. }
5.
6. vector<Base> ab(20);
7. vector<Derived> ad(20);
8.
9. void g()
10. {
11. f(ab);
12. f(ad); // error: cannot convert a vector<Derived> to a vector<Base>
13. }
We find that an astonishing number of novice programming errors in C and C++ relate to (mis)uses
of C arrays. Use std::vector or std::array instead.
Let’s assume the best case scenario: you’re an experienced C programmer, which almost by
definition means you’re pretty good at working with arrays. You know you can handle the
complexity; you’ve done it for years. And you’re smart — the smartest on the team — the smartest
in the whole company. But even given all that, please read this entire FAQ and think very carefully
about it before you go into “business as usual” mode.
Fundamentally it boils down to this simple fact: C++ is not C. That means (this might be painful for
you!!) you’ll need to set aside some of your hard earned wisdom from your vast experience in C.
The two languages simply are different. The “best” way to do something in C is not always the
same as the “best” way to do it in C++. If you really want to program in C, please do yourself a
favor and program in C. But if you want to be really good at C++, then learn the C++ ways of doing
things. You may be a C guru, but if you’re just learning C++, you’re just learning C++ — you’re a
newbie. (Ouch; I know that had to hurt. Sorry.)
Here’s what you need to realize about containers vs. arrays:
1. Container classes make programmers more productive. So if you insist on using arrays while
those around are willing to use container classes, you’ll probably be less productive than they are
(even if you’re smarter and more experienced than they are!).
2. Container classes let programmers write more robust code. So if you insist on using arrays
while those around are willing to use container classes, your code will probably have more bugs
than their code (even if you’re smarter and more experienced).
3. And if you’re so smart and so experienced that you can use arrays as fast and as safe as they
can use container classes, someone else will probably end up maintaining your code
and they’ll probably introduce bugs. Or worse, you’ll be the only one who can maintain your code
so management will yank you from development and move you into a full-time maintenance role
— just what you always wanted!
Here are some specific problems with arrays:
1. Subscripts don’t get checked to see if they are out of bounds. (Note that some container
classes, such as std::vector, have methods to access elements with or without bounds
checking on subscripts.)
2. Arrays often require you to allocate memory from the heap (see below for examples), in
which case you must manually make sure the allocation is eventually deleted (even when
someone throws an exception). When you use container classes, this memory management is
handled automatically, but when you use arrays, you have to manually write a bunch of code
(and unfortunately that code is often subtle and tricky) to deal with this. For example, in addition
to writing the code that destroys all the objects and deletes the memory, arrays often also force
you you to write an extra try block with a catch clause that destroys all the objects, deletes
the memory, then re-throws the exception. This is a real pain in the neck, as shown here. When
using container classes, things are much easier.
3. You can’t insert an element into the middle of the array, or even add one at the end, unless
you allocate the array via the heap, and even then you must allocate a new array and copy the
elements.
4. Container classes give you the choice of passing them by reference or by value, but arrays do
not give you that choice: they are always passed by reference. If you want to simulate pass-by-
value with an array, you have to manually write code that explicitly copies the array’s elements
(possibly allocating from the heap), along with code to clean up the copy when you’re done with
it. All this is handled automatically for you if you use a container class.
 5. If your function has a non-static local array (i.e., an “automatic” array), you cannot return
that array, whereas the same is not true for objects of container classes.
Here are some things to think about when using containers:
1. Different C++ containers have different strengths and weaknesses, but for any given job
there’s usually one of them that is better — clearer, safer, easier/cheaper to maintain, and often
more efficient — than an array. For instance,
 You might consider a std::map instead of manually writing code for a lookup table.
 A std::map might also be used for a sparse array or sparse matrix.
 A std::array is the most array-like of the standard container classes, but it also
offers various extra features such as bounds checking via the at() member function, automatic
memory management even if someone throws an exception, ability to be passed both by
reference and by value, etc.
 A std::vector is the second-most array-like of the standard container classes, and
offers additional extra features over std::array such as insertions/removals of elements.
 A std::string is almost always better than an array of char (you can think of
a std::string as a “container class” for the sake of this discussion).
2. Container classes aren’t best for everything, and sometimes you may need to use arrays. But
that should be very rare, and if/when it happens:
 Please design your container class’s public interface in such a way that the code that
uses the container class is unaware of the fact that there is an array inside.
 The goal is to “bury” the array inside a container class. In other words, make sure
there is a very small number of lines of code that directly touch the array (just your own
methods of your container class) so everyone else (the users of your container class) can write
code that doesn’t depend on there being an array inside your container class.
To net this out, arrays really are evil. You may not think so if you’re new to C++. But after you
write a big pile of code that uses arrays (especially if you make your code leak-proof and exception-
safe), you’ll learn — the hard way. Or you’ll learn the easy way by believing those who’ve already
done things like that. The choice is yours.
How can I make a perl-like associative array in C++?
Use the standard class template std::map<Key,Val>:
1. #include <string>
2. #include <map>
3. #include <iostream>
4.
5. int main()
6. {
7. // age is a map from string to int
8. std::map<std::string, int, std::less<std::string>> age;
9.
10. age["Fred"] = 42; // Fred is 42 years old
11. age["Barney"] = 37; // Barney is 37
12.
13. if (todayIsFredsBirthday()) // On Fred's birthday...
14. ++ age["Fred"]; // ...increment Fred's age
15.
16. std::cout << "Fred is " << age["Fred"] << " years old\n";
17. // ...
18. }
Nit: the order of elements in a std::map<Key,Val> are in the sort order based on the key, so from
a strict standpoint, that is different from Perl’s associative arrays which are unordered. If you want
an unsorted version for a closer match, you can use std::unordered_map<Key,Val> instead.
 Is the storage for a std::vector<T> or
a std::array<T,N> guaranteed to be contiguous?
Yes.
This means the following technique is safe:
1. #include <vector>
2. #include <array>
3. #include "Foo.h" /* get class Foo */
4.
5. // old-style code that wants an array
6. void f(Foo* array, unsigned numFoos);
7.
8. void g()
9. {
10. std::vector<Foo> v;
11. std::array<Foo, 10> a;
12. // ...
13. f(v.data(), v.size()); // Safe
14. f(a.data(), a.size()); // Safe
15. }
In general, it means you are guaranteed that &v[0] + n == &v[n], where v is a non-
empty std::vector<T> or std::array<T,N> and n is an integer in the range 0 ..
v.size()-1.
However v.begin() is not guaranteed to be a T*, which means v.begin() is not guaranteed to
be the same as &v[0]:
1. void g()
2. {
3. std::vector<Foo> v;
4. // ...
5. f(v.begin(), v.size()); // error, not guaranteed to be the same as &v[0]
6. ↑↑↑↑↑↑↑↑↑ // cough, choke, gag; use v.data() instead
7. }
Also, using &v[0] is undefined behavior if the std::vector or std::array is empty, while it is
always safe to use the .data() function.
Note: It’s possible the above code might compile for you today. If your compiler vendor happens to
implement std::vector or std::array iterators as T*’s, the above may happen to work on that
compiler – and at that, possibly only in release builds, because vendors often supply debug iterators
that carry more information than a T*. But even if this code happens to compile for you today, it’s
only by chance because of a particular implementation. It’s not portable C++ code.
Use .data() for these situations.
Why doesn’t C++ provide heterogeneous containers?
The C++ standard library provides a set of useful, statically type-safe, and efficient containers.
Examples are vector, list, and map:
1. vector<int> vi(10);
2. vector<Shape*> vs;
3. list<string> lst;
4. list<double> l2
5. map<string,Record*> tbl;
6. unordered_map<Key,vector<Record*> > t2;
These containers are described in all good C++ textbooks, and should be preferred over arrays and
“home cooked” containers unless there is a good reason not to.
 These containers are homogeneous; that is, they hold elements of the same type. If you want a
container to hold elements of several different types, you must express that either as a union or
(usually much better) as a container of pointers to a polymorphic type. The classical example is:
1. vector<Shape*> vi; // vector of pointers to Shapes
Here, vi can hold elements of any type derived from Shape. That is, vi is homogeneous in that all
its elements are Shapes (to be precise, pointers to Shapes) and heterogeneous in the sense
that vi can hold elements of a wide variety of Shapes, such as Circles, Triangles, etc.
So, in a sense all containers (in every language) are homogeneous because to use them there must be
a common interface to all elements for users to rely on. Languages that provide containers deemed
heterogeneous simply provide containers of elements that all provide a standard interface. For
example, Java collections provide containers of (references to) Objects and you use the (common)
Object interface to discover the real type of an element.
The C++ standard library provides homogeneous containers because those are the easiest to use in
the vast majority of cases, gives the best compile-time error message, and imposes no unnecessary
run-time overheads.
If you need a heterogeneous container in C++, define a common interface for all the elements and
make a container of those. For example:
1. class Io_obj { /* ... */ }; // the interface needed to take part in object I/O
2.
3. vector<Io_obj*> vio; // if you want to manage the pointers directly
4. vector<shared_ptr<Io_obj>> v2; // if you want a "smart pointer" to handle the objects
Don’t drop to the lowest level of implementation detail unless you have to:
1. vector<void*> memory; // rarely needed
A good indication that you have “gone too low level” is that your code gets littered with casts.
Using an Any class, such as boost::any, can be an alternative in some programs:
1. vector<any> v = { 5, "xyzzy", 3.14159 };
If all objects you want to store in a container are publicly derived from a common base class, you
can then declare/define your container to hold pointers to the base class. You indirectly store a
derived class object in a container by storing the object’s address as an element in the container.
You can then access objects in the container indirectly through the pointers (enjoying polymorphic
behavior). If you need to know the exact type of the object in the container you can
use dynamic_cast<> or typeid(). You’ll probably need the Virtual Constructor Idiom to copy a
container of disparate object types. The downside of this approach is that it makes memory
management a little more problematic (who “owns” the pointed-to objects? if you delete these
pointed-to objects when you destroy the container, how can you guarantee that no one else has a
copy of one of these pointers? if you don’t delete these pointed-to objects when you destroy the
container, how can you be sure that someone else will eventually do the deleteing?). It also makes
copying the container more complex (may actually break the container’s copying functions since
you don’t want to copy the pointers, at least not when the container “owns” the pointed-to objects).
In that case, you can use std::shared_ptr to manage the objects, and the containers will copy
correctly.
The second case occurs when the object types are disjoint — they do not share a common base
class. The approach here is to use a handle class. The container is a container of handle objects (by
value or by pointer, your choice; by value is easier). Each handle object knows how to “hold on to”
(i.e., maintain a pointer to) one of the objects you want to put in the container. You can use either a
single handle class with several different types of pointers as instance data, or a hierarchy of handle
classes that shadow the various types you wish to contain (requires the container be of handle base
class pointers). The downside of this approach is that it opens up the handle class(es) to
 maintenance every time you change the set of types that can be contained. The benefit is that you
can use the handle class(es) to encapsulate most of the ugliness of memory management and object
lifetime.

How can I build a heterogeneous <favorite container> of

objects of different types?
See heterogeneous containers.
Why can’t I assign a vector<Apple*> to
a vector<Fruit*>?
Because that would open a hole in the type system. For example:
1. class Apple : public Fruit { void apple_fct(); /* ... */ };
2. class Orange : public Fruit { /* ... */ }; // Orange doesn't have apple_fct()
3.
4. vector<Apple*> v; // vector of Apples
5.
6. void f(vector<Fruit*>& vf) // innocent Fruit manipulating function
7. {
8. vf.push_back(new Orange); // add orange to vector of fruit
9. }
10.
11. void h()
12. {
13. f(v); // error: cannot pass a vector<Apple*> as a vector<Fruit*>
14. for (int i=0; i<v.size(); ++i) v[i]->apple_fct();
15. }
Had the call f(v) been legal, we would have had an Orange pretending to be an Apple.
An alternative language design decision would have been to allow the unsafe conversion, but rely
on dynamic checking. That would have required a run-time check for each access to v’s members,
and h() would have had to throw an exception upon encountering the last element of v.
How can I insert/access/change elements from a linked
list/hashtable/etc?
The most important thing to remember is this: don’t roll your own from scratch unless there is a
compelling reason to do so. In other words, instead of creating your own list or hashtable, use one of
the standard class templates such as std::vector<T> or std::list<T> or whatever.
Assuming you have a compelling reason to build your own container, here’s how to handle inserting
(or accessing, changing, etc.) the elements.
To make the discussion concrete, I’ll discuss how to insert an element into a linked list. This
example is just complex enough that it generalizes pretty well to things like vectors, hash tables,
binary trees, etc.
A linked list makes it easy to insert an element before the first or after the last element of the list,
but limiting ourselves to these would produce a library that is too weak (a weak library is almost
worse than no library). This answer will be a lot to swallow for novice C++’ers, so I’ll give a couple
of options. The first option is easiest; the second and third are better.
1. Empower the List with a “current location,” and member functions such
as advance(), backup(), atEnd(), atBegin(), getCurrElem(), setCurrElem(Elem), i
nsertElem(Elem), and removeElem(). Although this works in small examples, the notion
 of a current position makes it difficult to access elements at two or more positions within the list
(e.g., “for all pairs x,y do the following…”).
2. Remove the above member functions from List itself, and move them to a separate
class, ListPosition. ListPosition would act as a “current position” within a list. This
allows multiple positions within the same list. ListPosition would be
a friend of class List, so List can hide its innards from the outside world (else the innards
of List would have to be publicized via public member functions in List).
Note: ListPosition can use operator overloading for things
like advance() and backup(), since operator overloading is syntactic sugar for normal
member functions.
3. Consider the entire iteration as an atomic event, and create a class template that embodies
this event. This enhances performance by allowing the public access member functions (which
may be virtual functions) to be avoided during the access, and this access often occurs within
an inner loop. Unfortunately the class template will increase the size of your object code, since
templates gain speed by duplicating code. For more, see [Koenig, “Templates as interfaces,”
JOOP, 4, 5 (Sept 91)], and [Stroustrup, “The C++ Programming Language Third Edition,” under
“Comparator”].
Can I have a container of smart pointers to my objects?
Yes, and you really want to do this, as smart pointers make your life easier and make your code
more robust compared to the alternatives.
Note: forget that std::auto_ptr ever existed. Really. You don’t want to use it, ever, especially in
containers. It is broken in too many ways.
Let’s motivate this discussion with an example. This first section shows why you’d want to use
smart pointers in the first place - this is what not to do:
1. #include <vector>
2.
3. class Foo {
4. public:
5. // ...blah blah...
6. };
7.
8. void foo(std::vector<Foo*>& v) // ← BAD FORM: a vector of dumb pointers to Foo objects
9. {
10. v.push_back(new Foo());
11. // ...
12. delete v.back(); // you have a leak if this line is skipped
13. v.pop_back(); // you have a "dangling pointer" if control-flow doesn't reach this line
14. }
If control flow doesn’t reach either of the last two lines, either because you don’t have it in your
code or you do a return or something throws an exception, you will have a leak or a “dangling
pointer”; bad news. The destructor of std::vector cleans up whatever allocations were made by
the std::vector object itself, but it will not clean up the allocation that you made
when you allocated a Foo object, even though you put a pointer to that allocated Foo object into
the std::vector object.
That’s why you’d want to use a smart pointer.
Now let’s talk about how to use a smart pointer. There are lots of smart pointers that can be copied
and still maintain shared ownership semantics, such as std::shared_ptr and many others. For
this example, we will use std::shared_ptr, though you might choose another based on the
semantics and performance trade-offs you desire.
1. typedef std::shared_ptr<Foo> FooPtr; // ← GOOD: using a smart-pointer
2.
3. void foo(std::vector<FooPtr>& v) // ← GOOD: using a container of smart-pointer
4. {
5. // ...
6. }
This just works safely with all operations. The object is destroyed when the last shared_ptr to it
is destroyed or set to point to something else.
Using a std::unique_ptr in a std::vector is safe, but it has some restrictions.
The unique_ptr is a move-only type, it can’t be copied. This move-only restriction then applies to
the std::vector containing them as well.
1. void create_foo(std::vector<std::unique_ptr<Foo>> &v)
2. {
3. v.emplace_back(std::make_unique<Foo>(/* ... */));
4. }
If you want to put an element from this vector into another vector, you must move it to the other
vector, as only one unique_ptr at a time can point to the same Foo object.
There are lots of good articles on this general topic, such as Herb Sutter’s in Dr. Dobbs and many
others.
Why are the standard containers so slow?
They aren’t, they’re among the fastest on the planet.
Probably “compared to what?” is a more useful question (and answer). When people complain
about standard-library container performance, we usually find one of three genuine problems (or
one of the many myths and red herrings):
 I suffer copy overhead
 I suffer slow speed for lookup tables
 My hand-coded (intrusive) lists are much faster than std::list
Before trying to optimize, consider if you have a genuine performance problem. In most of the cases
sent to me, the performance problem is theoretical or imaginary: First measure, then optimize only
if needed.
Let’s look at those problems in turn. Often, a vector<X> is slower than somebody’s
specialized My_container<X> because My_container<X> is implemented as a container of
pointers to X (brief spoiler: if you want that, you have it too: vector<X*> – more on this in a
moment). A vector<X> (no *) holds copies of values, and copies a value when you put it into the
container. This is essentially unbeatable for small values, but can be quite unsuitable for huge
objects:
1. vector<int> vi;
2. vector<Image> vim;
3. // ...
4. int i = 7;
5. Image im("portrait.jpg"); // initialize image from file
6. // ...
7. vi.push_back(i); // put (a copy of) i into vi
8. vim.push_back(im); // put (a copy of) im into vim
Now, if portrait.jpg is a couple of megabytes and Image has value semantics (i.e., copy
assignment and copy construction make copies) then vim.push_back(im) will indeed be
expensive. But – as the saying goes – if it hurts so much, just don’t do it.
Move semantics and in-place construction can negate many of these costs if the vector is going to
own the object, and you don’t need copies of it elsewhere.
1. vector<Image> vim;
2. vim.emplace_back("portrait.jpg"); // create image from file in place in the vector
 Alternatively, either use a container of handles or a container of pointers. For example,
if Image had reference semantics, the code above would incur only the cost of a copy constructor
call, which would be trivial compared to most image manipulation operators. If some class,
say Image again, does have copy semantics for good reasons, a container of pointers is often a
reasonable solution:
1. vector<int> vi;
2. vector<Image*> vim;
3. // ...
4. Image im("portrait.jpg"); // initialize image from file
5. // ...
6. vi.push_back(7); // put (a copy of) 7 into vi
7. vim.push_back(&im); // put (a copy of) &im into vim
Naturally, if you use pointers, you have to think about resource management, but containers of
pointers can themselves be effective and cheap resource handles (often, you need a container with a
destructor for deleting the “owned” objects), or you can simply use a container of smart pointers.
The second frequently occurring genuine performance problem is the use of a map<string,X> for
a large number of (string,X) pairs. Maps are fine for relatively small containers (say a few
hundred or few thousand elements – access to an element of a map of 10000 elements costs about 9
comparisons), where less-than is cheap, and where no good hash-function can be constructed. If you
have lots of strings and a good hash function, use an unordered_map.
Sometimes, you can speed up things by using (const char*,X) pairs rather
than (string,X) pairs, but remember that < doesn’t do lexicographical comparison for C-style
strings. Also, if X is large, you may have the copy problem also (solve it in one of the usual ways).
Intrusive lists can be really fast. However, consider whether you need a list at all: A vector is
more compact and is therefore smaller and faster in many cases – even when you do inserts and
erases. For example, if you logically have a list of a few integer elements, a vector is significantly
faster than a list (any list). Also, intrusive lists cannot hold built-in types directly (an int does not
have a link member). So, assume that you really need a list and that you can supply a link field for
every element type. The standard-library list by default performs an allocation followed by a copy
for each operation inserting an element (and a deallocation for each operation removing an
element). For std::list with the default allocator, this can be significant. For small elements
where the copy overhead is not significant, consider using an optimized allocator. Use a hand-
crafted intrusive lists only where a list and the last ounce of performance is needed.
People sometimes worry about the cost of std::vector growing incrementally. Many C++
programmers used to worry about that and used reserve() to optimize the growth. After
measuring their code and repeatedly having trouble finding the performance benefits
of reserve() in real programs, they stopped using it except where it is needed to avoid iterator
invalidation (a rare case in most code). Again: measure before you optimize.
The cost of std::vector growing incrementally in C++11 can be a lot less than it was in C+
+98/03 when you are using move-aware types, such as std::string or even std::vector<T>,
as when the vector is reallocated, the objects are moved into the new storage instead of copied.

Class Libraries
Save to:
InstapaperPocketReadability
Contents of this section:

 What is the “STL”?

 Where can I get a copy of “STL”?
 How can I find a Fred object in an STL container of Fred* such
as std::vector<Fred*>?
  Where can I get help on how to use STL?
 How can you tell if you have a dynamically typed C++ class library?
 What is the NIHCL? Where can I get it?
 Where can I ftp the code that accompanies “Numerical Recipes”?
 Why is my executable so large?
 Where can I get tons and tons of more information on C++ class libraries?
What is the “STL”?
STL (“Standard Templates Library”) is a library that consists mainly of (very efficient) container
classes, along with some iterators and algorithms to work with the contents of these containers.
Technically speaking the term “STL” is no longer meaningful since the classes provided by the STL
have been fully integrated into the standard library, along with other standard classes
like std::ostream, etc. Nonetheless many people still refer to the STL as if it were a separate
thing, so you might as well get used to hearing that term.
Where can I get a copy of “STL”?
Since the classes that were part of the STL have become part of the standard library, your compiler
should provide these classes. If your compiler doesn’t include these standard classes, either get an
updated version of your compiler or download a copy of the STL classes from one of the following:
 An STL site: ftp.cs.rpi.edu/pub/stl
 STL HP official site: butler.hpl.hp.com/stl/
 Mirror site in Europe: www.maths.warwick.ac.uk/ftp/mirrors/c++/stl/
 STL code alternate: ftp.cs.rpi.edu/stl
 The SGI implementation: www.sgi.com/tech/stl/
 STLport: www.stlport.org
STL hacks for GCC-2.6.3 are part of the GNU libg++ package 2.6.2.1 or later (and they may be in
an earlier version as well). Thanks to Mike Lindner.
Also you may as well get used to some people using “STL” to include the standard string
header, <string>, and others objecting to that usage.
How can I find a Fred object in an STL container
of Fred* such as std::vector<Fred*>?
STL functions such as std::find_if() help you find a T element in a container of T’s. But if you
have a container of pointers such as std::vector<Fred*>, these functions will enable you to find
an element that matches a given Fred* pointer, but they don’t let you find an element that matches
a given Fred object.
The solution is to use an optional parameter that specifies the “match” function. The following class
template lets you compare the objects on the other end of the dereferenced pointers.
1. template<typename T>
2. class DereferencedEqual {
3. public:
4. DereferencedEqual(const T* p) : p_(p) { }
5. bool operator() (const T* p2) const { return *p_ == *p2; }
6. private:
7. const T* p_;
8. };
Now you can use this template to find an appropriate Fred object:
1. void userCode(std::vector<Fred*> v, const Fred& match)
2. {
3. std::find_if(v.begin(), v.end(), DereferencedEqual<Fred>(&match));
4. // ...
5. }

Where can I get help on how to use STL?

Here are some resources (in random order):
Rogue Wave’s STL Guide:
www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibug/
index.html or stdcxx.apache.org/doc/stdlibug/index.html
The STL FAQ: butler.hpl.hp.com/stl/stl.faq
Kenny Zalewski’s STL guide: www.cs.rpi.edu/projects/STL/htdocs/stl.html
STL Newbie’s guide:
academic1.bellevue.edu/cpphome/stl/STL_newbie.html
SGI’s STL Programmer’s guide: www.sgi.com/tech/stl/
There are also some books that will help.
How can you tell if you have a dynamically typed C++
class library?
 Hint #1: when everything is derived from a single root class, usually Object.
 Hint #2: when the container classes (List, Stack, Set, etc) are non-templates.
 Hint #3: when the container classes (List, Stack, Set, etc) insert/extract elements as
pointers to Object. This lets you put an Apple into such a container, but when you get it out, the
compiler knows only that it is derived from Object, so you have to use a pointer cast to convert
it back to an Apple*; and you’d better pray a lot that it really is an Apple, cause your blood is on
your own head.
You can make the pointer cast “safe” by using dynamic_cast, but this dynamic testing is just that:
dynamic. This coding style is the essence of dynamic typing in C++. You call a function that says
“convert this Object into an Apple or give me NULL if its not an Apple,” and you’ve got dynamic
typing: you don’t know what will happen until run-time.
When you use templates to implement your containers, the C++ compiler can statically validate 90+
% of an application’s typing information (the figure “90+%” is apocryphal; some claim they always
get 100%, those who need persistence get something less than 100% static type checking). The
point is: C++ gets genericity from templates, not from inheritance.
What is the NIHCL? Where can I get it?
NIHCL stands for “National-Institute-of-Health’s-class-library.” It can be acquired
via 128.231.128.7/pub/NIHCL/nihcl-3.0.tar.Z
NIHCL (some people pronounce it “N-I-H-C-L,” others pronounce it like “nickel”) is a C++
translation of the Smalltalk class library. There are some ways where NIHCL’s use of dynamic
typing helps (e.g., persistent objects). There are also places where its use of dynamic typing
creates tension with the static typing of the C++ language.
Where can I ftp the code that accompanies “Numerical
Recipes”?
This software is sold and therefore it would be illegal to provide it on the net.
Note also that there are some fairly negative reviews of Numerical Recipes, such
as amath.colorado.edu/computing/Fortran/numrec.html.
Here are some other sources for numerical algorithms, listed alphabetically:
 Isaacson, E. and Keller, H., Analysis of Numerical Methods, Dover.
 Kahan, W., http.cs.berkeley.edu/~wkahan/.
 Knuth, Donald E., The Art of Computer Programming, Volume II: Seminumerical
Algorithms, Addison-Wesley, 1969.
 LAPACK: Linear Algebra Subroutine Library, www.siam.org
 NETLIB: the collected algorithms from ACM Transactions on Mathematical Software,
which have all been refereed, plus a great many other algorithms that have withstood somewhat
less formal scrutiny from peers, www.netlib.org
 Numerical Recipes, by Press et al. Although note some negative reviews, such
as amath.colorado.edu/computing/Fortran/numrec.html
 Ralston and Rabinowitz, A First Course in Numerical Analysis: Second Edition, Dover.
 Stoer, J. and Bulirsch, R., Introduction to Numerical Analysis, Springer Verlag, in German.
Why is my executable so large?
Many people are surprised by how big executables are, especially if the source code is trivial. For
example, a simple "hello world" program can generate an executable that is larger than most
people expect (40+K bytes).
One reason executables can be large is that portions of the C++ runtime library might get statically
linked with your program. How much gets linked in depends on compiler options regarding whether
to statically or dynamically link the standard libraries, on how much of it you are using, and on how
the implementer split up the library into pieces. For example, the <iostream> library is quite large,
and consists of numerous classes and virtual functions. Using any part of it might pull in nearly
all of the <iostream> code as a result of the interdependencies (however there might be a compiler
option to dynamically link these classes, in which case your program might be small).
Another reason executables can be large is if you have turned on debugging (again via a compiler
option). In at least one well known compiler, this option can increase the executable size by up to a
factor of 10.
You have to consult your compiler manuals or the vendor’s technical support for a more detailed
answer.

Where can I get tons and tons of more information on C++

class libraries?
Three places you should check (not necessarily in this order):
 The C++ Libraries FAQ is maintained by Nikki Locke and is available with
frames and without frames.
 Also you should check out www.mathtools.net/C_C__/. They have a good pile of stuff
organized into (at present) sixty-some categories.
 Also you should check out www.boost.org/. They have some wonderful stuff, some of
which will get proposed for standardization the next time around.
Important: none of these lists are exhaustive. If you are looking for some particular functionality
that you don’t find above, try a Web search such as Google. Also, don’t forget to help out the next
person via the Submission Form in the C++ Libraries FAQ.

Exceptions and Error Handling

Save to:
InstapaperPocketReadability
Contents of this section:
  Why use exceptions?
 How do I use exceptions?
 What shouldn’t I use exceptions for?
 What are some ways try / catch / throw can improve software quality?
 I’m still not convinced: a 4-line code snippet shows that return-codes aren’t any worse than
exceptions; why should I therefore use exceptions on an application that is orders of magnitude
larger?
 How do exceptions simplify my function return type and parameter types?
 What does it mean that exceptions separate the “good path” (or “happy path”) from the “bad
path”?
 I’m interpreting the previous FAQs as saying exception handling is easy and simple; did I get
it right?
 Exception handling seems to make my life more difficult; that must mean exception handling
itself is bad; clearly I’m not the problem, right??
 I have too many try blocks; what can I do about it?
 Can I throw an exception from a constructor? From a destructor?
 How can I handle a constructor that fails?
 How can I handle a destructor that fails?
 How should I handle resources if my constructors may throw exceptions?
 How do I change the string-length of an array of char to prevent memory leaks even if/when
someone throws an exception?
 What should I throw?
 What should I catch?
 But MFC seems to encourage the use of catch-by-pointer; should I do the same?
 What does throw; (without an exception object after the throw keyword) mean? Where
would I use it?
 How do I throw polymorphically?
 When I throw this object, how many times will it be copied?
 Why doesn’t C++ provide a “finally” construct?
 Why can’t I resume after catching an exception?
Why use exceptions?
What good can using exceptions do for me? The basic answer is: Using exceptions for error
handling makes your code simpler, cleaner, and less likely to miss errors. But what’s wrong with
“good old errno and if-statements”? The basic answer is: Using those, your error handling and
your normal code are closely intertwined. That way, your code gets messy and it becomes hard to
ensure that you have dealt with all errors (think “spaghetti code” or a “rat’s nest of tests”).
First of all there are things that just can’t be done right without exceptions. Consider an error
detected in a constructor; how do you report the error? You throw an exception. That’s the basis
of RAII (Resource Acquisition Is Initialization), which is the basis of some of the most effective
modern C++ design techniques: A constructor’s job is to establish the invariants for the class (create
the environment in which the member functions are to run) and that often requires the acquisition of
resources, such as memory, locks, files, sockets, etc.
Imagine that we did not have exceptions, how would you deal with an error detected in a
constructor? Remember that constructors are often invoked to initialize/construct objects in
variables:
1. vector<double> v(100000); // needs to allocate memory
2. ofstream os("myfile"); // needs to open a file
The vector or ofstream (output file stream) constructor could either set the variable into a “bad”
state (as ifstream does by default) so that every subsequent operation fails. That’s not ideal. For
 example, in the case of ofstream, your output simply disappears if you forget to check that the
open operation succeeded. For most classes that results are worse. At least, we would have to write:
1. vector<double> v(100000); // needs to allocate memory
2. if (v.bad()) { /* handle error */ } // vector doesn't actually have a bad(); it relies on exceptions
3. ofstream os("myfile"); // needs to open a file
4. if (os.bad()) { /* handle error */ }
That’s an extra test per object (to write, to remember or forget). This gets really messy for classes
composed of several objects, especially if those sub-objects depend on each other. For more
information see The C++ Programming Language section 8.3, Chapter 14, and Appendix E or the
(more academic) paper Exception safety: Concepts and techniques.
So writing constructors can be tricky without exceptions, but what about plain old functions? We
can either return an error code or set a non-local variable (e.g., errno). Setting a global variable
doesn’t work too well unless you test it immediately (or some other function might have re-set it).
Don’t even think of that technique if you might have multiple threads accessing the global variable.
The trouble with return values are that choosing the error return value can require cleverness and
can be impossible:
1. double d = my_sqrt(-1); // return -1 in case of error
2. if (d == -1) { /* handle error */ }
3. int x = my_negate(INT_MIN); // Duh?
There is no possible value for my_negate() to return: Every possible int is the correct answer for
some int and there is no correct answer for the most negative number in the twos-complement
representation. In such cases, we would need to return pairs of values (and as usual remember to
test) See Stroustrup’s Beginning programming book for more examples and explanations.
Common objections to the use of exceptions:
 “But exceptions are expensive!” Not really. Modern C++ implementations reduce the overhead
of using exceptions to a few percent (say, 3%) and that’s compared to no error handling. Writing
code with error-return codes and tests is not free either. As a rule of thumb, exception handling is
extremely cheap when you don’t throw an exception. It costs nothing on some implementations.
All the cost is incurred when you throw an exception: that is, “normal code” is faster than code
using error-return codes and tests. You incur cost only when you have an error.
 “But in JSF++ Stroustrup himself bans exceptions outright!” JSF++ is for hard-real time and
safety-critical applications (flight control software). If a computation takes too long someone may
die. For that reason, we have to guarantee response times, and we can’t – with the current level of
tool support – do that for exceptions. In that context, even free store allocation is banned!
Actually, the JSF++ recommendations for error handling simulate the use of exceptions in
anticipation of the day where we have the tools to do things right, i.e. using exceptions.
 “But throwing an exception from a constructor invoked by new causes a memory leak!” Nonsense!
That’s an old-wives’ tale caused by a bug in one compiler – and that bug was immediately fixed
over a decade ago.
How do I use exceptions?
See The C++ Programming Language section 8.3, Chapter 14, and Appendix E. The appendix
focuses on techniques for writing exception-safe code in demanding applications, and is not written
for novices.
In C++, exceptions are used to signal errors that cannot be handled locally, such as the failure to
acquire a resource in a constructor. For example:
1. class VectorInSpecialMemory {
2. int sz;
3. int* elem;
4. public:
5. VectorInSpecialMemory(int s)
6. : sz(s)
7. , elem(AllocateInSpecialMemory(s))
8. {
9. if (elem == nullptr)
10. throw std::bad_alloc();
11. }
12. ...
13. };
Do not use exceptions as simply another way to return a value from a function. Most users assume –
as the language definition encourages them to – that ** exception-handling code is error-handling
code **, and implementations are optimized to reflect that assumption.
A key technique is resource acquisition is initialization (sometimes abbreviated to RAII), which
uses classes with destructors to impose order on resource management. For example:
1. void fct(string s)
2. {
3. File_handle f(s,"r"); // File_handle's constructor opens the file called "s"
4. // use f
5. } // here File_handle's destructor closes the file
If the “use f” part of fct() throws an exception, the destructor is still invoked and the file is properly
closed. This contrasts to the common unsafe usage:
1. void old_fct(const char* s)
2. {
3. FILE* f = fopen(s,"r"); // open the file named "s"
4. // use f
5. fclose(f); // close the file
6. }
If the “use f” part of old_fct throws an exception – or simply does a return – the file isn’t closed.
In C programs, longjmp() is an additional hazard.
What shouldn’t I use exceptions for?
C++ exceptions are designed to support error handling.
 Use throw only to signal an error (which means specifically that the function couldn’t do
what it advertised, and establish its postconditions).
 Use catch only to specify error handling actions when you know you can handle an error
(possibly by translating it to another type and rethrowing an exception of that type, such as
catching a bad_alloc and rethrowing a no_space_for_file_buffers).
 Do not use throw to indicate a coding error in usage of a function. Use assert or other
mechanism to either send the process into a debugger or to crash the process and collect the crash
dump for the developer to debug.
 Do not use throw if you discover unexpected violation of an invariant of your component,
use assert or other mechanism to terminate the program. Throwing an exception will not cure
memory corruption and may lead to further corruption of important user data.
There are other uses of exceptions – popular in other languages – but not idiomatic in C++ and
deliberately not supported well by C++ implementations (those implementations are optimized
based on the assumption that exceptions are used for error handling).
In particular, do not use exceptions for control flow. throw is not simply an alternative way of
returning a value from a function (similar to return). Doing so will be slow and will confuse most
C++ programmers who are rightly used to seeing exceptions used only for error handling.
Similarly, throw is not a good way of getting out of a loop.
 What are some ways try / catch / throw can improve
software quality?
By eliminating one of the reasons for if statements.
The commonly used alternative to try / catch / throw is to return a return code (sometimes called
an error code) that the caller explicitly tests via some conditional statement such as if. For
example, printf(), scanf() and malloc() work this way: the caller is supposed to test the
return value to see if the function succeeded.
Although the return code technique is sometimes the most appropriate error handling technique,
there are some nasty side effects to adding unnecessary if statements:
 Degrade quality: It is well known that conditional statements are approximately ten times
more likely to contain errors than any other kind of statement. So all other things being equal, if
you can eliminate conditionals / conditional statements from your code, you will likely have more
robust code.
 Slow down time-to-market: Since conditional statements are branch points which are
related to the number of test cases that are needed for white-box testing, unnecessary conditional
statements increase the amount of time that needs to be devoted to testing. Basically if you don’t
exercise every branch point, there will be instructions in your code that will never have been
executed under test conditions until they are seen by your users/customers. That’s bad.
 Increase development cost: Bug finding, bug fixing, and testing are all increased by
unnecessary control flow complexity.
So compared to error reporting via return-codes and if, using try / catch / throw is likely to
result in code that has fewer bugs, is less expensive to develop, and has faster time-to-market. Of
course if your organization doesn’t have any experiential knowledge of try / catch / throw, you
might want to use it on a toy project first just to make sure you know what you’re doing — you
should always get used to a weapon on the firing range before you bring it to the front lines of a
shooting war.
I’m still not convinced: a 4-line code snippet shows that
return-codes aren’t any worse than exceptions; why
should I therefore use exceptions on an application that is
orders of magnitude larger?
Because exceptions scale better than return-codes.
The problem with a 4-line example is that it has only 4 lines. Give it 4,000 lines and you’ll see the
difference.
Here’s a classic 4-line example, first with exceptions:
1. try {
2. f();
3. // ...
4. } catch (std::exception& e) {
5. // ...code that handles the error...
6. }
Here’s the same example, this time using return-codes (rc stands for “return code”):
1. int rc = f();
2. if (rc == 0) {
3. // ...
4. } else {
5. // ...code that handles the error...
6. }
People point to those “toy” examples and say, “Exceptions don’t improve coding or testing or
maintenance cost in that; why should I therefore use them in a ‘real’ project?”
Reason: exceptions help you with real-world applications. You won’t likely see much if any benefit
on a toy example.
In the real world, the code that detects a problem must typically propagate error information back to
a different function that will handle the problem. This “error propagation” often needs to go through
dozens of functions — f1() calls f2() calls f3(), etc., and a problem is discovered way down
in f10() (or f100()). The information about the problem needs to get propagated all the way back
to f1(), because only f1() has enough context to actually know what should be done about the
problem. In an interactive app, f1() is typically up near the main event loop, but no matter what,
the code that detects the problem often isn’t the same as the code that handles the problem, and the
error information needs to get propagated through all the stack frames in between.
Exceptions make it easy to do this “error propagation”:
1. void f1()
2. {
3. try {
4. // ...
5. f2();
6. // ...
7. } catch (some_exception& e) {
8. // ...code that handles the error...
9. }
10. }
11.
12. void f2() { ...; f3(); ...; }
13. void f3() { ...; f4(); ...; }
14. void f4() { ...; f5(); ...; }
15. void f5() { ...; f6(); ...; }
16. void f6() { ...; f7(); ...; }
17. void f7() { ...; f8(); ...; }
18. void f8() { ...; f9(); ...; }
19. void f9() { ...; f10(); ...; }
20.
21. void f10()
22. {
23. // ...
24. if ( /*...some error condition...*/ )
25. throw some_exception();
26. // ...
27. }
Only the code that detects the error, f10(), and the code that handles the error, f1(), have any
clutter.
However using return-codes forces “error propagation clutter” into all the functions in between
those two. Here is the equivalent code that uses return codes:
1. int f1()
2. {
3. // ...
4. int rc = f2();
5. if (rc == 0) {
6. // ...
7. } else {
8. // ...code that handles the error...
9. }
10. }
11.
12. int f2()
13. {
14. // ...
15. int rc = f3();
16. if (rc != 0)
17. return rc;
18. // ...
19. return 0;
20. }
21.
22. int f3()
23. {
24. // ...
25. int rc = f4();
26. if (rc != 0)
27. return rc;
28. // ...
29. return 0;
30. }
31.
32. int f4()
33. {
34. // ...
35. int rc = f5();
36. if (rc != 0)
37. return rc;
38. // ...
39. return 0;
40. }
41.
42. int f5()
43. {
44. // ...
45. int rc = f6();
46. if (rc != 0)
47. return rc;
48. // ...
49. return 0;
50. }
51.
52. int f6()
53. {
54. // ...
55. int rc = f7();
56. if (rc != 0)
57. return rc;
58. // ...
59. return 0;
60. }
61.
62. int f7()
63. {
64. // ...
65. int rc = f8();
66. if (rc != 0)
67. return rc;
68. // ...
69. return 0;
70. }
71.
72. int f8()
73. {
74. // ...
75. int rc = f9();
76. if (rc != 0)
77. return rc;
78. // ...
79. return 0;
80. }
81.
82. int f9()
83. {
84. // ...
85. int rc = f10();
86. if (rc != 0)
87. return rc;
88. // ...
89. return 0;
90. }
91.
92. int f10()
93. {
94. // ...
95. if (...some error condition...)
96. return some_nonzero_error_code;
97. // ...
98. return 0;
99. }
The return-code solution “spreads out” the error logic. Functions f2() through f9() have explicit,
hand-written code related to propagating the error condition back up to f1(). That is badness:
 It clutters functions f2() through f9() with extra decision logic — the most common cause
of bugs.
 It increases the bulk of the code.
 It clouds the simplicity of the programming logic in functions f2() through f9().
 It requires the return value to perform two distinct duties —
functions f2() through f10() will need to handle both “my function succeeded and the result
is xxx” and “my function failed and the error information is yyy”. When the types
of xxx and yyy differ, you sometimes need extra by-reference parameters to propagate both the
“successful” and “unsuccessful” cases to the caller.
If you look very narrowly at f1() and f10() in the above examples, exceptions won’t give you
much of an improvement. But if you instead open your eyes to the big picture, you will see a
substantial difference in all the functions in between.
Conclusion: one of the benefits of exception handling is a cleaner, simpler way to propagate error
information back to the caller that can handle the error. Another benefit is your function doesn’t
need extra machinery to propagate both the “successful” and “unsuccessful” cases back to the caller.
Toy examples often don’t emphasize either error propagation or handling of the two-return-types
problem, therefore they don’t represent Real World code.
 How do exceptions simplify my function return type and
parameter types?
When you use return codes, you often need two or more distinct return values: one to indicate that
the function succeeded and to give the computed result, and another to propagate the error
information back to the caller. If there are, say, 5 ways the function could fail, you could need as
many as 6 different return values: the “successful computation” return value, and a possibly
different package of bits for each of the 5 error cases.
Let’s simplify it down to two cases:
 “I succeeded and the result is xxx.”
 “I failed and the error information is yyy.”
Let’s work a simple example: we would like to create a Number class that supports the four
arithmetic operations: add, subtract, multiply and divide. This is an obvious place for overloaded
operators, so let’s define them:
1. class Number {
2. public:
3. friend Number operator+ (const Number& x, const Number& y);
4. friend Number operator- (const Number& x, const Number& y);
5. friend Number operator* (const Number& x, const Number& y);
6. friend Number operator/ (const Number& x, const Number& y);
7. // ...
8. };
It’s very easy to use:
1. void f(Number x, Number y)
2. {
3. // ...
4. Number sum = x + y;
5. Number diff = x - y;
6. Number prod = x * y;
7. Number quot = x / y;
8. // ...
9. }
But then we have a problem: handling errors. Adding numbers could cause overflow, dividing could
cause divide-by-zero or underflow, etc. Whoops. How can we report both the “I succeeded and the
result is xxx” as well as “I failed and the error information is yyy”?
If we use exceptions, it’s easy. Think of exceptions as a separate return type that gets used only
when needed. So we just define all the exceptions and throw them when needed:
1. void f(Number x, Number y)
2. {
3. try {
4. // ...
5. Number sum = x + y;
6. Number diff = x - y;
7. Number prod = x * y;
8. Number quot = x / y;
9. // ...
10. }
11. catch (Number::Overflow& exception) {
12. // ...code that handles overflow...
13. }
14. catch (Number::Underflow& exception) {
15. // ...code that handles underflow...
16. }
17. catch (Number::DivideByZero& exception) {
18. // ...code that handles divide-by-zero...
19. }
20. }
But if we use return codes instead of exceptions, life gets hard and messy. When you can’t shove
both the “good” number and the error information (including details about what went wrong) inside
the Number object, you will probably end up using extra by-reference parameters to handle one of
the two cases: either “I succeeded” or “I failed” or both. Without loss of generality, I will handle the
computed result via a normal return value and the “I failed” case via a by-reference parameter, but
you can just as easily do the opposite. Here’s the result:
1. class Number {
2. public:
3. enum ReturnCode {
4. Success,
5. Overflow,
6. Underflow,
7. DivideByZero
8. };
9.
10. Number add(const Number& y, ReturnCode& rc) const;
11. Number sub(const Number& y, ReturnCode& rc) const;
12. Number mul(const Number& y, ReturnCode& rc) const;
13. Number div(const Number& y, ReturnCode& rc) const;
14. // ...
15. };
Now here’s how to use it — this code is equivalent to the above:
1. int f(Number x, Number y)
2. {
3. // ...
4.
5. Number::ReturnCode rc;
6. Number sum = x.add(y, rc);
7. if (rc == Number::Overflow) {
8. // ...code that handles overflow...
9. return -1;
10. } else if (rc == Number::Underflow) {
11. // ...code that handles underflow...
12. return -1;
13. } else if (rc == Number::DivideByZero) {
14. // ...code that handles divide-by-zero...
15. return -1;
16. }
17.
18. Number diff = x.sub(y, rc);
19. if (rc == Number::Overflow) {
20. // ...code that handles overflow...
21. return -1;
22. } else if (rc == Number::Underflow) {
23. // ...code that handles underflow...
24. return -1;
25. } else if (rc == Number::DivideByZero) {
26. // ...code that handles divide-by-zero...
27. return -1;
28. }
29.
30. Number prod = x.mul(y, rc);
31. if (rc == Number::Overflow) {
32. // ...code that handles overflow...
33. return -1;
34. } else if (rc == Number::Underflow) {
35. // ...code that handles underflow...
36. return -1;
37. } else if (rc == Number::DivideByZero) {
38. // ...code that handles divide-by-zero...
39. return -1;
40. }
41.
42. Number quot = x.div(y, rc);
43. if (rc == Number::Overflow) {
44. // ...code that handles overflow...
45. return -1;
46. } else if (rc == Number::Underflow) {
47. // ...code that handles underflow...
48. return -1;
49. } else if (rc == Number::DivideByZero) {
50. // ...code that handles divide-by-zero...
51. return -1;
52. }
53.
54. // ...
55. }
The point of this is that you normally have to muck up the interface of functions that use return
codes, particularly if there is more error information to propagate back to the caller. For example, if
there are 5 error conditions and the “error information” requires different data structures, you might
end up with a fairly messy function interface.
None of this clutter happens with exceptions. Exceptions can be thought of as a separate return
value, as if the function automatically “grows” new return types and return values based on what the
function can throw.
Note: Please don’t write me saying that you propose using return codes and storing the error
information in a namespace-scope, global or static variable, such as Number::lastError(). That
isn’t thread-safe. Even if you don’t have multiple threads today, you rarely want to permanently
prevent anyone in the future from using your class with multiple threads. Certainly if you do, you
should write lots and lots of BIG UGLY COMMENTS warning future programmers that your code
is not thread-safe, and that it probably can’t be made thread-safe without a substantial rewrite.
What does it mean that exceptions separate the “good
path” (or “happy path”) from the “bad path”?
It’s another benefit of exceptions over return-codes.
The “good path” (sometimes called the “happy path”) is the control-flow path that happens when
everything goes well — when there are no problems.
The “bad path” (or “error path”) is the path that control-flow takes when something goes wrong —
when there is a problem.
Exceptions, when done right, separate the happy path from the error path.
 Here is a simple example: function f() is suppoesd to call functions g(), h(), i() and j(), in
sequence, as shown below. If any of those fail with a “foo” or “bar” error, f() is to handle the error
immediately then return successfully. If any other error occurs, f() is to propagate the error
information back to the caller.
Here is the code if exceptions are used:
1. void f() // Using exceptions
2. {
3. try {
4. GResult gg = g();
5. HResult hh = h();
6. IResult ii = i();
7. JResult jj = j();
8. // ...
9. }
10. catch (FooError& e) {
11. // ...code that handles "foo" errors...
12. }
13. catch (BarError& e) {
14. // ...code that handles "bar" errors...
15. }
16. }
The “good” path and the “bad” path are cleanly separated. The “good” (or “happy”) path is the body
of the try block — you can read that linearly, and if there are no errors, control flows in a
simplistic path through those lines. The “bad” path is the body of the catch block and the body of
any matching catch blocks in any caller.
Using return codes instead of exception clutters this to the point where it is difficult to see the
relatively simple algorithm. The “good” (“happy”) and “bad” paths are hopelessly intermixed:
1. int f() // Using return-codes
2. {
3. int rc; // "rc" stands for "return code"
4.
5. GResult gg = g(rc);
6. if (rc == FooError) {
7. // ...code that handles "foo" errors...
8. } else if (rc == BarError) {
9. // ...code that handles "bar" errors...
10. } else if (rc != Success) {
11. return rc;
12. }
13.
14. HResult hh = h(rc);
15. if (rc == FooError) {
16. // ...code that handles "foo" errors...
17. } else if (rc == BarError) {
18. // ...code that handles "bar" errors...
19. } else if (rc != Success) {
20. return rc;
21. }
22.
23. IResult ii = i(rc);
24. if (rc == FooError) {
25. // ...code that handles "foo" errors...
26. } else if (rc == BarError) {
27. // ...code that handles "bar" errors...
28. } else if (rc != Success) {
29. return rc;
30. }
31.
32. JResult jj = j(rc);
33. if (rc == FooError) {
34. // ...code that handles "foo" errors...
35. } else if (rc == BarError) {
36. // ...code that handles "bar" errors...
37. } else if (rc != Success) {
38. return rc;
39. }
40.
41. // ...
42.
43. return Success;
44. }
By intermixing the good/happy path with the bad/error path, it’s harder to see what the code is
supposed to do. Contrast that with the version that used exceptions, which is almost self-
documenting — the basic functionality is very obvious.

I’m interpreting the previous FAQs as saying exception

handling is easy and simple; did I get it right?
No! Wrong! Stop! Go back! Do not collect $200.
The message isn’t that exception handling is easy and simple. The message is that exception
handling is worth it. The benefits outweigh the costs.
Here are some of the costs:
 Exception handling is not a free lunch. It requires discipline and rigor. To understand those
disciplines, you really should read the rest of the FAQ and/or one of the excellent books on the
subject.
 Exception handling is not a panacea. If you work with a team that is sloppy and
undisciplined, your team will likely have problems no matter whether they use exceptions or
return codes. Incompetent carpenters do bad work even if they use a good hammer.
 Exception handling is not one-size-fits-all. Even when you have decided to use exceptions
rather than return codes, that doesn’t mean you use them for everything. This is part of the
discipline: you need to know when a condition should be reported via return-code and when it
should be reported via an exception.
 Exception handling is a convenient whipping boy. If you work with people who blame
their tools, beware of suggesting exceptions (or anything else that is new, for that matter). People
whose ego is so fragile that they need to blame someone or something else for their screw-ups
will invariably blame whatever “new” technology was used. Of course, ideally you will work with
people who are emotionally capable of learning and growing: with them, you can make all sorts
of suggestions, because those sorts of people will find a way to make it work, and you’ll have fun
in the process.
Fortunately there is plenty of wisdom and insight on the proper use of exceptions. Exception
handling is not new. The industry as a whole has seen many millions of lines of code and many
person-centuries of effort using exceptions. The jury has returned its verdict: exceptions can be used
properly, and when they are used properly, they improve code.
Learn how.
Exception handling seems to make my life more difficult;
that must mean exception handling itself is bad;
clearly I’m not the problem, right??
You absolutely might be the problem!
The C++ exception handling mechanism can be powerful and useful, but if you have the wrong
mindset, the result can be a mess. It’s a tool; use it properly and it will help you; but don’t blame the
tool if you use it improperly.
If you’re getting bad results, for instance, if your code seems unnecessarily convoluted or overly
cluttered with try blocks, you might be suffering from a wrong mindset. This FAQ gives you a list
of some of those wrong mindsets.
Warning: do not be simplistic about these “wrong mindsets.” They are guidelines and ways of
thinking, not hard and fast rules. Sometimes you will do the exact opposite of what they recommend
— do not write me about some situation that is an exception (no pun intended) to one or more of
them — I guarantee that there are exceptions. That’s not the point.
Here are some “wrong exception-handling mindsets” in no apparent order:
 The return-codes mindset: This causes programmers to clutter their code with gobs
of try blocks. Basically they think of a throw as a glorified return code, and a try/catch as a
glorified “if the return code indicates an error” test, and they put one of these try blocks around
just about every function that can throw.
 The Java mindset: In Java, non-memory resources are reclaimed via
explicit try/finally blocks. When this mindset is used in C++, it results in a large number of
unnecessary try blocks, which, compared with RAII, clutters the code and makes the logic
harder to follow. Essentially the code swaps back and forth between the “good path” and the “bad
path” (the latter meaning the path taken during an exception). With RAII, the code is mostly
optimistic — it’s all the “good path,” and the cleanup code is buried in destructors of the
resource-owning objects. This also helps reduce the cost of code reviews and unit-testing, since
these “resource-owning objects” can be validated in isolation (with explicit try/catch blocks,
each copy must be unit-tested and inspected individually; they cannot be handled as a group).
 Organizing the exception classes around the physical thrower rather than the logical
reason for the throw: For example, in a banking app, suppose any of five subsystems might
throw an exception when the customer has insufficient funds. The right approach is to throw an
exception representing the reason for the throw, e.g., an “insufficient funds exception”; the wrong
mindset is for each subsystem to throw a subsystem-specific exception. For example,
the Foo subsystem might throw objects of class FooException, the Bar subsystem might throw
objects of class BarException, etc. This often leads to extra try/catch blocks, e.g., to catch
a FooException, repackage it into a BarException, then throw the latter. In general,
exception classes should represent the problem, not the chunk of code that noticed the problem.
 Using the bits / data within an exception object to differentiate different categories of
errors: Suppose the Foo subsystem in our banking app throws exceptions for bad account
numbers, for attempting to liquidate an illiquid asset, and for insufficient funds. When these three
logically distinct kinds of errors are represented by the same exception class, the catchers need to
say if to figure out what the problem really was. If your code wants to handle only bad account
numbers, you need to catch the master exception class, then use if to determine whether it is
one you really want to handle, and if not, to rethrow it. In general, the preferred approach is for
the error condition’s logical category to get encoded into the type of the exception object, not into
the data of the exception object.
  Designing exception classes on a subsystem by subsystem basis: In the bad old days, the
specific meaning of any given return-code was local to a given function or API. Just because one
function uses the return-code of 3 to mean “success,” it was still perfectly acceptable for another
function to use 3 to mean something entirely different, e.g., “failed due to out of memory.”
Consistency has always been preferred, but often that didn’t happen because it didn’t need to
happen. People coming with that mentality often treat C++ exception-handling the same way:
they assume exception classes can be localized to a subsystem. That causes no end of grief, e.g.,
lots of extra try blocks to catch then throw a repackaged variant of the same exception. In
large systems, exception hierarchies must be designed with a system-wide mindset. Exception
classes cross subsystem boundaries — they are part of the intellectual glue that holds the
architecture together.
 Use of raw (as opposed to smart) pointers: This is actually just a special case of non-RAII
coding, but I’m calling it out because it is so common. The result of using raw pointers is, as
above, lots of extra try/catch blocks whose only purpose in life is to delete an object then re-
throw the exception.
 Confusing logical errors with runtime situations: For example, suppose you have a
function f(Foo* p) that must never be called with nullptr. However you discover that
somebody somewhere is sometimes passing nullptr anyway. There are two possibilities: either
they are passing nullptr because they got bad data from an external user (for example, the user
forgot to fill in a field and that ultimately resulted in a nullptr) or they just plain made a mistake in
their own code. In the former case, you should throw an exception since it is a runtime situation
(i.e., something you can’t detect by a careful code-review; it is not a bug). In the latter case, you
should definitely fix the bug in the caller’s code. You can still add some code to write a message
in the log-file if it ever happens again, and you can even throw an exception if it ever happens
again, but you must not merely change the code within f(Foo* p); you must, must, MUST fix the
code in the caller(s) of f(Foo* p).
There are other “wrong exception-handling mindsets,” but hopefully those will help you out. And
remember: don’t take those as hard and fast rules. They are guidelines, and there are exceptions to
each.

I have too many try blocks; what can I do about it?

You might have the mindset of return codes even though you are using
the syntax of try/catch/throw. For instance, you might put a try block around just about every
call:
1. void myCode()
2. {
3. try {
4. foo();
5. }
6. catch (FooException& e) {
7. // ...
8. }
9.
10. try {
11. bar();
12. }
13. catch (BarException& e) {
14. // ...
15. }
16.
17. try {
18. baz();
19. }
20. catch (BazException& e) {
21. // ...
22. }
23. }
Although this uses the try/catch/throw syntax, the overall structure is very similar to the way
things are done with return codes, and the consequent software development/test/maintenance costs
are basically the same as they were for return codes. In other words, this approach doesn’t buy you
much over using return codes. In general, it is bad form.
One way out is to ask yourself this question for each try block: “Why am I using a try block here?”
There are several possible answers:
 Your answer might be, “So I can actually handle the exception. My catch clause deals with
the error and continues execution without throwing any additional exceptions. My caller never
knows that the exception occurred. My catch clause does not throw any exceptions and it does not
return any error-codes.” In that case, you leave the try block as-is — it is probably good.
 Your answer might be, “So I can have a catch clause that does blah blah blah, after which I
will rethrow the exception.” In this case, consider changing the try block into an object whose
destructor does blah blah blah. For instance, if you have a try block whose catch clause closes a
file then rethrows the exception, consider replacing the whole thing with a File object whose
destructor closes the file. This is commonly called RAII.
 Your answer might be, “So I can repackage the exception: I catch a XyzException, extract
the details, then throw a PqrException.” When that happens, consider a better hierarchy of
exception objects that doesn’t require this catch/repackage/rethrow idea. This often involves
broadening the meaning of XyzException, though obviously you shouldn’t go too far.
 There are other answers as well, but the above are some common ones that I’ve seen.
Main point is to ask “Why?”. If you discover the reason you’re doing it, you might find that there
are better ways to achieve your goal.
Having said all this, there are, unfortunately, some people who have the return-code-mindset burned
so deeply into their psyche that they just can’t seem to see any alternatives. If that is you, there is
still hope: get a mentor. If you see it done right, you’ll probably get it. Style is sometimes caught,
not just taught.
Can I throw an exception from a constructor? From a
destructor?
 For constructors, yes: You should throw an exception from a constructor whenever you
cannot properly initialize (construct) an object. There is no really satisfactory alternative to
exiting a constructor by a throw. For more details, see here.
 For destructors, not really: You can throw an exception in a destructor, but that exception
must not leave the destructor; if a destructor exits by emitting an exception, all kinds of bad things
are likely to happen because the basic rules of the standard library and the language itself will be
violated. Don’t do it. For more details, see here.
For examples and detailed explanations, see Appendix E of TC++PL3e.
There is a caveat: Exceptions can’t be used for some hard-real time projects. For example, see the
JSF air vehicle C++ coding standards.
How can I handle a constructor that fails?
Throw an exception.
Constructors don’t have a return type, so it’s not possible to use return codes. The best way to signal
constructor failure is therefore to throw an exception. If you don’t have the option of using
 exceptions, the “least bad” work-around is to put the object into a “zombie” state by setting an
internal status bit so the object acts sort of like it’s dead even though it is technically still alive.
The idea of a “zombie” object has a lot of down-side. You need to add a query (“inspector”)
member function to check this “zombie” bit so users of your class can find out if their object is truly
alive, or if it’s a zombie (i.e., a “living dead” object), and just about every place you construct one
of your objects (including within a larger object or an array of objects) you need to check that status
flag via an if statement. You’ll also want to add an if to your other member functions: if the
object is a zombie, do a no-op or perhaps something more obnoxious.
In practice the “zombie” thing gets pretty ugly. Certainly you should prefer exceptions over zombie
objects, but if you do not have the option of using exceptions, zombie objects might be the “least
bad” alternative.
Note: if a constructor finishes by throwing an exception, the memory associated with the object
itself is cleaned up — there is no memory leak. For example:
1. void f()
2. {
3. X x; // If X::X() throws, the memory for x itself will not leak
4. Y* p = new Y(); // If Y::Y() throws, the memory for *p itself will not leak
5. }
There is some fine print on this topic, so you need to keep reading. Specifically you need to
know how to prevent memory leaks if the constructor itself allocates memory, and you also need to
be aware of what happens if you use “placement” new rather than the ordinary new used in the
sample code above.
How can I handle a destructor that fails?
Write a message to a log-file. Terminate the process. Or call Aunt Tilda. But do not throw an
exception!
Here’s why (buckle your seat-belts):
The C++ rule is that you must never throw an exception from a destructor that is being called during
the “stack unwinding” process of another exception. For example, if someone says throw Foo(),
the stack will be unwound so all the stack frames between the
1. throw Foo()
and the
1. }
2. catch (Foo e)
3. {
will get popped. This is called stack unwinding.
During stack unwinding, all the local objects in all those stack frames are destructed. If one
of those destructors throws an exception (say it throws a Bar object), the C++ runtime system is in a
no-win situation: should it ignore the Bar and end up in the
1. }
2. catch (Foo e)
3. {
where it was originally headed? Should it ignore the Foo and look for a
1. }
2. catch (Bar e)
3. {
handler? There is no good answer — either choice loses information.
So the C++ language guarantees that it will call terminate() at this point,
and terminate() kills the process. Bang you’re dead.
 The easy way to prevent this is never throw an exception from a destructor. But if you really want to be
clever, you can say never throw an exception from a destructor while processing another exception. But
in this second case, you’re in a difficult situation: the destructor itself needs code to handle both
throwing an exception and doing “something else”, and the caller has no guarantees as to what
might happen when the destructor detects an error (it might throw an exception, it might do
“something else”). So the whole solution is harder to write. So the easy thing to do is always do
“something else”. That is, never throw an exception from a destructor.
Of course the word never should be “in quotes” since there is always some situation somewhere
where the rule won’t hold. But certainly at least 99% of the time this is a good rule of thumb.
How should I handle resources if my constructors may
throw exceptions?
Every data member inside your object should clean up its own mess.
If a constructor throws an exception, the object’s destructor is not run. If your object has already
done something that needs to be undone (such as allocating some memory, opening a file, or
locking a semaphore), this “stuff that needs to be undone” must be remembered by a data member
inside the object.
For example, rather than allocating memory into a raw Fred* data member, put the allocated
memory into a “smart pointer” member object, and the destructor of this smart pointer
will delete the Fred object when the smart pointer dies. The template std::unique_ptr is an
example of such as “smart pointer.” You can also write your own reference counting smart pointer.
You can also use smart pointers to “point” to disk records or objects on other machines.
By the way, if you think your Fred class is going to be allocated into a smart pointer, be nice to
your users and create a typedef within your Fred class:
1. #include <memory>
2.
3. class Fred {
4. public:
5. typedef std::unique_ptr<Fred> Ptr;
6. // ...
7. };
That typedef simplifies the syntax of all the code that uses your objects: your users can
say Fred::Ptr instead of std::unique_ptr<Fred>:
1. #include "Fred.h"
2.
3. void f(std::unique_ptr<Fred> p); // explicit but verbose
4. void f(Fred::Ptr p); // simpler
5.
6. void g()
7. {
8. std::unique_ptr<Fred> p1( new Fred() ); // explicit but verbose
9. Fred::Ptr p2( new Fred() ); // simpler
10. // ...
11. }

How do I change the string-length of an array of char to

prevent memory leaks even if/when someone throws an
exception?
If what you really want to do is work with strings, don’t use an array of char in the first place,
since arrays are evil. Instead use an object of some string-like class.
 For example, suppose you want to get a copy of a string, fiddle with the copy, then append another
string to the end of the fiddled copy. The array-of-char approach would look something like this:
1. void userCode(const char* s1, const char* s2)
2. {
3. char* copy = new char[strlen(s1) + 1]; // make a copy
4. strcpy(copy, s1); // of s1...
5.
6. // use a try block to prevent memory leaks if we get an exception
7. // note: we need the try block because we used a "dumb" char* above
8. try {
9.
10. // ...code that fiddles with copy...
11.
12. char* copy2 = new char[strlen(copy) + strlen(s2) + 1]; // append s2
13. strcpy(copy2, copy); // onto the
14. strcpy(copy2 + strlen(copy), s2); // end of
15. delete[] copy; // copy...
16. copy = copy2;
17.
18. // ...code that fiddles with copy again...
19.
20. }
21. catch (...) {
22. delete[] copy; // we got an exception; prevent a memory leak
23. throw; // re-throw the current exception
24. }
25.
26. delete[] copy; // we did not get an exception; prevent a memory leak
27. }
Using char*s like this is tedious and error prone. Why not just use an object of
some string class? Your compiler probably supplies a string-like class, and it’s probably just as
fast and certainly it’s a lot simpler and safer than the char* code that you would have to write
yourself. For example, if you’re using the std::string class from the standardization committee,
your code might look something like this:
1. #include <string> // Let the compiler see std::string
2.
3. void userCode(const std::string& s1, const std::string& s2)
4. {
5. std::string copy = s1; // make a copy of s1
6. // ...code that fiddles with copy...
7. copy += s2; // append s2 onto the end of copy
8. // ...code that fiddles with copy again...
9. }
The char* version requires you to write around three times more code than you would have to
write with the std::string version. Most of the savings came from std::string’s automatic
memory management: in the std::string version, we didn’t need to write any code…
 to reallocate memory when we grow the string.
 to delete[] anything at the end of the function.
 to catch and re-throw any exceptions.
What should I throw?
C++, unlike just about every other language with exceptions, is very accomodating when it comes to
what you can throw. In fact, you can throw anything you like. That begs the question then, what
should you throw?
 Generally, it’s best to throw objects, not built-ins. If possible, you should throw instances of classes
that derive (ultimately) from the std::exception class. By making your exception class inherit
(ultimately) from the standard exception base-class, you are making life easier for your users (they
have the option of catching most things via std::exception), plus you are probably providing
them with more information (such as the fact that your particular exception might be a refinement
of std::runtime_error or whatever).
The most common practice is to throw a temporary:
1. #include <stdexcept>
2.
3. class MyException : public std::runtime_error {
4. public:
5. MyException() : std::runtime_error("MyException") { }
6. };
7.
8. void f()
9. {
10. // ...
11. throw MyException();
12. }
Here, a temporary of type MyException is created and thrown. Class MyException inherits from
class std::runtime_error which (ultimately) inherits from class std::exception.
What should I catch?
In keeping with the C++ tradition of “there’s more than one way to do that” (translation: “give
programmers options and tradeoffs so they can decide what’s best for them in their situation”), C++
allows you a variety of options for catching.
 You can catch by value.
 You can catch by reference.
 You can catch by pointer.
In fact, you have all the flexibility that you have in declaring function parameters, and the rules for
whether a particular exception matches (i.e., will be caught by) a particular catch clause are almost
exactly the same as the rules for parameter compatibility when calling a function.
Given all this flexibility, how do you decide what to catch? Simple: unless there’s a good reason not
to, catch by reference. Avoid catching by value, since that causes a copy to be made and the copy
can have different behavior from what was thrown. Only under very special circumstances should
you catch by pointer.
But MFC seems to encourage the use of catch-by-pointer;
should I do the same?
Depends. If you’re using MFC and catching one of their exceptions, by all means, do it their way.
Same goes for any framework: when in Rome, do as the Romans. Don’t try to force a framework
into your way of thinking, even if “your” way of thinking is “better.” If you decide to use a
framework, embrace its way of thinking — use the idioms that its authors expected you to use.
But if you’re creating your own framework and/or a piece of the system that does not directly
depend on MFC, then don’t catch by pointer just because MFC does it that way. When you’re not in
Rome, you don’t necessarily do as the Romans. In this case, you should not. Libraries like MFC
predated the standardization of exception handling in the C++ language, and some of these libraries
use a backwards-compatible form of exception handling that requires (or at least encourages) you to
catch by pointer.
The problem with catching by pointer is that it’s not clear who (if anyone) is responsible for
deleting the pointed-to object. For example, consider the following:
1. MyException x;
2.
3. void f()
4. {
5. MyException y;
6.
7. try {
8. switch ((rand() >> 8) % 3) { // the ">> 8" (typically) improves the period of the lowest 2 bits
9. case 0: throw new MyException;
10. case 1: throw &x;
11. case 2: throw &y;
12. }
13. }
14. catch (MyException* p) {
15. // should we delete p here or not???!?
16. }
17. }
There are three basic problems here:
1. It might be tough to decide whether to delete p within the catch clause. For example, if
object x is inaccessible to the scope of the catch clause, such as when it’s buried in the private
part of some class or is static within some other compilation unit, it might be tough to figure
out what to do.
2. If you solve the first problem by consistently using new in the throw (and therefore
consistently using delete in the catch), then exceptions always use the heap which can cause
problems when the exception was thrown because the system was running low on memory.
3. If you solve the first problem by consistently not using new in the throw (and therefore
consistently not using delete in the catch), then you probably won’t be able to allocate your
exception objects as locals (since then they might get destructed too early), in which case you’ll
have to worry about thread-safety, locks, semaphores, etc. (static objects are not intrinsically
thread-safe).
This isn’t to say it’s not possible to work through these issues. The point is simply this: if you catch
by reference rather than by pointer, life is easier. Why make life hard when you don’t have to?
The moral: avoid throwing pointer expressions, and avoid catching by pointer, unless you’re using
an existing library that “wants” you to do so.
What does throw; (without an exception object after
the throw keyword) mean? Where would I use it?
You might see code that looks something like this:
1. class MyException {
2. public:
3. // ...
4. void addInfo(const std::string& info);
5. // ...
6. };
7.
8. void f()
9. {
10. try {
11. // ...
12. }
13. catch (MyException& e) {
14. e.addInfo("f() failed");
15. throw;
16. }
17. }
In this example, the statement throw; means “re-throw the current exception.” Here, a function
caught an exception (by non-const reference), modified the exception (by adding information to it),
and then re-threw the exception. This idiom can be used to implement a simple form of stack-trace,
by adding appropriate catch clauses in the important functions of your program.
Another re-throwing idiom is the “exception dispatcher”:
1. void handleException()
2. {
3. try {
4. throw;
5. }
6. catch (MyException& e) {
7. // ...code to handle MyException...
8. }
9. catch (YourException& e) {
10. // ...code to handle YourException...
11. }
12. }
13.
14. void f()
15. {
16. try {
17. // ...something that might throw...
18. }
19. catch (...) {
20. handleException();
21. }
22. }
This idiom allows a single function (handleException()) to be re-used to handle exceptions in a
number of other functions.
How do I throw polymorphically?
Sometimes people write code like:
1. class MyExceptionBase { };
2.
3. class MyExceptionDerived : public MyExceptionBase { };
4.
5. void f(MyExceptionBase& e)
6. {
7. // ...
8. throw e;
9. }
10.
11. void g()
12. {
13. MyExceptionDerived e;
14. try {
15. f(e);
16. }
17. catch (MyExceptionDerived& e) {
18. // ...code to handle MyExceptionDerived...
19. }
20. catch (...) {
21. // ...code to handle other exceptions...
22. }
23. }
If you try this, you might be surprised at run-time when your catch (...) clause is entered, and
not your catch (MyExceptionDerived&) clause. This happens because you didn’t throw
polymorphically. In function f(), the statement throw e; throws an object with the same type as
the static type of the expression e. In other words, it throws an instance of MyExceptionBase.
The throw statement behaves as-if the thrown object is copied, as opposed to making a “virtual
copy”.
Fortunately it’s relatively easy to correct:
1. class MyExceptionBase {
2. public:
3. virtual void raise();
4. };
5.
6. void MyExceptionBase::raise()
7. { throw *this; }
8.
9. class MyExceptionDerived : public MyExceptionBase {
10. public:
11. virtual void raise();
12. };
13.
14. void MyExceptionDerived::raise()
15. { throw *this; }
16.
17. void f(MyExceptionBase& e)
18. {
19. // ...
20. e.raise();
21. }
22.
23. void g()
24. {
25. MyExceptionDerived e;
26. try {
27. f(e);
28. }
29. catch (MyExceptionDerived& e) {
30. // ...code to handle MyExceptionDerived...
31. }
32. catch (...) {
33. // ...code to handle other exceptions...
34. }
35. }
Note that the throw statement has been moved into a virtual function. The
statement e.raise() will exhibit polymorphic behavior, since raise() is
declared virtual and e was passed by reference. As before, the thrown object will be of
the static type of the argument in the throw statement, but
within MyExceptionDerived::raise(), that static type is MyExceptionDerived,
not MyExceptionBase.
When I throw this object, how many times will it be
copied?
 Depends. Might be “zero.”
Objects that are thrown must have a publicly accessible copy-constructor. The compiler is allowed
to generate code that copies the thrown object any number of times, including zero. However even if
the compiler never actually copies the thrown object, it must make sure the exception class’s copy
constructor exists and is accessible.

Why doesn’t C++ provide a “finally” construct?

Because C++ supports an alternative that is almost always better: The “resource acquisition is
initialization” technique. The basic idea is to represent a resource by a local object, so that the local
object’s destructor will release the resource. That way, the programmer cannot forget to release the
resource. For example:
1. // wrap a raw C file handle and put the resource acquisition and release
2. // in the C++ type's constructor and destructor, respectively
3. class File_handle {
4. FILE* p;
5. public:
6. File_handle(const char* n, const char* a)
7. { p = fopen(n,a); if (p==0) throw Open_error(errno); }
8. File_handle(FILE* pp)
9. { p = pp; if (p==0) throw Open_error(errno); }
10.
11. ~File_handle() { fclose(p); }
12.
13. operator FILE*() { return p; } // if desired
14.
15. // ...
16. };
17.
18. // use File_handle: uses vastly outnumber the above code
19. void f(const char* fn)
20. {
21. File_handle f(fn,"rw"); // open fn for reading and writing
22. // use file through f
23. } // automatically destroy f here, calls fclose automatically with no extra effort
24. // (even if there's an exception, so this is exception-safe by construction)
In a system, in the worst case we need a “resource handle” class for each resource. However, we
don’t have to have a “finally” clause for each acquisition of a resource. In realistic systems, there
are far more resource acquisitions than kinds of resources, so the “resource acquisition is
initialization” technique leads to less code than use of a “finally” construct.
Also, have a look at the examples of resource management in Appendix E of TC++PL3e.
Why can’t I resume after catching an exception?
In other words, why doesn’t C++ provide a primitive for returning to the point from which an
exception was thrown and continuing execution from there?
Basically, someone resuming from an exception handler can never be sure that the code after the
point of throw was written to deal with the execution just continuing as if nothing had happened. An
exception handler cannot know how much context to “get right” before resuming. To get such code
right, the writer of the throw and the writer of the catch need intimate knowledge of each others
code and context. This creates a complicated mutual dependency that wherever it has been allowed
has led to serious maintenance problems.
 Stroustrup seriously considered the possibility of allowing resumption when he designed the C++
exception handling mechanism and this issue was discussed in quite some detail during
standardization. See the exception handling chapter of The Design and Evolution of C++.
If you want to check to see if you can fix a problem before throwing an exception, call a function
that checks and then throws only if the problem cannot be dealt with locally. A new_handler is an
example of this.

Reference and Value Semantics

Save to:
InstapaperPocketReadability
Contents of this section:

 What is value and/or reference semantics, and which is best in C++?

 What is “virtual data,” and how-can / why-would I use it in C++?
 What’s the difference between virtual data and dynamic data?
 Should I normally use pointers to freestore allocated objects for my data members, or should
I use “composition”?
 What are relative costs of the 3 performance hits associated with allocating member objects
from the freestore?
 Are “inline virtual” member functions ever actually “inlined”?
 Sounds like I should never use reference semantics, right?
 Does the poor performance of reference semantics mean I should pass-by-value?
What is value and/or reference semantics, and which is
best in C++?
With reference semantics, assignment is a pointer-copy (i.e., a reference). Value (or “copy”)
semantics mean assignment copies the value, not just the pointer. C++ gives you the choice: use the
assignment operator to copy the value (copy/value semantics), or use a pointer-copy to copy a
pointer (reference semantics). C++ allows you to override the assignment operator to do anything
your heart desires, however the default (and most common) choice is to copy the value.
Pros of reference semantics: flexibility and dynamic binding (you get dynamic binding in C++ only
when you pass by pointer or pass by reference, not when you pass by value).
Pros of value semantics: speed. “Speed” seems like an odd benefit for a feature that requires an
object (vs. a pointer) to be copied, but the fact of the matter is that one usually accesses an object
more than one copies the object, so the cost of the occasional copies is (usually) more than offset by
the benefit of having an actual object rather than a pointer to an object.
There are three cases when you have an actual object as opposed to a pointer to an object: local
objects, global/static objects, and fully contained member objects in a class. The most important
of these is the last (“composition”).
More info about copy-vs-reference semantics is given in the next FAQs. Please read them all to get
a balanced perspective. The first few have intentionally been slanted toward value semantics, so if
you only read the first few of the following FAQs, you’ll get a warped perspective.
Assignment has other issues (e.g., shallow vs. deep copy) which are not covered here.

What is “virtual data,” and how-can / why-would I use it

in C++?
 virtual data allows a derived class to change the exact class of a base class’s member
object. virtual data isn’t strictly “supported” by C++, however it can be simulated in C++. It ain’t
pretty, but it works.
To simulate virtual data in C++, the base class must have a pointer to the member object, and the
derived class must provide a new object to be pointed to by the base class’s pointer. The base class
would also have one or more normal constructors that provide their own referent (again via new),
and the base class’s destructor would delete the referent.
For example, class Stack might have an Array member object (using a pointer), and
derived class StretchableStack might override the base class member data
from Array to StretchableArray. For this to work, StretchableArray would have to inherit
from Array, so Stack would have an Array*. Stack’s normal constructors would initialize
this Array* with a new Array, but Stack would also have a (possibly protected) constructor
that would accept an Array* from a derived class. StretchableStack’s constructor would
provide a new StretchableArray to this special constructor.
Pros:
 Easier implementation of StretchableStack (most of the code is inherited)
 Users can pass a StretchableStack as a kind-of Stack
Cons:
 Adds an extra layer of indirection to access the Array
 Adds some extra freestore allocation overhead (both new and delete)
 Adds some extra dynamic binding overhead (reason given in next FAQ)
In other words, we succeeded at making our job easier as the implementer of StretchableStack,
but all our users pay for it. Unfortunately the extra overhead was imposed on both users
of StretchableStack and on users of Stack.
Please read the rest of this section. (You will not get a balanced perspective without the others.)
What’s the difference between virtual data and dynamic
data?
The easiest way to see the distinction is by an analogy with virtual functions: A virtual member
function means the declaration (signature) must stay the same in derived classes, but the definition
(body) can be overridden. The overriddenness of an inherited member function is a static property
of the derived class; it doesn’t change dynamically throughout the life of any particular object, nor
is it possible for distinct objects of the derived class to have distinct definitions of the member
function.
Now go back and re-read the previous paragraph, but make these substitutions:
 “member function” → “member object”
 “signature” → “type”
 “body” → “exact class”
After this, you’ll have a working definition of virtual data.
Another way to look at this is to distinguish “per-object” member functions from “dynamic”
member functions. A “per-object” member function is a member function that is potentially
different in any given instance of an object, and could be implemented by burying a function pointer
in the object; this pointer could be const, since the pointer will never be changed throughout the
object’s life. A “dynamic” member function is a member function that will change dynamically over
time; this could also be implemented by a function pointer, but the function pointer would not be
const.
Extending the analogy, this gives us three distinct concepts for data members:
 virtual data: the definition (class) of the member object is overridable in derived classes
provided its declaration (“type”) remains the same, and this overriddenness is a static property of
the derived class
 per-object-data: any given object of a class can instantiate a different conformal (same type)
member object upon initialization (usually a “wrapper” object), and the exact class of the member
object is a static property of the object that wraps it
 dynamic-data: the member object’s exact class can change dynamically over time
The reason they all look so much the same is that none of this is “supported” in C++. It’s all merely
“allowed,” and in this case, the mechanism for faking each of these is the same: a pointer to a
(probably abstract) base class. In a language that made these “first class” abstraction mechanisms,
the difference would be more striking, since they’d each have a different syntactic variant.

Should I normally use pointers to freestore allocated

objects for my data members, or should I use
“composition”?
Composition.
Your member objects should normally be “contained” in the composite object (but not always;
“wrapper” objects are a good example of where you want a pointer/reference; also the N-to-1-uses-a
relationship needs something like a pointer/reference).
There are three reasons why fully contained member objects (“composition”) has better
performance than pointers to freestore-allocated member objects:
 Extra layer of indirection every time you need to access the member object
 Extra freestore allocations (new in constructor, delete in destructor)
 Extra dynamic binding (reason given below)
What are relative costs of the 3 performance hits
associated with allocating member objects from the
freestore?
The three performance hits are enumerated in the previous FAQ:
 By itself, an extra layer of indirection is small potatoes
 Freestore allocations can be a performance issue (the performance of the typical
implementation of malloc() degrades when there are many allocations; OO software can easily
become “freestore bound” unless you’re careful)
 The extra dynamic binding comes from having a pointer rather than an object. Whenever the
C++ compiler can know an object’s exact class, virtual function calls can be statically bound,
which allows inlining. Inlining allows zillions (would you believe half a dozen :-) optimization
opportunities such as procedural integration, register lifetime issues, etc. The C++ compiler can
know an object’s exact class in three circumstances: local variables, global/static variables, and
fully-contained member objects
Thus fully-contained member objects allow significant optimizations that wouldn’t be possible
under the “member objects-by-pointer” approach. This is the main reason that languages which
enforce reference-semantics have “inherent” performance challenges.
Note: Please read the next three FAQs to get a balanced perspective!
 Are “inline virtual” member functions ever actually
“inlined”?
Occasionally…
When the object is referenced via a pointer or a reference, a call to a virtual function generally
cannot be inlined, since the call must be resolved dynamically. Reason: the compiler can’t know
which actual code to call until run-time (i.e., dynamically), since the code may be from a derived
class that was created after the caller was compiled.
Therefore the only time an inline virtual call can be inlined is when the compiler knows the
“exact class” of the object which is the target of the virtual function call. This can happen only
when the compiler has an actual object rather than a pointer or reference to an object. I.e., either
with a local object, a global/static object, or a fully contained object inside a composite. This
situation can sometimes happen even with a pointer or reference, for example when functions get
inlined, access through a pointer or reference may become direct access on the object.
Note that the difference between inlining and non-inlining is normally much more significant than
the difference between a regular function call and a virtual function call. For example, the
difference between a regular function call and a virtual function call is often just two extra
memory references, but the difference between an inline function and a non-inline function can
be as much as an order of magnitude (for zillions of calls to insignificant member functions, loss of
inlining virtual functions can result in 25X speed degradation! [Doug Lea, “Customization in C+
+,” proc Usenix C++ 1990]).
A practical consequence of this insight: don’t get bogged down in the endless debates (or sales
tactics!) of compiler/language vendors who compare the cost of a virtual function call on their
language/compiler with the same on another language/compiler. Such comparisons are largely
meaningless when compared with the ability of the language/compiler to “inline expand” member
function calls. I.e., many language implementation vendors make a big stink about how good their
dispatch strategy is, but if these implementations don’t inline member function calls, the overall
system performance would be poor, since it is inlining —not dispatching— that has the greatest
performance impact.
Here is an example of where virtual calls can be inlined even through a reference. The following
code is all in the same translation unit, or otherwise organized such that the optimizer can see all of
this code at once.
1. class Calculable
2. {
3. public:
4. virtual unsigned char calculate() = 0;
5. };
6.
7. class X : public Calculable
8. {
9. public:
10. virtual unsigned char calculate() { return 1; }
11. };
12.
13. class Y : public Calculable
14. {
15. public:
16. virtual unsigned char calculate() { return 2; }
17. };
18.
19. static void print(Calculable& c)
20. {
21. printf("%d\n", c.calculate());
22. printf("+1: %d\n", c.calculate() + 1);
23. }
24.
25. int main()
26. {
27. X x;
28. Y y;
29.
30. print(x);
31. print(y);
32. }
The compiler is free to transform main as follows:
1. int main()
2. {
3. X x;
4. Y y;
5.
6. printf("%d\n", x.calculate());
7. printf("+1: %d\n", x.calculate() + 1);
8. printf("%d\n", y.calculate());
9. printf("+1: %d\n", y.calculate() + 1);
10. }
It is now able to inline the virtual function calls.
Note: Please read the next two FAQs to see the other side of this coin!
Sounds like I should never use reference semantics,
right?
Wrong.
Reference semantics are A Good Thing. We can’t live without pointers. We just don’t want our
software to be One Gigantic Rats Nest Of Pointers. In C++, you can pick and choose where you
want reference semantics (pointers/references) and where you’d like value semantics (where objects
physically contain other objects etc). In a large system, there should be a balance. However if you
implement absolutely everything as a pointer, you’ll get enormous speed hits.
Objects near the problem skin are larger than higher level objects. The identity of these “problem
space” abstractions is usually more important than their “value.” Thus reference semantics should
be used for problem-space objects.
Note that these problem space objects are normally at a higher level of abstraction than the solution
space objects, so the problem space objects normally have a relatively lower frequency of
interaction. Therefore C++ gives us an ideal situation: we choose reference semantics for objects
that need unique identity or that are too large to copy, and we can choose value semantics for the
others. Thus the highest frequency objects will end up with value semantics, since we install
flexibility where it doesn’t hurt us (only), and we install performance where we need it most!
These are some of the many issues that come into play with real OO design. OO/C++ mastery takes
time and high quality training. If you want a powerful tool, you’ve got to invest.
Don’t stop now! Read the next FAQ too!!
Does the poor performance of reference semantics mean I
should pass-by-value?
 Nope.
The previous FAQ were talking about member objects, not parameters. Generally, objects that are
part of an inheritance hierarchy should be passed by reference or by pointer, not by value, since only
then do you get the (desired) dynamic binding (pass-by-value doesn’t mix with inheritance, since
larger derived class objects get sliced when passed by value as a base class object).
Unless compelling reasons are given to the contrary, member objects should be by value and
parameters should be by reference. The discussion in the previous few FAQs indicates some of the
“compelling reasons” for when member objects should be by reference.

Inline Functions
Save to:
InstapaperPocketReadability
Contents of this section:

 What’s the deal with inline functions?

 What’s a simple example of procedural integration?
 Do inline functions improve performance?
 How can inline functions help with the tradeoff of safety vs. speed?
 Why should I use inline functions instead of plain old #define macros?
 How do you tell the compiler to make a non-member function inline?
 How do you tell the compiler to make a member function inline?
 Is there another way to tell the compiler to make a member function inline?
 With inline member functions that are defined outside the class, is it best to put
the inline keyword next to the declaration within the class body, next to the definition outside
the class body, or both?
What’s the deal with inline functions?
When the compiler inline-expands a function call, the function’s code gets inserted into the caller’s
code stream (conceptually similar to what happens with a #define macro). This can, depending on
a zillion other things, improve performance, because the optimizer can procedurally integrate the
called code — optimize the called code into the caller.
There are several ways to designate that a function is inline, some of which involve
the inline keyword, others do not. No matter how you designate a function as inline, it is a
request that the compiler is allowed to ignore: the compiler might inline-expand some, all, or none
of the places where you call a function designated as inline. (Don’t get discouraged if that seems
hopelessly vague. The flexibility of the above is actually a huge advantage: it lets the compiler treat
large functions differently from small ones, plus it lets the compiler generate code that is easy to
debug if you select the right compiler options.)
What’s a simple example of procedural integration?
Consider the following call to function g():
1. void f()
2. {
3. int x = /*...*/;
4. int y = /*...*/;
5. int z = /*...*/;
6. // ...code that uses x, y and z...
7. g(x, y, z);
8. // ...more code that uses x, y and z...
9. }
 Assuming a typical C++ implementation that has registers and a stack, the registers and parameters
get written to the stack just before the call to g(), then the parameters get read from the stack
inside g() and read again to restore the registers while g() returns to f(). But that’s a lot of
unnecessary reading and writing, especially in cases when the compiler is able to use registers for
variables x, y and z: each variable could get written twice (as a register and also as a parameter) and
read twice (when used within g() and to restore the registers during the return to f()).
1. void g(int x, int y, int z)
2. {
3. // ...code that uses x, y and z...
4. }
If the compiler inline-expands the call to g(), all those memory operations could vanish. The
registers wouldn’t need to get written or read since there wouldn’t be a function call, and the
parameters wouldn’t need to get written or read since the optimizer would know they’re already in
registers.
Naturally your mileage may vary, and there are a zillion variables that are outside the scope of this
particular FAQ, but the above serves as an example of the sorts of things that can happen with
procedural integration.

Do inline functions improve performance?

Yes and no. Sometimes. Maybe.
There are no simple answers. inline functions might make the code faster, they might make it
slower. They might make the executable larger, they might make it smaller. They might cause
thrashing, they might prevent thrashing. And they might be, and often are, totally irrelevant to
speed.
inline functions might make it faster: As shown above, procedural integration might remove a
bunch of unnecessary instructions, which might make things run faster.
inline functions might make it slower: Too much inlining might cause code bloat, which might
cause “thrashing” on demand-paged virtual-memory systems. In other words, if the executable size
is too big, the system might spend most of its time going out to disk to fetch the next chunk of code.
inline functions might make it larger: This is the notion of code bloat, as described above. For
example, if a system has 100 inline functions each of which expands to 100 bytes of executable
code and is called in 100 places, that’s an increase of 1MB. Is that 1MB going to cause problems?
Who knows, but it is possible that that last 1MB could cause the system to “thrash,” and that could
slow things down.
inline functions might make it smaller: The compiler often generates more code to push/pop
registers/parameters than it would by inline-expanding the function’s body. This happens with very
small functions, and it also happens with large functions when the optimizer is able to remove a lot
of redundant code through procedural integration — that is, when the optimizer is able to make the
large function small.
inline functions might cause thrashing: Inlining might increase the size of the binary
executable, and that might cause thrashing.
inline functions might prevent thrashing: The working set size (number of pages that need to be
in memory at once) might go down even if the executable size goes up. When f() calls g(), the
code is often on two distinct pages; when the compiler procedurally integrates the code
of g() into f(), the code is often on the same page.
inline functions might increase the number of cache misses: Inlining might cause an inner loop
to span across multiple lines of the memory cache, and that might cause thrashing of the memory-
cache.
 inline functions might decrease the number of cache misses: Inlining usually improves locality
of reference within the binary code, which might decrease the number of cache lines needed to store
the code of an inner loop. This ultimately could cause a CPU-bound application to run faster.
inline functions might be irrelevant to speed: Most systems are not CPU-bound. Most systems
are I/O-bound, database-bound or network-bound, meaning the bottleneck in the system’s overall
performance is the file system, the database or the network. Unless your “CPU meter” is pegged at
100%, inline functions probably won’t make your system faster. (Even in CPU-bound
systems, inline will help only when used within the bottleneck itself, and the bottleneck is
typically in only a small percentage of the code.)
There are no simple answers: You have to play with it to see what is best. Do not settle for
simplistic answers like, “Never use inline functions” or “Always use inline functions” or
“Use inline functions if and only if the function is less than N lines of code.” These one-size-fits-
all rules may be easy to write down, but they will produce sub-optimal results.
How can inline functions help with the tradeoff of safety
vs. speed?
In straight C, you can achieve “encapsulated structs” by putting a void* in a struct, in which
case the void* points to the real data that is unknown to users of the struct. Therefore users of
the struct don’t know how to interpret the stuff pointed to by the void*, but the access functions
cast the void* to the appropriate hidden type. This gives a form of encapsulation.
Unfortunately it forfeits type safety, and also imposes a function call to access even trivial fields of
the struct (if you allowed direct access to the struct’s fields, anyone and everyone would be
able to get direct access since they would of necessity know how to interpret the stuff pointed to by
the void*; this would make it difficult to change the underlying data structure).
Function call overhead is small, but can add up. C++ classes allow function calls to be
expanded inline. This lets you have the safety of encapsulation along with the speed of direct
access. Furthermore the parameter types of these inline functions are checked by the compiler, an
improvement over C’s #define macros.
Why should I use inline functions instead of plain
old #define macros?
Because #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. Sometimes
you should use them anyway, but they’re still evil.
Unlike #define macros, inline functions avoid infamous macro errors since inline functions
always evaluate every argument exactly once. In other words, invoking an inline function is
semantically just like invoking a regular function, only faster:
1. // A macro that returns the absolute value of i
2. #define unsafe(i) \
3. ( (i) >= 0 ? (i) : -(i) )
4.
5. // An inline function that returns the absolute value of i
6. inline
7. int safe(int i)
8. {
9. return i >= 0 ? i : -i;
10. }
11.
12. int f();
13.
14. void userCode(int x)
15. {
16. int ans;
17.
18. ans = unsafe(x++); // Error! x is incremented twice
19. ans = unsafe(f()); // Danger! f() is called twice
20.
21. ans = safe(x++); // Correct! x is incremented once
22. ans = safe(f()); // Correct! f() is called once
23. }
Also unlike macros, argument types are checked, and necessary conversions are performed
correctly.
Macros are bad for your health; don’t use them unless you have to.
How do you tell the compiler to make a non-member
function inline?
When you declare an inline function, it looks just like a normal function:
1. void f(int i, char c);
But when you define an inline function, you prepend the function’s definition with the
keyword inline, and you put the definition into a header file:
1. inline
2. void f(int i, char c)
3. {
4. // ...
5. }
Note: It’s imperative that the function’s definition (the part between the {...}) be placed in a
header file, unless the function is used only in a single .cpp file. In particular, if you put
the inline function’s definition into a .cpp file and you call it from some other .cpp file, you’ll
get an “unresolved external” error from the linker.
How do you tell the compiler to make a member
function inline?
The declaration of an inline member function looks just like the declaration of a non-
inline member function:
1. class Fred {
2. public:
3. void f(int i, char c);
4. };
But when you define an inline member function (the {...} part), you prepend the member
function’s definition with the keyword inline, and you (almost always) put the definition into a
header file:
1. inline
2. void Fred::f(int i, char c)
3. {
4. // ...
5. }
The reason you (almost always) put the definition (the {...} part) of an inline function in a
header file is to avoid “unresolved external” errors from the linker. That error will occur if you put
the inline function’s definition in a .cpp file and if that function is called from some
other .cpp file.
Is there another way to tell the compiler to make a
member function inline?
 Yep: define the member function in the class body itself:
1. class Fred {
2. public:
3. void f(int i, char c)
4. {
5. // ...
6. }
7. };
This is often more convenient than the alternative of defining your inline functions outside the
class body. However, although it is easier on the person who writes the class, it is harder on all the
readers since it mixes what a class does (the external behavior) with how it does it (the
implementation). Because of this mixture, you should define all your member functions outside the
class body if your class is intended to be highly reused and your class’s documentation is the header
file itself. This is another application of Spock’s logic: the needs of the many (all the people reusing
your class) outweigh the needs of the few (those who maintain your class’s implementation) or the
one (the class’s original author).
Of course if you are not writing a highly reused class, or if you are providing documentation of your
class’s external behavior outside the header files (e.g., HTML or PDF or whatever), then you should
probably define your inline functions inside the class body proper, as that will simplify your
development as well as maintenance of the class’s implementation.
This approach is further exploited in the next FAQ.
With inline member functions that are defined outside
the class, is it best to put the inline keyword next to the
declaration within the class body, next to the definition
outside the class body, or both?
Definition only.
Here is an example of an inline member function defined outside the class body:
1. class Foo {
2. public:
3. void method(); // Best practice: Don't put the inline keyword here
4. // ...
5. };
6.
7. inline void Foo::method() // Best practice: Put the inline keyword here
8. {
9. // ...
10. }
Recall that you should define your inline member function outside the class body when your class
is intended to be highly reused and your reusers will read your header file to determine what the
class does — its observable semantics or external behavior. In that case…
 The public: part of the class body is where you describe the observable semantics of the
class, its public member functions, its friend functions, and any other features of the class to be
reused by others. The goal is to keep this public: part public — to drain the public: part of
any inklings of anything that is unimportant to reusers. If “it” can’t be observed from the caller’s
code, “it” shouldn’t be in the public: part of the class body.
 The other parts of the class, including non-public: part of the class body, the definitions of
your member and friend functions, etc. are pure implementation. Try not to describe any
observable semantics that were not already described in the class’s public: part. If “it” can be
observed from the caller’s code, “it” should be described in the public: part of the class body;
 “it” might also appear in the non-public: parts of the class, but “it” should be specified,
somehow, in the public: part.
From a practical standpoint, this separation makes life easier and safer for your class’s reusers. Say
Chuck wants to simply use your reusable class. Because you read this FAQ and used the above
separation, Chuck will see, in the public: part of your class, everything he needs to see
and nothing he doesn’t need to see. Your class’s public: part will be Chuck’s one-stop-shop for
your class’s observable semantics AKA external behavior. By purifying your
class’s public: parts, you made Chuck’s life both easier (he needs to look in only one spot) and
safer (his pure mind isn’t polluted by implementation minutiae).
Back to inline-ness: the decision of whether a function is or is not inline is an implementation
detail that does not change the observable semantics (the “meaning”) of a call. Therefore
the inline keyword should not go within the class’s public: (or the protected: or private:)
part, so it needs to go next to the function’s definition.
*NOTE: most people use the terms “declaration” and “definition” to differentiate the above two
places. For example, they might say, “Should I put the inline keyword next to the declaration or
the definition?” In case you’re talking to a language lawyer, it would be more precise to talk about a
non-defining declaration and a defining declaration, since definitions are also declarations.

Pointers to Member Functions

Save to:
InstapaperPocketReadability
Contents of this section:

 Is the type of “pointer-to-member-function” different from “pointer-to-function”?

 How do I pass a pointer-to-member-function to a signal handler, X event callback, system
call that starts a thread/task, etc?
 Why do I keep getting compile errors (type mismatch) when I try to use a member function
as an interrupt service routine?
 Why am I having trouble taking the address of a C++ function?
 How can I avoid syntax errors when creating pointers to members?
 How can I avoid syntax errors when calling a member function using a pointer-to-member-
function?
 How do I create and use an array of pointer-to-member-function?
 How do I declare a pointer-to-member-function that points to a const member function?
 What is the difference between the .* and ->* operators?
 Can I convert a pointer-to-member-function to a void*?
 Can I convert a pointer-to-function to a void*?
 I need something like function-pointers, but with more flexibility and/or thread-safety; is
there another way?
 What the heck is a functionoid, and why would I use one?
 Can you make functionoids faster than normal function calls?
 What’s the difference between a functionoid and a functor?
Is the type of “pointer-to-member-function” different from
“pointer-to-function”?
Yep.
Consider the following function:
1. int f(char a, float b);
 The type of this function is different depending on whether it is an ordinary function or a non-
static member function of some class:
 Its type is “int (*)(char,float)” if an ordinary function
 Its type is “int (Fred::*)(char,float)” if a non-static member function
of class Fred
Note: if it’s a static member function of class Fred, its type is the same as if it were an
ordinary function: “int (*)(char,float)”.
How do I pass a pointer-to-member-function to a signal
handler, X event callback, system call that starts a
thread/task, etc?
Don’t.
Because a member function is meaningless without an object to invoke it on, you can’t do this
directly (if The X Window System was rewritten in C++, it would probably pass references
to objects around, not just pointers to functions; naturally the objects would embody the required
function and probably a whole lot more).
As a patch for existing software, use a top-level (non-member) function as a wrapper which takes an
object obtained through some other technique. Depending on the routine you’re calling, this “other
technique” might be trivial or might require a little work on your part. The system call that starts a
thread, for example, might require you to pass a function pointer along with a void*, so you can
pass the object pointer in the void*. Many real-time operating systems do something similar for the
function that starts a new task. Worst case you could store the object pointer in a global variable;
this might be required for Unix signal handlers (but globals are, in general, undesired). In any case,
the top-level function would call the desired member function on the object.
Here’s an example of the worst case (using a global). Suppose you want to
call Fred::memberFn() on interrupt:
1. class Fred {
2. public:
3. void memberFn();
4. static void staticMemberFn(); // A static member function can usually handle it
5. // ...
6. };
7.
8. // Wrapper function uses a global to remember the object:
9. Fred* object_which_will_handle_signal;
10.
11. void Fred_memberFn_wrapper()
12. {
13. object_which_will_handle_signal->memberFn();
14. }
15.
16. int main()
17. {
18. /* signal(SIGINT, Fred::memberFn); */ // Can NOT do this
19. signal(SIGINT, Fred_memberFn_wrapper); // Okay
20. signal(SIGINT, Fred::staticMemberFn); // Okay usually; see below
21. // ...
22. }
Note: static member functions do not require an actual object to be invoked, so pointers-to-
static-member-functions are usually type-compatible with regular pointers-to-functions.
However, although it probably works on most compilers, it actually would have to be an extern
 "C" non-member function to be correct, since “C linkage” doesn’t only cover things like name
mangling, but also calling conventions, which might be different between C and C++.
Why do I keep getting compile errors (type mismatch)
when I try to use a member function as an interrupt
service routine?
This is a special case of the previous two questions, therefore read the previous two answers first.
Non-static member functions have a hidden parameter that corresponds to the this pointer.
The this pointer points to the instance data for the object. The interrupt hardware/firmware in the
system is not capable of providing the this pointer argument. You must use “normal” functions
(non class members) or static member functions as interrupt service routines.
One possible solution is to use a static member as the interrupt service routine and have that
function look somewhere to find the instance/member pair that should be called on interrupt. Thus
the effect is that a member function is invoked on an interrupt, but for technical reasons you need to
call an intermediate function first.
Why am I having trouble taking the address of a C++
function?
Short answer: if you’re trying to store it into (or pass it as) a pointer-to-function, then that’s the
problem — this is a corollary to the previous FAQ.
Long answer: In C++, member functions have an implicit parameter which points to the object
(the this pointer inside the member function). Normal C functions can be thought of as having a
different calling convention from member functions, so the types of their pointers (pointer-to-
member-function vs pointer-to-function) are different and incompatible. C++ introduces a new type
of pointer, called a pointer-to-member, which can be invoked only by providing an object.
NOTE: do not attempt to “cast” a pointer-to-member-function into a pointer-to-function; the result
is undefined and probably disastrous. E.g., a pointer-to-member-function is not required to contain
the machine address of the appropriate function. As was said in the last example, if you have a
pointer to a regular C function, use either a top-level (non-member) function, or a static (class)
member function.
How can I avoid syntax errors when creating pointers to
members?
Use a typedef.
Yea, right, I know: you are different. You are smart. You can do this stuff without a typedef. Sigh.
I have received many emails from people who, like you, refused to take the simple advice of this
FAQ. They wasted hours and hours of their time, when 10 seconds worth of typedefs would have
simplified their lives. Plus, face it, you are not writing code that only you can read; you are
hopefully writing your code that others will also be able to read — when they’re tired — when they
have their own deadlines and their own challenges. So why intentionally make life harder on
yourself and on others? Be smart: use a typedef.
Here’s a sample class:
1. class Fred {
2. public:
3. int f(char x, float y);
4. int g(char x, float y);
5. int h(char x, float y);
6. int i(char x, float y);
7. // ...
8. };
The typedef is trivial:
1. typedef int (Fred::*FredMemFn)(char x, float y); // Please do this!
That’s it! FredMemFn is the type name, and a pointer of that type points to any member
of Fred that takes (char,float), such as Fred’s f, g, h and i.
It’s then trivial to declare a member-function pointer:
1. int main()
2. {
3. FredMemFn p = &Fred::f;
4. // ...
5. }
And it’s also trivial to declare functions that receive member-function pointers:
1. void userCode(FredMemFn p)
2. { /*...*/ }
And it’s also trivial to declare functions that return member-function pointers:
1. FredMemFn userCode()
2. { /*...*/ }
So please, use a typedef. Either that or do not send me email about the problems you have with
your member-function pointers!
How can I avoid syntax errors when calling a member
function using a pointer-to-member-function?
If you have access to a compiler and standard library that implements the appropriate parts of the
upcoming C++17 standard, use std::invoke. Otherwise, use a #define macro.
Please.
Pretty please.
I get way too many emails from confused people who refused to take this advice. It’s so simple. I
know, you don’t need std::invoke or a macro, and the expert you talked to can do it without
either of them, but please don’t let your ego get in the way of what’s important: money. Other
programmers will need to read / maintain your code. Yes, I know: you are smarter than everyone
else; fine. And you are awesome; fine. But don’t add unnecessary complexity to your code.
Using std::invoke is trivial. Note: FredMemFn is a typedef for a pointer-to-member type:
1. void userCode(Fred& fred, FredMemFn p) // Use a typedef for pointer-to-member types
2. {
3. int ans = std::invoke(p, fred, 'x', 3.14);
4. // Would normally be: int ans = (fred.*p)('x', 3.14);
5.
6. // ...
7. }
If you can’t use std::invoke, reduce maintenance cost by, paradoxically, using
a #define macro in this particular case.
(Normally I dislike #define macros, but you should use them with pointers to members because
they improve the readability and writability of that sort of code.)
The macro is trivial:
1. #define CALL_MEMBER_FN(object,ptrToMember) ((object).*(ptrToMember))
Using the macro is also trivial. Note: FredMemFn is a typedef for a pointer-to-member type:
1. void userCode(Fred& fred, FredMemFn p) // Use a typedef for pointer-to-member types
2. {
3. int ans = CALL_MEMBER_FN(fred,p)('x', 3.14);
4. // Would normally be: int ans = (fred.*p)('x', 3.14);
5.
6. // ...
7. }
The reason std::invoke or this macro is a good idea is because member function invocations are
often a lot more complex than the simple example just given. The difference in readability and
writability is significant. comp.lang.c++ has had to endure hundreds and hundreds of postings
from confused programmers who couldn’t quite get the syntax right. Almost all these errors would
have vanished had they used std::invoke or the above macro.
Note: #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. But
they’re still useful sometimes. But you should still feel a vague sense of shame after using them.
How do I create and use an array of pointer-to-member-
function?
Use both the typedef and std::invoke or the #define macro described earlier, and you’re
90% done.
Step 1: create a typedef:
1. class Fred {
2. public:
3. int f(char x, float y);
4. int g(char x, float y);
5. int h(char x, float y);
6. int i(char x, float y);
7. // ...
8. };
9.
10. // FredMemFn points to a member of Fred that takes (char,float)
11. typedef int (Fred::*FredMemFn)(char x, float y);
Step 2: create a #define macro if you don’t have std::invoke:
1. #define CALL_MEMBER_FN(object,ptrToMember) ((object).*(ptrToMember))
Now your array of pointers-to-member-functions is straightforward:
1. FredMemFn a[] = { &Fred::f, &Fred::g, &Fred::h, &Fred::i };
And your usage of one of the member function pointers is also straightforward:
1. void userCode(Fred& fred, int memFnNum)
2. {
3. // Assume memFnNum is between 0 and 3 inclusive:
4. std::invoke(a[memFnNum], fred, 'x', 3.14);
5. }
or if you don’t have std::invoke,
1. void userCode(Fred& fred, int memFnNum)
2. {
3. // Assume memFnNum is between 0 and 3 inclusive:
4. CALL_MEMBER_FN(fred, a[memFnNum]) ('x', 3.14);
5. }
Note: #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. But they’re
still useful sometimes. Feel ashamed, feel guilty, but when an evil construct like a macro improves
your software, use it.
How do I declare a pointer-to-member-function that points
to a const member function?
Short answer: add a const to the right of the ) when you use a typedef to declare the member-
function-pointer type.
 For example, suppose you want a pointer-to-member-function that points
at Fred::f, Fred::g or Fred::h:
1. class Fred {
2. public:
3. int f(int i) const;
4. int g(int i) const;
5. int h(int j) const;
6. // ...
7. };
Then when you use a typedef to declare the member-function-pointer type, it should look like
this:
1. // FredMemFn points to a const member-function of Fred that takes (int)
2. typedef int (Fred::*FredMemFn)(int) const;
3. ↑↑↑↑↑ // Points only to member functions decorated with const
That’s it!
Then you can declare/pass/return member-function pointers just like normal:
1. void foo(FredMemFn p) // Pass a member-function pointer
2. { /*...*/ }
3.
4. FredMemFn bar() // Return a member-function pointer
5. { /*...*/ }
6.
7. void baz()
8. {
9. FredMemFn p = &Fred::f; // Declare a member-function pointer
10. FredMemFn a[10]; // Declare an array of member-function pointers
11. // ...
12. }

What is the difference between the .* and -

>* operators?
You won’t need to understand this if you use std::invoke or a macro for member-function-
pointer calls. Oh yea, please use std::invoke or a macro in this case. And did I mention that you
should use std::invoke or a macro in this case??!?
But if you really want to avoid std::invoke or the macro, sigh, groan, okay, here it is:
use .* when the left-hand argument is a reference to an object, and ->* when it is a pointer to an
object.
For example:
1. class Fred { /*...*/ };
2.
3. typedef int (Fred::*FredMemFn)(int i, double d); // use a typedef!!! please!!!
4.
5. void sample(Fred x, Fred& y, Fred* z, FredMemFn func)
6. {
7. x.*func(42, 3.14);
8. y.*func(42, 3.14);
9. z->*func(42, 3.14);
10. }
BUT please consider using a std::invoke or macro instead:
1. void sample(Fred x, Fred& y, Fred* z, FredMemFn func)
2. {
3. std::invoke(func, x, 42, 3.14);
4. std::invoke(func, y, 42, 3.14);
5. std::invoke(func, *z, 42, 3.14);
6. }
or
1. void sample(Fred x, Fred& y, Fred* z, FredMemFn func)
2. {
3. CALL_MEMBER_FN(x,func)(42, 3.14);
4. CALL_MEMBER_FN(y,func)(42, 3.14);
5. CALL_MEMBER_FN(*z,func)(42, 3.14);
6. }
As discussed earlier, real-world invocations are often much more complicated than the simple ones
here, so using a std::invoke or macro will typically improve your code’s writability and
readability.
Can I convert a pointer-to-member-function to a void*?
No!
1. class Fred {
2. public:
3. int f(char x, float y);
4. int g(char x, float y);
5. int h(char x, float y);
6. int i(char x, float y);
7. // ...
8. };
9.
10. // FredMemFn points to a member of Fred that takes (char,float)
11. typedef int (Fred::*FredMemFn)(char x, float y);
12.
13. #define CALL_MEMBER_FN(object,ptrToMember) ((object).*(ptrToMember))
14.
15. int callit(Fred& o, FredMemFn p, char x, float y)
16. {
17. return CALL_MEMBER_FN(o,p)(x, y);
18. }
19.
20. int main()
21. {
22. FredMemFn p = &Fred::f;
23. void* p2 = (void*)p; // ← illegal!!
24. Fred o;
25. callit(o, p, 'x', 3.14f); // okay
26. callit(o, FredMemFn(p2), 'x', 3.14f); // might fail!!
27. // ...
28. }
Technical details: pointers to member functions and pointers to data are not necessarily represented
in the same way. A pointer to a member function might be a data structure rather than a single
pointer. Think about it: if it’s pointing at a virtual function, it might not actually be pointing at a
statically resolvable pile of code, so it might not even be a normal address — it might be a different
data structure of some sort.
Please do not email me if the above seems to work on your particular version of your particular
compiler on your particular operating system. I don’t care. It’s illegal, period.
Can I convert a pointer-to-function to a void*?
 No!
1. int f(char x, float y);
2. int g(char x, float y);
3.
4. typedef int(*FunctPtr)(char,float);
5.
6. int callit(FunctPtr p, char x, float y)
7. {
8. return p(x, y);
9. }
10.
11. int main()
12. {
13. FunctPtr p = f;
14. void* p2 = (void*)p; // ← illegal!!
15. callit(p, 'x', 3.14f); // okay
16. callit(FunctPtr(p2), 'x', 3.14f); // might fail!!
17. // ...
18. }
Technical details: void* pointers are pointers to data, and function pointers point to functions. The
language does not require functions and data to be in the same address space, so, by way
of example and not limitation, on architectures that have them in different address spaces, the two
different pointer types will not be comparable.
Please do not email me if the above seems to work on your particular version of your particular
compiler on your particular operating system. I don’t care. It’s illegal, period.
I need something like function-pointers, but with more
flexibility and/or thread-safety; is there another way?
Use a functionoid.

What the heck is a functionoid, and why would I use

one?
Functionoids are functions on steroids. Functionoids are strictly more powerful than functions, and
that extra power solves some (not all) of the challenges typically faced when you use function-
pointers.
Let’s work an example showing a traditional use of function-pointers, then we’ll translate that
example into functionoids. The traditional function-pointer idea is to have a bunch of compatible
functions:
1. int funct1( /*...params...*/ ) { /*...code...*/ }
2. int funct2( /*...params...*/ ) { /*...code...*/ }
3. int funct3( /*...params...*/ ) { /*...code...*/ }
Then you access those by function-pointers:
1. typedef int(*FunctPtr)( /*...params...*/ );
2.
3. void myCode(FunctPtr f)
4. {
5. // ...
6. f( /*...args-go-here...*/ );
7. // ...
8. }
 Sometimes people create an array of these function-pointers:
1. FunctPtr array[10];
2. array[0] = funct1;
3. array[1] = funct1;
4. array[2] = funct3;
5. array[3] = funct2;
6. // ...
In which case they call the function by accessing the array:
1. array[i]( /*...args-go-here...*/ );
With functionoids, you first create a base class with a pure-virtual method:
1. class Funct {
2. public:
3. virtual int doit(int x) = 0;
4. virtual ~Funct() = 0;
5. };
6.
7. inline Funct::~Funct() { } // defined even though it's pure virtual; it's faster this way; trust me
Then instead of three functions, you create three derived classes:
1. class Funct1 : public Funct {
2. public:
3. virtual int doit(int x) { /*...code from funct1...*/ }
4. };
5.
6. class Funct2 : public Funct {
7. public:
8. virtual int doit(int x) { /*...code from funct2...*/ }
9. };
10.
11. class Funct3 : public Funct {
12. public:
13. virtual int doit(int x) { /*...code from funct3...*/ }
14. };
Then instead of passing a function-pointer, you pass a Funct*. I’ll create
a typedef called FunctPtr merely to make the rest of the code similar to the old-fashioned
approach:
1. typedef Funct* FunctPtr;
2.
3. void myCode(FunctPtr f)
4. {
5. // ...
6. f->doit( /*...args-go-here...*/ );
7. // ...
8. }
You can create an array of them in almost the same way:
1. FunctPtr array[10];
2. array[0] = new Funct1( /*...ctor-args...*/ );
3. array[1] = new Funct1( /*...ctor-args...*/ );
4. array[2] = new Funct3( /*...ctor-args...*/ );
5. array[3] = new Funct2( /*...ctor-args...*/ );
6. // ...
This gives us the first hint about where functionoids are strictly more powerful than function-
pointers: the fact that the functionoid approach has arguments you can pass to the ctors (shown
 above as …ctor-args…) whereas the function-pointers version does not. Think of a functionoid
object as a freeze-dried function-call (emphasis on the word call). Unlike a pointer to a function, a
functionoid is (conceptually) a pointer to a partially called function. Imagine for the moment a
technology that lets you pass some-but-not-all arguments to a function, then lets you freeze-dry that
(partially completed) call. Pretend that technology gives you back some sort of magic pointer to that
freeze-dried partially-completed function-call. Then later you pass the remaining args using that
pointer, and the system magically takes your original args (that were freeze-dried), combines them
with any local variables that the function calculated prior to being freeze-dried, combines all that
with the newly passed args, and continues the function’s execution where it left off when it was
freeze-dried. That might sound like science fiction, but it’s conceptually what functionoids let you
do. Plus they let you repeatedly “complete” that freeze-dried function-call with various different
“remaining parameters,” as often as you like. Plus they allow (not require) you to change the freeze-
dried state when it gets called, meaning functionoids can remember information from one call to the
next.
Let’s get our feet back on the ground and we’ll work a couple of examples to explain what all that
mumbo jumbo really means.
Suppose the original functions (in the old-fashioned function-pointer style) took slightly different
parameters.
1. int funct1(int x, float y)
2. { /*...code...*/ }
3.
4. int funct2(int x, const std::string& y, int z)
5. { /*...code...*/ }
6.
7. int funct3(int x, const std::vector<double>& y)
8. { /*...code...*/ }
When the parameters are different, the old-fashioned function-pointers approach is difficult to use,
since the caller doesn’t know which parameters to pass (the caller merely has a pointer to the
function, not the function’s name or, when the parameters are different, the number and types of its
parameters) (do not write me an email about this; yes you can do it, but you have to stand on your
head and do messy things; but do not write me about it — use functionoids instead).
With functionoids, the situation is, at least sometimes, much better. Since a functionoid can be
thought of as a freeze-dried function call, just take the un-common args, such as the ones I’ve
called y and/or z, and make them args to the corresponding ctors. You may also pass the common
args (in this case the int called x) to the ctor, but you don’t have to — you have the option of
passing it/them to the pure virtual doit() method instead. I’ll assume you want to
pass x into doit() and y and/or z into the ctors:
1. class Funct {
2. public:
3. virtual int doit(int x) = 0;
4. };
Then instead of three functions, you create three derived classes:
1. class Funct1 : public Funct {
2. public:
3. Funct1(float y) : y_(y) { }
4. virtual int doit(int x) { /*...code from funct1...*/ }
5. private:
6. float y_;
7. };
8.
9. class Funct2 : public Funct {
10. public:
11. Funct2(const std::string& y, int z) : y_(y), z_(z) { }
12. virtual int doit(int x) { /*...code from funct2...*/ }
13. private:
14. std::string y_;
15. int z_;
16. };
17.
18. class Funct3 : public Funct {
19. public:
20. Funct3(const std::vector<double>& y) : y_(y) { }
21. virtual int doit(int x) { /*...code from funct3...*/ }
22. private:
23. std::vector<double> y_;
24. };
Now you see that the ctor’s parameters get freeze-dried into the functionoid when you create the
array of functionoids:
1. FunctPtr array[10];
2.
3. array[0] = new Funct1(3.14f);
4.
5. array[1] = new Funct1(2.18f);
6.
7. std::vector<double> bottlesOfBeerOnTheWall;
8. bottlesOfBeerOnTheWall.push_back(100);
9. bottlesOfBeerOnTheWall.push_back(99);
10. // ...
11. bottlesOfBeerOnTheWall.push_back(1);
12. array[2] = new Funct3(bottlesOfBeerOnTheWall);
13.
14. array[3] = new Funct2("my string", 42);
15.
16. // ...
So when the user invokes the doit() on one of these functionoids, he supplies the “remaining”
args, and the call conceptually combines the original args passed to the ctor with those passed into
the doit() method:
1. array[i]->doit(12);
As I’ve already hinted, one of the benefits of functionoids is that you can have several instances of,
say, Funct1 in your array, and those instances can have different parameters freeze-dried into them.
For example, array[0] and array[1] are both of type Funct1, but the behavior of array[0]-
>doit(12) will be different from the behavior of array[1]->doit(12) since the behavior will
depend on both the 12 that was passed to doit() and the args passed to the ctors.
Another benefit of functionoids is apparent if we change the example from an array of functionoids
to a local functionoid. To set the stage, let’s go back to the old-fashioned function-pointer approach,
and imagine that you’re trying to pass a comparison-function to
a sort() or binarySearch() routine. The sort() or binarySearch() routine is
called childRoutine() and the comparison function-pointer type is called FunctPtr:
1. void childRoutine(FunctPtr f)
2. {
3. // ...
4. f( /*...args...*/ );
5. // ...
6. }
 Then different callers would pass different function-pointers depending on what they thought was
best:
1. void myCaller()
2. {
3. // ...
4. childRoutine(funct1);
5. // ...
6. }
7.
8. void yourCaller()
9. {
10. // ...
11. childRoutine(funct3);
12. // ...
13. }
We can easily translate this example into one using functionoids:
1. void childRoutine(Funct& f)
2. {
3. // ...
4. f.doit( /*...args...*/ );
5. // ...
6. }
7.
8. void myCaller()
9. {
10. // ...
11. Funct1 funct( /*...ctor-args...*/ );
12. childRoutine(funct);
13. // ...
14. }
15.
16. void yourCaller()
17. {
18. // ...
19. Funct3 funct( /*...ctor-args...*/ );
20. childRoutine(funct);
21. // ...
22. }
Given this example as a backdrop, we can see two benefits of functionoids over function-pointers.
The “ctor args” benefit described above, plus the fact that functionoids can maintain state between
calls in a thread-safe manner. With plain function-pointers, people normally maintain state between
calls via static data. However static data is not intrinsically thread-safe — static data is shared
between all threads. The functionoid approach provides you with something that
is intrinsically thread-safe since the code ends up with thread-local data. The implementation is
trivial: change the old-fashioned static datum to an instance data member inside the
functionoid’s this object, and poof, the data is not only thread-local, but it is even safe with
recursive calls: each call to yourCaller() will have its own distinct Funct3 object with its own
distinct instance data.
Note that we’ve gained something without losing anything. If you want thread-global data,
functionoids can give you that too: just change it from an instance data member inside the
functionoid’s this object to a static data member within the functionoid’s class, or even to a local-
scope static data. You’d be no better off than with function-pointers, but you wouldn’t be worse off
either.
 The functionoid approach gives you a third option which is not available with the old-fashioned
approach: the functionoid lets callers decide whether they want thread-local or thread-global data.
They’d be responsible to use locks in cases where they wanted thread-global data, but at least they’d
have the choice. It’s easy:
1. void callerWithThreadLocalData()
2. {
3. // ...
4. Funct1 funct( /*...declare ctor args here...*/ );
5. childRoutine(funct);
6. // ...
7. }
8.
9. void callerWithThreadGlobalData()
10. {
11. // ...
12. static Funct1 funct( /*...declare ctor args here...*/ ); // The static is the only difference
13. childRoutine(funct);
14. // ...
15. }
Functionoids don’t solve every problem encountered when making flexible software, but they are
strictly more powerful than function-pointers and they are worth at least evaluating. In fact you can
easily prove that functionoids don’t lose any power over function-pointers, since you can imagine
that the old-fashioned approach of function-pointers is equivalent to having a global(!) functionoid
object. Since you can always make a global functionoid object, you haven’t lost any ground. QED.

Can you make functionoids faster than normal function

calls?
Yes.
If you have a small functionoid, and in the real world that’s rather common, the cost of the function-
call can be high compared to the cost of the work done by the functionoid. In the previous FAQ,
functionoids were implemented using virtual functions and will typically cost you a function-call.
An alternate approach uses templates.
The following example is similar in spirit to the one in the previous FAQ. I have
renamed doit() to operator()() to improve the caller code’s readability and to allow someone
to pass a regular function-pointer:
1. class Funct1 {
2. public:
3. Funct1(float y) : y_(y) { }
4. int operator()(int x) { /*...code from funct1...*/ }
5. private:
6. float y_;
7. };
8.
9. class Funct2 {
10. public:
11. Funct2(const std::string& y, int z) : y_(y), z_(z) { }
12. int operator()(int x) { /*...code from funct2...*/ }
13. private:
14. std::string y_;
15. int z_;
16. };
17.
18. class Funct3 {
19. public:
20. Funct3(const std::vector<double>& y) : y_(y) { }
21. int operator()(int x) { /*...code from funct3...*/ }
22. private:
23. std::vector<double> y_;
24. };
The difference between this approach and the one in the previous FAQ is that the fuctionoid gets
“bound” to the caller at compile-time rather than at run-time. Think of it as passing in a parameter:
if you know at compile-time the kind of functionoid you ultimately want to pass in, then you can
use the above technique, and you can, at least in typical cases, get a speed benefit from having the
compiler inline-expand the functionoid code within the caller. Here is an example:
1. template <typename FunctObj>
2. void myCode(FunctObj f)
3. {
4. // ...
5. f( /*...args-go-here...*/ );
6. // ...
7. }
When the compiler compiles the above, it might inline-expand the call which might improve
performance.
Here is one way to call the above:
1. void blah()
2. {
3. // ...
4. Funct2 x("functionoids are powerful", 42);
5. myCode(x);
6. // ...
7. }
Aside: as was hinted at in the first paragraph above, you may also pass in the names of normal
functions (though you might incur the cost of the function call when the caller uses these):
1. void myNormalFunction(int x);
2.
3. void blah()
4. {
5. // ...
6. myCode(myNormalFunction);
7. // ...
8. }

What’s the difference between a functionoid and a

functor?
A functionoid is an object that has one major method. It’s basically the OO extension of a C-like
function such as printf(). One would use a functionoid whenever the function has more than one
entry point (i.e., more than one “method”) and/or needs to maintain state between calls in a thread-
safe manner (the C-style approach to maintaining state between calls is to add a local “static”
variable to the function, but that is horribly unsafe in a multi-threaded environment).
A functor is a special case of a functionoid: it is a functionoid whose method is the “function-call
operator,” operator()(). Since it overloads the function-call operator, code can call its major method
using the same syntax they would for a function call. E.g., if “foo” is a functor, to call the
“operator()()” method on the “foo” object one would say “foo()”. The benefit of this is in templates,
since then the template can have a template parameter that will be used as a function, and this
parameter can be either the name of a function or a functor-object. There is a performance
 advantage of it being a functor object since the “operator()()” method can be inlined (whereas if you
pass the address of a function it must, necessarily, be non-inlined).
This is very useful for things like the “comparison” function on sorted containers. In C, the
comparison function is always passed by pointer (e.g., see the signature to “qsort()”), but in C++ the
parameter can come in either as a pointer to function OR as the name of a functor-object, and the
result is that sorted containers in C++ can be, in some cases, a lot faster (and never slower) than the
equivalent in C.
Since Java has nothing similar to templates, it must use dynamic binding for all this stuff, and
dynamic binding of necessity means a function call. Normally not a big deal, but in C++ we want to
enable extremely high performance code. That is, C++ has a “pay for it only if you use it”
philosophy, which means the language must never arbitrarily impose any overhead over what the
physical machine is capable of performing (of course a programmer may, optionally, use techniques
such as dynamic binding that will, in general, impose some overhead in exchange for flexibility or
some other “ility”, but it’s up to the designer and programmer to decide whether they want the
benefits (and costs) of such constructs).

Serialization and Unserialization

Save to:
InstapaperPocketReadability
Contents of this section:

 What’s this “serialization” thing all about?

 How do I select the best serialization technique?
 How do I decide whether to serialize to human-readable (“text”) or non-human-readable
(“binary”) format?
 How do I serialize/unserialize simple types like numbers, characters, strings, etc.?
 How exactly do I read/write simple types in human-readable (“text”) format?
 How exactly do I read/write simple types in non-human-readable (“binary”) format?
 How do I serialize objects that aren’t part of an inheritance hierarchy and that don’t contain
pointers to other objects?
 How do I serialize objects that are part of an inheritance hierarchy and that don’t contain
pointers to other objects?
 How do I serialize objects that contain pointers to other objects, but those pointers form a
tree with no cycles and no joins?
 How do I serialize objects that contain pointers to other objects, but those pointers form a
tree with no cycles and only “trivial” joins?
 How do I serialize objects that contain pointers to other objects, and those pointers form a
graph that might have cycles or non-trivial joins?
 Are there any caveats when serializing / unserializing objects?
 What’s all this about graphs, trees, nodes, cycles, joins, and joins at the leaves vs. internal
nodes?
What’s this “serialization” thing all about?
It lets you take an object or group of objects, put them on a disk or send them through a wire or
wireless transport mechanism, then later, perhaps on another computer, reverse the process:
resurrect the original object(s). The basic mechanisms are to flatten object(s) into a one-dimensional
stream of bits, and to turn that stream of bits back into the original object(s).
 Like the Transporter on Star Trek, it’s all about taking something complicated and turning it into a
flat sequence of 1s and 0s, then taking that sequence of 1s and 0s (possibly at another place,
possibly at another time) and reconstructing the original complicated “something.”

How do I select the best serialization technique?

There are lots and lots (and lots) of if’s, and’s and but’s, and in reality there are a whole continuum
of techniques with lots of dimensions. Because I have a finite amount of time (translation: I don’t
get paid for any of this), I’ve simplified it to a decision between using human-readable (“text”) or
non-human-readable (“binary”) format, followed by a list of five techniques arranged more-or-less
in increasing order of sophistication.
You are, of course, not limited to those five techniques. You will probably end up mixing ideas
from several techniques. And certainly you can always use a more sophisticated (higher numbered)
technique than is actually needed. In fact it might be wise to use a more sophisticated technique than
is minimally needed if you believe future changes will require the greater sophistication. So think of
this list merely as a good starting point.
There’s a lot here, so get ready!
1. Decide between human-readable (“text”) and non-human-readable (“binary”) formats. The
tradeoffs are non-trivial. Later FAQs show how to write simple types in text format and how to
write simple types in binary format.
2. Use the least sophisticated solution when the objects to be serialized aren’t part of an
inheritance hierarchy (that is, when they’re all of the same class) and when they don’t contain
pointers to other objects.
3. Use the second level of sophistication when the objects to be serialized are part of an
inheritance hierarchy, but when they don’t contain pointers to other objects.
4. Use the third level of sophistication when the objects to be serialized contain pointers to
other objects, but when those pointers form a tree with no cycles and no joins.
5. Use the fourth level of sophistication when the objects to be serialized contain pointers to
other objects, and when those pointers form a graph with no cycles, and with joins at the leaves
only.
6. Use the most sophisticated solution when the objects to be serialized contain pointers to other
objects, and when those pointers form a graph that might have cycles or joins.
Here’s that same information arranged like an algorithm:
1. The first step is to make an eyes-open decision between text- and binary-formats.
2. If your objects aren’t part of an inheritance hierarchy and don’t contain pointers, use solution
#1.
3. Else if your objects don’t contain pointers to other objects, use solution #2.
4. Else if the graph of pointers within your objects contain neither cycles nor joins, use solution
#3.
5. Else if the graph of pointers within your objects don’t contain cycles and if the only joins are
to terminal (leaf) nodes, use solution #4.
6. Else use solution #5.
Remember: feel free to mix and match, to add to the above list, and, if you can justify the added
expense, to use a more sophisticated technique than is minimally required.
One more thing: the issues of inheritance and of pointers within the objects are logically unrelated,
so there’s no theoretical reason for #2 to be any less sophisticated than #3-5. However in practice it
often (not always) works out that way. So please do not think of these categories as somehow sacred
— they’re somewhat arbitrary, and you are expected to mix and match the solutions to fit your
 situation. This whole area of serialization has far more variants and shades of gray than can be
covered in a few questions/answers.
How do I decide whether to serialize to human-readable
(“text”) or non-human-readable (“binary”) format?
Carefully.
There is no “right” answer to this question; it really depends on your goals. Here are a few of the
pros/cons of human-readable (“text”) format vs. non-human-readable (“binary”) format:
 Text format is easier to “desk check.” That means you won’t have to write extra tools to
debug the input and output; you can open the serialized output with a text editor to see if it looks
right.
 Binary format typically uses fewer CPU cycles. However that is relevant only if your
application is CPU bound and you intend to do serialization and/or unserialization on an inner
loop/bottleneck. Remember: 90% of the CPU time is spent in 10% of the code, which means there
won’t be any practical performance benefit unless your “CPU meter” is pegged at 100%, and your
serialization and/or unserialization code is consuming a healthy portion of that 100%.
 Text format lets you ignore programming issues like sizeof and little-endian vs. big-
endian.
 Binary format lets you ignore separations between adjacent values, since many values have
fixed lengths.
 Text format can produce smaller results when most numbers are small and when you need
to textually encode binary results, e.g., uuencode or Base64.
 Binary format can produce smaller results when most numbers are large or when you don’t
need to textually encode binary results.
You might think of others to add as well… The important thing to remember is that one size does
not fit all — make a careful decision here.
One more thing: no matter which you choose, you might want to start each file / stream with a
“magic” tag and a version number. The version number would indicate the format rules. That way if
you decide to make a radical change in the format, you hopefully will still be able to read the output
produced by the old software.

How do I serialize/unserialize simple types like numbers,

characters, strings, etc.?
The answer depends on your decision regarding human-readable (“text”) format vs. non-human-
readable (“binary”) format:
 Here is how to serialize/unserialize simple types in human-readable (“text”) format.
 Here is how to serialize/unserialize simple types in non-human-readable (“binary”) format.
The primitives discussed in those FAQs will be needed for most of the other FAQs in this section.

How exactly do I read/write simple types in human-

readable (“text”) format?
Before you read this, make sure to evaluate all the tradeoffs between human-readable and non-
human-readable formats. The tradeoffs are non-trivial, so you should resist a knee-jerk reaction to
do it the way you did it on the last project — one size does not fit all.
After you have made an eyes-open decision to use human-readable (“text”) format, you should
remember these keys:
 You probably want to use iostream’s >> and << operators rather than
its read() and write() methods. The >> and << operators are better for text mode,
whereas read() and write() are better for binary mode.
 When storing numbers, you’ll probably want to add a separator to prevent items from
running together. One simple approach is to always add a space (' ') before each number, that
way the number 1 followed by the number 2 won’t run together and look like a 12. Since the
leading space will automatically get soaked up by the >> operator, you won’t have to do anything
explicit to extract the leading space in the code that reads things back in.
 String data is tricky because you have to unambiguously know when the string’s body stops.
You can’t unambiguously terminate all strings with a '\n' or '"' or even '\0' if some string
might contain those characters. You might want to use C++ source-code escape-sequences, e.g.,
writing '\' followed by 'n' when you see a newline, etc. After this transformation, you can
either make strings go until end-of-line (meaning they are deliminated by '\n') or you can
delimit them with '"'.
 If you use C++-like escape-sequences for your string data, be sure to always use the same
number of hex digits after '\x' and '\u'. I typically use 2 and 4 digits respectively. Reason: if
you write a smaller number of hex digits, e.g., if you simply use stream << "\\
x" << hex << unsigned(theChar), you’ll get errors when the next character in the string
happens to be a hex digit. E.g., if the string contains '\xF' followed by 'A', you should write "\
x0FA", not "\xFA".
 If you don’t use some sort of escape sequence for characters like '\n', be careful that the
operating system doesn’t mess up your string data. In particular, if you open
a std::fstream without std::ios::binary, some operating systems translate end-of-line
characters.
 Another approach for string data is to prefix the string’s data with an integer length, e.g., to
write "now is the time" as 15:now is the time. Note that this can make it hard for
people to read/write the file, since the value just after that might not have a visible separator, but
you still might find it useful.
Please remember that these are primitives that you will need to use in the other FAQs in this section.

How exactly do I read/write simple types in non-human-

readable (“binary”) format?
Before you read this, make sure to evaluate all the tradeoffs between human-readable and non-
human-readable formats. The tradeoffs are non-trivial, so you should resist a knee-jerk reaction to
do it the way you did it on the last project — one size does not fit all.
After you have made an eyes-open decision to use non-human-readable (“binary”) format, you
should remember these keys:
 Make sure you open the input and output streams using std::ios::binary. Do this even
if you are on a Unix system since it’s easy to do, it documents your intent, and it’s one less non-
portability to locate and change down the road.
 You probably want to use iostream’s read() and write() methods instead of
its >> and << operators. read() and write() are better for binary mode; >> and << are better
for text mode.
 If the binary data might get read by a different computer than the one that wrote it, be very
careful about endian issues (little-endian vs. big-endian) and sizeof issues. The easiest way to
handle this is to anoint one of those two formats as the official “network” format, and to create a
header file that contains machine dependencies (I usually call it machine.h). That header should
define inline functions like readNetworkInt(std::istream& istr) to read a
 “network int,” and so forth for reading and writing all the primitive types. You can define the
format for these pretty much anyway you want. E.g., you might define a “network int” as
exactly 32 bits in little endian format. In any case, the functions in machine.h will do any
necessary endian conversions, sizeof conversions, etc. You’ll either end up with a
different machine.h on each machine architecture, or you’ll end up with a lot of #ifdefs in
your machine.h, but either way, all this ugliness will be buried in a single header, and all the
rest of your code will be clean(er). Note: the floating point differences are the most subtle and
tricky to handle. It can be done, but you’ll have to be careful with things like NaN, over- and
under-flow, #bits in the mantissa or exponent, etc.
 When space-cost is an issue, such as when you are storing the serialized form in a small
memory device or sending it over a slow link, you can compress the stream and/or you can do
some manual tricks. The simplest is to store small numbers in a smaller number of bytes. For
example, to store an unsigned integer in a stream that has 8-bit bytes, you can hijack the 8th bit of
each byte to indicate whether or not there is another byte. That means you get 7 meaningful
bits/byte, so 0…127 fit in 1 byte, 128…16384 fit in 2 bytes, etc. If the average number is smaller
than around half a billion, this will use less space than storing every four-byte unsigned number in
four 8-bit bytes. There are lots of other variations on this theme, e.g., a sorted array of numbers
can store the difference between each number, storing extremely small values in unary format,
etc.
 String data is tricky because you have to unambiguously know when the string’s body stops.
You can’t unambiguously terminate all strings with a '\0' if some string might contain that
character; recall that std::string can store '\0'. The easiest solution is to write the integer
length just before the string data. Make sure the integer length is written in “network format” to
avoid sizeof and endian problems (see the solutions in earlier bullets).
Please remember that these are primitives that you will need to use in the other FAQs in this section.

How do I serialize objects that aren’t part of an

inheritance hierarchy and that don’t contain pointers to
other objects?
This is the least sophisticated problem, and not surprisingly, it is also the least sophisticated
solution:
 Every class should handle its own serialization and unserialization. You will typically create
a member function that serializes the object to some sink (such as a std::ostream), and another
that allocates a new object, or perhaps changes an existing object, setting the member data based
on what it reads from some source (such as a std::istream).
 If your object physically contains another object, e.g., a Car object might have a member
variable of type Engine, the outer object’s serialize() member function should simply call
the appropriate function associated with the member object.
 Use the primitives described earlier to read/write the simple types in text or binary format.
 If a class’s data structure might change someday, the class should write out a version number
at the beginning of the object’s serialized output. Unless you are absolutely sure that there is no
possible chance of the data structure changing at any point in the future, do yourself a favor and
include the version number now. It is much easier to put in a version number from the very
beginning than to add one later when you have an unanticipated data structure change. The
version number simply represents the serialized format; it should not get incremented simply
when the class’s behavior changes. This means the version numbers don’t need to be fancy —
they usually don’t need a major and minor number.
How do I serialize objects that are part of an inheritance
hierarchy and that don’t contain pointers to other
objects?
Suppose you want to serialize a “shape” object, where Shape is an abstract class with derived
classes Rectangle, Ellipse, Line, Text, etc. You would declare a pure
virtual function serialize(std::ostream&) const within class Shape, and make sure the
first thing done by each override is to write out the class’s identity. For
example, Ellipse::serialize(std::ostream&) const would write out the
identifier Ellipse (perhaps as a simple string, but there are several alternatives discussed below).
Things get a little trickier when unserializing the object. You typically start with a static member
function in the base class such as Shape::unserialize(std::istream& istr). This is
declared to return a Shape* or perhaps a smart pointer such as Shape::Ptr. It reads the class-
name identifier, then uses some sort of creational pattern to create the object. For example, you
might have a table that maps from the class name to an object of the class, then use the Virtual
Constructor Idiom to create the object.
Here’s a concrete example: Add a pure virtual method create(std::istream&) const within
base class Shape, and define each override to a one-liner that uses new to allocate an object of the
appropriate derived class. E.g., Ellipse::create(std::istream& istr) const would be {
return new Ellipse(istr); }. Add a static std::map<std::string,Shape*> object
that maps from the class name to a representative (AKA prototype) object of the appropriate class;
e.g., "Ellipse" would map to a new Ellipse().
Function Shape::unserialize(std::istream& istr) would read the class-name, throw an
exception if it’s not in the map (if (theMap.count(className) == 0) throw …
something…), then look up the associated Shape* and call its create() method: return
theMap[className]->create(istr).
The map is typically populated during static initialization. For example, if
file Ellipse.cpp contains the code for derived class Ellipse, it would also contain
a static object whose ctor adds that class to the map: theMap["Ellipse"] = new
Ellipse().
Notes and caveats:
 It adds a little flexibility if Shape::unserialize() passes the class name to
the create() method. In particular, that would let a derived class be used with two or more
names, each with its own “network format.” For example, derived class Ellipse could be used
for both "Ellipse" and "Circle", which might be useful to save space in the output stream or
perhaps other reasons.
 It’s usually easiest to handle errors during unserialization by throwing an exception. You can
return NULL if you want, but you will need to move the code that reads the input stream out of the
derived class’ ctors into the corresponding create() methods, and ultimately the result is often
that your code is more complicated.
 You must be careful to avoid the static initialization order fiasco with the map used
by Shape::unserialize(). This normally means using the Construct On First Use Idiom for
the map itself.
 For the map used by Shape::unserialize(), I personally prefer the Named Constructor
Idiom over the Virtual Constructor Idiom — it simplifies a few steps. Details: I usually define
a typedef within Shape such as typedef Shape* (*Factory)(std::istream&). This
means Shape::Factory is a “pointer to a function that takes a std::istream& and returns
a Shape*.” I then define the map as std::map<std::string,Factory>. Finally I populate
 that map using lines like theMap["Ellipse"] =
Ellipse::create (where Ellipse::create(std::istream&) is now a static member
function of class Ellipse, that is, the Named Constructor Idiom). You’d change
the return value in function Shape::unserialize(std::istream&
istr) from theMap[className]->create(istr) to theMap[className](istr).
 If you might need to serialize a NULL pointer, it’s usually easy since you already write out a
class identifier so you can just as easily write out a pseudo class identifier like "NULL". You
might need an extra if statement in Shape::unserialize(), but if you chose my preference
from the previous bullet, you can eliminate that special case (and generally keep your code clean)
by defining static member function Shape*
Shape::nullFactory(istream&) { return NULL; }. You add that function to the map as
any other: theMap["NULL"] = Shape::nullFactory;.
 You can make the serialized form smaller and a little faster if you tokenize the class name
identifiers. For example, write a class name only the first time it is seen, and for subsequent uses
write only a corresponding integer index. A mapping such
as std::map<std::string,unsigned> unique makes this easy: if a class name is already
in the map, write unique[className]; otherwise set a variable unsigned n =
unique.size(), write n, write the class name, and set unique[className] = n. (Note:
be sure to copy it into a separate variable. Do not say unique[className] =
unique.size()! You have been warned! Reason: the compiler might
evaluate unique[className] before unique.size(), and if so, unique[className] will
pre-increment the size.) When unserializing, use std::vector<std::string> unique, read
the number n, and if n == unique.size(), read a name and add it to the vector. Either way
the name will be unique[n]. You can also pre-populate the first N slots in these tables with
the N most common names, that way streams won’t need to contain any of those strings.
How do I serialize objects that contain pointers to other
objects, but those pointers form a tree with no cycles and
no joins?
Before we even start, you must understand that the word “tree” does not mean that the objects are
stored in some sort of tree-like data structure like std::set. It simply means that your objects
point to each other, and the “with no cycles” part means if you keep following pointers from one
object to the next, you never return to an earlier object. Your objects aren’t “inside” a tree;
they are a tree. If you don’t understand that, you really should read the lingo FAQ before continuing
with this one.
Second, don’t use this technique if the graph might someday contain cycles or joins.
Graphs with neither cycles nor joins are very common, even with “recursive composition” design
patterns like Composite or Decorator. For example, the objects representing an XML document or
an HTML document can be represented as a graph without joins or cycles.
The key to serializing these graphs is to ignore a node’s identity and instead to focus only on
its contents. A (typically recursive) algorithm dives through the tree and writes the contents as it
goes. For example, if the current node happens to have an integer a, a pointer b, a float c, and
another pointer d, then you first write the integer a, then recursively dive into the child pointed to
by b, then write the float c, and finally recursively dive into the child pointed to by d. (You don’t
have to write/read them in the declaration order; the only essential rule is that the reader’s order is
consistent with the writer’s order.)
When unserializing, you need a constructor that takes a std::istream&. The constructor for the
above object would read an integer and store the result in a, then would allocate an object to be
stored in pointer b (and will pass the std::istream to the constructor so it too can read the
 stream’s contents), read a float into c, and finally will allocate an object to be stored in pointer d.
Be sure to use smart pointers within your objects, otherwise you will get a leak if an exception is
thrown while reading anything but the first pointed-to object.
It is often convenient to use the Named Constructor Idiom when allocating these objects. This has
the advantage that you can enforce the use of smart pointers. To do this in a class Foo, write
a static method such as FooPtr Foo::create(std::istream& istr) { return new
Foo(istr); } (where FooPtr is a smart pointer to a Foo). The alert reader will note how
consistent this is with the technique discussed in the previous FAQ — the two techniques are
completely compatible.
If an object can contain a variable number of children, e.g., a std::vector of pointers, then the
usual approach is to write the number of children just before recursively diving into the first child.
When unserializing, just read the number of children, then use a loop to allocate the appropriate
number of child objects.
If a child-pointer might be NULL, be sure to handle that in both the writing and reading. This
shouldn’t be a problem if your objects use inheritance; see that solution for details. Otherwise, if the
first serialized character in an object has a known range, use something outside that range. E.g., if
the first character of a serialized object is always a digit, use a non-digit like 'N' to mean
a NULL pointer. Unseralization can use std::istream::peek() to check for the 'N' tag. If the
first character doesn’t have a known range, force one; e.g., write 'x' before each object, then use
something else like 'y' to mean NULL.
If an object physically contains another object inside itself, as opposed to containing a pointer to the
other object, then nothing changes: you still recursively dive into the child-node as if it were via a
pointer.

How do I serialize objects that contain pointers to other

objects, but those pointers form a tree with no cycles and
only “trivial” joins?
As before, the word “tree” does not mean that the objects are stored in some sort of tree-like data
structure like std::set. It simply means your objects have pointers to each other, and the “no
cycles” part means you can follow the pointers from one object to the next and never return to an
earlier object. The objects are not “inside” a tree; they are a tree. If that doesn’t make sense,
you really should read the lingo FAQ before continuing with this one.
Use this solution if the graph contains joins at the leaf nodes, but those joins can be easily
reconstructed via a simple look-up table. For example, the parse-tree of an arithmetic expression
like (3*(a+b) - 1/a) might have joins since a variable-name (like a) can show up more than
once. If you want the graph to use the same exact node-object to represent both occurrences of that
variable, then you could use this solution.
Although the above constraints don’t fit with those of the solution without any joins, it’s so close
that you can squeeze things into that solution. Here are the differences:
 During serialization, ignore the join completely.
 During unserializing, create a look-up table, like std::map<std::string,Node*>, that
maps from the variable name to the associated node.
Caveat: this assumes that all occurrences of variable a should map to the same node object; if it’s
more complicated than this, that is, if some occurrences of a should map to one object and some to
another, you might need to use a more sophisticated solution.
Caveat: you need to take special care if your objects contain pointers which point to a member of
some object, rather than to the object itself. For example, if pointer ‘p’ points to ‘x.y’ and pointer ‘q’
points to ‘x.z’, that is, they point to data members within object ‘x’ rather than to object ‘x’ itself,
when you serialize the pointers, you need to recognize both point to the same identical object. You
 will need to serialize object ‘x’, not just ‘x.y’ and ‘x.z’, and you need to make sure upon
unserialization ‘p’ and ‘q’ point again to the same identical object. The serialization process will
probably require a two-pass approach, and serialized pointer will probably need to store an offset
within the target object as well as the target object’s ID.

How do I serialize objects that contain pointers to other

objects, and those pointers form a graph that might have
cycles or non-trivial joins?
Caveat: the word “graph” does not mean that the objects are stored in some sort of data structure.
Your objects form a graph because they point to each other. They’re not “inside” a graph; they are a
graph. If that doesn’t make sense, you really should read the lingo FAQ before continuing with this
one.
Use this solution if the graph can contain cycles, or if it can contain more complicated kinds
of joins than are allowed by the solution for trivial joins. This solution handles two core issues: it
avoids infinite recursion and it writes/reads each node’s identity in addition to its contents.
A node’s identity doesn’t normally have to be consistent between different output streams. For
example, if a particular file uses the number 3 to represent node x, a different file can use the
number 3 to represent a different node, y.
There are some clever ways to serialize the graph, but the simplest to describe is a two-pass
algorithm that uses an object-ID map, e.g., std::map<Node*,unsigned> oidMap. The first pass
populates our oidMap, that is, it builds a mapping from object pointer to the integer that represents
the object’s identity. It does this by recursively diving through the graph, at each node checking if
the node is already in oidMap, and if not, adding the node and a unique integer to oidMap and
recursively diving into the new node’s children. The unique integer is often just the
initial oidMap.size(), e.g., unsigned n = oidMap.size(); oidMap[nodePtr] = n.
(Yes, we did that in two statements. You must also. Do not shorten it to a single statement. You
have been warned.)
The second pass iterates through the nodes of oidMap, and at each, writes the node’s identity (the
associated integer) followed by its contents. When writing the contents of a node that contains
pointers to other nodes, instead of diving into those “child” objects, it simply writes the identity (the
associated integer) of the pointer to those nodes. For example, when your node contains Node*
child, simply write the integer oidMap[child]. After the second pass, the oidMap can be
discarded. In other words, the mapping from Node* to unsigned should not normally survive
beyond the end of the serialization of any given graph.
There are also some clever ways to unserialize the graph, but here again the simplest to describe is a
two-pass algorithm. The first pass populates a std::vector<Node*> v with objects of the right
class, but any child pointers within those objects are all NULL. This means v[3] will point to the
object whose oid is 3, but any child pointers inside that object will be NULL. The second pass
populates the child pointers inside the objects, e.g., if v[3] has a child pointer called child that is
supposed to point to the object whose oid is 5, the second pass changes
changes v[3].child from NULL to v[5] (obviously encapsulation might prevent it from directly
accessing v[3].child, but ultimately v[3].child gets changed to v[5]). After unserializing a
given stream, the vector v can normally be discarded. In other words, the oids (3, 5, etc.)
mean nothing when serializing or unserializing a different stream — those numbers are only
meaningful within a given stream.
Note: if your objects contain polymorphic pointers, that is, base class pointers that might point at
derived class objects, then use the technique described earlier. You’ll also want to read some of the
earlier techniques for handling NULL, writing version numbers, etc.
 Note: you should seriously consider the Visitor pattern when recursively diving through the graph,
since serialization is probably just one of many different reasons to make that recursive dive, and
they’ll all need to avoid infinite recursion.
Are there any caveats when serializing / unserializing
objects?
One of the things you don’t want to do, except in unusual circumstances, is to make any changes to
the node’s data during the traversal. For example, some people feel they can map from Node* to
integer by simply adding an integer as a data member in the Node class. They also sometimes add
a bool haveVisited flag as another data member within Node objects.
But this causes lots of multi-threading and/or performance problems. Your serialize() method
can no longer be const, so even though it is logically just a reader of the node data, and even
though it logically makes sense to have multiple threads reading the nodes at the same time, the
actual algorithm writes into the nodes. If you fully understand threading and reader/writer conflicts,
the best you can hope for is to make your code more complicated and slower (you’ll have to block
all reader threads whenever any thread is doing anything with the graph). If you (or those who will
maintain the code after you!) don’t fully understand reader/writer conflicts, this technique can create
very serious and very subtle errors. Reader/writer and writer/writer conflicts are so subtle they often
slip through test into the field. Bad news. Trust me. If you don’t trust me, talk to someone you do
trust. But don’t cut corners.
There’s lots more I could say, such as several simplifications and special cases, but I’ve already
spent too much time on this. If you want more info, spend some money.

What’s all this about graphs, trees, nodes, cycles, joins,

and joins at the leaves vs. internal nodes?
When your objects contain pointers to other objects, you end up with something computer scientists
call a graph. Not that your objects are stored inside a tree-like data structure; they are a tree-like
structure.
Your objects correspond to the graph’s nodes AKA vertices, and the pointers within your objects
correspond to the graph’s edges. The graph is of a special variety called a rooted, directed graph.
The root object to be serialized corresponds to the graph’s root node, and the pointers correspond
to directed edges.
If object x has a pointer to object y, we say that x is a parent of y and/or that y is a child of x.
A path through a graph corresponds to starting with an object, following a pointer to another object,
etc., etc. to an arbitrary depth. If there is a path from x to z we say that x is an ancestor of z and/or
that z is a descendent of x.
A join in a graph means there are two or more distinct paths to the same object. For example, if z is
a child of both x and y, then the graph has a join, and z is a join node.
A cycle in a graph means there is a path from an object back to itself: if x has a pointer to itself, or
to y which points to x, or to y which points to z which points to x, etc. A graph is cyclic if it has one
or more cycles; otherwise it is acyclic.
An internal node is a node with children. A leaf node is a node without children.
As used in this section, the word tree means a rooted, directed, acyclic graph. Note that each node
within a tree is also a tree.

C++11 Overview
Save to:
InstapaperPocketReadability
Contents of this section:
 C++11: Purpose of this FAQ section
 What is C++11?
 What is C++0x?
 When will compilers implement C++11?
 How did the committee approach picking new language and library features for C++11?
 What were the general design goals of the C++11 effort?
 What specific design goals guided the committee?
 Where can I find the committee papers for C++11 features?
 Where can I find academic and technical papers about C++11?
 Where else can I read about C++11?
 Are there any videos about C++11?
 Is C++11 hard to learn?
 Is C++11 the final C++ standard?
C++11: Purpose of this FAQ section
The purpose of this FAQ’s C++11 sections (including this section) is:
 To give an overview of the new facilities (language features and standard libraries) offered
by C++11 in addition to what is provided by the previous version of the ISO C++ standard.
 To give an idea of the aims of the ISO C++ standards effort.
 To present a user’s view of the new facilities
 To provide references to allow for a more in depth study of features.
 To name many of the individuals who contributed (mostly as authors of the reports they
wrote for the committee). The standard is not written by a faceless organization.
We often borrow examples from the proposals. In those cases: Thanks to the proposal authors.
Many other examples are borrowed from Stroustrup’s talks and papers.
Please note that the purpose of this FAQ is not to provide comprehensive discussion of individual
features or a detailed explanation of how to use them. The aim is to give simple examples to
demonstrate what C++11 has to offer (plus references). Our ideal is “max one page per feature”
independently of how complex a feature is. Details can often be found in the references.
See the FAQ Home page for a list of all C++11 sections.

What is C++11?
C++11 is the ISO C++ standard formally ratified by a 21-0 national vote in August 2011.
This public working paper is the January 2012 working draft, and contains the C++11 standard plus
minor editorial changes.
C++11 is a major upgrade over C++98/03, with performance and convenience features that make it
feel like a new language.
The previous (and first) standard is often referred to as C++98 or C++03; the differences between
C++98 and C++03 are so few and so technical that they ought not concern users. This FAQ
discusses changes between C++98/C++03 to C++11.
What is C++0x?
The “under-development” name for C++11. Before its official ratification in 2011, the then-under-
development standard was unofficially called C++0x, as it was hoped to be completed in C++08 or
C++09. Think of ‘x’ as hexadecimal (i.e., C++0B == C++11).
When will compilers implement C++11?
 Currently shipping compilers (e.g. GCC C++, Clang C++, IBM C++, and Microsoft C++) already
implement most or all C++11 features, and are working on C++14 features.
Modulo bugs, the first fully conforming C++11 language implementation was GCC 4.8.1 (May 31,
2013) but it still did not have a conforming standard library. The first complete C++11
implementation, including both the language and the standard library, was Clang 3.3 (June 5, 2013).
Here are links to C++11 information from purveyors:
 comparison
 GCC
 IBM
 Microsoft
 EDG
 Clang
How did the committee approach picking new language
and library features for C++11?
You don’t improve a language by simply adding every feature that someone considers a good idea.
In fact, essentially every feature of most modern languages has been suggested for C++ by
someone: Try to imagine what the union of C99, C#, Java, Haskell, Lisp, Python, and Ada would
look like. To make the problem more difficult, remember that it is not feasible to eliminate older
features, even in the reasonably rare cases when the committee agrees that they are bad: Experience
shows that users force every implementer to keep providing deprecated and banned features under
compatibility switches (or by default) for decades.
In addition to the general design goals, to try to select rationally from the flood of suggestions the
committee devised a set of specific design goals. The result has been a language with greatly
improved abstraction mechanisms. The range of abstractions that C++ can express elegantly,
flexibly, and at zero cost compared to hand-crafted specialized code has greatly increased. When we
say “abstraction” people often just think “classes” or “objects.” C++11 goes far beyond that: The
range of user-defined types that can be cleanly and safely expressed has grown with the addition of
features such as initializer-lists, uniform initialization, template aliases, rvalue references, defaulted
and deleted functions, and variadic templates. Their implementation eased with features, such
as auto, inherited constructors, and decltype. These enhancements are sufficient to make C++11 feel
like a new language.
For information about accepted language features, see the C++11 language extensions sections of
this FAQ, listed on the FAQ Home page.
The standard library definition is already about 70% of the normative text of the standard (and that
doesn’t count the C standard library, which is included by reference). Even though some members
would have liked to see many more standard libraries, nobody could claim that the Library Working
Group has been lazy. It is also worth noting that the C++98 libraries have been significantly
improved through the use of new language features, such as initializer-lists, rvalue
references, variadic templates, noexcept, and constexpr. The C++11 standard library is easier to
use and provides better performance than the C++98 one.
For information about accepted library features, see the C++11 library extensions sections of this
FAQ, listed on the FAQ Home page.

What were the general design goals of the C++11

effort?
 C++ has from its inception been a general-purpose programming language with a bias towards
systems programming that
 is a better C
 supports data abstraction
 supports object-oriented programming
 supports generic programming
The overall aims of the C++11 effort was to strengthen that:
 Make C++ a better language for systems programming and library building – that is, to build
directly on C++’s contributions to programming, rather than providing specialized facilities for a
particular sub-community (e.g. numeric computation or Windows-style application development).
 Make C++ easier to teach and learn – through increased uniformity, stronger guarantees, and
facilities supportive of novices (there will always be more novices than experts).
 Naturally, this is done under very stringent compatibility constraints. Only very rarely is the
committee willing to break standards conforming code, though that’s done when a new keyword
(e.g. static_assert, nullptr, and constexpr) is introduced.
For more details see:
 B. Stroustrup: What is C++11?. CVu. Vol 21, Issues 4 and 5. 2009.
 B. Stroustrup: Evolving a language in and for the real world: C++ 1991-2006. ACM HOPL-
III. June 2007.
 B. Stroustrup: A History of C++: 1979-1991. Proc ACM History of Programming Languages
conference (HOPL-2). March 1993.
 B. Stroustrup: C and C++: Siblings. The C/C++ Users Journal. July 2002.
What specific design goals guided the committee?
Naturally, different people and different organizations involved with the standardization have
somewhat different aims, especially when it comes to details and to priorities. Also, detailed aims
change over time. Please remember that the committee can’t even do all that everyone agrees would
be good things – it consists of volunteers with very limited resources. However, here are a set of
criteria that has seen real use in the discussion of which features and libraries were appropriate for
C++11:
 Maintain stability and compatibility – don’t break old code, and if you absolutely must, don’t
break it quietly.
 Prefer libraries to language extensions – an ideal at which the committee wasn’t all that
successful; too many people in the committee and elsewhere prefer “real language features.”
 Prefer generality to specialization – focus on improving the abstraction mechanisms (classes,
templates, etc.).
 Support both experts and novices – novices can be helped by better libraries and through
more general rules; experts need general and efficient features.
 Increase type safety – primarily though facilities that allow programmers to avoid type-
unsafe features.
 Improve performance and ability to work directly with hardware – make C++ even better for
embedded systems programming and high-performance computation.
 Fit into the real world – consider tool chains, implementation cost, transition problems, ABI
issues, teaching and learning, etc.
Note that integrating features (new and old) to work in combination is the key – and most of the
work. The whole is much more than the simple sum of its parts.
Another way of looking at detailed aims is to look at areas of use and styles of usage:
 Machine model and concurrency – provide stronger guarantees for and better facilities for
using modern hardware (e.g. multicores and weakly coherent memory models). Examples
are threads, futures, thread-local storage, and atomics.
 Generic programming – GP is among the great success stories of C++98; we needed to
improve support for it based on experience. Examples are auto and template aliases.
 Systems programming – improve the support for close-to-the-hardware programming (e.g.
low-level embedded systems programming) and efficiency. Examples
are constexpr, std::array, and generalized PODs.
 Library building – remove limitations, inefficiencies, and irregularities from the abstraction
mechanisms. Examples are inline namespace, inherited constructors, and rvalue references.
Where can I find the committee papers for C++11
features?
Go to the committee papers archive and focus mainly on 2005 through early 2011. There you will
most likely drown in details. Look for “issues lists” and “State of” (e.g. State of Evolution (July
2008)) lists. The key groups then active were
 Core (CWG) – dealing with language-technical issues and formulation
 Evolution (EWG) – dealing with language feature proposals and issues crossing the
language/library boundary
 Library (LWG) – dealing with library facility proposals
Where can I find academic and technical papers about C+
+11?
Here is an incomplete list. To suggest additions or corrections, use the Suggestion icon on this FAQ
heading (you can do that on any FAQ of course).
 Bjarne Stroustrup: Software Development for Infrastructure. Computer, vol. 45, no. 1, pp.
47-58, Jan. 2012, doi:10.1109/MC.2011.353. Here is a video interview about that paper and video
of a talk on a very similar topic (That’s a 90 minute talk incl. Q&A).
 Saeed Amrollahi: Modern Programming in the New Millenium: A Technical Survey on
Outstanding features of C++0x. Computer Report (Gozaresh-e Computer), No.199, November
2011 (Mehr and Aban 1390), pages 60-82. (in Persian)
 Mark Batty et al’s: Mathematizing C++ concurrency, POPL 2012. // thorough, precise, and
mathematical.
 Gabriel Dos Reis and Bjarne Stroustrup: General Constant Expressions for System
Programming Languages. SAC-2010. The 25th ACM Symposium On Applied Computing.
 Hans-J. Boehm and Sarita V. Adve: Foundations of the C++ concurrency memory model.
ACM PLDI’08.
 Hans-J. Boehm: Threads Basic. HPL technical report 2009-259 // “what every programmer
should know about memory model issues”
 Douglas Gregor, Jaakko Jarvi, Jeremy Siek, Bjarne Stroustrup, Gabriel Dos Reis, and
Andrew Lumsdaine: Concepts: Linguistic Support for Generic Programming in C++.
OOPSLA’06, October 2006. // The concept design and implementation as it stood in 2006; it has
improved since, though not sufficiently to save it for C++11, and is now being worked on for a
future C++ standard.
 Douglas Gregor and Jaakko Jarvi: Variadic templates for C++0x. Journal of Object
Technology, 7(2):31-51, February 2008.
 Jaakko Jarvi and John Freeman: Lambda functions for C++0x. ACM SAC ‘08.
 M. Paterno and W. E. Brown: Improving Standard C++ for the Physics Community.
CHEP’04. // Much has been improved since then!
 Michael Spertus and Hans J. Boehm: The Status of Garbage Collection in C++0X. ACM
ISMM’09.
 Verity Stob: An unthinking programmer’s guide to the new C++ – Raising the standard. The
Register. May 2009. (Humor (I hope)).
 [N1781=05-0041] Bjarne Stroustrup: Rules of thumb for the design of C++0x.
 Bjarne Stroustrup: Evolving a language in and for the real world: C++ 1991-2006. ACM
HOPL-III. June 2007. (incl. slides and videos). // Covers the design aims of C++0x, the standards
process, and the progress up until 2007.
 B. Stroustrup: What is C++0x?. CVu. Vol 21, Issues 4 and 5. 2009.
 Anthony Williams: Simpler Multithreading in C++0x. devx.com.
Where else can I read about C++11?
The amount of information about C++11 is increasing as most C++ implementations provide the
new language features and libraries. Here is a short list of sources:
 B. Stroustrup: The C++ Programming Language (Fourth Edition).
 B. Stroustrup: A Tour of C++.
 The committe papers archive.
 The C++11 standard (closest public approximation)
 The C++11 Wikipedia entry. This seems to be actively maintained, though apparently not by
members of the committee.
 A list of support for C++11 features.
Are there any videos about C++11?
Yes:
 B. Stroustrup, H. Sutter, H-J. Boehm, A. Alexandrescu, S.T.Lavavej, Chandler Carruth, and
Andrew Sutton: Several talks and panels from the GoingNative 2012 conference.
 B. Stroustrup, H. Sutter, S. Meyers, A. Alexandrescu, S.T.Lavavej, Chandler Carruth, S.
Parent, and M. Wong: Several talks and panels from the GoingNative 2013 conference.
 Herb Sutter: Writing Modern C++ Code: How C++ has evolved over the years. September
2011.
 Herb Sutter: Why C++?. C++ and Beyond 2011, August 2011.
 Herb Sutter: (Not Your Father’s) C++. Lang.NEXT, April 2012.
 Herb Sutter: atomic<> Weapons: The C++ Memory Model and Modern Hardware, Part
1, Part 2, Slides, from C++ and Beyond, August 2012.
 Lawrence Crowl: Lawrence Crowl on C++ Threads. in Sophia Antipolis, June 2008.
 Bjarne Stroustrup: The design of C++0x. University of Waterloo, 2007.
 Bjarne Stroustrup: Initialization. Google, 2007.
 Bjarne Stroustrup: C++0x – An overview. in Sophia Antipolis, June 2008.
 Lawrence Crowl: Threads.
 Roger Orr: C++0x. January 2008.
 Hans-J. Boehm: Getting C++ Threads Right. December 2007.
Is C++11 hard to learn?
C++11 makes C++ easier to learn than ever, and has near-perfect compatibility with C++98/03.
For those who have never used C++, C++11 is far easier to learn than the previous version of the
language. Even though there are more features, the code you write tends to be simpler and many
things that used to be hard or obscure aren’t any more. (Of course, like any general-purpose
language, there are still some hard or obscure parts.) In fact, Stroustrup now covers the essentials of
the entire C++11 language and library in one concise 180-page book, A Tour of C++.
 If you know C++98/03, essentially all your code will continue to work unchanged because C++11 is
nearly perfectly backward-compatible with the previous standard. However, as you learn the new
features, you will find that they often make your code simpler (e.g., auto), clearer (e.g., template
aliases instead of typedef), more powerful and expressive (e.g., lambda functions), and faster than
ever (e.g., rvalue references and move semantics will often make your existing C++ code faster
simply by recompiling it with a C++11 compiler!). The extra simplicity and clarity really make C+
+11 feel like a fresh new language.
Clearly C++11 is bigger than C++98 and has more features. So how can it be easier to learn? When
designing C++11, the committee used several tools for simplification (from the point of view of
learners), including:
 Generalization: In some cases C++11 replaces, say, three rules with one more general rule
(e.g., uniform initialization, inheriting constructors, and threads). It also removes special cases so
there’s less to learn (as a trivial example, vector<vector<int>> is perfectly legal now without
putting a space between >>). All of this reduces “concept count” or the number of things to
memorize by rote; for example, a rule with three exceptions or special cases has a concept count
of four things to memorize, whereas two general rules that just work together in all combinations
have a concept count of just two things to memorize, yet can often express much more than the
single rule with three special cases.
 Simpler alternatives: In other cases C++11 provides new facilities that are easier to use than
their older alternatives (e.g., std::array, auto, range-for statement, and regex).
A word of caution: People who insist on teaching C++ “from the bottom up” (corner cases first, C
subset first, etc.) will nullify any such advantage and make the language appear obscure and hard.
This is not necessary or desirable. We are finally getting better materials that teach C++ from the
top down, notably Stroustrup’s A Tour of C++. If you see people learning C++ from the bottom up,
steer them to the Tour and similar materials as quickly as possible.
Is C++11 the final C++ standard?
No. The upcoming next C++ International Standard is called C++14 as it is expected to be
published in 2014, and as of this writing it is nearly finalized. The committee is also working on
issuing numerous Technical Specifications due in 2014 onward, on topics from low-level libraries
like File System and Networking to Concurrency and Parallelism and Concepts, and more. Many of
these Technical Specifications are expected to become part of the next major actual C++
International Standard, currently expected in about 2017.
For the latest details, see the current status page.

C++11 Language Extensions — General

Features
Save to:
InstapaperPocketReadability
Contents of this section:

 auto
 decltype
 Range-for statement
 Initializer lists
 Uniform initialization syntax and semantics
 Rvalue references and move semantics
 Lambdas
 noexcept to prevent exception propagation
  constexpr
 nullptr – a null pointer literal
 Copying and rethrowing exceptions
 Inline namespaces
 User-defined literals
auto
Consider
1. auto x = 7;
Here x will have the type int because that’s the type of its initializer. In general, we can write
1. auto x = expression;
and the type of x will be the type of the value computed from “expression”.
The use of auto to deduce the type of a variable from its initializer is obviously most useful when
that type is either hard to know exactly or hard to write. Consider:
1. template<class T> void printall(const vector<T>& v)
2. {
3. for (auto p = v.begin(); p!=v.end(); ++p)
4. cout << *p << "\n";
5. }
In C++98, we’d have to write
1. template<class T> void printall(const vector<T>& v)
2. {
3. for (typename vector<T>::const_iterator p = v.begin(); p!=v.end(); ++p)
4. cout << *p << "\n";
5. }
When the type of a variable depends critically on template argument it can be really hard to write
code without auto. For example:
1. template<class T, class U> void multiply(const vector<T>& vt, const vector<U>& vu)
2. {
3. // ...
4. auto tmp = vt[i]*vu[i];
5. // ...
6. }
The type of tmp should be what you get from multiplying a T by a U, but exactly what that is can be
hard for the human reader to figure out, though of course the compiler knows once it has figured out
what particular T and U it is dealing with.
The auto feature has the distinction to be the earliest to be suggested and implemented: Stroustrup
had it working in his Cfront implementation in early 1984, but was forced to take it out because of
C compatibility problems. Those compatibility problems disappeared when C++98 and C99
accepted the removal of “implicit int”; that is, both languages now require every variable and
function to be defined with an explicit type. The old meaning of auto (namely “this is a local
variable”) is now illegal. Several committee members trawled through millions of lines of code
finding only a handful of uses – and most of those were in test suites or appeared to be bugs.
Being primarily a facility to simplify notation in code, auto does not affect the standard library
specification.
See also:
 the C++ draft section 7.1.6.2, 7.1.6.4, 8.3.5 (for return types)
 [N1984=06-0054] Jaakko Jarvi, Bjarne Stroustrup, and Gabriel Dos Reis: Deducing the type
of variable from its initializer expression (revision 4).
 Herb Sutter: GotW #92: Auto Variables, Part 1
 Herb Sutter: GotW #93: Auto Variables, Part 2
  Herb Sutter: GotW #94: AAA Style (Almost Always Auto)
decltype
decltype(E) is the type (“declared type”) of the name or expression E and can be used in
declarations. For example:
1. void f(const vector<int>& a, vector<float>& b)
2. {
3. typedef decltype(a[0]*b[0]) Tmp;
4. for (int i=0; i<b.size(); ++i) {
5. Tmp* p = new Tmp(a[i]*b[i]);
6. // ...
7. }
8. // ...
9. }
This notion has been popular in generic programming under the label “typeof” for a long time, but
the “typeof” implementations in actual use were incomplete and incompatible, so the standard
version is named decltype.
Note: Prefer just using auto when you just need the type for a variable that you are about to
initialize. You really need decltype if you need a type for something that is not a variable, such as
a return type.
See also:
 the C++ draft 7.1.6.2 Simple type specifiers
 [Str02] Bjarne Stroustrup. Draft proposal for “typeof”. C++ reflector message c++std-ext-
5364, October 2002. (original suggestion).
 [N1478=03-0061] Jaakko Jarvi, Bjarne Stroustrup, Douglas Gregor, and Jeremy
Siek: Decltype and auto (original proposal).
 [N2343=07-0203] Jaakko Jarvi, Bjarne Stroustrup, and Gabriel Dos Reis: Decltype (revision
7): proposed wording.
Range-for statement
A range for statement allows you to iterate through a “range”, which is anything you can iterate
through like an STL-sequence defined by a begin() and end(). All standard containers can be
used as a range, as can a std::string, an initializer list, an array, and anything for which you
define begin() and end(), e.g. an istream. For example:
1. void f(vector<double>& v)
2. {
3. for (auto x : v) cout << x << '\n';
4. for (auto& x : v) ++x; // using a reference to allow us to change the value
5. }
You can read that as “for all x in v” going through starting with v.begin() and iterating
to v.end(). Another example:
1. for (const auto x : { 1,2,3,5,8,13,21,34 }) cout << x << '\n';
The begin() (and end()) can be a member to be called as x.begin() or a free-standing function
to be called as begin(x). The member version takes precedence.
See also:
 the C++ draft section 6.5.4 (note: changed not to use concepts)
 [N2243==07-0103] Thorsten Ottosen: Wording for range-based for-loop (revision 2).
 [N3257=11-0027 ] Jonathan Wakely and Bjarne Stroustrup: Range-based for statements and
ADL (Option 5 was chosen).
Initializer lists
 Consider
1. vector<double> v = { 1, 2, 3.456, 99.99 };
2. list<pair<string,string>> languages = {
3. {"Nygaard","Simula"}, {"Richards","BCPL"}, {"Ritchie","C"}
4. };
5. map<vector<string>,vector<int>> years = {
6. { {"Maurice","Vincent", "Wilkes"},{1913, 1945, 1951, 1967, 2000} },
7. { {"Martin", "Ritchards"}, {1982, 2003, 2007} },
8. { {"David", "John", "Wheeler"}, {1927, 1947, 1951, 2004} }
9. };
Initializer lists are not just for arrays any more. The mechanism for accepting a {}-list is a function
(often a constructor) accepting an argument of type std::initializer_list<T>. For example:
1. void f(initializer_list<int>);
2. f({1,2});
3. f({23,345,4567,56789});
4. f({}); // the empty list
5. f{1,2}; // error: function call ( ) missing
6.
7. years.insert({{"Bjarne","Stroustrup"},{1950, 1975, 1985}});
The initializer list can be of arbitrary length, but must be homogeneous (all elements must be of the
template argument type, T, or convertible to T).
A container might implement an initializer-list constructor like this:
1. template<class E> class vector {
2. public:
3. vector (std::initializer_list<E> s) // initializer-list constructor
4. {
5. reserve(s.size()); // get the right amount of space
6. uninitialized_copy(s.begin(), s.end(), elem); // initialize elements (in elem[0:s.size()))
7. sz = s.size(); // set vector size
8. }
9.
10. // ... as before ...
11. };
The distinction between direct initialization and copy initialization is maintained for {}-
initialization, but becomes relevant less frequently because of {}-initialization. For
example, std::vector has an explicit constructor from int and
an initializer_list constructor:
1. vector<double> v1(7); // ok: v1 has 7 elements
2. v1 = 9; // error: no conversion from int to vector
3. vector<double> v2 = 9; // error: no conversion from int to vector
4.
5. void f(const vector<double>&);
6. f(9); // error: no conversion from int to vector
7.
8. vector<double> v1{7}; // ok: v1 has 1 element (with its value 7.0)
9. v1 = {9}; // ok v1 now has 1 element (with its value 9.0)
10. vector<double> v2 = {9}; // ok: v2 has 1 element (with its value 9.0)
11. f({9}); // ok: f is called with the list { 9 }
12.
13. vector<vector<double>> vs = {
14. vector<double>(10), // ok: explicit construction (10 elements)
15. vector<double>{10}, // ok explicit construction (1 element with the value 10.0)
16. 10 // error: vector's constructor is explicit
17. };
 The function can access the initializer_list as an immutable sequence. For example:
1. void f(initializer_list<int> args)
2. {
3. for (auto p=args.begin(); p!=args.end(); ++p) cout << *p << "\n";
4. }
A constructor that takes a single argument of type std::initializer_list is called an
initializer-list constructor.
The standard library containers, string, and regex have initializer-list constructors, assignment,
etc. An initializer-list can be used as a range, e.g. in a range for statement.
The initializer lists are part of the scheme for uniform and general initialization. They also prevent
narrowing. In general, you should usually prefer initializing using {} instead of () unless you want
to share code with a C++98 compiler or (rarely) need to use () to call a non-
initializer_list overloaded constructor.
See also:
 the C++ draft 8.5.4 List-initialization [dcl.init.list]
 [N1890=05-0150 ] Bjarne Stroustrup and Gabriel Dos Reis: Initialization and initializers (an
overview of initialization-related problems with suggested solutions).
 [N1919=05-0179] Bjarne Stroustrup and Gabriel Dos Reis: Initializer lists.
 [N2215=07-0075] Bjarne Stroustrup and Gabriel Dos Reis: Initializer lists (Rev. 3).
 [N2640=08-0150] Jason Merrill and Daveed Vandevoorde: Initializer Lists – Alternative
Mechanism and Rationale (v. 2) (final proposal).
Uniform initialization syntax and semantics
C++98 offers several ways of initializing an object depending on its type and the initialization
context. When misused, the error can be surprising and the error messages obscure. Consider:
1. string a[] = { "foo", " bar" }; // ok: initialize array variable
2. vector<string> v = { "foo", " bar" }; // error: initializer list for non-aggregate vector
3. void f(string a[]);
4. f( { "foo", " bar" } ); // syntax error: block as argument
and
1. int a = 2; // "assignment style"
2. int aa[] = { 2, 3 }; // assignment style with list
3. complex z(1,2); // "functional style" initialization
4. x = Ptr(y); // "functional style" for conversion/cast/construction
and
1. int a(1); // variable definition
2. int b(); // function declaration
3. int b(foo); // variable definition or function declaration
It can be hard to remember the rules for initialization and to choose the best way.
The C++11 solution is to allow {}-initializer lists for all initialization:
1. X x1 = X{1,2};
2. X x2 = {1,2}; // the = is optional
3. X x3{1,2};
4. X* p = new X{1,2};
5.
6. struct D : X {
7. D(int x, int y) :X{x,y} { /* ... */ };
8. };
9.
10. struct S {
11. int a[3];
12. S(int x, int y, int z) :a{x,y,z} { /* ... */ }; // solution to old problem
13. };
Importantly, X{a} constructs the same value in every context, so that {}-initialization gives the
same result in all places where it is legal. For example:
1. X x{a};
2. X* p = new X{a};
3. z = X{a}; // use as cast
4. f({a}); // function argument (of type X)
5. return {a}; // function return value (function returning X)
C++11 uniform initialization is not perfectly uniform, but it’s very nearly so. C+
+11’s {} initialization syntax and semantics provide a much simpler and consistent way to perform
initialization, that is also more powerful (e.g., vector<int> v = { 1, 2, 3, 4 }) and safer
(e.g., {} does not allow narrowing conversions). Prefer initializing using {}.
See also:
 [N2215==07-0075 ] Bjarne Stroustrup and Gabriel Dos Reis: Initializer lists (Rev. 3).
 [N2640==08-0150] Jason Merrill and Daveed Vandevoorde: Initializer Lists – Alternative
Mechanism and Rationale (v. 2) (final proposal).
Rvalue references and move semantics
The distinction between lvalues (what can be used on the left-hand side of an assignment) and
rvalues (what can be used on the right-hand side of an assignment) goes back to Christopher
Strachey (the father of C++’s distant ancestor CPL and of denotational semantics). In C++98,
references to non-const can bind to lvalues and references to const can bind to lvalues or rvalues,
but there is nothing that can bind to a non-const rvalue. That’s to protect people from changing the
values of temporaries that are destroyed before their new value can be used. For example:
1. void incr(int& a) { ++a; }
2. int i = 0;
3. incr(i); // i becomes 1
4. incr(0); // error: 0 in not an lvalue
If that incr(0) were allowed either some temporary that nobody ever saw would be incremented
or – far worse – the value of 0 would become 1. The latter sounds silly, but there was actually a bug
like that in early Fortran compilers that set aside a memory location to hold the value 0.
So far, so good, but consider
1. template<class T> swap(T& a, T& b) // "old style swap"
2. {
3. T tmp(a); // now we have two copies of a
4. a = b; // now we have two copies of b
5. b = tmp; // now we have two copies of tmp (aka a)
6. }
If T is a type for which it can be expensive to copy elements, such
as string and vector, swap becomes an expensive operation (for the standard library, we have
specializations of string and vector swap() to deal with that). Note something curious: We
didn’t want any copies at all. We just wanted to move the values of a, b, and tmp around a bit.
In C++11, we can define “move constructors” and “move assignments” to move rather than copy
their argument:
1. template<class T> class vector {
2. // ...
3. vector(const vector&); // copy constructor
4. vector(vector&&); // move constructor
5. vector& operator=(const vector&); // copy assignment
6. vector& operator=(vector&&); // move assignment
7. }; // note: move constructor and move assignment takes non-const &&
8. // they can, and usually do, write to their argument
The && indicates an “rvalue reference”. An rvalue reference can bind to an rvalue (but not to an
lvalue):
1. X a;
2. X f();
3. X& r1 = a; // bind r1 to a (an lvalue)
4. X& r2 = f(); // error: f() is an rvalue; can't bind
5.
6. X&& rr1 = f(); // fine: bind rr1 to temporary
7. X&& rr2 = a; // error: bind a is an lvalue
The idea behind a move assignment is that instead of making a copy, it simply takes the
representation from its source and replaces it with a cheap default. For example,
for strings s1=s2 using the move assignment would not make a copy of s2’s characters; instead,
it would just let s1 treat those characters as its own and somehow delete s1’s old characters (maybe
by leaving them in s2, which presumably is just about to be destroyed).
How do we know whether it’s ok to simply move from a source? We tell the compiler:
1. template<class T>
2. void swap(T& a, T& b) // "perfect swap" (almost)
3. {
4. T tmp = move(a); // could invalidate a
5. a = move(b); // could invalidate b
6. b = move(tmp); // could invalidate tmp
7. }
move(x) is just a cast that means “you can treat x as an rvalue”. Maybe it would have been better
if move() had been called rval(), but by now move() has been used for years.
The move() template function can be written in C++11 (see the “brief introduction”) and and uses
rvalue references.
Rvalue references can also be used to provide perfect forwarding.
In the C++11 standard library, all containers are provided with move constructors and move
assignments, and operations that insert new elements, such as insert() and push_back(), have
versions that take rvalue references. The net result is that the standard containers and algorithms
quietly – without user intervention – improve in performance because they copy less.
See also:
 N1385 N1690 N1770 N1855 N1952
 [N2027==06-0097] Howard Hinnant, Bjarne Stroustrup, and Bronek Kozicki: A brief
introduction to rvalue references
 [N1377=02-0035] Howard E. Hinnant, Peter Dimov, and Dave Abrahams: A Proposal to
Add Move Semantics Support to the C++ Language (original proposal).
 [N2118=06-0188] Howard Hinnant: A Proposal to Add an Rvalue Reference to the C++
Language Proposed Wording (Revision 3) (final proposal).
Lambdas
A lambda expression is a mechanism for specifying a function object. The primary use for a lambda
is to specify a simple action to be performed by some function. For example:
1. vector<int> v = {50, -10, 20, -30};
2.
3. std::sort(v.begin(), v.end()); // the default sort
4. // now v should be { -30, -10, 20, 50 }
5.
6. // sort by absolute value:
7. std::sort(v.begin(), v.end(), [](int a, int b) { return abs(a)<abs(b); });
8. // now v should be { -10, 20, -30, 50 }
The argument [](int a, int b) { return abs(a)<abs(b); } is a “lambda” (or “lambda
function” or “lambda expression”), which specifies an operation that given two integer
arguments a and b returns the result of comparing their absolute values.
A lambda expression can access local variables in the scope in which it is used. For example:
1. void f(vector<Record>& v)
2. {
3. vector<int> indices(v.size());
4. int count = 0;
5. generate(indices.begin(),indices.end(),[&count](){ return count++; });
6.
7. // sort indices in the order determined by the name field of the records:
8. std::sort(indices.begin(), indices.end(), [&](int a, int b) { return v[a].name<v[b].name; });
9. // ...
10. }
Some consider this “really neat!”; others see it as a way to write dangerously obscure code. Both are
right.
The [&] is a “capture list” specifying that local names used will be passed by reference. Had we
wanted to “capture” only v, we could have said so: [&v]. Had we wanted to pass v by value, we
could have said so: [=v] or [v]. Capture nothing is [], capture all by reference is [&], and capture
all by value is [=].
If an action is neither common nor simple, consider using a named function object or function. For
example, the example above could have been written:
1. void f(vector<Record>& v)
2. {
3. vector<int> indices(v.size());
4. int count = 0;
5. generate(indices.begin(),indices.end(),[&](){ return ++count; });
6.
7. struct Cmp_names {
8. const vector<Record>& vr;
9. Cmp_names(const vector<Record>& r) :vr(r) { }
10. bool operator()(int a, int b) const { return vr[a].name<vr[b].name; }
11. };
12.
13. // sort indices in the order determined by the name field of the records:
14. std::sort(indices.begin(), indices.end(), Cmp_names(v));
15. // ...
16. }
For a tiny function, such as this Record name field comparison, the function object notation is
verbose, though the generated code is likely to be identical. In C++98, such function objects had to
be non-local to be used as template argument; in C++ this is no longer necessary.
To specify a lambda you must provide
 Its capture list: the list of variables it can use (in addition to its arguments), if any
([&] meaning “all local variables passed by reference” in the Record comparison example). If no
names need to be captured, a lambda starts with plain [].
 (optionally) Its arguments and their types (e.g, (int a, int b))
 The action to be performed as a block (e.g., { return v[a].name<v[b].name; }).
 (optionally) The return type using the new suffix return type syntax; but typically we just
deduce the return type from the return statement. If no value is returned then void is deduced.
 See also:
 Standard 5.1.2 Lambda expressions
 [N1968=06-0038] Jeremiah Willcock, Jaakko Jarvi, Doug Gregor, Bjarne Stroustrup, and
Andrew Lumsdaine: Lambda expressions and closures for C++ (original proposal with a different
syntax)
 [N2550=08-0060] Jaakko Jarvi, John Freeman, and Lawrence Crowl: Lambda Expressions
and Closures: Wording for Monomorphic Lambdas (Revision 4) (final proposal).
 [N2859=09-0049] Daveed Vandevoorde: New wording for C++0x Lambdas.
noexcept to prevent exception propagation
If a function cannot throw an exception or if the program isn’t written to handle exceptions thrown
by a function, that function can be declared noexcept. For example:
1. extern "C" double sqrt(double) noexcept; // will never throw
2.
3. vector<double> my_computation(const vector<double>& v) noexcept // I'm not prepared to handle
memory exhaustion
4. {
5. vector<double> res(v.size()); // might throw
6. for(int i; i<v.size(); ++i) res[i] = sqrt(v[i]);
7. return res;
8. }
If a function declared noexcept throws (so that the exception tries to escape
the noexcept function) the program is terminated by a call to std::terminate(). The call
of terminate() cannot rely on objects being in well-defined states; that is, there is no guarantee
that destructors have been invoked, no guaranteed stack unwinding, and no possibility for resuming
the program as if no problem had been encountered. This is deliberate and makes noexcept a
simple, crude, and very efficient mechanism – much more efficient than the old
dynamic throw() exception specification mechanism.
It is possible to make a function conditionally noexcept. For example, an algorithm can be
specified to be noexcept if (and only if) the operations it uses on a template argument
are noexcept:
1. template<class T>
2. void do_f(vector<T>& v) noexcept(noexcept(f(v.at(0)))) // can throw if f(v.at(0)) can
3. {
4. for(int i; i<v.size(); ++i)
5. v.at(i) = f(v.at(i));
6. }
Here, we first use noexcept as an operator: noexcept(f(v.at(0))) is true
if f(v.at(0)) can’t throw, that is if the f() and at() used are noexcept.
The noexcept() operator is a constant expression and does not evaluate its operand.
The general form of a noexcept declaration is noexcept(expression) and “plain noexcept”
is simply a shorthand for noexcept(true). All declarations of a function must have
compatible noexcept specifications.
A destructor shouldn’t throw; a generated destructor is implicitly noexcept (independently of what
code is in its body) if all of the members of its class have noexcept destructors (which, ahem, they
too will have by default).
It is typically a bad idea to have a move operation throw, so declare those noexcept wherever
possible. A generated copy or move operation is implicitly noexcept if all of the copy or move
operations it uses on members of its class have noexcept destructors.
noexcept is widely and systematically used in the standard library to improve performance and
clarify requirements.
 See also:
 Standard: 15.4 Exception specifications [except.spec].
 Standard: 5.3.7 noexcept operator [expr.unary.noexcept].
 [N3103==10-0093] D. Kohlbrenner, D. Svoboda, and A. Wesie: Security impact of
noexcept. (Noexcept must terminate, as it does).
 [N3167==10-0157] David Svoboda: Delete operators default to noexcept.
 [N3204==10-0194] Jens Maurer: Deducing “noexcept” for destructors.
 [N3050==10-0040] D. Abrahams, R. Sharoni, and D. Gregor: Allowing Move Constructors
to Throw (Rev. 1).
constexpr
The constexpr mechanism
 provides more general constant expressions
 allows constant expressions involving user-defined types
 provides a way to guarantee that an initialization is done at compile time
Consider
1. enum Flags { good=0, fail=1, bad=2, eof=4 };
2.
3. constexpr int operator|(Flags f1, Flags f2) { return Flags(int(f1)|int(f2)); }
4.
5. void f(Flags x)
6. {
7. switch (x) {
8. case bad: /* ... */ break;
9. case eof: /* ... */ break;
10. case bad|eof: /* ... */ break;
11. default: /* ... */ break;
12. }
13. }
Here constexpr says that the function must be of a simple form so that it can be evaluated at
compile time if given constant expressions arguments.
In addition to be able to evaluate expressions at compile time, we want to be able to require
expressions to be evaluated at compile time; constexpr in front of a variable definition does that
(and implies const):
1. constexpr int x1 = bad|eof; // ok
2.
3. void f(Flags f3)
4. {
5. constexpr int x2 = bad|f3; // error: can't evaluate at compile time
6. int x3 = bad|f3; // ok
7. }
Typically we want the compile-time evaluation guarantee for global or namespace objects, often for
objects we want to place in read-only storage.
This also works for objects for which the constructors are simple enough to be constexpr and
expressions involving such objects:
1. struct Point {
2. int x,y;
3. constexpr Point(int xx, int yy) : x(xx), y(yy) { }
4. };
5.
6. constexpr Point origo(0,0);
7. constexpr int z = origo.x;
8.
9. constexpr Point a[] = {Point(0,0), Point(1,1), Point(2,2) };
10. constexpr int x = a[1].x; // x becomes 1
Please note that constexpr is not a general purpose replacement for const (or vice versa):
 const’s primary function is to express the idea that an object is not modified through an
interface (even though the object may very well be modified through other interfaces). It just so
happens that declaring an object const provides excellent optimization opportunities for the
compiler. In particular, if an object is declared const and its address isn’t taken, a compiler is
often able to evaluate its initializer at compile time (though that’s not guaranteed) and keep that
object in its tables rather than emitting it into the generated code.
 constexpr’s primary function is to extend the range of what can be computed at compile
time, making such computation type safe and also usable in compile-time contexts (such as to
initialize enumerator or integral template parameters). Objects declared constexpr have their
initializer evaluated at compile time; they are basically values kept in the compiler’s tables and
only emitted into the generated code if needed.
See also:
 the C++ draft 3.6.2 Initialization of non-local objects, 3.9 Types [12], 5.19 Constant
expressions, 7.1.5 The constexpr specifier
 [N1521=03-0104] Gabriel Dos Reis: Generalized Constant Expressions (original proposal).
 [N2235=07-0095] Gabriel Dos Reis, Bjarne Stroustrup, and Jens Maurer: Generalized
Constant Expressions – Revision 5.
nullptr – a null pointer literal
nullptr is a literal denoting the null pointer; it is not an integer:
1. char* p = nullptr;
2. int* q = nullptr;
3. char* p2 = 0; // 0 still works and p==p2
4.
5. void f(int);
6. void f(char*);
7.
8. f(0); // call f(int)
9. f(nullptr); // call f(char*)
10.
11. void g(int);
12. g(nullptr); // error: nullptr is not an int
13. int i = nullptr; // error: nullptr is not an int
See also:
 [N1488==/03-0071] Herb Sutter and Bjarne Stroustrup: A name for the null pointer: nullptr.
 [N2214 = 07-0074 ] Herb Sutter and Bjarne Stroustrup: A name for the null pointer: nullptr
(revision 4).
 ECMA-372 for a description of this feature as originally designed in C++/CLI before being
proposed for ISO C++.
Copying and rethrowing exceptions
How do you catch an exception and then rethrow it on another thread? Use a bit of library magic as
described in the standard 18.8.5 Exception Propagation:
 exception_ptr current_exception(); Returns: An exception_ptr object that
refers to the currently handled exception (15.3) or a copy of the currently handled exception, or a
null exception_ptr object if no exception is being handled. The referenced object shall remain
valid at least as long as there is an exception_ptr object that refers to it. …
  void rethrow_exception(exception_ptr p);
 template<class E> exception_ptr copy_exception(E e); Effects: as if
1. try {
2. throw e;
3. } catch(...) {
4. return current_exception();
5. }
This is particularly useful for transmitting an exception from one thread to another.
Inline namespaces
The inline namespace mechanism is intended to support library evolution by providing a
mechanism that supports a form of versioning. Consider:
1. // file V99.h:
2. inline namespace V99 {
3. void f(int); // does something better than the V98 version
4. void f(double); // new feature
5. // ...
6. }
7.
8. // file V98.h:
9. namespace V98 {
10. void f(int); // does something
11. // ...
12. }
13.
14. // file Mine.h:
15. namespace Mine {
16. #include "V99.h"
17. #include "V98.h"
18. }
We here have a namespace Mine with both the latest release (V99) and the previous one (V98). If
you want to be specific, you can:
1. #include "Mine.h"
2. using namespace Mine;
3. // ...
4. V98::f(1); // old version
5. V99::f(1); // new version
6. f(1); // default version
The point is that the inline specifier makes the declarations from the nested namespace appear
exactly as if they had been declared in the enclosing namespace.
This is a very “static” and implementer-oriented facility in that the inline specifier has to be
placed by the designer of the namespaces – thus making the choice for all users. It is not possible for
a user of Mine to say “I want the default to be V98 rather than V99.”
See
 Standard 7.3.1 Namespace definition [7]-[9].
User-defined literals
C++ has always provided literals for a variety of built-in types (2.14 Literals):
1. 123 // int
2. 1.2 // double
3. 1.2F // float
4. 'a' // char
5. 1ULL // unsigned long long
6. 0xD0 // hexadecimal unsigned
7. "as" // string
However, in C++98 there are no literals for user-defined types. This can be a bother and also seen as
a violation of the principle that user-defined types should be supported as well as built-in types are.
In particular, people have requested:
1. "Hi!"s // std::string, not ``zero-terminated array of char''
2. 1.2i // imaginary
3. 123.4567891234df // decimal floating point (IBM)
4. 101010111000101b // binary
5. 123s // seconds
6. 123.56km // not miles! (units)
7. 1234567890123456789012345678901234567890x // extended-precision
C++11 supports “user-defined literals” through the notion of literal operators that map literals with a
given suffix into a desired type. For example:
1. constexpr complex<double> operator "" i(long double d) // imaginary literal
2. {
3. return {0,d}; // complex is a literal type
4. }
5.
6. std::string operator""s (const char* p, size_t n) // std::string literal
7. {
8. return string(p,n); // requires free store allocation
9. }
Note the use of constexpr to enable compile-time evaluation. Given those, we can write
1. template<class T> void f(const T&);
2. f("Hello"); // pass pointer to char*
3. f("Hello"s); // pass (5-character) string object
4. f("Hello\n"s); // pass (6-character) string object
5.
6. auto z = 2+1i; // complex(2,1)
The basic (implementation) idea is that after parsing what could be a literal, the compiler always
checks for a suffix. The user-defined literal mechanism simply allows the user to specify a new
suffix and what is to be done with the literal before it. It is not possible to redefine the meaning of a
built-in literal suffix or augment the syntax of literals. A literal operator can request to get its
(preceding) literal passed “cooked” (with the value it would have had if the new suffix hadn’t been
defined) or “uncooked” (as a string).
To get an “uncooked” string, simply request a single const char* argument:
1. Bignum operator"" x(const char* p)
2. {
3. return Bignum(p);
4. }
5.
6. void f(Bignum);
7. f(1234567890123456789012345678901234567890x);
Here the C-style string "1234567890123456789012345678901234567890" is passed
to operator"" x(). Note that we did not explicitly put those digits into a string.
There are four kinds of literals that can be suffixed to make a user-defined literal.
 Integer literal: accepted by a literal operator taking a single unsigned long
long or const char* argument.
 Floating-point literal: accepted by a literal operator taking a single long double or const
char* argument.
  String literal: accepted by a literal operator taking a pair of (const char*, size_t)
arguments.
 Character literal: accepted by a literal operator taking a single char argument.
Note that you cannot make a literal operator for a string literal that takes just a const
char* argument (and no size). For example:
1. string operator"" S(const char* p); // warning: this will not work as expected
2.
3. "one two"S; // error: no applicable literal operator
The rationale is that if we want to have “a different kind of string” we almost always want to know
the number of characters anyway.
Suffixes will tend to be short (e.g. s for string, i for imaginary, m for meter, and x for extended),
so different uses could easily clash. Use namespaces to prevent clashes:
1. namespace Numerics {
2. // ...
3. class Bignum { /* ... */ };
4. namespace literals {
5. operator"" X(char const*);
6. }
7. }
8.
9. using namespace Numerics::literals;
See also:
 Standard 2.14.8 User-defined literals
 [N2378==07-0238] Ian McIntosh, Michael Wong, Raymond Mak, Robert Klarer, Jens
Mauer, Alisdair Meredith, Bjarne Stroustrup, David Vandevoorde: User-defined Literals (aka.
Extensible Literals (revision 3)).

C++11 Language Extensions – Classes

Save to:
InstapaperPocketReadability
Contents of this section:

 =default and =delete

 Control of default move and copy
 Delegating constructors
 In-class member initializers
 Inherited constructors
 Override controls: override
 Override controls: final
 Explicit conversion operators
=default and =delete
The common idiom of “prohibiting copying” can now be expressed directly:
1. class X {
2. // ...
3.
4. X& operator=(const X&) = delete; // Disallow copying
5. X(const X&) = delete;
6. };
Conversely, we can also say explicitly that we want to default copy behavior:
1. class Y {
2. // ...
3. Y& operator=(const Y&) = default; // default copy semantics
4. Y(const Y&) = default;
5. };
Explicitly writing out the default by hand is at best redundant, and has two drawbacks: it sometimes
generates less efficient code than the compiler-generated default would, and it prevents types from
being considered PODs. However, comments about copy operations and (worse) a user explicitly
defining copy operations meant to give the default behavior were not uncommon in pre-C++11
code. Leaving it to the compiler to implement the default behavior is simpler, less error-prone, and
often leads to better object code.
The =default mechanism can be used for any function that has a default.
The =delete mechanism can be used for any function. For example, we can eliminate an undesired
conversion like this:
1. struct Z {
2. // ...
3.
4. Z(long long); // can initialize with a long long
5. Z(long) = delete; // but not anything smaller
6. };
See also:
 [N2326==07-0186] Lawrence Crowl: Defaulted and Deleted Functions.
 [N3174=100164] B. Stroustrup: To move or not to move. An analysis of problems related to
generated copy and move operations. Approved.
For further historical background of alternatives, see
 [N1717==04-0157] Francis Glassborow and Lois Goldthwaite: explicit class and default
definitions (an early proposal).
 Bjarne Stroustrup: Control of class defaults (a dead end).
Control of default move and copy
By default, a class has five operations:
 copy assignment
 copy constructor
 move assignment
 move constructor
 destructor
If you declare any of those you must consider all and explicitly define or =default the ones you
want. Think of copying, moving, and destruction as closely related operations, rather than individual
operations that you can freely mix and match – you can specify arbitrary combinations, but only a
few combinations make sense semantically.
If any move, copy, or destructor is explicitly specified (declared, defined, =default, or =delete)
by the user, no move is generated by default. If any copy or destructor is explicitly specified
(declared, defined, =default, or =delete) by the user, any undeclared copy operations are
generated by default, but this is deprecated, so don’t rely on that. For example:
1. class X1 {
2. X1& operator=(const X1&) = delete; // Disallow copying
3. };
This implicitly also disallows moving of X1s. Copy initialization is allowed, but deprecated.
1. class X2 {
2. X2& operator=(const X2&) = default;
3. };
This implicitly also disallows moving of X2s. Copy initialization is allowed, but deprecated.
1. class X3 {
2. X3& operator=(X3&&) = delete; // Disallow moving
3. }
This implicitly also disallows copying of X3s.
1. class X4 {
2. ~X4() = delete; // Disallow destruction
3. }
This implicitly also disallows moving of X4s. Copying is allowed, but deprecated.
If you declare one of these five function, you should explicitly declare all. For example:
1. template<class T>
2. class Handle {
3. T* p;
4. public:
5. Handle(T* pp) : p{pp} {}
6. ~Handle() { delete p; } // user-defined destructor: no implicit copy or move
7.
8. Handle(Handle&& h) :p{h.p} { h.p=nullptr; } // transfer ownership
9. Handle& operator=(Handle&& h) { delete p; p=h.p; h.p=nullptr; return *this; } // transfer
ownership
10.
11. Handle(const Handle&) = delete; // no copy
12. Handle& operator=(const Handle&) = delete;
13.
14. // ...
15. };
See also:
 [N2326==07-0186] Lawrence Crowl: Defaulted and Deleted Functions.
 [N3174=100164] B. Stroustrup: To move or not to move. An analysis of problems related to
generated copy and move operations. Approved.
Delegating constructors
In C++98, if you want two constructors to do the same thing, repeat yourself or call
“an init() function.” For example:
1. class X {
2. int a;
3. void validate(int x) { if (0<x && x<=max) a=x; else throw bad_X(x); }
4. public:
5. X(int x) { validate(x); }
6. X() { validate(42); }
7. X(string s) { int x = lexical_cast<int>(s); validate(x); }
8. // ...
9. };
Verbosity hinders readability and repetition is error-prone. Both get in the way of maintainability.
So, in C++11, we can define one constructor in terms of another:
1. class X {
2. int a;
3. public:
4. X(int x) { if (0<x && x<=max) a=x; else throw bad_X(x); }
5. X() :X{42} { }
6. X(string s) :X{lexical_cast<int>(s)} { }
7. // ...
8. };
 See also:
 the C++ draft section 12.6.2
 N1986==06-0056 Herb Sutter and Francis Glassborow: Delegating Constructors (revision 3).
 ECMA-372 for a description of this feature as originally designed in C++/CLI before being
proposed for ISO C++.
In-class member initializers
In C++98, only static const members of integral types could be initialized in-class, and the
initializer has to be a constant expression. These restrictions ensured that the compiler can do the
initialization at compile-time. For example:
1. int var = 7;
2.
3. class X {
4. static const int m1 = 7; // ok
5. const int m2 = 7; // error: not static
6. static int m3 = 7; // error: not const
7. static const int m4 = var; // error: initializer not constant expression
8. static const string m5 = "odd"; // error: not integral type
9. // ...
10. };
The basic idea for C++11 was to allow a non-static data member to be initialized where it is
declared (in its class). A constructor can then use the initializer when run-time initialization is
needed. Consider:
1. class A {
2. public:
3. int a = 7;
4. };
This is equivalent to:
1. class A {
2. public:
3. int a;
4. A() : a(7) {}
5. };
This saves a bit of typing, but the real benefits come in classes with multiple constructors. Often, all
constructors use a common initializer for a member:
1. class A {
2. public:
3. A(): a(7), b(5), hash_algorithm("MD5"), s("Constructor run") {}
4. A(int a_val) : a(a_val), b(5), hash_algorithm("MD5"), s("Constructor run") {}
5. A(D d) : a(7), b(g(d)), hash_algorithm("MD5"), s("Constructor run") {}
6. int a, b;
7. private:
8. HashingFunction hash_algorithm; // Cryptographic hash to be applied to all A instances
9. std::string s; // String indicating state in object lifecycle
10. };
The fact that hash_algorithm and s each have a single default is lost in the mess of code and
could easily become a problem during maintenance. Instead, we can factor out the initialization of
the data members:
1. class A {
2. public:
3. A(): a(7), b(5) {}
4. A(int a_val) : a(a_val), b(5) {}
5. A(D d) : a(7), b(g(d)) {}
6. int a, b;
7. private:
8. HashingFunction hash_algorithm{"MD5"}; // Cryptographic hash to be applied to all A instances
9. std::string s{"Constructor run"}; // String indicating state in object lifecycle
10. };
If a member is initialized by both an in-class initializer and a constructor, only the constructor’s
initialization is done (it “overrides” the default). So we can simplify further:
1. class A {
2. public:
3. A() {}
4. A(int a_val) : a(a_val) {}
5. A(D d) : b(g(d)) {}
6. int a = 7;
7. int b = 5;
8. private:
9. HashingFunction hash_algorithm{"MD5"}; // Cryptographic hash to be applied to all A instances
10. std::string s{"Constructor run"}; // String indicating state in object lifecycle
11. };
See also:
 the C++ draft section “one or two words all over the place”; see proposal.
 [N2628=08-0138] Michael Spertus and Bill Seymour: Non-static data member initializers.
Inherited constructors
People sometimes are confused about the fact that ordinary scope rules apply to class members. In
particular, a member of a base class is not in the same scope as a member of a derived class:
1. struct B {
2. void f(double);
3. };
4.
5. struct D : B {
6. void f(int);
7. };
8.
9. B b; b.f(4.5); // fine
10. D d; d.f(4.5); // surprise: calls f(int) with argument 4
In C++98, we can “lift” a set of overloaded functions from a base class into a derived class:
1. struct B {
2. void f(double);
3. };
4.
5. struct D : B {
6. using B::f; // bring all f()s from B into scope
7. void f(int); // add a new f()
8. };
9.
10. B b; b.f(4.5); // fine
11. D d; d.f(4.5); // fine: calls D::f(double) which is B::f(double)
Stroustrup has said that “Little more than a historical accident prevents using this to work for a
constructor as well as for an ordinary member function.” C++11 provides that facility:
1. class Derived : public Base {
2. public:
3. using Base::f; // lift Base's f into Derived's scope -- works in C++98
4. void f(char); // provide a new f
5. void f(int); // prefer this f to Base::f(int)
6.
7. using Base::Base; // lift Base constructors Derived's scope -- new in C++11
8. Derived(char); // provide a new constructor
9. Derived(int); // prefer this constructor to Base::Base(int)
10. // ...
11. };
If you so choose, you can still shoot yourself in the foot by inheriting constructors in a derived class
in which you define new member variables needing initialization:
1. struct B1 {
2. B1(int) { }
3. };
4.
5. struct D1 : B1 {
6. using B1::B1; // implicitly declares D1(int)
7. int x;
8. };
9.
10. void test()
11. {
12. D1 d(6); // Oops: d.x is not initialized
13. D1 e; // error: D1 has no default constructor
14. }
You might remove the bullet from your foot by using a member-initializer:
1. struct D1 : B1 {
2. using B1::B1; // implicitly declares D1(int)
3. int x{0}; // note: x is initialized
4. };
5.
6. void test()
7. {
8. D1 d(6); // d.x is zero
9. }
See also:
 the C++ draft section 12.9.
 [N1890=05-0150 ] Bjarne Stroustrup and Gabriel Dos Reis: Initialization and initializers (an
overview of initialization-related problems with suggested solutions).
 [N1898=05-0158 ] Michel Michaud and Michael Wong: Forwarding and inherited
constructors.
 [N2512=08-0022] Alisdair Meredith, Michael Wong, Jens Maurer: Inheriting
Constructors (revision 4).
Override controls: override
No special keyword or annotation is needed for a function in a derived class to override a function
in a base class. For example:
1. struct B {
2. virtual void f();
3. virtual void g() const;
4. virtual void h(char);
5. void k(); // not virtual
6. };
7.
8. struct D : B {
9. void f(); // overrides B::f()
10. void g(); // doesn't override B::g() (wrong type)
11. virtual void h(char); // overrides B::h()
12. void k(); // doesn't override B::k() (B::k() is not virtual)
13. };
This can cause confusion (what did the programmer mean?), and problems if a compiler doesn’t
warn against suspicious code. For example,
 Did the programmer mean to override B::g()? (almost certainly yes).
 Did the programming mean to override B::h(char)? (probably not because of the
redundant explicit virtual).
 Did the programmer mean to override B::k()? (probably, but that’s not possible).
To allow the programmer to be more explicit about overriding, we now have the “contextual
keyword” override:
1. struct D : B {
2. void f() override; // OK: overrides B::f()
3. void g() override; // error: wrong type
4. virtual void h(char); // overrides B::h(); likely warning
5. void k() override; // error: B::k() is not virtual
6. };
A declaration marked override is only valid if there is a function to override. The problem
with h() is not guaranteed to be caught (because it is not an error according to the language
definition) but it is easily diagnosed.
override is only a contextual keyword, so you can still use it as an identifier:
1. int override = 7; // not recommended
See also:
 Standard: 10 Derived classes [class.derived] [9]
 Standard: 10.3 Virtual functions [class.virtual]
 [N3234==11-0004] Ville Voutilainen: Remove explicit from class-head.
 [N3151==10-0141] Ville Voutilainen: Keywords for override control. Earlier, more elaborate
design.
 [N3163==10-0153] Herb Sutter: Override Control Using Contextual Keywords. Alternative
earlier more elaborate design.
 ECMA-372 for a description of the more elaborate version of this feature as designed in C+
+/CLI before being proposed for ISO C++.
 [N2852==09-0042] V. Voutilainen, A. Meredith, J. Maurer, and C. Uzdavinis: Explicit
Virtual Overrides. Earlier design based on attributes.
 [N1827==05-0087] C. Uzdavinis and A. Meredith: An Explicit Override Syntax for C++.
The original proposal.
Override controls: final
Sometimes, a programmer wants to prevent a virtual function from being overridden. This can be
achieved by adding the specifier final. For example:
1. struct B {
2. virtual void f() const final; // do not override
3. virtual void g();
4. };
5.
6. struct D : B {
7. void f() const; // error: D::f attempts to override final B::f
8. void g(); // OK
9. };
 There are legitimate reasons for wanting to prevent overriding, but it should be noted that many
examples used to motivate final have been based on mistaken assumptions on how expensive
virtual functions are (usually based on experience with other languages). So, if you feel the urge to
add a final specifier, please double check that the reason is logical: Would semantic errors be
likely if someone defined a class that overrode that virtual function? Adding final closes the
possibility that a future user of the class might provide a better implementation of the function for
some class you haven’t thought of. If you don’t want to keep that option open, why did you define
the function to be virtual in the first place? Most reasonable answers to that question encountered
to date have been along the lines: This is a fundamental function in a framework that the framework
builders needed to override but isn’t safe for general users to override. Be suspicious towards such
claims and be sure final is really appropriate.
If it is performance (inlining) you want or you simply never want to override, it is typically better
not to define a function to be virtual in the first place. This is not Java.
final is only a contextual keyword, so you can still use it as an identifier:
1. int final = 7; // not recommended
See also:
 Standard: 10 Derived classes [class.derived] [9]
 Standard: 10.3 Virtual functions [class.virtual]
Explicit conversion operators
C++98 provides implicit and explicit constructors; that is, the conversion defined by a
constructor declared explicit can be used only for explicit conversions whereas other
constructors can be used for implicit conversions also. For example:
1. struct S { S(int); }; // "ordinary constructor" defines implicit conversion
2. S s1(1); // ok
3. S s2 = 1; // ok
4. void f(S);
5. f(1); // ok (but that's often a bad surprise -- what if S was vector?)
6.
7. struct E { explicit E(int); }; // explicit constructor
8. E e1(1); // ok
9. E e2 = 1; // error (but that's often a surprise)
10. void f(E);
11. f(1); // error (protects against surprises -- e.g. std::vector's constructor from int is explicit)
However, a constructor is not the only mechanism for defining a conversion. If we can’t modify a
class, we can define a conversion operator from a different class. For example:
1. struct S { S(int) { } /* ... */ };
2.
3. struct SS {
4. int m;
5. SS(int x) :m(x) { }
6. operator S() { return S(m); } // because S don't have S(SS); non-intrusive
7. };
8.
9. SS ss(1);
10. S s1 = ss; // ok; like an implicit constructor
11. S s2(ss); // ok ; like an implicit constructor
12. void f(S);
13. f(ss); // ok; like an implicit constructor
Unfortunately, C++98 had no explicit conversion operators, largely because there are far fewer
problematic examples. C++11 deals with that oversight by allowing conversion operators to
be explicit. For example:
1. struct S { S(int) { } };
2.
3. struct SS {
4. int m;
5. SS(int x) :m(x) { }
6. explicit operator S() { return S(m); } // because S don't have S(SS)
7. };
8.
9. SS ss(1);
10. S s1 = ss; // error; like an explicit constructor
11. S s2(ss); // ok ; like an explicit constructor
12. void f(S);
13. f(ss); // error; like an explicit constructor
See also:
 Standard: 12.3 Conversions
 [N2333=07-0193] Lois Goldthwaite, Michael Wong, and Jens Maurer: Explicit Conversion
Operator (Revision 1).

C++11 Language Extensions — Other Types

Save to:
InstapaperPocketReadability
Contents of this section:

 enum class
 long long – a longer integer
 Extended integer types
 Generalized unions
 Generalized PODs
enum class
The enum classes (“new enums”, “strong enums”) address three problems with traditional C++
enumerations:
 Conventional enums implicitly convert to an integer, causing errors when someone does not
want an enumeration to act as an integer.
 Conventional enums export their enumerators to the surrounding scope, causing name
clashes.
 The underlying type of an enum cannot be specified, causing confusion, compatibility
problems, and makes forward declaration impossible.
enum classes (“strong enums”) are strongly typed and scoped:
1. enum Alert { green, yellow, orange, red }; // traditional enum
2.
3. enum class Color { red, blue }; // scoped and strongly typed enum
4. // no export of enumerator names into enclosing scope
5. // no implicit conversion to int
6. enum class TrafficLight { red, yellow, green };
7.
8. Alert a = 7; // error (as ever in C++)
9. Color c = 7; // error: no int->Color conversion
10.
11. int a2 = red; // ok: Alert->int conversion
12. int a3 = Alert::red; // error in C++98; ok in C++11
13. int a4 = blue; // error: blue not in scope
14. int a5 = Color::blue; // error: not Color->int conversion
15.
16. Color a6 = Color::blue; // ok
As shown, traditional enums work as usual, but you can now optionally qualify enumerators with
the enum name
The new enums are “enum class” because they combine aspects of traditional enumerations
(names values) with aspects of classes (scoped members and absence of conversions). This is the
same name for this feature as when it was originally designed in C++/CLI before being proposed for
ISO C++.
Being able to specify the underlying type allows simpler interoperability and guaranteed sizes of
enumerations:
1. enum class Color : char { red, blue }; // compact representation
2.
3. enum class TrafficLight { red, yellow, green }; // by default, the underlying type is int
4.
5. enum E { E1 = 1, E2 = 2, Ebig = 0xFFFFFFF0U }; // how big is an E?
6. // (whatever the old rules say;
7. // i.e. "implementation defined")
8.
9. enum EE : unsigned long { EE1 = 1, EE2 = 2, EEbig = 0xFFFFFFF0U }; // now we can be specific
It also enables forward declaration of enums:
1. enum class Color_code : char; // (forward) declaration
2. void foobar(Color_code* p); // use of forward declaration
3. // ...
4. enum class Color_code : char { red, yellow, green, blue }; // definition
The underlying type must be one of the signed or unsigned integer types; the default is int.
In the standard library, enum classes are used
 For mapping systems specific error codes: In : enum class errc;
 For pointer safety indicators: In : enum class pointer_safety { relaxed, preferred, strict };
 For I/O stream errors: In : enum class io_errc { stream = 1 };
 For asynchronous communications error handling: In : enum class future_errc
{ broken_promise, future_already_retrieved, promise_already_satisfied };
Several of these have operators such as == defined.
See also:
 the C++ draft section 7.2
 [N1513=03-0096] David E. Miller: Improving Enumeration Types (original enum proposal).
 [N2347 = J16/07-0207] David E. Miller, Herb Sutter, and Bjarne Stroustrup: Strongly Typed
Enums (revision 3).
 [N2499=08-0009] Alberto Ganesh Barbati: Forward declaration of enumerations.
long long – a longer integer
An integer that’s at least 64 bits long. For example:
1. long long x = 9223372036854775807LL;
No, there are no long long longs nor can long be spelled short long long.
See also:
 [05-0071==N1811] J. Stephen Adamczyk: Adding the long long type to C++ (Revision
3).
Extended integer types
There is a set of rules for how an extended (precision) integer type should behave if one exists.
 See
 [06-0058==N1988] J. Stephen Adamczyk: Adding extended integer types to C++ (Revision
1).
Generalized unions
In C++98 (as in the earlier pre-Standard versions of C++), a member with a user-defined
constructor, destructor, or assignment cannot be a member of a union:
1. union U {
2. int m1;
3. complex<double> m2; // error (silly): complex has constructor
4. string m3; // error (not silly): string has a serious invariant
5. // maintained by ctor, copy, and dtor
6. };
In particular
1. U u; // which constructor, if any?
2. u.m1 = 1; // assign to int member
3. string s = u.m3; // disaster: read from string member
Obviously, it’s illegal to write one member and then read another but people do that nevertheless
(usually by mistake).
C++11 modifies the restrictions of unions to make more member types feasible; in particular, it
allows a member of types with constructors and destructors. It also adds a restriction to make the
more flexible unions less error-prone by encouraging the building of discriminated unions.
Union member types are restricted:
 No virtual functions (as ever)
 No references (as ever)
 No bases (as ever)
 If a union has a member with a user-defined constructor, copy, or destructor then that special
function is deleted; that is, it cannot be used for an object of the union type. This is new.
For example:
1. union U1 {
2. int m1;
3. complex<double> m2; // ok
4. };
5.
6. union U2 {
7. int m1;
8. string m3; // ok
9. };
This may look error-prone, but the new restriction helps. In particular:
1. U1 u; // ok
2. u.m2 = {1,2}; // ok: assign to the complex member
3. U2 u2; // error: the string destructor caused the U destructor to be deleted
4. U2 u3 = u2; // error: the string copy constructor caused the U copy constructor to be deleted
Basically, U2 is useless unless you embed it in a struct that keeps track of which member (variant) is
used. So, build discriminated unions, such as:
1. class Widget { // Three alternative implementations represented as a union
2. private:
3. enum class Tag { point, number, text } type; // discriminant
4. union { // representation
5. point p; // point has constructor
6. int i;
7. string s; // string has default constructor, copy operations, and destructor
8. };
9. // ...
10. widget& operator=(const widget& w) // necessary because of the string variant
11. {
12. if (type==Tag::text && w.type==Tag::text) {
13. s = w.s; // usual string assignment
14. return *this;
15. }
16.
17. if (type==Tag::text) s.~string(); // destroy (explicitly!)
18.
19. switch (w.type) {
20. case Tag::point: p = w.p; break; // normal copy
21. case Tag::number: i = w.i; break;
22. case Tag::text: new(&s)(w.s); break; // placement new
23. }
24. type = w.type;
25. return *this;
26. }
27. };
See also:
 the C++ draft section 9.5
 [N2544=08-0054] Alan Talbot, Lois Goldthwaite, Lawrence Crowl, and Jens
Maurer: Unrestricted unions (Revision 2)
Generalized PODs
A POD (“Plain Old Data”) is something that can be manipulated like a C struct, e.g. bitwise
copyable with memcpy(), bitwise initializable with memset(), etc. In C++98 the actual definition
of POD is based on a set of restrictions on the use of language features used in the definition of a
struct:
1. // S is a POD
2. struct S {
3. int a;
4. };
5.
6. // SS was not a POD in C++98, is a POD in C++11
7. struct SS {
8. int a;
9. SS(int aa) : a(abs(aa)) { assert(a>=0); }
10. };
11.
12. // Definitely not POD
13. struct SSS {
14. virtual void f(); /* ... */
15. };
In C++11, S and SS are “standard layout types” (a superset of “POD types”) because there is really
nothing “magic” about SS: The constructor does not affect the layout (so memcpy() would be fine),
only the initialization rules do (memset() would be bad – not enforcing any invariant the type
might have, such as a >= 0). However, SSS will still have an embedded vptr and will not be
anything like “plain old data.” C++11 defines POD types, trivially copyable types, trivial types,
and standard-layout types to deal with various technical aspects of what used to be PODs. POD is
defined recursively:
  If all your members and bases are PODs, you’re a POD
 As usual (details in section 9 [10])
 No virtual functions
 No virtual bases
 No references
 No multiple access specifiers
The most important aspect of C++11 PODs is that adding or subtracting constructors do not affect
layout or performance.
See also:
 the C++ draft section 3.9 and 9 [10]
 [N2294=07-0154] Beman Dawes: POD’s Revisited; Resolving Core Issue 568 (Revision 4).

C++11 Language Extensions – Templates

Save to:
InstapaperPocketReadability
Contents of this section:

 Extern templates
 Template aliases
 Variadic templates
 Local types as template arguments
Extern templates
A template specialization can be explicitly declared as a way to suppress multiple instantiations. For
example:
1. #include "MyVector.h"
2.
3. extern template class MyVector<int>; // Suppresses implicit instantiation below --
4. // MyVector<int> will be explicitly instantiated elsewhere
5.
6. void foo(MyVector<int>& v)
7. {
8. // use the vector in here
9. }
The “elsewhere” might look something like this:
1. #include "MyVector.h"
2.
3. template class MyVector<int>; // Make MyVector available to clients (e.g., of the shared library
This is basically a way of avoiding significant redundant work by the compiler and linker.
See:
 Standard 14.7.2 Explicit instantiation
 [N1448==03-0031] Mat Marcus and Gabriel Dos Reis: Controlling Implicit Template
Instantiation.
Template aliases
How can we make a template that’s “just like another template” but possibly with a couple of
template arguments specified (bound)? Consider:
1. template<class T>
2. using Vec = std::vector<T,My_alloc<T>>; // standard vector using my allocator
3.
4. Vec<int> fib = { 1, 2, 3, 5, 8, 13 }; // allocates elements using My_alloc
5.
6. vector<int,My_alloc<int>> verbose = fib; // verbose and fib are of the same type
The keyword using is used to get a linear notation “name followed by what it refers to.” We tried
with the conventional and convoluted typedef solution, but never managed to get a complete and
coherent solution until we settled on a less obscure syntax.
Specialization works (you can alias a set of specializations but you cannot specialize an alias) For
example:
1. template<int>
2. struct int_exact_traits { // idea: int_exact_trait<N>::type is a type with exactly N bits
3. typedef int type;
4. };
5.
6. template<>
7. struct int_exact_traits<8> {
8. typedef char type;
9. };
10.
11. template<>
12. struct int_exact_traits<16> {
13. typedef char[2] type;
14. };
15.
16. // ...
17.
18. template<int N>
19. using int_exact = typename int_exact_traits<N>::type; // define alias for convenient notation
20.
21. int_exact<8> a = 7; // int_exact<8> is an int with 8 bits
In addition to being important in connection with templates, type aliases can also be used as a
different (and IMO better) syntax for ordinary type aliases:
1. typedef void (*PFD)(double); // C style
2. using PF = void (*)(double); // using plus C-style type
3. using P = auto (*)(double)->void; // using plus suffix return type
See also:
 the C++ draft: 14.6.7 Template aliases; 7.1.3 The typedef specifier
 [N1489=03-0072] Bjarne Stroustrup and Gabriel Dos Reis: Templates aliases for C++.
 [N2258=07-0118] Gabriel Dos Reis and Bjarne Stroustrup: Templates Aliases (Revision
3) (final proposal).
Variadic templates
Problems to be solved:
 How to construct a class with 1, 2, 3, 4, 5, 6, 7, 8, 9, or … initializers?
 How to avoid constructing an object out of parts and then copying the result?
 How to construct a tuple?
The last question is the key: Think tuple! If you can make and access general tuples the rest will
follow.
 Here is an example (from “A brief introduction to Variadic templates” (see references))
implementing a general, type-safe, printf(). It would probably be better to use boost::format,
but consider:
1. const string pi = "pi";
2. const char* m = "The value of %s is about %g (unless you live in %s).\n";
3. printf(m, pi, 3.14159, "Indiana");
The simplest case of printf() is when there are no arguments except the format string, so we’ll
handle that first:
1. void printf(const char* s)
2. {
3. while (s && *s) {
4. if (*s=='%' && *++s!='%') // make sure that there wasn't meant to be more arguments
5. // %% represents plain % in a format string
6. throw runtime_error("invalid format: missing arguments");
7. std::cout << *s++;
8. }
9. }
That done, we must handle printf() with more arguments:
1. template<typename T, typename... Args> // note the "..."
2. void printf(const char* s, T value, Args... args) // note the "..."
3. {
4. while (s && *s) {
5. if (*s=='%' && *++s!='%') { // a format specifier (ignore which one it is)
6. std::cout << value; // use first non-format argument
7. return printf(++s, args...); // "peel off" first argument
8. }
9. std::cout << *s++;
10. }
11. throw std::runtime error("extra arguments provided to printf");
12. }
This code simply “peels off” the first non-format argument and then calls itself recursively. When
there are no more non-format arguments, it calls the first (simpler) printf() (above). This is
rather standard functional programming done at compile time. Note how the overloading
of << replaces the use of the (possibly erroneous) “hint” in the format specifier.
The Args... defines what is called a “parameter pack.” That’s basically a sequence of (type/value)
pairs from which you can “peel off” arguments starting with the first. When printf() is called
with one argument, the first printf(const char*) is chosen. When printf() is called with
two or more arguments, the second printf(const char*, T value, Args... args)) is
chosen, with the first argument as s, the second as value, and the rest (if any) bundled into the
parameter pack args for later use. In the call
1. printf(++s, args...);
the parameter pack args is expanded so that the next argument can now be selected as value. This
carries on until args is empty (so that the first printf() is called).
If you are familiar with functional programming, you should find this an unusual notation for a
pretty standard technique. If not, here are some small technical examples that might help. First we
can declare and use a simple variadic template function (just like printf() above):
1. template<class ... Types>
2. void f(Types ... args); // variadic template function
3. // (i.e. a function that can take an arbitrary number of arguments of arbitrary types)
4. f(); // OK: args contains no arguments
5. f(1); // OK: args contains one argument: int
6. f(2, 1.0); // OK: args contains two arguments: int and double
We can build a variadic type:
1. template<typename Head, typename... Tail>
2. class tuple<Head, Tail...>
3. : private tuple<Tail...> { // here is the recursion
4. // Basically, a tuple stores its head (first (type/value) pair
5. // and derives from the tuple of its tail (the rest of the (type/value) pairs.
6. // Note that the type is encoded in the type, not stored as data
7. typedef tuple<Tail...> inherited;
8. public:
9. tuple() { } // default: the empty tuple
10.
11. // Construct tuple from separate arguments:
12. tuple(typename add_const_reference<Head>::type v, typename add_const_reference<Tail>::type...
vtail)
13. : m_head(v), inherited(vtail...) { }
14.
15. // Construct tuple from another tuple:
16. template<typename... VValues>
17. tuple(const tuple<VValues...>& other)
18. : m_head(other.head()), inherited(other.tail()) { }
19.
20. template<typename... VValues>
21. tuple& operator=(const tuple<VValues...>& other) // assignment
22. {
23. m_head = other.head();
24. tail() = other.tail();
25. return *this;
26. }
27.
28. typename add_reference<Head>::type head() { return m_head; }
29. typename add_reference<const Head>::type head() const { return m_head; }
30.
31. inherited& tail() { return *this; }
32. const inherited& tail() const { return *this; }
33. protected:
34. Head m_head;
35. }
Given that definition, we can make tuples (and copy and manipulate them):
1. tuple<string,vector,double> tt("hello",{1,2,3,4},1.2);
2. string h = tt.head(); // "hello"
3. tuple<vector<int>,double> t2 = tt.tail(); // {{1,2,3,4},1.2};
It can get a bit tedious to mention all of those types, so often, we deduce them from argument types,
e.g. using the standard library make_tuple():
1. template<class... Types>
2. tuple<Types...> make_tuple(Types&&... t) // this definition is somewhat simplified (see standard
20.5.2.2)
3. {
4. return tuple<Types...>(t...);
5. }
6.
7. string s = "Hello";
8. vector<int> v = {1,22,3,4,5};
9. auto x = make_tuple(s,v,1.2);
See also:
 Standard 14.6.3 Variadic templates
 [N2151==07-0011] D. Gregor, J. Jarvi: Variadic Templates for the C++0x Standard Library.
  [N2080==06-0150] D. Gregor, J. Jarvi, G. Powell: Variadic Templates (Revision 3).
 [N2087==06-0157] Douglas Gregor: A Brief Introduction to Variadic Templates.
 [N2772==08-0282] L. Joly, R. Klarer: Variadic functions: Variadic templates or initializer
lists? – Revision 1.
 [N2551==08-0061] Sylvain Pion: A Variadic std::min(T, ...) for the C++ Standard
Library (Revision 2).
 Anthony Williams: An Introduction to Variadic Templates in C++0x. DevX.com, May 2009.
Local types as template arguments
In C++98, local and unnamed types could not be used as template arguments. This could be a
burden, so C++11 lifts the restriction:
1. void f(vector<X>& v)
2. {
3. struct Less {
4. bool operator()(const X& a, const X& b) { return a.v<b.v; }
5. };
6. sort(v.begin(), v.end(), Less()); // C++98: error: Less is local
7. // C++11: ok
8. }
In C++11, we also have the alternative of using a lambda expression:
1. void f(vector<X>& v)
2. {
3. sort(v.begin(), v.end(),
4. [] (const X& a, const X& b) { return a.v<b.v; }); // C++11
5. }
It is worth remembering that naming action can be quite useful for documentation and an
encouragement to good design. Also, non-local (necessarily named) entities can be reused.
C++11 also allows values of unnamed types to be used as template arguments:
1. template<typename T> void foo(T const& t){}
2. enum X { x };
3. enum { y };
4.
5. int main()
6. {
7. foo(x); // C++98: ok; C++11: ok
8. foo(y); // C++98: error; C++11: ok
9. enum Z { z };
10. foo(z); // C++98: error; C++11: ok
11. }
See also:
 [N2402=07-0262] Anthony Williams: Names, Linkage, and Templates (rev 2).
 [N2657] John Spicer: Local and Unnamed Types as Template Arguments.

C++11 Language Extensions — Concurrency

Save to:
InstapaperPocketReadability
Contents of this section:

 Concurrency memory model

  Dynamic initialization and destruction with concurrency
 Thread-local storage
Concurrency memory model
A memory model is an agreement between the machine architects and the compiler writers to ensure
that most programmers do not have to think about the details of modern computer hardware.
Without a memory model, few things related to threading, locking, and lock-free programming
would make sense. The key guarantee is: Two threads of execution can update and access separate
memory locations without interfering with each other. But what is a “memory location?” A memory
location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having
non-zero width. For example, here S has exactly four separate memory locations:
1. struct S {
2. char a; // location #1
3. int b:5, // location #2
4. int c:11,
5. int :0, // note: :0 is "special"
6. int d:8; // location #3
7. struct {int ee:8;} e; // location #4
8. };
Why is this important? Why isn’t it obvious? Wasn’t this always true? The problem is that when
several computations can genuinely run in parallel, that is several (apparently) unrelated instructions
can execute at the same time, the quirks of the memory hardware can get exposed. In fact, in the
absence of compiler support, issues of instruction and data pipelining and details of cache use will
be exposed in ways that are completely unmanageable to the applications programmer. This is true
even if no two threads have been defined to share data! Consider, two separately compiled
“threads:”
1. // thread 1:
2. char c;
3. c = 1;
4. int x = c;
5.
6. // thread 2:
7. char b;
8. b = 1;
9. int y = b;
For greater realism, we could have used separate compilation (within each thread) to ensure that the
compiler/optimizer wouldn’t be able to eliminate memory accesses and simply ignore c and b and
directly initialize x and y with 1. What are the possible values of x and y? According to C++11 the
only correct answer is the obvious one: 1 and 1. The reason that’s interesting is that if you take a
conventional good pre-concurrency C or C++ compiler, the possible answers are 0 and 0 (unlikely),
1 and 0, 0 and 1, and 1 and 1. This has been observed “in the wild.” How? A linker might
allocate c and b right next to each other (in the same word) – nothing in the C or C++ 1990s
standards says otherwise. In that, C++98 resembled all languages not designed with real concurrent
hardware in mind. However, most modern processors cannot read or write a single character, it must
read or write a whole word, so the assignment to c really is “read the word containing c, replace
the c part, and write the word back again.” Since the assignment to b is similar, there are plenty of
opportunities for the two threads to clobber each other even though the threads do not (according to
their source text) share data!
So, C++11 guarantees that no such problems occur for “separate memory locations.” More
precisely: A memory location cannot be safely accessed by two threads without some form of
locking unless they are both read accesses. Note that different bitfields within a single word are not
 separate memory locations, so don’t share structs with bitfields among threads without some form
of locking. Apart from that caveat, the C++ memory model is simply “as everyone would expect.”
However, it is not always easy to think straight about low-level concurrency issues. Consider:
1. // start with x==0 and y==0
2.
3. if (x) y = 1; // Thread 1
4.
5. if (y) x = 1; // Thread 2
Is there a problem here? More precisely, is there a data race? (No there isn’t).
Fortunately, we have already adapted to modern times and every current C++ compiler (that we
know of) gives the one right answer and have done so for years. They do so for most (but
unfortunately not yet for all) tricky questions. After all, C++ has been used for serious systems
programming of concurrent systems “forever.” The standard memory model further improves
things.
See also:
 Standard: 1.7 The C++ memory model [intro.memory]
 Herb Sutter: atomic<> Weapons: The C++ Memory Model and Modern Hardware, Part
1, Part 2, Slides, from C++ and Beyond, August 2012.
 Paul E. McKenney, Hans-J. Boehm, and Lawrence Crowl: C++ Data-Dependency Ordering:
Atomics and Memory Model. N2556==08-0066.
 Hans-J. Boehm: Threads basics, HPL technical report 2009-259. “what every programmer
should know about memory model issues.”
 Hans-J. Boehm and Paul McKenney: A somewhat dated FAQ on C++ memory model issues.
Dynamic initialization and destruction with concurrency
See
 [N2660 = 08-0170] Lawrence Crowl: Dynamic Initialization and Destruction with
Concurrency (Final proposal).
Thread-local storage
In C++11 you can use the storage class thread_local to define a variable that should be
instantiated once per thread.
Note that using thread_local storage requires care, and in particular does not work well with
most parallel algorithms.
See
 [N2659 = 08-0169] Lawrence Crowl: Thread-Local Storage (final proposal).

C++11 Language Extensions — Miscellaneous

Language Features
Save to:
InstapaperPocketReadability
Contents of this section:

 What is the value of __cplusplus for C++11?

 Suffix return type syntax
  Preventing narrowing
 Right-angle brackets
 static_assert compile-time assertions
 Raw string literals
 Attributes
 Alignment
 C99 features
What is the value of __cplusplus for C++11?
In C++11 the macro __cplusplus is set to the value 201103L. (Before C++11, it was 199711L.)
Suffix return type syntax
Consider:
1. template<class T, class U>
2. ??? mul(T x, U y)
3. {
4. return x*y;
5. }
What can we write as the return type? It’s “the type of x*y”, of course, but how can we say that?
First idea, use decltype:
1. template<class T, class U>
2. decltype(x*y) mul(T x, U y) // scope problem!
3. {
4. return x*y;
5. }
That won’t work because x and y are not in scope. However, we can write:
1. template<class T, class U>
2. decltype(*(T*)(0)**(U*)(0)) mul(T x, U y) // ugly! and error prone
3. {
4. return x*y;
5. }
However, calling that “not pretty” would be overly polite.
The solution is put the return type where it belongs, after the arguments:
1. template<class T, class U>
2. auto mul(T x, U y) -> decltype(x*y)
3. {
4. return x*y;
5. }
We use the notation auto to mean “return type to be deduced or specified later.”
The suffix syntax is not primarily about templates and type deduction, it is really about scope.
1. struct List {
2. struct Link { /* ... */ };
3. Link* erase(Link* p); // remove p and return the link before p
4. // ...
5. };
6.
7. List::Link* List::erase(Link* p) { /* ... */ }
The first List:: is necessary only because the scope of List isn’t entered until the
second List::. Better:
1. auto List::erase(Link* p) -> Link* { /* ... */ }
Now neither Link needs explicit qualification.
 See also:
 [Str02] Bjarne Stroustrup. Draft proposal for “typeof”. C++ reflector message c++std-ext-
5364, October 2002.
 [N1478=03-0061] Jaakko Jarvi, Bjarne Stroustrup, Douglas Gregor, and Jeremy
Siek: Decltype and auto.
 [N2445=07-0315] Jason Merrill: New Function Declarator Syntax Wording.
 [N2825=09-0015] Lawrence Crowl and Alisdair Meredith: Unified Function Syntax.
Preventing narrowing
The problem: C and C++ implicitly truncate:
1. int x = 7.3; // Ouch!
2. void f(int);
3. f(7.3); // Ouch!
However, in C++11, {} initialization doesn’t narrow:
1. int x0 {7.3}; // error: narrowing
2. int x1 = {7.3}; // error: narrowing
3. double d = 7;
4. int x2{d}; // error: narrowing (double to int)
5. char x3{7}; // ok: even though 7 is an int, this is not narrowing
6. vector<int> vi = { 1, 2.3, 4, 5.6 }; // error: double to int narrowing
The way C++11 avoids a lot of incompatibilities is by relying on the actual values of initializers
(such as 7 in the example above) when it can (and not just type) when deciding what is a narrowing
conversion. If a value can be represented exactly as the target type, the conversion is not narrowing.
1. char c1{7}; // OK: 7 is an int, but it fits in a char
2. char c2{77777}; // error: narrowing (assuming 8-bit chars)
Note that floating-point to integer conversions are always considered narrowing – even 7.0 to 7.
See also:
 the C++ draft section 8.5.4.
 [N1890=05-0150 ] Bjarne Stroustrup and Gabriel Dos Reis: Initialization and initializers (an
overview of initialization-related problems with suggested solutions).
 [N2215=07-0075] Bjarne Stroustrup and Gabriel Dos Reis: Initializer lists (Rev. 3).
 [N2640=08-0150] Jason Merrill and Daveed Vandevoorde: Initializer Lists – Alternative
Mechanism and Rationale (v. 2) (final proposal).
Right-angle brackets
Consider
1. list<vector<string>> lvs;
In C++98 this is a syntax error because there is no space between the two >s. C++11 recognizes
such two >s as a correct termination of two template argument lists.
Why was this ever a problem? A compiler front-end is organized parses/stages. This is about the
simplest model:
 lexical analysis (make up tokens from characters)
 syntax analysis (check the grammar)
 type checking (find the type of names and expressions)
These stages are in theory and sometimes in practice strictly separate, so the lexical analyzer that
determines that >> is a token (usually meaning right-shift or input) has no idea of its meaning; in
particular, it has no idea of templates or nested template argument lists. However, to get that
example “correct” the three stages must somehow cooperate. The key observation that led to the
 problem being resolved was that every C++ compiler already did understand the problem so that it
could give decent error messages.
See also:
 [N1757==05-0017] Daveed Vandevoorde: revised right angle brackets proposal (revision 2).
static_assert compile-time assertions
A static (compile time) assertion consists of a constant expression and a string literal:
1. static_assert(expression,string);
The compiler evaluates the expression and writes the string as an error message if the expression is
false (i.e., if the assertion failed). For example:
1. static_assert(sizeof(long)>=8, "64-bit code generation required for this library.");
2. struct S { X m1; Y m2; };
3. static_assert(sizeof(S)==sizeof(X)+sizeof(Y),"unexpected padding in S");
A static_assert can be useful to make assumptions about a program and its treatment by a
compiler explicit. Note that since static_assert is evaluated at compile time, it cannot be used
to check assumptions that depends on run-time values. For example:
1. int f(int* p, int n)
2. {
3. static_assert(p==0,"p is not null"); // error: static_assert() expression not a constant expression
4. // ...
5. }
(Instead, use a normal assert(p==0 && "p is not null"); or test and throw an exception in
case of failure.)
See also:
 the C++ draft 7 [4].
 [N1381==02-0039] Robert Klarer and John Maddock: Proposal to Add Static Assertions to
the Core Language.
 [N1720==04-0160] Robert Klarer, John Maddock, Beman Dawes, Howard
Hinnant: Proposal to Add Static Assertions to the Core Language (Revision 3).
Raw string literals
In many cases, such as when you are writing regular expressions for the use with the
standard regex library, the fact that a backslash (\) is an escape character is a real nuisance,
because in regular expressions backslash is used to introduce special characters representing
character classes. Consider how to write the pattern representing two words separated by a
backslash (\w\\\w):
1. string s = "\\w\\\\\\w"; // I hope I got that right
Note that the backslash character is represented as two backslashes in a regular expression.
Basically, a “raw string literal” is a string literal where a backslash is just a backslash so that our
example becomes:
1. string s = R"(\w\\\w)"; // I'm pretty sure I got that right
The original proposal for raw strings presents this as a motivating example
1. "('(?:[^\\\\']|\\\\.)*'|\"(?:[^\\\\\"]|\\\\.)*\")|" // Are the five backslashes correct or not?
2. // Even experts become easily confused.
The R"(...)" notation is a bit more verbose than the “plain” "..." but “something more” is
necessary when you don’t have an escape character: How do you put a quote in a raw string? Easy,
unless it is preceded by a ):
1. R"("quoted string")" // the string is "quoted string"
 So, how do we get the character sequence )" into a raw string? Fortunately, that’s a rare problem,
but "(...)" is only the default delimiter pair. We can add delimiters before and after
the (...) in "(...)". For example
1. R"***("quoted string containing the usual terminator (")")***" // the string is "quoted string
containing the usual terminator (")"
The character sequence after ) must be identical to the sequence before the (. This way we can cope
with (almost) arbitrarily complicated patterns.
The initial R of a raw string can be preceded by an encoding-prefix: u8, u, U, or L. For
example u8R"(fdfdfa)" is a UTF-8 string literal.
See also:
 Standard 2.13.4
 [N2053=06-0123] Beman Dawes: Raw string literals. (original proposal)
 [N2442=07-0312] Lawrence Crowl and Beman Dawes: Raw and Unicode String Literals;
Unified Proposal (Rev. 2). (final proposal combined with the User-defined literals proposal).
 [N3077==10-0067] Jason Merrill: Alternative approach to Raw String issues.
(replacing [ with ();
Attributes
“Attributes” is a new standard syntax aimed at providing some order in the mess of facilities for
adding optional and/or vendor specific information into source code
(e.g. __attribute__, __declspec, and #pragma). C++11 attributes differ from existing
syntaxes by being applicable essentially everywhere in code and always relating to the immediately
preceding syntactic entity. For example:
1. void f [ [ noreturn ] ] () // f() will never return
2. {
3. throw "error"; // OK
4. }
5.
6. struct foo* f [ [ carries_dependency ] ] (int i); // hint to optimizer
7. int* g(int* x, int* y [ [ carries_dependency ] ] );
As you can see, an attribute is placed within double square
brackets: [ [ … ] ]. noreturn and carries_dependency are the two attributes defined in the
standard.
There is a reasonable fear that attributes will be used to create language dialects. The
recommendation is to use attributes to only control things that do not affect the meaning of a
program but might help detect errors (e.g. noreturn) or help optimizers
(e.g. carries_dependency).
One planned use for attributes is improved support for OpenMP. For example:
1. for [ [ omp::parallel() ] ] (int i=0; i<v.size(); ++i) {
2. // ...
3. }
(Note that this very example again illustrates the concern that attributes will be (mis)used to hide
language extensions dressed up as [ [ keywords ] ] … the semantics of a parallel loop are decidedly
not the same as a sequential loop.)
As shown, attributes can be qualified.
See also:
 Standard: 7.6.1 Attribute syntax and semantics, 7.6.3-4 noreturn, carries_dependency 8
Declarators, 9 Classes, 10 Derived classes, 12.3.2 Conversion functions
  [N2418=07-027] Jens Maurer, Michael Wong: Towards support for attributes in C++
(Revision 3)
Alignment
Occasionally, especially when we are writing code that manipulate raw memory, we need to specify
a desired alignment for some allocation. For example:
1. alignas(double) unsigned char c[1024]; // array of characters, suitably aligned for doubles
2. alignas(16) char[100]; // align on 16 byte boundary
There is also an alignof operator that returns the alignment of its argument (which must be a
type). For example
1. constexpr int n = alignof(int); // ints are aligned on n byte boundaries
See also:
 Standard: 5.3.6 Alignof [expr.alignof]
 Standard: 7.6.2 Alignment specifier [dcl.align]
 [N3093==10-0083] Lawrence Crowl: C and C++ Alignment Compatibility. Aligning the
proposal to C’s later proposal.
 [N1877==05-0137] Attila (Farkas) Fehér: Adding Alignment Support to the C++
Programming Language. The original proposal.
C99 features
To preserve a high degree of compatibility, a few minor changes to the language were introduced in
collaboration with the C standards committee:
 long long.
 Extended integral types (i.e. rules for optional longer int types).
 UCN changes [N2170==07-0030] “lift the prohibitions on control and basic source universal
character names within character and string literals.”
 concatenation of narrow/wide strings.
 Not VLAs (Variable Length Arrays) a better version of which is being considered for
standardization.
Some extensions of the preprocessing rules were added:
 __func__ a macro that expands to the name of the lexically current function
 __STDC_HOSTED__
 _Pragma: _Pragma( X ) expands to #pragma X
 vararg macros (overloading of macros with different number of arguments), for example:
1. #define report(test, ...) ((test)?puts(#test):printf(_ _VA_ARGS_ _))
 empty macro arguments
A lot of standard library facilities were inherited from C99 (essentially all changes to the C99
library from its C89 predecessor):
See:
 Standard: 16.3 Macro replacement.
 [N1568=04-0008] P.J. Plauger: Proposed additions to TR-1 to improve compatibility with
C99.

C++11 Standard Library Extensions — General

Libraries
Save to:
 InstapaperPocketReadability
Contents of this section:

 unique_ptr
 shared_ptr
 weak_ptr
 Garbage collection ABI
 tuple
 Type traits
 function and bind
 Regular Expressions
 Time utilities
 Random number generation
 Scoped allocators
unique_ptr
unique_ptr (defined in <memory>) provides a semantics of strict ownership:
 owns the object it holds a pointer to
 is not CopyConstructible, nor CopyAssignable, however it is MoveConstructible and
MoveAssignable.
 stores a pointer to an object and deletes that object using the associated deleter when it is
itself destroyed (such as when leaving block scope (6.7)).
The uses of unique_ptr include:
 providing exception safety for dynamically allocated memory
 passing ownership of dynamically allocated memory to a function
 returning dynamically allocated memory from a function
 storing pointers in containers
unique_ptr is almost exactly as efficient as using a raw pointer, but with safe ownership
semantics. It’s “what auto_ptr should have been” (but that we couldn’t write in C++98).
unique_ptr is a move-only type, and so relies critically on rvalue references and move semantics.
Here is a conventional 20th-century piece of exception unsafe code:
1. X* f()
2. {
3. X* p = new X;
4. // do something - maybe throw an exception
5. return p;
6. }
A solution is to hold the pointer to the object on the free store in a unique_ptr:
1. X* f()
2. {
3. unique_ptr<X> p(new X); // or {new X} but not = new X
4. // do something -- maybe throw an exception
5. return p.release();
6. }
Now, if an exception is thrown, the unique_ptr will (implicitly) destroy the object pointed to.
That’s basic RAII. However, unless we really need to return a built-in pointer, we can do even better
by returning a unique_ptr:
1. unique_ptr<X> f()
2. {
3. unique_ptr<X> p(new X); // or {new X} but not = new X
4. // do something -- maybe throw an exception
5. return p; // the ownership is transferred out of f()
6. }
 We can use this f like this:
1. void g()
2. {
3. unique_ptr<X> q = f(); // move using move constructor
4. q->memfct(2); // use q
5. X x = *q; // copy the object pointed to
6. // ...
7. } // q and the object it owns is destroyed on exit
The unique_ptr has “move semantics” so the initialization of q with the rvalue that is the result of
the call f() simply transfers ownership into q.
One of the uses of unique_ptr is as a pointer in a container that owns its heap-allocated objects,
where in the past we might have used a built-in pointer except for exception safety problems (and to
guarantee destruction of the pointed to elements):
1. vector<unique_ptr<string>> vs { new string{"Doug"}, new string{"Adams"} };
unique_ptr is represented by a simple built-in pointer and the overhead of using one compared to
a built-in pointer are miniscule. In particular, unique_ptr does not offer any form of dynamic
checking.
See also:
 the C++ draft section 20.7.10
 Howard E. Hinnant: unique_ptr Emulation for C++03 Compilers.
shared_ptr
A shared_ptr is used to represent shared ownership; that is, when two pieces of code need access
to some data but neither has exclusive ownership (in the sense of being responsible for destroying
the object). A shared_ptr is a reference counted pointer where the object pointed to is deleted
when the use count goes to zero. Here is a highly artificial example:
1. void test()
2. {
3. shared_ptr<int> p1(new int); // count is 1
4. {
5. shared_ptr<int> p2(p1); // count is 2
6. {
7. shared_ptr<int> p3(p1); // count is 3
8. } // count goes back down to 2
9. } // count goes back down to 1
10. } // here the count goes to 0 and the int is deleted.
A more realistic example would be be pointers to nodes in a general graph where someone wanting
to remove a pointer to a node wouldn’t know if anyone else held a pointer to that node. If a node
can hold resources that require an action by a destructor (e.g. a file handle so that a file needs to be
closed when the node is deleted). You could consider shared_ptr to be for what you might
consider plugging in a garbage collector for, except that maybe you don’t have enough garbage for
that to be economical, your execution environment doesn’t allow that, or the resource managed is
not just memory (e.g. that file handle) so that you need release to be deterministic when the last user
goes away instead of done lazily at some nondeterminstic time, and ordered so that the object’s
destructor can safely use other heap objects. For example:
1. struct Node { // note: a Node may be pointed to from several other nodes.
2. shared_ptr<Node> left;
3. shared_ptr<Node> right;
4. File_handle f;
5. // ...
6. };
Here Node’s destructor (the implicitly generated destructor will do fine) deletes its sub-nodes; that
is, left and right’s destructors are invoked. When this node is destroyed, since left is
 a shared_ptr, the Node pointed to (if any) is deleted if left was the last pointer to it; right is
handled similarly and f’s destructor does whatever is required for f.
Note that you should not use a shared_ptr just to pass a pointer from one owner to another; that’s
what unique_ptr is for and unique_ptr does that cheaper and better. If you have been using
counted pointers as return values from factory functions and the like, consider upgrading
to unique_ptr rather than shared_ptr.
Please don’t thoughtlessly replace pointers with shared_ptrs in an attempt to prevent memory
leaks; shared_ptrs are not a panacea nor are they without costs:
 a circular linked structure of shared_ptrs will cause a memory leak (you’ll need some
logical complication to break the circle, e.g. using a weak_ptr),
 “shared ownership objects” tend to stay “live” for longer than scoped objects (thus causing
higher average resource usage),
 heavy manipulation of shared pointers themselves (such as transferring ownership around
frequently, though this is an antipattern) can be expensive in a multi-threaded environment
because of the need to avoid data races on the use count,
 the algorithms/logic for the update of any shared object is easier to get wrong than for an
object that’s not shared.
A shared_ptr represents shared ownership but shared ownership isn’t always ideal: By default, it
is better if an object has a definite owner and a definite, predictable lifespan. Prefer the following in
order: stack or member lifetime (stack variables or by-value member variables); heap allocation
with unique_ptr unique ownership; and heap allocation via make_shared with shared
ownership.
See also:
 the C++ draft: Shared_ptr (20.7.13.3)
 Herb Sutter: GotW #89: Smart Pointers.
 Herb Sutter: GotW #90: Factories.
 Herb Sutter: GotW #91: Smart Pointer Parameters.
weak_ptr
weak_ptrs are for shared observation just as shared_ptrs are for shared ownership. weak_ptrs
are commonly known to be what you need to break cycles in data structures managed
using shared_ptrs, but more generally it is better to think of a weak_ptr as a pointer to
something that
1. you need access to (only) if it exists, and
2. may get deleted (by someone else), and
3. must have its destructor called after its last use (usually to delete a non-memory resource)
Consider an implementation of the old “asteroid game”. All asteroids are owned by “the game” but
each asteroids must keep track of neighboring asteroids and handle collisions. A collision typically
leads to the destruction of one or more asteroids. Each asteroid must keep a list of other asteroids in
its neighborhood. Note that being on such a neighbor list should not keep an astroid “alive” (so
a shared_ptr would be inappropriate). On the other hand, an asteroid must not be destroyed while
another asteroid is looking at it (e.g. to calculate the effect of a collision). And obviously, an
asteroid’s destructor must be called to release resources (such as a connection to the graphics
system). What we need is a list of asteroids that might still be intact and a way of “getting hold of
one if it exists” for a while. A weak_ptr does just that:
1. void owner()
2. {
3. // ...
4. vector<shared_ptr<Asteroid>> va(100);
5. for (int i=0; i<va.size(); ++i) {
6. // ... calculate neighbors for new asteroid ...
7. va[i].reset(new Asteroid(weak_ptr<Asteroid>(va[neighbor]));
8. launch(i);
9. }
10. // ...
11. }
reset() is the function to make a shared_ptr refer to a new object.
Obviously, this example code radically simplified “the owner” and gave each new Asteroid just
one neighbor. The key is that we give the Asteroid a weak_ptr to that neighbor. The owner
keeps a shared_ptr to represent the ownership that’s shared whenever an Asteroid is looking
(but not otherwise). The collision calculation for an Asteroid will look something like this:
1. void collision(weak_ptr<Asteroid> p)
2. {
3. if (auto q = p.lock()) { // p.lock returns a shared_ptr to p's object
4. // ... that Asteroid still existed: calculate ...
5. }
6. else {
7. // ... oops: that Asteroid has already been destroyed: just forget about it (delete the weak_ptr to
it ...
8. }
9. }
Note that even if the owner decides to shut down the game and deletes all Asteroids (by
destroying the shared_ptrs representing ownership), every Asteroid that is in the middle of
calculating a collision still finishes correctly because after the p.lock() it holds
a shared_ptr that will ensure the Asteroid stays alive for at least as long as collision is
using it via that shared_ptr.
You should expect to find weak_ptr use much rarer than “plain” shared_ptr use, and both of
those to be rarer than unique_ptr which should be most popular of all as it represents a simpler
(and more efficient) notion of ownership and (therefore) allows better local reasoning.
See also:
 the C++ draft: weak_ptr (20.7.13.3)
Garbage collection ABI
Garbage collection (automatic recycling of unreferenced regions of memory) is optional in C++;
that is, a garbage collector is not a compulsory part of an implementation. However, C++11
provides a definition of what a GC can do if one is used and an ABI (Application Binary Interface)
to help control its actions.
The rules for pointers and lifetimes are expressed in terms of “safely derived pointer” (3.7.4.3);
roughly: “pointer to something allocated by new or to a sub-object thereof.” Here are some
examples of “not safely derived pointers” aka “disguised pointers” aka what not to do in a program
you want to be considered well behaved and comprehensible to ordinary mortals:
 Make a pointer point “elsewhere” for a while
1. int* p = new int;
2. p+=10;
3. // ... collector may run here ...
4. p-=10;
5. *p = 10; // can we be sure that the int is still there?
 Hide the pointer in an int
1. int* p = new int;
2. int x = reinterpret_cast<int>(p); // non-portable
3. p=0;
4. // ... collector may run here ...
5. p = reinterpret_cast<int*>(x);
6. *p = 10; // can we be sure that the int is still there?
 There are many more and even nastier tricks. Think I/O, think “scattering the bits around in
different words”, …
There are legitimate reasons to disguise pointers (e.g. the xor trick in exceptionally memory-
constrained applications), but not as many as some programmers think.
A programmer can specify where there are no pointers to be found (e.g. inside a JPEG image) and
what memory can’t be reclaimed even if the collector can’t find a pointer into it:
1. void declare_reachable(void* p); // the region of memory starting at p
2. // (and allocated by some allocator
3. // operation which remembers its size)
4. // must not be collected
5. template<class T> T* undeclare_reachable(T* p);
6.
7. void declare_no_pointers(char* p, size_t n); // p[0..n] holds no pointers
8. void undeclare_no_pointers(char* p, size_t n);
A programmer can inquire which rules for pointer safety and reclamation is in force:
1. enum class pointer_safety {relaxed, preferred, strict };
2. pointer_safety get_pointer_safety();
3.7.4.3[4]: If a pointer value that is not a safely-derived pointer value is dereferenced or deallocated,
and the referenced complete object is of dynamic storage duration and has not previously been
declared reachable (20.7.13.7), the behavior is undefined.
 relaxed: safely-derived and not safely-derived pointers are treated equivalently; like C and
C++98, but that was not my intent - I wanted to allow GC if a user didn’t keep a valid pointer
around for an object.
 preferred: like relaxed; but a garbage collector may be running as a leak detector and/or
detector of dereferences of “bad pointers”
 strict: safely-derived and not safely-derived pointers may be treated differently, i.e. a garbage
collector may be running and will ignore pointers that aren’t safely derived
There is no standard way of saying which alternative you prefer. Considered that a “quality of
implementation” and a “programming environment” issue.
See also:
 the C++ draft 3.7.4.3
 the C++ draft 20.7.13.7
 Hans Boehm’s GC page
 Hans Boehm’s Discussion of Conservative GC
 N2527: Hans-J. Boehm and Mike Spertus: Minimal Support for Garbage Collection and
Reachability-Based Leak Detection (revised) (final proposal)
 Michael Spertus and Hans J. Boehm: The Status of Garbage Collection in C++0X. ACM
ISMM’09.
tuple
The standard library tuple (an N-tuple) is a ordered sequence of N values where N can be a
constant from 0 to a large implementation-defined value, defined in <tuple>. You can think of
a tuple as an unnamed struct with members of the specified element types. In particular, the
elements of a tuple are stored compactly; a tuple is not a linked structure.
The element types of a tuple can explicitly specified or be deduced (using make_tuple()) and
the elements can be access by (zero-based) index using get():
1. tuple<string,int> t2("Kylling",123);
2.
3. auto t = make_tuple(string("Herring"),10, 1.23); // t will be of type tuple<string,int,double>
4. string s = get<0>(t);
5. int x = get<1>(t);
6. double d = get<2>(t);
Tuples are used (directly of indirectly) whenever we want a heterogeneous list of elements at
compile time but do not want to define a named class to hold them. For example, tuple is used
internally in std::function and std::bind to hold arguments.
The most frequently useful tuple is the 2-tuple; that is, a pair. However, pair is directly
supported in the standard library through std::pair (20.3.3 Pairs). A pair can be used to
initialize a tuple, but the opposite isn’t the case.
The comparison operators (==, !=, <, <=, >, and >=) are defined for tuples of comparable element
types.
See also:
 Standard: 20.5.2 Class template tuple
 [N2087==06-0157] Douglas Gregor: A Brief Introduction to Variadic Templates.
 Boost::tuple
Type traits
See:
 [N2984==09-0174] B. Dawes, D. Krügler, A. Meredith: Additional Type Traits for C++0x
(Revision 1).
function and bind
Note: function is long-term useful. However, bind is almost entirely superseded by C++14
lambdas with generalized lambda capture, but it has a few advantages if your compiler supports
only C++11 lambdas and can be more compact in basic cases.
The bind and function standard function objects are defined in <functional> (together with a
lot of other function objects); they are used to handle functions and function arguments. bind is
used to take a function (or a function object or anything you can invoke using the (a,b,c) syntax)
and produce a function object with one or more of the arguments of the argument function “bound”
or rearranged. For example:
1. int f(int,char,double);
2.
3. auto ff = bind(f,_1,'c',1.2); // deduce return type
4. int x = ff(7); // f(7,'c',1.2);
5.
6. // equivalent with lambdas
7. auto ff2 = [](int i){ f(i,'c',1.2); }; // deduce return type
8. int x2 = ff2(7); // f(7,'c',1.2);
This binding of arguments is usually called “Currying.” The _1 is a placeholder object indicating
where the first argument of ff is to go when f is called through ff. The first argument is called _1,
the second _2, and so on. For example:
1. int f(int,char,double);
2.
3. auto frev = bind(f,_3,_2,_1); // reverse argument order
4. int x = frev(1.2,'c',7); // f(7,'c',1.2);
5.
6. // equivalent with lambdas
7. auto frev2 = [](double d, char c, int i){ f(i,c,d); }; // reverse argument order
8. int x2 = frev2(1.2,'c',7); // f(7,'c',1.2);
Note how auto saves us from having to specify the type of the result of bind.
 If the function to be called is overloaded, it is not possible to just bind arguments. Instead, we have
to explicitly state which version of an overloaded function we want to bind:
1. int g(int);
2. double g(double); // g() is overloaded
3.
4. auto g1 = bind(g,_1); // error: which g()?
5. auto g2 = bind((double(*)(double))g,_1); // ok (but ugly)
6.
7. // equivalent with C++11 lambdas, which handle this naturally
8. auto g3 = [](double d){ g(d); }; // ok in C++11
9.
10. // both shorter and more powerful with C++14 lambdas
11. auto g4 = [](auto x){ g(x); }; // ok in C++14, and gives full access to the overload set
bind() comes in two variants: the one shown above and a “legacy” version where you explicitly
specify the return type:
1. auto f2 = bind<int>(f,7,'c',_1); // explicit return type
2. int x = f2(1.2); // f(7,'c',1.2);
This second version was necessary in C++98 and is widely used because the first (and for a user
simplest) version cannot be implemented in C++98.
function is a type that can hold a value of just about anything you can invoke using
the (a,b,c) syntax, including allowing conversions on the parameters and the return type, making
it a very flexible facility indeed while preserving strict type-safety. In particular, the result
of bind can be assigned to a function. function is very simple to use. For example:
1. function<float (int x, int y)> f; // make a function object
2.
3. struct int_div { // take something you can call using ()
4. float operator()(int x, int y) const { return ((float)x)/y; };
5. };
6.
7. f = int_div(); // assign
8. cout << f(5, 3) << endl; // call through the function object
9. std::accumulate(b,e,1,f); // passes beautifully
Member functions can be treated as free functions with an extra “explicit this” argument:
1. struct X {
2. int foo(int);
3. };
4.
5. function<int (X*, int)> f;
6. f = &X::foo; // pointer to member
7.
8. X x;
9. int v = f(&x, 5); // call X::foo() for x with 5
10. function<int (int)> ff = std::bind(f,&x,_1); // first argument for f is &x
11. v=ff(5); // call x.foo(5)
functions are useful for callbacks, for passing operations as argument, etc. function can be seen
as a replacement for the C++98 standard library function
objects mem_fun_t, pointer_to_unary_function, etc. Similarly, bind() can be seen as a
replacement for bind1st() and bind2nd().
See also:
 Standard: 20.7.12 Function template bind, 20.7.16.2 Class template function
 Herb Sutter: Generalized Function Pointers. August 2003.
 Douglas Gregor: Boost.Function.
  Boost::bind
Regular Expressions
To be written.
In the meantime, see:
 Microsoft documentation.
Time utilities
We often want to time things or to do things dependent on timing. For example, the standard-
library mutexes and locks provide the option for a thread to wait for a period of time (a duration)
or to wait until a given point in time (a time_point).
If you want to know the current time_point, you can call now() for one of three
clocks: system_clock, steady_clock, and high_resolution_clock. For example:
1. steady_clock::time_point t = steady_clock::now();
2. // do something
3. steady_clock::duration d = steady_clock::now() - t;
4. // something took d time units
A clock returns a time_point, and a duration is the difference between two time_points from
the same clock. As usual, if you are not interested in details, auto is your friend:
1. auto t = steady_clock::now();
2. // do something
3. auto d = steady_clock::now() - t;
4. // something took d time units
The time facilities here are intended to efficiently support uses deep in the system; they do not
provide convenience facilities to help you maintain your social calendar. In fact, the time facilities
originated with the stringent needs for high-energy physics. To be able to express all time scales
(such as centuries and picoseconds), avoid confusion about units, typos, and rounding
errors, durations and time_points are expressed using a compile-time rational number package.
A duration has two parts: a numeric clock “tick” and something (a “period”) that says what a tick
means (is it a second or a millisecond?); the period is part of a duration’s type. The following
table from the standard header <ratio>, defining the periods of the SI system (also known as MKS
or metric system) might give you an idea of the scope of use:
1. // convenience SI typedefs:
2. typedef ratio<1, 1000000000000000000000000> yocto; // conditionally supported
3. typedef ratio<1, 1000000000000000000000> zepto; // conditionally supported
4. typedef ratio<1, 1000000000000000000> atto;
5. typedef ratio<1, 1000000000000000> femto;
6. typedef ratio<1, 1000000000000> pico;
7. typedef ratio<1, 1000000000> nano;
8. typedef ratio<1, 1000000> micro;
9. typedef ratio<1, 1000> milli;
10. typedef ratio<1, 100> centi;
11. typedef ratio<1, 10> deci;
12. typedef ratio< 10, 1> deca;
13. typedef ratio< 100, 1> hecto;
14. typedef ratio< 1000, 1> kilo;
15. typedef ratio< 1000000, 1> mega;
16. typedef ratio< 1000000000, 1> giga;
17. typedef ratio< 1000000000000, 1> tera;
18. typedef ratio< 1000000000000000, 1> peta;
19. typedef ratio< 1000000000000000000, 1> exa;
20. typedef ratio< 1000000000000000000000, 1> zetta; // conditionally supported
21. typedef ratio<1000000000000000000000000, 1> yotta; // conditionally supported
 The compile time rational numbers provide the usual arithmetic (+, -, *, and /) and comparison
(==, !=, <, <=, >, >=) operators for whatever combinations durations and time_points makes
sense (e.g. you can’t add two time_points). These operations are also checked for overflow and
divide by zero. Since this is a compile-time facility, don’t worry about run-time performance. In
addition you can use ++, --, +=, -=, *=, and /= on durations and tp+=d and tp-=d for
a time_point tp and a duration d.
Here are some examples of values using standard duration types as defined in <chrono>:
1. microseconds mms = 12345;
2. milliseconds ms = 123;
3. seconds s = 10;
4. minutes m = 30;
5. hours h = 34;
6.
7. auto x = std::chrono::hours(3); // being explicit about namespaces
8. auto x = hours(2)+minutes(35)+seconds(9); // assuming suitable "using"
You cannot initialize a duration to a fraction. For example, don’t try 2.5 seconds; instead use
2500 milliseconds. This is because a duration is interpreted as a number of “ticks.” Each tick
represents one unit of the duration’s “period,” such as milli and kilo as defined above. The
default unit is seconds; that is, for a duration with a period of 1 a tick is interpreted as a second. We
can be explicit about the representation of a duration:
1. duration<long> d0 = 5; // seconds (by default)
2. duration<long,kilo> d1 = 99; // kiloseconds!
3. duration<long,ratio<1000,1>> d2 = 100; // d1 and d2 have the same type ("kilo" means "*1000")
If we actually want to do something with a duration, such as writing it out, we have to give a unit,
such as minutes or microseconds. For example:
1. auto t = steady_clock::now();
2. // do something
3. nanoseconds d = steady_clock::now() - t; // we want the result in nanoseconds
4. cout << "something took " << d << "nanoseconds\n";
Alternatively, we could convert the duration to a floating point number (to get rounding):
1. auto t = steady_clock::now();
2. // do something
3. auto d = steady_clock::now() - t;
4. cout << "something took " << duration_cast<double>(d).count() << "seconds\n";
The count() is the number of “ticks.”“
See also:
 Standard: 20.9 Time utilities [time]
 Howard E. Hinnant, Walter E. Brown, Jeff Garland, and Marc Paterno: A Foundation to
Sleep On. N2661=08-0171. Including “A Brief History of Time” (With apologies to Stephen
Hawking).
Random number generation
Random numbers are useful in many contexts, such as testing, games, simulation, and security. The
diversity of application areas is reflected in the wide selection of random number generation utilities
provided by the standard library. A random number generator consists of two parts: (1) an engine
that produces a sequence of random or pseudo-random values, and (2) a distribution that maps those
values to a mathematical distribution in a range. Examples of distributions
are uniform_int_distribution (where all integers produced are equally likely)
and normal_distribution (“the bell curve”), each for some specified range. For example:
1. uniform_int_distribution<int> one_to_six {1,6}; // distribution that maps to the ints 1..6
2. default_random_engine re {}; // the default engine
To get a random number, you call a distribution with an engine:
1. int x = one_to_six(re); // x becomes a value in [1:6]
To avoid passing the engine in every call, we could bind that argument to get a function object
that’s callable without arguments:
1. auto dice {bind(one_to_six,re)}; // make a generator
2.
3. int x = dice(); // roll the dice: x becomes a value in [1:6]
(Thanks to its uncompromising attention to generality and performance, one expert deemed the
standard-library random number component “what every random number library wants to be when
it grows up.)
What if we just want something simple to use like:
1. int rand_int(int low, int high); // generate a random number from a uniform distribution in
[low:high]
So, how could we get that? We have to put something like dice() inside rand_int():
1. int rand_int(int low, int high)
2. {
3. static default_random_engine re {};
4. using Dist = uniform_int_distribution<int>;
5. static Dist uid {};
6. return uid(re, Dist::param_type{low,high});
7. }
While providing that definition needs a bit of expertise, calling rand_int() is manageable in even
the first week of a C++ course.
Just to show a non-trivial example, here is a program that generates and prints a normal
distribution’s histogram:
1.
#include <iostream>
2. #include <random>
3. #include <vector>
4.
5. std::default_random_engine re; // the default engine
6. std::normal_distribution<double> nd(31 /* mean */, 8 /* sigma */);
7.
8. auto norm = std::bind(nd, re);
9.
10. std::vector<int> mn(64);
11.
12. int main()
13. {
14. for (int i = 0; i<1200; ++i) ++mn[round(norm())]; // generate
15.
16. for (int i = 0; i<mn.size(); ++i) {
17. std::cout << i << '\t';
18. for (int j=0; j<mn[i]; ++j) std::cout << '*';
19. std::cout << '\n';
20. }
21. }
The result of one execution was:
1. 0
2. 1
3. 2
4. 3
5. 4 *
6. 5
7. 6
8. 7
9. 8
10. 9 *
11. 10 ***
12. 11 ***
13. 12 ***
14. 13 *****
15. 14 *******
16. 15 ****
17. 16 **********
18. 17 ***********
19. 18 ****************
20. 19 *******************
21. 20 *******************
22. 21 **************************
23. 22 **********************************
24. 23 **********************************************
25. 24 ********************************************
26. 25 *****************************************
27. 26 *********************************************
28. 27 *********************************************************
29. 28 ***************************************************
30. 29 ******************************************************************
31. 30 **********************************************
32. 31 *********************************************************************
33. 32 **********************************************
34. 33 *************************************************************
35. 34 **************************************************************
36. 35 ***************************************
37. 36 ***********************************************
38. 37 **********************************************
39. 38 *********************************************
40. 39 ********************************
41. 40 ********************************************
42. 41 ***********************
43. 42 **************************
44. 43 ******************************
45. 44 *****************
46. 45 *************
47. 46 *********
48. 47 ********
49. 48 *****
50. 49 *****
51. 50 ****
52. 51 ***
53. 52 ***
54. 53 **
55. 54 *
56. 55 *
57. 56
58. 57 *
59. 58
60. 59
61. 60
62. 61
63. 62
64. 63
See also:
 Standard 26.5: Random number generation
 Walter E. Brown: Random Number Generation in C++11 – note, normally committee papers
are not tutorials, and it’s not often you get an excellent tutorial written by a world-class expert
who is also the designer of the library – strongly recommended as a go-to source of information
about <random>
Scoped allocators
For compactness of container objects and for simplicity, C++98 did not require containers to
support allocators with state: Allocator objects need not be stored in container objects. This is still
the default in C++11, but it is possible to use an allocator with state, say an allocator that holds a
pointer to an arena from which to allocate. For example:
1. template<class T> class Simple_alloc { // C++98 style
2. // no data
3. // usual allocator stuff
4. };
5.
6. class Arena {
7. void* p;
8. int s;
9. public:
10. Arena(void* pp, int ss);
11. // allocate from p[0..ss-1]
12. };
13.
14. template<class T> struct My_alloc {
15. Arena& a;
16. My_alloc(Arena& aa) : a(aa) { }
17. // usual allocator stuff
18. };
19.
20. Arena my_arena1(new char[100000],100000);
21. Arena my_arena2(new char[1000000],1000000);
22.
23. vector<int> v0; // allocate using default allocator
24.
25. vector<int,My_alloc<int>> v1(My_alloc<int>{my_arena1}); // allocate from my_arena1
26.
27. vector<int,My_alloc<int>> v2(My_alloc<int>{my_arena2}); // allocate from my_arena2
28.
29. vector<int,Simple_alloc<int>> v3; // allocate using Simple_alloc
Typically, the verbosity would be alleviated by the use of typedefs.
It is not guaranteed that the default allocator and Simple_alloc take up no space in
a vector object, but a bit of elegant template metaprogramming in the library implementation can
ensure that. So, using an allocator type imposes a space overhead only if its objects actually has
state (like My_alloc).
A rather sneaky problem can occur when using containers and user-defined allocators: Should an
element be in the same allocation area as its container? For example, if you
use Your_alloc for Your_string to allocate its elements and someone else uses My_alloc to
allocate elements of My_vector, then which allocator should be used for string elements
in My_vector<Your_alloc>>? The solution is the ability to tell a container which allocator to
pass to elements. For example, assuming that there is an allocator My_alloc and you want
 a vector<string> that uses My_alloc for both the vector element and string element
allocations, first, you must make a version of string that accepts My_alloc objects:
1. using xstring = basic_string<char, char_traits<char>, My_alloc<char>>; // a string with my allocator
Then, you must make a version of vector that accepts those strings, accepts a My_alloc object,
and passes that object on to the string:
1. using svec = vector<xstring,scoped_allocator_adaptor<My_alloc<xstring>>>;
Finally, we can make an allocator of type My_alloc<xstring>:
1. svec v(svec::allocator_type(My_alloc<xstring>{my_arena1}));
Now svec is a vector of strings using My_alloc to allocate memory for strings. What’s new is
that the standard library “adaptor” (“wrapper type”) scoped_allocator_adaptor is used to
indicate that string also should use My_alloc. Note that the adaptor can (trivially)
convert My_alloc<xstring> to the My_alloc<char> that string needs.
So, we have four alternatives:
1. // vector and string use their own (the default) allocator:
2. using svec0 = vector<string>;
3. svec0 v0;
4.
5. // vector (only) uses My_alloc and string uses its own (the default) allocator:
6. using svec1 = vector<string,My_alloc<string>>;
7. svec1 v1(My_alloc<string>{my_arena1});
8.
9. // vector and string use My_alloc (as above):
10. using xstring = basic_string<char, char_traits<char>, My_alloc<char>>;
11. using svec2 = vector<xstring,scoped_allocator_adaptor<My_alloc<xstring>>>;
12. svec2 v2(scoped_allocator_adaptor<My_alloc<xstring>>{my_arena1});
13.
14. // vector uses My_alloc and string uses My_string_alloc:
15. using xstring2 = basic_string<char, char_traits<char>, My_string_alloc<char>>;
16. using svec3 = vector<xstring2,scoped_allocator_adaptor<My_alloc<xstring>, My_string_alloc<char>>>;
17. svec3 v3(scoped_allocator_adaptor<My_alloc<xstring2>,
My_string_alloc<char>>{my_arena1,my_string_arena});
Obviously, the first variant, svec0, will be by far the most common, but for systems with serious
memory-related performance constraints, the other versions (especially svec2) can be important. A
few typedefs would make that code a bit more readable, but it is good it is not something you
have to write every day. The scoped_allocator_adaptor2 is a variant
of scoped_allocator_adaptor for the case where the two non-default allocators differ.
See also:
 Standard: 20.8.5 Scoped allocator adaptor [allocator.adaptor]
 Pablo Halpern: The Scoped Allocator Model (Rev 2). N2554=08-0064.

C++11 Standard Library Extensions —

Containers and Algorithms
Save to:
InstapaperPocketReadability
Contents of this section:

 Algorithms improvements
 Container improvements
 unordered_* containers
 std::array
 forward_list
 Algorithms improvements
The standard library algorithms are improved partly by simple addition of new algorithms, partly by
improved implementations made possible by new language features, and partly by new language
features enabling easier use:
 New algorithms:
1. bool all_of(Iter first, Iter last, Pred pred);
2. bool any_of(Iter first, Iter last, Pred pred);
3. bool none_of(Iter first, Iter last, Pred pred);
4.
5. Iter find_if_not(Iter first, Iter last, Pred pred);
6.
7. OutIter copy_if(InIter first, InIter last, OutIter result, Pred pred);
8. OutIter copy_n(InIter first, InIter::difference_type n, OutIter result);
9.
10. OutIter move(InIter first, InIter last, OutIter result);
11. OutIter move_backward(InIter first, InIter last, OutIter result);
12.
13. pair<OutIter1, OutIter2> partition_copy(InIter first, InIter last, OutIter1 out_true, OutIter2 out_false,
Pred pred);
14. Iter partition_point(Iter first, Iter last, Pred pred);
15.
16. RAIter partial_sort_copy(InIter first, InIter last, RAIter result_first, RAIter result_last);
17. RAIter partial_sort_copy(InIter first, InIter last, RAIter result_first, RAIter result_last, Compare
comp);
18. bool is_sorted(Iter first, Iter last);
19. bool is_sorted(Iter first, Iter last, Compare comp);
20. Iter is_sorted_until(Iter first, Iter last);
21. Iter is_sorted_until(Iter first, Iter last, Compare comp);
22.
23. bool is_heap(Iter first, Iter last);
24. bool is_heap(Iter first, Iter last, Compare comp);
25. Iter is_heap_until(Iter first, Iter last);
26. Iter is_heap_until(Iter first, Iter last, Compare comp);
27.
28. T min(initializer_list<T> t);
29. T min(initializer_list<T> t, Compare comp);
30. T max(initializer_list<T> t);
31. T max(initializer_list<T> t, Compare comp);
32. pair<const T&, const T&> minmax(const T& a, const T& b);
33. pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
34. pair<const T&, const T&> minmax(initializer_list<T> t);
35. pair<const T&, const T&> minmax(initializer_list<T> t, Compare comp);
36. pair<Iter, Iter> minmax_element(Iter first, Iter last);
37. pair<Iter, Iter> minmax_element(Iter first, Iter last, Compare comp);
38.
39. void iota(Iter first, Iter last, T value); // For each element referred to by the iterator i in the range
[first,last), assigns *i = value and increments value as if by ++value
 Effects of move: Moving can be much more efficient than copying (see Move semantics. For
example, move-based std::sort() and std::set::insert() have been measured to be 15
times faster than copy based versions. This is less impressive than it sounds because such standard
library operations for standard library types, such as string and vector, are usually hand-
optimized to gain the effects of moving through techniques such as replacing copies with
optimized swaps. However, if your type has a move operation, you gain the performance benefits
 automatically from the standard algorithms. Consider also that the use of moves allows simple
and efficient sort (and other algorithms) of containers of smart pointers, especially unique_ptr:
1. template<class P> struct Cmp<P> { // compare *P values
2. bool operator() (P a, P b) const { return *a<*b; }
3. }
4.
5. vector<std::unique_ptr<Big>> vb;
6. // fill vb with unique_ptr's to Big objects
7.
8. sort(vb.begin(),vb.end(),Cmp<Big>()); // don't try that with an auto_ptr
 Use of lambdas: For ages, people have complained about having to write functions or (better)
function objects for use as operations, such as Cmp<T> above, for standard library (and other)
algorithms. This was especially painful to do if you wrote large functions (don’t) because in C+
+98 you could not define a local function object to use as an argument; now you can.
However, lambdas allows us to define operations “inline”:
1. sort(vb.begin(),vb.end(),[](unique_ptr<Big> a, unique_ptr<Big> b) { return *a<*b; });
 Use of initializer lists: Sometimes, initializer lists come in handy as arguments. For example,
assuming string variables and Nocase being a case-insensitive comparison:
1. auto x = max({x,y,z},Nocase());
See also:
 25 Algorithms library [algorithms]
 26.7 Generalized numeric operations [numeric.ops]
 Howard E. Hinnant, Peter Dimov, and Dave Abrahams: A Proposal to Add Move Semantics
Support to the C++ Language. N1377=02-0035.
Container improvements
Given the new language features and a decade’s worth of experience, what has happened to the
standard containers? First, of course we got a few new ones: array (a fixed-sized
container), forward_list (a singly-linked list), and unordered containers (the hash tables). Next, new
features, such as initializer lists, rvalue references, variadic templates, and constexpr[cpp11-
constexpr] were put to use. Consider std::vector.
 Initializer lists: The most visible improvement is the use of initializer-list constructors to
allow a container to take an initializer list as its argument:
1. vector<string> vs = { "Hello", ", ", "World!", "\n" };
2. for (auto s : vs ) cout << s;
 Move operators: Containers now have move constructors and move assignments (in addition
to the traditional copy operations). The most important implication of this is that we can
efficiently return a container by value from a function:
1. vector<int> make_random(int n)
2. {
3. vector<int> ref(n);
4. for(auto& x : ref) x = rand_int(0,255); // some random number generator
5. return ref;
6. }
7.
8. vector<int> v = make_random(10000);
9. for (auto x : make_random(1000000)) cout << x << '\n';
The point here is that no vectors are copied. Rewrite this to return a free-store-allocated vector and
you have to deal with memory management. Rewrite this to pass the vector to be filled as an
argument to make_random() and you have a far less obvious code (plus an added opportunity for
making an error).
 Improved push operations: Many people’s favorite container operation is push_back() that
allows a container to grow gracefully:
1. vector<pair<string,int>> vp;
2. string s;
3. int i;
4. while(cin>>s>>i) vp.push_back({s,i});
This will construct a pair<string,int> out of s and i and move it into vp. Note “move” not
“copy;” there is a push_back version that takes an rvalue reference argument so that we can take
advantage of string’s move constructor. Note also the use of the uniform initializer syntax to
avoid verbosity.
 Emplace operations: The push_back() using a move constructor is far more efficient in
important cases than the traditional copy-based one, but in extreme cases we can go further. Why
copy/move anything? Why not make space in the vector and then construct the desired value in
that space? Operations that do that are called “emplace” (meaning “putting in place”). For
example emplace_back():
1. vector<pair<string,int>> vp;
2. string s;
3. int i;
4. while(cin>>s>>i) vp.emplace_back(s,i);
An emplace takes a variadic template argument and uses that to construct an object of the desired
type. Whether the emplace_back() really is more efficient than the push_back() depends on
the types involved and the implementation (of the library and of variadic templates). If you think it
matters, measure. Otherwise, choose based on
aesthetics: vp.push_back({s,i}); or vp.emplace_back(s,i);. For now, many prefer
the push_back() version in part due to familiarity, but that might change over time.
 Scoped allocators: Containers can now hold “real allocation objects (with state)” and use
those to control nested/scoped allocation (e.g. allocation of elements in a container).
Obviously, the containers are not the only parts of the standard library that have benefited from the
new language features. Consider:
 Compile-time evaluation: constexpr is used to ensure compiler time evaluation
in <numeric_limits>, bitset, duration, char_traits, array, atomic types, random
numbers, complex, etc. In some cases, it means improved performance; in others (where there is
no alternative to compile-time evaluation), it means absence of messy low-level code and macros.
 Tuples: Tuples would not be possible without variadic templates
unordered_* containers
An unordered_* container is implemented using a hash table. C++11 offers four standard ones:
 unordered_map
 unordered_set
 unordered_multimap
 unordered_multiset
They would have been called hash_map etc., but there are so many incompatible uses of those
names that the committee had to choose new names and the unordered_* name nicely
highlighted the key difference between (say) map and unordered_map: When you iterate over
a map from begin() to end(), you do so in the order provided by its key type’s less-than
comparison operator (by default <) whereas the value type of unordered_map is not required to
have a less-than comparison operator and a hash table doesn’t naturally provide an order. The are
other differences; in particular, conversely, the element type of a map is not required to have a hash
function.
The basic idea is simply to use unordered_map as an optimized version of map where
optimization is possible and reasonable. For example:
1. map<string,int> m {
2. {"Dijkstra",1972}, {"Scott",1976}, {"Wilkes",1967}, {"Hamming",1968}
3. };
4. m["Ritchie"] = 1983;
5. for(auto& x : m) cout << '{' << x.first << ',' << x.second << '}';
6.
7. unordered_map<string,int> um {
8. {"Dijkstra",1972}, {"Scott",1976}, {"Wilkes",1967}, {"Hamming",1968}
9. };
10. um["Ritchie"] = 1983;
11. for(auto& x : um) cout << '{' << x.first << ',' << x.second << '}';
The iterator over m will present the elements in alphabetical order; the iteration over um will not
(except through a freak accident). Lookup is implemented very differently for m and um.
For m lookup involves log2(m.size()) less-than comparisons, whereas for um lookup involves a
single call of a hash function and one or more equality operations. For a few elements (say a few
dozen), it is hard to tell which is faster. For larger numbers of elements (e.g. thousands), lookup in
an unordered_map can be much faster than for a map.
See also:
 Standard: 23.5 Unordered associative containers.
std::array
The standard container array is a fixed-sized random-access sequence of elements defined
in <array>. It has no space overheads beyond what it needs to hold its elements, it does not use
free store, it can be initialized with an initializer list, it knows its size (number of elements), and
doesn’t convert to a pointer unless you explicitly ask it to. In other words, it is very much like a
built-in array without the problems.
1. array<int,6> a = { 1, 2, 3 };
2. a[3]=4;
3. int x = a[5]; // x becomes 0 because default elements are zero initialized
4. int* p1 = a; // error: std::array doesn't implicitly convert to a pointer
5. int* p2 = a.data(); // ok: get pointer to first element
Note that you can have zero-length arrays but that you cannot deduce the length of an array from
an initializer list:
1. array<int> a3 = { 1, 2, 3 }; // error: size unknown/missing
2. array<int,0> a0; // ok: no elements
3. int* p = a0.data(); // unspecified; don't try it
The standard array’s features makes it attractive for embedded systems programming (and similar
constrained, performance-critical, or safety critical tasks). It is a sequence container so it provides
the usual member types and functions (just like vector):
1. template<class C> typename C::value_type sum(const C& a)
2. {
3. return accumulate(a.begin(),a.end(),0);
4. }
5.
6. array<int,10> a10;
7. array<double,1000> a1000;
8. vector<int> v;
9. // ...
10. int x1 = sum(a10);
11. double x2 = sum(a1000);
12. int x3 = sum(v);
Also, you don’t get (potentially nasty) derived to base conversions:
1. struct Apple : Fruit { /* ... */ };
2. struct Pear : Fruit { /* ... */ };
3.
4. void nasty(array<Fruit*,10>& f)
5. {
6. f[7] = new Pear();
7. };
8.
9. array<Apple*,10> apples;
10. // ...
11. nasty(apples); // error: can't convert array<Apple*,10> to array<Fruit*,10>;
If that was allowed, apples would now contain a Pear.
See also:
 Standard: 23.3.1 Class template array
forward_list
The standard container forward_list, defined in <forward_list>, is basically a singly-linked
list. It supports forward iteration (only) and guarantees that elements don’t move if you insert or
erase one. It occupies minimal space (an empty list is likely to be one word) and does not provide
a size() operation (so that it does not have to store a size member):
1. template <ValueType T, Allocator Alloc = allocator<T> >
2. // requires NothrowDestructible<T>
3. class forward_list {
4. public:
5. // the usual container stuff
6. // no size()
7. // no reverse iteration
8. // no back() or push_back()
9. };
See also:
 Standard: 23.3.3 Class template forward_list

C++11 Standard Library Extensions —

Concurrency
Save to:
InstapaperPocketReadability
Contents of this section:

 Threads
 Mutual exclusion
 Locks
 Condition variables
 Atomics
 Futures and promises
 async
 Abandoning a process
Threads
A thread is a representation of an execution/computation in a program. In C++11, as in much
modern computing, a thread can – and usually does – share an address space with other threads. In
this, it differs from a process, which generally does not directly share data with other processes. C+
+ has had a host of threads implementations for a variety of hardware and operating systems in the
past, what’s new is a standard-library threads library.
 Many thick books and tens of thousands of papers have been written about concurrency,
parallelism, and threading, this FAQ entry barely scratches the surface. It is hard to think clearly
about concurrency. If you want to do concurrent programming, at least read a book. Do not rely just
on a manual, a standard, or a FAQ.
A thread is launched by constructing a std::thread with a function or a function object (incl.
a lambda):
1. #include <thread>
2.
3. void f();
4.
5. struct F {
6. void operator()();
7. };
8.
9. int main()
10. {
11. std::thread t1{f}; // f() executes in separate thread
12. std::thread t2{F()}; // F()() executes in separate thread
13. }
Unfortunately, this is unlikely to give any useful results – whatever f() and F() might do. The
snag is that the program may terminate before or after t1 executes f() and before or
after t2 executes F(). We need to wait for the two tasks to complete:
1. int main()
2. {
3. std::thread t1{f}; // f() executes in separate thread
4. std::thread t2{F()}; // F()() executes in separate thread
5.
6. t1.join(); // wait for t1
7. t2.join(); // wait for t2
8. }
The join()s ensure that we don’t terminate until the threads have completed. To “join” means to
wait for the thread to terminate.
Typically, we’d like to pass some arguments to the task to be executed (here we are calling
something executed by a thread a “task”). For example:
1. void f(vector<double>&);
2.
3. struct F {
4. vector<double>& v;
5. F(vector<double>& vv) :v{vv} { }
6. void operator()();
7. };
8.
9. int main()
10. {
11. std::thread t1{std::bind(f,some_vec)}; // f(some_vec) executes in separate thread
12. std::thread t2{F(some_vec)}; // F(some_vec)() executes in separate thread
13.
14. t1.join();
15. t2.join();
16. }
Basically, the standard library bind makes a function object of its arguments.
In general, we’d also like to get a result back from an executed task. With plain tasks, there is no
notion of a return value; std::future is the correct default choice for that. Alternatively, we can
pass an argument to a task telling it where to put its result: For example:
1. void f(vector<double>&, double* res); // place result in res
2.
3. struct F {
4. vector<double>& v;
5. double* res;
6. F(vector<double>& vv, double* p) :v{vv}, res{p} { }
7. void operator()(); // place result in res
8. };
9.
10. int main()
11. {
12. double res1;
13. double res2;
14.
15. std::thread t1{std::bind(f,some_vec,&res1)}; // f(some_vec,&res1) executes in separate thread
16. std::thread t2{F(some_vec,&res2)}; // F(some_vec,&res2)() executes in separate thread
17.
18. t1.join();
19. t2.join();
20.
21. std::cout << res1 << ' ' << res2 << '\n';
22. }
But what about errors? What if a task throws an exception? If a task throws an exception and
doesn’t catch it itself std::terminate() is called. That typically means that the program
finishes. We usually try rather hard to avoid that. A std::future can transmit an exception to the
parent/calling thread; that’s one reason to like futures. Otherwise, return some sort of error code.
When a thread goes out of scope the program is terminate()d unless its task has completed.
That’s obviously to be avoided.
There is no way to request a thread to terminate (i.e. request that it exit as a soon as possible and as
gracefully as possible) or to force a thread to terminate (i.e. kill it). We are left with the options of
 designing our own cooperative “interruption mechanism” (with a piece of shared data that a
caller thread can set for a called thread to check, and quickly and gracefully exit when it is set),
 “going native” by using thread::native_handle() to gain access to the operating
system’s notion of a thread,
 kill the process (std::quick_exit()),
 kill the program (std::terminate()).
This was all the committee could agree upon. In particular, representatives from POSIX were
vehemently against any form of “thread cancellation” however much C++’s model of resources rely
on destructors. There is no perfect solution for every system and every possible application.
The basic problem with threads is data races; that is, two threads running in a single address space
can independently access an object in ways that cause undefined results. If one (or both) writes to
the object and the other (or both) reads the object they have a “race” for who gets its operation(s)
done first. The results are not just undefined; they are usually completely unpredictable.
Consequently, C++11 provides some rules/guarantees for the programmer to avoid data races:
 A C++ standard library function shall not directly or indirectly access objects accessible by
threads other than the current thread unless the objects are accessed directly or indirectly via the
function’s arguments, including this.
 A C++ standard library function shall not directly or indirectly modify objects accessible by
threads other than the current thread unless the objects are accessed directly or indirectly via the
function’s nonconst arguments, including this.
  C++ standard library implementations are required to avoid data races when different
elements in the same sequence are modified concurrently.
Concurrent access to a stream object, stream buffer object, or C Library stream by multiple threads
may result in a data race unless otherwise specified. So don’t share an output stream between two
threads unless you somehow control the access to it.
You can:
 wait for a thread for a specified time
 control access to some data by mutual exclusion
 control access to some data using locks
 wait for an action of another task using a condition variable
 return a value from a thread through a future
See also:
 Standard: 30 Thread support library [thread]
 17.6.4.7 Data race avoidance [res.on.data.races]
 H. Hinnant, L. Crowl, B. Dawes, A. Williams, J. Garland, et al.: Multi-threading Library for
Standard C++ (Revision 1) N2497==08-0007
 H.-J. Boehm, L. Crowl: C++ object lifetime interactions with the threads API N2880==09-
0070.
 L. Crowl, P. Plauger, N. Stoughton: Thread Unsafe Standard Functions N2864==09-0054.
 WG14: Thread Cancellation N2455=070325.
Mutual exclusion
A mutex is a primitive object used for controlling access in a multi-threaded system. The most
basic use is:
1. std::mutex m;
2. int sh; // shared data
3. // ...
4. m.lock();
5. // manipulate shared data:
6. sh+=1;
7. m.unlock();
Only one thread at a time can be in the region of code between the lock() and
the unlock() (often called a critical region). If a second thread tries m.lock() while a first thread
is executing in that region, that second thread is blocked until the first executes the m.unlock().
This is simple. What is not simple is to use mutexes in a way that doesn’t cause serious problems:
What if a thread “forgets” to unlock()? What if a thread tries to lock() the same mutex twice?
What if a thread waits a very long time before doing an unlock()? What if a thread needs
to lock() two mutexes to do its job? The complete answers fill books. Here (and in the Locks
section) are just the raw basics.
In addition to lock(), a mutex has a try_lock() operation which can be used to try to get into
the critical region without the risk of getting blocked:
1. std::mutex m;
2. int sh; // shared data
3. // ...
4. if (m.try_lock()) {
5. // manipulate shared data:
6. sh+=1;
7. m.unlock();
8. else {
9. // maybe do something else
10. }
 A recursive_mutex is a mutex that can be acquired more than once by a thread:
1. std::recursive_mutex m;
2. int sh; // shared data
3. // ...
4. void f(int i)
5. {
6. // ...
7. m.lock();
8. // manipulate shared data:
9. sh+=1;
10. if (--i>0) f(i);
11. m.unlock();
12. // ...
13. }
Here, we have been blatant and let f() call itself. Typically, the code is more subtle. The recursive
call will be indirect along the line of f() calls g() that calls h() that calls f().
What if you need to acquire a mutex within the next ten seconds? The timed_mutex class is
offered for that. Its operations are specialized versions of try_lock() with an associated time
limit:
1. std::timed_mutex m;
2. int sh; // shared data
3. // ...
4. if (m.try_lock_for(std::chrono::seconds(10))) {
5. // manipulate shared data:
6. sh+=1;
7. m.unlock();
8. }
9. else {
10. // we didn't get the mutex; do something else
11. }
The try_lock_for() takes a relative time, a duration as its argument. If instead you want to wait
until a fixed point in time, a time_point you can use try_lock_until():
1. std::timed_mutex m;
2. int sh; // shared data
3. // ...
4. if (m.try_lock_until(midnight)) {
5. // manipulate shared data:
6. sh+=1;
7. m.unlock();
8. }
9. else {
10. // we didn't get the mutex; do something else
11. }
The midnight is a feeble joke: For a mechanism as low level as mutexes, the timescale is more
likely to be milliseconds than hours.
There is of course also a recursive_timed_mutex.
A mutex is considered a resource (as it is typically used to represent a real resource) and must be
visible to at least two threads to be useful. Consequently, it cannot be copied or moved (you
couldn’t just make another copy of a hardware input register).
It can be surprisingly difficult to get the lock()s and unlock()s to match. Think of complicated
control structures, errors, and exceptions. If you have a choice, use locks to manage your mutexes;
that will save you and your users a lot of sleep.
See also:
  Standard: 30.4 Mutual exclusion [thread.mutex]
 H. Hinnant, L. Crowl, B. Dawes, A. Williams, J. Garland, et al.: Multi-threading Library for
Standard C++ (Revision 1)
Locks
A lock is an object that can hold a reference to a mutex and may unlock() the mutex during the
lock’s destruction (such as when leaving block scope). A thread may use a lock to aid in managing
mutex ownership in an exception safe manner. In other words, a lock implements Resource
Acquisition Is Initialization for mutual exclusion. For example:
1. std::mutex m;
2. int sh; // shared data
3. // ...
4. void f()
5. {
6. // ...
7. std::unique_lock lck(m);
8. // manipulate shared data: lock will be released even if this code throws an exception
9. sh+=1;
10. }
A lock can be moved (the purpose of a lock is to represent local ownership of a non-local resource),
but not copied (which copy would own the resource/mutex?).
This straightforward picture of a lock is clouded by unique_lock having facilities to do just about
everything a mutex can, but safer. For example, we can use a unique_lock to do try_lock:
1. std::mutex m;
2. int sh; // shared data
3. // ...
4. void f()
5. {
6. // ...
7. std::unique_lock lck(m,std::defer_lock); // make a lock, but don't acquire the mutex
8. // ...
9. if (lck.try_lock()) {
10. // manipulate shared data:
11. sh+=1;
12. }
13. else {
14. // maybe do something else
15. }
16. }
Similarly, unique_lock supports try_lock_for() and try_lock_until(). What you get
from using a lock rather than the mutex directly is exception handling and protection against
forgetting to unlock(). In concurrent programming, we need all the help we can get.
What if we need two resources represented by two mutexes? The naive way is to acquire the
mutexes in order:
1. std::mutex m1;
2. std::mutex m2;
3. int sh1; // shared data
4. int sh2
5. // ...
6. void f()
7. {
8. // ...
9. std::unique_lock lck1(m1);
10. std::unique_lock lck2(m2);
11. // manipulate shared data:
12. sh1+=sh2;
13. }
This has the potentially deadly flaw that some other thread could try to acquire m1 and m2 in the
opposite order so that each had one of the locks needed to proceed and would wait forever for the
second (that’s one classic form of deadlock). With many locks in a system, that’s a real danger.
Consequently, the standard locks provide two functions for (safely) trying to acquire two or more
locks:
1. void f()
2. {
3. // ...
4. std::unique_lock lck1(m1,std::defer_lock); // make locks but don't yet try to acquire the mutexes
5. std::unique_lock lck2(m2,std::defer_lock);
6. std::unique_lock lck3(m3,std::defer_lock);
7. lock(lck1,lck2,lck3);
8. // manipulate shared data
9. }
Obviously, the implementation of lock() has to be carefully crafted to avoid deadlock. In essence,
it will do the equivalent to careful use of try_lock()s. If lock() fails to acquire all locks it will
throw an exception. Actually, lock() can take any argument with lock(), try_lock(),
and unlock() member functions (e.g. a mutex), so we can’t be specific about which
exception lock() might throw; that depends on its arguments.
If you prefer to use try_lock()s yourself, there is an equivalent to lock() to help:
1. void f()
2. {
3. // ...
4. std::unique_lock lck1(m1,std::defer_lock); // make locks but don't yet try to acquire the mutexes
5. std::unique_lock lck2(m2,std::defer_lock);
6. std::unique_lock lck3(m3,std::defer_lock);
7. int x;
8. if ((x = try_lock(lck1,lck2,lck3))==-1) { // welcome to C land
9. // manipulate shared data
10. }
11. else {
12. // x holds the index of a mutex we could not acquire
13. // e.g. if lck2.try_lock() failed x==1
14. }
15. }
See also:
 Standard: 30.4.3 Locks [thread.lock]
Condition variables
Condition variables provide synchronization primitives used to block a thread until notified by some
other thread that some condition is met or until a system time is reached.
See also:
 Standard: 30.5 Condition variables [thread.condition]
Atomics
To be written.
In the meantime, see:
  Herb Sutter: atomic<> Weapons: The C++ Memory Model and Modern Hardware, Part
1, Part 2, Slides, from C++ and Beyond, August 2012.
Futures and promises
Concurrent programming can be hard, especially if you try to be clever with threads, and locks. It is
harder still if you must use condition variables or use atomics (for lock-free programming). C++11
offers future and promise for returning a value from a task spawned on a separate thread,
and packaged_task to help launch tasks. The important point about future and promise is that
they enable a transfer of a value between two tasks without explicit use of a lock; “the system”
implements the transfer efficiently. The basic idea is simple: When a task wants to return a value to
the thread that launched it, it puts the value into a promise. Somehow, the implementation makes
that value appear in the future attached to the promise. The caller (typically the launcher of the
task) can then read the value. For added simplicity, see async().
The standard provides three kinds of futures, future for most simple uses,
and shared_future and atomic_future for some trickier cases. Here, we’ll just
present future because it’s the simplest and does all we need done. If we have
a future<X> called f, we can get() a value of type X from it:
1. X v = f.get(); // if necessary wait for the value to get computed
If the value isn’t there yet, our thread is blocked until it arrives. If the value couldn’t be computed
and the task threw an exception, calling get() will rethrow that exception to the code
calling get().
We might not want to wait for a result, so we can ask the future if a result has arrived:
1. if (f.wait_for(0)) { // there is a value to get()
2. // do something
3. }
4. else {
5. // do something else
6. }
However, the main purpose of future is to provide that simple get().
The main purpose of promise is to provide a simple set() to match future’s get(). The
names future and promise are historical; they are also a fertile source of puns.
If you have a promise and need to send a result of type X (back) to a future, there are basically two
things you can do: pass a value and pass an exception:
1. try {
2. X res;
3. // compute a value for res
4. p.set_value(res);
5. }
6. catch (...) { // oops: couldn't compute res
7. p.set_exception(std::current_exception());
8. }
So far so good, but how do I get a matching future/promise pair, one in my thread and one in
some other thread? Well, since futures and promises can be moved (not copied) around there is a
wide variety of possibilities. The most obvious idea is for whoever wants a task done to create a
thread and give the promise to it while keeping the corresponding future as the place for the result.
Using async() is the most extreme/elegant variant of the latter technique.
The packaged_task type is provided to simplify launching a thread to execute a task. In
particular, it takes care of setting up a future connected to a promise and to provides the wrapper
code to put the return value or exception from the task into the promise. For example:
1. double comp(vector<double>& v)
2. {
3. // package the tasks:
4. // (the task here is the standard accumulate() for an array of doubles):
5. packaged_task<double(double*,double*,double)> pt0{std::accumulate<double*,double*,double>};
6. packaged_task<double(double*,double*,double)> pt1{std::accumulate<double*,double*,double>};
7.
8. auto f0 = pt0.get_future(); // get hold of the futures
9. auto f1 = pt1.get_future();
10.
11. pt0(&v[0],&v[v.size()/2],0); // start the threads
12. pt1(&v[v.size()/2],&v[size()],0);
13.
14. return f0.get()+f1.get(); // get the results
15. }
See also:
 Standard: 30.6 Futures [futures]
 Anthony Williams: Moving Futures - Proposed Wording for UK comments 335, 336, 337
and 338. N2888==09-0078.
 Detlef Vollmann, Howard Hinnant, and Anthony Williams: An Asynchronous Future Value
(revised) N2627=08-0137.
 Howard E. Hinnant: Multithreading API for C++0X – A Layered Approach. N2094=06-
0164. The original proposal for a complete threading package.
async
Here is an example of a way for the programmer to rise above the messy threads-plus-lock level of
concurrent programming:
1. template<class T, class V> struct Accum { // simple accumulator function object
2. T* b;
3. T* e;
4. V val;
5. Accum(T* bb, T* ee, const V& v) : b{bb}, e{ee}, val{vv} {}
6. V operator() () { return std::accumulate(b,e,val); }
7. };
8.
9. double comp(vector<double>& v)
10. // spawn many tasks if v is large enough
11. {
12. if (v.size()<10000) return std::accumulate(v.begin(),v.end(),0.0);
13.
14. auto f0 {async(Accum{&v[0],&v[v.size()/4],0.0})};
15. auto f1 {async(Accum{&v[v.size()/4],&v[v.size()/2],0.0})};
16. auto f2 {async(Accum{&v[v.size()/2],&v[v.size()*3/4],0.0})};
17. auto f3 {async(Accum{&v[v.size()*3/4],&v[v.size()],0.0})};
18.
19. return f0.get()+f1.get()+f2.get()+f3.get();
20. }
This is a very simple-minded use of concurrency (note the “magic number”), but note the absence of
explicit threads, locks, buffers, etc. The type of the f-variables are determined by the return type of
the standard-library function async() which is a future. If necessary, get() on a future waits
for a thread to finish. Here, it is async()’s job to spawn threads as needed and the future’s job
to join() the threads appropriately. “Simple” is the most important aspect of
the async()/future design; futures can also be used with threads in general, but don’t even think
of using async() to launch tasks that do I/O, manipulate mutexes, or in other ways interact with
other tasks. The idea behind async() is the same as the idea behind the range-for statement:
 Provide a simple way to handle the simplest, rather common, case and leave the more complex
examples to the fully general mechanism.
An async() can be requested to launch in a new thread, in any thread but the caller’s, or to launch
in a different thread only if async() “thinks” that it is a good idea. The latter is the simplest from
the user’s perspective and potentially the most efficient (for simple tasks only).
The committee is actively working on providing a much more general form of executors (execution
agents) that will subsume std::async. In the meantime, std::async is the simple facility
included in the standard.
See also:
 Lawrence Crowl: An Asynchronous Call for C++. N2889 = 09-0079.
 Herb Sutter : A simple async() N2901 = 09-0091 .
Abandoning a process
To be written.
In the meantime, see:
 Lawrence Crowl: Abandoning a Process. N2440, 2007.
C++14 Overview
Save to:
InstapaperPocketReadability
Contents of this section:

 C++14: Purpose of this FAQ section

 What is C++14?
 When will compilers implement C++14?
 Where can I find the committee papers for C++14 features?
 Where else can I read about C++14?
 Are there any videos about C++14?
 Is C++14 the final C++ standard?
C++14: Purpose of this FAQ section
The purpose of this section and the language additions section and library additions section is:
 To give an overview of the new facilities (language features and standard libraries) offered
by C++14 in addition to what is provided by the previous version of the ISO C++ standard.
 To give an idea of the aims of the ISO C++ standards effort.
 To present a user’s view of the new facilities
 To provide references to allow for a more in depth study of features.
 To name many of the individuals who contributed (mostly as authors of the reports they
wrote for the committee). The standard is not written by a faceless organization.
We often borrow examples from the proposals. In those cases: Thanks to the proposal authors.
Many other examples are borrowed from Stroustrup’s talks and papers.
Please note that the purpose of this FAQ is not to provide comprehensive discussion of individual
features or a detailed explanation of how to use them. The aim is to give simple examples to
demonstrate what C++14 has to offer (plus references). Our ideal is “max one page per feature”
independently of how complex a feature is. Details can often be found in the references.

What is C++14?
 C++14 is the ISO C++ standard formally ratified by a national vote in 2014. This public working
paper is the October 2013 working draft, and contains the C++14 draft standard which is expected
to be finalized with a few more minor tweaks and editorial changes.
C++14 is a minor but important upgrade over C++11, and largely “completes C++11.”

When will compilers implement C++14?

Currently shipping compilers (e.g., GCC C++, Clang C++, IBM C++, and Microsoft C++) already
implement some or many C++14 features.
Modulo bugs, the first fully conforming C++14 language implementation is shipped by the January
2014 release of LLVM/Clang 3.4.
Here are links to C++14 information from purveyors:
 comparison
 GCC
 IBM
 Microsoft
 EDG
 Clang
Where can I find the committee papers for C++14
features?
Go to the committee papers archive and focus mainly on papers written from 2011 through early
2014. There you will most likely drown in details. Look for “issues lists” and “State of …” (e.g.,
“State of Evolution”) lists.
Where else can I read about C++14?
The amount of information about C++14 is increasing as the standard nears completion and C++
implementations start providing new language features and libraries. Here is a short list of sources:
 B. Stroustrup: The C++ Programming Language (Fourth Edition).
 B. Stroustrup: A Tour of C++.
 The committee papers archive.
Are there any videos about C++14?
Yes:
 B. Stroustrup, H. Sutter, S. Meyers, A. Alexandrescu, S.T.Lavavej, Chandler Carruth, S.
Parent, and M. Wong: Several talks and panels from the GoingNative 2013 conference.
Is C++14 the final C++ standard?
No. The committee is also working on issuing numerous Technical Specifications due in 2014
onward, on topics from low-level libraries like File System and Networking to Concurrency and
Parallelism and Concepts, and more. Many of these Technical Specifications are expected to
become part of the next major actual C++ International Standard, currently expected in about 2017.
For the latest details, see the current status page.

C++14 Language Extensions

Save to:
InstapaperPocketReadability
 Contents of this section:

 Binary literals
 Generalized return type deduction
 decltype(auto)
 Generalized lambda captures
 Generic lambdas
 Variable templates
 Extended constexpr
 The [ [deprecated] ] attribute
 Digit separators
The following are the main additions and improvements to the C++ standard language in C++14.
There are also miscellaneous smaller improvements and bug fixes besides those listed here,
including various “transparent” improvements of the “now guarantees the program does what you
would expect in a corner case you didn’t notice yet” variety.

Binary literals
C++ now supports binary literals:
1. // the answer to life, the universe, etc. in...
2. auto a1 = 42; // ... decimal
3. auto a2 = 0x2A; // ... hexadecimal
4. auto a3 = 0b101010; // ... binary
This works well in combination with the new ' digit separators, for example to separate nybbles or
bytes:
1. auto a = 0b100'0001; // ASCII 'A'
See also:
 [N3472] James Dennett: Binary Literals in the C++ Core Language.
Generalized return type deduction
C++11 permitted automatically deducing the return type of a lambda function whose body consisted
of only a single return statement:
1. // C++11
2. [=]() -> some_type { return foo() * 42; } // ok
3. [=] { return foo() * 42; } // ok, deduces "-> some_type"
This has been expanded in two ways. First, it now works even with more complex function bodies
containing more than one return statement, as long as all return statements return the same type:
1. // C++14
2. [=] { // ok, deduces "-> some_type"
3. while( something() ) {
4. if( expr ) {
5. return foo() * 42; // with arbitrary control flow
6. }
7. }
8. return bar.baz(84); // & multiple returns
9. } // (types must be the same)
Second, it now works with all functions, not just lambdas:
1. // C++11, explicitly named return type
2. some_type f() { return foo() * 42; } // ok
3. auto f() -> some_type { return foo() * 42; } // ok
4.
5. // C++14
6. auto f() { return foo() * 42; } // ok, deduces "-> some_type"
7.
8. auto g() { // ok, deduces "-> some_type"
9. while( something() ) {
10. if( expr ) {
11. return foo() * 42; // with arbitrary control flow
12. }
13. }
14. return bar.baz(84); // & multiple returns
15. } // (types must be the same)
Of course, this requires the function body to be visible.
Finally, someone will ask: “Hmm, does this work for recursive functions?” The answer is yes, as
long as a return precedes the recursive call.
See also:
 [N3638] Jason Merrill: Return type deduction for normal functions.
decltype(auto)
Given these functions:
1. string lookup1();
2. string& lookup2();
In C++11 we could write the following wrapper functions which remember to preserve the
reference-ness of the return type:
1. string look_up_a_string_1() { return lookup1(); }
2. string& look_up_a_string_2() { return lookup2(); }
In C++14, we can automate that:
1. decltype(auto) look_up_a_string_1() { return lookup1(); }
2. decltype(auto) look_up_a_string_2() { return lookup2(); }
Note: decltype(auto) is primarily useful for deducing the return type of forwarding functions
and similar wrappers, as shown above, where you want the type to exactly “track” some expression
you’re invoking. However, decltype(auto) is not intended to be a widely used feature beyond
that. In particular, although it can be used to declare local variables, doing that is probably just an
antipattern since a local variable’s reference-ness should not depend on the initialization expression.
Also, it is sensitive to how you write the return statement. These two functions have different return
types:
1. decltype(auto) look_up_a_string_1() { auto str = lookup1(); return str; }
2. decltype(auto) look_up_a_string_2() { auto str = lookup1(); return(str); }
The first returns string, the second returns string &, which is a reference to the local
variable str.
See also:
 [N3638] Jason Merrill: Return type deduction for normal functions.
Generalized lambda captures
In C++11, lambdas could not (easily) capture by move. In C++14, we have generalized lambda
capture that solves not only that problem, but allows you to define arbitrary new local variables in
the lambda object. For example:
1. auto u = make_unique<some_type>( some, parameters ); // a unique_ptr is move-only
2.
3. go.run( [ u=move(u) ] { do_something_with( u ); } ); // move the unique_ptr into the lambda
 In the above example, we kept the name of the variable u the same inside the lambda. But we’re not
limited to that… we can rename variables:
1. go.run( [ u2=move(u) ] { do_something_with( u2 ); } ); // capture as "u2"
And we can add arbitrary new state to the lambda object, because each capture creates a new type-
deduced local variable inside the lambda:
1. int x = 4;
2. int z = [&r = x, y = x+1] {
3. r += 2; // set x to 6; "R is for Renamed Ref"
4. return y+2; // return 7 to initialize z
5. }(); // invoke lambda
See also:
 [N3648] Daveed Vandevoorde, Ville Voutilainen: Wording Changes for Generalized
Lambda-capture.
Generic lambdas
Lambda function parameters can now be auto to let the compiler deduce the type. This generates a
lambda type with a templated operator() so that the same lambda object can be invoked with any
suitable type and a type-safe function with the right parameter type will be automatically generated.
In C++11, we had to explicitly state the type of a lambda parameter, which was often fine but
sometimes annoying:
1. // C++11: have to state the parameter type
2.
3. for_each( begin(v), end(v), [](decltype(*cbegin(v)) x) { cout << x; } );
4.
5. sort( begin(w), end(w), [](const shared_ptr<some_type>& a,
6. const shared_ptr<some_type>& b) { return *a<*b; } );
7.
8. auto size = [](const unordered_map<wstring, vector<string>>& m) { return m.size(); };
In C++14, we can get type deduction for the same functions we could write in C++11:
1. // C++14: just deduce the type
2.
3. for_each( begin(v), end(v), [](const auto& x) { cout << x; } );
4.
5. sort( begin(w), end(w), [](const auto& a, const auto& b) { return *a<*b; } );
On top of that, we can now express something new we couldn’t express before, namely a lambda
that will work with any suitable type and just do the right thing:
1. // C++14: new expressive power
2.
3. auto size = [](const auto& m) { return m.size(); };
Note that this new version of size is not limited to unordered_map<wstring,
vector<string>>s, but can be invoked with any type that has a .size() member function.
Furthermore, because it also implicitly deduces the return type, the return type will be
whatever m.size() returns, which can be different for different types.
See also:
 [N3559] Faisal Vali, Herb Sutter, Dave Abrahams: Proposal for Generic (Polymorphic)
Lambda Expressions.
 [N3649] Faisal Vali, Herb Sutter, Dave Abrahams: Generic (Polymorphic) Lambda
Expressions (Revision 3).
Variable templates
 In C++11, the addition of using type aliases and constexpr functions largely replaced the need
for “traits” templates. If you want to compute a type then prefer using a templated type
alias alias_t<T> instead of a traits<T>::type, and if you want to compute a value then prefer
using a value_v(); function that is constexpr instead of a traits<T>::value.
So far, so good. But it turns out that sometimes we end up creating constexpr functions only to
return a constant, and since we can templatize the function we can return the constant “cast” to the
correct type. But the function only exists because we can’t express a templated variable directly.
Enter the variable template:
1. // math constant with precision dictated by actual type
2. template<typename T> constexpr T pi = T(3.14159265358979323846);
3.
4. // Example use:
5. template<class T> T area_of_circle_with_radius(T r) { return pi<T> * r * r; }
6.
7. // Same use, in a more C++14-stylish way:
8. auto area_of_circle_with_radius = [](auto r) { return pi<decltype(r)> * r * r; };
See also:
 [N3651] Gabriel Dos Reis: Variable Templates (Revision 1).
Extended constexpr
In C++11, to make a function constexpr can mean rewriting it. For example, let’s say we have
this constexpr function:
1. constexpr int my_charcmp( char c1, char c2 ) {
2. return (c1 == c2) ? 0 : (c1 < c2) ? : -1 : 1;
3. }
That’s fine and useful for characters, so why not extend it to strings? That would require iteration
over the characters of the string, which C++11 did not allow in constexpr functions, so the C++11
version that supports strings would have to be recursive instead (and a little more complicated).
C++14 now allows more things inside the body of constexpr functions, notably:
 local variable declarations (not static or thread_local, and no uninitialized variables)
 mutating objects whose lifetime began with the constant expression evaluation
 if, switch, for, while, do-while (not goto)
So in C++14, the above function generalized to strings can stay idiomatic, and use a normal loop
directly:
1. constexpr int my_strcmp( const char* str1, const char* str2 ) {
2. int i = 0;
3. for( ; str1[i] && str2[i] && str1[i] == str2[i]; ++i )
4. {}
5. if( str1[i] == str2[i] ) return 0;
6. if( str1[i] < str2[i] ) return -1;
7. return 1;
8. }
C++14 also removes the C++11 rule that constexpr member functions are implicitly const.
See also:
 [N3652] Richard Smith: Relaxing constraints on constexpr functions.
The [ [deprecated] ] attribute
The deprecated attribute allows marking an entity deprecated, which makes it still legal to use
but puts users on notice that use is discouraged and may cause a warning message to be printed
during compilation.
 The attribute may be applied to the declaration of a class, a typedef-name, a variable, a non-static
data member, a function, an enumeration, or a template specialization.
See also:
 [N3760] Alberto Ganesh Barbati: [ [deprecated] ] attribute.
Digit separators
The single-quote character ' can now be used anywhere within a numeric literal for aesthetic
readability. It does not affect the numeric value.
1. auto million = 1'000'000;
2. auto pi = 3.14159'26535'89793;
See also:
 [N3781] Lawrence Crowl, Richard Smith, Jeff Snyder, Daveed Vandevoorde: Single-
Quotation-Mark as a Digit Separator.

C++14 Library Extensions

Save to:
InstapaperPocketReadability
Contents of this section:

 Shared locking
 User-defined literals for std:: types
 make_unique
 Type transformation _t aliases
The following are the main additions and improvements to the C++ standard library in C++14.
There are also miscellaneous smaller improvements besides those listed here, such as addressing
tuples by type (e.g., get<string>(t)) and being able to omit the type of operator functors
(e.g., greater<>(x) is okay).
Shared locking
See also:
 [N3568] Howard Hinnant: Shared locking in C++, Revision 1. This paper contains more
informational material. Note that some features were not approved for C++14.
 [N3659] Howard Hinnant: Shared locking in C++, Revision 2. This paper summarizes what
was approved for C++14.
User-defined literals for std:: types
C++11 added user-defined literals, but didn’t use them in the standard library. Now some very
useful and popular ones work:
1. auto a_string = "hello there"s; // type std::string
2. auto a_minute = 60s; // type std::chrono::duration = 60 seconds
3. auto a_day = 24h; // type std::chrono::duration = 24 hours
Note s means “string” when used on a string literal, and “seconds” when used on an integer literal,
without ambiguity.
See also:
 [N3642] Peter Sommerlad: User-defined Literals for Standard Library Types (part 1 –
version 4).
make_unique
 This fixes an omission:
1. auto p1 = make_shared<widget>(); // C++11, type is shared_ptr
2. auto p2 = make_unique<widget>(); // new in C++14, type is unique_ptr
Unlike make_shared, using make_unique doesn’t add any optimization. What it does do is
enable us to tell people “don’t write naked new any more to allocate an object on the heap” (except
only perhaps in the internals of low-level data structures).
See also:
 [N3656] Stephan T. Lavavej: make_unique (Revision 1).
Type transformation _t aliases
As part of the movement of C++ away from “traits” types, C++14 added type aliases to avoid
having to spell out typename and ::type, and actually make the traits more technically usable
because they now work in deduced contexts.
1. // C++11
2. ... typename remove_reference<T>::type ...
3. ... typename make_unsigned<T>::type ...
4.
5. // new in C++14
6. ... remove_reference_t<T> ...
7. ... make_unsigned_t<T> ...
See also:
 [N3655] Walter E. Brown: TransformationTraits Redux, v2. Note part 4 was not adopted.

Compiler Dependencies
Save to:
InstapaperPocketReadability
Contents of this section:

 Where can I download a free C++ compiler?

 Where can I get more information on using MFC and Visual C++?
 How do I display text in the status bar using MFC?
 How can I decompile an executable program back into C++ source code?
 Where can I get information about the C++ compiler from {IBM, Microsoft, Sun, etc.}?
 What’s the difference between C++ and Visual C++?
 How do compilers use “over-allocation” to remember the number of elements in an allocated
array?
 How do compilers use an “associative array” to remember the number of elements in an
allocated array?
 If name mangling was standardized, could I link code compiled with compilers from
different compiler vendors?
 GNU C++ (g++) produces big executables for tiny programs; Why?
 Is there a yacc-able C++ grammar?
 What is C++ 1.2? 2.0? 2.1? 3.0?
 Is it possible to convert C++ to C?
Where can I download a free C++ compiler?
Check these out (alphabetically by vendor-name):
 Clang (LLVM)
 Digital Mars.
  DJGPP is a port of GCC 3.2 to DOS, and includes RHIDE, a DOS-based IDE.
 Embarcadero gives away a command line compiler.
 Microsoft Visual C++ command-line compiler (version 2003).
 MinGW has a port of GCC 3.2 that runs on MS Windows.
Also check out these lists:
 www.compilers.net/Dir/Free/Compilers/CCpp.htm
 www.idiom.com/free-compilers/LANG/C++-1.html
Where can I get more information on using MFC and Visual
C++?
Here are some resources (in no particular order):
 www.visionx.com/mfcpro/
 www.mvps.org/vcfaq
 www.flounder.com/mvp_tips.htm
 msdn.microsoft.com/archive/en-us/dnarvc/html/msdn_mfcfaq50.asp
How do I display text in the status bar using MFC?
Use the following code snipped:
1. CString s = "Text";
2. CStatusBar* p =
3. (CStatusBar*)AfxGetApp()->m_pMainWnd->GetDescendantWindow(AFX_IDW_STATUS_BAR);
4. p->SetPaneText(1, s);
This works with MFC v.1.00 which hopefully means it will work with other versions as well.

How can I decompile an executable program back into C+

+ source code?
You gotta be kidding, right?
Here are a few of the many reasons this is not even remotely feasible:
 What makes you think the program was written in C++ to begin with?
 Even if you are sure it was originally written (at least partially) in C++, which one of the
gazillion C++ compilers produced it?
 Even if you know the compiler, which particular version of the compiler was used?
 Even if you know the compiler’s manufacturer and version number, what compile-time
options were used?
 Even if you know the compiler’s manufacturer and version number and compile-time
options, what third party libraries were linked-in, and what was their version?
 Even if you know all that stuff, most executables have had their debugging information
stripped out, so the resulting decompiled code will be totally unreadable.
 Even if you know everything about the compiler, manufacturer, version number, compile-
time options, third party libraries, and debugging information, the cost of writing a decompiler
that works with even one particular compiler and has even a modest success rate at generating
code would be significant — on the par with writing the compiler itself from scratch.
But the biggest question is not how you can decompile someone’s code, but why do you want to do
this? If you’re trying to reverse-engineer someone else’s code, shame on you; go find honest work.
If you’re trying to recover from losing your own source, the best suggestion I have is to make better
backups next time.
 (Don’t bother writing me email saying there are legitimate reasons for decompiling; I didn’t say
there weren’t.)

Where can I get information about the C++ compiler from

{IBM, Microsoft, Sun, etc.}?
In alphabetical order by vendor name:
 Clang (LLVM): clang.llvm.org/
 Comeau C++: www.comeaucomputing.com/
 Digital Mars (free) C++: www.digitalmars.com/
 DJ C++ (“DJGPP”): www.delorie.com/
 Edison Design Group C++: www.edg.com/cpp.html
 GNU C++ (“g++” or “GCC”): gcc.gnu.org/. Note: there are two versions precompiled for
Win32: Cygwin and minGW.
 HP C++: www.tru64unix.compaq.com/linux/compaq_cxx/index.html
 IBM VisualAge C++: www.ibm.com/software/ad/vacpp/
 Intel Reference C++: developer.intel.com/software/products/compilers/
 KAI C++: developer.intel.com/software/products/kcc/
 Metrowerks C++: metrowerks.com or www.metrowerks.com
 Microsoft Visual C++: msdn.microsoft.com/visualc/
 Open Watcom C++ (an open-source follow-up to Watcom C++): www.openwatcom.org/
 Portland Group C++: www.pgroup.com
 Silicon Graphics C++: www.sgi.com/developers/devtools/languages/c++.html
 Watcom C++: www.sybase.com/products/archivedproducts/watcomc
[If anyone has other suggestions that should go into this list, please let us know. Thanks.]
What’s the difference between C++ and Visual C++?
C++ is the language itself, Visual C++ is a compiler that tries to implement the language.
How do compilers use “over-allocation” to remember the
number of elements in an allocated array?
Recall that when you delete[] an array, the runtime system magically knows how many
destructors to run. This FAQ describes a technique used by some C++ compilers to do this (the
other common technique is to use an associative array).
If the compiler uses the “over-allocation” technique, the code for p = new Fred[n] looks
something like the following. Note that WORDSIZE is an imaginary machine-dependent constant that
is at least sizeof(size_t), possibly rounded up for any alignment constraints. On many
machines, this constant will have a value of 4 or 8. It is not a real C++ identifier that will be defined
for your compiler.
1. // Original code: Fred* p = new Fred[n];
2. char* tmp = (char*) operator new[] (WORDSIZE + n * sizeof(Fred));
3. Fred* p = (Fred*) (tmp + WORDSIZE);
4. *(size_t*)tmp = n;
5. size_t i;
6. try {
7. for (i = 0; i < n; ++i)
8. new(p + i) Fred(); // Placement new
9. }
10. catch (...) {
11. while (i-- != 0)
12. (p + i)->~Fred(); // Explicit call to the destructor
13. operator delete[] ((char*)p - WORDSIZE);
14. throw;
15. }
Then the delete[] p statement becomes:
1. // Original code: delete[] p;
2. size_t n = * (size_t*) ((char*)p - WORDSIZE);
3. while (n-- != 0)
4. (p + n)->~Fred();
5. operator delete[] ((char*)p - WORDSIZE);
Note that the address passed to operator delete[] is not the same as p.
Compared to the associative array technique, this technique is faster, but more sensitive to the
problem of programmers saying delete p rather than delete[] p. For example, if you make a
programming error by saying delete p where you should have said delete[] p, the address that
is passed to operator delete(void*) is not the address of any valid heap allocation. This will
probably corrupt the heap. Bang! You’re dead!
How do compilers use an “associative array” to remember
the number of elements in an allocated array?
Recall that when you delete[] an array, the runtime system magically knows how many
destructors to run. This FAQ describes a technique used by some C++ compilers to do this (the
other common technique is to over-allocate).
If the compiler uses the associative array technique, the code for p = new Fred[n] looks
something like this (where arrayLengthAssociation is the imaginary name of a hidden, global
associative array that maps from void* to size_t):
1. // Original code: Fred* p = new Fred[n];
2. Fred* p = (Fred*) operator new[] (n * sizeof(Fred));
3. size_t i;
4. try {
5. for (i = 0; i < n; ++i)
6. new(p + i) Fred(); // Placement new
7. }
8. catch (...) {
9. while (i-- != 0)
10. (p + i)->~Fred(); // Explicit call to the destructor
11. operator delete[] (p);
12. throw;
13. }
14. arrayLengthAssociation.insert(p, n);
Then the delete[] p statement becomes:
1. // Original code: delete[] p;
2. size_t n = arrayLengthAssociation.lookup(p);
3. while (n-- != 0)
4. (p + n)->~Fred();
5. operator delete[] (p);
Cfront uses this technique (it uses an AVL tree to implement the associative array).
Compared to the over-allocation technique, the associative array technique is slower, but less
sensitive to the problem of programmers saying delete p rather than delete[] p. For example,
if you make a programming error by saying delete p where you should have said delete[] p,
only the first Fred in the array gets destructed, but the heap may survive (unless you’ve
replaced operator delete[] with something that doesn’t simply call operator delete, or
unless the destructors for the other Fred objects were necessary).
If name mangling was standardized, could I link code
compiled with compilers from different compiler
vendors?
Short answer: Probably not.
In other words, some people would like to see name mangling standards incorporated into the
proposed C++ ANSI standards in an attempt to avoiding having to purchase different versions of
class libraries for different compiler vendors. However name mangling differences are one of the
smallest differences between implementations, even on the same platform.
Here is a partial list of other differences:
 Number and type of hidden arguments to member functions.
 is this handled specially?
 where is the return-by-value pointer passed?
 Assuming a v-table is used:
 what is its contents and layout?
 where/how is the adjustment to this made for multiple and/or virtual inheritance?
 How are classes laid out, including:
 location of base classes?
 handling of virtual base classes?
 location of v-pointers, if they are used at all?
 Calling convention for functions, including:
 where are the actual parameters placed?
 in what order are the actual parameters passed?
 how are registers saved?
 where does the return value go?
 does caller or callee pop the stack after the call?
 special rules for passing or returning structs or doubles?
 special rules for saving registers when calling leaf functions?
 How is the run-time-type-identification laid out?
 How does the runtime exception handling system know which local objects need to be
destructed during an exception throw?
GNU C++ (g++) produces big executables for tiny
programs; Why?
libg++ (the library used by g++) was probably compiled with debug info (-g). On some machines,
recompiling libg++ without debugging can save lots of disk space (approximately 1 MB; the down-
side: you’ll be unable to trace into libg++ calls). Merely strip-ping the executable doesn’t reclaim
as much as recompiling without -g followed by subsequent strip-ping the resultant a.out’s.
Use size a.out to see how big the program code and data segments really are, rather than ls -s
a.out which includes the symbol table.
Is there a yacc-able C++ grammar?
The primary yacc grammar you’ll want is from Ed Willink. Ed believes his grammar is fully
compliant with the ISO/ANSI C++ standard, however he doesn’t warrant it: “the grammar has not,”
he says, “been used in anger.” You can get the grammar without action routines or the grammar
with dummy action routines. You can also get the corresponding lexer. For those who are interested
 in how he achieves a context-free parser (by pushing all the ambiguities plus a small number of
repairs to be done later after parsing is complete), you might want to read chapter 4 of his thesis.
There is also a very old yacc grammar that doesn’t support templates, exceptions, nor namespaces;
plus it deviates from the core language in some subtle ways. You can get that grammar here or here.
What is C++ 1.2? 2.0? 2.1? 3.0?
These are not versions of the language, but rather versions of Cfront, which was the original C++
translator implemented by AT&T. It has become generally accepted to use these version numbers as
if they were versions of the language itself.
Very roughly speaking, these are the major features:
 2.0 includes multiple/virtual inheritance and pure virtual functions
 2.1 includes semi-nested classes and delete[] pointerToArray
 3.0 includes fully-nested classes, templates and i++ vs. ++i
 4.0 will include exceptions
Is it possible to convert C++ to C?
Depends on what you mean. If you mean, Is it possible to convert C++ to readable and
maintainable C-code? then sorry, the answer is No — C++ features don’t directly map to C, plus
the generated C code is not intended for humans to follow. If instead you mean, Are there compilers
which convert C++ to C for the purpose of compiling onto a platform that yet doesn’t have a C++
compiler? then you’re in luck — keep reading.
A compiler which compiles C++ to C does full syntax and semantic checking on the program, and
just happens to use C code as a way of generating object code. Such a compiler is not merely some
kind of fancy macro processor. (And please don’t email me claiming these are preprocessors — they
are not — they are full compilers.) It is possible to implement all of the features of ISO Standard C+
+ by translation to C, and except for exception handling, it typically results in object code with
efficiency comparable to that of the code generated by a conventional C++ compiler.
Here are some products that perform compilation to C (note: if you know of any other products that
do this, please let us know):
 Comeau Computing offers a compiler based on Edison Design Group’s front end that outputs
C code.
 LLVM is a downloadable compiler that emits C code. See also here and here.
 Cfront, the original implementation of C++, done by Bjarne Stroustrup and others at AT&T,
generates C code. However it has two problems: it’s been difficult to obtain a license since the
mid 90s when it started going through a maze of ownership changes, and development ceased at
that same time and so it doesn’t get bug fixes and doesn’t support any of the newer language
features (e.g., exceptions, namespaces, RTTI, member templates).
 Contrary to popular myth, as of this writing there is no version of g++ that translates C++ to
C. Such a thing seems to be doable, but I am not aware that anyone has actually done it (yet).
Note that you typically need to specify the target platform’s CPU, OS and C compiler so that the
generated C code will be specifically targeted for this platform. This means: (a) you probably can’t
take the C code generated for platform X and compile it on platform Y; and (b) it’ll be difficult to
do the translation yourself — it’ll probably be a lot cheaper/safer with one of these tools.
One more time: do not email me saying these are just preprocessors — they are not — they are
compilers.

Miscellaneous Technical Issues

Save to:
 InstapaperPocketReadability
Contents of this section:

 What is a function object?

 How do I convert a value (a number, for example) to a std::string?
 How do I convert a std::string to a number?
 Can I templatize the above functions so they work with other types?
 Why do my compiles take so long?
 What should be done with macros that contain if?
 What should be done with macros that have multiple lines?
 What should be done with macros that need to paste two tokens together?
 Why can’t the compiler find my header file in #include "c:\test.h" ?
 What are the C++ scoping rules for for loops?
 Why can’t I overload a function by its return type?
 What is “persistence”? What is a “persistent object”?
 How can I create two classes that both know about each other?
 What special considerations are needed when forward declarations are used with member
objects?
 What special considerations are needed when forward declarations are used with inline
functions?
 Why can’t I put a forward-declared class in a std::vector<>?
 Why do some people think x = ++y + y++ is bad?
 What’s the value of i++ + i++?
 What’s the deal with “sequence points”?
What is a function object?
An object that in some way behaves like a function, of course. Typically, that would mean an object
of a class that defines the application operator – operator().
A function object is a more general concept than a function because a function object can have state
that persist across several calls (like a static local variable) and can be initialized and examined from
outside the object (unlike a static local variable). For example:
1. class Sum {
2. int val;
3. public:
4. Sum(int i) :val(i) { }
5. operator int() const { return val; } // extract value
6.
7. int operator()(int i) { return val+=i; } // application
8. };
9.
10. void f(vector<int> v)
11. {
12. Sum s = 0; // initial value 0
13. s = for_each(v.begin(), v.end(), s); // gather the sum of all elements
14. cout << "the sum is " << s << "\n";
15.
16. // or even:
17. cout << "the sum is " << for_each(v.begin(), v.end(), Sum(0)) << "\n";
18. }
Note that a function object with an inline application operator inlines beautifully because there are
no pointers involved that might confuse optimizers. To contrast: current optimizers are rarely
(never?) able to inline a call through a pointer to function.
 Function objects are extensively used to provide flexibility in the standard library.

How do I convert a value (a number, for example) to

a std::string?
Call to_string.
For advanced and corner-case uses that aren’t covered by that answer, read on…
There are two easy ways to do this: you can use the <cstdio> facilities or
the <iostream> library. In general, you should prefer the <iostream> library.
The <iostream> library allows you to convert pretty much anything to a std::string using the
following syntax (the example converts a double, but you could substitute pretty much anything
that prints using the << operator):
1. // File: convert.h
2. #include <iostream>
3. #include <sstream>
4. #include <string>
5. #include <stdexcept>
6.
7. class BadConversion : public std::runtime_error {
8. public:
9. BadConversion(const std::string& s)
10. : std::runtime_error(s)
11. {}
12. };
13.
14. inline std::string stringify(double x)
15. {
16. std::ostringstream o;
17. if (!(o << x))
18. throw BadConversion("stringify(double)");
19. return o.str();
20. }
The std::ostringstream object o offers formatting facilities just like those for std::cout.
You can use manipulators and format flags to control the formatting of the result, just as you can for
other std::cout.
In this example, we insert x into o via the overloaded insertion operator, <<. This invokes the
iostream formatting facilities to convert x into a std::string. The if test makes sure the
conversion works correctly — it should always succeed for built-in/intrinsic types, but the if test is
good style.
The expression o.str() returns the std::string that contains whatever has been inserted into
stream o, in this case the string value of x.
Here’s how to use the stringify() function:
1. #include "convert.h"
2.
3. void myCode()
4. {
5. double x = /*...*/ ;
6. // ...
7. std::string s = "the value is " + stringify(x);
8. // ...
9. }

How do I convert a std::string to a number?

 Call stoi.
For advanced and corner-case uses that aren’t covered by that answer, read on…
There are two easy ways to do this: you can use the <cstdio> facilities or
the <iostream> library. In general, you should prefer the <iostream> library.
The <iostream> library allows you to convert a std::string to pretty much anything using the
following syntax (the example converts a double, but you could substitute pretty much anything
that can be read using the >> operator):
1. // File: convert.h
2. #include <iostream>
3. #include <sstream>
4. #include <string>
5. #include <stdexcept>
6.
7. class BadConversion : public std::runtime_error {
8. public:
9. BadConversion(const std::string& s)
10. : std::runtime_error(s)
11. {}
12. };
13.
14. inline double convertToDouble(const std::string& s)
15. {
16. std::istringstream i(s);
17. double x;
18. if (!(i >> x))
19. throw BadConversion("convertToDouble(\"" + s + "\")");
20. return x;
21. }
The std::istringstream object i offers formatting facilities just like those for std::cin. You
can use manipulators and format flags to control the formatting of the result, just as you can for
other std::cin.
In this example, we initialize the std::istringstream i passing the std::string s (for
example, s might be the string "123.456"), then we extract i into x via the overloaded extraction
operator, >>. This invokes the iostream formatting facilities to convert as much of the string as
possible/appropriate based on the type of x.
The if test makes sure the conversion works correctly. For example, if the string contains
characters that are inappropriate for the type of x, the if test will fail.
Here’s how to use the convertToDouble() function:
1. #include "convert.h"
2.
3. void myCode()
4. {
5. std::string s = /*...a string representation of a number...*/ ;
6. // ...
7. double x = convertToDouble(s);
8. // ...
9. }
You probably want to enhance convertToDouble() so it optionally checks that there aren’t any
left-over characters:
1. inline double convertToDouble(const std::string& s,
2. bool failIfLeftoverChars = true)
3. {
4. std::istringstream i(s);
5. double x;
6. char c;
7. if (!(i >> x) || (failIfLeftoverChars && i.get(c)))
8. throw BadConversion("convertToDouble(\"" + s + "\")");
9. return x;
10. }

Can I templatize the above functions so they work with

other types?
Yes — for any types that support iostream-style input/output.
For example, suppose you want to convert an object of class Foo to a std::string, or perhaps the
reverse: from a std::string to a Foo. You could write a whole family of conversion functions
based on the ones shown in the previous FAQs, or you could write a template function so the
compiler does the grunt work.
For example, to convert an arbitrary type T to a std::string, provided T supports syntax
like std::cout << x, you can use this:
1. // File: convert.h
2. #include <iostream>
3. #include <sstream>
4. #include <string>
5. #include <typeinfo>
6. #include <stdexcept>
7.
8. class BadConversion : public std::runtime_error {
9. public:
10. BadConversion(const std::string& s)
11. : std::runtime_error(s)
12. {}
13. };
14.
15. template<typename T>
16. inline std::string stringify(const T& x)
17. {
18. std::ostringstream o;
19. if (!(o << x))
20. throw BadConversion(std::string("stringify(")
21. + typeid(x).name() + ")");
22. return o.str();
23. }
Here’s how to use the stringify() function:
1. #include "convert.h"
2.
3. void myCode()
4. {
5. Foo x;
6. // ...
7. std::string s = "this is a Foo: " + stringify(x);
8. // ...
9. }
You can also convert from any type that supports iostream input by adding this to
file convert.h:
1. template<typename T>
2. inline void convert(const std::string& s, T& x,
3. bool failIfLeftoverChars = true)
4. {
5. std::istringstream i(s);
6. char c;
7. if (!(i >> x) || (failIfLeftoverChars && i.get(c)))
8. throw BadConversion(s);
9. }
Here’s how to use the convert() function:
1. #include "convert.h"
2.
3. void myCode()
4. {
5. std::string s = /*...a string representation of a Foo...*/ ;
6. // ...
7. Foo x;
8. convert(s, x);
9. // ...
10. // ...code that uses x...
11. }
To simplify your code, particularly for light-weight easy-to-copy types, you probably want to add a
return-by-value conversion function to file convert.h:
1. template<typename T>
2. inline T convertTo(const std::string& s,
3. bool failIfLeftoverChars = true)
4. {
5. T x;
6. convert(s, x, failIfLeftoverChars);
7. return x;
8. }
This simplifies your “usage” code some. You call it by explicitly specifying the template
parameter T:
1. #include "convert.h"
2.
3. void myCode()
4. {
5. std::string a = /*...string representation of an int...*/ ;
6. std::string b = /*...string representation of an int...*/ ;
7. // ...
8. if (convertTo<int>(a) < convertTo<int>(b))
9. /*...*/ ;
10. }

Why do my compiles take so long?

You may have a problem with your compiler. It may be old, you may have it installed wrongly, or
your computer might be an antique. I can’t help you with such problems.
However, it is more likely that the program that you are trying to compile is poorly designed, so that
compiling it involves the compiler examining hundreds of header files and tens of thousands of lines
of code. In principle, this can be avoided. If this problem is in your library vendor’s design, there
isn’t much you can do (except changing to a better library/vendor), but you can structure your own
code to minimize re-compilation after changes. Designs that do that are typically better, more
maintainable, designs because they exhibit better separation of concerns.
Consider a classical example of an object-oriented program:
1. class Shape {
2. public: // interface to users of Shapes
3. virtual void draw() const;
4. virtual void rotate(int degrees);
5. // ...
6. protected: // common data (for implementers of Shapes)
7. Point center;
8. Color col;
9. // ...
10. };
11.
12. class Circle : public Shape {
13. public:
14. void draw() const;
15. void rotate(int) { }
16. // ...
17. protected:
18. int radius;
19. // ...
20. };
21.
22. class Triangle : public Shape {
23. public:
24. void draw() const;
25. void rotate(int);
26. // ...
27. protected:
28. Point a, b, c;
29. // ...
30. };
The idea is that users manipulate shapes through Shape’s public interface, and that implementers of
derived classes (such as Circle and Triangle) share aspects of the implementation represented
by the protected members.
There are three serious problems with this apparently simple idea:
 It is not easy to define shared aspects of the implementation that are helpful to all derived
classes. For that reason, the set of protected members is likely to need changes far more often than
the public interface. For example, even though “center” is arguably a valid concept for
all Shapes, it is a nuisance to have to maintain a point “center” for a Triangle – for triangles, it
makes more sense to calculate the center if and only if someone expresses interest in it.
 The protected members are likely to depend on “implementation” details that the users
of Shapes would rather not have to depend on. For example, much (most?) code using
a Shape will be logically independent of the definition of a “color”, yet the presence of Color in
the definition of Shape will probably require compilation of header files defining the operating
system’s notion of color.
 When something in the protected part changes, users of Shape have to recompile – even
though only implementers of derived classes have access to the protected members.
Thus, the presence of “information helpful to implementers” in the base class that also acts as the
interface to users is the source of instability in the implementation, spurious recompilation of user
code (when implementation information changes), and excess inclusion of header files into user
code (because the “information helpful to implementers” needs those headers). This is sometimes
known as the “brittle base class problem.”
The obvious solution is to omit the “information helpful to implemeters” for classes that are used as
interfaces to users. That is, to make interfaces, pure interfaces. That is, to represent interfaces as
abstract classes:
1. class Shape {
2. public: // interface to users of Shapes
3. virtual void draw() const = 0;
4. virtual void rotate(int degrees) = 0;
5. virtual Point center() const = 0;
6. // ...
7.
8. // no data
9. };
10.
11. class Circle : public Shape {
12. public:
13. void draw() const;
14. void rotate(int) { }
15. Point center() const { return cent; }
16. // ...
17. protected:
18. Point cent;
19. Color col;
20. int radius;
21. // ...
22. };
23.
24. class Triangle : public Shape {
25. public:
26. void draw() const;
27. void rotate(int);
28. Point center() const;
29. // ...
30. protected:
31. Color col;
32. Point a, b, c;
33. // ...
34. };
The users are now insulated from changes to implementations of derived classes. I have seen this
technique decrease build times by orders of magnitudes.
But what if there really is some information that is common to all derived classes (or simply to
several derived classes)? Simply make that information a class and derive the implementation
classes from that also:
1. class Shape {
2. public: // interface to users of Shapes
3. virtual void draw() const = 0;
4. virtual void rotate(int degrees) = 0;
5. virtual Point center() const = 0;
6. // ...
7.
8. // no data
9. };
10.
11. struct Common {
12. Color col;
13. // ...
14. };
15.
16. class Circle : public Shape, protected Common {
17. public:
18. void draw() const;
19. void rotate(int) { }
20. Point center() const { return cent; }
21. // ...
22. protected:
23. Point cent;
24. int radius;
25. };
26.
27. class Triangle : public Shape, protected Common {
28. public:
29. void draw() const;
30. void rotate(int);
31. Point center() const;
32. // ...
33. protected:
34. Point a, b, c;
35. };

What should be done with macros that contain if?

Ideally you’ll get rid of the macro. Macros are evil in 4 different ways: evil#1, evil#2, evil#3,
and evil#4, regardless of whether they contain an if (but they’re especially evil if they contain
an if).
Nonetheless, even though macros are evil, sometimes they are the lesser of the other evils. When
that happens, read this FAQ so you know how to make them “less bad,” then hold your nose and do
what’s practical.
Here’s a naive solution:
1. #define MYMACRO(a,b) \ (Bad)
2. if (xyzzy) asdf()
This will cause big problems if someone uses that macro in an if statement:
1. if (whatever)
2. MYMACRO(foo,bar);
3. else
4. baz;
The problem is that the else baz nests with the wrong if: the compiler sees this:
1. if (whatever)
2. if (xyzzy) asdf();
3. else baz;
Obviously that’s a bug.
The easy solution is to require {...} everywhere, but there’s another solution that I prefer even if
there’s a coding standard that requires {...} everywhere (just in case someone somewhere
forgets): add a balancing else to the macro definition:
1. #define MYMACRO(a,b) \ (Good)
2. if (xyzzy) asdf(); \
3. else (void)0
(The (void)0 causes the compiler to generate an error message if you forget to put the ; after the
‘call’.)
Your usage of that macro might look like this:
1. if (whatever)
2. MYMACRO(foo,bar);
3. ↑ // This ; closes off the else (void)0 part
4. else
5. baz;
which will get expanded into a balanced set of ifs and elses:
1. if (whatever)
2. if (xyzzy)
3. asdf();
4. else
5. (void)0;
6. ↑↑↑↑↑↑↑↑ // A do-nothing statement
7. else
8. baz;
Like I said, I personally do the above even when the coding standard calls for {...} in all the ifs.
Call me paranoid, but I sleep better at night and my code has fewer bugs.
There is another approach that old-line C programmers will remember:
1. #define MYMACRO(a,b) \ (Okay)
2. do { \
3. if (xyzzy) asdf(); \
4. } while (false)
Some people prefer the do {...} while (false) approach, though if you choose to use that,
be aware that it might cause your compiler to generate less efficient code. Both approaches cause
the compiler to give you an error message if you forget the ; after MYMACRO(foo,bar).
What should be done with macros that have multiple
lines?
Avoid macros wherever possible. But yes, sometimes you need to use them anyway, and when you
do, read this to learn some safe ways to write a macro that has multiple statements.
Here’s a naive solution:
1. #define MYMACRO(a,b) \ (Bad)
2. statement1; \
3. statement2; \
4. /*...*/ \
5. statementN;
This can cause problems if someone uses the macro in a context that demands a single statement.
E.g.,
1. while (whatever)
2. MYMACRO(foo, bar);
The naive solution is to wrap the statements inside {...}, such as this:
1. #define MYMACRO(a,b) \ (Bad)
2. {\
3. statement1; \
4. statement2; \
5. /*...*/ \
6. statementN; \
7. }
But this will cause compile-time errors with things like the following:
1. if (whatever)
2. MYMACRO(foo, bar);
3. else
4. baz;
…since the compiler will see:
1. if (whatever)
2. {
3. statement1;
4. statement2;
5. // ...
6. statementN;
7. } ; else
8. ↑↑↑↑↑↑↑↑ // Compile-time error!
9. baz;
One solution is to use a do { <statements go here> } while (false) pseudo-loop. This
executes the body of the “loop” exactly once. The macro might look like this:
1. #define MYMACRO(a, b) \ (Okay)
2. do { \
3. statement1; \
4. statement2; \
5. /*...*/ \
6. statementN; \
7. } while (false)
8. ↑ // Intentionally not adding a ; here!
The ; gets added by the macro’s user, such as:
1. if (whatever)
2. MYMACRO(foo, bar);
3. ↑ // The user of MYMACRO() adds the ; here
4. else
5. baz;
After expansion, the compiler will see this:
1. if (whatever)
2. do {
3. statement1;
4. statement2;
5. // ...
6. statementN;
7. } while (false);
8. ↑ // From user's code, not from MYMACRO() itself
9. else
10. baz;
There is an unlikely but possible downside to the above approach: historically some C++ compilers
have refused to inline-expand any function containing a loop. If your C++ compiler has that
limitation, it will not inline-expand any function that uses MYMACRO(). Chances are this won’t be a
problem, either because you don’t use MYMACRO() in any inline functions, or because your
compiler (subject to all its other constraints) is willing to inline-expand functions containing loops
(provided the inline function meets all your compiler’s other requirements). However, if you are
concerned, do some tests with your compiler: examine the resulting assembly code and/or perform a
few simple timing tests.
If you have any problems with your compiler’s willingness to inline-expand functions containing
loops, you can change MYMACRO()’s definition to if (true) {…} else (void)0
1. #define MYMACRO(a, b) \
2. if (true) { \
3. statement1; \
4. statement2; \
5. /*...*/ \
6. statementN; \
7. } else
8. (void)0
9. ↑ // Intentionally not adding a ; here!
After expansion, the compiler will see a balanced set of ifs and elses):
1. if (whatever)
2. if (true) {
3. statement1;
4. statement2;
5. // ...
6. statementN;
7. } else
8. (void)0;
9. ↑↑↑↑↑↑↑ // A do-nothing statement
10. else
11. baz;
The (void)0 in the macro definition forces users to remember the ; after any usage of the macro.
If you forgot the ; like this…
1. foo();
2. MYMACRO(a, b)
3. ↑ // Whoops, forgot the ; here
4. bar();
5. baz();
…then after expansion the compiler would see this:
1. foo();
2. if (true) {
3. statement1; \
4. statement2; \
5. /*...*/ \
6. statementN; \
7. } else
8. (void)0 bar();
9. ↑↑↑↑↑ // Fortunately(!) this will produce a compile-time error-message
10. baz();
Even though the specific error message is likely to be confusing, it will at least cause the
programmer to notice that something is wrong. That’s a lot better than the alternative: without
the (void)0 in the MYMACRO() definition, the compiler would silently generate the wrong code:
the bar() call would never be called, since it would erroneously be on the
unreachable else branch of the if.
What should be done with macros that need to paste two
tokens together?
Groan. I really hate macros. Yes they’re useful sometimes, and yes I use them. But I always wash
my hands afterwards. Twice. Macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4.
Here we go again, desperately trying to make an inherently evil thing a little less evil.
First, the basic approach is use the ISO/ANSI C and ISO/ANSI C++ “token pasting” feature: ##. On
the surface this would look like the following:
Suppose you have a macro called “MYMACRO”, and suppose you’re passing a token as the
parameter of that macro, and suppose you want to concatenate that token with the token “Tmp” to
create a variable name. For example, the use of MYMACRO(Foo) would create a variable
named FooTmp and the use of MYMACRO(Bar) would create a variable named BarTmp. In this case
the naive approach would be to say this:
1. #define MYMACRO(a) \
2. /*...*/ a ## Tmp /*...*/
However you need a double layer of indirection when you use ##. Basically you need to create a
special macro for “token pasting” such as:
1. #define NAME2(a,b) NAME2_HIDDEN(a,b)
2. #define NAME2_HIDDEN(a,b) a ## b
Trust me on this — you really need to do this! (And please nobody write me saying it sometimes
works without the second layer of indirection. Try concatenating a symbol with __LINE__ and see
what happens then.)
 Then replace your use of a ## Tmp with NAME2(a,Tmp):
1. #define MYMACRO(a) \
2. /*...*/ NAME2(a,Tmp) /*...*/
And if you have a three-way concatenation to do (e.g., to paste three tokens together), you’d create
a NAME3() macro like this:
1. #define NAME3(a,b,c) NAME3_HIDDEN(a,b,c)
2. #define NAME3_HIDDEN(a,b,c) a ## b ## c

Why can’t the compiler find my header file in #include

"c:\test.h" ?
Because "\t" is a tab character.
You should use forward slashes ("/") rather than backslashes ("\") in your #include filenames,
even on operating systems that use backslashes such as DOS, Windows, OS/2, etc. For example:
1. #if 1
2. #include "/version/next/alpha/beta/test.h" // RIGHT!
3. #else
4. #include "\version\next\alpha\beta\test.h" // WRONG!
5. #endif
Note that you should use forward slashes ("/") on all your filenames, not just on
your #include files.
Note that your particular compiler might not treat a backslash within a header-name the same as it
treats a backslash within a string literal. For instance, your particular compiler might
treat #include "foo\bar\baz" as if the '\' chars were quoted. This is because header names
and string literals are different: your compiler will always parse backslashes in string literals in the
usual way, with '\t' becoming a tab character, etc., but it might not parse header names using
those same rules. In any case, you still shouldn’t use backslashes in your header names since there’s
something to lose but nothing to gain.
What are the C++ scoping rules for for loops?
Loop variables declared in the for statement proper are local to the loop body.
The following code used to be legal, but not any more, since i’s scope is now inside the for loop
only:
1. for (int i = 0; i < 10; ++i) {
2. // ...
3. if ( /* something weird */ )
4. break;
5. // ...
6. }
7.
8. if (i != 10) {
9. // We exited the loop early; handle this situation separately
10. // ...
11. }
If you’re working with some old code that uses a for loop variable after the for loop, the compiler
will (hopefully!) give you a warning or an error message such as “Variable i is not in scope”.
Unfortunately there are cases when old code will compile cleanly, but will do something different
— the wrong thing. For example, if the old code has a global variable i, the above code if (i !=
10) silently change in meaning from the for loop variable i under the old rule to the global
variable i under the current rule. This is not good. If you’re concerned, you should check with your
compiler to see if it has some option that forces it to use the old rules with your old code.
Note: You should avoid having the same variable name in nested scopes, such as a global i and a
local i. In fact, you should avoid globals altogether whenever you can. If you abided by these
 coding standards in your old code, you won’t be hurt by a lot of things, including the scoping rules
for for loop variables.
Note: If your new code might get compiled with an old compiler, you might want to
put {...} around the for loop to force even old compilers to scope the loop variable to the loop.
And please try to avoid the temptation to use macros for this. Remember: macros are evil in 4
different ways: evil#1, evil#2, evil#3, and evil#4.
Why can’t I overload a function by its return type?
If you declare both char f() and float f(), the compiler gives you an error message, since
calling simply f() would be ambiguous.
What is “persistence”? What is a “persistent object”?
A persistent object can live after the program which created it has stopped. Persistent objects can
even outlive different versions of the creating program, can outlive the disk system, the operating
system, or even the hardware on which the OS was running when they were created.
The challenge with persistent objects is to effectively store their member function code out on
secondary storage along with their data bits (and the data bits and member function code of all
member objects, and of all their member objects and base classes, etc). This is non-trivial when you
have to do it yourself. In C++, you have to do it yourself. C++/OO databases can help hide the
mechanism for all this.

How can I create two classes that both know about each
other?
Use a forward declaration.
Sometimes you must create two classes that use each other. This is called a circular dependency. For
example:
1. class Fred {
2. public:
3. Barney* foo(); // Error: Unknown symbol 'Barney'
4. };
5.
6. class Barney {
7. public:
8. Fred* bar();
9. };
The Fred class has a member function that returns a Barney*, and the Barney class has a member
function that returns a Fred*. You may inform the compiler about the existence of a class or
structure by using a “forward declaration”:
1. class Barney;
This line must appear before the declaration of class Fred. It simply informs the compiler that the
name Barney is a class, and further it is a promise to the compiler that you will eventually supply a
complete definition of that class.
What special considerations are needed when forward
declarations are used with member objects?
The order of class declarations is critical.
The compiler will give you a compile-time error if the first class contains an object (as opposed to a
pointer to an object) of the second class. For example,
1. class Fred; // Okay: forward declaration
2.
3. class Barney {
4. Fred x; // Error: The declaration of Fred is incomplete
5. };
6.
7. class Fred {
8. Barney* y;
9. };
One way to solve this problem is to reverse order of the classes so the “used” class is defined before
the class that uses it:
1. class Barney; // Okay: forward declaration
2.
3. class Fred {
4. Barney* y; // Okay: the first can point to an object of the second
5. };
6.
7. class Barney {
8. Fred x; // Okay: the second can have an object of the first
9. };
Note that it is never legal for each class to fully contain an object of the other class since that would
imply infinitely large objects. In other words, if an instance of Fred contains a Barney (as opposed
to a Barney*), and a Barney contains a Fred (as opposed to a Fred*), the compiler will give you
an error.
What special considerations are needed when forward
declarations are used with inline functions?
The order of class declarations is critical.
The compiler will give you a compile-time error if the first class contains an inline function that
invokes a member function of the second class. For example,
1. class Fred; // Okay: forward declaration
2.
3. class Barney {
4. public:
5. void method()
6. {
7. x->yabbaDabbaDo(); // Error: Fred used before it was defined
8. }
9. private:
10. Fred* x; // Okay: the first can point to an object of the second
11. };
12.
13. class Fred {
14. public:
15. void yabbaDabbaDo();
16. private:
17. Barney* y;
18. };
There are a number of ways to work around this problem. One workaround would be to
define Barney::method() with the keyword inline below the definition of class Fred (though
still within the header file). Another would be to define Barney::method() without the
keyword inline in file Barney.cpp. A third would be to use nested classes. A fourth would be to
reverse the order of the classes so the “used” class is defined before the class that uses it:
1. class Barney; // Okay: forward declaration
2.
3. class Fred {
4. public:
5. void yabbaDabbaDo();
6. private:
7. Barney* y; // Okay: the first can point to an object of the second
8. };
9.
10. class Barney {
11. public:
12. void method()
13. {
14. x->yabbaDabbaDo(); // Okay: Fred is fully defined at this point
15. }
16. private:
17. Fred* x;
18. };
Just remember this: Whenever you use forward declaration, you can use only that symbol; you may
not do anything that requires knowledge of the forward-declared class. Specifically you may not
access any members of the second class.
Why can’t I put a forward-declared class in
a std::vector<>?
Because the std::vector<> template needs to know the sizeof() its contained elements, plus
the std::vector<> probably accesses members of the contained elements (such as the copy
constructor, the destructor, etc.). For example,
1. class Fred; // Okay: forward declaration
2.
3. class Barney {
4. std::vector<Fred> x; // Error: the declaration of Fred is incomplete
5. };
6.
7. class Fred {
8. Barney* y;
9. };
One solution to this problem is to change Barney so it uses
a std::vector<> of Fred pointers (raw pointers or smart pointers such as unique_ptr or
shared_ptr) rather than a std::vector<> of Fred objects:
1. class Fred; // Okay: forward declaration
2.
3. class Barney {
4. std::vector<std::unique_ptr<Fred>> x; // Okay: Barney can use Fred pointers
5. };
6.
7. class Fred {
8. Barney* y;
9. };
Another solution to this problem is to reverse the order of the classes so Fred is defined
before Barney:
1. class Barney; // Okay: forward declaration
2.
3. class Fred {
4. Barney* y; // Okay: the first can point to an object of the second
5. };
6.
7. class Barney {
8. std::vector<Fred> x; // Okay: Fred is fully defined at this point
9. };
Just remember this: Whenever you use a class as a template parameter, the declaration of that class
must be complete and not simply forward declared.
Why do some people think x = ++y + y++ is bad?
Because it’s undefined behavior, which means the runtime system is allowed to do weird or even
bizarre things.
The C++ language says you cannot modify a variable more than once between sequence points.
Quoth the standard (section 5, paragraph 4):
Between the previous and next sequence point a scalar object shall have its stored value modified at
most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to
determine the value to be stored.

What’s the value of i++ + i++?

It’s undefined. Basically, in C and C++, if you read a variable twice in an expression where you also
write it, the result is undefined. Don’t do that. Another example is:
1. v[i] = i++;
Related example:
1. f(v[i],i++);
Here, the result is undefined because the order of evaluation of function arguments is undefined.
Having the order of evaluation undefined is claimed to yield better performing code. Compilers
could warn about such examples, which are typically subtle bugs (or potential subtle bugs). It’s
disappointing that after decades, most compilers still don’t warn, leaving that job to specialized,
separate, and underused tools.

What’s the deal with “sequence points”?

Note: The C++11 standard has expressed the same rules as below in a different way. It no longer
refers to “sequence points,” but the effects should be the same as described below.
The C++98 standard said (1.9p7):
At certain specified points in the execution sequence called sequence points, all side effects of
previous evaluations shall be complete and no side effects of subsequent evaluations shall have
taken place.
For example, if an expression contains the subexpression y++, then the variable y will be
incremented by the next sequence point. Furthermore if the expression just after the sequence point
contains the subexpression ++z, then z will not have yet been incremented at the moment the
sequence point is reached.
The “certain specified points” that are called sequence points are (section and paragraph numbers
are from the standard):
 the semicolon (1.9p16)
 the non-overloaded comma-operator (1.9p18)
 the non-overloaded || operator (1.9p18)
 the non-overloaded && operator (1.9p18)
 the ternary ?: operator (1.9p18)
  after evaluation of all a function’s parameters but before the first expression within the
function is executed (1.9p17)
 after a function’s returned object has been copied back to the caller, but before the code just
after the call has yet been evaluated (1.9p17)
 after the initialization of each base and member (12.6.2p3)

Miscellaneous Environmental Issues

Save to:
InstapaperPocketReadability
Contents of this section:

 How can I generate HTML documentation for my classes? Does C++ have anything similar
to javadoc?
 Is there a TeX or LaTeX macro that fixes the spacing on “C++”?
 Are there any pretty-printers that reformat C++ source code?
 Is there a C++-mode for GNU emacs? If so, where can I get it?
 Where can I get OS-specific questions answered (e.g., BC++, Windows, etc)?
 Why does my DOS C++ program says “Sorry: floating point code not linked”?
 Why does my BC++ Windows app crash when I’m not running the BC45 IDE?
How can I generate HTML documentation for my classes?
Does C++ have anything similar to javadoc?
Yes. Here are a few (listed alphabetically by tool name):
 ccdoc supports javadoc-like syntax with various extensions. It’s freely copiable and
customizable.
 doc++ generates HTML or TeX. Supports javadoc-like syntax with various extensions.
Open Source.
 doxygen generates HTML, LaTeX or RTF. Supports javadoc-like syntax with various
extensions. Open Source.
 PERCEPS generates HTML, TeX, RTF, man page, plain text, and anything else you’d like
(it lets you set up arbitrary output formats). It’s freely copiable.
Other documentation tools are listed at www.robertnz.net/cpp_site.html.
Is there a TeX or LaTeX macro that fixes the spacing on
“C++”?
Yes.
Here are two LaTeX macros for the word “C++”. They prevent line breaks between the “C” and “+
+”, and the first packs the two “+”s close to each other but the second does not. Try them both and
see which one you like best.
1. \newcommand{\CC}{C\nolinebreak\hspace{-.05em}\raisebox{.4ex}{\tiny\bf +}\nolinebreak\
hspace{-.10em}\raisebox{.4ex}{\tiny\bf +}}
2.
3. \def\CC{{C\nolinebreak[4]\hspace{-.05em}\raisebox{.4ex}{\tiny\bf ++}}}
Here are two more LaTeX macros for the word “C++”. They allow line breaks between the “C” and
“++”, which may not be desirable, but they’re included here just in case.
1. \def\CC{C\raise.22ex\hbox{{\footnotesize +}}\raise.22ex\hbox{\footnotesize +}}
2.
3. \def\CC{{C\hspace{-.05em}\raisebox{.4ex}{\tiny\bf ++}}}

Are there any pretty-printers that reformat C++ source

code?
In alphabetical order:
 A2PS is a Unix-based pretty-printer. It is available
from www.infres.enst.fr/~demaille/a2ps/
 Artistic Style is a reindenter and reformatter of C++, C and Java source code. It is available
from astyle.sourceforge.net/
 C++2LaTeX is a LaTeX pretty printer. It is available
from roederberg.dyndns.org/~arnold/cpp2latex
 C-Clearly by V Communications, Inc. is a Windows program that comes with standard
formatting templates and also allows you to customize your
own. www.mixsoftware.com/product/ccl.htm
 GNU indent program may help. It’s available at www.arceneaux.com/indent.html.
You can also find an “official” GNU mirror site by looking
at www.gnu.org/order/ftp.html or perhaps the original GNU
site, prep.ai.mit.edu/pub/gnu/ (e.g., if the current version is 1.9.1 you could
use prep.ai.mit.edu/pub/gnu/indent-1.9.1.tar.gz).
 “HPS Beauty” is reported to be a Windows 95/98/NT4/NT2000 utility that beautifies C/C++
source code based on rules. The interface is entirely GUI, but HPS Beauty may also be run from
the command line. It supports style files, which allow you to save and restore groups of settings.
HPS Beauty also offers an optional visual results window, that shows both the before and the after
file. Optional HTML output allows you to view source code with syntax highlighting in your
browser. www.highplains.net.
 “ProFactor StyleManager” has lots of options, and is integrated with Microsoft Visual C++.
It is a commercial product with a free 14-day trial
period. www.profactor.co.uk/products.php.
 “Source Styler for C++” has lots of bells and whistles. It is a commercial product with a free
15-day trial period. It seems to offer control over tons of different
features. www.sourcestyler.com/.
 tgrind is a Unix based pretty printer. It usually comes with the public distribution of TeX
and LaTeX in the directory "...tex82/contrib/van/tgrind". A more up-to-date version of
tgrind by Jerry Leichter can be found on: venus.ycc.yale.edu/pub in [.TGRIND]. [Note: If
anyone has an updated URL for tgrind, please let me know.]
 uncrustify from uncrustify.sourceforge.net.
Finally, you might consider lgrind which is another C++ to LaTeX translator (check for the
closest mirror site of the ctan archive). The following is a grind definition for C++ (but this one
doesn’t recognize some new keywords such as bool or wchar_t, and it doesn’t recognize a file
ending with .cpp as C++):
1. C++|c++|CC:\
2. :pb=\p\d?\(:cf:np=\)\d?;:bb={:be=}:\
3. :cb=(SLASH)*:ce=*(SLASH):ab=(SLASH)(SLASH):ae=$:sb=":se=\e":lb=':\
4. :zb=@:ze=@:tb=%%:te=%%:mb=%\$:me=\$%:vb=%\|:ve=\|%:\
5. :le=\e':tl:id=_~\::\
6. :kw=asm auto break case cdecl char continue default do double else\
7. enum extern far float for fortran goto huge if int interrupt long\
8. near pascal register return short signed sizeof static struct\
9. switch typedef union unsigned while void\
10. #define #else #endif #if #ifdef #ifndef #include #undef # define\
11. endif ifdef ifndef include undef defined #pragma\
12. class const delete friend inline new operator overload private\
13. protected public template this virtual:

Is there a C++-mode for GNU emacs? If so, where can I

get it?
Yes, there is a C++-mode for GNU emacs.
The latest and greatest version of C++-mode (and C-mode) is implemented in the file cc-mode.el.
It is an extension of Detlef and Clamen’s version. A version is included with emacs. Newer version
are available from the elisp archives.
Where can I get OS-specific questions answered (e.g., BC+
+, Windows, etc)?
See one of the following:
 MS-DOS issues: comp.os.msdos.programmer
 MS-Windows issues: comp.windows.ms.programmer
 Unix issues: comp.unix.programmer
 Borland C++ issues (e.g., OWL, BC++ compiler bugs, general C++ concepts, windows
programming):
 Using your Web browser: www.cs.rpi.edu/~wiseb/owl-list/
 To get on the mailing list: send an e-mail message with the word “SUBSCRIBE” in
the Subject: line to majordomo@netlab.cs.rpi.edu
 To get the
FAQ: ftp.netlab.cs.rpi.edu/pub/lists/owl-list-faq/drafts/owl_faq.hlp
Why does my DOS C++ program says “Sorry: floating point
code not linked”?
The compiler attempts to save space in the executable by not including the float-to-string format
conversion routines unless they are necessary, but sometimes it guesses wrong, and gives you the
above error message. You can fix this by (1) using <iostream> instead of <cstdio>, or (2) by
including the following function somewhere in your compilation (but don’t call it!):
1. static void dummyfloat(float *x) { float y; dummyfloat(&y); }
See the FAQ on stream I/O for more reasons to use <iostream> vs. <cstdio>.
Why does my BC++ Windows app crash when I’m not
running the BC45 IDE?
If you’re using BC++ for a Windows app, and it works okay as long as you have the BC45 IDE
running, but when the BC45 IDE is shut down you get an exception during the creation of a
window, then add the following line of code to the InitMainWindow() member function of your
application (YourApp::InitMainWindow()):
1. EnableBWCC(TRUE);

Miscellaneous Style Issues

Save to:
InstapaperPocketReadability
Contents of this section:

 Is int* p; right or is int *p; right?

  Which layout style is the best for my code?
 How do you name variables? Do you recommend Hungarian notation?
 Should I put const before or after the type?
 What good is static_cast?
 So, what’s wrong with using macros?
 How do you pronounce cout?
 How do you pronounce char?
Is int* p; right or is int *p; right?
Both are “right” in the sense that both are valid C and C++ and both have exactly the same meaning.
As far as the language definitions and the compilers are concerned we could just as well
say int*p; or int * p;.
The choice between int* p; and int *p; is not about right and wrong, but about style and
emphasis. C emphasized expressions; declarations were often considered little more than a
necessary evil. C++, on the other hand, has a heavy emphasis on types.
A “typical C programmer” writes int *p; and explains it as “*p is what is the int” emphasizing
syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the
style. Indeed, the * binds to the name p in the grammar.
A “typical C++ programmer” writes int* p; and explains it as “p is a pointer to an int:”
emphasizing type. Indeed the type of p is int*. A C++ mindset prefers that emphasis and sees it as
important for using the more advanced parts of C++ well.
The critical confusion comes (only) when people try to declare several pointers with a single
declaration:
1. int* p, p1; // probable error: p1 is not an int*
Placing the * closer to the name does not make this kind of error significantly less likely.
1. int *p, p1; // probable error?
Declaring one name per declaration minimizes the problem – in particular when we initialize the
variables. People are far less likely to write:
1. int* p = &i;
2. int p1 = p; // error: int initialized by int*
And if they do, the compiler will complain.
Whenever something can be done in two ways, someone will be confused. Whenever something is a
matter of taste, discussions can drag on forever. Stick to one pointer per declaration and always
initialize variables and the source of confusion disappears. See The Design and Evolution of C+
+ for a longer discussion of the C declaration syntax.
Which layout style is the best for my code?
Such style issues are a matter of personal taste. Often, opinions about code layout are strongly held,
but probably consistency matters more than any particular style. Like most people, you’ll have a
hard time constructing a solid logical argument for your preferences.
Design issues, such as the use of abstract classes for major interfaces, use of templates to present
flexible type-safe abstractions, and proper use of exceptions to represent errors, are far more
important than the choice of layout style.
How do you name variables? Do you recommend
Hungarian notation?
 There are two kinds of “Hungarian notation” – “Systems Hungarian,” the kind that encodes the type
in the variable name, is widely regarded as an antipattern. This FAQ is about that kind of
Hungarian.
Encoding a type in a variable name is a technique that can be useful in untyped languages, but is
completely unsuitable for a language that supports generic programming and object-oriented
programming – both of which emphasize selection of operations based on the type an arguments
(known to the language or to the run-time support). In this case, “building the type of an object into
names” simply complicates and minimizes abstraction. To various extent, you will have similar
problems with every scheme that embeds information about language-technical details (e.g., scope,
storage class, syntactic category) into names. Yes, in some cases, building type hints into variable
names can be helpful, but in general, and especially as software evolves, this becomes a
maintenance hazard and a serious detriment to good code. Avoid it like the plague.
If after all that you still want to risk encoding a type in a variable name anyway, be our guest: If you
do decide to play Hungarian Games, may the odds be ever in your favor.
Moving on…
So, if you shouldn’t like naming a variable after its type, what should you like and recommend?
Name a variable (function, type, whatever) based on what it is or does. Choose meaningful name;
that is, choose names that will help people understand your program. Even you will have problems
understanding what your program is supposed to do if you litter it with variables with easy-to-type
names like x1, x2, s3, and p7. Abbreviations and acronyms can confuse people, so use them
sparingly. Acronyms should be used sparingly. Consider, mtbf, TLA, myw, RTFM, and NBV. They are
obvious, but wait a few months and you will have forgotten at least one.
Short names, such as x and i, are meaningful when used conventionally; that is, x should be a local
variable or a parameter and i should be a loop index. Ain’t nothing wrong with that.
Don’t use overly long names; they are hard to type, make lines so long that they don’t fit on a
screen, and are hard to read quickly. These are probably okay:
1. partial_sum element_count stable_partition
These are probably too long:
1. the_number_of_elements remaining_free_slots_in_symbol_table
The ISO standard prefers to use underscores to separate words in an identifier
(e.g, element_count) rather than alternatives, such as elementCount and ElementCount.
Never use names with all capital letter (e.g., BEGIN_TRANSACTION) because that’s conventionally
reserved for macros. Even if you don’t use macros, someone might have littered your header files
with them. One common practice is to use an initial capital letter for types
(e.g., Square and Graph). The C++ language and standard library don’t use capital letters, so
it’s int rather than Int and string rather than String. That way, you can recognize the standard
types.
Avoid names that are easy to mistype, misread, or confuse. For example
1. name names nameS
2. foo f00
3. fl f1 fI fi
The characters 0, o, O, 1, l, and I are particularly prone to cause trouble.
Often, your choice of naming conventions is limited by local style rules. Remember that a
maintaining a consistent style is often more important than doing every little detail in the way you
think best.

Should I put const before or after the type?

 Many authors put it before, but that’s a matter of taste. const T and T const were – and are –
(both) allowed and equivalent. For example:
1. const int a = 1; // ok
2. int const b = 2; // also ok
Using the first version will likely confuse fewer programmers (“is more idiomatic”).
Note that in const pointers, const always comes after the *. For example:
1. int *const p1 = q; // constant pointer to int variable
2. int const* p2 = q; // pointer to constant int
3. const int* p3 = q; // pointer to constant int

What good is static_cast?

Casts are generally best avoided. With the exception of dynamic_cast, their use implies the
possibility of a type error or the truncation of a numeric value. Even an innocent-looking cast can
become a serious problem if, during development or maintenance, one of the types involved is
changed. For example, what does this mean:
1. x = (T)y;
We don’t know. It depends on the type T and the types of x and y. T could be the name of a class, a
type alias, or maybe a template parameter. Maybe x and y are scalar variables and (T) represents a
value conversion. Maybe x is of a class derived from y’s class and (T) is a downcast.
Maybe x and y are unrelated pointer types. Because the C-style cast (T) can be used to express
many logically different operations, the compiler has only the barest chance to catch misuses. For
the same reason, a programmer may not know exactly what a cast does. This is sometimes
considered an advantage by novice programmers and is a source of subtle errors when the novice
guessed wrong.
The “new-style casts” were introduced to give programmers a chance to state their intentions more
clearly and for the compiler to catch more errors. For example:
1. int a = 7;
2. double* p1 = (double*) &a; // ok (but a is not a double)
3. double* p2 = static_cast<double*>(&a); // error
4. double* p2 = reinterpret_cast<double*>(&a); // ok: I really mean it
5.
6. const int c = 7;
7. int* q1 = &c; // error
8. int* q2 = (int*)&c; // ok (but *q2=2; is still invalid code and may fail)
9. int* q3 = static_cast<int*>(&c); // error: static_cast doesn't cast away const
10. int* q4 = const_cast<int*>(&c); // I really mean it
The idea is that conversions allowed by static_cast are somewhat less likely to lead to errors
than those that require reinterpret_cast. In principle, it is possible to use the result of
a static_cast without casting it back to its original type, whereas you should always cast the
result of a reinterpret_cast back to its original type before using it to ensure portability.
A secondary reason for introducing the new-style cast was that C-style casts are very hard to spot in
a program. For example, you can’t conveniently search for casts using an ordinary editor or word
processor. This near-invisibility of C-style casts is especially unfortunate because they are so
potentially damaging. An ugly operation should have an ugly syntactic form. That observation was
part of the reason for choosing the syntax for the new-style casts. A further reason was for the new-
style casts to match the template notation, so that programmers can write their own casts, especially
run-time checked casts.
Maybe, because static_cast is so ugly and so relatively hard to type, you’re more likely to think
twice before using one? That would be good, because casts really are mostly avoidable in modern
C++.
 So, what’s wrong with using macros?
Macros do not obey the C++ scope and type rules. This is often the cause of subtle and not-so-subtle
problems. Consequently, C++ provides alternatives that fit better with the rest of C++, such as inline
functions, templates, and namespaces.
Consider:
1. #include "someheader.h"
2.
3. struct S {
4. int alpha;
5. int beta;
6. };
If someone (unwisely) has written a macro called alpha or a macro called beta this may not
compile or (worse) compile into something unexpected. For example, someheader.h may contain:
1. #define alpha 'a'
2. #define beta b[2]
Conventions such as having macros (and only macros) in ALLCAPS helps, but there is no language-
level protection against macros. For example, the fact that the member names were in the scope of
the struct didn’t help: Macros operate on a program as a stream of characters before the compiler
proper sees it. This, incidentally, is a major reason for C and C++ program development
environments and tools have been unsophisticated: the human and the compiler see different things.
Unfortunately, you cannot assume that other programmers consistently avoid what you consider
“really stupid”. For example, programmers have reported sightings of macros containing
a goto along with heard arguments that might – in a weak moment – appear to make sense. For
example:
1. #define prefix get_ready(); int ret__
2. #define Return(i) ret__=i; do_something(); goto exit
3. #define suffix exit: cleanup(); return ret__
4.
5. int f()
6. {
7. prefix;
8. // ...
9. Return(10);
10. // ...
11. Return(x++);
12. //...
13. suffix;
14. }
Imagine being presented with that as a maintenance programmer; “hiding” the macros in a header –
as is not uncommon – makes this kind of “magic” harder to spot.
One of the most common subtle problems is that a function-style macro doesn’t obey the rules of
function argument passing. For example:
1. #define square(x) (x*x)
2.
3. void f(double d, int i)
4. {
5. square(d); // fine
6. square(i++); // ouch: means (i++*i++)
7. square(d+1); // ouch: means (d+1*d+1); that is, (d+d+1)
8. // ...
9. }
 The “d+1” problem is solved by adding parentheses in the “call” or in the macro definition:
1. #define square(x) ((x)*(x)) /* better */
However, the problem with the (presumably unintended) double evaluation of i++ remains.
And yes, it is well known that there are things known as macros that doesn’t suffer the problems of
C/C++ preprocessor macros. However, the C++ community generally has no ambitions for
improving C++ macros. Instead, we recommend the use of facilities from the C++ language proper,
such as inline functions, templates, constructors (for initialization), destructors (for cleanup),
exceptions (for exiting contexts), etc.
How do you pronounce cout?
Many people, including Stroustrup, pronounce cout as “see-out”. The “c” stands for “character”
because iostreams map values to and from byte (char) representations.
Lots of people pronounce it as rhyming with “gout” and “spout.”

How do you pronounce char?

Many people pronounce char the same as the English verb “char” (as in, to char wood in a fire).
Others pronounce it like the English word “care,” the same as the first syllable of “character.”
But pronounce it however you like, we don’t char.

C++0x Concepts — Historical FAQs

Save to:
InstapaperPocketReadability
Contents of this section:

 What happened to C++0x “concepts”?

 What were C++0x concepts?
 What were C++0x concept maps?
 What were C++0x axioms?
What happened to C++0x “concepts”?
They were overly complex for C++0x/C++11, so were removed from that standard so that work
could continue to simplify them for a future standard. That work has been ongoing, and a radically
simplified version “Concepts Lite” will be part of the C++14 wave of deliverables as a Technical
Specification.
“Concepts” was a feature designed to allow precise specification of requirements on template
arguments. Unfortunately, the committee decided that further work on concepts could seriously
delay the C++0x/C++11 standard and voted to remove the feature from the working paper. See
Stroustrup’s note The C++0x “Remove Concepts” Decision and A DevX interview with Stroustrup
on concepts and the implications for C++0x for an explanation.
The C++0x-era concept sections are retained in this FAQ as historical information:
 C++0x concepts
 C++0x axioms (semantic assumptions)
 C++0x concept maps
What were C++0x concepts?
Note: This is a historical section. “C++0x concepts” did not make it into C++11, and a radical redesign is
in progress.
“Concepts” is a mechanism for describing requirements on types, combinations of types, and
combinations of types and integers. It is particularly useful for getting early checking of uses of
 templates. Conversely, it also helps early detection of errors in a template body. Consider the
standard library algorithm fill:
1. template<ForwardIterator Iter, class V> // types of types
2. requires Assignable<Iter::value_type,V> // relationships among argument types
3. void fill(Iter first, Iter last, const V& v); // just a declaration, not definition
4.
5.
6. fill(0, 9, 9.9); // Iter is int; error: int is not a ForwardIterator
7. // int does not have a prefix *
8. fill(&v[0], &v[9], 9.9); // Iter is int; ok: int* is a ForwardIterator
Note that we only declared fill(); we did not define it (provide its implementation). On the other
hand, we explicitly stated what fill() requires from its argument:
 The arguments first and last must be of a type that is a ForwardIterator (and they
must be of the same type).
 The third argument v must be of a type that can be assigned to
the ForwardIterator’s value_type.
We knew that, of course, having read the standard. However, compilers do not read requirement
documents, so we had to tell it in code using the concepts ForwardIterator and Assignable.
The result is that errors in the use of fill() are caught immediately at the point of use and that
error messages are greatly improved. The compiler now has the information about the programmers’
intents to allow good checking and good diagnostics.
Concepts also help template implementers. Consider:
1. template<ForwardIterator Iter, class V>
2. requires Assignable<Iter::value_type,V>
3. void fill(Iter first, Iter last, const V& v)
4. {
5. while (first!=last) {
6. *first = v;
7. first=first+1; // error: + not defined for Forward_iterator
8. // (use ++first)
9. }
10. }
This error is caught immediately, eliminating the need for much tedious testing (though of course
not all testing).
Being able to classify and distinguish different types of types, we can overload based on the kind of
types passed. For example
1. // iterator-based standard sort (with concepts):
2. template<Random_access_iterator Iter>
3. requires Comparable<Iter::value_type>
4. void sort(Iter first, Iter last); // use the usual implementation
5.
6. // container-based sort:
7. template<Container Cont>
8. requires Comparable<Cont::value_type>
9. void sort(Cont& c)
10. {
11. sort(c.begin(),c.end()); // simply call the iterator version
12. }
13.
14. void f(vector<int>& v)
15. {
16. sort(v.begin(), v.end()); // one way
17. sort(v); // another way
18. // ...
19. }
You can define your own concepts, but for starters the standard library provides a variety of useful
concepts, such as ForwardIterator, Callable, LessThanComparable, and Regular.
Note: The C++0x standard libraries were specified using concepts.
See also:
 the C++ draft 14.10 Concepts
 [N2617=08-0127] Douglas Gregor, Bjarne Stroustrup, James Widman, and Jeremy
Siek: Proposed Wording for Concepts (Revision 5) (Final proposal).
 Douglas Gregor, Jaakko Jarvi, Jeremy Siek, Bjarne Stroustrup, Gabriel Dos Reis, and
Andrew Lumsdaine: Concepts: Linguistic Support for Generic Programming in C++.
OOPSLA’06, October 2006.
What were C++0x concept maps?
Note: This is a historical section. “C++0x concepts” did not make it into C++11, and a radical redesign is
in progress.
An int* is a ForwardIterator; we said so when presenting concepts, the standard has always
said so, and even the first version of the STL used pointers as iterators. However, we also talked
about ForwardIterator’s value_type. But an int* does not have a member
called value_type; in fact, it has no members. So how can an int* be a ForwardIterator? It
is because we say it is. Using a concept_map, we say that when a T* is used where
a ForwardIterator is required, we consider the T its value_type:
1. template<Value_type T>
2. concept_map ForwardIterator<T*> { // T*'s value_type is T
3. typedef T value_type;
4. };
A concept_map allows us to say how we want to see a type, saving us from having to modify it or
to wrap it into a new a type. “Concept maps” is a very flexible and general mechanism for adapting
independently developed software for common use.
See also:
 the C++ draft 14.10.2 Concept maps
 [N2617=08-0127] Douglas Gregor, Bjarne Stroustrup, James Widman, and Jeremy
Siek: Proposed Wording for Concepts (Revision 5) (Final proposal).
 Douglas Gregor, Jaakko Jarvi, Jeremy Siek, Bjarne Stroustrup, Gabriel Dos Reis, and
Andrew Lumsdaine: Concepts: Linguistic Support for Generic Programming in C++.
OOPSLA’06, October 2006.
What were C++0x axioms?
Note: This is a historical section. “C++0x concepts” did not make it into C++11, and a radical redesign is
in progress.
An axiom is a set of predicates specifying the semantics of a concept. The primary use cases for
axioms are external tools (e.g. not the common compiler actions), such as tools for domain-specific
optimizations (languages for specifying program transformations were a significant part of the
motivation for axioms). A secondary use is simply precise specification of semantics in the standard
(as is used in many parts of the standard library specification). Axioms may also be useful for some
optimizations (done by compilers and traditional optimizers), but compilers are not required to take
notice of user-supplied axioms; they work based on the semantics defined by the standard.
An axiom lists pairs of computations that may be considered equivalent. Consider:
1. concept Semigroup<typename Op, typename T> : CopyConstructible<T> {
2. T operator()(Op, T, T);
3. axiom Associativity(Op op, T x, T y, T z) {
4. op(x, op(y, z)) <=> op(op(x, y), z); // T's operator may be assumed to be associative
5. }
6. }
7.
8. concept Monoid<typename Op, typename T> : Semigroup<Op, T> { // a monoid is a semigroup with
an identity element
9. T identity_element(Op);
10. axiom Identity(Op op, T x) {
11. op(x, identity_element(op)) <=> x;
12. op(identity_element(op), x) <=> x;
13. }
14. }
The <=> is the equivalence operator, which is used only in axioms. Note that you cannot (in
general) prove an axiom; we use axioms to state what we cannot prove, but what a programmer can
state to be an acceptable assumption. Note that both sides of an equivalence statement may be
illegal for some values, e.g. use of a NaN (not a number) for a floating-point type: if both sides of an
equivalence uses a NaN both are (obviously) invalid and equivalent (independently of what the
axiom says), but if only one side uses a NaN there may be opportunities for taking advantage of the
axiom.
An axiom is a sequence of equivalence statements (using <=>) and conditional statements (of the
form “if (something) then we may assume the following equivalence”):
1. // in concept TotalOrder:
2. axiom Transitivity(Op op, T x, T y, T z)
3. {
4. if (op(x, y) && op(y, z)) op(x, z) <=> true; // conditional equivalence
5. }
See also:
 the C++ draft 14.9.1.4 Axioms

Myths and urban legends about C++

Save to:
InstapaperPocketReadability
Contents of this section:

 Note: This section needs more material

 Why doesn’t C++ have modern compilers and tools to support things like refactoring? Why
do I have to implement a whole C++ compiler to parse C++ instead of being able to plug into an
existing implementation like I can for other languages?
 Why does C++ create useless deep copies of objects all over the place, such as returning by
value?
 What is copy elision? What is RVO?
Note: This section needs more material
This section contains initial information but needs additional FAQs. If you can supply a common
myth or misconception about C++, please hover over any FAQ title and click the icon for
“recommend an improvement.” (If you can also supply a sketch of an answer to the misconception,
that would be great but is optional.)
Why doesn’t C++ have modern compilers and tools to
support things like refactoring? Why do I have to
implement a whole C++ compiler to parse C++ instead of
being able to plug into an existing implementation like I
can for other languages?
It does, and you don’t. Use Clang – an open source and world-class C++ compiler that is designed
from the ground up to be modular, pluggable, extensible, and reusable to let you build all sorts of
C++ tools without having to write a C++ compiler first. Lots of projects are using it, and more are
picking it up every day.
Before Clang, the only open source C++ compiler was GCC/g++, and it was a closed and non-
reusable implementation by design for philosophical as well as technical reasons. This lack of
reusability was a primary reason Clang was created as an alternative and independently developed
open-source C++ compiler. Now that Clang is hot, GCC is starting to follow suit and its C++
compiler is being re-engineered and opened up to be a competitive and reusable C++
implementation that others can build on too. Competition is a great thing!
In the past, it was harder to write C++ tools because there were no open source reusable C++
parsers. Now there are. Knock yourself out!

Why does C++ create useless deep copies of objects all

over the place, such as returning by value?
C++ is a value semantic language and, by default, will copy values that are specified as parameters
or returns. Copying can be avoided by the programmer through the use of reference semantics or by
the compiler through the use of copy elision.
Modern C++ (C++11 and onward) eliminates many temporaries outright by supporting move
semantics, which allows transferring the innards of one object directly to another object without
actually performing a deep copy at all. Even better, move semantics are turned on automatically in
common cases like pass-by-value and return-by-value, without the code having to do anything
special at all. This gives you the convenience and code clarity of using value types, with the
performance of reference types.
C++ code has always been fast, but now if you take existing pre-C++11 code and just compile it
with a newer compiler that supports move semantics, you’ll likely find that your old code just runs
faster still because the compiler is able to do lightweight moves instead of deep copies for return
values and other temporary objects. This isn’t relying on smart compiler optimizations, either – the
language now guarantees moves will occur.

What is copy elision? What is RVO?

Copy elision is a compiler technique that can be used in situations where an object that is about to
be disposed of, needs to be copied. Compilers are called upon to make copies of objects that are
passed as parameters to functions or objects that are returned from functions.
In cases where the object that is being copied is about to be destroyed, for example when a functions
parameter is a temporary or when an object being returned is local to the function being called, the
compiler may elide the copy by substituting the original object instead of destroying it.
An example of copy elisions is Return Value Optimization (RVO), which may be used when a
specific local variable is returned by every return statement in a function.
Because copy constructors and destructors can have side effects, is possible for a conforming
program to detect that copy elision is taking place. Compiler transformations that are detectable by
conforming programs are not covered by the “as if” rule, so these optimizations would not be legal
except that the C++ standard specifically allows copy elision.