- Boost - lists.boost.org

[1.46.1] Release candidates available
by Beman Dawes 12 Mar '11

12 Mar '11

Release candidate files for 1.46.1 are available at http://boost.cowic.de/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

10 19

[xint] Review ending in 2 days
by Vladimir Prus 12 Mar '11

12 Mar '11

Boosters, I just wanted to remind that review of the Boost.XInt library, by Chad Nelson, is about to end at March 11. So, if you plan to submit a review, please do it now. The documentation for the current version is available at: http://www.oakcircle.com/xint_docs/ The source code is available via Subversion at: http://svn.boost.org/svn/boost/sandbox/xint or can be downloaded at: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z… Here are the important points: 1. All comments are appreciated. Even if you don't have the time for in-depth study of everything, comments on parts of the library are welcome. In particular, if you are already using logging in your applications and have specialized requirements, you might want to directly check how the proposed library handles them. 2. The reviews and all comments should be submitted to the developers list, boost(a)lists.boost.org and the email should have "[xint]" prefix in the subject to make sure it's not missed. The deadline for reviews is 23:59, March 11, PST, or 2:59, March 12, EST, or 7:59 March 12, UK time, 10:59, March 12 MSK 4. The general review checklist is provided below: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks, Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

3 2

[Filesystem.v3] Request to rename imbue to something else like global_locale
by Artyom 11 Mar '11

11 Mar '11

Hello, The static member function boost::filesystem::path::imbue(std::locale const &) Is very misleading. In the C++ standard library imbue usually refers to specific object like specific stream and not referred to global object. And because it is possible to write: boost::filesystem::path p; p.imbue(some_locale); p="some_file.txt"; Which looks like you change p's locale and not global locale. I'd recommend, provide static member function boost::filesystem::path::global_locale With same semantics as imbue and deprecate imbue. Artyom

3 4

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 10 Mar '11

10 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