Articles & Books

Quick Q: How do I write string literals that contain special characters? -- StackOverflow

so-blackjack.PNGQuick A: Use raw string literals! If your compiler doesn't have them yet, nag.

The original question on SO, but note the best answer is pepper_chico's rather than the selected answer:

Only Detect Text in Quotations (C++)

I'm not great at programming and recently started to read tutorials on C++.

I decided I would attempt to make a simple blackjack program. I tried to make a title with "big text" but C++ is preventing me from doing it because it is detecting other things inside the text.

    //Start Screen Begin
cout << " ____  _            _     _            _        ";
cout << "| __ )| | __ _  ___| | __(_) __ _  ___| | __    ";
cout << "|  _ \| |/ _` |/ __| |/ /| |/ _` |/ __| |/ /    ";
cout << "| |_) | | (_| | (__|   < | | (_| | (__|   <     ";
cout << "|____/|_|\__,_|\___|_|\_\/ |\__,_|\___|_|\_\    ";
cout << "                       |__/                     ";
    //Start Screen End

This is what I am trying to display, yet keep getting the following error:

undefined reference to 'WinMain@16'

I am asking if there is a way to tell C++ I only want it to read and display the text, and not use any functions.

C++ in 2014 -- Jens Weller

From new C++ user groups springing up across Europe and upcoming conferences, to the Boost refactoring and (of course) C++14, Jens Weller has a nice piece previewing some of the things to look forward to for C++ in 2014.

C++ in 2014

by Jens Weller

Note that Jens' list is not complete, but it gives a pretty good overview of what's coming up in the near term with a few more things to be added later.

A small teaser from the article:

I already know that there are new C++ User Groups in Aachen, Dortmund, Heidelberg and Munich in Germany, also a Russian C++ User Group is now meeting in St. Petersburg and Moscow. I think a few others will follow...

 

Quick Q: Should "property get" functions be noexcept? -- StackOverflow

Quick A: Maybe, but it generally commits you to exposing the internal type (can't change representation).

Recently on SO:

Should I use noexcept for getters always?

Should I use noexcept method modifier for getters always in C++11?

I mean simple getters here that just return members. At least in all my getters I have here an exception can't possibly be thrown. One downside is that a getter gets too verbose:

const std::string& getName() const noexcept{ return name; }

The good side as pointed out in Stroustrup's book is that the compiler might do some optimizations here and there.

GotW #95 Solution: Thread Safety and Synchronization -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #95 Solution: Thread Safety and Synchronization

by Herb Sutter

From the article:

This GotW was written to answer a set of related frequently asked questions. So here’s a mini-FAQ on "thread safety and synchronization in a nutshell," and the points we’ll cover apply to thread safety and synchronization in pretty much any mainstream language.

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

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

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

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

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

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.