When both and public private method have the same name and differ by their
const-ness, a compilation error may result.

For example, adding to the binding tutorial:

http://developer.qt.nokia.com/wiki/PySide_Binding_Generation_Tutorial%3A_Binding_libfoo_using_Shiboken

Let me add two very similar methods:

class Math : public QObject
{
    Q_OBJECT
public:
    Math() {}
    virtual ~Math() {}
    int squared(int x);

    const Math* ptr() const { return this; }
private:
    Math* ptr() { return this; }
};

That is, I have added two ptr() methods, one public that is const and one
private that is not const. Leaving everything else the same with the tutorial,
results in the following compilation errors:

../libfoo/foo.h: In function ‘PyObject* Sbk_MathFunc_ptr(PyObject*)’:
../libfoo/foo.h:16:11: error: ‘Math* Math::ptr()’ is private
foo/foo/math_wrapper.cpp:292:55: error: within this contex

The generated code may be summarized as:

Math* cppSelf = 0;
...
const Math * cppResult = cppSelf->ptr();

Note that since cppSelf is a non-const pointer, the compiler chooses to call
the non-const method, namely the private version. That call, of course, results
in a compilation error. However, if I manually change cppSelf to be a const
pointer, everything compiles just fine.

So, I believe when a method is declared const, a const pointer should be used
for invoking all methods to avoid inadvertently calling a non-const method,
which can lead to compile errors.

The obvious workaround in the meantime, is to change the name of the private
method and to change the source code appropriately. However, sometime one does
not have access to the underlying source code.

One final note, this bug may be very distantly related to bug 42, which has
been closed. At the very least, a unit test could be added in the same place.