Without this change a `gsl::not_null<class_type>` triggers these `noexcept` warnings:
```
.../gsl/include/gsl/pointers:162:50: warning: noexcept-expression evaluates to ‘false’ because of a call to ‘constexpr gsl::details::value_or_reference_return_t<T> gsl::not_null<T>::get() const [with T = class_type*; gsl::details::value_or_reference_return_t<T> = class_type* const]’ [-Wnoexcept]
162 | const not_null<U>& rhs) noexcept(noexcept(lhs.get() == rhs.get()))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../gsl/include/gsl/pointers:119:55: note: but ‘constexpr gsl::details::value_or_reference_return_t<T> gsl::not_null<T>::get() const [with T = class_type*; gsl::details::value_or_reference_return_t<T> = class_type* const]’ does not throw; perhaps it should be declared ‘noexcept’
119 | constexpr details::value_or_reference_return_t<T> get() const
| ^~~
```
Co-authored-by: Werner Henze <w.henze@avm.de>
Headers that were previously prefixed with `gsl_` were renamed to drop the `gsl_` prefix in https://github.com/microsoft/GSL/pull/946, and the original version deprecated.
The deprecation happened a long time ago, so it is now time to remove these headers entirely.
Turns out supporting GSL.natvis perfectly is quite difficult.
There is no universal way to consume .natvis files that would satisfy everyone.
I thought the solution was to use the /NATVIS linker option. But it turns out that actually embeds information into the PDB. So I'm not sure how to properly support the Ninja generator...
That's not even accounting for the fact target_link_options doesn't play nicely with /NATVIS
When you just add the file via target_sources the visual studio solution will just pick it up and recognize it without adding it to the PDB file. Which won't affect the binary and is what most devs want.
This all comes down to the fact that /NATVIS files have native integration with visual studio that makes it difficult to use with non-visual studio solutions. /NATVIS almost works but embeds itself into the PDB which not everyone wants, and not everyone generates PDBs either.
Docs for natvis files and /NATVIS
- https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022
- https://learn.microsoft.com/en-us/cpp/build/reference/natvis-add-natvis-to-pdb?view=msvc-170
So my current solution is to just simplify the existing CMake code, and install the natvis so the user can decide.
closes#1084
Using `<`,`<=`,`>`,`>=` to compare unrelated pointers gives an unspecified result according to the standard.
This PR replaces the usage of these operators in `gsl::not_null` with the STL counterparts, which would leverage any implementation-defined strict total ordering for pointers.
Resolves#880
`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
The `#i13-do-not-pass-an-array-as-a-single-pointer` anchor seems to be auto generated based on the title of the section. The `#Ri-array` anchor is explicitely written in the source, so this should be a better link.
https://github.com/microsoft/GSL/issues/1075
- Add `static_assert` because we only support C style array `at` for up to half of the address space.
- Add `std::` before `size_t`.
- tests:
- Add `#include <exception>`
- Implement `span_tests` `interop_with_gsl_at` like `at_tests` `std_span`
Add a `linguist-language` Git attribute that matches the files at `include/gsl` and sets their language to C++. Without this override, these files are not detected as C++ code by [GitHub's Linguist](https://github.com/github/linguist) (likely due to lacking any file extensions).
This will cause GitHub.com to count these files correctly as C++ code and do syntax highlighting when browsing the repo.
**Linguist breakdown results**
Before:
<details>
```
$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) -t linguist github-linguist --breakdown
91.57% 152148 C++
8.43% 14011 CMake
CMake:
CMakeLists.txt
cmake/gsl_functions.cmake
cmake/gsl_install.cmake
include/CMakeLists.txt
tests/CMakeLists.txt
C++:
tests/algorithm_tests.cpp
tests/assertion_tests.cpp
tests/at_tests.cpp
tests/byte_tests.cpp
tests/deathTestCommon.h
tests/no_exception_ensure_tests.cpp
tests/notnull_tests.cpp
tests/owner_tests.cpp
tests/span_compatibility_tests.cpp
tests/span_ext_tests.cpp
tests/span_tests.cpp
tests/strict_notnull_tests.cpp
tests/utils_tests.cpp
```
</details>
After:
<details>
```
$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) -t linguist github-linguist --breakdown
94.16% 225699 C++
5.84% 14011 CMake
CMake:
CMakeLists.txt
cmake/gsl_functions.cmake
cmake/gsl_install.cmake
include/CMakeLists.txt
tests/CMakeLists.txt
C++:
include/gsl/algorithm
include/gsl/assert
include/gsl/byte
include/gsl/gsl
include/gsl/gsl_algorithm
include/gsl/gsl_assert
include/gsl/gsl_byte
include/gsl/gsl_narrow
include/gsl/gsl_util
include/gsl/narrow
include/gsl/pointers
include/gsl/span
include/gsl/span_ext
include/gsl/string_span
include/gsl/util
tests/algorithm_tests.cpp
tests/assertion_tests.cpp
tests/at_tests.cpp
tests/byte_tests.cpp
tests/deathTestCommon.h
tests/no_exception_ensure_tests.cpp
tests/notnull_tests.cpp
tests/owner_tests.cpp
tests/span_compatibility_tests.cpp
tests/span_ext_tests.cpp
tests/span_tests.cpp
tests/strict_notnull_tests.cpp
tests/utils_tests.cpp
```
</details>
- `fail_fast`,`basic_string_span` and `basic_zstring_span` are not declared in the headers any more.
- Name the exporting header file for all types in `GSL.natvis`.
This solves issue #1070 and removes the class `string_span`. The only content remaining in the header file `gsl/string_span` is the `*zstring` types.
This also removes the `string_span_tests.cpp` unit tests as these were only for the deprecated `string_span` class.
Co-authored-by: Werner Henze <werner.henze+gitcommits@posteo.de>
Guidelines issue 2006 removes the null check inside not_null::get, since the contained pointer is already guaranteed to be not-null upon construction.
Resolves#1051
The Clang compiler for MSVC in Visual Studio 2022 17.4.33122.133 used by the test runner has a bug which raises -Wdeprecated "out-of-line definition of constexpr static data member is redundant in C++17 and is deprecated" in gsl/span, when compiling with C++14. Temporarily suppress this warning for MSVC Clang with C++14.
This avoids propagating -std=c++14 as a compile option
Currently if you use less than CMake 3.8 and you install the project
`-std=c++14` gets added to the INTERFACE_COMPILE_OPTIONS. This forces
users to use C++ 14 or remove the property from the imported target.
The solution is to raise the minimum and use `cxx_std_14`
- Move all install logic inside gsl_install.cmake
- This makes reading the logic easier, and avoids the enable language
issue with `GNUInstallDirs` by having it included after the project
call
- Have all functions inside gsl_functions.cmake
- Use CMake idiom PROJECT_IS_TOP_LEVEL
- Update README.md
Closes issue #550, which highlighted overhead in not_null::get for larger types such as shared_ptr. Every call to get would return a copy of the contained value.
This PR implements Herb's suggestion for changing the return type of not_null::get. The not_null's value will now only be copied if it is "trivially copyable"; otherwise, it will be returned by const reference.
Note: this change also forces the returned copy to be const.
Somewhere along the way, GSL's implementation of final_act and finally seems to have become way overthought. This PR is to re-simplify these facilities back to what C++ Core Guidelines C.30 said which is simple and clear and works. It just copies the invocable thing, and doesn't bother trying to optimize the copy. This should be fine, because we're typically passing something that's cheap to copy, often a stateless lambda.
The problem in #846 appears to be because finally looks like was originally written as a const&/&& overload (its state at the time that issue was opened)... to eliminate a copy when you invoke it with a temporary. If so, then the && was probably never intended to be a forwarder, but an rvalue reference that tripped over the horrid C++ syntax collision where a && parameter magically instead means a forwarding reference because the type happens to be a template parameter type here. So I suspect the original author was just trying to write an rvalue overload, and the forwarder that's there now was never intended at all.
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.
This file uses std::exception, so it should include the appropriate header.
Normally it gets the STL's <exception> header included via the gsl/assert file, but this is skipped with _HAS_EXCEPTIONS=0. I understand _HAS_EXCEPTIONS is undocumented and unsupported, but regardless, the appropriate header should be included here.
Alternatively, gsl/narrow should be modified to support _HAS_EXCEPTIONS=0, like gsl/assert was. But I'm not proposing that change. <exception> does define std::exception even with _HAS_EXCEPTIONS=0.
In the implementation of gsl::narrow, there is a comparison `static_cast<U>(t) != u` which may be comparing two floats.
The comparison here is done purposefully to categorize ill effects of narrowing conversion, since the values being compared *should* be the same when compared with `operator==`.
Note, using #pragma GCC will suppress this warning for both GCC and Clang.
The following reserved identifiers are being used specifically to target certain MSVC constructs, so suppress the warning in VS 2022 (LLVM) "... is reserved because it starts with '_' followed by a capital letter":
- _Unchecked_type
- _Verify_range
- _Verify_offset
- _Unwrapped
- _Unwrap_when_unverified
- _Seek_to
- _Unchecked_begin
- _Unchecked_end
