----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su> To: <boost@lists.boost.org> Sent: Sunday, May 02, 2010 8:55 AM Subject: Re: [boost] [xint] Third release is ready,requesting preliminary review
vicente.botet wrote:
----- 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.
That does not seem like a great idea. Suppose my application uses a library A that uses library B that uses library C that uses xint -- and library A uses xint classes in its interface. I certainly don't want all those libraries to suddely be templated on threading model -- where a library might not have a single function template in the first place.
Whell imagine I name the template integet as xint:integer_tmpl, and xint_ts::integer is a typedef of xint:integer_tmpl<>. The the libraries could use xint_ts::integer without adding any template. But yes in general it will be easier if thexint implemented thread safe interger without too much overhead. Best, Vicente