-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2010 09:15 AM, Scott McMurray wrote:
On the minus side, it looks like every function will have to be a template, which is something that I tried very hard to avoid in previous implementations. It'll be fast, but if a program uses more than one combination of options, the size will increase greatly. The saving grace, I suppose, is that there shouldn't be much need to use too many option combinations.
Would it not be possible to still keep the math parts in (internal) non-templated functions? It feels like the duplication should mostly be in the interface parts.
It's possible for a few of the primitives and more basic functions, but anything that has to allocate a temporary integer_t needs the full-fat version, or it won't know how to allocate and deallocate it properly. Someone using the library for a security program would be put out to discover that temporary variables ignored his stated allocator and Secure preference, for instance.
For instance, a single addition function could take 2 ranges of pointers and perform all the addition logic independently of the template parameters. Then the various templates would arrange the storage properly, call the function, and translate any errors appropriately (not that there'd be any errors for addition, though I suppose there might be a carry).
That would work for addition, subtraction, and multiplication. It definitely wouldn't for division (which is more code than the aforementioned three combined). I'm not sure which of the others it would be possible for offhand, but I suspect it would be less than half of them. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwJAYkACgkQp9x9jeZ9/wSjGQCgoooCthX9gPJ6z02ePYcrQjBm 9QoAoPJ/EW9JzI93IstX4rqwMZoUOoBO =3BOb -----END PGP SIGNATURE-----