C++ class namespace weirdness

Question

I have a C++ class using Core Audio structs on OS X. My initial implementation was like this:

class MyClass
{
private:
    AUNode _converterNode;
    AURenderCallbackStruct _renderCBStruct;

public:
    MyClass();
    ~MyClass();

    inline AUNode* getConverterNode() { return &_converterNode; }
    inline AURenderCallbackStruct* AURenderCallbackStruct() { return &_renderCBStruct; }
};

After reading the Poco style guides, I wanted to change the order of the private/public blocks. It then looked like this:

class MyClass
{
public:
    MyClass();
    ~MyClass();

    inline AUNode* getConverterNode() { return &_converterNode; }
    inline AURenderCallbackStruct* AURenderCallbackStruct() { return &_renderCBStruct; }
private:
    AUNode _converterNode;
    AURenderCallbackStruct _renderCBStruct;
};

The compiler now tells me that the type AURenderCallbackStruct is unknown and tells me to replace the type name with ::AURenderCallbackStruct . When I do that, there are no compiler errors. Weirdly, this only appears for the `AURenderCallbackStruct and not the AUNode.

The AURenderCallbackStruct is defined like this:

typedef struct AURenderCallbackStruct {
    AURenderCallback            inputProc;
    void *                      inputProcRefCon;
} AURenderCallbackStruct;

and AUNode is defined like this:

typedef SInt32  AUNode;

Can anyone explain why the change of order of private/public block produces a compiler error and why the error disappears when adding a :: in front of the type?

Answer 1

First of all it is not clear why you named the member function as AURenderCallbackStruct that coincides with the corresponding structure's name and looks like the structure constructor. The problem is this stupid name.

in the first case the compiler thinks that you indeed define the member function that hides the corresponding name of the structure. In the second case the compiler thinks that you trying to call the constructor of the structure.

Simply rename the function that there would not be an ambiguity.