`size_bytes()` returns the span's size in bytes.
Assuming the span was constructed with an accurate size parameter, the check `size() < dynamic_extent / sizeof(element_type)` isn't required, since `size_t(-1)` (which is `dynamic_extent`) represents the size of the address space, so the number of bytes will never exceed it and in practice won't even come close.
Otherwise, it is not actually feasible to detect cases when the size parameter does not correspond to the dimensions of the underlying data pointer. In these cases, the relationship `size() < dynamic_extent / sizeof(element_type)` is simply one of many ways in which the `size()` could be incorrect, and serves no necessary purpose.
Resolves#1012
GCC 4.8.0 - 7.0 has a bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480) involving specialization in a namespace enclosing the specialized template. This PR fixes an appearance of this bug in the span header.
Both checks for Expects(ExtentType::size() != dynamic_extent); in storage_type are always useless. storage_type<ExtentType> is only ever created with ExtentType == extent_type<Extent>, where Extent has type std::size_t and is the extent of the span.
Looking at extent_type<std::size_t Ext>::size():
- if Ext != dynamic_extent, then size() always returns Ext, and therefore size() != dynamic_extent
- if Ext == dynamic_extent, then size() returns extent_type<dynamic_extent>::size_. size_ can only be set via one of two constructors:
- constexpr explicit extent_type(size_type size), which already does the check in question
- constexpr explicit extent_type(extent_type<Other> ext) : size_(ext.size()), which simply relies on the other extent's size() method
So there is no way for ExtentType::size() == dynamic_extent.
[SF.12: Prefer the quoted form of #include for files relative to the including file and the angle bracket form everywhere else](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-incform)
Additionally changed #include order in `span` so that all `span_ext` is in the GSL include block and not in the STL include block.
Fixes issues #1025.
Co-authored-by: Werner Henze <w.henze@avm.de>
* move span specialization of 'at' to <gsl/span> and update the parameter to be taken by reference
* undid previous changes and acted upon decisions made in maintainer sync. Fixed tests failing in /kernel mode
* ran clang-format on the include folder
* ran clang-format on the test folder
Co-authored-by: Jordan Maples <jordan.maples@microsoft.com>
* Azure pipeline (#8)
* azure-pipeline test
* nl @ eof
* trimming the pipeline and adding debug steps
* removing redundant lines
* change ctest to script cmd and remove debug
* removed bad char
* added dir change for ctest
* explicit output file and cmake standard
* test cat
* more ctest tests
* injecting failure in test for validation
* another test
* removing bad test
* massive matrix
* added parallel
* commenting everything but xcode out for testing purposes
* uncomment the other tests
* testing some variables
* rename
* changed macos versions
* adding one more layer of templates
* fixing jobs.yml
* idk what i'm doing
* slight modifications
* maybe some spaces will help
* removing 'variables.'
* another test
* adding back pr w/ autocancel
* adding failing test to validate error = failing task
* remove failing test
* trigger master
* nl in steps.yml
* remove forced decay of array reference to pointer in span array ctor
- suppress " warning C26481: Don't use pointer arithmetic. Use span instead (bounds.1)."
- Please note that the suppression in `end()` does not work with MSVC 16.5.4.
VS 2019 doesn't seem to match -1 for size_t template parameter, as a result dynamic span/basic_string_span/basic_zstring_span show extent as `extent = 4294967295` (for 32-bit builds). This change updates details::extent_type to have static constexpr size_ parameter for non-dynamic span/basic_string_span/basic_zstring_span and simplifies/removes dynamic versions from GSL.natvis
fixes#856
