In this code:
while(k != listeners.getLength()) {
if(listeners[k] != nullptr) {
listeners[k]->onNewMessage(*newMessage);
}
k++;
}
The compiler does not like the ->
at all.
listeners[k]
is a class with an operator->()
that is both public and defined, returning a reference to a type with a (virtual) method onNewMessage
.
Changing it to:
while(k != listeners.getLength()) {
if(listeners[k] != nullptr) {
listeners[k].operator ->().onNewMessage(*newMessage);
}
k++;
}
works.
It used to work. I added some boolean operators (==
and !=
to the type returned by reference of listeners[k]
). I also added a constructor for a ::std::nullptr_t
type. I can't see any reason why these would cause a problem, and the error mentions no ambiguity so it's not that it has too many options.
Why is there a problem here?
Addendum
To clarify the structure is as follows:
List<PtrWrapper<LogListener>> listeners;
T& List<T>::operator[](int);
and a const definition to go with it.
T& PtrWrapper<T>::operator->();
and a const version to go with it.
LogListener
has a virtual method onNewMessage
.
So listeners[k]
is a PtrWrapper<LogListener>&
.
The operator->()
is a bit of an odd-ball: although it can return a non-pointer type, the resulting type would need to overload the operator->()
, too! Basically, when the compiler sees a use of an overloaded operator->()
it will keep applying operator->()
s until the result is a pointer. Once a pointer is obtained, it knows how to access the corresponding member.
It is an error if repeated application of operator->()
leads to a non-pointer type which doesn't overload operator->()
.
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