To make it short, what do you think does the following program print?

#include <iostream>

struct X { };

class Y {
public:
    Y (const X& x) {
        std::cout << "fnord" << std::endl;
    }
};

int main() {
    Y o(X());
    return 0;
}

At first sight it looks like everything is ok. We know that references to temporaries must be const, which is the case here. So we think, o is going to be a Y object which was initilized with a temporary X object. In this case, the program should output "fnord".

But it doesn't. Instead it prints nothing. Mysterious you think? So did I. So I started debugging the issue while Roker was giggling. So, if o is not a Y object, what is it then? Let's ask the compiler and the C++ runtime:

#include <typeinfo>
//...
int main() {
    Y o(X());
    std::cout << typeid(o).name() << std::endl;
    return 0;
}

The program now prints "F1YPF1XvEE". Hmm, I can not decrypt this, can you? We need to demangle the name in order to see it's real C++ nature:

$ c++filt -t F1YPF1XvEE
Y ()(X (*)())

Who can decrypt this? If you can't, here is a howto on reading C type declarations, because the unfamiliar syntax for function types is a C heritage. And what does this type mean after all? It means, that d is a pointer to a function which returns a Y object and expects a pointer to a function which returns a X object and expects nothing. Got it? If not, here is how I would write it, in case I would need such a type:

#include <iostream>
#include <typeinfo>

struct X { };
class Y { /*...*/ }; 

typedef X (Inner)();
typedef Y (Outer)(Inner);

int main()
{
    Outer o;
    std::cout << typeid(o).name() << std::endl;
    return 0;
}

Ok, so now we know, what the program does. It instantiates a variable of type pointer to function whatever. That's why there is no X object ever created. So, although the code could mean what we originally intended, the compiler chooses to understand something else, which is also possible due to the C syntax rules. And what's the C way of removing ambiguity from syntax? Right, it's braces:

//...
int main()
{
    Y o((X()));
    std::cout << typeid(o).name() << std::endl;
    return 0;
}

To sum it up, this is yet another example for why I consider the C heritage to be a major source of trouble for C++ developers. The C syntax was never designed for temporary variables and combining both yields to what we have seen here: ambiguity, ugly workarounds and surprise and furstration for the developer. Don't get me wrong, though. I still think that C++ could hardly have been made better given the design goals which where taken those days. I truly have a love-hate for that language.

Today he pointed me at Cay Horstmann's list of C++ pitfalls. Some of the issues have already been covered here but some haven't. I recommend reading it to every C++ developer as this takes less time than learning it the hard way by debugging code. Have fun.

Concerning the iterator issues Cay provides a Safe STL implementation which is supposed to be used as a drop in replacement for the STL during development. It adds state and knowledge about the owner to iterators and uses this information to do runtime checks. If you accidently use your iterators in a wrong way you end up with a comprehensive runtime error instead of a segfault "deep in the bowels of STL code".

I haven't tested Safe STL. If anybody did feel free to send me your experience. I would be glad to blog about it.

Roker pointed me to an article about the safe bool idiom where the author elaborates on why a simple operator bool is not satisfying if you want to be able to use an object within a bool context. Have fun...

Today Roker pointed me to a poor guy from #c++@freenode with the following problem:

#include <iostream>
#include <list>

typedef std::list<int> list_t;

list_t::const_iterator find_first_odd(const list_t & list)
{
  for (list_t::const_iterator i = list.begin(); i != list.end(); ++i)
  {
    if (*i % 2 != 0) return i;
  }

  return list.end();
}

int main()
{
  list_t list;
  list.push_back(2);
  list.push_back(3);
  list.push_back(4);

  list_t::const_iterator odd_i = find_first_odd(list);

  if (odd_i != list.end())
    // Error. Can not use const_iterator with 'std::list::erase'
    list.erase(odd_i);

  return 0;
}

For the sake of const correctness the function find_first_odd expects a constant reference to the list because it is not going to modify it. But as a result the function can only return a const_iterator, because there is no way to get a non-const iterator from the constant list.

So the caller of find_first_odd ends up with a const_iterator which is useless for modifying operations such as erase. And for him it is also impossible to turn the const_iterator into a non-const iterator. The two types have no relation to each other, so casting does not work. And there are no conversion functions in the STL either. So the only way out here is to sacrifice const correctness and pass a non-const reference to find_first_odd.

According to Roker nobody on #c++ had a better solution. And according to Scott Meyers' article Three Guidelines for Effective Iterator Usage there is none. const_iterators can not be easily transformed into iterators. What you can do is nasty and rather inefficient.

Here it comes:

template <class Container>
typename Container::iterator convert(typename Container::const_iterator in, Container& container)
{
    typename Container::iterator out(container.begin());
    std::advance(out, std::distance<typename Container::const_iterator>(out, in));
    return out;
}

But there are others who blog about C++. So I will be satisfied with passively following the C++ topic and refering to them.

Today's featured C++ blog is C++ thruths from Sumant Tambe. Hmm, infinite regress, yummy. ;-)

Thank you Roker

[the C++ 0x standard will be] the longest suicide note in history.

Other languages do better. Python 3.0 and Perl 6 are not downward compatible and in both cases I think this is a good idea. Why is this impossible for C++?

Links zu den Folien und den Aufzeichnungen gibt es hier.

It's a WordPress, so I am leaving the nanoblogger paradigm of static page content. What I can get is interaction through reader comments and trackbacks. But I'm also a target for spam and crackers now. We'll see...

Anyway, here is copton's ETH blog. For the time being new posts will go there.

Although some things are different with C++, I recommend everybody to read at least the report. Otherwise you surely will stumble on those items sooner or later.