Should I replace (void*, size) with a GSL span?

Question

Suppose I have

int foo(void* p, size_t size_in_bytes);

and assume it doesn't make sense to make foo typed. I want to be a good coder and apply the C++ core guidelines. Specifically, I want to use spans instead of (*, len) pairs. Well, span<void> won't compile (can't add to a void *); and span<char> or span<uint8_t> etc. would imply foo actually expects chars, which it might not.

So should I use a span<something-with-size-1> in this case, or stick with void*?

@Jarod42: You're assuming there is a correct type. What if the function checks whether the buffer intersects a region in my memory space which is, say, mapped to a file? — einpoklum, May 26 '16 at 22:19
What? `span` looks like the GSL generalized version of `string_view`, which is not applicable to this situation at all. — uh oh somebody needs a pupper, May 26 '16 at 22:35
@GuillaumeRacicot Why the forwarding reference? OP simply wants a pointer and a size, or some C++ thing that could represent that, but `T&&` could literally be anything (rvalue reference, lvalue reference, pointer, etc) — notadam, May 26 '16 at 22:46

Nicol Bolas · Answer 1 · 2017-02-28T19:39:24.877

There can be no general answer to this question.

For a function to say that it takes a span<T> means that it takes a contiguous array of values, without any form of ownership transference. If that description does not reasonably represent what is going on, then it should not take a span<T>.

For example:

What if the function checks whether the buffer intersects a region in my memory space which is, say, mapped to a file?

That doesn't sound like a span<T>. That sounds like you should have a simple aggregate with a name that makes it clear what it means:

struct memory_region
{
  void* p;
  size_t size_in_bytes;
};

You could even give it a member function for testing intersections. If you are making a system for dealing with such regions of memory, I might advise a more encapsulated class type with constructors and such.

What type the function takes should explain what the data means. Preferably this meaning would be in a general sense, but at the very least, it should say what it means for the function in question.

One more thing:

or span<uint8_t> etc. would imply foo actually expects chars

No, it would not. While uint8_t will almost certainly have the same size as an unsigned char, that does not mean that one would expect to be able to pass an array of characters to any function which takes span<uint8_t>. If that function wanted to advertise that it accepted characters, it would have used unsigned char.

I meant to say span<whatever> would imply the function expect whatever's.

Yes, the requirement for spans is that it is passed an actual array of Ts of the given size.

neilmacintosh · Answer 2 · 2016-08-03T00:51:33.103

1

The proposal before the C++ standardization committee is that if you want to pass around a pointer to a sequence of bytes (which is often what people want to do when passing void* around), then you would pass a span<std::byte>, which relies upon a new std::byte type. However, that requires a small change to the language standard to be legal.

In today's C++, you could pass span<unsigned char> (typedef'd as you find most descriptive) and get the same effect: access to a sequence of bytes.

edited Aug 03 '16 at 00:51

answered Aug 03 '16 at 00:37

neilmacintosh

11
2

Can you possibly link to that proposal? – einpoklum Aug 03 '16 at 08:48
Ping on my earlier comment. – einpoklum Feb 28 '17 at 21:12

einpoklum · Accepted Answer · 2016-10-04T19:52:08.457

What I chose to do, and what I think is, shall we say, sound design-wise, is implement a class named memory_region, which has all of the type-inspecific functionality of gsl::span (hence, for example, it doesn't have a begin() or an end()). It is not the same thing as a span of bytes, IMO - and I can structurally never get them mixed up.

Here's my implementation (it's part of a repository of DBMS-related GPU kernels and a testing framework I'm working on, hence the CUDA-related snippet; and it depends on some GSL, in my case gsl-lite by MS'es should be ok too I think).

Should I replace (void*, size) with a GSL span?

3 Answers3