Articles & Books

Quick Q: Why prefer making shared_ptrs via make_shared? -- StackOverflow

Quick A: Because it's more efficient, since it can eliminate an additional allocation.

Recently on SO:

Difference in make_shared and normal shared_ptr in C++

std::shared_ptr<Object> p1 = std::make_shared<Object>("foo");
std::shared_ptr<Object> p2(new Object("foo"));

Many google and stackoverflow posts are there on this, but I am not able to understand why make_shared is more efficient than directly using shared_ptr. Can someone explain me step by step sequence of objects created and operations done by both so that I will be able to understand how make_shared is efficient. I have given one example above for reference.

An overview of smart pointers -- Jens Weller

Jens's latest, following up on his pointers post:

An overview on smart pointers

by Jens Weller

From the article:

So, a smart pointer is only needed, when you use new or other means of dynamic memory allocation. In my opinion, you should prefer to allocate variables on the stack, so when refactoring code (to C++11), you should always ask yourself, if this new is needed, or could be replaced with an object on the stack. When you need to use new, you should always use a smart pointer in my opinion. Also some smart pointers offer a custom deleter, which is handy if you have an object that is either not allocated by new and/or needs to be freed by calling a special function.

Quick Q: Should we really avoid new and delete? -- StackOverflow

A: Yes, except possibly encapsulated inside the implementations of low-level data structures.

The more general question on SO was:

About the usage of new and delete, and Stroustrup's advice

About the usage of new and delete, and Stroustrup's advice...

He says something like (but not exactly, this is from my notes of his book):

A rule of thumb is that, new belongs in constructors and similar operations, delete belongs in destructors. In addition, new is often used in arguments to resource handles. Otherwise avoid using new and delete, use resource handles (smart pointers) instead.

I was wondering if the more experienced folks with C++11 have really applied this or not.

My impression of this was, wow this seems like a really cool rule to follow. But then I got suspicious, as for any general rule. At the end of the day you will end up using new and delete wherever necessary. But maybe this rule is a good guideline I don't know.

Interlude: C++’s Strides in 2013 -- K-ballo

K-ballo's look at the achievements of C++ completed in 2013 and coming up in 2014, with an overview of draft C++14 features.

Interlude

by K-ballo

From the article:

One year down the road, 2013 has gone by but not without modifications to the C++ lands. Two major compilers have reached C++11 conformance ---GCC and Clang---. Shortly after, the Committee Draft (CD) for C++14 was completed, which is now just around the corner...

All things considered, it was an impressive year for C++ conformance. And notably, it looks like for the first time there will be feature complete compilers for a C++ standard on the very same year it is ratified. The following slide from GoingNative's Keynote: Herb Sutter -- One C++ summarizes the situation nicely:

[... lots of discussion of C++14 features ...]

The C++ lands grew bigger during 2013, and we can only expect this trend to intensify during 2014. With the likely ratification of C++14 and at least some of the TS, it will certainly be a good year for C++.

 

GotW #7b Solution: Minimizing Compile-Time Dependencies, Part 2

The solution to the latest GotW problem is now available.

GotW #7b Solution: Minimizing Compile-Time Dependencies, Part 2

by Herb Sutter

From the article:

Now that the unnecessary headers have been removed, it’s time for Phase 2: How can you limit dependencies on the internals of a class?

... 

Guideline: For widely-included classes whose implementations may change, or to provide ABI-safety or binary compatibility, consider using the compiler-firewall idiom (Pimpl Idiom) to hide implementation details. Use an opaque pointer (a pointer to a declared but undefined class) declared as struct impl; std::unique_ptr<impl> pimpl; to store private nonvirtual members.

Quick Q: Does constexpr guarantee compile-time evaluation? -- StackOverflow

Quick A: constexpr guarantees compile-time evaluation is possible if operating on a compile-time value, and that compile-time evaluation will happen if a compile-time result is needed.

From SO, the originally worded question:

Can C++ constexpr function actually accept non-constant expression as argument?

I have defined a constexpr function as following:

constexpr int foo(int i)
{
    return i*2;
}

And this is what in the main function:

int main()
{
    int i=2;
    cout<<foo(i)<<endl;
    int arr[foo(i)];
    for(int j=0;j<foo(i);j++)
        arr[j]=j;
    for(int j=0;j<foo(i);j++)
        cout<<arr[j]<<" ";
    cout<<endl;
    return 0;
}

The program was compiled under OS X 10.8 with command clang++. I was surprised that the compiler did not produce any error message about foo(i) not being a constant expression, and the compiled program actually worked fine. Why?

Quick Q: How do I use conditional noexcept? -- StackOverflow

The question also has a lemon-zest touch of "templates in headers" but the basic noexcept question is still the same:

Use of the noexcept specifier in function declaration and definition?

Consider the following function:

// Declaration in the .h file
class MyClass
{
    template <class T> void function(T&& x) const;
};

// Definition in the .cpp file
template <class T> void MyClass::function(T&& x) const;

I want to make this function noexcept if the type T is nothrow constructible.

How to do that? (I mean what is the syntax ?)