Tag Archives: C++

Herb Sutter GotW91: Smart Pointer parameters

Herb Sutter’s guidelines on passing smart pointers as parameters include the following:

  • Copying smart pointers incurs two performance hits:
    • Cost of increment and decrement on the internally synchronised reference count
    • Scalability woes due to cache contention on the shared reference count
  • Passing a shared_ptr by value implies taking shared ownership. A copy is needed anyway, so incurring copying cost is fine.
  • Don’t use a const smart_ptr& parameter because it exposes the function to the caller’s lifetime management policy. Use a Widget* instead.

Guideline: Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership.

Guideline: Prefer passing objects by value, *, or &, not by smart pointer.

Leave a comment

Filed under C++, Programming

Herb Sutter GotW89: Smart Pointers

Herb Sutter’s GotW89 Smart Pointers post includes good reasons to use make_shared/make_unique instead of naked new. Avoiding memory fragmentation is one of those:

Separate allocation

auto sp1 = shared_ptr<Widget>{ new widget{} };
auto sp2 = sp1;

Separate allocation

Single allocation
If you use make_shared to allocate the object and the shared_ptr all in one go, then the implementation can fold them together in a single allocation.

auto sp1 = make_shared<Widget>();
auto sp2 = sp1;

Single allocation

Leave a comment

Filed under C++, Programming

decltype and declval

Good examples of decltype and declval posted on reddit and TheNewCpp.com.

Leave a comment

Filed under C++, Programming

How to choose whether to pass by const-reference or by value

There was a post on the ISOCpp blog last week about passing by const-reference or by value. The full StackOverflow post is Why do we copy then move? and another related post asks Are the days of passing by const ref over?.

First, as my friend and colleague Andy Sawyer pointed out in a conversation, taking a parameter by value leaks implementation detail out of the function so he recommends passing by const reference unless there’s a good reason not to.

Second, whilst passing by value presents the opportunity for the callee to store data using move semantics, the callee has to invoke that explicitly by calling std::move:


#include <string>
#include <iostream>

class A
{
public:
 A( const std::string& s ) :
 str_( s )
 {
   std::cout << "A: s='" << s << "', str_='" << str_ << "'\n";
 }
private:
 std::string str_;
};

class B
{
public:
 B( std::string s ) :
 str_( s )
 {
   std::cout << "B: s='" << s << "', str_='" << str_ << "'\n";
 }
private:
 std::string str_;
};

class C
{
public:
 C( std::string s ) :
 str_( std::move(s) )
 {
std::cout << "C: s='" << s << "', str_='" << str_ << "'\n";
 }
private:
 std::string str_;
};


int _tmain(int argc, _TCHAR* argv[])
{
 A a( "ConstReference" ); // Constructor(char*) then CopyConstructor
 B b( "PassByValue" ); // Constructor(char*) then CopyConstructor
 C c( "PassByValueAndMove" );// Constructor(char*) then MoveConstructor

return 0;
}

PassByValueAndMove

2 Comments

Filed under C++, C++ Code, Programming

Herb Sutter GotW6: Const and Mutable

This item covers ground Herb already presented in this video. He recommends that const member functions must be one of:

  • truly physically/bitwise const with respect to this object
  • internally synchronized so that if it does perform any actual writes to the object’s data, that data is correctly protected with a mutex or equivalent (or if appropriate are atomic) so that any possible concurrent non-const accesses by multiple callers can’t tell the difference.

Similarly, he asserts that the guidelines taught for C++98, that const means logically const but you had a free rein with internal data, is no longer true for C++11 with its memory model and thread safety specification.

This implies stricter best practice on use of mutable member variables. Any time you need to mutate data in a const member function, you should protect it with a synchronisation object to ensure thread safety.

Leave a comment

Filed under C++, Programming

Lambdas v Closures

Scott Meyers posted this explanation of the difference between a lambda and a closure.

The distinction between a lambda and the corresponding closure is precisely equivalent to the distinction between a class and an instance of the class. A class exists only in source code; it doesn’t exist at runtime. What exists at runtime are objects of the class type. Closures are to lambdas as objects are to classes. This should not be a surprise, because each lambda expression causes a unique class to be generated (during compilation) and also causes an object of that class type–a closure–to be created (at runtime).

He also managed to squeeze in mention of Universal References (in the context of the managing the lifetime of a closure).

1 Comment

Filed under C++, Programming

Herb Sutter GotW 4: Class Mechanics

Herb Sutter’s GotW 4 on class mechanics is a treasure trove of best practice. It includes handy examples and canonical signatures for operator<, operator+ and the pre/post-increment operators.

I particularly liked his recommendation for implementing the postfix increment in terms of the prefix version:

complex operator++( int ) {
        auto temp = *this;
        ++real;
        return temp;
    }

Leave a comment

Filed under C++, Programming

Guru of the Week restarting from Item 1

Herb Sutter is reviewing his Guru of the Week series from item one, in the light of features in C++11 and C++14. This will form the backbone of a new issue of Exceptional C++.

Leave a comment

Filed under C++, Programming

How to profile performance by hand

I recently needed to profile some C++ code that was taking longer than expected to run. The code was running on a machine without a profiler, so I wrote a handy Timer class that dumps nested timings of each method. You can initialize it to write either to a file or to std::cout if the machine has a console.

I originally thought of this as a ‘Poor Man’s Profiler’, but having used it there are real benefits to taking the trouble to instrument your own code – you can use the file dumps to swiftly compare performance between code changes; you can print out performance statistics and take along to meetings.

#include <iostream>
#include <chrono>
class TimerOutput
{
  public:
    TimerOutput( const std::string file_path = "" ) :
      file_path_( file_path )
    {
      if ( !file_path_.empty() )
      {
        file_.open( file_path_ );
      }
    }

    std::ostream& Stream()
    {
      if (file_path_.empty() )
        return std::cout;
      else
        return file_;
    }

private:
    std::string file_path_;
    std::ofstream file_;
};

class Timer
{
public:
    Timer( const std::string& description ) :
      description_(description),
      start_(std::chrono::system_clock::now())
    {
        applyIndent();
        timer_output_->Stream() << "Start " << description_.c_str() << "\n";
        ++indent;
    }

    ~Timer()
    {
        --indent;
        const std::chrono::time_point<std::chrono::system_clock> finish = std::chrono::system_clock::now();
        auto milliseconds = std::chrono::duration_cast<std::chrono::milliseconds>(finish - start_).count();

        applyIndent();
        timer_output_->Stream() << "Finished " << description_.c_str()
            << ", took " << milliseconds << " (ms)" << "\n";
}

private:
    void applyIndent() const
    {
        for ( size_t i = 0; i < indent; ++i )
        {
            timer_output_->Stream() << "--";
        }
    }

    static size_t indent;
    static TimerOutput* timer_output_;
    std::string description_;
    const std::chrono::time_point<std::chrono::system_clock> start_;
};

#define INITIALIZE_PROFILING_TO_CONSOLE() \
  TimerOutput timer_output; \
  size_t Timer::indent = 0; \
  TimerOutput* Timer::timer_output_ = &timer_output;

#define INITIALIZE_PROFILING_TO_FILE( path ) \
  TimerOutput timer_output( path ); \
  size_t Timer::indent = 0; \
  TimerOutput* Timer::timer_output_ = &timer_output;

#define TIME( description, f ) \
  { \
    Timer profiler( description ); \
    f; \
  }

The obvious limitation of my solution is that it uses a class static to achieve the levels of nesting, so it won’t work on multi-threaded code – but it was great for my purposes. Here’s some sample code that shows it in action:

#include "stdafx.h"

#include <thread>
#include <fstream>

#include "..\MusingStudio\Profiler.h"

//INITIALIZE_PROFILING_TO_CONSOLE()
INITIALIZE_PROFILING_TO_FILE( "c:/temp/timings.txt" )

void method2()
{
  TIME( "method2",
    std::chrono::milliseconds short_wait( 5 );
    std::this_thread::sleep_for( short_wait );
  )
}

void method1()
{
 TIME( "method1",
  TIME( "loop",
    for ( int i = 0; i &lt; 5; ++i )
    {
        method2();
    }
  )

  TIME( "expensive algorithm",
    std::chrono::milliseconds wait( 100 );
    std::this_thread::sleep_for( wait );
  )
 )
}

void method3()
{
  TIME( "method3",
    std::chrono::milliseconds long_wait( 500 );
    std::this_thread::sleep_for( long_wait );
  )
}

int main(int argc, char* argv[])
{
  TIME( "main",
    method1();
    method3();
  )

  return 0;
}

Here’s the output from the sample code:
Profiler

Leave a comment

Filed under C++, C++ Code, Programming

Idiot’s Guide to C++ Templates

This article on C++ templates is well written, if rather long!

The second part is here.

Leave a comment

Filed under C++, Programming