user defined copy operators suppress compiler creation of move operations, and not having all of copy/move/dtor
defined (rule of 0/5) is suspicious. Also happens to be very slightly slower
-- NOTE: ctor was removed because it can't have been in use, and is duplicated by the overload below it. A pair parameter is only optimal in a very limited number of use cases, and then only slightly over the begin/end overload
Users may still want to dereference a const iterator (note: not a const_iterator).
Also use the "reference" typedef to ensure there is only 1 source of information
For rule of 5/0, where no implementation is required, all 5 operations have been declared as defaulted. This is less likely to forget definitions for all 5 if required
- removed forwarding of copy ctor to assignment (which was defaulted already) in favour of defaulted copy ctor
- added defaulted move assignment/ctor and destructor
Users may still want to derederence a const iterator (note: not a const_iterator).
Also use the "reference" typedef to ensure there is only 1 source of information
For rule of 5/0, where no implementation is required, all 5 operations have been declared as defaulted. This is less likely to forget definitions for all 5 if required
- removed forwarding of copy to assignment (which was defaulted already) in favour of defaulted copy ctor
- added defaulted move assignment/ctor and destructor
Detailed reasoning for the deprecation is provided by the paper proposing deprecation (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r2.html) and a related LWG issue (https://cplusplus.github.io/LWG/issue2438).
This was the only issue preventing a clean compile with VS 15.7.2 with c++17/c++latest set as the target language
The issue could be resolved in two ways. Providing a custom replacement to std::iterator (a very simple structure) or by providing the 5 required typedefs. The only functional difference from my reading is that the typedefs are not immediately available to the implementer with the inheritance. I find the inline typedefs to be clearer hence the selection in this commit
workbook::operator== was comparing the value of the raw pointer held by two std::unique_ptr's. By definition, this is always false in a well behaved program (if it's true, things go bang...). This then led to adding equality operators to nearly every other struct/class in xlnt to support workbook::operator==
workbook::load and the non-default ctors for loading data from a file are tested using the now functional equality operator
NOTE: a large number of copy ctors need updates/fixing. Many should be defaulted
-- custom_heights was the only test sheet where the integral value was being saved with a trailing ".0"
-- Updated tests to expect the new values
-- added the new property "defaultColWidth"
-- sqref is a block of selected cells containing the active_cell (normally is just == active_cell)
-- active cell is the selected vell in this selection/view/pane
-- inactive selections use the top-left cell as the active_cell
