04.06.2016, 18:10, "charleyb123 ." <charleyb...@gmail.com>: > I won't be active in this thread, because IMHO this is the stuff of legends: > We are about to usher in a new decade of flame wars for all of C++ with this > topic (and these wars are underway in other C++ communities outside Qt). > > However, I want to chime-in here for Qt, and then I'll not be active on this > thread (but I will lurk). > > C++ is a value-semantics stack-based language, where heap allocations demand > that the developer (and the system design) manage object lifecycle. This is > different from reference-based languages like C# or Java that have garbage > collection. > > This means that in C++, the act of "Design", or even the act of "Software > Development" is: > > (1) Decide what objects exist (e.g., types-and-instances) > (2) Decide who owns them (e.g., object-lifecycle) > > There is no (3). > > Yes, the following idiom is currently being marketed to the C++ community: > > auto f = std::make_shared<Foo>(...); > > This is to free the developer from considering implications of (2).
I disagree, (2) is still present as the choice of make-function. It's up to you to decide if it will be Foo(...), std::make_shared<Foo>(...), std::make_unique<Foo>(...), or something else. > However, there are real-world consequences. > > This is a highly precarious design pattern at scale. This is the new "goto". > Without sufficient discipline within the design to explicitly manage > lifecycles, this is the equivalent of a "global" instance of unknown duration > and unknown mutation across threads, arbitrarily, without any controls. > > It is a very dangerous design decision. Who else is accessing the object > behind your shared pointer? Are they all properly participating in the link > count? Is another thread modifying the object while you are reading? Are > you sure? How will you debug when you find out you were wrong? > > Qt's historic model is parent-ownership, and if no parent, then the developer > explicitly manages ownership with "QObject::deleteLater()". There are other > patterns, and indeed within Qt, you are encouraged to use these mechanisms > within your higher-order patterns. For example, you are free to put your > "custom-deleter" within your "std::shared_ptr<>" or "std::unique_ptr<>". > > However, injecting "std::shared_ptr<>" and "std::unique_ptr<>" ubiquitously > through an API and library will go down in history as one of the biggest > design mistakes in C++, precisely because attention to (2) above should be > more explicit within the system design. IMHO, a C++ developer cannot be > forgiven inattention to that detail. > > If you want to scale, the C++ developer must do both (1) and (2). > > I concede that for small projects, scaling is not an issue. Yet. > > --charley > > On Sat, Jun 4, 2016 at 7:14 AM, Nye <kshegu...@gmail.com> wrote: >> Hello, >> Since this is opinion based I will give my opinion without explicitly >> stating it's just a personal view on the subject on every line. >> >> On Sat, Jun 4, 2016 at 3:55 PM, Антон Жилин <antonyzhi...@gmail.com> wrote: >>> A trend in modern C++ is AAA idiom. >> >> The newest and hottest fad, which I consider to be a complete and utter *rap. >> >>> The idea here is to *prohibit* new in user code, because ownership >>> semantics of raw pointer is undefined. >> >> That's a matter of some debate. I consider the ownership to be passed to the >> person invoking new, unless otherwise stated (e.g. in Qt's documentation the >> ownership transfer(s) are duly noted). >> >>> How can we apply these idioms to Qt? >> >> The question rather is: Should we? >> >>> Yes, if we add a couple of helper functions! >>> >>> 1. Non-widgets can usually be constructed on stack or using std::unique_ptr >>> -- Great >> >> Applies to widgets as well. A stack allocation is much faster and robust >> than new-ing needlessly. So if you don't need to keep binary compatibility >> (e.g. when you have widgets in an application, or not directly exposed from >> a library) I'd always opt for stack allocation. No need to have two heap >> allocations, when I can get only one (the d-ptr of the QObject). >> >>> 2. If we construct an object with a parent, we do something like this: >>> auto pushButton = new QPushButton(..., parent); >>> -- Not so great, we need to look at parent to know if we need to delete >>> pushButton >> >> There was recently a thread on this same mailing list dealing with similar >> issues. For most intents and purposes you can delete the child directly, if >> that's not possible the deletion can be scheduled through the event loop. I >> for one don't see any reason to complicate matters. >> >>> 3. Widgets without a parent are usually used with QSharedPointer >> >> "Usually"? Not in my experience. Widgets without a parent I just create in >> the stack if possible. If not, I either use QScopedPointer when I own them, >> or QPointer when ownership is transferred to Qt. I don't intend to share my >> widgets, much less pass them across threads, so I don't see any good reason >> why I would want to use a _shared_ pointer to keep reference to them >> >>> What do you think? >> >> Well that's pretty much what I think. You can agree or disagree, but I >> really don't see any reason to embark in writing AAA-style. >> >> Kind regards, >> Konstantin. > , > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest -- Regards, Konstantin _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
