5 ms·

Single-function classes make sense if you want the computation to happen lazily on-demand (it may be resource-intensive in CPU, GPU, storage, I/O, etc). The cla

• kstenerud 6y ago
  Yup. As in everything, the INTENT is very important when judging someone's code. Unfortunately, this makes it very easy to set up strawmen, then add a click-baity title for the perfect gift for "your side".
• tom_mellior 6y ago
  > 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.
  • vlovich123 6y ago
    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.
    • steerablesafe 6y ago
      Yes, access to mutable members should be synchronized in const methods.
      • vlovich123 6y ago
        > 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.
    • gpderetta 6y ago
      > threading model says that const member methods are thread safe that's only true for standard library objects, although it is an useful guideline for all code.
      • vlovich123 6y ago
        I don't think that's true. > 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.
• noobermin 6y ago
  Finally, the first real example. Every single one so far has been pretty weak.
• josephcsible 6y ago
  Using classes and objects for laziness is a hack to work around the limitations of OOP. In more functional languages, there are better ways to accomplish that. For example, in Scala, you can just use "lazy val", and in Haskell, everything's lazy by default.