Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: Have Span<T> and Memory<T> evolved? #28926

Closed
JPKusumi opened this issue Mar 11, 2019 · 4 comments
Closed

Q: Have Span<T> and Memory<T> evolved? #28926

JPKusumi opened this issue Mar 11, 2019 · 4 comments
Labels
area-System.Memory question Answer questions and provide assistance, not an issue with source code or documentation.
Milestone

Comments

@JPKusumi
Copy link

I ask this because I read Stephen Toub's article, 'All About Span: Exploring a New .NET Mainstay'. It says, "This article has been updated to reflect technical changes following its publication."

And yet, there may be two stories in circulation 'out there'. In Story dotnet/corefx#1, Span is only for items on the stack, and Memory may be used for items on the heap. That's the sense that I got from the Toub article.

Story dotnet/corefx#2 comes to me from Code Magazine; here's a link to an article by Ahson A. Khan:
https://www.codemag.com/article/1807051/Introducing-.NET-Core-2.1-Flagship-Types-Span-T-and-Memory-T

The first example in Khan's article speaks of "an array of bytes allocated somewhere on the heap", and it proceeds to use Span to access it.

These two stories cannot both be correct. Is Toub wrong? Is Khan wrong? Or, did Span evolve so that an older story went out of date? Which idea should be deprecated? TYVM.

@EgorBo
Copy link
Member

EgorBo commented Mar 11, 2019

Well, the statement from the Stephen's article actually is
As a result, Span<T> instances can only live on the stack, not on the heap.
not
Span is only for items on the stack
🙂

@JPKusumi
Copy link
Author

I think that's good news. It should mean, point to anywhere with a Span, and don't worry that the Span instance itself lives on the stack. If that's correct, then I will quit worrying about it. :) (y)

@benaadams
Copy link
Member

The Span struct can only live on the stack; its data can be anywhere. The Memory struct can live anywhere, but its main purpose is to eventually give you a Span.

You can store a Memory in a class, or pass to an async method (as async moves from stack to heap the first time it yields), whereas you can't do this with a Span.

Similarly you can Pin a Memory and get back a MemoryHandle which you can store; whereas a Span you can only pin via a fixed statement.

One thing a Span can do that Memory cannot is refer to stackalloc'd data, because that also can only live on the stack (which means its gone when the method that allocated it exits).

Its a one direction flow, you can get a Span from Memory; but you cannot get a Memory from Span.

@stephentoub
Copy link
Member

The concerns seem to be addressed, but feel free to reopen if they weren't.

@stephentoub stephentoub reopened this Mar 11, 2019
@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the 3.0 milestone Feb 1, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Memory question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
None yet
Development

No branches or pull requests

5 participants