Klaus Iglberger is a great presenter, passionate about his topic. He is able to explain simply very complex concepts, with humility and passion. thanks for the great talk and explanation. You convinced me design patterns matter !
Another great talk by Klaus Iglberger! I really appreciate Klaus's effort to promote the design and architecture focus in the C++ community. I believe those who are interested can find much deeper and wider information about how to break dependencies from his C++ design book.
Great talk! Regarding singleton, note that its definition in 53:30 is more focused on “ensuring one instance” than on “providing an interface to an object without passing it around”. As Klaus says, if the book wasn’t written in the 90s perhaps the notion would have been implemented differently. For example, consider a singleton who’s instance() method returns a move-only (perhaps unique-ptr to an) object, that gets moved from “one global place” and can be further moved around (and perhaps moved back to the global location when not needed) - ensuring a single instance, but eliminating parallel use. I think in some cases this “move-only” approach for singleton can be a reasonable design choice for objects representing physical (non-fungable?) entities, which lends itself to dependency injection if needed.
I agree, but I'm still glad the question was asked. It made me realize that, while the solution presented for implementing Singleton does break dependencies, it also introduces a new failure point (calling get() before the first set()) that is somewhat harder to prevent. The traditional Singleton that relies directly on a concrete type doesn't have that failure point. So it's a trade-off. To delve deeper into the topic (even if not relevant to the point of the talk): in the usual case where the Singleton concrete type won't change at runtime after the start of the program, then a compile-time or link-time solution should also be considered. It would avoid the failure point, and would also avoid the added cost of virtual functions, which are not useful in this case.
@Stefan Asbeck: Agree, I think the question mixed up 2 problems: The global initialization order and The singleton. Once global objects start depending on each other, it has become a serious problem on its own, and there is nothing to do with the Singleton. I think the reason for the mixing here could be that Singleton introduces more hidden dependencies, which makes the problem appear easier.
"High quality software: easy to change, easy to extend, easy to test." None of those things matter to a user. High quality software performs the expected functions with high performance, low latency, and good UI/UX.
Klaus Iglberger is a great presenter, passionate about his topic. He is able to explain simply very complex concepts, with humility and passion.
thanks for the great talk and explanation. You convinced me design patterns matter !
Another great talk by Klaus Iglberger!
I really appreciate Klaus's effort to promote the design and architecture focus in the C++ community.
I believe those who are interested can find much deeper and wider information about how to break dependencies from his C++ design book.
Great talk! Regarding singleton, note that its definition in 53:30 is more focused on “ensuring one instance” than on “providing an interface to an object without passing it around”. As Klaus says, if the book wasn’t written in the 90s perhaps the notion would have been implemented differently. For example, consider a singleton who’s instance() method returns a move-only (perhaps unique-ptr to an) object, that gets moved from “one global place” and can be further moved around (and perhaps moved back to the global location when not needed) - ensuring a single instance, but eliminating parallel use. I think in some cases this “move-only” approach for singleton can be a reasonable design choice for objects representing physical (non-fungable?) entities, which lends itself to dependency injection if needed.
This is why I despise Agile, because too many companies treat it as a license to just plunge into coding with little thought to design.
The question at the end completely missed the point of the talk.
I agree, but I'm still glad the question was asked. It made me realize that, while the solution presented for implementing Singleton does break dependencies, it also introduces a new failure point (calling get() before the first set()) that is somewhat harder to prevent. The traditional Singleton that relies directly on a concrete type doesn't have that failure point. So it's a trade-off.
To delve deeper into the topic (even if not relevant to the point of the talk): in the usual case where the Singleton concrete type won't change at runtime after the start of the program, then a compile-time or link-time solution should also be considered. It would avoid the failure point, and would also avoid the added cost of virtual functions, which are not useful in this case.
@Stefan Asbeck: Agree, I think the question mixed up 2 problems: The global initialization order and The singleton.
Once global objects start depending on each other, it has become a serious problem on its own, and there is nothing to do with the Singleton.
I think the reason for the mixing here could be that Singleton introduces more hidden dependencies, which makes the problem appear easier.
"High quality software: easy to change, easy to extend, easy to test." None of those things matter to a user. High quality software performs the expected functions with high performance, low latency, and good UI/UX.
What you described is a high quality product in my point of view.
You are right,but how to achieve it? The video is just one of the ways