3 ms·

None of them are selling themselves as not being OOP. What they are doing is implementing an ad-hoc version of OOP that forgoes using C++'s native OO feature-s

by Kranar 6y ago

None of them are selling themselves as not being OOP. What they are doing is implementing an ad-hoc version of OOP that forgoes using C++'s native OO feature-set. Native C++ OO clashes with modern C++, often creating a dialect that does not play well with resource management and common C++ idioms. The type erasure libraries provide many of the traditional benefits of OO but allow you to retain value semantics (which native C++ OO does not). My argument was never about OO as a general concept, it was strictly that C++'s native OO feature set is very poor and modern C++ allows developers to move away from that feature set.

AnimalMuppet 6y ago
How does native C++ OO not allow you to retain value semantics? Doesn't the Rule of 3 exactly give you value semantics? And it's quite standard to do that with what you're calling "native" C++ OO.
- Kranar 6y ago
  The rule of 3 doesn't apply to C++ native polymorphic types and your statement is so far out of left field I'm guessing you don't do much C++ development. To humor you... if I have a base class of type Animal and a derived class of type Cat, then making a copy of a Cat through a pointer or reference to an Animal results in object slicing which is not what you expect when you make a copy of a polymorphic object. Basically you only end up copying the Animal instead of the entire Cat. https://en.wikipedia.org/wiki/Object_slicing https://en.wikipedia.org/wiki/Object_slicing One of the motivating reasons to use type erasure is precisely to solve this issue, so that one can copy an Animal or assign Animals and treat an Animal as a value and copies work as expected. When one copies a std::function or any of the type erased classes provided by the standard library, it just works as expected, without needing to consider lifetime issues, object slicing, C++'s complex rules about inheritance vs. virtual inheritance, and a host of other problems that don't mix well with other parts of the language. The cost of type erasure is that it requires a lot more work on the part of the author. The libraries I linked to help alleviate most of the boilerplate, but as the examples demonstrate, there's still a lot of work that needs to be done to get it right.
  - AnimalMuppet 6y ago
    > The rule of 3 doesn't apply to C++ native polymorphic types and your statement is so far out of left field I'm guessing you don't do much C++ development. First: I've done professional C++ development since 1996. Fulltime, with just a smidgen of Java in a couple of places. So your guess is completely mistaken, as is your opinion of where I'm coming from. Second: The post I replied to never mentioned "polymorphic", so I interpreted "value" as your claiming that you couldn't treat a pre-C++11 class as a value type, which is clearly a bogus claim. I do mostly embedded systems. I do use polymorphism, but most of my objects cannot be cloned (private, unimplmented copy constructor and assignment operator), and the only collection they live in is a fixed-sized array. If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method. I understand the slicing problem, and that a slice is not what you want. I confess that I don't understand how type erasure helps with the copying problem, nor how std::function uses type erasure.
    - Kranar 6y ago
      So when I mentioned the traditional benefits of OO, it didn't occur to you that polymorphism was one of them? Okay... >private, unimplmented copy constructor and assignment operator If you're using C++11 or better, then avoid doing that. In modern C++ you declare those as deleted. >If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method. This would do absolutely nothing and once again, despite you claiming to have 25 years of professional experience in C++, I must shake my head to even hear such a thing. All I get from this conversation is that you have a very antiquated idea of how to use C++ and have not kept up to date with modern standards. You mention the rule of 3, which is a pre-C++11 idiom and superseded by the rule of 5 with the advent of move constructors (or the rule of 0). Yet despite this you felt it appropriate to claim that since you personally have never encountered any recent advancement in C++ in the past decade, that it must be me who is distorting the situation. It could not possibly be the case that the C++ of today is much different from the C++ back in 1996 when you started using it, nor could it possibly be that using C++ for embedded development represents only a tiny subset of how C++ is used, or that maybe you just aren't familiar with something because no one is an expert in everything and we have to prioritize what we spend our time learning. No... the conclusion you chose to go with is that I'm distorting reality because you happen to lack any modern knowledge about a technology that you claim to have 25 years of experience with. Hate to break it to you... but it's not the 90s anymore.

by Kranar 6y ago

AnimalMuppet 6y ago

How does native C++ OO not allow you to retain value semantics? Doesn't the Rule of 3 exactly give you value semantics? And it's quite standard to do that with what you're calling "native" C++ OO.

Kranar 6y ago
The rule of 3 doesn't apply to C++ native polymorphic types and your statement is so far out of left field I'm guessing you don't do much C++ development. To humor you... if I have a base class of type Animal and a derived class of type Cat, then making a copy of a Cat through a pointer or reference to an Animal results in object slicing which is not what you expect when you make a copy of a polymorphic object. Basically you only end up copying the Animal instead of the entire Cat. https://en.wikipedia.org/wiki/Object_slicing https://en.wikipedia.org/wiki/Object_slicing One of the motivating reasons to use type erasure is precisely to solve this issue, so that one can copy an Animal or assign Animals and treat an Animal as a value and copies work as expected. When one copies a std::function or any of the type erased classes provided by the standard library, it just works as expected, without needing to consider lifetime issues, object slicing, C++'s complex rules about inheritance vs. virtual inheritance, and a host of other problems that don't mix well with other parts of the language. The cost of type erasure is that it requires a lot more work on the part of the author. The libraries I linked to help alleviate most of the boilerplate, but as the examples demonstrate, there's still a lot of work that needs to be done to get it right.
- AnimalMuppet 6y ago
  > The rule of 3 doesn't apply to C++ native polymorphic types and your statement is so far out of left field I'm guessing you don't do much C++ development. First: I've done professional C++ development since 1996. Fulltime, with just a smidgen of Java in a couple of places. So your guess is completely mistaken, as is your opinion of where I'm coming from. Second: The post I replied to never mentioned "polymorphic", so I interpreted "value" as your claiming that you couldn't treat a pre-C++11 class as a value type, which is clearly a bogus claim. I do mostly embedded systems. I do use polymorphism, but most of my objects cannot be cloned (private, unimplmented copy constructor and assignment operator), and the only collection they live in is a fixed-sized array. If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method. I understand the slicing problem, and that a slice is not what you want. I confess that I don't understand how type erasure helps with the copying problem, nor how std::function uses type erasure.
  - Kranar 6y ago
    So when I mentioned the traditional benefits of OO, it didn't occur to you that polymorphism was one of them? Okay... >private, unimplmented copy constructor and assignment operator If you're using C++11 or better, then avoid doing that. In modern C++ you declare those as deleted. >If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method. This would do absolutely nothing and once again, despite you claiming to have 25 years of professional experience in C++, I must shake my head to even hear such a thing. All I get from this conversation is that you have a very antiquated idea of how to use C++ and have not kept up to date with modern standards. You mention the rule of 3, which is a pre-C++11 idiom and superseded by the rule of 5 with the advent of move constructors (or the rule of 0). Yet despite this you felt it appropriate to claim that since you personally have never encountered any recent advancement in C++ in the past decade, that it must be me who is distorting the situation. It could not possibly be the case that the C++ of today is much different from the C++ back in 1996 when you started using it, nor could it possibly be that using C++ for embedded development represents only a tiny subset of how C++ is used, or that maybe you just aren't familiar with something because no one is an expert in everything and we have to prioritize what we spend our time learning. No... the conclusion you chose to go with is that I'm distorting reality because you happen to lack any modern knowledge about a technology that you claim to have 25 years of experience with. Hate to break it to you... but it's not the 90s anymore.