March 2011 - Boost - lists.boost.org

boost::system::error_code::operator unspecified-bool-type()
by Gruenke, Matt 11 Mar '11

11 Mar '11

I've found boost.system to be very useful for wrapping return codes from 3rd party libraries (e.g. libcurl). However, one problem I've encountered is that error_code's operator for boolean tests assumes that an error value of 0 == success. I've found it puzzling that this logic doesn't reside in the error_category, where it can be customized as needed. For instance, boolean tests could chain to a is_error() virtual method in the error_category, the default implementation of which preserves the current behavior: namespace boost { namespace system { class error_category : public noncopyable { public: // ... virtual bool is_error( int ev ) const { return ev != 0; } // ... }; class error_code { public: // ... operator unspecified-bool-type() const { return m_cat->is_error( m_val ) ? unspecified_bool_true : 0; } // ... }; } } Is there any reason this was not done? What do people think about adding it in a future release? Matt

2 1

[XInt] review
by Steven Watanabe 11 Mar '11

11 Mar '11

AMDG *I vote to accept XInt into Boost* Overall: * The basic interface of the library is solid. * All thread-safety issues *must* be addressed. General: It should be possible to #include any header by itself. I don't like the fact that you split up the library into separate headers all of which can only be included from the main header. I don't have a problem with providing an option to enable COW, however: * It should not be used by default * If it is off, it should be off completely. Currently, the threadsafe option doesn't seem to have any effect on COW. boost::xint::integer is totally not thread-safe, because of the race on the reference count. Not only that, constructing an integer references a global variable in magnitude_manager_t::zerodata. This means that the library currently cannot safely be used with multiple threads at all, regardless of whether I try to prevent sharing or not. Thoughts on expression templates: Expression templates are a powerfull tool. However, I'm not convinced that they're appropriate for this library. Although they allow some clever optimizations, the extra complexity can cause confusion. This is a fairly basic library which we can expect to be used by people who don't know the language well enough to cope with the problems easily. Thoughts on separating out the arithmetic algorithms: * From an interface standpoint, arithmetic algorithms that can operate on arbitrary ranges are orthogonal to the functionality that the library provides. An big integer type that is a (mostly) drop in replacement for int is important by itself. IMHO, we should be reviewing the library that was submitted, not some hypothetical library that has not been written and has very different goals. * I think this is a much harder problem than those demanding this feature seem to think. Just off the top of my head: - Memory management can't just be ignored. Unlike the STL algorithms, the amount of space required for the results is dependent on the values involved. It isn't a direct function of the size of the input. Not to mention that all but the most basic functions need to create intermediate results. - Different representations of integers can't easily be encapsulated behind a concept that the generic algorithms can use. There are a quite a few possible representations. A class can pick one representation and stick with it. Generic algorithms would need to handle anything. I'd like to be able to make a fixedsize integer that uses only stack storage. There are two reasons for this: * Efficiency. This has already been mentioned by others. This is not a high priority for me, since it can always be optimized without affecting the interface. * Exception safety. I have some cases where I need intermediate results larger than any built-in integer type. However, I can easily find an upper bound on values I need to work with (Usually twice the size of whatever type I was given). I need to guarantee that these operations cannot fail. Just using nothrow is not an option, since NaN is as bad as an exception here. I think I agree that is_prime should be called is_probably_prime. exceptions.hpp: What is the rationale for on_exception? normally you should just use BOOST_THROW_EXCEPTION. integer.hpp Virtual inheritance is probably wrong. It's only needed with a diamond inheritence graph. Using chained inheritance instead of multiple inheritance probably works better with the empty base optimization. What is the correct way to specify the allocator? The example in the documentation shows my_allocator<boost::xint::detail::digit_t>, but I don't think that I as a user should ever need to refer to namespace detail. Can I use a Boost.Interprocess allocator to put an integer_t in shared memory? I doubt it since I don't see any constructors taking an allocator. line 268: if (str[0] == tnan[0] && std::basic_string<charT>(str) == tnan) You can compare a std::string directly to a const char*. Why can the comparison operators throw? I would have expected that they could be implemented to never throw. The comparison and arithmetic operators should be restricted with SFINAE. As written, they will allow comparison with a string. Is that intended? When you test for integer_t<BOOST_XINT_APARAMS>::Nothrow && n.is_nan(), you could just test n.is_nan() and make sure that n.is_nan() is always false if Nothrow is true. is_nan should be a free function, so it can overload with is_nan for other types. random.hpp: Watch out for ADL issues. Making strong_random_generator a typedef for a type in namespace detail means that boost::xint::detail is an associated namespace and boost::xint in *not*. I don't think that base_random_generator is needed anymore. addsubtract.hpp basic_types_and_includes.hpp digit_t: "It must contain at least half the number of bits that a doubledigit_t can hold," const std::size_t bits_per_digit = std::numeric_limits<digit_t>::digits; These two statements are somewhat contradictory. I believe that you have to guarantee that the result of multiplying any two digits together fits in a doubledigit_t. If digit_t holds more than half the number of bits of a doubledigit_t, then this won't hold. Of course this is rather hypothetical, since we always work with powers of 2. magnitude_t: * It probably needs to be POD for you to make assumptions about the layout. * Can't you make the assignment operator private instead of having it throw? Actually if this is to avoid C4512, you're better off disabling the warning. convert.hpp: You assume that the letters are contiguous. While this is usually true, it is not guaranteed. The only guarantee that the standard gives about the character set is that the digits 0-9 are contiguous. to_string uses the global locale to convert char to charT. from_string uses implicit conversion. Be consistent. gcd.hpp: The behavior of invmod when the inverse doesn't exist is to return zero. Wouldn't an exception/NaN be more consistant? internals.hpp: You should probably check BOOST_NO_EXCEPTIONS (from boost/config.hpp) in addition to BOOST_XINT_NO_EXCEPTIONS. log2.hpp: What about using boost/pending/integer_log2.hpp? Perhaps this should also be called integer_log2, to avoid confusion with std::log2 which returns a floating point value. prime.hpp is_prime should take a generator instead of creating its own. That way random_prime can use the same generator for everything. randomgen.hpp: Do you want the /dev/urandom implementation to be buffered? Boost.Random intentionally uses raw file descriptors to avoid reading more random bytes than are actually needed. streams.hpp: Even though you templated the stream operators on the traits, they won't compile with anything other than std::char_traits, because to_string uses the default traits, and when you send a string to a stream, the traits have to match. I don't think std::showbase works correctly with std::setw. (This is a very common problem with ostream operators) Make sure that you handle std::internal, too. operator>> should skip leading whitespace (depending on whether this is set for the stream of course.) Tests: You don't need to create an alias to run the tests. Just use run test_streams.cpp ; run test_add.cpp ; ... I've written a few extra test cases. The ones called fail_*.cpp should be marked as compile-fail, the ones called test should pass. Beyond that, here are a few more things that I thought were missing from the tests: All the comparison operators. Not just operator< and operator>. Check the behavior of <, >, <=, and >= for equal arguments. Check cases where the operators should return false. In Christ, Steven Watanabe

6 13

[xint] Boost.XInt formal review
by Edward Diener 11 Mar '11

11 Mar '11

This is my review of the XInt library. > > - What is your evaluation of the design? The design looks clean and clear to me. The fact that the default boost::xint::integer provides immediate use of an extended integer is good. The fact that other classes can be created from the integer_t template, to change the functionality of an extended integer in various ways, is fine also. I do not see the need for random number functionality in the library. It also appears to me that prime number generation belongs outside the library. I think the design should be based on providing an extended integer which has the functionality of the C++ built-in integer types, and not try to have other functionality as part of the basic design. Other functionality for working with the extended integer outside of this core emulation of the C++ integer types can be presented as a separate library if necessary in the future. One area that does not follow this emulation of C++ integer types which I would like to see is the ability to convert back and forth to floating point types, since one can do this with built-in integer types. It would be very nice if this were part of the library since converting to C++ integer types and then to a floating point type will fail if the extended integer type is too large for a C++ integer type. But the range of floating point types is large enough for most extended integer values. > - What is your evaluation of the implementation? I did not look at the code. In general I am not concerned with the implementation details of a library unless I am being asked to change things myself, or I see some bug or slowdown. As an end-user of a library I mainly concern myself with the public and protected functionality of any library components. I feel in general that there is too much of an effort by reviewers to dictate how the internals of a library should be implemented, based on the reviewer's favorite ideas regarding coding. Unless there is a technical issue which will cause the library to not compile or run properly, or to compile or run much slower than need be, I do not see the point of such an effort to pick apart the internal implementation. Of course such technical areas of the internal implementation that causes the aforementioned problems should be critiqued. > - What is your evaluation of the documentation? The documentation presents a good first page. Things which I feel could be improved are: 1) Features are mentioned, but the "Detailed Usage Information" does not have topics which discuss all those features. I feel that each main feature of a library should have at least a brief discussion before suggesting to look in the reference. 2) Saying to look in the reference section for something more advanced than the basic use of instantiating and using a boost::xint::integer is certainly valid but I would greatly have preferred a more explanatory approach to what is considered "advanced" usage. Again this is similar to 1) in that I feel the documentation should provide as complete a discussion of the features, both simple and advanced, that it can. Furthermore what those "advanced" features are should be enumerated. The reference section is very well done and makes using the integer class fairly easy to understand. However the options to integer_t are not easy to find in the reference section. I think that because this is one of the central concepts of the library, which is that creating an extended integer is flexible, the creation of an extended integer beyond the default boost::xint::integer should be its own topic. I general I think the documentation is laid out well but should be more complete as far as topic explanations. > - What is your evaluation of the potential usefulness of the library? The potential usefulness is huge. Applications which need integer values beyond the maximum C++ long long values, but which do not want the problems of floating point number calculations, need such a library. > - Did you try to use the library? With what compiler? Did you have any > problems? I have tried to use the library with VC++ 10 and gcc-4.5.2 with no problems. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? A slow reading of the documentation. > - Are you knowledgeable about the problem domain? Yes, fairly knowledgable but not an expert. I vote to have the library accepted into Boost. I feel that if one looks for the "perfect" extended integer library which meets everyone's criteria, then the search will go on forever, while Boost.XInt is certainly good enough in its functionality/design/documentation. I trust that the implementer of the library can work out issues in the future, and I see the library serving a fundamental need now. Edward Diener

2 1

Unit test custom runner
by Emy 10 Mar '11

10 Mar '11

Hi, I am trying to unit test my project with boost. Working in visual studio, what I have now is a solution (sln) with many projects. Importants one are a lib (the project I want to test) and a other one is a project for my unit test (exe). At first, I wanted to use "BOOST_TEST_MAIN" in my UnitTest project. But because of our solution architecture, the entry point of each project isn't "main( int argc, char* argv[] )", but have a custom name ("InitMain( int argc, char* argv[] )"). Because of that custom name, even when I set my unitTest project as the start up project, it doesn't work using BOOST_TEST_MAIN (because it's not the main called first, but InitMain). Is there a way to use macros (BOOST_AUTO_TEST_CASE, etc...) and the unit_test_main (to process some console arguments), but having a custom entry point (in my case, InitMain) instead of main ? Thank you ! Emilie -- View this message in context: http://boost.2283326.n4.nabble.com/Unit-test-custom-runner-tp3346717p334671… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.46.1] Fresh release candidates available
by Beman Dawes 10 Mar '11

10 Mar '11

Fresh release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/ This RC reverts the exceptions problem found in yesterday's RC. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

3 3

boost::future and exceptions
by Andy Venikov 10 Mar '11

10 Mar '11

What's the proper way to make sure user-created exceptions are propagated between threads? When a user exception is thrown from packaged_task, future.get() throws "boost::unknown_exception". I understand that without a language support it's impossible to propagate the exception correctly, but I couldn't find any documentation that describes proper steps. I tried deriving my_exception from std::exception - didn't help. Thanks, Andy. P.S. There's no boost::async() equivalent to std::async(), is there?

2 1

[xint] Review
by Jarrad Waterloo 10 Mar '11

10 Mar '11

I do believe this library should be added to Boost provided the author is committed to supporting it and taking into consideration, at least, the comments raised by everyone's review. 1) What is your evaluation of the design? I like it. It mostly behaves like an ordinary integer. It is more than adequate for my needs. Potential enhancemnts which should not limit its adoption would include the following. 1.1) convenience functions for extracting sub integers ie. bit fields 1.2) convenience functions for creating masks 1.3) support for bitsets 1.4) support for dynamic bitsets ie. partial specialization vector<bool> from C++1x 2) What is your evaluation of the implementation? I am more concerned with the public interface which is mostly correct with the exception of incremental operators which was raised by another. I do expect speed enhancements to come over time and am pleased that it has the slower but standard C++ cross platform algorithms for the general case. Other reviewers have proposed the following of which I agree but don't mind if they come in another release. 2.a) Separate algorithms from integer 2.b) Provide a fixed size that is completely stack allocated and is exactly the size with no overhead using 2's complement like int now 2.c) Get rid of virtual 2.d) allow integer to be created with allocators I believe all of those suggestions are related. You should split your class back into two one dynamically allocated like a vector<int> and another which stack allocated like int or bitset. [Sorry, I know that at one time it was like this.] You can get your reuse by separating the algorithms and having your two or more classes do inline calls to them. This will also provide the algorithms so that others can use it on their own containers. Since these are separate sealed classes than their is no need for the virtual. The dynamic variant should than support allocators. Either way, I consider these mostly internal implementation details as I use the operators and typedefs when working with this library. 3) What is your evaluation of the documentation? Adequate to teach me how to use it. I do agree that all references to it being fast should be replaced with a request for faster preferably assembly level patches. It was lacking in examples of masks and bit fields which can be performed on regular integers but wasn't absolutely clear on this class of so many configuration options. 4) What is your evaluation of the potential usefulness of the library? Very useful and much needed 5) Did you try to use the library? With what compiler? Did you have any problems? Yes. GCC and VS8 and VS10. No problems 6) How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth study with respect to my problem domains and also have been following everyone else review and comments. 7) Are you knowledgeable about the problem domain? From the domains of using cryptographic algorithms for licensing and large numbers for working with id tagging of products where speed is not paramount than yes. No with respect to cryptography and cryptanalysis in general security where speed is critical.

2 1

[xint] review
by Phil Endecott 10 Mar '11

10 Mar '11

Dear All, Here is my review of the proposed XInt library. There seem to be several issues with the design of this library; all have been discussed before at length so I will simply summarise: 1. Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation. 2. There is no assembler, and there are no "hooks" in the implementation where a contributor could insert assembler fragments for critical code. 3. Performance is hindered by the creation of temporaries in expressions such as a = b+c+d+e; a system of expression templates that allowed the expression to be computed "slicewise" would eliminate the need for temporaries. 4. The interface is not very generic; for example the is_(probably)_prime function cannot be used on a regular int; the implementation operates on the internal representation of the integer for no apparent reason. (If the reason is performance, then that itself indicates a deficiency in the interface.) (Aside: I feel that is_(probably)_prime would be better in Boost.Math, which is apparently already organised into sub-libraries.) Also the basic algorithms (addition, multiplication...) are not generic, i.e. they cannot be used other than on the provided integer type (this would matter much less if the provided type were more performant). 5. Although I don't have strong views either way on COW, I do feel that in 2011 we should focus primarily on thread-safe code i.e. single-thread code is now the special case, not the norm. So if COW is to be used it should be thread-safe COW. 6. Apparently sign-magnitude is used without tweaks for bitwise operations, giving "wrong" answers for negatives (in contrast to e.g. GMP which stores sign-mag yet gives "right" answers, IIUC). 7. Choice of algorithms for some operations (e.g. sqrt) seems to have poor big-O complexity. In view of these issues, I do not believe that this library should be accepted. I am not suggesting that all of these issues need to be fixed for the library to be acceptable. Boost libraries do not have to be perfect. I just believe that the current state is below the required threshold. Standard answers: - What is your evaluation of the design? See above. - What is your evaluation of the implementation? It seems reasonably bug-free. - What is your evaluation of the documentation? I'm not a huge fan of doxygen, but that's mostly my problem. The docs would benefit hugely from some benchmarks. - What is your evaluation of the potential usefulness of the library? I've never needed a large integer library. - Did you try to use the library? With what compiler? Did you have any problems? Yes, g++ (ARM Linux), no problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Two or three hours work, running benchmarks, reading a few bits of the source, and following the discussion. - Are you knowledgeable about the problem domain? More so now than a week ago, but fundamentally no. One final comment: many reviews end with some sort of "accepted subject to changes" result. This indicates some trust that the author would be able to make the required changes without further review. I do not believe that this would be appropriate in this case. Regards, Phil.

2 1

Fwd: Re: [move] You can do it better: implementing push_back and handling implicit conversions
by Jeffrey Lee Hellrung, Jr. 10 Mar '11

10 Mar '11

[My original reply went directly to Ion, due to me being cc'ed in the original email. Hence forwarding... (pun intended)] -------- Original Message -------- Subject: Re: [move] You can do it better: implementing push_back and handling implicit conversions Date: Tue, 08 Mar 2011 17:23:58 -0800 From: Jeffrey Lee Hellrung, Jr. <jhellrung(a)ucla.edu> Reply-To: jhellrung(a)ucla.edu To: Ion Gaztañaga <igaztanaga(a)gmail.com> On 3/8/2011 1:57 PM, Ion Gaztañaga wrote: > Hi to all, > > Are you a C++ expert? Do you like Boost.Move? I have a challenge for you. > > During Boost.Move review, Jeffrey Lee Hellrung suggested adding > "techniques to capture (implicitly created) rvalues with emulated rvalue > references in C++03, e.g., for push_back, when you have knowledge of the > types of objects you want to capture". Yes, you know, I do seem to remember suggesting that... > I've worked on this problem these days and the solution is less than > obvious (several compilers have has problems with > ::boost::is_convertible and non-copyable types). I found a solution > (attached test and required boost/move/move.hpp header) after several > tries but it's complex (it needs several overloads and enable_if tricks) > but I'm sure boosters will find a easier solution ;-) Yes, a bit more complex than the solution I've been using for a while now (rough idea attached and explained below). > Current solution seems to work on these compilers: MSVC 7.1, 8.0, 9.0, > Intel 11.0, GCC 4.3.4, 4.4, 4.4 c++0x mode, 4.5, 4.5 c++0x mode. I've gotten your test cpp to compile and run with no assertion failures on MSVC9 (with a slight modification to assertions; see below), and I've used this same technique on gcc, but I don't work nearly as much on gcc, so it may be that some corner cases fail. > Problem: MSVC 10.0 (Visual 2010) with real rvalue references seems to > have bugs and does not compile the test. I can't find a workaround, a > future Service Pack might solve these errors, but maybe we should stick > to emulation code in this compiler, unless someone could shed some light > on this, of course. Well...that sucks :( > Waiting your proposals, > > Ion Okay, here is the summary. Ion, I count 5 overloads of push_back in C++03 and 4 overloads in C++0x for your solution. I believe one can get by with just 3 overloads in C++03, and 1 in C++0x, but the path to "T construction" in my solution is a little bit different than yours. I delay any T construction until the placement new statement in priv_push_back. I don't know what your requirements are in general, but for push_back, I think this should be fine. The solution I sent you has maybe a slight disadvantage over yours in that conversion errors would likely end up pointing to priv_push_back, but if this is a concern, the template overloads of push_back can be restricted (further) with enable_if (I think). This has the effect that push_back'ing a conversion_source object x directly constructs the storage with x, rather than constructing a temporary and copying or constructing a temporary and moving. For push_back, it seems this is definitely desirable, and I'm having a hard time coming up with a situation where it is *not* desirable to delay the construction as long as possible. In any case, this explains the change in your assertions. I also added a Default value to the ConstructionType enum because...it was bugging me ;) The 3 overloads in C++03 are basically: // captures const lvalues and rvalues that are *not* T template< class U > typename boost::disable_if< is_same_sans_const_sans_reference<U,T> >::type push_back(const U& x) { ... as_lvalue(x) ... } // captures non-const lvalues and T lvalues template< class U > void push_back(U& x) { ... x ... } typedef typename add_reference_add_const< typename add_rvalue_reference<T>::type >::type rv_param_type; // captures T rvalues (if T is movable) void push_back(rv_param_type x) { ... x ... } In C++0x, a single overload is sufficient, I think: template< class U > void push_back(U&& x) { ... boost::forward<U>(x) ... } Let me know what you think of this framework. - Jeff

2 6

[XInt] Review
by Joachim Faulhaber 10 Mar '11

10 Mar '11

Dear Chad, Volodya, list, This is my review on the XInt library. On the outset I'd like to thank Chad for his work and stamina in providing the XInt library. It is not only a big effort to provide a portable, functional and well documented library like this, but it also takes a great deal of courage to undergo a review process on the boost list. As far as I can see from some tests and use cases the library is useful, functional, correct and portable. The library implements the interface that is about to be part of the new standard. So many things are looking good and independent of the final result of the review, XInt is already a valuable tool and a great contribution. While this is more than is needed for many purposes, I come to the conclusion that it is not enough for boost. Integer is a very central prototypical data structure that should be and will be expected to be a model for the design of other libraries. I expected its design to be very clear and simple and very flexible and generic at the same time. While I was looking more deeply into the code and structures of XInt I came more and more to the conclusion that the current design is insufficient for a boost library in general even more so for an Infinite Precision Integer Library. So my vote is NO for acceptance of XInt with its current design. Even though, I'd like to encourage Chad to solve the questions around concept based generic design for XInt and to resubmit his project, when design and other issues raised in this review are solved. Maybe a deal of patience and reflection and openness to the information provided by others was helpful. Maybe the person with the most unpleasant critique has the most valuable insights for you. At the same time I'd like to call on the boost community to support Chad and to see an Integer library as an opportunity to develop more common understanding how a state of the art generic design looks like in this specific case. Best regards, Joachim ============== Review Details ============== 1.1 Naming: Library =================== An unlimited integer is an int that is not limited to a size restriction. So it conforms the mathematical notion of an integer better than built in ints. My favorite name for such a library was Boost.Integer Where would a (new) user expect such a library, exactly there. IMO Boost.Integer is much better than Boost.Xint. Boost.Integer already exists. So why not integrate new (unlimited) integer types into Boost.Integer? For simple concise naming and intuitive structuring according to user expectations, that would be the best choice. 1.2 Naming: Namespace ===================== Components of Boost.Integer are relatively old and located directly within namespace boost. So for the new Integer library we can choose namespace integers completely consistent to the official boost naming conventions: http://www.boost.org/development/requirements.html#Naming_consistency which says: The library's primary namespace (in parent ::boost) is given that same name [as the library], except when there's a component with that name (e.g., boost::tuple), in which case the namespace name is *pluralized*. which is specifically consistent since we know that Chads Integer library offers *different* integer types such that declarations integers::pure<> i; // limitless "pure" integers integers::fixed<512> j; // limited to fixed size are pretty intuitve. 1.3 Naming: Types ================= What I like about boost, compared to many other libraries, is the culture of short and concise naming. This includes the absence of cryptic pre and suffixes. But there are exceptions. One of those is the _t suffix used for a variety of types, namely int<n>_t types from Boost.Integer. I am opposed to any pre or suffixing, since it is not inline with general boost naming conventions, that discourages cryptic names or name components. My guess is that the _t suffix has been chosen as an emergency measure once: The name of choice had been used already and overloading was not possible. Where no such conflict is present, I propose to use concise and simple names without pre or suffixes. One of the reasons why I dislike pre/suffixes is that they are cryptic abbreviations most of the time. The second reason is that they, even if non cryptic, introduce useless redundancy: // "type" is used 5 times as pre or suffix typedef typename foo_type::key_type mykey_type; // instead of def foo::key mykey; // or type mykey = foo::key 2. Design ========= As other reviewers have pointed out before the design does not allow for decoupled integer types that can be models of integer concepts, such that appropriate sets of free standing functions will serve to operate on those types and the library can be extended for any other type that will be implemented as model of the integer concepts that the library defines. I think such a design would implement the ideas that can be found in [Järvi et.al. 2003, Concept Controlled Polymorphism] http://parasol.tamu.edu/~jarvi/papers/concept-controlled.pdf and that is implemented in modern boost libraries like e.g. Boost.Polygon. (Boost.Geometry is also a good example, but not so close to the Järvi paper) Because of its fundamental character, a general Boost.Integer should serve as a model, a prototype for other libraries and it should represent the current state of the art in this field. Because everyone understands integers, people will probably look at Boost's Integer design to understand modern design from a concise example. This is an opportunity and a challenge for the author but more so for the boost community. It could also be an opportunity to converge and synthesize different points of view in a prototypical design. The current design does not meet my requirements here. This is not a shortcoming of the author alone. In the discussions that have taken place around xint's design, the concept based paradigm and techniques obviously were not communicated in such a way that they found their way into a state of the art design. 2.2 Boost.Parameter considered unfavorable ========================================== Although flexible, the options feature based on Boost.Parameter comes with an unnecessary and undesired level of abstraction and indirection. It obfuscates the different kinds of parameters and makes the implementation much more difficult to read. Moreover the meta code involved with Boost.Parameter imposes a compile time penalty. IIUC all of the option parameters are compile time constants designed to steer implementation variants. There are much simpler and clearer ways to do that. Also integers::fixed<512> myVar; //is very intuitive, while xint::integer_t<xint::options::fixedlength<512> > myVar; // can't probably be done without consulting the docs // and it is more verbose 2.3 Policy based design ======================= I think policy based design is a very good and powerful technique that is specifically useful to separate implementation variants of class templates in clear and flexible ways. Unfortunately I can not see that you are actually using policy based design here. Because your design lacks typical policy classes that encapsulate implementation variants in a way that reduces codereplication and enhances flexibility. What your intended policy classes say, nan_functions<..>, only do is to encapsulate the functions that other implementation variants do not need. But this can be done by simple object inheritence alone. 2.4 Do we really want to be nanied ================================== Recently I met a guy named Larry from Huston Texas who introduced me to the notion of a nanny state. Germany, for example is a nanny state, because it imposes coercive health inshurance on its citizens. This may be totally unnecessary for some, who are always able to perform surgery on themselves. In a similar sense we could introduce the notion of a nany class, for thouse of us, who are not able to control their program logic ;-) To come to the point. I still don't really see the the indispensable benefits of nan and an exception free bigint class. We happiely work with ints for decades, that throw interrupts for division by zero. So why do we need a protection against that case that can be easily controlled through program logic? If we let go of the nan idea, everything is a great deal simpler and less ugly. The rationale given by the docs does not convince me either. 3. Implementation ================= 3.1. Codestyle ============== 3.1.1 Codestyle: Layout ======================= The library aheres to a restricion of a line length of 80 characters, which is still official boost policy. In many instances the lines are just broken before length 81 regardless of syntactical structure and readability. I dislike this coding style since it obscures structure and easy readability for no obvious reason. At some points the reader needs extra efforts to scan the text. E.g. the inheritence list of class template integer_t is an amorph textblock template<BOOST_XINT_INITIAL_APARAMS> class integer_t: virtual public detail::integer_t_data <BOOST_XINT_APARAMS>, public detail::nan_functions<detail:: integer_t_data<BOOST_XINT_APARAMS>::NothrowType::value, integer_t<BOOST_XINT_APARAMS>, BOOST_XINT_APARAMS>, public detail::fixed_functions<detail::integer_t_data <BOOST_XINT_APARAMS>::BitsType::value, integer_t <BOOST_XINT_APARAMS>, BOOST_XINT_APARAMS>, public detail::unsigned_negative_functions<detail::integer_t_data< BOOST_XINT_APARAMS>::SignType::value, BOOST_XINT_APARAMS> instead of a structured text template<BOOST_XINT_INITIAL_APARAMS> class integer_t: virtual public detail::integer_t_data<BOOST_XINT_APARAMS>, public detail::nan_functions < detail::integer_t_data<BOOST_XINT_APARAMS> ::NothrowType::value, integer_t<BOOST_XINT_APARAMS>, BOOST_XINT_APARAMS >, public detail::fixed_functions < detail::integer_t_data<BOOST_XINT_APARAMS> ::BitsType::value, integer_t<BOOST_XINT_APARAMS>, BOOST_XINT_APARAMS >, public detail::unsigned_negative_functions < detail::integer_t_data<BOOST_XINT_APARAMS> ::SignType::value, BOOST_XINT_APARAMS > that facilitates readability. 3.1.2 Codestyle: Filesize ========================= integer.hpp is too long. It should be separated in smaller named entities according to structural aspects. Filesizes can also be reduced by decomposition of the design and by reduction of redundancies and code replication. 3.1.3 Redundancies and Codereplication ====================================== There is a great deal of code replication in the current implementation of xint::integer_t. This code replication reflects the insufficient degree of decoupling of the libraries components. Not only is the code bloated by this. Also conditional expressions that are computable at compile time seem to be checked redundantly at runtime many times unless compilers are smart enough to optimize them away. But even if they do, as a developer I desire to write more elegant code in the first place and I try to use code replication as a guidepost to detect design flaws. template<BOOST_XINT_CLASS_APARAMS> integer_t<BOOST_XINT_APARAMS>& integer_t<BOOST_XINT_APARAMS> ::some_xint_fun (const integer_t<BOOST_XINT_APARAMS> b) { if (Nothrow) { if (b.is_nan()) data.make_nan(); if (!is_nan()) { BOOST_XINT_TRY { some_xint_fun(data, b.data);//#1 if (Threadsafe == true) data.make_unique(); } BOOST_XINT_CATCH { data.make_nan(); } } } else { some_xint_fun(data, b.data);//#2 if (Threadsafe == true) data.make_unique(); } return *this; } This skeleton (and some variations of it) occurs over and over again only to propagate the call of the function to the implementing class at positions #1 and #2. 3.2 Implementation issues ========================= 3.2.1 Operator template overloading conflicts ============================================= In integer.hpp 2399 and 2426, there are template macros with an unrestricted template parameter 'typename N' in template <typename N, BOOST_XINT_CLASS_APARAMS> this leads to ambiguities in overload resolution with other types that allow to combine values via operator o. icl::interval_set<xint::integer> xi_set; xint::integer xi; xi_set + xi; // Adds a single value Compilers say things like: constructor overload resolution was ambiguous. 3.2.2 Specialization of std::numerical_limits fails =================================================== When used with other Boost libraries, namely Boost.Rational and Boost.Icl metacode using std::numeric_limits fails: BOOST_AUTO_TEST_CASE(xint_and_rational) { rational<xint::integer> xrat; //error C2975: 'x' : invalid template argument for //'boost::STATIC_ASSERTION_FAILURE' //boost/rational.hpp (127) //BOOST_STATIC_ASSERT( ::std::numeric_limits<IntType>::is_specialized ); //Although is_specialized is defined in integer.hpp(2605) } I used msvc-9. I looks as if the compiler fails to recognize the code template<BOOST_XINT_CLASS_APARAMS> const bool numeric_limits<boost::xint::integer_t<BOOST_XINT_APARAMS> >:: is_specialized = true; as proper compile time constant. When assigned directly with the declaration, it works. xint/integer.h (2543) static const bool is_specialized = true; Unfortunately a similar problem occurs with numeric_limits<T>::digits //-------------------------------------------------------------- //Problems with constants from std::numeric_limits template <class Type> struct test_is_fixed_numeric { typedef test_is_fixed_numeric type; BOOST_STATIC_CONSTANT(bool, value = (0 < std::numeric_limits<Type>::digits)); //rev_xint.cpp(49) : error C2057: expected constant expression }; BOOST_AUTO_TEST_CASE(xint_std_numeric_limits) { typedef xint::integer_t<options::fixedlength<8> > fixn8; BOOST_CHECK_EQUAL(test_is_fixed_numeric<fixn8>::value, true); } //-------------------------------------------------------------- 3.2.3 Specialization of boost::is_integral<T> ============================================= You'd have to provide an instantiation of boost type trait boost::is_integral for xint::integral_t, so meta code that is implemented for all intergal types will be able to work with xint instantly. -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 5