on 10.06.2010 at 5:49 Chad Nelson wrote :
A stack-based integer's magnitude would always have to be stored directly adjacent to the integer itself on the stack, or risk having one deallocated before the other. That means no sharing of memory (even temporarily) for integers with identical magnitudes, and no moving magnitudes around by pointer-swapping -- every time you copy an integer for any reason, you'd have to copy each and every byte of the magnitude along with it. Swapping two 512-bit integers, just as an example, would mean three copies of 64+ bytes each, rather than a simple pointer swap.
I assume you wanted to use stack-based memory for speed, but due to the above, it would likely be slower than the equivalent heap-based integer. Especially with a good caching allocator.
It would probably also require some modifications to the lower levels of the code, to disable all the pointer-swapping stuff that I've built in for speed. That makes it difficult to experiment with it at present. Once the library is finalized, we can play with it and see if we can find a way around that problem. yes you are right i can see the rationale behind this now i guess the cost of allocation compared to cost of operations is negligible so in fact stack version will not gain much and it seems to me that i recalled the discussion about it
anyway i think that fixed integer is a valuable part of the lib one more question arises is that many algorithms that use built-in integer modular arithmetic can be generalized to larger ints (PRNG, hash etc.) but as i understood from the docs fixed_integer does not exercise modular arithmetic like built-in types do at the same time there already is modular arithmetic implementation in the lib it confuses me what was your intention? -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out