Top Ten Reasons To Send Your Developers to CppCon (or any C++ Conference)

Here is a list of the top business reasons to send your developers to a C++ conference.

Sending software engineers to conferences is both a time and money expense, but conferences exists because they provide value to attendees and companies that send them. Some of the value may be obvious, some may not. Here is a list of the top business reasons to send your developers to CppCon or any other C++ conference:

ISO Committee Members
  1. Education: There is a new release of C++ every three years. If you aren’t arranging C++ training on a regular basis, then your team is losing their edge. Not because they are getting worse at what they do, they aren’t, but because they are missing out on learning industry best practice. Conferences like CppCon are where the community as a whole evolves the definition of best practices in C++ and educates itself on best practices related to new standard library and language features. CppCon features pre- and post- conference classes for formal training workshops, but the entire conference is about learning better ways to use C++. The difference between regular conferences sessions and the workshops offered by CppCon and many other conferences, is that workshops usually feature hands-on exercises, which aids in both understanding and retention.
  2. Motivation: No one comes back from CppCon without being energized to write quality code and to raise the code quality bar for themselves and their team.
  3. Language Expertise: Don’t underestimate the value of language skills training. Unless you are in the tools business, the purpose of your app is not C++. The language is just a tool to express your team’s domain expertise, but don’t get trapped into thinking that all your training investment should be focused on domain expertise. For a team made up of domain experts, the ROI on further domain training may be lower than the return from having a few team members that can leverage the power of C++. Having a team member that understands the best way apply C++ to the problem at hand and able to quickly parse hard-to-understand compiler errors, may result in a better result, more quickly arrived at, than having yet another domain main expert with redundant knowledge.
  4. Recruiting: If you want C++ engineers outside your company to know you are hiring and have a great working environment, there is no substitute for sending your team members to meet them in person. Even better if they present a session that ends with a slide that says, “If you’d like to work on challenges like this with people like me, my company is hiring.” Leverage this by being a conference sponsor or exhibitor. If you hire most of your team from a particular region, supporting a conference (or local user groups) in that region will increase your recognition as a company that is engaged in the community and likely to be a good team to join.
  5. Morale: Sending a team member to an important conference like CppCon is a way of saying, “We value your contribution and we want to invest in you.” This will make anyone feel better about their job, their career, and you.
  6. Team building: If you can send your whole team, great—the shared experience will make them a better team, but that is often unrealistic. Instead, the team members that you send will share the best of what they’ve learned with formal trip reports and and informal discussions. Either way, the entire team benefits.
  7. Resources: The number of development websites and tools, both proprietary and open source, is growing every day. Is your team getting the best use of all of these? No, because no one can keep up with all the new tools and new features of existing tools. The best way to stay abreast on what new resources are available and get motivated to use them on your project is to see them demonstrated and speak with knowledgable developers. A conference like CppCon will features dozens of opportunities to learn about tools and engage with their developers and users.
  8. Skill building: Presenting technical information is an important software engineering skill that is needed by senior engineers in all companies, but growth opportunities in this area are limited in most companies. CppCon offers attendees the ability to present technical information in the main program, Open Content sessions, lightning talks, and the poster competition. Presenting at local groups and conferences an unparalleled opportunity for technical presentation skill building. CppCon offers a one-day workshop one technical presentations lead by some of the best known presenters in the C++ community.
  9. Contacts: When it comes time to find someone for contacting, training, security audits, outside code reviews, or anything that requires finding someone with rare technical skills, there is no substitute for having engaged with them personally at a technical event. Your own team can become your first and best resource for find special talent.
  10. Give Back: Your organization’s success depends upon the ecosystem of C++ compilers, tools, libraries, and shared experience to port to new hardware, adapt to industry advances, evolve standards, and developer best practices. Bring your in-house expertise and domain experience to the broader C++ community to advance the state of art for the industry and for the broader community.
conference crowd

Attending CppCon (or any C++ conference) is the one of the best ways for your team to support, engage with, and leverage the wider C++ community. For information about C++ conferences worldwide visit the Conferences Worldwide page on the Standard C++ Foundation’s wiki. For CppCon, register here:

Developing Talk Ideas

As a conference organizer, I’m always in speaker recruitment mode. Engaging presentations are the life blood of conferences and stimulate the most important part of a conference–the attendee discussion outside of scheduled sessions.

I don’t know what to talk about.

conference speakerOne comment that I hear from potential speakers is that they don’t know what to talk about. Sometimes this comes from an engineer that has never done a conference talk and sometimes from a speaker that has presented a few times covering all of the obvious (to them) topics.

If this situation applies to you: You’d like present, but feel at a loss for a topic, here is my advice:

watch videos

Start watching videos of other presenters. You know where to find them. Here is the C++Now video channel, the Meeting C++ channel, the CppCon channel, the Pacific++ channel, and, well, all of the C++ videos on YouTube.

But don’t just passively watch them. Watch them taking notes. Make a note about:

  • everything that you find interesting and want to go investigate.

If a talk touches on a feature or idea that is new to you or is used in a new way, you may want to play with it to learn more about it and see how it works in your domain.

You might come up with something that no one has every done before. Even if what you find isn’t completely new, if it was new to you, it is likely to be new to many in your audience.

  • everything that you think that you could explain better or provide better examples or use cases.

conference speakerThis is where presentation skills are so important. I can’t tell you how many times I’ve seen a talk, after which, if you’d ask me, “What new fact did you learn?” I might be hard pressed to say what was new, but I feel like I understood the topic better because of how well it was presented.

Saying the same thing that others have said, but better, is worth doing. C++ is complicated enough that, for most topics, most of us won’t absorb every detail on the first presentation.

Just repeating someone else’s talk with better examples isn’t going to be very compelling, but offering a better way of thinking about a topic and combining topics to provide better comparison or contrast, yields value to your audience.

  • everything that you disagree with.

If you feel like you have a better solution or approach than what is currently being presented as conventional wisdom, then you’ll be passionate about your presentation and passion can be the difference between a good presentation and a great one. Perhaps you have a lightning talk duel in your future.

Interested is interesting.

Look at your notes. Do you have a list of ideas that sound interesting to you? If you are interested, your audience probably is as well. Interested is interesting.

Are you seeing patterns? Perhaps you are developing a fresh perspective. If it is a point of view that make more sense to you, it is likely that your audience will appreciate your insights.

Do you have something you want to rant about? I think I’ve got five minutes in our program schedule for you.

the best way to develop C++ presentation ideas is to be engaged with the C++ community.

Hate videos? You can use this approach without watching a single video. Instead, you can listen to CppCast or read any of the many C++ blogs. Because the insight that I’m sharing is that the best way to develop presentation ideas is to be engaged with the community. The ideas that are exciting the rest of the community are going to spark something in you as well.

Good luck and I’ll see you on stage!

A Foolish Consistency

The Hobgoblin of Little Minds

Ralph Waldo EmersonRalph Waldo Emerson famously said, “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” I don’t think he was talking about code, but that statement couldn’t be more relevant to software engineers.

I’ve experienced a scenario like this a number of time in my career:

I’m sharing a new approach to writing code that offers some clear improvements to what we’ve been doing. Perhaps it is more readable, more efficient, or safer. But the response that I hear from colleagues is, “But we can’t do that here. We have <some large number> lines of code where we didn’t do it that way, so it wouldn’t be consistent.”

This is Why We Can’t Have Nice Things

I know what you’re thinking:

That can’t be right. No one would say “No” to a better way of doing something simply because they can’t improve their entire codebase all at once.

In a sense you are right. I really think that most of the time I’ve heard this response, the individual was really thinking:

I’m uncomfortable with change in general and this change in particular, but I don’t want to admit that I don’t like/understand this just because it wasn’t invented by me. If I try to argue against this change on its merits, I’ll reveal that I don’t really understand the issues and I take the chance that I won’t prevail on the merits, so I’ll play the “consistency” trump card to shutdown discussion now.

A Wise Consistency

Don’t get me wrong, I’m all for consistency. It was clearly a mistake that the member function to delete all elements of specific value from a container was called erase for all containers except list, where it was called remove. (This mistake was fixed in C++11, by adding erase to list.)

Accidental inconsistencies are, of course, foolish and unproductive. Leave gratuitous  inconsistencies for creative writing. In technical work, figure out the best way to express something and always express it the same way.

Until you learn a better way. Then embrace the improvement. This inconsistency is called growth.

Improvement is Change

The STL was a monumental intellectual achievement, but one flaw was that member predicates were improperly named. Consider the empty container member function. Is it a command to empty the container or a query about the container’s state? You know, but that is because you are already familiar with the library. Naive users must experience the confusion between empty, which is a query and clear, which is a command. There is no a priori way of knowing which is which. They could just as easily be the other way around.

The flaw is unnecessary if the policy that predicates should start with is_ had been followed. The function that is named empty should have been named is_empty and the function that is named clear should have been named empty. (It isn’t obvious that clear means “empty the container,” it could, just as easily, mean, set all element to the default constructed state.)

To be consistent, no predicate in the standard should start with is_. Fortunately the committee elected to be inconsistent when naming the predicates in <type_traits>. Improvements from previous practice are, by their very nature, inconsistent with that practice.

Being consistent means never improving. This is acceptable for people who think that their coding practice is perfect, but not for people that crave continuous improvement.

Street Signs

Imagine driving through a unfamiliar city that had mismatched street signs at every corner. It would be hard to navigate because it would be hard to pick out the street signs amid the visual noise of all the business signage and billboards. That kind of inconsistency could lead to traffic snarls and accidents and should be avoided.

But suppose a city with uniform street signs adopts a new, more readable,  standard for signs. The city might not have the budget to replace all the signs overnight. It might start replacing the signs on the busiest streets and using the new signs on newly constructed streets. Over time, less traveled streets would get new signs, but perhaps some residential streets where traffic is slow moving and there is no competing signage, might never be updated.

How hard would it be navigate a city that had two signage styles? This isn’t the challenge of a mismatched signs at every corner, it is simply dealing with the change that is inevitable with improvement.

East const

I’ve not written a post in… well, I don’t want to know… so what got me motivated to vent about hobgoblins and little minds?

Some background: Many years ago I read an article by Dan Saks which recommend placing const after what it modifies. I found the article persuasive. Notice that the rule for const placement is:

const modifies what is on its left. Unless there is nothing on its left, in which case it modifies what’s on its right.

If you consistently place const after what it modifies, the rule becomes much simpler:

const modifies what is on its left.

(I love simple, consistent rules.)

It also make declarations (which are read inside-out and right to left) easier to read. This isn’t the place to list all the arguments that Dan shared, but they convinced me. For years, I’ve followed this practice. I knew that I was in a stylistic minority, but I thought it was a better way to write code so that is what I did.

Recently, I’ve noticed that more and more C++ programmers are starting to adopt this style. In fact, a few months ago, I learned that it had a catchy name: East const.

What prompted this posting was a tweet with a link to this core guideline: NL.26: Use conventional const notation. You can read it yourself, but it essentially says, don’t use East const. The guideline concedes that East const is more logical, but since it is less common, it is forbidden.

As I said, I’ve known for years that I was in the minority and I’m okay with it if you say:

This is how we wrote code back in the Eighties and we liked it!

But to condemn a more logical approach because of inconsistency? Well, you know what Ralph Waldo Emerson said about it.

It really gets me that after invoking consistency, the guidelines authors hide behind novices. They are in effect saying, we need to compromise the quality of our code instead of improving our training materials.

What puzzles me is the enforcement:

Flag const used as a suffix for a type.

How is one supposed to declare an immutable pointer that references a mutable int? I might do it like this:

int * const p;

But the type of p ends in const. Perhaps there is another way to declare it that doesn’t have a const suffix. If so you won’t see it in this core guideline because one of its “OK” examples also ends in const. Or perhaps the enforcement engine will just have a complicated rule.

I don’t like complicated rules, but some people seem to like them for const.

If you’d like to share your thoughts, please comment on the reddit post. (I’m well aware that this is a rant, but please keep comments constructive and professional. Thanks.)

Undefined Behavior and CERT’s Vulnerability Note

There were a lot of interesting comments to last week’s post on Apple’s secure coding guide and I plan to follow up on those in future posts, but I first wanted to make a comment of my own on the  vulnerability note from that was referenced by Apple’s document and by my post.

CERT’s vulnerability note

The vulnerability note’s overview states:


Undefined behavior











Some Undefined Behaviors are More Equal Than Others






Please post comments on Google Plus.

Undefined Behavior and Apple’s Secure Coding Guide



size_t bytes = n * m;
    ... /* allocate "bytes" space */






size_t bytes = n * m;
    ... /* allocate "bytes" space */

I have to say I’m a little surprised by  this!





So what is the solution to a situation like this?


else {
    /* handle the overflow case */



Shout out to Microsoft MVP Bruce for pointing out this issue.

Please post comments on Google Plus.


What is a User-Defined Type?








Consider this from [namespace.std]:



namespace std
    template <>

This is okay because:

  • swap is Standard Library template and
  • my_type is a user-defined type.


namespace std
    template <>


namespace std
    template <>



  • common_type in Table 57 of [meta.trans.other],
  • is_error_code_enum and is_error_condition_enum of [syserr].





Let me know what you think.

C++ Amusements

By the time you read this, I’ll probably be “under the knife” or recovering from same.

The surgeon is predicting a couple of rather uncomfortable days followed by over two weeks of taking it easy. I won’t be able to operate heavy machinery so it’s fortunate that my main development machine is a laptop. I should have several days of naps being broken up by sessions on the computer. Which brings me to the point of this blog.

What are your C++ time killers amusements?

logo-sun-1I go to the C++ Standard Foundation’s website at least once a day to see the latest in the C++ world. Hi Herb, Eric, Marshall… (Rumor has it that there is a lot more content coming to that site. Keep an eye on it.) In addition to news about C++ events and postings, it has some recent StackOverflow questions. If one of those looks interesting I may be sucked in to look at few questions and there goes an hour.

C++NowOf course if I know I have an hour or so, I may look for an interesting online video. There are some great sessions recorded at C++Now and GoingNative. Channel 9 sometimes has a C++ and Beyond session. The recording quality is better for the Channel 9 videos, but the BoostCon videos cover a wide range of topics and have a lot of content.

If you didn’t get enough questions on StackOverflow, try out the just launched C++ Quiz. Hi Anders. By the way here is my C++ trivia question (apologies to those that already saw this on twitter):

Q) what is the name of the only std::exception member function to return a pointer
A) true

If you didn’t get enough interesting links on, spend a few minutes on twitter searching for #cpp or #cpp11 (or even #cpp14). You’ll likely find something worthing reading and several people worth following. Hi James, Kate, Jens, Andrey, Eric, Marshall, Anna-Jayne, Dean, Anders, Diego


If twitter isn’t your thing, look at the C++ sub reddit. Hi STL. Just about everything of interest to C++ programmers will get posted there. But there is a bit of noise mixed with the signal. For a purer experience stick with established C++ blogs like the ones I’ve listed on my blog roll at the right. Hi everybody.

You might not expect good technical conversations on a social network, but Google+ is pretty good. Why not drop by and let me know what ideas you have for how I can spend my time while I’m recuperating.

Capacity Members for vector – shrink_to_fit()

shrunkC++11 introduced a new member function called shrink_to_fit() for the three sequence containers vector, deque, and string. Before shrink_to_fit() there was no member to reduce capacity on these containers, not even erase(). In fact, the standard made it very unlikely that any implementation would reduce capacity with any call. The standard provides the guarantee that if reserve() is called, then any subsequence addition to the container will not invalidate iterators (until an addition increases the size of the container above the reserve() point.

Since this guarantee is not relaxed even if the user calls erase(), a implementation that chose to reduce capacity would be required to track whether or not reserve had previously been called. It would be theoretically possible for an implementation to add this extra state to the container implementation, but in practice no implementation is going to do that.

Perhaps this lack of attention to minimizing capacity isn’t surprising. In most modern code, our concern is usually time performance rather than space requirements. But C++ is the language of choice for demanding situations and sometimes this means minimizing space requirements.

Scott Meyers
Scott Meyers

So what can users do if they want to reduce the capacity of a container? Is this not possible? It turns out that it is possible. In Item 17 of Scott Meyer’s Effective STL, Scott explains that there is a “Swap Trick” that we can use to reduce capacity.

Here is the quick synopsis of the Swap trick:

Container(begin(c), end(c)).swap(c);

where “c” is a container whose capacity we want to reduce and Container is it’s type.

What is happening is that we are creating a temporary container as a copy of our original container using the iterator range constructor and then swapping the contents of the our temporary container with our original container. This works because most implementations will implement the iterator range constructor to not make the capacity any larger than necessary. The reserve() guarantee is swapped to the other container with the call to swap().

In practice we’d almost certainly want to write this something like this:

if (c.capacity() > c.size())


if (c.capacity() > (c.size() + some_value))

Because this trick involves copying all the items in the container, we don’t want to do it unless it saves enough space to be worthwhile. (In C++11 we could use moves instead of copies. This would make the technique less expensive, but we really only want to do this if the moves are no_except. This is a beyond the scope of what I want to discuss in this post.)

Meyers’ Swap Trick was state of the art, at least until C++11 where we can now do this:

if (c.capacity() > c.size())

assuming type of c is vector, deque, or string. For vector and string the standard says “… request to reduce capacity() to size().” (We’ll consider the ellipse shortly.) For deque the standard says “… request to reduce memory use.”

Why is deque’s description different than vector and string? Because deque doesn’t have a capacity() member function. The point of the capacity member function is tell us how much we can grow the number of items in the container before an addition would invalidate iterators. This concept doesn’t make much sense for deque, so there is no such call as deque::capacity().

So let’s look at what I left out just now when I quoted the standard. What it really says for vector and string is “shrink_to_fit is a non-binding request to reduce capacity() to size().” The emphasis is mine. The standard has made shrink_to_fit() non-binding. (Also true for deque.) It can be implemented as a no-op!

Why would the committee do such a thing? The standard gives an answer: “[Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ]” What this means is that the committee knows that there are implementations where doing the right thing might not result in size() == capacity().

Consider the “short string” optimization. A string is an allocated array and a straight-forward implementation would allocation an array even for a string that was only one character long. One character long strings are not particularly common, but short strings are. So an library might choose to implement the string class so that the class itself has (data member) space for “short” strings so that no allocation is necessary until the size of the string is no longer “short” for some value of “short.” Given this implementation how would capacity() be implemented? In particular would capacity() ever return a value less than the “short” string limit? No because we can always expand the string to the “short” string limit without invalidating iterators (assuming the current size() is less than this limit).

This means that if we currently have a string whose size() is less than the “short” string limit, a “request to reduce capacity() to size()” is going to fail. So the standard doesn’t want to say that the implementation must reduce capacity() to size().

But in my opinion the committee has let us down. While I’m all for giving implementers latitude for their implementations, I think the committee has underspecified this call. It is acceptable to say that the implementation need not reduce capacity() all the way to size(), but it should say that it will reduce capacity at least as far as the Swap Trick would have.

Since the Swap Trick is potentially expensive in time, it is likely only used in situations where users are very serious about reducing excess capacity. Given this, and faced with the fact that shrink_to_fit() may be a no-op, I think conscientious coders will choose to skip the new shrink_to_fit() and continue to use the Swap Trick.

And that is a shame. With shrink_to_fit() the user is very explicitly stating the desired outcome, so this has the potential to allow implementers to exploit interesting optimizations. This should be better than the somewhat obscure looking Swap Trick. But clarity and interesting optimizations aren’t of much use if users don’t use the new call. And they may avoid it because the old way gives them guarantees that the committee didn’t see fit to apply to the new call.

Please comment on Google Plus or reddit.

Capacity Members for vector – reserve()

I want to talk about a couple of the lesser known member functions of the best known STL container: reserve() and shrink_to_fit(). These members manipulate the vector’s capacity. The reserve() member is original and I discuss it in this post. New with C++11 is shrink_to_fit(). I’ll talk about it in a future post.

Note: The use of kittens in explaining C++ is patented by STL. This image used without permission.
The vector class stores data in an allocated array whose allocation the class handles for us. Each call to push_back() does a check to see if the array has space for the new item. If not, the class must perform a reallocation. This involves allocating a larger array and copying all existing items into the new array before destroying the originals in the old array and releasing the old array. This is expensive, but the cost is amortized so that order of push_back() is amortized constant time.

How can it be constant time when copying all existing items will take time proportional to the number of existing items? The trick is that when push_back() triggers a reallocation, the new array is not a constant size increase of the existing array, but is proportional to the existing array (e.g. doubling in size). This approach means that although each reallocation is more expensive (due the increased number of exiting items), the allocations end up being required exponentially less often. The result works out to average (or amortized) constant time.

This is a great way to deal with allocations when we don’t know how many items we will need the vector to hold. But what if we do know how many items will be required? Suppose we know in advance that our vector will need to hold a thousand items. If vector initially allocates enough space for eight items and allocates an array twice as large as the existing one with each reallocation, we’ll need seven reallocations (and copies of all existing items) before we are finished adding our thousand items. This may be optimal if we have no idea how many items we’ll need to handle, but it is wasteful if we know in advance that we will need to hold a thousand items. We’d like a way to tell vector upfront that we need to hold a thousand items so it can create this space with one allocation and avoid needlessly copying items.

One way to do this to pre-fill our vector. If we are working with a vector of ints we can do something like this:

#include <iostream>
#include <vector>

using Ints = std::vector<int>;
// some how we know the upper bound of our storage requirement
const int vector_limit(1000);

int main()
    Ints v(vector_limit); // pre-fill a thousand ints

    std::cout << v.capacity() << std::endl;
some value >= 1000, likely 1000

The drawback to this approach is that we’ve not just changed the vector’s capacity, but its content as well. If we know we need to store a thousand ints, pre-filling the vector may not be a problem, but consider some other cases. Suppose we know only the upper bound of the number of items, but not the exact number and the item type has an expensive constructor. Or no default constructor. In these cases, pre-filling the vector is problematic.

What we need is a way to increase a vector’s capacity without changing it’s size.

Enter reserve(). reserve() takes a parameter that tells the vector class how many items we expect to hold. In our example we can call reserve() with the value one thousand before pushing back any items. This would trigger a single allocation and since we haven’t added any items to the vector, there are no existing items that need to be copied. Big win.

#include <iostream>
#include <vector>

using Ints = std::vector<int>;
const int vector_limit(1000);

int main()
    Ints v; // creates an empty vector

    v.reserve(vector_limit); // increase capacity only

some value >= 1000, likely 1000

One of the reasons that I wanted to discuss reserve() is because of a discussion I had with some very experienced and knowledgable C++ programmers. I was surprised to learn that they believed that reserve() is only an optimization-enabling hint to the library and that the library has the option of implementing it as a no-op. This is wrong on two counts. The standard does not allow reserve() to be a no-op (unless the passed values is already less than or equal to the vector’s current capacity).

Further, the standard guarantees that adding items to the vector up to the reserve() limit, will not only not cause a reallocation, but that iterators will not be invalidated. This is not just an optimization, but is an important guarantee because in general, we always assume that push_back() and insert() will invalidate iterators. (You can verify that these calls will not invalidate iterators for a specific call by checking the current capacity before the call.)

Because of this guarantee we can be confident that iterators (and references and pointers) are not invalidated as long as don’t increase the size of our vector beyond our reserve.

#include <cassert>
#include <iostream>
#include <vector>

using Ints = std::vector<int>;
const int vector_limit(1000);

int main()
    Ints v; // creates an empty vector

    v.reserve(vector_limit); // increase capacity only

    // add a single element and remember its address
    const int* start_of_allocated_array(&v[0]);

    // fill the vector to our limit
    for (int i(1); i < vector_limit; ++i) v.push_back(i);

    // verify no invalidation of iterators, pointers, or references
    assert(start_of_allocated_array == &v[0]);

What if we want to maintain stable access to items in the face of iterator invalidation (where we are adding items beyond the vector's capacity)? The trick is to use index values instead of iterators, pointers, or references. The Nth item in the vector will still be the Nth items after a reallocation.

The other reason I wanted to discuss reserve() is because of a nasty performance bug that some of my co-workers found within the last few days. Proper use of reserve() can be a nice performance win, but there is a gotcha scenario. In the bug, the code was calculating how many items needed to be added to the vector and then calling reserve() before adding them. This seems like a good use, until you realize that this code is being called in a loop. So what is happening is, each time through the loop we find that we need to add a few more items so we call reserve() which has the result of copying all existing items. What leads to this result is one of the characteristic of reserve() that isn't mandated by the standard, but it is usually the way that it is implemented. Let me explain.

As I said before, when a reallocation happens, the new size of the array is some proportion, usually double, of the old size of the array. The standard doesn't mandate any particular ratio. It also doesn't provide an upper limit on the capacity after a call to reserve(). An implementation is free to allocate an array double the value of the reserve() parameter. But that isn't what users would usually want or what most implementations provide. Usually reserve() will create a capacity exactly equal to the value passed. The passed value is a very good hint about the upper bound of the vector's size, and implementations take advantage of this hint.

Consider the implication of this on our performance bug. Without the call to reserve(), the push_back() in the loop would have added items with amortized constant time. But by calling reserve() in the loop, each reserve() resulted in copying every item in the vector every time through the loop and also pinning the capacity to exactly the reserve() value rather than a proportionally larger value, with disastrous performance consequences.

reserve() is a great tool for optimizing vector performance, but keep in mind the optimal use case for it. We want to call reserve() once when we can determine the upper bound on the vector's size requirement before we have added any values to the vector. There are many cases were we can't predict the size requirement upper bound, so we can't implement this optimal strategy and we may have to modify it. But calling reserve() several times with increasing estimates of the required capacity is not a strategy likely to yield success.

Please comment on Google Plus or reddit.

Tutorials for C++Now





Scott Schurr
Scott Schurr



  • “Fixed Size Arrays.”
  • Topics that don’t focus on a specific feature.  The Meeting C++ conference ( has several such topics this year:
    • Simpler C++ code through C++11
    • Generic Programming for the rest of us
    • Efficient Team Development for C++ Projects
    • C++ Timeline
    • Goals for C++11
    • The Simpler Core Language Features
      • auto, decltype, trailing return types
      • nullptr
      • Range for
      • >> in template specializations
      • static_assert
      • noexcept
      • extern template
      • constexpr
    • Generated functions: default / delete
    • Override control: override / final
    • Delegating constructors
    • Inheriting constructors
    • Increased flexibility for in-class initializers
    • Explicit conversion operators
    • Initialization
      • Initializer lists
      • Uniform initialization
      • Prevention of narrowing
    • Lambdas
    • Rvalue references, move semantics, perfect forwarding:
      • lvalues and rvalues (the modern view)
      • “move” semantics
      • Universal references
      • Perfect forwarding
  • “C++11/14 Overview: Concurrency”
    • Threads
    • Passing arguments to threads
    • Data lifetime considerations
    • Synchronization with mutexes and locking
    • Returning values from threads using async() and futures
    • Condition variables
    • Thread-local storage
    • Atomics

Please comment on Google Plus or reddit.