GNOME Bugzilla – Bug 539329
Improve exception safety with smart pointers
Last modified: 2016-10-09 16:04:36 UTC
Would you like to wrap any pointer data members with the template class "std::auto_ptr"? http://en.wikipedia.org/wiki/Auto_ptr Candidates: http://svn.gnome.org/viewvc/gparted/trunk/src/Dialog_Base_Partition.cc?revision=856&view=markup http://svn.gnome.org/viewvc/gparted/trunk/src/Frame_Resizer_Base.cc?revision=696&view=markup http://svn.gnome.org/viewvc/gparted/trunk/src/GParted_Core.cc?revision=857&view=markup
Thank you Markus for pointing out another way to improve the source code of GParted. It has been a long time since you first raised this bug. I do appreciate your patience. Recently there has been some discussion about auto_ptr being deprecated. It would appear that there are problems with auto_ptr that are supposedly fixed with a new unique_ptr implementation. This is mentioned in the wikipedia article above that contains the following link: Using unique_ptr, Part I http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=400 Based on this information I am not sure how to proceed. If we implement auto_ptr then it might become deprecated. If we implement unique_ptr, we would probably need to handle the case where the C++ compiler does not have unique_ptr implemented. What are your thoughts on this? Perhaps we should move forward on bug #633635 first? This would permit time to think further on the possible use of auto_ptr.
(In reply to comment #1) The software landscape has changed since my initial request on this issue. http://stackoverflow.com/questions/2953530/unique-ptr-boost-equivalent http://hostilefork.com/2009/07/10/smart-pointer-casting-study/ Would we like to reuse the template class "unique_ptr" like Danny Kalev shows in his articles? http://www.devx.com/cplus/10MinuteSolution/39071/1954 http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=401 I would prefer to move some pointer code to attributes before other affected assignments will be moved from constructor bodies to initialisation lists as I suggested an adjustment by bug #633635. Do we also need to clarify copy/move semantics for GParted classes?
Hi Markus, Before we get deep into this conversation I want you to know that I am not an expert on C++ or object oriented languages in general. Most of my background is in procedural languages like C. As such please be patient with me if I make dumb statements or ask questions that should be obvious. If I understand this bug request properly, we have at least three choices: 1) Do nothing. Advantages: Requires no further effort. Code will compile with old and new g++ compilers. Disadvantage: The possibility of memory leaks exists if exceptions are encountered while executing the code. This becomes more important if running in low memory environments, or if gparted is kept running for a long, long time. The memory is recovered when gparted is terminated. 2) Implement auto_ptr. Advantage: Code will compile with old and probably new g++ compilers. Addresses the problem of memory leaks if exceptions are encountered while executing the code. Disadvantages: auto_ptr is deprecated in newer versions of C++. Some uses of auto_ptr can cause a runtime program crash when the behaviour is not as expected. E.g., a move occurs but a copy of pointer was expected. 3) Implement unique_ptr. Advantages: Addresses the problem of memory leaks if exceptions are encountered while executing the code. Addresses the problem of runtime program crashes that can occur when auto_ptr is used. Disadvantage: Only new g++ compilers (v4.4 and higher) support unique_ptr. Option 3 sounds like the best path long term. I am concerned though that older g++ compilers do not support unique_ptr. As such if we add unique_ptr to the code, then people running older GNU/Linux distributions with g++ less than version 4.4 would not be able to compile GParted. The first link in comment #2 indicates that the boost library has a unique_ptr equivalent, but I would prefer not to introduce dependencies on other libraries if it can be avoided. Is there some way to work around this? Perhaps by including a unique_ptr class in GParted that is only used if the g++ compiler is less than version 4.4? Responses to questions from comment #2: Question 1: Would we like to reuse the template class "unique_ptr" like Danny Kalev shows in his articles? Answer 1: Perhaps. It might depend on if there is a way to work around the problem of requiring g++ version 4.4 to be able to use unique_ptr in the code. Question 2: Do we also need to clarify copy/move semantics for GParted classes? Answer 2: I apologize, but I am not sure what you mean by this. Would you be able to explain this question in further detail, or point me to further reading resources?
(In reply to comment #3) > 1) Do nothing. > [...] > Disadvantage: The possibility of memory leaks exists if exceptions are > encountered while executing the code. I do not see so far that this is the case. My feature request is a try for a clarification of acceptable coding style adjustments here. > 2) Implement auto_ptr. I do not see that this is needed because the available implementations can be reused until they will vanish from future C++ compilers. > 3) Implement unique_ptr. I am curious when this new template class will be officially supported by a couple of C++ compilers. http://bartoszmilewski.wordpress.com/2008/10/26/who-ordered-rvalue-references-part-2/ > Option 3 sounds like the best path long term. I am concerned though that older > g++ compilers do not support unique_ptr. As such if we add unique_ptr to the > code, then people running older GNU/Linux distributions with g++ less than > version 4.4 would not be able to compile GParted. I am also curious when such a dependency on a current C++ standard library can be introduced. > Answer 2: I apologize, but I am not sure what you mean by this. Would we like to make any copy constructors private in GParted? Are we going to add any move constructors? (Should the concept of copy and/or move semantics be explicitly expressed in the class library?)
(In reply to comment #3) > Is there some way to work around this? Would you like to reuse the approach by Howard E. Hinnant in the meantime? http://home.roadrunner.com/~hinnant/unique_ptr03.html Is reference counting needed by any GParted class? http://library.gnome.org/devel/glibmm/stable/classGlib_1_1RefPtr.html#_details > Answer 2: [...] Would you be able to explain this question in further detail, > or point me to further reading resources? Are you going to mark any GParted class as non-copyable? http://boost.org/doc/libs/1_44_0/libs/utility/utility.htm#Class_noncopyable http://www.devx.com/cplus/10MinuteSolution/34577/1954 http://www.artima.com/cppsource/rvalue.html http://thbecker.net/articles/rvalue_references/section_01.html http://pizer.wordpress.com/2009/04/13/c0x-do-people-understand-rvalue-references/ http://www.codesynthesis.com/~boris/blog/2008/12/01/rvalue-references-affect-your-code/ http://gcc.gnu.org/projects/cxx0x.html
Thank you again Markus for your questions and these additional information links. While reading through this information I have come to realize that my current level of understanding of C++ is not sufficient to appropriately address this request. This reminds me that I need to increase my knowledge of C++. I need to finish reading Bruce Eckel's first book on Thinking in C++, and then start learning the concepts in his second book. http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html I will need time to accomplish this before I can appropriately respond to this request. Your patience is appreciated. In the interim, if you wish to proceed with bug #633635 then please feel free to do so. Regards, Curtis Gedak
Since gparted does not make use of exceptions, there's no need to bother with this.
(In reply to comment #7) Would you like to be prepared for an exception like "std::bad_alloc"?
No. The only time that is going to happen is if we did something like new char[4000000000]. If we did something like that, then the appropriate thing to do is just crash, which is what would happen.
This request deals with a preference in coding and does not represent an error in the program. Closing this report as NOTABUG.
(In reply to Curtis Gedak from comment #10) > This request deals with a preference in coding and does not represent an > error in the program. Do you care for further useful software evolution? https://en.wikipedia.org/wiki/Smart_pointer#unique_ptr
Please refrain from re-opening this bug report.
(In reply to Curtis Gedak from comment #12) * Can further software improvements be still achieved when such an issue seems to be "closed"? * Do you prefer a continuation for the current situation under a new bug number?