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.
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
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 :)
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.
![[MUC++] Klaus Iglberger - "Embrace No Paradigm Programming!"](http://i.ytimg.com/vi/fwXaRH5ffJM/mqdefault.jpg)
![[LIVE] : ONE ลุมพินี 76 | คู่เอก "ผึ้งหลวง vs สมิงดำ"](http://i.ytimg.com/vi/9SBshmGQOIM/mqdefault.jpg)
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.
One of the best OO talks/resources I've ever seen so far. Simple yet powerful in some sense. Absolute gem.
Really? I'm half way in and it's nothing to do with Oop, just general cpp knowledge about construction and destruction.
Is this for begginers or uberadvanced stuff for no less than phds?
brilliant
That was a damn good talk.
Excellent video.
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
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 :)
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?
you dont want the value to change while you are reading it
32:25, if you're bringing culture into it then in japan cats would go nya, not meow
Thank you, noted
I’m I able to access these slides? He has a reference concerning “padding” at 7:20 which I’ll like to read more about
Here it is:
docs.google.com/presentation/d/1t7dhyXHfFfNEEiUSC6rhznyKXkThcLQhlQJdv57M7mI/edit?usp=sharing
37:00, bad example as all squares are rectangles but not all rectangles are squares which means square would inherit from rectangle
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.
Guy speaks too fast, that thick accent doesn’t help either.
I had no problems listening to him at x1.5 speed