Home » Blog » Categories »

Sometimes You Must Violate an Abstraction to Maintain It -- Andrew Koenig

By Blog Staff | Jul 17, 2013 01:55 PM | Tags: basics

Koenig explains std::move as, well, just a bit of a fib, really:

Sometimes You Must Violate an Abstraction to Maintain It

by Andrew Koenig

From the article:

What std::move really does is to return its argument as an rvalue reference. In effect, every time we use std::move, we are telling a lie. In this case, by writing std::move(t.s), we are saying that we want to use t.s, but to do so in a way that treats t.s as an rvalue. It is acceptable for us to tell this lie for exactly the same reason that it is acceptable for us to cast t.s to string&& in the previous example: We know that t.s is a member of t, and t really refers to an rvalue in our caller's context.

We can tell such lies any time we are willing to take responsibility for the consequences. ...

Quick Q: Can I use a const std::regex from two threads without synchronization? -- StackOverflow

By Blog Staff | Jul 16, 2013 10:00 AM | Tags: None

Quick A: See GotW #6a. The answer is the same for any object, not just regex.

Concurrently using std::regex, defined behaviour?

[...] I can't find anything which states whether using a const std::regex concurrently results in undefined behaviour or not. As far as I can tell, no edits are being made to the regex object so no undefined behaviour should be induced by using it concurrently?

Thanks in advance!

C++11/14 Training Materials -- Scott Meyers

By Blog Staff | Jul 13, 2013 04:59 PM | Tags: intermediate basics

meyers-newcppmaterials.PNGC++14 is still very much a draft -- it only became feature-complete in April and is now in its primary comment ballot. But interest in this new standard is high, with a restarted "Guru of the Week" series focusing on C++14 and now Scott Meyers has produced the first book-like materials that include significant coverage of C++14.

C++11 Training Materials Updated -- Now With C++14 Info!

For the seventh time since originally releasing them over three years ago, I've updated my annotated training materials for "The New C++". Until this update, "the new C++" referred to C++11, but with this revision, I'm including treatment of several features from draft C++14 that I believe will make it into the new new standard. As far as I know, this makes my training materials the first "book-like" publication that covers features in C++14.

What is std::promise? -- StackOverflow

By Blog Staff | Jul 13, 2013 04:11 PM | Tags: intermediate

Inquiring minds want to know this classic question:

What is std::promise?

I'm fairly familiar with the new standard library's std::thread, std::async and std::future components (e.g. see this answer), which are straight-forward.

However, I cannot quite grasp what std::promise is, what it does and in which situations it is best used. The standard document itself doesn't contain a whole lot of information beyond its class synopsis, and neither does just::thread.

Could someone please give a brief, succinct example of a situation where an std::promise is needed and where it is the most idiomatic solution?

Quick Q: Why is noexcept not enforced at compile time? -- StackOverflow

By Blog Staff | Jul 12, 2013 06:35 AM | Tags: intermediate

NoSenseEtAl asked:

Why noexcept is not enforced at compile time?

As you might know C++11 has noexcept keyword. Now ugly part about it is this:

Note that a noexcept specification on a function is not a compile-time check; it is merely a method for a programmer to inform the compiler whether or not a function should throw exceptions.

http://en.cppreference.com/w/cpp/language/noexcept_spec

So is this a design failure on the committee part or they just left it as an exercise for the compile writers smile in a sense that decent compilers will enforce it, bad ones can still be compliant?

C++11 New Feature: auto Type Deduction -- FangLu

By stella | Jul 10, 2013 08:22 AM | Tags: basics

A new article on auto type deduction has been posted to IBM's C/C++ cafe.

C++11 new feature: auto type deduction

by FangLu

This article describes a new C++11 feature that deprecates the auto keyword as a storage class specifier, but reserves auto as a type specifier that directs the compiler to deduce the type of a declared variable from its initialization expression. This auto type deduction feature can increase programming convenience, eliminate potential typing errors, and simplify the code.

Optimizing C++ Code: Constant-Folding -- Jim Hogg

By Blog Staff | Jul 10, 2013 08:18 AM | Tags: optimization intermediate

vc-team-blog.PNGThe Visual C++ Team Blog has been publishing an article series about optimizations that C++ compilers perform for you under the covers to make your code more efficient. This short nugget answers a question people sometimes ask: "What's constant folding, and why do I care?"

Optimizing C++ Code: Constant-Folding

by Jim Hogg

From the article:

This post examines Constant-Folding -- one of the simplest optimizations performed by the VC++ compiler.  In this optimization, the compiler works out the result of an expression while it is compiling (at “compile-time”), and inserts the answer directly into the generated code.  This avoids the cost of performing those same calculations when the program runs (at “runtime”).

Here is an example...

Quick Q: What's the weak_ptr equivalent for unique_ptr? -- StackOverflow

By Blog Staff | Jul 9, 2013 03:39 PM | Tags: basics

Quick A: There isn't, because unique_ptr is unique. If you want shared ownership or shared observation, you need a shared_ptr. The "shared"-ness in shared_ptr enables both shared ownership (shared_ptr) and shared observation (weak_ptr).

shared_ptr<> is to weak_ptr<> as unique_ptr<> is to... what?

In C++11, you can use a shared_ptr<> to establish an ownership relation with an object or variable and weak_ptr<> to safely reference that object in a non-owned way.

You can also use unique_ptr<> to establish an ownership relation with an object or variable. But what if other, non-owning objects want to also reference that object? weak_ptr<> isn't helpful in this case. Raw pointers are helpful but bring various downsides (e.g. they can be automatically initialized to nullptr but this is accomplished through techniques that are not consistent with the std::*_ptr<> types).

What is the equivalent of weak_ptr<> for non-owning references to objects owned via unique_ptr<>?