传递复杂类型时的const-correctness

Question

So, I have four classes:

App - this represents the entry-point for the application

MainPage - this represents the home screen

Authenticator - this represents a helper/utility class for authentication

LoginPage - this represents a login screen.

App, MainPage, and LoginPage all have pointers to an Authenticator, and it is, in-fact, passed from App, to MainPage, to LoginPage as the user starts the app, reaches the main screen, and is prompted to log in. App creates MainPage, and if MainPage needs to log in, it creates LoginPage. The Authenticator pointer is passed at creation.

Let's say Authenticator looks something like this:

class Authenticator {
public:
   std::string GetToken() const;
   void Login(std::string username, std::string pass);
}

Now, App will create a normal, non-const pointer to Authenticator but because I don't want MainPage to be able to modify Authenticator, I want it to store a const pointer to it (ie so it can only call const member functions on it). However, I would like LoginPage to be able to call non-const member functions, like Login(), so when I pass my Authenticator from MainPage to LoginPage, I'll need to cast away the const-ness.

My question is : is it bad to do so in this situation? Should a class that is not allowed to modify an object be able to pass it to one that can? Or would it be better to have App create MainPage and LoginPage at the same time, and give them both the same Authenticator to start with? My only problem with that option is that I create a LoginPage actively, rather than lazily, and I'd prefer to do it lazily.

Thanks in advance.

Answer 1

From the Apps point of view, MainPage is modifying the Authenticator. If it's doing so directly or calling another party (LoginPage) to do it on it's behalf doesn't matter. So MainPage should get a non-const pointer and should then pass this to it's sub page for login.

If you want to make sure that your MainPage does not modify the Authenticator, you could implement a base class for it that stores this pointer and has a method to call the login dialog. The Authenticator is private, the method is protected. You can then derive your own MainPageDerived which has no (legal, non-hacky) chance to modify Authenticator but can call LoginPage if needed.

Note that I said could because for 3 classes I would think that's way overengineered. However, if you have more pages in the future, that may be a valid approach.

Answer 2

You're missing an important part of the concept of logical constness. When a class accepts a pointer (or reference) to a const object, it's promising NEVER to use the pointer/reference in a way that could modify the object. This of course means passing along to someone else who could modify it.

In other words, if MainPage is planning to ask someone to modify the Authenticator for it (that is, pass a non-const pointer to it to someone else), it's also responsible for the modifications, and should thus be storing a non-const pointer to it.

Answer 3

From an interface point of view: if you have MainPage( Authenticator const* ) , you are promessing that nothing MainPage does will modify the observable state of Authenticator . Directly or indirectly—if MainPage later passes its pointer to another class which will modify the object, you've violated the contract. Thus, in your case, it const-correctness requires MainPage( Authenticator* ) : the code constructing MainPage doesn't care whether the modifications are direct or indirect; it just wants to know what the contract is, and that it is upheld.

Answer 4

Give MainPage only what it needs. You can look at this a few ways. It could need:

• An AuthenticationTokenSource which provides an up-to-date Token .
• An AuthenticatedExectuor which performs Action s which MainPage defines, but AuthenticatedExectuor provides the authentication as it calls the Action

There are probably other ways, but those are the first that spring to mind.