Home » Blog » Tags » basics

basics

C++'s Best Feature -- Andrzej Krzemieński

By Blog Staff | Jul 18, 2013 05:07 PM | Tags: basics

Andrzej's title is not only catchy, but completely correct (we politely disagree with your final disclaimer, sorry Andrzej): Deterministic lifetime with destructors is C++'s best feature, and very underappreciated. Like most wonderful things, you appreciate it most when it's gone, namely when you're using another language where it's absent.

C++'s best feature

by Andrzej Krzemieński

From the article:

C++, if you want to learn all of it, is big, difficult and tricky. If you look at what some people do with it, you might get scared. New features are being added. It takes years to learn every corner of the language.

But you do not need to learn all of it. Effective use of C++ requires only the knowledge of a couple of its essential features. In this post, I am going to write about one C++ feature that I consider one of the most important. The one that makes me choose C++ rather than other popular programming languages. ...

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

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.

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.

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

Working with Dynamic Memory in C++ -- Stan Lippman, Josée Lajoie, Barbara Moo

By Blog Staff | Jul 9, 2013 09:57 AM | Tags: basics

A chapter worth reading on InformIT, excerpted from C++ Primer 5th Edition:

Working with Dynamic Memory in C++

by Stan Lippman, Josée Lajoie, Barbara Moo

C++ lets you allocate objects dynamically. The authors of C++ Primer discuss why properly freeing dynamic memory is a rich source of bugs, and how the new library defines smart pointers -- shared_ptr, unique_ptr, and weak_ptr -- that make managing dynamic memory much safer.

Quick Q: How do I remove a unique_ptr from a queue? -- StackOverflow

By Blog Staff | Jul 8, 2013 11:39 AM | Tags: basics

Quick A: move(q.front()).

remove unique_ptr from queue

I'm trying to figure out how/if I can use unique_ptr in a queue.

// create queue
std::queue<std::unique_ptr<int>> q;

// add element
std::unique_ptr<int> p (new int{123});
q.push(std::move(p));

// try to grab the element
auto p2 = foo_queue.front();
q.pop();

I do understand why the code above doesn't work. Since the front & pop are 2 separate steps, the element cannot be moved. Is there a way to do this?

Quick Q: What are move semantics? -- StackOverflow

By Blog Staff | Jul 6, 2013 05:22 AM | Tags: basics

One of the highest-ranked C++ questions (and answers) on StackOverflow is worth re-reading if you're new to the topic:

What are move semantics?

I just finished listening to the Software Engineering talk radio podcast interview with Scott Meyers regarding C++0x. Most of the new features made sense to me, and I am actually excited about C++0x now, with the exception of one. I still don't get move semantics... What are they exactly?

Moving an Object Does Not Destroy The Original -- Andrew Koenig

By Blog Staff | Jul 5, 2013 04:17 PM | Tags: basics

Andy's next on move semantics:

Moving an Object Does Not Destroy The Original

by Andrew Koenig

From the article:

Recall first that objects are generally moved instead of copied because the originals are about to go away. When I learned this fact, I thought at first that moving an object should destroy the original. ...

I was surprised to learn that that is not what happens. Instead, whenever a program moves an object, it must leave that object with a valid value so that it can be destroyed later. ...