----- Original Message ----- From: "Chad Nelson" <chad.thecomfychair@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, May 01, 2010 5:18 PM Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/01/2010 03:32 AM, Marius wrote:
I'm happy to announce that the third release of the Extended Integer library is ready, in both the sandbox and the Vault. [...]
Hi, i must say that i'm a bit concerned about making thread safety a compile time option especially considering that on unix systems you don't ussually compile the library and ship it with your program.
I see your point, but I don't consider that a major problem. Most people using the library won't need thread-safe operation; the ones that do can compile it themselves with little effort.
And if all the libraries in boost will have compile time options like that it will quickly become unmanageable for distributions.
That's hardly a problem, since "all the libraries in boost" *don't* have that kind of compile-time option. Though several of them already do... just off the top of my head, Boost.Regex requires a compile-time option to support Unicode characters, and I seem to recall several others.
I would suggest that you either make thread safe the default compile behaviour
That's not really an option, for two reasons: thread-safe behavior is markedly slower, and it has dependencies on Boost.Move (which isn't yet an official Boost library) and Boost.Thread (which, as a compiled library itself, requires linking). The single-thread version is much faster and doesn't require either of those.
or offer both safe and unsafe classes.
Certainly possible, though it would complicate the library.
Couldn't you add a template parameter stating the thread model? This parameter can be by default single_threaded, and the user can set it also to multi_threaded. In this way you let the user of each xint::integer to decide if the library must ensure thread safety or not. Best, Vicente