In C++ consider the grammar rule:
member-access-expression
: LHS
member-access-operator
RHS
(op is .
)
andLHS
=unqualified id-expression
e.g. that references an instance variable.RHS
=qualified id-expression
(with at least one nested identifier)
example: a.b::c
If that can ever pass the semantic check, what situation would it be ?
The following experiment:
struct B{};
struct A
{
B b;
};
int main()
{
A a;
a.b::c;
}
returns
'b' is not a class, namespace, or enumeration
a.b::c;
^
(demo)
This tends to hint to me that there can't be any legal case of a qualified-id on the right of a member access.
A very simple example is if you want to call a member function of a parent class:
struct A {
void f();
};
struct B: A {
void f();
};
B b;
b.A::f();
One use case is accessing members of an enum
within some struct A
by using an instance of A
(rather than using the enum directly via A::b::c
):
struct A {
enum class b { c }; // can be unscoped as well
};
A a;
a.b::c; // Access to enum value c - similarly, A::b::c would work
Here's a trivial example:
struct A {
void f() {}
};
int main()
{
A a;
a.A::f();
}
A::f()
is a qualified version of the name for the function f
that's a member of A
. You can use it in member access just like the "short" (or unqualified) name.
In fact, one might argue that every time you write a.f()
, that's a shortcut for a.A::f()
(with the A::
part being taken automatically from decltype(a)
).
There's nothing magic about this, though it's unusual to see the construct outside of the sort of scenarios the other answerers demonstrated, because in this example it's redundant.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With