qwertie
commented
7 years ago Here's the plan I was thinking over at StackOverflow:
- Fork ecsharp repo.
- Create a new library, say, Loyc.AList64.dll, that references Loyc.Essentials but not Loyc.Collections.
- Use LeMP to generate 64-bit versions of the sparse list interfaces in Loyc.Essentials.dll (the new interfaces will still be defined in Loyc.Essentials.dll, not Loyc.AList64.dll, because I treat Loyc.Essentials.dll as a central location for defining interfaces in my libraries)
- Use LeMP to generate 64-bit versions of
SparseAList, its base classes, and its node classes.
To get the ball rolling I added an alist64 branch to this repository, and did step 3. In that branch you'll see I've modified the original Collections/Interfaces/ISparseList.cs by adding using index = System.Int32; and then replacing all occurrences of int with index. Then I added SparseList64.ecs which generates a 64-bit version like this:
// Insert the contents of the file into the inner replace command (if you
// write includeFile("ISparseList.cs") directly inside replace, it doesn't
// work because the replacements happen before includeFile runs.
replacePP(file => includeFile("ISparseList.cs"))
{
// Bug in replace: replace({ using index = System.Int32; } => { using index = System.Int64; }) doesn't work.
// Workaround: replace( { index = System.Int32; } => { index = System.Int64; }) happens to work.
replace(
{ index = System.Int32; } => { index = System.Int64; },
ISparseListSource<T> => ISparseListSource64<T>,
ISparseList<T> => ISparseList64<T>,
ISparseListEx<T> => ISparseListEx64<T>,
// there is currently no 64-bit version of IList<T>, IListSource<T>, IListAndListSource<T>, or IListEx<T>
IListSource<T> => IReadOnlyList64<T>,
IListAndListSource<T> => IReadOnlyList64<T>,
IListEx<T> => IReadOnlyList64<T>)
{
file;
}
}LeMP is based on a modified version of C# syntax called Enhanced C#. LeMP is a preprocessor, not a complete compiler.
Admittedly, I immediately encountered some kind of bug or limitation in LeMP as described in the comment. Since LeMP has few users, you might find that something you want to do has never been done before and therefore there could be a bug in it. Just let me know if it gives you any trouble and I'll find a fix and/or workaround.
Since you'll be using replace a lot, I want to point out that Enhanced C# does not allow "custom" syntax - it's just a "liberalized" or "generalized" syntax of normal C#. In particular, the expressions ISparseList<T> => ISparseList64<T> and { using index = System.Int32; } => { using index = System.Int64; } in the above code are both parsed as "normal" lambda expressions. Since => is always a lambda operator, you may notice that a command like replace (a + b => c + d) doesn't work. The reason is that the Enhanced C# parser understands it as replace (a + (b => c + d)), not replace ((a + b) => (c+ d)) like you intended. So you would have to write it as replace ((a + b) => c + d).
By the way do you prefer the name LongSparseAList? I was thinking SparseAList64.
Oh, and are you using Visual Studio 2017? Due to lack of demand I haven't actually upgraded LeMP to integrate with VS2017 yet.
MkazemAkhgary
SparseAList is very solid collection, And I use it for mapping lots of sequential data into different integer places. but sadly my main requirement is 64bit integers.
It seems extending SparseAList to support 64bit indexer is not possible. since its based on AList and whole thing has to be changed to support 64bit indexing. @qwertie told me that this has additional 50% overhead in size.
However in my case benefit of SparseAList overweighs additional overhead of 64bit version. I would like to have this collection, since collection complexity is at monster level (it seems 😃), I'm looking for approach to minimize (or completely avoid) possible mistakes by manually copying every bit.
as suggested by @qwertie this can be achieved by LeMP, I would like to do to this.