AMDG On 03/14/2011 02:35 AM, Domagoj Saric wrote:
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110312020807.3aa7c86f@ubuntu...
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library.
Then my acceptance vote remains a firm no...not just because such a library will not fulfil my needs or satisfy my notion of a 'proper implementation' but because you seem to fixed on the idea of adding a library to Boost that primarily suits your needs in spite of objective and validly argued demands from the Boost community. Your 'whole point of the library' is exactly that, >your< point, I did not see any reviewer agreeing with you on that point. All of this makes the library not Boost.XInt but ChadNelson.XInt...
And why exactly do you refuse to treat fixed-size integers 'properly and equally'? So far the only reasons I could find are: - you have no need for them - a priori irrelevant if you want inclusion in Boost
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with. However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
- you do not have or do not want to spend time 'doing it right' - if you listened to advice, various people repeatedly already gave you way back in the earlier iterations of the library, to decouple orthogonal concepts (namely algorithms from data storage) it would have been trivial to add fixed-size support (i.e. almost as simple as choosing between boost::array and std::vector). Probably a fraction of the time spent arguing about it (and coming up with pointless arguments like that of a 'performant swap')...
Pointless?
The argument against separating algorithms so far has been that it would expose a wider public interface with the addition of SW's arguments against STL-like algorithms specifically. However, none of those arguments apply to the sole idea of algorithm extraction as this does not in any way imply that you have to make them public or STL-like...They can still remain an internal implementation detail...
The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right',
It isn't. If there's one thing I hate more than anything else, it's blindly applying rules, while forgetting the reason that the rules exist to begin with.
and even after your experience and/or knowledge has been shown as lacking, cements the no vote even more because, as Dave Abrahams said, the vote goes to the library and the maintainer...
In Christ, Steven Watanabe