|
yeah i've seen that. it's cool. thread safe too as i recall. I'd rather build one. Using that won't teach me anything
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Then go ahead. Build an own class which runs on platform ABI calls internally guarded by runtime platform checks and implements the interface you want. It's a PITA, that I absolutely agree with but on the other hand, the greater the learning effect and if there's a clean interface, the implementation doesn't matter anyway (except for said learning effect).
|
|
|
|
|
I'm probably going to write it all in managed code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Exactly my point, keep it managed, save yourself the trouble of cross-compiling and furthermore, the distributional pain. Distributing different binaries for different platforms has been the norm for pretty much forever (in computing at least), but .NET Core/Mono provide means to do it better. Hey, remember when even DOS software had to have different binaries for different computer vendors despite them all running DOS? I surely don't miss those days.
|
|
|
|
|
I planned to keep it managed from the beginning. The only reason i discussed an unmanaged scenario is because memory mapped files basically don't work - at least how they were designed to be used - under .NET.
I wanted people to understand the problem domain. I do not make mixed mode distributions anymore.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I don't quite believe you that memory-mapped files don't work in .NET since .NET has a MemoryMappedFile class.
|
|
|
|
|
I said they don't work how they are supposed to.
How they were designed was to map files to a process address space so you could do pointer ops to read and write files.
That is not doable under .NET.
Sorry I've just explained this a lot. If you've used memory mapped files in unmanaged code then you know what i'm talking about. Otherwise you might never. I don't know.
You cannot do
var foo = new int[100000]; //backed by file.
That's how it's supposed to work. It can't under .NET
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: It can't under .NET
not even with "unsafe"?
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
This StackOverflow question appears to allow you to get a fixed pointer to a mapped view. Then you could use a Span object to provide an array representation over that memory range (use the constructor that takes a Void* and Int32 ) and then writes to the Span would be written to the mapped memory and thus to the mapped file?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Oooh now that's clever.I forgot about span! Hmmm. this might be doable. thanks for the link.
Span is cool.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
No problem...
Inspiration came from using std::slice in Rust and gsl::span in C++ - both create a non-owning array-like wrapper over a chunk of memory...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
yeah. My professional dev years are behind me and so the newer .NET stuff I'm still picking up. I even stopped coding for years.
But I remember span, now that you mention it of course. I thought it was one of the coolest new features of .NET =)
Now if i can just remember it all the time.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I believe this is the type of library you are looking for...
C# BPlusTree
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I've seen that. This is a learning exercise for me, so I'm not looking for one that's already made.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Use unsafe code with pointers just as you would in C and you can do the same thing as you could in C.
|
|
|
|
|
Nope, because you can't pin an object to a specific address in memory.
Ergo I can't back a .NET instance with a memory mapped file.
Memory mapped files work by mapping a portion of the process address space to your application.
So you can read and write the file doing pointer ops.
However, in .NET you can only get pointers to the GC heap by pinning objects.
So I cannot do
var arr = new int[100000000];
in any variation. Even if I were to pin the array to get the pointer, the pointer wouldn't be part of that mapped address space.
At best, I have to *copy* the entire object into that mapped region, which absolutely defeats the whole point of why I'd use mem mapped I/O here in the first place.
There's a half measure using Span, but it only works in Standard and Core, not the DNF
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Another commenter pointed out Span, which I had forgotten about. It's a half measure** but gets me closer, however, it does not work in the DNF, only in Core and Standard i think.
GCHandle.Alloc will not let me pin to a specific address.
In order for .NET to do anything beyond span it would have to allow you to create unmanaged heaps to allocate objects on which the collector wouldn't collect.
It's designed such that it can't work, and I accept that.
It would just be nice if it had some kind of feature like the above to enable it.
** I don't actually want to store an array, i was using that as an example. My datastructure is complex and nested, which is precisely why i'd like to use vmem
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Well in that case for .NET Framework unsafe code is the only answer.
Or just return a IntPtr and let the user decide if they want to marshal or use unsafe code if this is for an API. Thats how MS does it.
|
|
|
|
|
Not applicable for this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
MS uses unsafe code all over the place in their own frameworks. Not sure how its an issue but ok.
Even if you could address managed array to a native buffer that would make it unsafe usage.
|
|
|
|
|
unsafe isn't a problem. This has nothing to do with a desire not to run unsafe code
Again, what it has to do with is mapping a complex managed data structure to a file using Vmem.
It's not doable.
At best, you resolve to something much like standard file i/o which defeats the whole reason i'd use vmem. Adding, span would help here, but it doesn't go near enough to to be a solution since these data structures aren't simple arrays.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Then just wrap the C API that does what you want. Anything you can do in C you can do in C# by using it like C. So it is doable just maybe not how you like.
|
|
|
|
|
can't do that either because it ties it to a platform.
the goal is cross platform. At best i'd have to do two binaries per platform. and it would only support a limited number of them. So it doesn't fulfill the requirements.
If I didn't care about being cross platform, I'd just use mixed mode C++.
It's okay that this isn't doable. I accept it. It would just be nice if it was.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You don't need multiple native or managed binaries for this. You can just wrap each platform and detect what platform you're on in the .NET runtime via RuntimeInformation class.
So you would probably only need one for Win32 and one for POSIX (aka Linux, BSD and macOS).
Because a .NET lib doesn't exist for what you need thats portable, you will have to make one that is.
|
|
|
|