> Annotations could be used on the header files, and qdoc > could be smart enough to present them in a clear way. It could be a solution. However, I don't think that this is possible to have annotations for all objects passed or returned by raw pointers.
Another thing is that you usually need to perform some action to see an annotation (hover-over, for example) and it usually provides more information than you need for case we're discussing. I think that having annotations is a good but optional thing and cannot solve identified issues with raw pointers. There are many tools that might help you fight various issues, but probably this is worth not having issues when it possible, rather than create them and then fight? > But this seems to be a point for *not* using std::, isn't it? We also > want Qt to be used with a program that does *not* use exceptions. > > What would happen if one of the STL classes publicly used in the Qt API > gained some method that can throw an exception (not just in OOM cases, > but as part of a common scenario)? Well, this is another issue, which should probably be addressed separately for each new std:: type added to the API. But on the other hand, we have some recommendations how to deal with exceptions at some cases: https://doc.qt.io/qt-5/exceptionsafety.html. Perhaps we will have to extend documentation. I also don't think that this is something we should worry about when discussing adding smart pointers. On 2/4/20 4:16 PM, Alberto Mardegan wrote: > On 04/02/20 16:55, Vitaly Fanaskov wrote: >> But if you see API like this: >> >> std::unique_ptr<Foo> someAPI(); >> >> You have much more information about managed object just by reading the >> code. This is also much easier to understand what can or cannot be done >> with the returned value in the example above. > True. I still think that the benefit it's not worth the imposition of > smart pointers. Annotations could be used on the header files, and qdoc > could be smart enough to present them in a clear way. > >> There also were good arguments about exceptions. We shouldn't forget >> that Qt can be used with a program that uses exceptions. > But this seems to be a point for *not* using std::, isn't it? We also > want Qt to be used with a program that does *not* use exceptions. > > What would happen if one of the STL classes publicly used in the Qt API > gained some method that can throw an exception (not just in OOM cases, > but as part of a common scenario)? > > Ciao, > Alberto > -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company / Qt Quick and Widgets Team _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development