> The class acts as the place to hold the parameters needed for it and the result if/when it is computed. There's nothing wrong with that.
Right, and the constness problem can be overcome by making some fields mutable. This is exactly what "mutable" is for.
If the requirement is to have a lazy, memoized computation, then a class is good. If the requirement is to have an eager, non-memoized computation, a function is good. The article keeps shifting the goalposts and beating strawmen that implement different specifications. It's not very good at making the point it thinks it's making.
Mutable in C++11 land holds a weird space because the threading model says that const member methods are thread safe, which mutable member variables are not.
> A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this
Consider the case where I invoke `std::find_if`. It takes const iterators to a std::vector. I'm now indirectly modifying objects through standard library functions that are modifying objects by multiple threads through const arguments.
Pretty sure this is a viral requirement and using any part of the STL can effectively taint your program if you're not careful.
> A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this
Consider the case where I invoke `std::find_if`. It takes const iterators to a std::vector. I'm now indirectly modifying objects through standard library functions that are modifying objects by multiple threads through const arguments. Using a mutex doesn't change the fact that my usage of the STL is now in undefined behavior land.
I think the only safe thing to do is to have a mutable mutex (there may be other parts of the legalese) but outside of that you may run into serious trouble at some point compilers become intelligent enough to enforce that undefined behavior. Realistically I doubt any compiler would ever enforce that legalese because of how const & mutable both are interpreted to mean "this variable is thread-safe" by everyone involved so a mutable variable that is synchronized in some way will always work fine.
Right, and the constness problem can be overcome by making some fields mutable. This is exactly what "mutable" is for.
If the requirement is to have a lazy, memoized computation, then a class is good. If the requirement is to have an eager, non-memoized computation, a function is good. The article keeps shifting the goalposts and beating strawmen that implement different specifications. It's not very good at making the point it thinks it's making.