It's not quite clear why go through hoops with the lambdas in the Oven example. For me it's much cleaner to have a class with a function template that forwards the call.
Agreed, I also feel like `oven_instance.do(oven_set_temperature, 212)` is a better API than `oven_instance(over_set_temperature, 212)`. Also that example felt like it went against the whole "C++ is multi-paradigm" message.
@@not_ever That implicitly has the notion of REASONABLE ways of thinking attached. Of course you can think of it in other terms too - you could break it down to the chemistry if you want - that would just be retarded. And example for "there are different approaches" should always be one that has at least in principle some benefits - or it is an example of how not to do it.
@@ABaumstumpf he EXPLICITLY stated at the beginning of the talk that things may not be best practices Also, "thinking differently" does not imply "thinking reasonable".
27:04 - at this point you have created an oven that is worse then the original one. I always find it fascinating when people come up with "But now you need to change this every time something new is added" - so? The change has to be done somewhere and having it explicitly inside my file makes it easy to maintain. It becomes easier to add other functionalities, sanity-checks and test - also you are no longer forced by the old C-style API. And it might just be the field i am working with but to me it would seem there is something seriously wrong with the program architectures and the coding approach if you constantly have to change fundamentals of your code
until ur file is 4000 lines long... I think the Open/Closed advice is mainly useful when you have like 10 engineers in the same codebase and you don't want everyone colliding all the time.
The lambda example is actually quite interesting
I have read all the books mentioned here
It's not quite clear why go through hoops with the lambdas in the Oven example. For me it's much cleaner to have a class with a function template that forwards the call.
Agreed, I also feel like `oven_instance.do(oven_set_temperature, 212)` is a better API than `oven_instance(over_set_temperature, 212)`.
Also that example felt like it went against the whole "C++ is multi-paradigm" message.
“The goal of this talk is to show you different ways of thinking about a problem”
@@not_ever That implicitly has the notion of REASONABLE ways of thinking attached. Of course you can think of it in other terms too - you could break it down to the chemistry if you want - that would just be retarded.
And example for "there are different approaches" should always be one that has at least in principle some benefits - or it is an example of how not to do it.
@@ABaumstumpf he EXPLICITLY stated at the beginning of the talk that things may not be best practices
Also, "thinking differently" does not imply "thinking reasonable".
This dude actually decided not to use any syntax highlighting for those walls of text...
This felt like a back to basics talk. Does anybody know why it wasn't marked as such? Did it not make it into the track?
what does that mean?
Why would this be a back to basics talk?
27:04 - at this point you have created an oven that is worse then the original one.
I always find it fascinating when people come up with "But now you need to change this every time something new is added" - so? The change has to be done somewhere and having it explicitly inside my file makes it easy to maintain. It becomes easier to add other functionalities, sanity-checks and test - also you are no longer forced by the old C-style API.
And it might just be the field i am working with but to me it would seem there is something seriously wrong with the program architectures and the coding approach if you constantly have to change fundamentals of your code
until ur file is 4000 lines long... I think the Open/Closed advice is mainly useful when you have like 10 engineers in the same codebase and you don't want everyone colliding all the time.