Home » Blog » Categories » Articles & Books

Articles & Books

Using constexpr to Improve Security, Performance and Encapsulation in C++ -- Danny Kalev

By Blog Staff | Dec 28, 2012 01:33 PM | Tags: intermediate

How is constexpr different from const, and how does it contribute to making modern C++ code cleaner and simpler, as well as faster than ever? Danny Kalev gives a nice summary:

Using constexpr to Improve Security, Performance and Encapsulation in C++

by Danny Kalev

constexpr is a new C++11 keyword that rids you of the need to create macros and hardcoded literals. It also guarantees, under certain conditions, that objects undergo static initialization. Danny Kalev shows how to embed constexpr in C++ applications to define constant expressions that might not be so constant otherwise.

Continue reading...

Quick Q: A unique_ptr is not copyable, so why can I return one by value? -- StackOverflow

By Blog Staff | Dec 27, 2012 05:16 PM | Tags: basics

 

A common question for programmers new to C++11 and its new features: "Hey, look how easy this was! ... But, um, why and how did it work?"

Returning unique_ptr from functions

unique_ptr<T> does not allow copy construction, instead it supports move semantics. Yet, I can return a unique_ptr<T> from a function and assign the returned value to a variable.

#include <iostream>
#include <memory>
using namespace std;

unique_ptr<int> foo()
{
  unique_ptr<int> p( new int(10) );
  return p;                   // 1
  //return move( p );         // 2
}

int main()
{
  unique_ptr<int> p = foo();
  cout << *p << endl;
  return 0;
}

The code above compiles and works as intended. So how is it that line 1 doesn't invoke the copy constructor and result in compiler errors? If I had to use line 2 instead it'd make sense (using line 2 works as well, but we're not required to do so).

I know C++0x allows this exception to unique_ptr since the return value is a temporary object that will be destroyed as soon as the function exits, thus guaranteeing the uniqueness of the returned pointer. I'm curious about how this is implemented, is it special cased in the compiler or is there some other clause in the language specification that this exploits?

Continue reading...

C++11: A cheat sheet -- Alex Sinyakov

By Blog Staff | Dec 26, 2012 10:40 AM | Tags: basics

Want a quick "cheat sheet" overview of what's new in C++11? Alex Sinyakov recently gave a presentation on this topic and has posted slides that are useful as a capsule summary in flash card form:

C++11 (PDF slides)

Alex Sinyakov, AMC Bridge LLC

Slide after slide shows C++11 code side by side with the same code written in older C++ style or in other languages. You'll quickly notice a pattern: In example after example, C++11 code is clean, safe, and as fast as ever... and sometimes even faster.

As Bjarne Stroustrup puts it: "Surprisingly, C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever."

Enjoy these great quick study notes as a refresher before your next C++11 interview.

For a detailed treatment of what’s new in C++11, see Overview of the New C++ (C++11) by Scott Meyers, featured on our Get Started! page. These are Scott’s fully-annotated color training materials from his course of the same name, and the best current approximation of “a book on what’s new in C++11.” (Free sample available.)

Best of 2012: auto

By Blog Staff | Dec 26, 2012 09:31 AM | Tags: basics

Perhaps the most common single question about C++11 is: When should we use auto to declare local variables?

Here's a current set of responses on Programmers.StackExchange. Enjoy.

Does auto make C++ code harder to understand?

I saw a conference by Herb Sutter where he encourages every C++ programmer to use auto.

I had to read C# code some time ago where var was extensively used and the code was very hard to understand -- every time var was used I had to check the return type of the right side. Sometimes more than once, because I forgot the type of the variable after a while!

I know the compiler knows the type and I don’t have to write it, but it is widely accepted that we should write code for programmers, not for compilers.

I also know that is more easy to write:

auto x = GetX();

Than:

 

someWeirdTemplate<someOtherVeryLongNameType, ...>::someOtherLongType x = GetX();

But this is written only once and the GetX() return type is checked many times to understand what type x has.

This made me wonder -- does auto make C++ code harder to understand?

Continue reading...

Quick Q: Inserting a variadic argument list into a vector? -- StackOverflow

By Blog Staff | Dec 24, 2012 05:40 PM | Tags: intermediate

From StackOverflow [c++11]:

I have an object that needs to take a variadic argument list in its constructor and store the arguments in a vector. How do I initialize a vector from a the arguments of a variadic constructor?

class GenericNode {
public:
    GenericNode(GenericNode*... inputs) {
            /* Something like... */
        // inputs_.push_back(inputs)...;
}
private:
    std::vector<GenericNode*> inputs_;
};

Continue reading...

Quick Q: Simultaneously iterating over and modifying an unordered_set? -- StackOverflow

By Blog Staff | Dec 21, 2012 02:27 PM | Tags: basics

From StackOverflow [c++11]:

Consider the following code:

unordered_set<T> S = ...;
for (const auto& x : S)
   if (...)
       S.insert(...);

This is broken correct? If we insert something into S then the iterators may be invalidated (due to a rehash), which will break the range-for because under the hood it is using S.begin ... S.end.

Is there some pattern to deal with this?

Continue reading...

Is C++11 uniform initialization a replacement for the old style syntax? -- Programmers.StackExchange

By Joel Lamotte | Dec 20, 2012 09:09 AM | Tags: basics

Here is a question from Programmer's StackExchange (tags [c++] and [c++11]) which most C++ developers, whatever their level, will ask as soon as they are introduced to the new Uniform Initialization syntax:

Is it recommended now to use uniform initialization in all cases? What should the general approach be for this new feature as far as coding style goes and general usage? What are some reasons to not use it?

The accepted answer clearly provides very good reasons to use this new syntax as much as possible (if your compiler supports it already): minimizing redundant typenames and avoiding the Most Vexing Parse. It also points some reasons to not use this syntax, in particular in case you're trying to call a standard container constructor.

There is one other reason not to:

std::vector<int> v{100};

What does this do? It could create a vector<int> with one hundred default-constructed items. Or it could create a vector<int> with one item whose value is 100. ... In actuality, it does the latter.

Read the full QA.

Read Stroustrup's FAQ about Uniform Initialization syntax.

Constexpr Unions -- Andrzej KrzemieĊ„ski

By Blog Staff | Dec 17, 2012 08:02 AM | Tags: advanced

On using constexpr and unions, with insights into the design of the currently-proposed std::optional<T>:

Constexpr Unions

by Andrzej Krzemieński

I assume you are already familiar with constexpr functions. (If not, see a short introduction here.) [Ed.: We linked to that article recently, so you've seen it if you've been following isocpp.org.]

In this post I wanted to share my experience with using unions in constant expressions. Unions are not very popular due to type-safety hole they open, but they offer some capabilities that I found priceless when working with Fernando Cacciola on std::optional proposal.

Continue reading...