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.
[Un]defined behavior
Thursday, September 8, 2011
The rule of the [3] 4: swap
Wednesday, August 17, 2011
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.
dispatch the call to the appropriate template.
Wednesday, August 10, 2011
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.
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.
Wednesday, August 3, 2011
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.
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.
Thursday, July 28, 2011
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?
Labels:
C++,
free function,
interface,
member function
Saturday, July 23, 2011
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.
Thursday, July 21, 2011
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
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<>
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
.
Subscribe to:
Posts (Atom)