Oook ... well, first i want to stress out i am not here to get personal at you Chad. This is a review process not a crusade. Here's comment on your comments. Consider unanswered comments as being accepted by me as valid.
Why would you? Give me a viable use-case, and if it fits the library's design criteria, I'll be happy to try to make it happen.
Well, let's say i just have some file format storing large integer this way or receiving large integer over a network by unconnected packet. It's a variation of reading the int value from a string like "45748764465768754564634687314313270".
No, you cannot. Deliberately. If you were able to, then the interface would be permanently stuck at a version-1 state, because if I made any future changes to it, it would break existing client code. In my opinion, the freedom to improve the internal design without breaking client code is far more desirable than giving client code free rein to mess around in its internals.
No. you shield yourself from this by having a proper iterator/range types that hides said details of your internals. Code works with std::vector iterator everywhere and the concept iterator makes it possible to work even if w/e vendor decide to implement quantum information storage instead of contiguous one.
Your opinion has been noted. The code is not ideal, but it works, it's available, and it can (and will, if not rejected) be improved. If you're waiting for the perfect library to come along before you'll accept it, you're going to be waiting forever.
I am not. I am pointing out the fact that the current design is still requiring concept refinement so you could : a/ propose your current implementation as a basic, free for all solution b/ enable mapping to other representation with extension points
Point A, you don't have to, LCM is already in there.
So i missed it. Sorry
Point B, it can handle essentially any mathematical operation that can be expressed as a combination of existing operations. No one has yet provided any concrete example of a mathematical operation that *can't* be done using the operators and functions already available, and I suspect you'd have to get pretty esoteric to find one.
OK, so let me rephrase. What if i want to implement a function that has a non trivial algorithm which is faster than the usual combo of operations ?
Then you're don't understand it. Maybe, but I'll wager I do. Other concern is sharing data like this between threads may lead to memory contention and/or false sharing if data fit incomplete cache lines.
Yes, I could break it up into 2K one-line files. Somehow I think that would be even harder to follow.
20 x 100 lines is OK in my book
Would it be easier on everyone if I just deleted that line, since most people are bikeshedding about it?
Yes.
GMP is a collaboration of dozens of developers, contains years of work, and includes low-level optimizations that go against XInt's design goals. XInt is the product of one developer over five months. Do you measure a child's running speed against that of an Olympic gold medalist?
No I am not, you are by actually putting the dreaded "it is fast" line in the documentation. Development is not a fire and forget process, even more so if you go over some task like this one where people has tons of diverging use cases and expectations. I am not slapping you with a large trout for fun, i am just trying to show you that, if made more generic, you can still have your current impl and let said people with unusual needs be able to tweak the library from the outside to fulfill them.