Using Regular Expressions with Modern C++ -- Kenny Kerr

By Blog Staff | Jan 14, 2014 08:49 AM | Tags: intermediate

In the current MSDN Magazine:

Using Regular Expressions with Modern C++

by Kenny Kerr

From the article:

C++11 introduced a long list of features that are in themselves quite exciting, but if all you see is a list of isolated features, then you’re missing out. The combination of these features makes C++ into the powerhouse that many have grown to appreciate. I’m going to illustrate this point by showing you how to use regular expressions with modern C++... the combination of C++ language and library features really turns C++ into a productive programming language.

Quick Q: How can I avoid writing ::value and ::type when using std::enable_if? -- StackOverflow

By Blog Staff | Jan 14, 2014 06:54 AM | Tags: None

Quick A: Use a template alias. Several standard ones are coming in C++14.

Recently on SO:

How can I avoid writing ::value and ::type when using std::enable_if? [cppx]

In some of my code, namely the header rfc/cppx/text/String.h, I found the following mysterious snippet:

template< class S, class enable = CPPX_IF_( Is_a_< String, S > ) >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

The operator! is in support of a String class that has an implicit conversion to raw pointer. So I overload (among others) operator! for this class and derived classes, so that inadvertent use of a non-supported operator will give a suitable compilation error, mentioning that it's meaningless and inaccessible. Which I think is much preferable to such usage being silently accepted with an unexpected, incorrect result.

The CPPX_IF_ macro supports Visual C++ 12.0 (2013) and earlier, which finds C++11 using to be mostly beyond its ken. For a more standard-conforming compiler I would have written just ...

template< class S, class enable = If_< Is_a_< String, S > > >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

This looks like std::enable_if,

template< class S, class enabled = typename std::enable_if< Is_a_< String, S >::value, void >::type >
void operator!  ( S const& )
{ string_detail::Meaningless::operation(); }

except that the If_ or CPPX_IF_, and its expression, is much more concise and readable.

How on Earth did I do that?

Type Erasure, Part 4 -- Andrzej Krzemieński

By Blog Staff | Jan 13, 2014 09:40 AM | Tags: intermediate

In part 4, Andrzej wraps up his series on type erasure with a discussion and comparison of facilities in the standard library, Boost, and otherwise.

Type Erasure, Part 4

by Andrzej Krzemieński

From the article:

In this post we will be wrapping up the series on type erasure. We will see an another form of value-semantic type erasure: boost::any, and try to compare the different methods.

Quick Q: Is pass-by-value-and-then-move a bad idiom? -- StackOverflow

By Blog Staff | Jan 13, 2014 01:47 AM | Tags: basics

Quick A: It's a good style by default when you know you'll keep a copy of the parameter anyway. If you have an expensive-to-move type or otherwise want additional control, you can overload on &/&& or else perfect-forward.

Recently on SO:

Is the pass-by-value-and-then-move construct a bad idiom?

Since we have move semantincs in C++, nowadays it is usual to do

void set_a(A a) { _a = std::move(a); }

The reasoning is that if a is an rvalue, the copy will be elided and there will be just one move.

But what happens if a is an lvalue? It seems there will be a copy construction and then a move assignment (assuming A has a proper move assignment operator). Move assignments can be costly if the object has too many member variables.

On the other hand, if we do

void set_a(const A& a) { _a = a; }

There will be just one copy assignment. Can we say this way is preferred over the pass-by-value idiom if we will pass lvalues?

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

By Blog Staff | Jan 10, 2014 12:47 PM | Tags: basics

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.

Quick Q: Is it possible to have automatically generated destructors in C++? -- StackOverflow

By Blog Staff | Jan 10, 2014 11:37 AM | Tags: basics

Quick A: Yes, and we do!

Recently on SO -- the selected answer is the correct one:

Is it possible to have automatically generated destructors in C++?

It is too big burden to do it by ourselves all the time. Is it so hard for the compiler to generate destructors? Can't it detect what is a "resource" and release it in the destructor?

An overview of smart pointers -- Jens Weller

By Blog Staff | Jan 10, 2014 10:30 AM | Tags: basics

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.

GotW #7c Solution: Minimizing Compile-Time Dependencies, Part 3

By Blog Staff | Jan 8, 2014 10:32 AM | Tags: intermediate

The solution to the latest GotW problem is now available:

GotW #7c Solution: Minimizing Compile-Time Dependencies, Part 3

by Herb Sutter

From the article:

But did you notice the curious thing about B's virtual functions?

"What?" you might say. "B has no virtual functions."

Right. That is the curious thing...

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

By Blog Staff | Jan 2, 2014 01:48 AM | Tags: basics

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

By Blog Staff | Jan 1, 2014 10:13 AM | Tags: None

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++.