Hello,

I use a small simple class that takes a pointer and a size for wrapping normal arrays, quite the same what array_view is designed to solve in a much more generic fashion. I found a drawback compared to using a simple class, and that is that array_view does not work with incomplete classes. I dont know if its possible to fix this via templates specialization and sfinae voodoo, but would be really nice if this use-case is covered aswell

#include <array_view.h>
class CIncomplete;

void foo(gsl::array_view<CIncomplete> s); // OK
gsl::array_view<CIncomplete> s; // Not OK (says clang 3.6 and gcc 5.1 )

I started trying to convert some code that provides safety / convenience wrappers around D3D API calls over to use gsl::array_view and ran into a problem that means I can't support the interface I want. I have calling code that looks like this:

// defined somewhere 
Microsoft::WRL::ComPtr<ID3D11DeviceContext> context;
Micrsofot::WRL::ComPtr<ID3D11Buffer> vertices;
UINT stride;

// calling code somewhere else
IASetVertexBuffers(context, 0, {vertices.Get()}, {stride});

And a wrapper around ID3D11DeviceContext::IASetVertexBuffers() with signature:

void IASetVertexBuffers(
  [in]                 UINT                StartSlot,
  [in]                 UINT                NumBuffers,
  [in, optional]       ID3D11Buffer *const *ppVertexBuffers,
  [in, optional] const UINT                *pStrides,
  [in, optional] const UINT                *pOffsets
);

That currently looks like this:

template <typename Context, typename Buffers = std::initializer_list<ID3D11Buffer*>,
          typename Strides = std::initializer_list<UINT>>
void IASetVertexBuffers(const Context& context, unsigned startSlot, const Buffers& buffers,
                        const Strides& strides) {
    UINT offsets[D3D11_IA_VERTEX_INPUT_RESOURCE_SLOT_COUNT] = {};
    context->IASetVertexBuffers(UINT(startSlot), UINT(std::size(buffers)), std::begin(buffers),
                                std::begin(strides), std::begin(offsets));
};

This wrapper lets me directly pass a braced init list as an argument for buffers and strides (the default std::initializer_list template arguments allow the compiler to deduce the type correctly in this case) or any other Container type that supports begin() and end().

I'd like to convert the buffers and strides parameters to gsl::array_views over the appropriate types. Currently however gsl::array_view has no constructor taking an std::initializer_list which means I can't get my desired call-site syntax of directly passing a braced init list and having a gsl::array_view implicitly constructed from it. I could write my own as_array_view helper but I hate unnecessary typing at the call site :-)

I think a gsl::array_view constructor taking an std::initializer_list would give me the call syntax I'd like but I may be missing some subtlety that means that wouldn't work. Still, one way or another I'd like to be able to directly pass braced init lists to functions taking a gsl::array_view of the corresponding type.

Since 2fc94db3ebfb1b066edeafac1837f34d6111bff4, this program does not work anymore without explicit cast to not_null (here tested with clang 5.0.2 on linux with -std=c++14):

#include <gsl/pointers>
#include <iostream>

void f(gsl::not_null<const int *> i) {
  std::cout << *i << '\n';
}

int main() {
  int i = 42;
  f(&i); // no matching function for call to 'f'
         // note: candidate function not viable: no known conversion from 'int *' to 'gsl::not_null<const int *>' for 1st argument
  return 0;
}

If this is really wanted, could you explain why?

Kind regards

It seems to me that offering a conversion from T to not_null<T> looses the potential to detect certain bugs at compile-time.

if I have a function that returns a raw (potentially null) pointer, and I carelessly pass it to a function taking not_null it will compile fine, and will try report a bug at run-time when it is likely too late.

Instead, if the constructor from T were explicit, an inadvertent assignment:

use_ptr(make_ptr());

would be impossible, and I would be forced to explicitly require a potentially unsafe conversion:

use_ptr(not_null<T>{make_ptr()});

This would be a kind of the signature: by writing this cast, I am taking the responsibility for guaranteeing that the raw pointer will not be null. If it is not the case, you will know that I did it consciously.

See also CppCoreGuidelines issue: https://github.com/isocpp/CppCoreGuidelines/issues/767

Guidelines Support Library shorthand "GSL" if will get widespread could be ambiguous in projects that use GNU Scientific Library (shorthand is GSL). Namespace gsl:: is used for some C++ wrappers for GNU Scientific Library. Same goes for macro prefixed with GSL_. Related to #9 #38

You have this -

#if _MSC_VER < 1910 #pragma push_macro("constexpr") #define constexpr /constexpr/ #define GSL_USE_STATIC_CONSTEXPR_WORKAROUND #endif // _MSC_VER < 1910 #else // _MSC_VER // See if we have enough C++17 power to use a static constexpr data member // without needing an out-of-line definition #if !(defined(__cplusplus) && (__cplusplus >= 201703L)) #define GSL_USE_STATIC_CONSTEXPR_WORKAROUND #endif // !(defined(__cplusplus) && (__cplusplus >= 201703L)) #endif // _MSC_VER

Which will fail, because Visual Studio doesn't correctly set __cplusplus value.

A correct, cross-platform way to do this can be found in https://github.com/dcleblanc/SafeInt/commits/master/SafeInt.hpp from lines 19-128

I don't assert that my approach in SafeInt is ideal, but it definitely works, I've tested it.

The current implementations of array_view's as_bytes() and as_writeable_bytes() do this:

// as_bytes()
return { reinterpret_cast<const byte*>(this->data()), this->bytes() };
// as_writeable_bytes()
return { reinterpret_cast<byte*>(this->data()), this->bytes() };

Where byte is defined as:

enum class byte : std::uint8_t {};

This appears to invoke undefined behaviour if the array_view is used to access memory as per 3.10.10:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

• the dynamic type of the object,
• a cv-qualified version of the dynamic type of the object,
• a type similar (as defined in 4.4) to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
• an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union),
• a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
• a char or unsigned char type.

The usual get-out for this type of operation is the bolded clause (you are allowed to access any memory via a pointer to char or unsigned char) however I don't believe this applies because a) uint8_t is not guaranteed to be a typedef for either char or unsigned char (18.4.1):

typedef unsigned integer type uint8_t; // optional

and b) an enum is a distinct type even if its storage is specified as a char type (7.2.1):

An enumeration is a distinct type (3.9.2) with named constants.

It's possible there is language elsewhere in the standard that makes this code not undefined behaviour but I can't find anything that would seem to make this well defined.

I am trying to use this in an other project which compiles without exception support.
I would not mind substituting the exceptions with asserts, and let it fire only in debug.

currently I use only the <gsl/span> header, my problem lies in <gsl/gsl_util>.
Could we get something like:

#if defined ( __cpp_exceptions) || \
        (defined (_MSC_VER) && defined (__CPPUNWIND)) || \
        (defined (__GNUC__) && defined (__EXCEPTIONS))
    #define ABORT_THROW (x) throw x
#else
    #define ABORT_THROW (x) (x, std::abort())
#endif

and then use ABORT_THROW when needed?

I tried using gsl with Intel compiler 16 under SUSE Linux Enterprise Server 11 SP4 and got a

icpc ../main.cpp -o test -std=c++14
In file included from ../gsl/multi_span(23),
             from ../gsl/gsl(24),
             from ../main.cpp(1):
../gsl/gsl_byte(78): error #3377: constexpr function return is non-constant
    return l = byte(static_cast<unsigned char>(l) | static_cast<unsigned char>(r));

(multiple times)

icpc --version
icpc (ICC) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

cat ../main.cpp
#include "gsl/gsl"
int main(int argc, char* argv[]) {
}

Microsoft/GSL conflicts with https://www.gnu.org/software/gsl/ (another completely different project) and not only with the name, but as far as I can see also in the installed files.

Would it be possible to ponder a rename of this project, on the basis that GNU's GSL is much older than Microsoft's GSL?

When building with GCC 5.4, the compiler spits out a warning about the following:

warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow]

This patch fixes this issue.

Signed-off-by: “Rian <“[email protected]”>

https://github.com/microsoft/GSL/issues/1075

• Change Expects for at: there is no need to convert the size. It is better to check the converted index.
• Add static_assert because we only support C style array at for up to half of the address space.
• Add #include <exception>
• Add death check for at() overload that takes a gsl::span.
• Add std:: before size_t.

I was just looking at the gsl::at overloads and don't understand the Expects check. For example for the C style array version.

template <class T, std::size_t N>
    constexpr T& at(T (&arr)[N], const index i)
{
    Expects(i >= 0 && i < narrow_cast<index>(N));
    return arr[narrow_cast<std::size_t>(i)];
}

Checking that i is non-negative makes sense. But why is then i checked against narrow_cast<index>(N)? For example on a 32 bit platform when having an array with 0xff'ff'ff'ff elements and when accessing element i==0 why would I want to check that i<narrow_cast<index>(0xff'ff'ff'ff) which is i<-1? Wouldn't it make more sense to check narrow_cast<std::size_t>(i) < N? The same question applies to the other overloads of gsl::at.

SL.Con.3 encourages the use bounds-checked functions such as .at() and gsl::at() over the use of operator[]. However, this becomes inconvenient when trying to access values inside multi-dimensional arrays.

For example, assume we have a 3-dimensional array named memo, which caches the values for some expensive function. To access a value, we would need to write memo.at(x).at(y).at(z), or at(at(at(memo, x), y), z) when using the GSL function. By using the new variadic template, we can simply write at(memo, x, y, z).

I am introducing GSL in the company I am working for. For our usage it would be good to have a documentation like Doxygen (which we use here) for all the classes and their functions. I am thinking about writing such a Doxygen for my company. Is there any interest in such a documentation here? If so, are there any restrictions or wishes?

The gsl::not_null class template has:

• a compiler-generated trivial destructor;
• an explicitly defaulted trivial copy constructor;
• an explicitly defaulted trivial copy assignment operator;
• no move constructor;
• no move assignment operator.

This makes it trivially copyable. However, move construction of an object of this class invokes a non-trivial, non-noexcept constructor template (include/gsl/pointers, line 90). This is unusual and unexpected; in fact, this triggers a bug in libstdc++’s implementation of std::variant. This could be fixed by adding explicitly defaulted move constructor and move assignment operator.

GSL should obey the core guidelines. Expects and Ensures should be GSL_EXPECTS and GSL_ENSURES. As the person who has suffered for 30 years for defining widely used macros check and require I can attest to just how bad an idea those names are. (https://opensource.apple.com/source/xnu/xnu-7195.141.2/EXTERNAL_HEADERS/AssertMacros.h.auto.html)