Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-02 04:34:39
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <boost_at_[hidden]>
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_at_[hidden]>
>> To: <boost_at_[hidden]>
>> 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