Home » Blog » Tags » basics

basics

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

 

Auto: A Necessary Evil? -- Roger Orr

By fbuontempo | Jul 2, 2013 02:05 PM | Tags: intermediate basics

Roger Orr has written about the history and use of auto in ACCU's Overload 115:

Auto -- A Necessary Evil?

by Roger Orr

From the article:

The keyword auto now lets you declare variables where the compiler provides the actual type and the programmer is either unwilling or unable to name the actual type. The keyword can also be used in function definitions to let you provide the return type after the rest of the function declaration, which is useful when the return type depends on the type of the arguments.

As with any new keyword there are questions about usage –- at two levels. First of all, where and how are programmers permitted to use the new feature. Secondly, what guidance is there to sensible adoption of the new feature. I intend to start with by answering the first question and then subsequently focus on the second.

Explicit Is Better Than Implicit -- K-ballo

By Blog Staff | Jun 21, 2013 01:52 PM | Tags: intermediate explicit conversions basics

tales-of-cpp.PNGTales of C++, Episode 5:

Explicit Is Better Than Implicit

The Zen of Python tell us that Explicit is better than Implicit. This is good advice for any and all languages, but what are the implications in the C++ lands? There is one particular C++ feature that relates directly to that advice; one important enough that grants on its own the introduction of a keyword. That feature is user-defined conversions and that keyword is explicit.

GotW #93 Solution: Auto Variables, Part 2 -- Herb Sutter

By Blog Staff | Jun 14, 2013 04:36 PM | Tags: intermediate basics

The solution to the latest GotW problem is now available:

GotW #93 Solution: Auto Variables, Part 2

by Herb Sutter

From the article:

As you worked through these cases, perhaps you noticed a pattern: The cases are mostly very different, but what they have in common is that they illustrate reason after reason motivating why (and how) to use auto to declare variables.

Let’s dig in and see...

Quick Q: What type to return from a property-style "getter"? -- StackOverflow

By Blog Staff | Jun 11, 2013 03:40 PM | Tags: return type ownership getters basics

Quick A: Reference to const.

c++11 -- Ownership and getters

I'm new to C++ and I have troubles wrapping my head around ownership, specifically with a getter. Here's some example code:

class GameObject {
public:
  Transform *transform();
private:
  Transform _transform;
};

I guess a raw pointer is unsafe to use as someone could access it later when the object doesn't exist anymore?

  1. So I thought about using a unique_ptr for the transform member, since GameObject is the only one that owns the transform. But I can't return that from the getter, can I? But then again, why would I ever use a unique_ptr in the first place instead of adding it as a member like above?
  2. So why not use a shared_ptr? It just seems wrong to me, I don't want to share ownership, GameObject is the owner and others may access it...
  3. So what is it? A reference? I guess shared_ptr seems the wisest choice, since others could safely keep a reference to transform, but what good is that if the enclosing GameObject got destroyed, rendering the transform useless? I'm probably just thinking about ownership the wrong wrong way here but every way seems wrong to me. Thanks for your help.

Quick Q: In a function template, why pass const T& vs. T&&? -- StackOverflow

By Blog Staff | Jun 10, 2013 01:07 PM | Tags: basics

Quick A: Because you want to not change the argument, or you want to forward it, respectively.

c++ rvalue reference and const qualifier

Among the many benefits of const qualification is to make an API more understandable, example:

template<typename T> int function1(T const& in);
// clearly, the input won’t change through function1

With the introduction of rvalue references, one can benefit from perfect forwarding but often const qualifiers are removed, example:

template<typename T> int function2(T&& in);
// can explicitly forward the input if it's an rvalue

Apart from documentation, is there a good way to describe that function2 won’t change its input?