On 15/01/2016 16:44, Alex Dyachenko wrote: > Hello MPIR team, > > In my fork, I have created Visual Studio solutions (for versions 2012, > 2013, and 2015) to build an adapter using C++/CLI that exposes MPIR for > consumption by .Net 4.5+ languages. The basic idea is that first you > build the LIB version of MPIR using one of the existing VS > solutions, for your desired processor architecture. Then you build my > solution that links to that LIB and produces a .Net assembly which > exposes .Net classes for ints, rationals, and floats, and forwards the > methods and overloaded operators on those classes to native MPIR calls. > Similarly to the native C++ interface, most operations are implemented > through overloaded operators that produce expressions with > deferred-to-assignment evaluation, such that a single operation (e.g. a > = b + c) results in a single MPIR call (mp*_add), while more complicated > expressions will use temporaries as necessary. (The actual syntax would > be a.Value = b + c; the reason for that is that .Net does not support > overloaded assignment). This is not just a set of pinvoke signatures, > but a full OO interface.
This sounds like a useful addition to MPIR as .Net development is very popular on Windows. > This effort is now complete with a full suite of unit tests and XML > comments on the entire public interface (which feed nicely into Visual > Studio intellisense), tested under both Win32 and Win64, and can of > course be linked to any processor-specific assembly-optimized build of > MPIR. I had to make one small refactoring to the existing MPIR code in > the raw IO area where the existing entry point was at too high a level > to be reused, and I split a method in two so I could use my own memory > allocation and call into the "meat" of the raw IO. This resulted in a > couple of new entry points being added to mpir.h but no existing > signatures were changed. I could have re-implemented this method > entirely in my code to avoid making any changes to the MPIR proper, but > that wouldn't have been in the spirit of writing an adapter whose > internals are all forwarded. > > I would like to create a pull request to have this addition code > reviewed and eventually merged in. I realize this may take a while, and > I'll be happy to answer your questions and/or tweak the implementation > based on your input. I'm also willing to support it in future MPIR > releases. Before I do the pull request, I wanted to post this as a > heads up and to get initial feedback from you as to whether you're > interested in general. Your willingness to maintain and support this potential addition is very important and counts as a big plus point for its inclusion. It would also be nice to add a new dewveloper to the MPIR team! > Also I would like to write up a chapter for the manual, which will > probably be similar in size and structure to the C++ interface chapter, > however I'm not sure what tool chain you're using for that. I have a > linux VM where I'm able to edit texi sources in the doc folder and > produce a PDF from them, but if I understand correctly these are > dual-purpose sources that also work in some other tool that perhaps > parses out the special texi instructions that don't seem to do anything > for PDF output, and I wouldn't want to break that. If you let me know > the official way to edit and test the documentation, I can get started. This is a great proposal which will offer a worthwhile addition to MPIR. If this raises any issues that need attention in my existing VS solutions, I will be happy to take a look at these. Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
