Marvelous job done by Amir, In inheritance he is explaining a subtle concept of keeping OO performant, especially with state pattern. I am already thanking him for real thought behind state pattern.
For quite a long time I thought of a state pattern as something that is quite verbose and to be used in "complex" frameworks and/or libraries whatever. But now it makes so much more sense to me to use it my daily code.
12:00, Wouldn't it better if the compiler just assumes initialisation to 0 is fine unless it finds a matching constructor for what is presented to it, for instance: class X { char const* m_say; public: X( char const*say ) { m_say = say; } char const* talk() { return m_say; } }; ... X a = X("Hello world!"), b = X(); puts( a.talk() ); puts( b.talk() ? b.talk() : "(null)" ); Would produce: Hello world! (null) While this: class X { char const* m_say; public: X() { m_say = "Goodbye :)"; } X( char const* say ) { m_say = say; } char const* talk() { return m_say; } }; ... X a = X("Hello world!"), b = X(); puts( a.talk() ); puts( b.talk() ? b.talk() : "(null)" ); Would produce: Hello world! Goodbye :)
54:55, Alternative more reliable solution: class Pet { ... Pet( PetType &type ) { ... } operator= ( PetType &type ) { ... } ... } If they make the mistake of using the pet type as a pet the managing class should just accept it and construct itself with empty data or override an existing type
24:39 Why would i want to lock a mutex in a method that is const? Wouldn't that be a read only operation by default which does not need synchronization?
No mention of class invariants. Does not mention that members should be public if there are no invariants. Has a Point class with private members, even though there are no invariants.
