Writing simple understandable code is much better than trying to achieve perfection. I don’t agree with the philosophy of this talk, but I enjoyed the fancy ideas.
While that was interesting, it also made it clear to me that Francesco Zoffoli deals with a very different set of problems then I do. I can only think of a handful of places where this sort of added scaffolding would apply in my codebase, and those cases are already handled perfectly well by simple base* and runtime polymorphism. In essence, this seems very applicable to the sort of work one might do at Facebook; building behaviours that you expect other people to assemble like lego. I'm not convinced that the complexity overhead would be worthwhile for many smaller scale/less reusable projects (especially in my case where dependency on an external library already creates inherent coupling between many procedures and data structures).
I did some experimentation, and yes, a factory that returns a unique_ptr is more versatile if you want to use a unique_ptr on the client side of things. As a unique_ptr - R value can be assigned to a unique_ptr L-value. And a shared_ptr L-value can be assigned from a unique_ptr - R value.
The factory whose given solution was to use a shared pointer.... it's just bad. The example was clearly bad designed, if the bufffilereader needs a buffer, he basically needs to own it, and hence to take a unique_ptr through a move. If he doesn't then a reference to the unique_ptr is fine (and then someone else has to own it, thus why instanciating in the clojure?). Last but not least, if bufffilereader interface supports legacy code via raw pointers, then a simple release() of the unique_ptr was sufficient.
Reference member variables are usually a bad idea, I don't understand why the presenter recommends them. They remove default copy and move assignment. Storing raw pointers has identical utility and no such drawbacks.
In my experience, any class that has pointers and references to other complex functional objects (not just data) is not something that should be copied and doesn't need to. And something that holds data should not and really doesn't need any access to (polymorphic) behaviors and has simple constructors. So, removing something you shouldn't have anyway is a good thing. Many programming languages nowadays start out with "data classes" or "record" etc
"You don't need to have everything as classes to use dependency injection"
THANK YOU. I wish this were known more widely.
The way to explain interactions with geometrical figures is so clear and smart that should be used constantly in lessons, thanks!
Writing simple understandable code is much better than trying to achieve perfection.
I don’t agree with the philosophy of this talk, but I enjoyed the fancy ideas.
great talk
Very nice talk.
Amazing!
While that was interesting, it also made it clear to me that Francesco Zoffoli deals with a very different set of problems then I do. I can only think of a handful of places where this sort of added scaffolding would apply in my codebase, and those cases are already handled perfectly well by simple base* and runtime polymorphism.
In essence, this seems very applicable to the sort of work one might do at Facebook; building behaviours that you expect other people to assemble like lego. I'm not convinced that the complexity overhead would be worthwhile for many smaller scale/less reusable projects (especially in my case where dependency on an external library already creates inherent coupling between many procedures and data structures).
I am also curious about this. How are these things useful on a smaller scale.
shared_ptr has constructor from unique_ptr, there's no point in returning shared_ptr from factory
As long as it is R-Value. Yes. That is correct. But will that make any difference?
I did some experimentation, and yes, a factory that returns a unique_ptr is more versatile if you want to use a unique_ptr on the client side of things. As a unique_ptr - R value can be assigned to a unique_ptr L-value. And a shared_ptr L-value can be assigned from a unique_ptr - R value.
The factory whose given solution was to use a shared pointer.... it's just bad. The example was clearly bad designed, if the bufffilereader needs a buffer, he basically needs to own it, and hence to take a unique_ptr through a move. If he doesn't then a reference to the unique_ptr is fine (and then someone else has to own it, thus why instanciating in the clojure?). Last but not least, if bufffilereader interface supports legacy code via raw pointers, then a simple release() of the unique_ptr was sufficient.
Hm, why no type erasure? Its what you need
Reference member variables are usually a bad idea, I don't understand why the presenter recommends them. They remove default copy and move assignment. Storing raw pointers has identical utility and no such drawbacks.
In my experience, any class that has pointers and references to other complex functional objects (not just data) is not something that should be copied and doesn't need to.
And something that holds data should not and really doesn't need any access to (polymorphic) behaviors and has simple constructors.
So, removing something you shouldn't have anyway is a good thing.
Many programming languages nowadays start out with "data classes" or "record" etc
Utterly inscrutable talk. No concrete example whatsoever; all abstract talk.
Agreed .. pathetic
Title should be like "How to speed down compile time 100x"
Man the constant clicking noises he makes with his mouth is so annoying