I have Polymorphic Behavior when I need Type Erasure. Also ALL OO Base Classes should have Virtual Destructor? Either a Public Virtual Base Destructor or a Protected Non-virtual Destructor if you don't want delete through pointer to base, or don't want to delete at all (think RAII IO Types). I would rather you didn't dynamically allocate my InputStreams, but if you do, I don't want you deleting it through a pointer to InputStream*.
connor horman Wrt to virtual destructor i was deliberately omitting situations without heap allocation or exclusively using shared_ptr, because you can not control what people using the hierarchy are doing with it. Understanding and following those limitations is expert-level expertise, as is implementing type erasure. Note that many safety critical systems disallow using the heap after initialization.
4:30, I disagree about references and string_view. To me, they have been easy-to-use. I would put them on safe and sane. Pointers I would put on the middle-to-high discipline. 6:05, I think a pointer should not travel across f()s, replacing a reference, nor manage memory directly. But there's plenty of use for them locally, for optimization (flexible, faster) or as iterators managing an object members, for instance. 8:04, being "yes or no", that assertion will always be false.
thanks for the reupload!
I have Polymorphic Behavior when I need Type Erasure. Also ALL OO Base Classes should have Virtual Destructor? Either a Public Virtual Base Destructor or a Protected Non-virtual Destructor if you don't want delete through pointer to base, or don't want to delete at all (think RAII IO Types). I would rather you didn't dynamically allocate my InputStreams, but if you do, I don't want you deleting it through a pointer to InputStream*.
connor horman
Wrt to virtual destructor i was deliberately omitting situations without heap allocation or exclusively using shared_ptr, because you can not control what people using the hierarchy are doing with it. Understanding and following those limitations is expert-level expertise, as is implementing type erasure. Note that many safety critical systems disallow using the heap after initialization.
4:30, I disagree about references and string_view. To me, they have been easy-to-use. I would put them on safe and sane. Pointers I would put on the middle-to-high discipline.
6:05, I think a pointer should not travel across f()s, replacing a reference, nor manage memory directly. But there's plenty of use for them locally, for optimization (flexible, faster) or as iterators managing an object members, for instance.
8:04, being "yes or no", that assertion will always be false.
I like undefined behavior... you never know WHAT you’re gonna get! 🤪
more room for optimization, that's for sure 😊