|
honey the codewitch wrote: my posts of this nature were already weighed in on by Chris
Careful.
I said posts that talk about general programming stuff like "here's what I'm doing" are fine. Posts that are of a technical nature that are better suited to one of the dedicated programming forums should be posted in the appropriate forum in order to allow members to discuss programming topics.
Yeah it's a grey area, but follow the spirit.
cheers
Chris Maunder
|
|
|
|
|
I hear, you and I'm trying. My brain is all tech whenever i'm on a coding jag, so i eat sleep and breathe it.
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 ever get to the point where you try and have conversations with non-coders and you get internal parsing errors?
I guess the question could be "do you ever not get to the point..."
cheers
Chris Maunder
|
|
|
|
|
yes i do. my solution thus far has been while i'm coding to limit my exposure to non-coders. 
But i wind up here a lot lately while in the middle of it. Mainly because i look here for inspiration and a break from the actual writing of code. sometimes to vent about chicanery in MS products and the like too. Still, I can't turn my mind away from it entirely when i'm in the thick of it. I'm like a dog with a bone.
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.
|
|
|
|
|
Environments designated to making simple things simple tend to make complicated things more complicated. Or maybe not, in the case of .NET, there's the unsafe keyword which allows you to work on raw pointers. However, that indeed doesn't help much with disk stuff.
See it this way, C# is the polar opposite of C here. In C, complex things and simple things work about the same way at the cost of simple things being ridiculously complicated.
I remember a project of mine where I combined the strengths of two worlds, I did my low-level in C (technically C++, but I had raw pointers at work), exposed a C interface and did my business logic in C#. Such a mixed design is of course too easy to get wrong, but I think I've managed to make it make sense.
|
|
|
|
|
I completely agree, and I've done similar. It's just that here, it's not really my goal to make something tied to the windows platform specifically, and pretty much no matter the route i take as soon as I'm relying on that mixed managed and unmanaged code I'm also inherently tying it to a platform.
Sure I can cross compile the unmanaged code, but even then, it's one package per platform - not what i want.
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.
|
|
|
|
|
Don't quote me, but I am rather sure that you can't do that in a platform-agnostic manner. Going with P/Invoke or a low-level library in C will require platform ties as the C API doesn't know of the concept you need (hey, the C standard doesn't even have a concept of alignment). From what I know, the C++ standard library doesn't have this concept either and the moment your standard libraries don't provide something, you have to work with IFDEFs for platforms. Be it with .NET, C++ or any other language.
|
|
|
|
|
yeah but i think you can do p/invoke in mono to access ELF binaries (or whatever they'll called these days), etc. worst case I'd use #if in C# to plug in the right p/invoke attributes for the platform
So like i said, it might be that I could cross compile the unmanaged bits, but in any case it doesn't give me what i want here.
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.
|
|
|
|
|
As I was saying, I am darn sure that it's not realistic to get this rather special use case of yours in a platform-agnostic manner. You don't need to cross-compile though. Of course can you P/Invoke in Mono and Mono has it's own share of IFDEFs to tell platforms apart. So compile ONE executable to run on Mono (or .NET Core which also has ways to tell platforms apart) but with your NativeMethods class being full of IFDEFs.
|
|
|
|
|
I'm pretty sure I'd need to cross compile the C code as Virtual memory management is completely different under windows than it is in linux for example. I don't think i can even map arbitrary files to process address space in linux but i could be wrong.
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 would have to cross-compile if you go the route of compiling a separate library (in, let's say, C) for this stuff. But you can also go with P/Invoke which you "cross compile" via runtime checks. .NET Core supports this scenario, I haven't checked on Mono (yet). https://stackoverflow.com/questions/38790802/determine-operating-system-in-net-core
|
|
|
|
|
yeah in the general sense, but in this case, i'd need two binaries per platform (one managed, one unmanaged) probably. #ifs require compilation of course, in C# as well as C
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.
|
|
|
|
|
Why do you insist on an unmanaged binary? Why don't you want to do your unmanaged ABI calls with P/Invoke?
|
|
|
|
|
Because it's impossible to map a file to process address space in C#.
You can only marshal calls to the vmem system which makes it exactly like reading and writing a file instead of reading and writing a pointer. Defeating the primary reason I'd use it.
what I want (and can't have)
var foo = new int[100000];
and i don't want an unmanaged binary. I'm speaking in the hypothetical. I will not use vmem in this project because of .NET limitations.
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.
|
|
|
|
|
Write an "array" class which looks like an array from the outside but works with ABI calls internally. Using container classes is often recommended over using plain arrays in C# anyway.
|
|
|
|
|
it has been done. It's called List<t>/IList<t> and it doesn't help me. It does zero to reduce the complexity of what I'm trying to do.
I don't actually need an int array. I need a B+tree. Try wrapping that in something fun and you'll have done my job. 
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.
|
|
|
|
|
http://csharptest.net/projects/bplustree
From the description "BPlusTree is a implementation of the generic IDictionary<TKey, TValue> interface backed by a disk-based B+Tree".
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
