Sutter’s Mill

JG Question

1. What are the performance and correctness implications of the following function declaration? Explain.

void f( shared_ptr<widget> );

Guru Question

2. A colleague is writing a function f that takes an existing object of type widget as a required input-only parameter, and trying to decide among the following basic ways to take the parameter (omitting const):

void f( widget& );
void f( unique_ptr<widget> );
void f( unique_ptr<widget>& );
void f( shared_ptr<widget> );
void f( shared_ptr<widget>& );

Under what circumstances is each appropriate? Explain your answer, including where const should or should not be added anywhere in the parameter type.

(There are other ways to pass the parameter, but we will consider only the ones shown above.)

Read Full Post »

The solution to GotW #104 is now live.

Read Full Post »

While spelunking through the code of a new project you recently joined, you find the following factory function declaration:

widget* load_widget( widget::id desired );

JG Question

1. What’s wrong with this return type?

Guru Questions

2. What is the recommended return type? Explain your answer, including any tradeoffs.

3. You’d like to actually change the return type to match the recommendation in #2, but at first you worry about breaking source compatibility with existing calling code; recompiling existing callers is fine, but having to go change them all is not. Then you have an “aha!” moment, realizing that this is a fairly new project and all of your calling code is written using modern C++ idioms, and you go ahead and change the return type without fear, knowing it will require few or no code changes to callers. What makes you so confident?

Read Full Post »

The solution to GotW #103 is now live.

Read Full Post »

JG Question

1. When should you use shared_ptr vs. unique_ptr? List as many considerations as you can.

Guru Questions

2. Why should you always use make_shared to allocate objects whose lifetimes will be managed by shared_ptr? Explain.

3. What’s the deal with auto_ptr?

Read Full Post »

The solution to GotW #102 is now live.

Read Full Post »

JG Question

1. In each of the following statements, what can you say about the order of evaluation of the functions f, g, and h and the expressions expr1 and expr2? Assume that expr1 and expr2 do not contain more function calls.

// Example 1(a)
//
f( expr1, expr2 );

// Example 1(b)
//
f( g( expr1 ), h( expr2 ) );

Guru Questions

2. In your travels through the dusty corners of your company’s code archives, you find the following code fragment:

//  Example 2

//  In some header file:
void f( T1*, T2* );

//  At some call site:
f( new T1, new T2 );

Does this code have any potential exception safety or other problems? Explain.

3. As you continue to root through the archives, you see that someone must not have liked Example 2 because later versions of the files in question were changed as follows:

//  Example 3

//  In some header file:
void f( std::unique_ptr<T1>, std::unique_ptr<T2> );

//  At some call site:
f( std::unique_ptr<T1>{ new T1 }, std::unique_ptr<T2>{ new T2 } );

What are the semantics of this call? What improvements does this version offer over Example 2, if any? Do any exception safety problems remain? Explain.

4. Demonstrate how to write a make_unique facility that solves the safety problems in Question 3 and can be invoked as follows:

//  Example 4

//  In some header file:
void f( std::unique_ptr<T1>, std::unique_ptr<T2> );

//  At some call site:
f( make_unique<T1>(), make_unique<T2>() );

Read Full Post »

The solution to GotW #101 is now live.

Read Full Post »

GotW #100 demonstrated the best way to express the Pimpl idiom using only standard C++11 features:

// in header file
class widget {
public:
    widget();
    ~widget();
private:
    class impl;
    unique_ptr<impl> pimpl;
};

// in implementation file
class widget::impl {
    // :::
};

widget::widget() : pimpl{ new impl{ /*...*/ } } { }
widget::~widget() { }                   // or =default

Guru Question

Is it possible to make the widget code easier to write by wrapping the Pimpl pattern in some sort of library helper? If so, how?

Try to make the widget code as convenient and concise as possible to write, with any compiler-generated semantics either correct by default or producing compile-time errors if the widget author forgets to write them.

[Update: Removed move operations from the basic pattern. Since not all Pimpl’d types need to be move-aware, it’s not really part of the core pattern.]

Read Full Post »

The solution to GotW #100 is now live.

Read Full Post »