Back to Basics: Object-Oriented Programming in C++ - Amir Kirsh - CppCon 2022

---

Back to Basics - Object-Oriented Programming in Cpp - Amir Kirsh - CppCon 2022

C++ is not just an Object-Oriented Programming Language, it supports many paradigms. But in this session we would focus on the object oriented aspects of C++, from encapsulation to inheritance and polymorphism.

The session aims to cover the basic syntax together with best practices, tips, pitfalls to avoid and more. We would discuss design considerations, the advantages and disadvantages of different approaches and other alternatives that the language provides. Some relevant design patterns may also pop-by.

This session is part of the Back to Basics track and is aimed for novice and intermediate C++ developers (up to about 2-3 years of C++ coding experience). More experienced developers are of course welcomed to join and enrich the discussion with their knowledge and experience.
---

Amir Kirsh

C++ lecturer at the Academic College of Tel-Aviv-Yaffo and Dev Advocate at Incredibuild. Previously the Chief Programmer at Comverse. Co-organizer of Core C++ conference and a member of the Israeli ISO C++ NB. Currently a visiting researcher at Stony Brook University, New-York.
---

#cppcon #programming #cppprogramming

[Nikage]

One of the best OO talks/resources I've ever seen so far. Simple yet powerful in some sense. Absolute gem.

[alidanish]

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.

[TheJackal]

Is this for begginers or uberadvanced stuff for no less than phds?

[zxuiji]

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 :)

[zxuiji]

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

[zeez]

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?

[eddyecko]

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

[zxuiji]

32:25, if you're bringing culture into it then in japan cats would go nya, not meow

[zxuiji]

37:00, bad example as all squares are rectangles but not all rectangles are squares which means square would inherit from rectangle

[MalcolmParsons]

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.

[kevinzebb]

Guy speaks too fast, that thick accent doesn’t help either.