basics

Quick Q: was raw-pointer constructor of shared_ptr a mistake?

Quick A: No, its usage is well defined.

Recently on SO:

was raw-pointer constructor of shared_ptr a mistake?

In hindsight, given make_shared, would shared_ptr have a constructor that takes a raw pointer had it been introduced with C++11?
What if you don't control the allocation of the object? What if you need to use a custom deleter? What if you need list-initialization instead of parens?

None of these cases is handled by make_shared.

Additionally, if you're using weak_ptr, a shared_ptr allocated via make_shared won't free any memory until all the weak_ptrs are destroyed as well. So even if you have a normal shared pointer where none of the above apply, it's possible that you may still prefer the raw pointer constructor.

Yet another situation would be if your type provides overloads for operator new and operator delete. These may make it ill-suited for make_shared, since those overloads will not be called - and presumably they exist for a reason.

Quick Q: Why assigning a value is calling the implicit constructor?

Quick A: Because the default assignement operator knows only the type of your object, which it can get be calling the constructor.

Recently on SO:

What is the point of calling constructor with implicit conversion instead of assignment operator after an object is initalized?

There is no implicit CBox::operator=(double), so box = 2.0; has to create a temporary CBox object. It's equivalent to box = CBox(2.0);.

Making your constructor explicit disallows the implicit conversion from double to CBox, so no appropriate assignment operator exists, and you get a compile error.

Quick Q: Why is there no to_string(const string&)?

Quick A: If you need such a function you can create it.

Recently on SO:

Why is there no to_string(const string&)?

You can just write your own templated function with proper overloads as follows:

#include <iostream>
#include <string>
using namespace std;

template<typename T>
std::string toString(const T& t) {
    return std::to_string(t);
}

std::string toString(const char* t) {
    return t;
}

std::string toString(const std::string& t) {
    return t;
}

int main() {
    cout << toString(10) << endl;
    cout << toString(1.5) << endl;
    cout << toString("char*") << endl;
    cout << toString(std::string("string")) << endl;
    return 0;
}

Quick Q: Templated Function results in Circular Inclusion

Quick A: Separate definition and implementation.

Recently on SO:

Templated Function results in Circular Inclusion

Define registerEvent after IApp.

class IApp;

class Component
{
    IApp* app;
    template<typename T>
    void registerEvent(const int& evtId, Status (T::*func) (int));
};

class IApp : public Component {
  ...
};

template <typename T>
Component::registerEvent(const int& evtId, Status (T::*func) (int)) {
  auto res = std::bind(func, (T*)this, std::placeholders::_1);
  app->registerForEvent(evtId);
}

If need be, also define A::registerEvent after Component::registerEvent.

Quick Q: Why is list initialization (using curly braces) better than the alternatives?

Quick A: It is less likely to generate an unexpected error.

Recently on SO:

Why is list initialization (using curly braces) better than the alternatives?

Basically copying and pasting from Bjarne Stroustrup's "The C++ Programming Language 4th Edition":

List initialization does not allow narrowing (§iso.8.5.4). That is:

  • An integer cannot be converted to another integer that cannot hold its value. For example, char to int is allowed, but not int to char.
  • A floating-point value cannot be converted to another floating-point type that cannot hold its value. For example, float to double is allowed, but not double to float.
  • A floating-point value cannot be converted to an integer type.
  • An integer value cannot be converted to a floating-point type.

Example:

void fun(double val, int val2) {

    int x2 = val; // if val==7.9, x2 becomes 7 (bad)

    char c2 = val2; // if val2==1025, c2 becomes 1 (bad)

    int x3 {val}; // error: possible truncation (good)

    char c3 {val2}; // error: possible narrowing (good)

    char c4 {24}; // OK: 24 can be represented exactly as a char (good)

    char c5 {264}; // error (assuming 8-bit chars): 264 cannot be
                   // represented as a char (good)

    int x4 {2.0}; // error: no double to int value conversion (good)

}

The only situation where = is preferred over {} is when using auto keyword to get the type determined by the initializer.

Example:

auto z1 {99}; // z1 is an initializer_list<int>
auto z2 = 99; // z2 is an int

Conclusion

Prefer {} initialization over alternatives unless you have a strong reason not to.

Strict Weak Ordering and STL -- Saurabh Singh

Saurabh Singh describes in a brief tutorial on how to correctly implement the comparator function for STL containers and algorithms. 

Strict Weak Ordering and STL

by Saurabh Singh

From the article:

If you had ever used a map or set or even std::sort I bet you would have to give a comparator function. (Or an overload to the < (less than) operator).
I will try to give an overview of how certain associative stl containers use this property for ordering the elements.
Almost all stl containers rely on strict weak ordering A strict weak ordering defines the relative position of elements in terms of precedence of one item over other. For eg. if you have a room full of person and you have to form a queue based on their height, a person with "lesser" height will "precede" the person with greater height. For a function to be satisfying strict weak ordering following conditions need to be met.

The PDF version of the document is available here.

Quick Q: Need of a weak_ptr in C++11

Quick A: To keep a pointer on a ressource without owning it.

Recently on SO:

Need of a weak_ptr in C++11

The second half of that statement should be clear: if a pointer is not an owning pointer then the object it is pointing at might be deleted by whatever software is the owner - and then you'd have the standard dangling reference.

So this issue is: you've got objects owned by some piece of software which is letting other software have access to it - but the other software won't share the ownership. So the owner can delete it at any time and the other software needs to know it's pointer is no longer valid.

Maybe an example would help:

You've got some piece of software watching a camera pointing out your window to a bird feeder and it is identifying birds at the feeder, which come and go. Each bird at the feeder has an object created by this software when it arrives at the feeder, and the object is deleted when the bird flies away.

Meanwhile, some other software it taking a census. Every 10 seconds it grabs from the feeder-watching software a collection of the birds at the feeder. Every 100 seconds it emits a report of which birds were at the feeder for the entire 100 seconds.

Because the data for a bird is big the census-taker doesn't copy the data. It merely gets, every 10 seconds, a collection of pointers from the feeder-watcher.

To make it necessary to use weak pointers, let's say the feeder-watcher only provides pointers to birds which have arrived in the last ten seconds, not the ones which have been there. That is, there is no notification that birds have disappeared.

By using weak pointers it can know, at report time, which of the birds are still there, and when they arrived (but not when they left).

(Maybe I'll think of a better example later.)

The Ultimate Question of Programming, Refactoring, and Everything

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort.

The Ultimate Question of Programming, Refactoring, and Everything

by Andrey Karpov

From the article:

The scope of my interests − the C/C++ language and the promotion of code analysis methodology. I have been Microsoft MVP in Visual C++ for 5 years. The main aim of my articles and work in general - is to make the code of programs safer and more secure. I'll be really glad if these recommendations help you write better code, and avoid typical errors. Those who write code standards for companies may also find some helpful information here.