: Standard C++

Home » Blog » Categories »

« Prev Next »

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

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

dn519920.kenny_kerr_headshot(en-us,MSDN.10).jpg 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.

N3828: C++ Standards Committee Meeting, Nov 3-8, 2014, Urbana-Champaign

By Blog Staff | Jan 9, 2014 11:01 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3828

Date: 2014-01-07

C++ Standards Committee Meeting November 3-8, 2014 University of Illinois at Urbana-Champaign

by Jill Peckham

Excerpt:

The Fall 2014 C++ Standards Committee Meeting will be held on the
campus of the University of Illinois at Urbana-Champaign. Hosts for the
meeting are the U of I Department of Computer Science and the Parallel
Computing Institute.

Meetings will be held in the Thomas M. Siebel Center for Computer Science
and the Coordinated Science Laboratory, both conveniently located just a
few blocks from either conference hotel and across the street from each
other.

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