The rule of the [3] 4: swap

Object oriented programming focuses on bundling together the data with the operations that can be applied to them. Access specifiers allow you to control the invariants of the type, and deterministic destruction of objects provides the glue that makes management of all types of resources.

But homogeneous does not mean trivial, and attention has to be paid. In a language with exceptions special care needs to be taken so that resources don't leak, but resources are not the only problem, when we model a domain, we need to maintain the invariants on top of which our algorithms are built.

Dynamic dispatching to template functions

As in the first post I wrote, less than a month ago, this time I am going to visit another stackoverflow question. The user has a template parametrized by a template argument and wants to write a non-templated function that takes an integer argument and will
dispatch the call to the appropriate template.

Value semantics: Copy elision

In the last post we discussed Named Return Value Optimization and one case of copy elision when constructing a variable from an rvalue expression.

But copy elision is not limited to those particular use cases. The question is where else can we take advantage of this optimization, and where the compiler will not be able to optimize away the extra copies.

Value semantics: NRVO

C++ is a language with value semantics. It was designed so that user defined types will behave in the same ways that primitive types do. This offers advantages, but also imposes burdens on development: programmers have to implement those semantics, and it also falls in the programmers to decide how parameters are passed in and out of functions and the impact that has.

With the language being designed with value semantics in mind, you would imagine that some optimizations are in place to avoid unneeded processing. In this category you can find things like [Named] Return Value Optimization, or copy elision in the current standard, or move semantics in the upcoming C++0x. Understanding what they mean, and when the compiler can or cannot apply them will improve efficiency and readability in the code.

Operator overloading, OO the C++ way

If you question around about a mainstream object oriented language, most people will point to Java, or C#. Sure that C++ has classes, and objects, inheritance, polymorphism... but it's not really object oriented, there are still non-member functions, and that is just so no-OO. Or is it?

Implementating vs. understanding

Solving a problem and actually understanding what the problem is do not always go hand by hand. Many times not just the problem eludes understanding, but even the solution we just wrote.

Improving conversions of std::pair<T,U>s

As we already saw, even if the implementations are more permisive, the standard mandates that conversions from std::pair<> types should use only implicit conversions. That solves only half of the problem: when two types are implicitly convertible, then std::pair<> containing those types are also implicitly convertible.

But what about explicit conversions? Do we need to fail there? It would seem appropriate if, given two types that are explicitly convertible, we allowed explicit conversions of the std::pair.

Conversions of std::pair<T,U>s

I decided to start writing a few months ago, but I never actually committed to it. Then I decided a few days ago that I was actually going to do it, and I have spent the last few days trying to decide what would be a good first post. I am still undecided. But today I read an interesting question in StackOverflow, and decided to write about it.

The problem Rafał has is with implicit conversions. In his application he has two types that are convertible, but only explicitly convertible. He is surprised that an std::pair<>that contains one of those types is implicitly convertible to a std::pair<> of that contains the second type.