-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/03/2010 05:28 PM, Jeffrey Lee Hellrung, Jr. wrote:
I'm not sure that's really an improvement. The current design separates throwing and nonthrowing for a reason; take a look at some of the function implementations and you'll see why. Combining those would mean, at the very least, an extra if statement in every function.
If by "an extra if statement" you mean an extra compile-time dispatch, then yes, but there wouldn't (or shouldn't, if done correctly) be any runtime overhead.
Yes, once I realized that what I thought he meant didn't fit with what you guys were saying, I did some research and realized what he really meant.
I can see Marius' point of unifying all the integer classes under a single templated class xint::integer_t, but I imagine it will require quite a bit of refactoring. Whether to do this or not, and actually doing it if it should be done, is not the tallest nail right now (or is it?).
I've redesigned the whole blasted thing three times already. What's once more? (Yeah, that was a little cynical. I've really got to get back to paying work, I've spent too much time on this already.)
-add another pointer(probably the most serious issue, but you already have a 3 pointer indirection - maby you can make it so you can keep that ? )
The fact that it takes any at all means that it would slow the library down further. Just adding support for user-selected allocators slowed it down by 2.3 to 2.5 percent, something I am not very happy about. I'd need a *very* compelling reason to slow it any further.
Wait...adding support for custom allocators slowed things down over raw new/delete??? That doesn't sound right, though the 2~3% hit might be quality of compiler... [...]
It's the requirements of having a design that supports allocators, while still working with concrete base classes so that the basic functions don't have to be templates. I don't see any good reason to make duplicates of every used function just because, for example, you want to use three different fixed-bit sizes, which is what would happen if every function was a template, in the design I thought I needed before. With policy-based design, that probably wouldn't be a problem, though I need to study it further and do some experiments to see what's possible with it.
I'll have to review this incantation of the library when I get some free time.
Please do. I'd really like to know exactly what you guys want it to look like before I spend another month redesigning it yet again. - -- 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/ iEYEARECAAYFAkwIJnAACgkQp9x9jeZ9/wT+6wCfdokeTTI6zTPhd5eFWCCDWjbY lMQAoJMbqh28SPFMcCmPXMKYS10CkG1S =LpOf -----END PGP SIGNATURE-----