Mirrors
/
gparted
mirror of https://gitlab.gnome.org/GNOME/gparted.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gparted/src/OperationResizeMove.cc

257 lines
8.4 KiB
C++
Raw Normal View History

lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
/* Copyright (C) 2004 Bart 'plors' Hakvoort
Enhance format_size() for sector sizes > 512 bytes
2010-03-23 13:06:26 -06:00
* Copyright (C) 2008, 2009, 2010 Curtis Gedak
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Replace obsolete FSF postal address in copyright notices (#721565) This is part of parent bug: Bug #721455 - Obsolete info in license text on multiple modules and GNOME Goal: https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals * verify all source files to make sure they have a license and a copyright, and that both are up-to-date Bug #721565 - License text contains obsolete FSF postal address
2014-01-23 03:59:48 -07:00
* GNU General Public License for more details.
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
*
* You should have received a copy of the GNU General Public License
Replace obsolete FSF postal address in copyright notices (#721565) This is part of parent bug: Bug #721455 - Obsolete info in license text on multiple modules and GNOME Goal: https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals * verify all source files to make sure they have a license and a copyright, and that both are up-to-date Bug #721565 - License text contains obsolete FSF postal address
2014-01-23 03:59:48 -07:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
*/
Remove "../include/" from GParted header #includes It made the code look a little messy, is easily resolved in the build system and made the dependencies more complicated than needed. Each GParted header was tracked via multiple different names (different numbers of "../include/" prefixes). For example just looking at how DialogFeatures.o depends on Utils.h: $ cd src $ make DialogFeatures.o $ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po ../include/DialogFeatures.h ../include/../include/Utils.h \ ../include/../include/../include/../include/../include/../include/Utils.h \ ../include/../include/../include/Utils.h \ After removing "../include/" from the GParted header #includes, just need to add "-I../include" to the compile command via the AM_CPPFLAGS in src/Makefile.am. Now the dependencies on GParted header files are tracked under a single name (with a single "../include/" prefix). Now DialogFeatures.o only depends on a single name to Utils.h: $ make DialogFeatures.o $ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po ../include/DialogFeatures.h ../include/Utils.h ../include/i18n.h \
2016-10-18 16:45:28 -06:00
#include "OperationResizeMove.h"
#include "Partition.h"
#include "PartitionVector.h"
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
namespace GParted
{
OperationResizeMove::OperationResizeMove( const Device & device,
const Partition & partition_orig,
const Partition & partition_new )
{
renamed some enums * renamed some enums
2006-07-29 09:20:32 -06:00
type = OPERATION_RESIZE_MOVE ;
Shallow copy Device object into Operation object (#750168) When Operation objects are created they take a copy of the Device object to which the operation is to be applied. The Device object includes a vector of all the contained Partition objects currently on the device, so these get copied too. These additional deep copied Partition objects in the Operation object are never accessed. Therefore don't copy the contained Partition objects when copying the Device object into the Operation object. Bug 750168 - Reduce the amount of copying of partition objects
2015-05-24 07:13:37 -06:00
this->device = device.get_copy_without_partitions();
Implement and use virtual Partition copy constructor clone() (#759726) Final step for full polymorphic handling of Partition objects is to implement a virtual copy constructor. C++ doesn't directly support virtual copy constructors, so instead use the virtual copy constructor idiom [1]. (Just a virtual method called clone() which is implemented in every polymorphic class and creates a clone of the current object and returns a pointer to it). Then replace all calls to the (monomorphic) Partition object copy constructor throughout the code, except in the clone() implementation itself, with calls to the new virtual clone() method "virtual copy constructor". Also have to make the Partition destructor virtual too [2][3] so that the derived class destructor is called when deleting using a base class pointer. C++ supports this directly. [1] Wikibooks: More C++ Idioms / Virtual Constructor https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Virtual_Constructor [2] When to use virtual destructors? http://stackoverflow.com/questions/461203/when-to-use-virtual-destructors [3] Virtuality Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual http://www.gotw.ca/publications/mill18.htm Bug 759726 - Implement Partition object polymorphism SQUASH: When first using pointers to Partition and calling delete
2015-12-05 09:26:30 -07:00
this->partition_original = partition_orig.clone();
this->partition_new = partition_new.clone();
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
}
OperationResizeMove::~OperationResizeMove()
{
delete partition_original;
delete partition_new;
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
partition_original = nullptr;
partition_new = nullptr;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
Use PartitionVector class throughout the code (#759726) Replace all occurrences of std::vector<Partition> with PartitionVector. Bug 759726 - Implement Partition object polymorphism
2015-05-23 13:22:37 -06:00
void OperationResizeMove::apply_to_visual( PartitionVector & partitions )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
g_assert(partition_original != nullptr); // Bug: Not initialised by constructor or reset later
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_original->type == TYPE_EXTENDED )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
apply_extended_to_visual( partitions ) ;
else
apply_normal_to_visual( partitions ) ;
}
void OperationResizeMove::create_description()
{
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
g_assert(partition_original != nullptr); // Bug: Not initialised by constructor or reset later
g_assert(partition_new != nullptr); // Bug: Not initialised by constructor or reset later
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
//i'm not too happy with this, but i think it is the correct way from a i18n POV
enum Action
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
NONE = 0,
MOVE_RIGHT = 1,
MOVE_LEFT = 2,
GROW = 3,
SHRINK = 4,
MOVE_RIGHT_GROW = 5,
MOVE_RIGHT_SHRINK = 6,
MOVE_LEFT_GROW = 7,
MOVE_LEFT_SHRINK = 8
} ;
Action action = NONE ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->get_sector_length() > partition_original->get_sector_length() )
{
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
//Grow partition
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
action = GROW ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start > partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_RIGHT_GROW ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start < partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_LEFT_GROW ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
}
else if ( partition_new->get_sector_length() < partition_original->get_sector_length() )
{
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
//Shrink partition
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
action = SHRINK ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start > partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_RIGHT_SHRINK ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start < partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_LEFT_SHRINK ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
}
else
{
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
//No change in partition size
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start > partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_RIGHT ;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_new->sector_start < partition_original->sector_start )
Fixed incorrectly recognized partition move/resize operations svn path=/trunk/; revision=858
2008-06-18 12:30:19 -06:00
action = MOVE_LEFT ;
}
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
switch ( action )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
case NONE :
Replace String::ucompose() with Glibmm equivalent (#46) Glibmm has implemented a ustring::compose() set of methods [1] since Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that GParted already requires glibmm >= 2.32 as set in configure.ac. This commit just replaces all the method calls. Edit created by: sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc [1] Glibmm Reference Manual, Glib::ustring Class, compose() method https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500 Closes #46 - Drop compose subdir
2019-03-25 14:41:08 -06:00
description = Glib::ustring::compose( _("resize/move %1"), partition_original->get_path() );
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
description += " (" ;
Change em dashes to period with new sentence With the em dashes in the translatable strings, a 'make distcheck' would fail. Hence these have been change to be a period followed by a new sentence.
2009-10-26 15:19:04 -06:00
description += _("new and old partition have the same size and position. Hence continuing anyway") ;
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
description += ")" ;
break ;
case MOVE_RIGHT :
Replace String::ucompose() with Glibmm equivalent (#46) Glibmm has implemented a ustring::compose() set of methods [1] since Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that GParted already requires glibmm >= 2.32 as set in configure.ac. This commit just replaces all the method calls. Edit created by: sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc [1] Glibmm Reference Manual, Glib::ustring Class, compose() method https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500 Closes #46 - Drop compose subdir
2019-03-25 14:41:08 -06:00
description = Glib::ustring::compose( _("Move %1 to the right"), partition_original->get_path() );
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
break ;
case MOVE_LEFT :
Replace String::ucompose() with Glibmm equivalent (#46) Glibmm has implemented a ustring::compose() set of methods [1] since Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that GParted already requires glibmm >= 2.32 as set in configure.ac. This commit just replaces all the method calls. Edit created by: sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc [1] Glibmm Reference Manual, Glib::ustring Class, compose() method https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500 Closes #46 - Drop compose subdir
2019-03-25 14:41:08 -06:00
description = Glib::ustring::compose( _("Move %1 to the left"), partition_original->get_path() );
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
break ;
case GROW :
description = _("Grow %1 from %2 to %3") ;
break ;
case SHRINK :
description = _("Shrink %1 from %2 to %3") ;
break ;
case MOVE_RIGHT_GROW :
description = _("Move %1 to the right and grow it from %2 to %3") ;
break ;
case MOVE_RIGHT_SHRINK :
description = _("Move %1 to the right and shrink it from %2 to %3") ;
break ;
case MOVE_LEFT_GROW :
description = _("Move %1 to the left and grow it from %2 to %3") ;
break ;
case MOVE_LEFT_SHRINK :
description = _("Move %1 to the left and shrink it from %2 to %3") ;
break ;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
lots of fixes and improvements (mostly move-related) * lots of fixes and improvements (mostly move-related)
2006-07-11 12:13:27 -06:00
if ( ! description .empty() && action != NONE && action != MOVE_LEFT && action != MOVE_RIGHT )
Replace String::ucompose() with Glibmm equivalent (#46) Glibmm has implemented a ustring::compose() set of methods [1] since Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that GParted already requires glibmm >= 2.32 as set in configure.ac. This commit just replaces all the method calls. Edit created by: sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc [1] Glibmm Reference Manual, Glib::ustring Class, compose() method https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500 Closes #46 - Drop compose subdir
2019-03-25 14:41:08 -06:00
description = Glib::ustring::compose( description,
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
partition_original->get_path(),
Utils::format_size( partition_original->get_sector_length(),
partition_original->sector_size ),
Utils::format_size( partition_new->get_sector_length(),
partition_new->sector_size ) );
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
Use PartitionVector class throughout the code (#759726) Replace all occurrences of std::vector<Partition> with PartitionVector. Bug 759726 - Implement Partition object polymorphism
2015-05-23 13:22:37 -06:00
void OperationResizeMove::apply_normal_to_visual( PartitionVector & partitions )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
g_assert(partition_original != nullptr); // Bug: Not initialised by constructor or reset later
g_assert(partition_new != nullptr); // Bug: Not initialised by constructor or reset later
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
Replace Operation class members index and index_extended with local variables (#755214) These member variables store no Operation class information and were being used as local variables. Replace with local variables. Also indent a code block within an if clause so that the compiler can confirm that the new local variable isn't used uninitialised. Prevents this compiler warning: OperationResizeMove.cc: In member function 'void GParted::OperationResizeMove::apply_normal_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)': OperationResizeMove.cc:125: warning: 'index' may be used uninitialized in this function Bug 755214 - Refactor operation merging
2015-09-27 02:30:13 -06:00
int index_extended;
int index;
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
if ( partition_original->inside_extended )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
Create and use general find_extended_partition() function The Operation class already provided find_index_extended() method and was used in the Operation and derived classes where required. It returns the index to the extended partition in the PartitionVector object, or -1 when no extended partition exists. There were several cases of the same functionality being open coded in GParted_Core and Win_GParted. Therefore move the implementation to find_extended_partition() in PartitionVector compilation unit and use this implementation everywhere.
2016-08-21 04:56:51 -06:00
index_extended = find_extended_partition( partitions );
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
if ( index_extended >= 0 )
{
Replace Operation class members index and index_extended with local variables (#755214) These member variables store no Operation class information and were being used as local variables. Replace with local variables. Also indent a code block within an if clause so that the compiler can confirm that the new local variable isn't used uninitialised. Prevents this compiler warning: OperationResizeMove.cc: In member function 'void GParted::OperationResizeMove::apply_normal_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)': OperationResizeMove.cc:125: warning: 'index' may be used uninitialized in this function Bug 755214 - Refactor operation merging
2015-09-27 02:30:13 -06:00
index = find_index_original( partitions[ index_extended ] .logicals ) ;
if ( index >= 0 )
{
Replace all Partition object copy assignment (#759726) Copy assignment of Partition objects is now only performed in a few places in the Operation and OperationResizeMove classes when updating the displayed PartitionVector. (From Refresh_Visual() when each operation is visually applied to the display_partitions vector; the new_partition from the operation is copy assigned over the top of the relevant existing partition in the display_partitions vector). In general polymorphic copy assignment is complicated [1], and is now unnecessary given the above limited use. All that is needed is a way to polymorphically replace one Partition object with another in a PartitionVector. First, prevent further use of Partition object copy assignment by providing a private declaration and no implementation, so the compiler enforces this. Second implement and use PartitionVector method replace_at() which replaces a pointer to one Partition object with another at the specified index in the PartitionVector. [1] The Assignment Operator Revisited [Section:] Virtual assignment http://icu-project.org/docs/papers/cpp_report/the_assignment_operator_revisited.html Bug 759726 - Implement Partition object polymorphism
2015-12-20 04:28:09 -07:00
partitions[index_extended].logicals.replace_at( index, partition_new );
Replace Operation class members index and index_extended with local variables (#755214) These member variables store no Operation class information and were being used as local variables. Replace with local variables. Also indent a code block within an if clause so that the compiler can confirm that the new local variable isn't used uninitialised. Prevents this compiler warning: OperationResizeMove.cc: In member function 'void GParted::OperationResizeMove::apply_normal_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)': OperationResizeMove.cc:125: warning: 'index' may be used uninitialized in this function Bug 755214 - Refactor operation merging
2015-09-27 02:30:13 -06:00
remove_adjacent_unallocated( partitions[index_extended].logicals, index );
insert_unallocated( partitions[index_extended].logicals,
partitions[index_extended].sector_start,
partitions[index_extended].sector_end,
device.sector_size,
true );
}
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
}
else
{
index = find_index_original( partitions ) ;
if ( index >= 0 )
{
Replace all Partition object copy assignment (#759726) Copy assignment of Partition objects is now only performed in a few places in the Operation and OperationResizeMove classes when updating the displayed PartitionVector. (From Refresh_Visual() when each operation is visually applied to the display_partitions vector; the new_partition from the operation is copy assigned over the top of the relevant existing partition in the display_partitions vector). In general polymorphic copy assignment is complicated [1], and is now unnecessary given the above limited use. All that is needed is a way to polymorphically replace one Partition object with another in a PartitionVector. First, prevent further use of Partition object copy assignment by providing a private declaration and no implementation, so the compiler enforces this. Second implement and use PartitionVector method replace_at() which replaces a pointer to one Partition object with another at the specified index in the PartitionVector. [1] The Assignment Operator Revisited [Section:] Virtual assignment http://icu-project.org/docs/papers/cpp_report/the_assignment_operator_revisited.html Bug 759726 - Implement Partition object polymorphism
2015-12-20 04:28:09 -07:00
partitions.replace_at( index, partition_new );
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
remove_adjacent_unallocated( partitions, index ) ;
Set sector size and add to operation and dialog methods This change is in preparation for supporting sectors sizes > 512 bytes.
2010-04-19 19:22:31 -06:00
insert_unallocated( partitions, 0, device .length -1, device .sector_size, false ) ;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
}
}
Use PartitionVector class throughout the code (#759726) Replace all occurrences of std::vector<Partition> with PartitionVector. Bug 759726 - Implement Partition object polymorphism
2015-05-23 13:22:37 -06:00
void OperationResizeMove::apply_extended_to_visual( PartitionVector & partitions )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
g_assert(partition_new != nullptr); // Bug: Not initialised by constructor or reset later
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
Replace Operation class members index and index_extended with local variables (#755214) These member variables store no Operation class information and were being used as local variables. Replace with local variables. Also indent a code block within an if clause so that the compiler can confirm that the new local variable isn't used uninitialised. Prevents this compiler warning: OperationResizeMove.cc: In member function 'void GParted::OperationResizeMove::apply_normal_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)': OperationResizeMove.cc:125: warning: 'index' may be used uninitialized in this function Bug 755214 - Refactor operation merging
2015-09-27 02:30:13 -06:00
int index_extended;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
//stuff OUTSIDE extended partition
Create and use general find_extended_partition() function The Operation class already provided find_index_extended() method and was used in the Operation and derived classes where required. It returns the index to the extended partition in the PartitionVector object, or -1 when no extended partition exists. There were several cases of the same functionality being open coded in GParted_Core and Win_GParted. Therefore move the implementation to find_extended_partition() in PartitionVector compilation unit and use this implementation everywhere.
2016-08-21 04:56:51 -06:00
index_extended = find_extended_partition( partitions );
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
if ( index_extended >= 0 )
{
remove_adjacent_unallocated( partitions, index_extended ) ;
Create and use general find_extended_partition() function The Operation class already provided find_index_extended() method and was used in the Operation and derived classes where required. It returns the index to the extended partition in the PartitionVector object, or -1 when no extended partition exists. There were several cases of the same functionality being open coded in GParted_Core and Win_GParted. Therefore move the implementation to find_extended_partition() in PartitionVector compilation unit and use this implementation everywhere.
2016-08-21 04:56:51 -06:00
index_extended = find_extended_partition( partitions );
fixed another issue in apply_to_visual(), this time with resizing/moveing * src/OperationResizeMove.cc: fixed another issue in apply_to_visual(), this time with resizing/moveing the extended partition.
2006-04-01 07:36:16 -07:00
if ( index_extended >= 0 )
{
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
partitions[index_extended].sector_start = partition_new->sector_start;
partitions[index_extended].sector_end = partition_new->sector_end;
fixed another issue in apply_to_visual(), this time with resizing/moveing * src/OperationResizeMove.cc: fixed another issue in apply_to_visual(), this time with resizing/moveing the extended partition.
2006-04-01 07:36:16 -07:00
}
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
Set sector size and add to operation and dialog methods This change is in preparation for supporting sectors sizes > 512 bytes.
2010-04-19 19:22:31 -06:00
insert_unallocated( partitions, 0, device .length -1, device .sector_size, false ) ;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
//stuff INSIDE extended partition
Create and use general find_extended_partition() function The Operation class already provided find_index_extended() method and was used in the Operation and derived classes where required. It returns the index to the extended partition in the PartitionVector object, or -1 when no extended partition exists. There were several cases of the same functionality being open coded in GParted_Core and Win_GParted. Therefore move the implementation to find_extended_partition() in PartitionVector compilation unit and use this implementation everywhere.
2016-08-21 04:56:51 -06:00
index_extended = find_extended_partition( partitions );
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
if ( index_extended >= 0 )
{
if ( partitions[ index_extended ] .logicals .size() > 0 &&
Strip unnecessary scope from GParted::TYPE_* (!20) The code inconsistently uses GParted:: scope in front of TYPE_*. $ fgrep 'GParted::TYPE_' src/*.cc | wc -l 35 $ egrep '[^:]TYPE_' src/*.cc | wc -l 83 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups
2018-10-14 06:27:58 -06:00
partitions[index_extended].logicals.front().type == TYPE_UNALLOCATED )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
partitions[ index_extended ] .logicals .erase( partitions[ index_extended ] .logicals .begin() ) ;
if ( partitions[ index_extended ] .logicals .size() &&
Strip unnecessary scope from GParted::TYPE_* (!20) The code inconsistently uses GParted:: scope in front of TYPE_*. $ fgrep 'GParted::TYPE_' src/*.cc | wc -l 35 $ egrep '[^:]TYPE_' src/*.cc | wc -l 83 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups
2018-10-14 06:27:58 -06:00
partitions[index_extended].logicals.back().type == TYPE_UNALLOCATED )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
partitions[ index_extended ] .logicals .pop_back() ;
insert_unallocated( partitions[ index_extended ] .logicals,
partitions[ index_extended ] .sector_start,
partitions[ index_extended ] .sector_end,
Set sector size and add to operation and dialog methods This change is in preparation for supporting sectors sizes > 512 bytes.
2010-04-19 19:22:31 -06:00
device .sector_size,
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
true ) ;
}
}
Use PartitionVector class throughout the code (#759726) Replace all occurrences of std::vector<Partition> with PartitionVector. Bug 759726 - Implement Partition object polymorphism
2015-05-23 13:22:37 -06:00
void OperationResizeMove::remove_adjacent_unallocated( PartitionVector & partitions, int index_orig )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
{
//remove unallocated space following the original partition
if ( index_orig +1 < static_cast<int>( partitions .size() ) &&
Strip unnecessary scope from GParted::TYPE_* (!20) The code inconsistently uses GParted:: scope in front of TYPE_*. $ fgrep 'GParted::TYPE_' src/*.cc | wc -l 35 $ egrep '[^:]TYPE_' src/*.cc | wc -l 83 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups
2018-10-14 06:27:58 -06:00
partitions[index_orig+1].type == TYPE_UNALLOCATED )
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
partitions .erase( partitions .begin() + index_orig +1 );
trivial cleanups fixed a glitch in apply_to_visual() accept returnvalues * src/GParted_Core.cc: trivial cleanups * src/OperationResizeMove.cc: fixed a glitch in apply_to_visual() * src/ext2.cc, src/ext3.cc: accept returnvalues 0, 1 and 2 instead of 0 and 1
2006-03-31 11:58:58 -07:00
//remove unallocated space preceding the original partition
Strip unnecessary scope from GParted::TYPE_* (!20) The code inconsistently uses GParted:: scope in front of TYPE_*. $ fgrep 'GParted::TYPE_' src/*.cc | wc -l 35 $ egrep '[^:]TYPE_' src/*.cc | wc -l 83 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups
2018-10-14 06:27:58 -06:00
if (index_orig-1 >= 0 && partitions[index_orig-1].type == TYPE_UNALLOCATED)
trivial cleanups fixed a glitch in apply_to_visual() accept returnvalues * src/GParted_Core.cc: trivial cleanups * src/OperationResizeMove.cc: fixed a glitch in apply_to_visual() * src/ext2.cc, src/ext3.cc: accept returnvalues 0, 1 and 2 instead of 0 and 1
2006-03-31 11:58:58 -07:00
partitions .erase( partitions .begin() + ( index_orig -1 ) ) ;
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
}
Encapsulate operation merging inside the Operation* classes (#755214) Win_GParted::Merge_Operations() method was modifying the internals of Operation* objects; in particular the partition_new member variable. This is breaking data hiding and encapsulation tenant of object oriented programming. Implement exactly the same operation merge semantics, but hide the manipulation of the internals of the Operation* objects within the Operation* classes themselves. Bug 755214 - Refactor operation merging
2015-09-12 07:59:40 -06:00
bool OperationResizeMove::merge_operations( const Operation & candidate )
{
C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation
2023-08-31 14:08:59 -06:00
g_assert(partition_new != nullptr); // Bug: Not initialised by constructor or reset later
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
Protect partition members within Operation classes (#759726) The Operation classes contain partition objects which are copied by value. Need to replace these with pointers to Partition objects instead and manage their lifetimes so that they can be used polymorphically. First step is to protect the partition members partition_new, partition_original, and for OperationCopy class only, partition_copied within the Operation classes and provide accessor methods. get_partition_new() and get_partition_original() accessors are implemented in the Operation base class so all derived classes get an implementation. get_partition_new() is also virtual so that OperationCheck and OperationDelete can override the implementation and assert that they don't use partition_new. get_partition_copied() is provided for the OperationCopy class only so can only be accessed via an OperationCopy type variable. Bug 759726 - Implement Partition object polymorphism
2015-09-19 08:57:39 -06:00
if ( candidate.type == OPERATION_RESIZE_MOVE &&
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
*partition_new == candidate.get_partition_original() )
Encapsulate operation merging inside the Operation* classes (#755214) Win_GParted::Merge_Operations() method was modifying the internals of Operation* objects; in particular the partition_new member variable. This is breaking data hiding and encapsulation tenant of object oriented programming. Implement exactly the same operation merge semantics, but hide the manipulation of the internals of the Operation* objects within the Operation* classes themselves. Bug 755214 - Refactor operation merging
2015-09-12 07:59:40 -06:00
{
Use pointers to Partitions in Operation classes (#759726) Operation classes now internally use pointers to Partition objects and take on management of their lifetimes. As before, with the PartitionVector class, when storing pointers in a class the Big 3 of destructor, copy constructor and copy assignment operator also have to be considered. First, all the Partition objects are allocated in the derived Operation* class parameterised constructors and freed in the associated destructors. However the Operation classes are never copy constructed or copy assigned; they are only ever created and destroyed. Only pointers to the derived Operations are copied into the vector of pending operations. Therefore the copy construtor and copy assignment operator aren't needed. To enforce this provide inaccessible private declarations without any implementation so that the compiler will enforce this [1][2]. This example code fragment: 1 OperationCheck o1( device, partition ); 2 OperationCheck o2 = o1; 3 o2 = o1; Does these OperationCheck calls: 1 Implemented parameterised construtor, 2 Disallowed copy constructor, 3 Disallowed copy assignment Trying to compile the above code would fail with errors like these: ../include/OperationCheck.h: In member function 'void GParted::Win_GParted::activate_check()': ../include/OperationCheck.h:36:2: error: 'GParted::OperationCheck::OperationCheck(const GParted::OperationCheck&)' is private OperationCheck( const OperationCheck & src ); // Not implemented copy constructor ^ test.cc:2:21: error: within this context OperationCheck o2 = o1; ^ ../include/OperationCheck.h:37:19: error: 'GParted::OperationCheck& GParted::OperationCheck::operator=(const GParted::OperationCheck&)' is private OperationCheck & operator=( const OperationCheck & rhs ); // Not implemented copy assignment operator ^ test.cc:3:4: error: within this context o2 = o1; ^ [1] Disable copy constructor http://stackoverflow.com/questions/6077143/disable-copy-constructor [2] Disable compiler-generated copy-assignment operator [duplicate] http://stackoverflow.com/questions/7823845/disable-compiler-generated-copy-assignment-operator Bug 759726 - Implement Partition object polymorphism
2015-09-20 03:50:57 -06:00
delete partition_new;
Implement and use virtual Partition copy constructor clone() (#759726) Final step for full polymorphic handling of Partition objects is to implement a virtual copy constructor. C++ doesn't directly support virtual copy constructors, so instead use the virtual copy constructor idiom [1]. (Just a virtual method called clone() which is implemented in every polymorphic class and creates a clone of the current object and returns a pointer to it). Then replace all calls to the (monomorphic) Partition object copy constructor throughout the code, except in the clone() implementation itself, with calls to the new virtual clone() method "virtual copy constructor". Also have to make the Partition destructor virtual too [2][3] so that the derived class destructor is called when deleting using a base class pointer. C++ supports this directly. [1] Wikibooks: More C++ Idioms / Virtual Constructor https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Virtual_Constructor [2] When to use virtual destructors? http://stackoverflow.com/questions/461203/when-to-use-virtual-destructors [3] Virtuality Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual http://www.gotw.ca/publications/mill18.htm Bug 759726 - Implement Partition object polymorphism SQUASH: When first using pointers to Partition and calling delete
2015-12-05 09:26:30 -07:00
partition_new = candidate.get_partition_new().clone();
Encapsulate operation merging inside the Operation* classes (#755214) Win_GParted::Merge_Operations() method was modifying the internals of Operation* objects; in particular the partition_new member variable. This is breaking data hiding and encapsulation tenant of object oriented programming. Implement exactly the same operation merge semantics, but hide the manipulation of the internals of the Operation* objects within the Operation* classes themselves. Bug 755214 - Refactor operation merging
2015-09-12 07:59:40 -06:00
create_description();
return true;
}
return false;
}
lots of cleanups in operationhandling. This resulted in cleaner/less code * lots of cleanups in operationhandling. This resulted in cleaner/less code and the fixing of some longstanding issues.
2006-03-24 12:08:41 -07:00
} //GParted