gsl-lite / gsl-lite Goto Github PK

Make constructor explicit, remove converting assignment from T.

See M-GSL issue 681, and M-GSL PR 659.

See M-GSL PR 449.

See M-GSL PR 401, replaces M-GSL PR 400, PR #45

See M-GSL issue 371, PR 374.

Hi,

the following fails to compile:

uint8_t* p;
size_t n;
gsl::span<const uint8_t> s(p, n);

The workaround is to first construct a span<T>, which is implicitly convertible to a span<const T>.

Review changes from GSL PR 166.

See M-GSL PR 326.

C++ Core Guidelines uses the name “Guideline support library” not “Guidelines support library”.

Function declarations preferably use the following order:

gsl_api inline gsl_constexpr type function() gsl_noexcept

Note 1: constexpr implies inline, however gsl_constexpr may be empty.
Note 2: also use inline on function templates.

While testing migrating my project from Microsoft's GSL to GSL-Lite, my tests started failing when doing string_span comparisons. This was because some string_spans were null-terminated, some were not.

Is it intended behaviour for string_spans which are identical other than one being null-terminated to be considered different?

I have been experimenting with adding an option for special string_span comparison operators that ignore the last element of the operands if they are equal to `'\0' - do you think this is a good approach?

My additions can be seen on my fork.

Thank you!

See discussion at M-GSL issue #688.

Activate on_return, on_error via -Dgsl_FEATURE_EXPERIMENTAL_RETURN_GUARD.

See M-GSL PR 262, microsoft/GSL#262

See M-GSL PR 401.
[See M-GSL Issue 395.]

Hello!
I would like to request support for compilation with exception handling turned off.
This is currently an issue within the "narrow" function, which throws "narrowing_error"-s and results in a compilation error on clang.

../thirdparty/gsl-lite/include/gsl/gsl-lite.h:598:9: error: cannot use 'throw' with exceptions disabled
throw narrowing_error();

I would like to request a configuration similar to the contract violation throw/terminate one.

When compiling GPU code using the CUDA framework, one needs to designate whether a function or a method is to be used on the "host" (the system's main CPU(s) and RAM) or on the "device" (the GPU card). This is done by prepending __host__ and/or __device__ to the declaration.

By default, code is host-only, thus gsl-lite cannot be used in GPU device code. However, it would be very easy (AFAICT) to make gsl-lite CUDA compatible:

#ifdef __CUDACC__
#define CUDA_DESIGNATOR __host__ __device__
#ifdef Expects
#undef Expects
#undef Ensures
#define Expects(x)
#define Ensures(x)
#endif
#else /* non-CUDA code */
#define CUDA_DESIGNATOR
#ifndef Expects
#define Expects(x)  ::gsl::fail_fast_assert((x))
#define Ensures(x)  ::gsl::fail_fast_assert((x))
#endif
#endif

and then prepending the function and member function definitions with CUDA_DESIGNATOR. It might even be the case that you don't need to get rid of the fail_fast_assert(), but I'm not sure about that.

There should be no impact on anything at all, i.e. this is a safe change.

I would very much like to see this committed (for use with my DBMS-oriented CUDA kernel tester, which will soon be sporting a modified version version of gsl-lite as per the above.)

This would allow you to use gsl::byte as a key in an unordered_map.

In release 0.14.0 of gsl lite gsl_CONFIG_CONTRACT_VIOLATION_TERMINATES and gsl_CONFIG_CONTRACT_VIOLATION_THROWS also govern the behavior of narrow() when a conversion discards information (issue #50 ).

This change to the behavior of narrow() is a breaking change: on discarding information narrow() used to always throw, whereas it now only throws if the non-default gsl_CONFIG_CONTRACT_VIOLATION_THROWS is selected. Would more or different control over narrow()'s behavior be required?

In span, M-GSL and p0122r3 use:

using index_type = std::ptrdiff_t;

whereas GSL Lite uses:

typedef size_t size_type;

Should GSL Lite also use index_type and std::ptrdiff_t and deprecate size_type (see issue #42)?

See also M-GSL issue span index is an int instead of unsigned int #339.

Duplicate of issue #1: Review changes from GSL PR 165.

Changes:

• Use target_include_directories over include_directories.
• Use INTERFACE library.
• Add GSL project to tests/CMakeLists.txt.

Note: requires CMake 2.8.12 instead of 2.8.11.2 (Travis).

See M-GSL PR #370.

See M-GSL PR 400; replaced by M-GSL PR 401, PR #46 .

On M-GSL, Eric Niebler:

throwing copy and move constructors cause final_act to not execute the action #283 .

The constructor of final_act here moves from argument f into member f_. If that throws, then the action is not executed, which is kinda the whole point of this utility. This paper shows how to do it right.

This paper: P0052R2
Example code on Peter Sommerlad's GitHub

operator bool() interacts badly with comparison, see issue #32.

M-GSL removed operator bool() from span (issue#140). Also proposal for span p0122r3 has no operator bool().

This also closes issue #4, Make conversion of span<> to bool explicit.

Hi,

currently, writing to a const span<T> doesn't compile:

int* p;
size_t n;
const span<int> s(p, n);

s[0] = 42; // doesn't compile

This is surprising behaviour, and not what Microsoft's GSL implementation does -- or the STL, for that matter. In the STL, it is customary that constness is shallow, that is:

const std::shared_ptr<int> p = std::make_shared<int>(42);
*p = 43; // this is fine
p = std::make_shared<int>(44); // this isn't

std::shared_ptr<const int> p = std::make_shared<int>(42);
*p = 43; // this doesn't compile
p = std::make_shared<int>(44); // this does!

Shouldn't GSL adhere to this principle?

See M-GSL issue 248, PR 344.

It seems that with Microsoft GSL it is possible to create empty subspan by giving offset == length():

int arr[5] = {1, 2, 3, 4, 5};
span<int, 5> av = arr;
CHECK(av.subspan(5).length() == 0);
CHECK_THROW(av.subspan(6).length(), fail_fast);

but with gsl-lite it's an error (blow_offset test case).

Hi, I am using GSL in my multi-platform CMake-based project (MSVS2013 + GCC 4.9). Unfortunately I cannot switch to GCC 5+ at the moment, so I will use gsl-lite when building under Linux. I set up GSL as a CMake external project and to avoid any ifdefs, I just added a gsl.h to the include folder in my fork which simply includes gsl/gsl-lite.h internally. Does it make sense to you to have such a file in gsl-lite? If yes, I'll make a PR or you can simply add it yourself.

See M-GSL PR 404.

There is no move constructor/move assignment for span. Is this intended?

M-GSL PR 387 states:

In the current standard library, size_type is only offered by container types and it is always unsigned. span is not a container type, nor should it pretend to be one.

• remove row maybe_null
• add algorithms: copy() (add tests for copy()), ...

The constructor for gsl::span from any container seems to be a bit too permissive when it comes to Base and Derived types. (nb: the same remark applies to Microsoft's version of GSL)

struct B { int _b; B(int b) : _b{b} { } }; 
struct D : B { int _d; D(int b,int d) : B{b}, _d{d} { } };
std::vector<D> v1={{1,10},{2,20},{3,30}};
gsl::span<B> s1(v1);
for(const auto &i: s1) { std::cerr << i._b << ' '; } std::cerr << '\n';
// obtained: 1 10 2 20 3 30 (i.e. kind of reinterpret_cast with an incorrect size!)
// expected: compilation failure since D[] is not convertible to B[]
//           (although D* is convertible to B*)

I would suggest a constructor similar to this one.

  template<typename Container,
           typename PointerType = decltype(std::declval<Container>().data()),
           typename ValueType = decltype(*std::declval<PointerType>()),
           typename SizeType = decltype(std::declval<Container>().size()),
           typename = std::enable_if_t<
                        std::is_convertible<PointerType,pointer>::value&&
                        std::is_same<std::decay_t<ValueType>,
                                     std::decay_t<value_type>>::value&&
                        std::is_convertible<SizeType,size_type>::value>>
  gsl_api gsl_constexpr14
  span(Container &c) noexcept
  : begin_{c.data()}
  , end_{c.data()+c.size()}
  { }

By the way (another topic): shouldn't GSL_UNENFORCED_ON_CONTRACT_VIOLATION be automatically defined when NDEBUG is?

Thank you for your great work (and readable code!).
Hope that helps.

Note gsl-lite string_span vs. MS GSL string_span<>.

Provide gsl_CONFIG_STRING_SPAN_TEMPLATE or some such?

See also issue #5 "add gsl.h to include?"

Hi Martin, thanks for your great job.
I think you already know this little issue: I realized that Final_act relies on the copy-elision optimization of the compiler. Although this will be a standard feature of C++17, at the moment it's not. Consider this simple example:

auto act = finally([]{cout << "hello\n";});

disabling copy-elision (e.g. -fno-elide-constructors on clang), you get:

hello
hello
hello

That is not what you expect. A simple solution consists in just adding a flag (that is also useful in case you provide a "disable-execution" capability).

I blogged about that 4 years ago:
https://marcoarena.wordpress.com/2012/08/27/mix-raii-and-lambdas-for-deferred-execution/

Microsoft's GSL contains a correct final_act here:
https://github.com/Microsoft/GSL/blob/master/include/gsl_util.h#L60

Keep up the good work!

Marco

M-GSL PR #398.

span<> in gsl-lite has rank:1.

static constexpr std::size_t rank() { return 1; }

template <size_t Dim = 0>
constexpr size_type extent() const noexcept;

constexpr size_type extent(size_t dim) const noexcept;

Microsoft/GSL PR 201.

See also Microsoft/GSL issue 140:

[explicit] operator bool() => bool empty().

See M-GSL issue 335 ... and Bjarne's response.

Review changes from GSL PR 165.

See M-GSL PR 413

After span's comparison functions have been made free functions in release 0.9.0, they now give incorrect results when comparing spans differing in constness:

char data[] = {'a', 'b'};
gsl::string_span a = gsl::as_span(data);
gsl::cstring_span b = gsl::as_span(data).last(1);

assert(a != b); // previously worked as expected, now converts to bool and compares equal!

Severity    Code    Description Project File    Line    Suppression State
Warning C26495  Variable 'gsl::Final_act > >::action_' is uninitialized. Always initialize a member variable. (type.6: http://go.microsoft.com/fwlink/p/?LinkID=620422)  gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 265 Active
Warning C6385   Reading invalid data from 'arr':  the readable size is '16' bytes, but 'index' bytes may be read.   gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 345 Active
Warning C26482  Only index into arrays using constant expressions. (bounds.2: http://go.microsoft.com/fwlink/p/?LinkID=620414)  gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 345 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 511 Active
Warning C26485  Expression 'arr': No array to pointer decay. (bounds.3: http://go.microsoft.com/fwlink/p/?LinkID=620415)    gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 518 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 519 Active
Warning C26485  Expression 'arr': No array to pointer decay. (bounds.3: http://go.microsoft.com/fwlink/p/?LinkID=620415)    gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 519 Active
Warning C26485  Expression 'arr': No array to pointer decay. (bounds.3: http://go.microsoft.com/fwlink/p/?LinkID=620415)    gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 524 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 525 Active
Warning C26485  Expression 'arr': No array to pointer decay. (bounds.3: http://go.microsoft.com/fwlink/p/?LinkID=620415)    gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 525 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 534 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 542 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 664 Active
Warning C26490  Don't use reinterpret_cast. (type.1: http://go.microsoft.com/fwlink/p/?LinkID=620417)   gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 717 Active
Warning C26490  Don't use reinterpret_cast. (type.1: http://go.microsoft.com/fwlink/p/?LinkID=620417)   gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 722 Active
Warning C26490  Don't use reinterpret_cast. (type.1: http://go.microsoft.com/fwlink/p/?LinkID=620417)   gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 729 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 745 Active
Warning C26485  Expression 'arr': No array to pointer decay. (bounds.3: http://go.microsoft.com/fwlink/p/?LinkID=620415)    gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 772 Active
Warning C26481  Don't use pointer arithmetic. Use span instead. (bounds.1: http://go.microsoft.com/fwlink/p/?LinkID=620413) gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 852 Active
Warning C26493  Don't use C-style casts that would perform a static_cast downcast, const_cast, or reinterpret_cast. (type.4: http://go.microsoft.com/fwlink/p/?LinkID=620420)   gsl-lite.t  d:\own\martin\dropbox\project\github-pre\isocpp\gsl-lite\include\gsl\gsl-lite.h 856 Active

Hello,

I think it would be convenient to be able to use as_bytes on basic_string_span, I just had a need for this in my project.

What do you think of this? Here is the diff

Thanks!

See C++ Core Guidelines, F.24: Use a span or a span_p to designate a half-open sequence.

See M-GSL issue 313.

See M-GSL PR # 369.

E.g., change

template<...>
gsl_api inline gsl_constexpr14 byte & operator>>=( byte & b,... ) gsl_noexcept
{
    ...
    b.v = to_uchar( b ) >> shift; return b;
}

to

template<...>
gsl_api inline gsl_constexpr byte & operator>>=( byte & b,... ) gsl_noexcept
{
    ...
    return b.v = to_uchar( b ) >> shift, b;
}

Visual Studio 2015 Update 3 seems to no longer have _HAS_CPP0X defined, this affects:
define gsl_HAVE_CONTAINER_DATA_METHOD 1
define gsl_HAVE_SHARED_PTR 1
define gsl_HAVE_UNIQUE_PTR 1

I did the following change on my fork but I wasn't sure if it was the right way to fix it, so I created an issue instead of a PR for this one. Wasn't sure if you'd prefer to move them up into the ifdef gsl_COMPILER_MSVC_VERSION >= 14 block above.

decaf-emu@a9efb2d

See M-GSL Cleanup additional warnings, PR 407.

• -Wcast-align
• -Wconversion
• -Wctor-dtor-privacy
• -Wextra
• -Wnon-virtual-dtor
• -Wold-style-cast
• -Woverloaded-virtual
• -Wpedantic
• -Wshadow (many in lest) => created Issue at lest
• -Wsign-conversion, see PR #71

Hi,

I saw you removed boundary checking in operator[], but later you undid that change. What is your rationale of either adding or removing it?

My view is, that the general C++ philosophy of zero-cost abstractions and "don't pay for what you don't use" is violated by performing bounds checking when indexing. Indexing should be unchecked, if the user desires boundary checking behaviour, she can always opt-in by using the at() member function.

This is the general consensus in the STL, e.g. in std::vector and std::array.

What do you think?

Thanks,
Márton

See Guidelines Support Library Review: span, section Subspans.