Re: [Development] New scenegraph renderer
On Sep 3, 2013, at 10:44 PM, Mark wrote: > On Tue, Sep 3, 2013 at 8:23 PM, Nicolás Alvarez > wrote: > 2013/9/3 Mark : > > psst: http://blog.qt.digia.com/blog/2013/09/02/new-scene-graph-renderer/ > > > > Reading it now. While browsing it i noticed some very nice graphs in > > there! How did you make those? > > Nice but misleading. The pointless use of 3D gives wrong subjective > ideas about the values, because you tend to look at the area of the > red or green shape, not the height. For example, you can't really tell > that the 522 bar is twice as high as the 212 bar, they seem of similar > size, because of the top square. That was certainly not my intention, but I see your point :) > > While that is very much true, i still like to know what's used to create > those graphs since it looks quite nice :) > I was using http://nces.ed.gov/nceskids/createagraph/ cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On 04.09.2013 07:36, Olivier Goffart wrote: > On Tuesday 03 September 2013 21:20:20 Peter Kümmel wrote: >> It is of great benefit that you never had to think about if >> QScopedPointer(5.1) will delete when leaving scope. > > That's not true. > > QScopedPointer<...> myPtr(foo()); > myPtr.take(); Sure, but then you don't pass a QScopedPointer and have to care about the plain pointer. > > And it does not delete when leaving the scope. > > Think of qMove(myPtr) of a safer convenience to the already existing take() > >> The main point is that in Qt is nothing like std::unique_ptr, > > False again. only when QScopedPointer is movable QScopedPointer is almost exactly the same as unique_ptr. They > have the same API. > Compare http://en.cppreference.com/w/cpp/memory/unique_ptr and > http://qt-project.org/doc/qt-5.0/qtcore/qscopedpointer.html and tell me again > they are > nothing like eachother. The point of the thread is not functionality but naming. > > The documentation of unique_ptr even starts with: "std::unique_ptr is a smart > pointer that retains sole ownership of an object through a pointer and > destroys that object when the unique_ptr goes out of scope." > > It is unfortunate that the standard did not choose the name > std::scoped_pointer, but that's not the first time the standard and Qt are > using different name (QByteArray <> std::string, QLinkedList <> std::list, > ...) > > (I assume you meant s/Qt/QScopedPointer/) > >> so when it is needed and we can't use std::unique_ptr, we have to introduce >> a QUniquePointer. This is better than to add features to classes which are >> contradictorily to their naming. > > Based on all the false assumptions in your mail, I think it's safe to discard > your conclusion. > Maybe boost is also some sort of reference; there the scoped pointer is also not movable: http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/scoped_ptr.htm With making QScopedPointer movable we cemented the bad naming. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday 03 September 2013 19:17:53 Olivier Goffart wrote: [...] > I would even go further and add conversions operators for STL compatibility: > > inline QScopePointer::QScopePointer(std::unique_ptr other) > inline QScopePointer::operator std::unique_ptr() I obviously meant: inline QScopePointer::QScopePointer(std::unique_ptr &&other) inline QScopePointer::operator std::unique_ptr() && It should only work with rvalue reference. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday 03 September 2013 14:00:39 Thiago Macieira wrote: > On terça-feira, 3 de setembro de 2013 22:50:53, Stephen Kelly wrote: > > > QGraphicesView::addItem(QScopedPointer item) > > > > > > now you know that the the ownership is taken by the view. > Note that you should probably not use even std::unique_ptr for the case > above. QGraphicsView is taking ownership, I want to be explicit about that. > You probably want N3740[1] A Proposal for the World's Dumbest Smart Pointer. > [1] http://isocpp.org/files/papers/n3740.pdf QExemptPointer (or whatever name it will be) means there is no transfer of ownership. (Arguably, a reference could be used. But we don't use references for other reasons) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday 03 September 2013 21:20:20 Peter Kümmel wrote: > It is of great benefit that you never had to think about if > QScopedPointer(5.1) will delete when leaving scope. That's not true. QScopedPointer<...> myPtr(foo()); myPtr.take(); And it does not delete when leaving the scope. Think of qMove(myPtr) of a safer convenience to the already existing take() > The main point is that in Qt is nothing like std::unique_ptr, False again. QScopedPointer is almost exactly the same as unique_ptr. They have the same API. Compare http://en.cppreference.com/w/cpp/memory/unique_ptr and http://qt-project.org/doc/qt-5.0/qtcore/qscopedpointer.html and tell me again they are nothing like eachother. The documentation of unique_ptr even starts with: "std::unique_ptr is a smart pointer that retains sole ownership of an object through a pointer and destroys that object when the unique_ptr goes out of scope." It is unfortunate that the standard did not choose the name std::scoped_pointer, but that's not the first time the standard and Qt are using different name (QByteArray <> std::string, QLinkedList <> std::list, ...) (I assume you meant s/Qt/QScopedPointer/) > so when it is needed and we can't use std::unique_ptr, we have to introduce > a QUniquePointer. This is better than to add features to classes which are > contradictorily to their naming. Based on all the false assumptions in your mail, I think it's safe to discard your conclusion. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Change in qt/qtbase[dev]: Enable -Werror for all of qtbase
FYI You're affected if you are: * using -developer-build * building dev * on one of the following compilers / OS: * Apple Clang 4.0 to 4.2 (technically on any OS) * ICC 13.0, 13.1, 14.0 on Linux * GCC 4.6 to 4.8 (any OS) What I didn't check: does the CI run -developer-build? Probably not, since this integrated on the first try. -- Forwarded message -- Qt Continuous Integration System has approved a build with this change and it was merged. Change subject: Enable -Werror for all of qtbase .. Enable -Werror for all of qtbase This change applies to all qtbase modules, tools and applications. It does not apply to examples or unit tests. This change complements the changes done to mkspecs/qt_common.prf (especially 043b80919747676c2df4b4423ed5950583233d30 and ebfd85a499a4382ace09d443b1f35cd6b1848af6). It enables -Werror checking in qtbase for GCC 4.6-4.8, Apple clang 4.0-4.2 and ICC 13.0-14.0. Change-Id: I6d29a7a1b3716960a149409f551363385991714c --- M .qmake.conf 1 file changed, 1 insertion(+), 0 deletions(-) Approvals: Qt Sanity Bot: Sanity review passed Thiago Macieira: Lars Knoll: Looks good to me, but someone else must approve Oswald Buddenhagen: Looks good to me, approved Message: QtBase_dev_Integration #1672: SUCCESS Tested changes (refs/builds/dev_1378252330): http://codereview.qt-project.org/63819 [PS2] - Enable -Werror for all of qtbase - -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consistency in Qt headers (extends: 'renaming all QWindow properties that have "window" in them')
Hi, I don't know about QtJsonDb but QtPim has a few people interested in it (Jolla for one, and Canonical for another). At the moment, development resources dedicated to improving it are somewhat limited, but that situation will change. If there's anything in particular which you think needs changing, please add it to https://bugreports.qt-project.org/browse/QTBUG-31824 so that it can be scheduled. Cheers, Chris. On Wed, Sep 4, 2013 at 8:30 AM, Stephen Kelly wrote: > On Friday, October 26, 2012 19:10:15 Stephen Kelly wrote: > > QtBluetooth uses a namespace for public APIs, but QtLocation does not, > for > > example. > > Hello Sze-Howe, > > The qtconnectivity repo will likely be part of Qt 5.2, but it is still not > consistent - it uses a QtBluetooth and QtNfc. Both namespaces should be > removed. > > http://thread.gmane.org/gmane.comp.lib.qt.devel/7464/focus=7616 > > Are you going to clean up that module? > > The qtpim and qtjsondb repos also still have classes in namespaces, but as > far > as I know, those are headed for the big git submodule in the sky. > > Thanks, > > -- > Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com > > Stephen Kelly | Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-Independent Software Solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consistency in Qt headers (extends: 'renaming all QWindow properties that have "window" in them')
On Friday, October 26, 2012 19:10:15 Stephen Kelly wrote: > QtBluetooth uses a namespace for public APIs, but QtLocation does not, for > example. Hello Sze-Howe, The qtconnectivity repo will likely be part of Qt 5.2, but it is still not consistent - it uses a QtBluetooth and QtNfc. Both namespaces should be removed. http://thread.gmane.org/gmane.comp.lib.qt.devel/7464/focus=7616 Are you going to clean up that module? The qtpim and qtjsondb repos also still have classes in namespaces, but as far as I know, those are headed for the big git submodule in the sky. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On terça-feira, 3 de setembro de 2013 22:50:53, Stephen Kelly wrote: > > QGraphicesView::addItem(QScopedPointer item) > > > > > > now you know that the the ownership is taken by the view. > > Peter said what I was going to say. When the need to add such a method > arises, you should write a QUniquePointer. You should not shoehorn moving > into QScopedPointer thereby breaking the meaning of QScopedPointer. Note that you should probably not use even std::unique_ptr for the case above. You probably want N3740[1] A Proposal for the World's Dumbest Smart Pointer. [1] http://isocpp.org/files/papers/n3740.pdf -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 19:17:53 you wrote: > Hi, > > In modern C++, one should not handle pointer directly. Yes. A good goal. > QGraphicesView::addItem(QScopedPointer item) > > now you know that the the ownership is taken by the view. Peter said what I was going to say. When the need to add such a method arises, you should write a QUniquePointer. You should not shoehorn moving into QScopedPointer thereby breaking the meaning of QScopedPointer. QUniquePointer could even share code with QScopedPointer, but that can be part of the implementation discussion. Currently we are discussing the features QScopedPointer should have, so we don't need to discuss the implementation details of QUniquePointer here. The non-movability of QScopedPointer is a feature, and it is a feature QScopedPointer should have. If you are reading code written by someone smart (and based on Qt 5.1) and you see a QScopedPointer, you know that it will not escape its scope. Someone who is not smart might use q.reset(p.take()), but someone smart would not use QScopedPointer if they needed to do that. Similarly, someone who is not smart might write delete sharedPtr.data(); We should assume people are smart. Particularly if the smart pointer they are using has 'scoped' in the name, and has had the 'scoped' meaning since Qt 4.6 when it was introduced. > QScopedPointer QStyleFactory::create(QString); This looks really wrong. I'm surprised you do not see that. Obviously it should be QUniquePointer QStyleFactory::create(QString); > > Each C++ library come with its own set of smart pointer. Now that C++11 is > there I think we should align to the same semantics, that's what C++ > developers should learn. C++11 has no 'scoped' pointer. C++11 has a 'unique' pointer. If you want Qt to have a 'unique' pointer, it should not be called QScopedPointer (very very bad and non-Qt-like- class name for something which is supposed to be 'the Qt unique pointer'). It should be QUniquePointer. That should be very obvious. Making QScopedPointer movable was a mistake. That should be very obvious too. > > Adding a move contructor to QScopedPointer makes no sense, because moving > > means 'escaping the scope', which breaks the fundamental point of > > QScopedPointer. QScopedPointer is different to std::unique_ptr and should > > remain so. > > I disagree. The fact that you can exit the scope explicitly is perfectly > fine. Ok - you disagree. That doesn't change my mind. > > I would even go further and add conversions operators for STL compatibility: > > inline QScopePointer::QScopePointer(std::unique_ptr other) This is somewhat reasonable. However, it is unrelated to whether QScopedPointer should be movable. I have comments on what you propose, but as it is off-topic for this thread, I'll keep them to myself for now. > inline QScopePointer::operator std::unique_ptr() This is not a good idea. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting triaging rights for QBS JIRA
http://qt-project.org/wiki/Triaging_Bugs#89f846f264788bfaf58c4efbf05de4eb On Tue, Sep 3, 2013 at 9:12 PM, Jake Petroules wrote: > Hello, > > I would like to request triaging rights for the QBS project on JIRA. > > I was encouraged to request these privileges on IRC but I was not able to > find any documentation on the process for doing so. I apologize if this is > the wrong place to ask. > > My QBS development history: > https://codereview.qt-project.org/#q,owner:jake.petroules%2540petroules.com+status:merged+project:qt-labs/qbs,n,z > My assigned QBS issues: > https://bugreports.qt-project.org/issues/?jql=project%20%3D%20QBS%20AND%20assignee%20%3D%20jakepetroules > > Thank you. > -- > *Jake Petroules* > Chief Technology Officer > Petroules Corporation · www.petroules.com > Email: jake.petrou...@petroules.com > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Requesting triaging rights for QBS JIRA
Hello, I would like to request triaging rights for the QBS project on JIRA. I was encouraged to request these privileges on IRC but I was not able to find any documentation on the process for doing so. I apologize if this is the wrong place to ask. My QBS development history: https://codereview.qt-project.org/#q,owner:jake.petroules%2540petroules.com+status:merged+project:qt-labs/qbs,n,z My assigned QBS issues: https://bugreports.qt-project.org/issues/?jql=project%20%3D%20QBS%20AND%20assignee%20%3D%20jakepetroules Thank you. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
On Tue, Sep 3, 2013 at 8:23 PM, Nicolás Alvarez wrote: > 2013/9/3 Mark : > > psst: http://blog.qt.digia.com/blog/2013/09/02/new-scene-graph-renderer/ > > > > Reading it now. While browsing it i noticed some very nice graphs in > > there! How did you make those? > > Nice but misleading. The pointless use of 3D gives wrong subjective > ideas about the values, because you tend to look at the area of the > red or green shape, not the height. For example, you can't really tell > that the 522 bar is twice as high as the 212 bar, they seem of similar > size, because of the top square. > > While that is very much true, i still like to know what's used to create those graphs since it looks quite nice :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On terça-feira, 3 de setembro de 2013 22:12:58, Oswald Buddenhagen wrote: > "A non-null QScopedPointer deletes when it leaves the scope." > > which sounds quite reasonable to me. It still does that. Moving out of a QScopedPointer simply means taking the pointer out of it before it goes out of scope. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tue, Sep 03, 2013 at 09:20:20PM +0200, Peter Kümmel wrote: > >> Adding a move contructor to QScopedPointer makes no sense, because moving > >> means 'escaping the scope', which breaks the fundamental point of > >> QScopedPointer. QScopedPointer is different to std::unique_ptr and should > >> remain so. > > I have to agree with Steven. After allowing moving, the semantic is > different to the naming: after this change we could write in the docs > > "QScopedPointer sometimes deletes when it leaves the scope." > > Which makes it obvious that "QScopedPointer" is the wrong name for such a > behavior. > actually, it is "A non-null QScopedPointer deletes when it leaves the scope." which sounds quite reasonable to me. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On terça-feira, 3 de setembro de 2013 11:47:33, Stephen Kelly wrote: > Why not use std::unique_ptr instead in the cases where the patch has an > effect? We cannot. All uses of std::unique_ptr inside Qt are automatic -2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On terça-feira, 3 de setembro de 2013 11:42:04, Oswald Buddenhagen wrote: > you did, however, make no effort to substantiate your position. > an argument against your interpretation is for example bisectability. > also, it's just plain illogical to tear apart an allegedly "too complex" > change, because then assessing the pieces requires adding "external" > context. which is just a less handy way to review one big change. I've made it clear that I prefer reviewability (now and in the future) over compilability, in extreme cases. It's an opinion. As such, it does not have to be substantiated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
>> Adding a move contructor to QScopedPointer makes no sense, because moving >> means 'escaping the scope', which breaks the fundamental point of >> QScopedPointer. QScopedPointer is different to std::unique_ptr and should >> remain so. I have to agree with Steven. After allowing moving, the semantic is different to the naming: after this change we could write in the docs "QScopedPointer sometimes deletes when it leaves the scope." Which makes it obvious that "QScopedPointer" is the wrong name for such a behavior. It is of great benefit that you never had to think about if QScopedPointer(5.1) will delete when leaving scope. > > I disagree. The fact that you can exit the scope explicitly is perfectly > fine. > > I would even go further and add conversions operators for STL compatibility: > > inline QScopePointer::QScopePointer(std::unique_ptr other) > inline QScopePointer::operator std::unique_ptr() > The main point is that in Qt is nothing like std::unique_ptr, so when it is needed and we can't use std::unique_ptr, we have to introduce a QUniquePointer. This is better than to add features to classes which are contradictorily to their naming. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
2013/9/3 Mark : > psst: http://blog.qt.digia.com/blog/2013/09/02/new-scene-graph-renderer/ > > Reading it now. While browsing it i noticed some very nice graphs in > there! How did you make those? Nice but misleading. The pointless use of 3D gives wrong subjective ideas about the values, because you tend to look at the area of the red or green shape, not the height. For example, you can't really tell that the 522 bar is twice as high as the 212 bar, they seem of similar size, because of the top square. -- Nicolás ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
On terça-feira, 3 de setembro de 2013 18:58:33, Mark wrote: > > I already did, but I need to wait for a doc-run before one of the links > > become available > psst: http://blog.qt.digia.com/blog/2013/09/02/new-scene-graph-renderer/ Yup, I saw it. That's why I announced it too: https://plus.google.com/b/104580575722059274792/104580575722059274792/posts/CaDgYFFNYBk https://twitter.com/qtproject/status/374614250620063744 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On terça-feira, 3 de setembro de 2013 19:17:53, Olivier Goffart wrote: > But because we don't want to use the STL in our ABI, we can't use > std::unique_ptr as parameter or return value of our exported functions. > > So we have to duplicate, or we have to reconsider that decision not to use > the STL. There are two issues here: 1) we cannot use any of the C++11 additions to the Standard Library, anywhere That includes inside .cpp, even if it does not affect the ABI. That's because we have no way of properly detecting whether the feature has been added to the library in use. At least in Blackberry, the C++ library is a much older version than the compiler in use. The exceptions are std::move, std::forward, and std::initializer_list, mostly because they're already in use and because they exist only to complement a language feature (respectively, rvalue references; rvalue references and variadic templates; uniform initialisation). And even if you can detect the presence of the feature, you need to make sure that Qt still compiles when the feature is absent. That either means having a fallback codepath or disabling the Qt feature if the Standard Library feature is absent. 2) we cannot use any Standard Library symbol somewhere that affects the ABI (besides the language support features, like operator new, typeinfos, etc) That's because we need to support multiple C++ standard libraries that are binary incompatible with one binary: libc++ and libstdc++. While libstdc++ is waning on OS X, libc++ gets more interesting on Linux and especially the BSDs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
Hi, In modern C++, one should not handle pointer directly. This is very error prone. Qt was designed before C++98 was standardized. The parent-child memory management is great, but not perfect. Using raw pointer all over the place is confusing because you never know what is the ownership of your pointers. Smart pointer allow you to take ownership explicitly. Example: QGraphicsView::addItem(QGraphicsItem *item) When you call this function, who gets the ownership? You need to go in the documentation to find out. And it's not easy to remember or even guess because even Qt is not always consistent. QGraphicesView::addItem(QScopedPointer item) now you know that the the ownership is taken by the view. Or, in case of shared ownership: QAbstractItemView::setSelectionModel(QSharedPointer itm) And if you return a scoped pointer, it means the caller takes ownership QScopedPointer QStyleFactory::create(QString); Each C++ library come with its own set of smart pointer. Now that C++11 is there I think we should align to the same semantics, that's what C++ developers should learn. On Tuesday 03 September 2013 10:02:52 Stephen Kelly wrote: > [...] > Again, this is what std::unique_ptr is for. We should not try to turn > QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a > need for a std::unique_ptr, they should use it. We should not adapt > QScopedPointer to fit the need instead. But because we don't want to use the STL in our ABI, we can't use std::unique_ptr as parameter or return value of our exported functions. So we have to duplicate, or we have to reconsider that decision not to use the STL. > Adding a move contructor to QScopedPointer makes no sense, because moving > means 'escaping the scope', which breaks the fundamental point of > QScopedPointer. QScopedPointer is different to std::unique_ptr and should > remain so. I disagree. The fact that you can exit the scope explicitly is perfectly fine. I would even go further and add conversions operators for STL compatibility: inline QScopePointer::QScopePointer(std::unique_ptr other) inline QScopePointer::operator std::unique_ptr() -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
On Mon, Sep 2, 2013 at 5:51 PM, Sletta Gunnar wrote: > > On Sep 2, 2013, at 5:35 PM, Thiago Macieira > wrote: > >> On segunda-feira, 2 de setembro de 2013 15:31:45, Sletta Gunnar wrote: >>> Hi, >>> >>> The new scene graph renderer was just accepted into the qtdeclarative "dev" >>> branch. I've done a fair amount of testing, but I'm sure some things will >>> have slipped through, so if you notice something: Create a bugreport, mail >>> me or ping me on IRC and I'll try to get it ironed out as soon as possible. >> >> Cool! >> >> Can you write a blog with the benefits? > > I already did, but I need to wait for a doc-run before one of the links > become available :) > > cheers, > Gunnar > >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development psst: http://blog.qt.digia.com/blog/2013/09/02/new-scene-graph-renderer/ Reading it now. While browsing it i noticed some very nice graphs in there! How did you make those? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Category Logging Patch - please review
Hi, This is just a heads up that https://codereview.qt-project.org/#change,44430 is now ready to be reviewed from my side ;) So feel free to have a look. If you don't know what the patch is actually about, I recommend to check out the included example: https://codereview.qt-project.org/#patch,sidebyside,44430,16,examples/logging/logger/main.cpp https://codereview.qt-project.org/#patch,sidebyside,44430,16,examples/logging/logger/logrules.txt Regards Kai > -Original Message- > From: development-bounces+kai.koehne=digia@qt-project.org > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > Behalf Of Koehne Kai > Sent: Monday, August 26, 2013 4:38 PM > To: Blasche Alexander; Robin Burchell; development@qt-project.org > Cc: Poenitz Andre > Subject: Re: [Development] Tracing Qt > [...] > I actually started a patch back in January that I just revived: > > https://codereview.qt-project.org/#change,44430 > > There are certainly still rough edges, but IMO we should be able to re-use > some of it for a hypothetical tracing solution, too. The actual data flow > will be > different from the logging case (you don't want to go through > QMessageLogger etc, and don't want to convert everything to a QString in > the first place), but the idea that you can activate/deactivate categories at > runtime through different means is the same. > > Regards > > Kai > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I think the advantages of having these functions available in QtCore/Gui outweighs the risk of customers accidentally using platform-dependent code. Maintenance will be easier since there is less code duplication. Morten On Sep 2, 2013, at 11:38 PM, Joseph Crowell wrote: > Most of the functionality was already in Qt 4 and was moved out for Qt 5 > because of maintenance issues and different code for different platforms > exposed to the customer. > > On 02/09/2013 10:35 PM, Sorvig Morten wrote: >> I agree the "Extra" looks superfluous. In fact I'd like to go a bit further >> and suggest we don't have platform extras at all and instead integrate the >> functionality into Qt: >> >> - Conversion functions for types in QtCore to QtCore >> - Conversion functions for types in QtGui to QtGui >> - Widgets to QtWidgets >> - Non-trivial implementation to the platform plugin >> - etc. >> >> I've prepared a set of patches showing how (for parts of QtMacExtras): >> >> https://codereview.qt-project.org/64342 >> https://codereview.qt-project.org/64343 >> https://codereview.qt-project.org/64344 >> https://codereview.qt-project.org/64345 >> https://codereview.qt-project.org/64346 >> >> Notes: >> - The platform extras will continue to exist as research playgrounds. >> - This approach works for platforms that has an Q_OS #define >> - The function header is named "qmacfunctions.h", the namespace is "QMac" >> - We can now use the public NSString conversion functions in QtCore when >> implementing rest of Qt. >> - Conversion functions in QtCore And Gui can be used without bringing in >> QtMacExtras and its widgets dependency >> >> One case is still unsolved: classes that wrap native UI elements but are >> neither widgets nor Qt Quick Items. (Mac native tool bar and windows task >> bar for example). A possible solution could be to add the implementation to >> the platform plugin and add public API in QtWidgets and Qt Quick Controls. >> QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are >> basically API wrappers around the implementation in QCococaWindow. >> >> Morten >> >> >> On Aug 30, 2013, at 3:27 PM, Jake Petroules >> wrote: >> >>> +1 from me for doing it everywhere, including in the library names. >>> -- >>> Jake Petroules >>> Chief Technology Officer >>> Petroules Corporation · www.petroules.com >>> Email: jake.petrou...@petroules.com >>> >>> On Aug 30, 2013, at 9:17 AM, Nurmi J-P wrote: >>> Hi all, While we still have a chance to tweak things before releasing 5.2, I'd like to re-open the discussion about platform extras naming. Short version: Could we rename the QtMacExtras & QtWinExtras namespaces to just QtMac & QtWin? (QtX11Extras namespace doesn't exist, at least yet) Long version: The current status: - Classes: QPlatformFoo - QX11Info (*) - QMacNativeWidget, ... - QWinTaskbarButton, ... (*) The only thing in QtX11Extras - already released in Qt 5.1. - Stand-alone function namespaces: QtPlatformExtras::toType() - QtWinExtras::toHBITMAP(), ... - QtMacExtras::toCGImageRef(), ... I'm not entirely happy with how the current stand-alone function namespaces look in application code. I would find it prettier if we dropped the "Extras" part from the namespace names. IMHO that would still remain distinctive enough, just making it look more professional and... convenient to type. :) if (QtWinExtras::isCompositionEnabled()) // ... vs. if (QtWin::isCompositionEnabled()) // ... Open questions: - What about the headers? - Could #include also become ? - was already released - so it would have to remain as a compatibility header if we chose the latter - What about the lib names? Should we keep them intact? - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. QtMac.framework is not necessarily an improvement - The lib names are IMHO not that important, because users rarely have to care. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailin
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 13:06:50 Jocelyn Turcotte wrote: > On Tue, Sep 03, 2013 at 12:07:09PM +0200, Stephen Kelly wrote: > > std::auto_ptr is very different to QScopedPointer. > > I'm no C++ master, so you might teach me something if you explain what you > meant, but the only important difference I see between them is that > QScopedPointer is non-copyable. That's the main difference I see too. The point you tried to make is irrelevant. > On the other hand, I don't see in which case QScopedPointer being movable > would be a problem. It makes the 'scoped' pointer not scoped. > The move semantic was designed so that it's either > explicit or implicit when safe to do. > > In any case I don't have a strong opinion on whether or not we should keep > it, I'm just puzzled on how it is problematic. Ok, then be puzzled. > Redundancy with std hasn't been a strong concern of Qt before. We obsoleted qSort and friends and are actively replacing the use of it with std::sort. Introducing *new* redundancy which is redundant from the moment it hit the repo is not a good idea. Therefore the patch should be reverted. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 12:48:51 Daniel Teske wrote: > > Again, this is what std::unique_ptr is for. We should not try to turn > > QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have > > a need for a std::unique_ptr, they should use it. We should not adapt > > QScopedPointer to fit the need instead. > > > > Adding a move contructor to QScopedPointer makes no sense, because moving > > means 'escaping the scope', which breaks the fundamental point of > > QScopedPointer. QScopedPointer is different to std::unique_ptr and should > > remain so. > > *const* unique_ptr is a scoped ptr. So QScopedPointer is a NIH irregardless > of a move support. A const unique_ptr is like a Qt 5.1 QScopedPointer. A const unique_ptr can not be moved. A const unique_ptr is *not* like a Qt 5.2 QScopedPointer. A Qt 5.2 QScopedPointer can be moved. That is why we have this thread. I am suggesting that a Qt 5.2 QScopedPointer should not be movable. Your point is also C++11 only. QScopedPointer also works with C++98. So QScopedPointer still has a reason to exist, and it still has no reason to be movable. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tue, Sep 03, 2013 at 12:07:09PM +0200, Stephen Kelly wrote: > std::auto_ptr is very different to QScopedPointer. I'm no C++ master, so you might teach me something if you explain what you meant, but the only important difference I see between them is that QScopedPointer is non-copyable. This is the main issue I see with auto_ptr, where it could cause more trouble than it would help. On the other hand, I don't see in which case QScopedPointer being movable would be a problem. The move semantic was designed so that it's either explicit or implicit when safe to do. In any case I don't have a strong opinion on whether or not we should keep it, I'm just puzzled on how it is problematic. Redundancy with std hasn't been a strong concern of Qt before. I personally find the functionality convenient and non-obstrusive. Cheers, Jocelyn ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
> Again, this is what std::unique_ptr is for. We should not try to turn > QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have > a need for a std::unique_ptr, they should use it. We should not adapt > QScopedPointer to fit the need instead. > > Adding a move contructor to QScopedPointer makes no sense, because moving > means 'escaping the scope', which breaks the fundamental point of > QScopedPointer. QScopedPointer is different to std::unique_ptr and should > remain so. *const* unique_ptr is a scoped ptr. So QScopedPointer is a NIH irregardless of a move support. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 11:57:06 you wrote:
> On Tue, Sep 03, 2013 at 11:44:58AM +0200, Stephen Kelly wrote:
> > Em, what?
> >
> > I suppose you didn't read the patch. Am I correct?
> >
> > The patch *only* has an effect for people using C++11, where it is
> > redundant because of std::unique_ptr.
> >
> > The original patch only tries to make QScopedPointer something it's not.
>
> Another thing to keep in mind is that QScopedPointer is also partially
> redundant with std::auto_ptr.
std::auto_ptr is very different to QScopedPointer.
I suppose 'partially' is the operative word in your sentence, but that makes
your sentence meaningless. You can make a claim of 'partial' redundance with
anything.
{
std::shared_ptr p = someCreateApi();
// p refcount is 1
} // p refcount is 0. delete.
"std::shared_ptr is partially redundant with std::unique_ptr" !!!
I don't buy the partial redundance claim at all.
QScopedPointer has a reason to exist. It does not have a reason to be movable.
> Yet, it exists and people use it instead.
> QScopedPointer is also used in many classes as a member, which conflicts
> with its name, and it does that job pretty well anyway.
There is no conflict. In that case the QScopedPointer instance is scoped to
the class instance.
Thanks,
--
Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday 3. September 2013 11.44.58 Stephen Kelly wrote: > On Tuesday, September 03, 2013 11:39:58 Simon Hausmann wrote: > > > Adding a move contructor to QScopedPointer makes no sense, because > > > moving > > > means 'escaping the scope', which breaks the fundamental point of > > > QScopedPointer. QScopedPointer is different to std::unique_ptr and > > > should > > > remain so. > > > > The only argument I can see in your email that explains _why_ this feature > > shouldn't be added to QScopedPointer is NIH. > > > > What is the price of NIH here? Compared to the value we're adding at the > > same time to developers who are not able to rely on C++11 yet? > > Em, what? > > I suppose you didn't read the patch. Am I correct? > > The patch *only* has an effect for people using C++11, where it is redundant > because of std::unique_ptr. Eeek, I overlooked that detail (that I admit is rather important :) Please disregard my earlier email then. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tue, Sep 03, 2013 at 11:44:58AM +0200, Stephen Kelly wrote: > Em, what? > > I suppose you didn't read the patch. Am I correct? > > The patch *only* has an effect for people using C++11, where it is redundant > because of std::unique_ptr. > > The original patch only tries to make QScopedPointer something it's not. > Another thing to keep in mind is that QScopedPointer is also partially redundant with std::auto_ptr. Yet, it exists and people use it instead. QScopedPointer is also used in many classes as a member, which conflicts with its name, and it does that job pretty well anyway. The way I see it is that its name is just too specific to encapsulate all the situations where it can be useful. My name is Jocelyn, it's a girl name in english speaking countries, but that doesn't mean I should behave like a girl there. Just my 2 cents. Cheers, Jocelyn ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On Tuesday, September 03, 2013 11:42:04 Oswald Buddenhagen wrote: > On Mon, Sep 02, 2013 at 11:37:03AM -0700, Thiago Macieira wrote: > > On segunda-feira, 2 de setembro de 2013 18:46:37, Oswald Buddenhagen wrote: > > > in fact, point 4 of the commit policy is pretty clear on that matter. it > > > is absurd to remove function (specific to the scope of the commit) from > > > the definition of atomicity. > > > also, the policy does not know a "topic" concept, for good reasons. you > > > cannot use topics (or branches which you intend to merge, for that > > > matter) as an excuse for violating the policy. > > > > We established that I disagree with those definitions in a previous > > discussion on this topic. > > you did, however, make no effort to substantiate your position. > an argument against your interpretation is for example bisectability. > also, it's just plain illogical to tear apart an allegedly "too complex" > change, because then assessing the pieces requires adding "external" > context. which is just a less handy way to review one big change. I agree with ossi here. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 11:31:28 Oswald Buddenhagen wrote: > On Tue, Sep 03, 2013 at 10:02:52AM +0200, Stephen Kelly wrote: > > Again, this is what std::unique_ptr is for. We should not try to turn > > QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have > > a need for a std::unique_ptr, they should use it. We should not adapt > > QScopedPointer to fit the need instead. > > why exactly would such a dual-use scoped pointer be a problem? anything > else than dogmatism? What is "dual-use" about having a 'scoped' pointer which is not scoped? It makes as much sense as creating a 'shared' pointer which is not shared. To turn the question around on people who don't see the need to revert the original patch: Why not use std::unique_ptr instead in the cases where the patch has an effect? Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 11:39:58 Simon Hausmann wrote: > > Adding a move contructor to QScopedPointer makes no sense, because moving > > means 'escaping the scope', which breaks the fundamental point of > > QScopedPointer. QScopedPointer is different to std::unique_ptr and should > > remain so. > > The only argument I can see in your email that explains _why_ this feature > shouldn't be added to QScopedPointer is NIH. > > What is the price of NIH here? Compared to the value we're adding at the > same time to developers who are not able to rely on C++11 yet? Em, what? I suppose you didn't read the patch. Am I correct? The patch *only* has an effect for people using C++11, where it is redundant because of std::unique_ptr. The original patch only tries to make QScopedPointer something it's not. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
Op 3-9-2013 11:31, Oswald Buddenhagen schreef: > On Tue, Sep 03, 2013 at 10:02:52AM +0200, Stephen Kelly wrote: >> Again, this is what std::unique_ptr is for. We should not try to turn >> QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a >> need for a std::unique_ptr, they should use it. We should not adapt >> QScopedPointer to fit the need instead. >> > why exactly would such a dual-use scoped pointer be a problem? anything > else than dogmatism? > Because it breaks what QScopedPointer is trying to do for you. If you want something that you can return, there are other alternatives around like the mentioned std::unique_ptr or even QSharedPointer if you fancy. Outfitting QScopedPointer with methods that allow you to break out of the scope means that you can't rely on that core feature anymore. André -- You like Qt? I am looking for collegues to join me at i-Optics! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On Mon, Sep 02, 2013 at 11:37:03AM -0700, Thiago Macieira wrote: > On segunda-feira, 2 de setembro de 2013 18:46:37, Oswald Buddenhagen wrote: > > in fact, point 4 of the commit policy is pretty clear on that matter. it > > is absurd to remove function (specific to the scope of the commit) from > > the definition of atomicity. > > also, the policy does not know a "topic" concept, for good reasons. you > > cannot use topics (or branches which you intend to merge, for that > > matter) as an excuse for violating the policy. > > We established that I disagree with those definitions in a previous > discussion on this topic. > you did, however, make no effort to substantiate your position. an argument against your interpretation is for example bisectability. also, it's just plain illogical to tear apart an allegedly "too complex" change, because then assessing the pieces requires adding "external" context. which is just a less handy way to review one big change. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday 3. September 2013 10.02.52 Stephen Kelly wrote:
> Hi there,
>
> Commit 5b9006bbdba7dcab01b8e640554a7d7a4b64f76b in qtbase added move
> capability to QScopedPointer.
>
> That means that in Qt 5.2, if you use C++11, you can do this:
>
> int main(int argc, char **argv)
> {
>QScopedPointer p_out;
>{
> QScopedPointer p(new int);
> p_out = std::move(p);
>}
> }
>
> However, if you want to move a QScopedPointer like that, then you don't want
> a QScopedPointer at all, but a std::unique_ptr instead.
>
> It also means that you can put a QScopedPointer in your API:
>
> QScopedPointer returnScopedPointer()
> {
>QScopedPointer p(new int);
>return p;
> }
>
> int main(int argc, char **argv)
> {
>QScopedPointer p = returnScopedPointer();
> }
>
>
> Again, this is what std::unique_ptr is for. We should not try to turn
> QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a
> need for a std::unique_ptr, they should use it. We should not adapt
> QScopedPointer to fit the need instead.
>
> Adding a move contructor to QScopedPointer makes no sense, because moving
> means 'escaping the scope', which breaks the fundamental point of
> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
> remain so.
The only argument I can see in your email that explains _why_ this feature
shouldn't be added to QScopedPointer is NIH.
What is the price of NIH here? Compared to the value we're adding at the same
time to developers who are not able to rely on C++11 yet?
Qt's goal is to make life easier for developers. Adding a small piece of
functionality to QScopedPointer seems to be in line with that goal IMHO.
Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tue, Sep 03, 2013 at 10:02:52AM +0200, Stephen Kelly wrote: > Again, this is what std::unique_ptr is for. We should not try to turn > QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a > need for a std::unique_ptr, they should use it. We should not adapt > QScopedPointer to fit the need instead. > why exactly would such a dual-use scoped pointer be a problem? anything else than dogmatism? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
On Tuesday, September 03, 2013 10:41:35 Giuseppe D'Angelo wrote: > While I partially agree with the dreaded NIH syndrome, let me forward > the argument that "escaping the scope" is very explicit in the code: If it shouldn't be possible, it doesn't matter how explicit it is. > The move assignment in particular doesn't require anything "new" -- it's > literally q.reset(p.take()). The first point in my mail was that if you are doing q.reset(p.take()), then you don't want QScopedPointer in the first place. You want std::unique_ptr instead. If you don't have c++11, then you would have to stick with q.reset(p.take()) anyway (and you should reconsider why you are using QScopedPointer there at all, if this is existing code). Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making QScopedPointer scoped (again)
Il 03/09/2013 10:02, Stephen Kelly ha scritto: Again, this is what std::unique_ptr is for. We should not try to turn QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a need for a std::unique_ptr, they should use it. We should not adapt QScopedPointer to fit the need instead. Adding a move contructor to QScopedPointer makes no sense, because moving means 'escaping the scope', which breaks the fundamental point of QScopedPointer. QScopedPointer is different to std::unique_ptr and should remain so. While I partially agree with the dreaded NIH syndrome, let me forward the argument that "escaping the scope" is very explicit in the code: either one has to return it: > return scopedPointer; or it's being moved > q = std::move(p); The move assignment in particular doesn't require anything "new" -- it's literally q.reset(p.take()). Food for thought, -- Join us at Qt Developer Days 2013! - https://devdays.kdab.com Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Making QScopedPointer scoped (again)
Hi there,
Commit 5b9006bbdba7dcab01b8e640554a7d7a4b64f76b in qtbase added move
capability to QScopedPointer.
That means that in Qt 5.2, if you use C++11, you can do this:
int main(int argc, char **argv)
{
QScopedPointer p_out;
{
QScopedPointer p(new int);
p_out = std::move(p);
}
}
However, if you want to move a QScopedPointer like that, then you don't want a
QScopedPointer at all, but a std::unique_ptr instead.
It also means that you can put a QScopedPointer in your API:
QScopedPointer returnScopedPointer()
{
QScopedPointer p(new int);
return p;
}
int main(int argc, char **argv)
{
QScopedPointer p = returnScopedPointer();
}
Again, this is what std::unique_ptr is for. We should not try to turn
QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a
need for a std::unique_ptr, they should use it. We should not adapt
QScopedPointer to fit the need instead.
Adding a move contructor to QScopedPointer makes no sense, because moving
means 'escaping the scope', which breaks the fundamental point of
QScopedPointer. QScopedPointer is different to std::unique_ptr and should
remain so.
Please approve:
https://codereview.qt-project.org/#change,64428
Thanks,
--
Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Gerrit Update deployed
> [mailto:development-bounces+ismo.haataja=digia@qt-project.org] On > Behalf Of Thiago Macieira > > On sexta-feira, 30 de agosto de 2013 08:01:14, Haataja Ismo wrote: > > > > Today we have deployed one new feature for Gerrit: new 'deferred' status > > for a change. > > If you give a hand, people will ask for the arm: is anyone looking into > upgrading our Gerrit installation to the latest, version 2.6? Yes, I am. But we probably are skipping version or two and targeting version 2.8. Although this task is still in that early phase that I can't be sure if this is the final outcome. The actual upgrade may then be 2.6 or at least 2.5. But some upgrade is coming, that's for sure :) > My colleagues here at Intel are working on some interesting things for the > Tizen Gerrit that I'd like to consider for ours when they become public, but > I'm told some of them require newer versions of Gerrit. Yes, why not, if good stuff is available. -- Ismo Haataja Senior Software Specialist - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
