I'm dusted off a file-reading class I'd been working on earlier, which implements some comfort features and iterators. Since the class doesn't modify the file it's being given but only its own internal (book keeping) state, I decided to use the mutable keyword and make the entire public interface const.
What's your opinion on doing that? Is it elegant or misleading? I feel that the user would prefer to use const methods, giving them a sense of read-only access to the managed resource.
Do any of the member functions change the observable state of the object? If not, then having them be const and using mutable for the internal book keeping state is precisely what mutable is for.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
I don't think they do.
So in this case the std::ifstream is affected by seek/read operations, but no other class member is touched. Would that be an appropriate use of mutable/const?Code:// simplified std::string MyClass::operator[](size_t index) const noexcept { std::string output; // use this->std::ifstream member to fill "output" return output; }
Last edited by Guest; 04-30-2016 at 04:21 AM.
In this case, I'd say it's a good use of mutable/const.
Question to ask oneself: If I repeatedly call this function on the same object, will I get back the same result every time? If so, then the observable state of the object hasn't changed (to me). Hence, you should consider using const there.
Right. I also give access to- and overload std::ifstream::read through the public interface, and that function requires manual seeking and/or eofbit clearing to behave identical each call, so I won't mark it const then.
