stlfilt helps, but it doesn’t always save you from template hell.
comaofferimagegeneratorlib.cpp:149: cannot convert `it.Mdbm<_comaofferid ,ImageData *>::iterator::operator ->()-> pair::key_type, Mdbm<_comaofferid ,ImageData *>::data_type>::second' from type `Mdbm<_comaofferid ,ImageData *>::data_type' to type `ImageData *'
It’s not impossible to interpret this, but it isn’t exactly a walk in the park either.
It’s times like these that make me appreciate the utter simplificity of Java and its container classes – by making every object inherit from a common base class (Object) and making containers that contain references to objects of that base class, you get a simple, elegant container mechanism. C++, not having a common base class, resorts to templates – a nifty but sometimes very irritating feature.
Are they evil??? Nothing prevents someone writing C++ code to have their own java.lang.Object equivalent. And, using templates and single rooted object hierarchies have nothing to do with each other, at least not in this context.
Everybody knows the cost in terms of type safety that we pay when using heterogeneous containers in Java… the same cost that we pay with a dynamic_cast in C++ when using a heterogeneous container with a single rooted object hierarchy.
And I think the Comparable interface is a nuisance, when you could write a b). But it is a nuisance Java programmers put up with because it is a well documented nuisance.
that should have been a < b (or a > b)