public const*char const member versus protected char*

[zosrothko]

Hi
msvc2013 emits a error on the following code
class Buffer {
public
const char* data() const;

protected:
char* data();
}

void foo() {
Buffer buffer;
string s(buffer.data(), 2);
}

msvc2013 states that buffer.data() is inaccessible.

It seems that the compiler takes the protected Buffer::data() definition while ignoring the public buffer::data() definition. Is this correct? Is this a msvc2013 bug? Remember that the string constructor is specified as string(const char*, size_t n), so it should use the public definition. Am i wrong?

Thank for any detailled explanation.

[Peter87]

It's not a bug. GCC also fails to compile this code. It doesn't matter how the string constructor is declared. What matters is that buffer is not const, which means the non-const version of data() should be called.

[zosrothko]

If I explicitly defined a member function const char* data() const, I would expect that a lookup of a const char* parameter would match this definition even if the object is no const....

What the problem in following this lookup?
Is it defined in the standard as such?
Can it be changed in the new coming standard?

[JLBorges]

Peter87 +1.

To elaborate:

> It seems that the compiler takes the protected Buffer::data() definition
> while ignoring the public buffer::data() definition.

It does not ignore the public member Buffer::data().
Both overloads public: const char* data() const; and protected: char* data(); are visible and viable.
The object buffer is non-const; and the protected member function is selected via overload resolution.


> Is this correct?

Yes. Access specifiers control access, not visibility.

In the case of overloaded function names, access control is applied to the function selected by overload resolution.
...
It should be noted that it is access to members and base classes that is controlled, not their visibility. Names of members are still visible, and implicit conversions to base classes are still considered, when those members and base classes are inaccessible. The interpretation of a given construct is established without regard to access control. If the interpretation established makes use of inaccessible member names or base classes, the construct is ill-formed. - IS

EDIT:

> Can it be changed in the new coming standard?

In theory, it can be changed. In practise it won't be changed.