basics

Quick Q: Confused about vectors

Quick A: Do not confuse mathematical concepts with C++ terminology.

Recently on SO:

Confused about vectors

You are getting confused because the mathematical concept of a vector can mean a "collection of data" and that is what you were taught int v[10] was. The actual name for that in C++ (and most other languages) is an "array" not a vector.

The libraries referred to in C++ Primer have a class called "vector" which is an implementation of an array. They are similar, but not the same.

I hope that clears that up a bit. You are probably confused because you were taught that int v[10] is a vector, but it is "not really" in C++. It's an array. Use that term to refer to it. If you ever refer to it as a vector, you will confuse others and yourself.

5 ways how unique_ptr enhances resource safety in your code -- Bartlomiej Filipek

Examples where unique_ptr shines:

5 ways how unique_ptr enhances resource safety in your code

by Bartlomiej Filipek

From the article:

While shared_ptr and weak_ptr are more complex, unique_ptr seems to be a perfect replacement for owning raw pointers. Not to mention is the fact that this pointer type is mostly a compile time “wrapper” and it cost almost nothing in the runtime.

Quick Q: What does the explicit keyword mean?

Quick A: It tell the compiler not to do any implicit conversions of types.

Recnetly on SO:

What does the explicit keyword mean?

The compiler is allowed to make one implicit conversion to resolve the parameters to a function. What this means is that the compiler can use constructors callable with a single parameter to convert from one type to another in order to get the right type for a parameter.

Here's an example class with a constructor that can be used for implicit conversions:

class Foo
{
public:
  // single parameter constructor, can be used as an implicit conversion
  Foo (int foo) : m_foo (foo)
  {
  }

  int GetFoo () { return m_foo; }

private:
  int m_foo;
};

Here's a simple function that takes a Foo object:

void DoBar (Foo foo)
{
  int i = foo.GetFoo ();
}

and here's where the DoBar function is called.

int main ()
{
  DoBar (42);
}

The argument is not a Foo object, but an int. However, there exists a constructor for Foo that takes an int so this constructor can be used to convert the parameter to the correct type.

The compiler is allowed to do this once for each parameter.

Prefixing the explicit keyword to the constructor prevents the compiler from using that constructor for implicit conversions. Adding it to the above class will create a compiler error at the function call DoBar (42). It is now necessary to call for conversion explicitly with  DoBar (Foo (42))

The reason you might want to do this is to avoid accidental construction that can hide bugs. Contrived example:

  • You have a MyString(int size) class with a constructor that constructs a string of the given size. You have a function print(const MyString&), and you call print(3) (when you actually intended to call print("3")). You expect it to print "3", but it prints an empty string of length 3 instead.

How not_null can improve your code? -- Bartlomiej Filipek

Let’s investigate what "not_null" (from the Core Guidelines/Guideline Support Library) can do for us.

How not_null can improve your code?

by Bartlomiej Filipek

From the article:

I believe "not_null" can help in many places. It won’t do the magic on its own, but at least it forces us to rethink the design. Functions might become smaller (as they won’t have to check for nulls), but on the other hand, the caller might require being updated.