July 2008 - Boost - lists.boost.org

Help with deficient compilers?
by Daryle Walker 27 Jul '08

27 Jul '08

I need help with fixing code in BOOST_ROOT/libs/integer/test/ integer_test.cpp. It works fine on my computer, but other ones are giving errors. I have some guesses on what's wrong, but I need suggestions on what the fixes should be. 1. I have a custom meta-function like: //========================= typedef boost::mpl::vector<unsigned char, unsigned short, unsigned int, unsigned long long> distinct_unsigned_types; typedef boost::mpl::transform< distinct_unsigned_types, boost::make_signed< boost::mpl::_1 > >::type distinct_signed_types; // List the digit counts for each integral type template < typename T > struct digits_of : boost::mpl::int_< std::numeric_limits<T>::digits > { }; typedef boost::mpl::transform< distinct_unsigned_types, digits_of< boost::mpl::_1 > >::type distinct_integral_bit_counts; //========================= I noticed that supplied meta-functions, like boost.make_unsigned, use macros in their implementations, instead of the straight implementation I use in digits_of. Now MPL says that its machinery will make sure that straight implementations work. However, I don't think it's successful on deficient compilers. Maybe I should structure digits_of with all the work-around macros. How? (I don't want to just look at the headers and guess how they work.) 2. I don't think I have SFINAE selection correct: //========================= #ifndef BOOST_NO_SFINAE template < typename ValueT, template<ValueT> class Tmpl, ValueT Value > bool print_out_template( Tmpl<Value> const &, ValueT setting, char const *template_pre_name, char const *template_post_name, typename Tmpl<Value>::type *unused = 0 ) { // Too bad the type-id expression couldn't use the compact form "*unused", // but type-ids of dereferenced null pointers throw by order of C ++ 2003, // sect. 5.2.8, para. 2 (although the result is not conceptually needed). PRIVATE_SHOW_MESSAGE( "This is " << template_pre_name << setting << template_post_name << " specialization, with type '" << typeid(typename Tmpl<Value>::type).name() << "'." ); return true; } template < typename ValueT, typename T > bool print_out_template( T const &, ValueT setting, char const *template_pre_name, char const *template_post_name ) { PRIVATE_SHOW_MESSAGE( "Looking for " << template_pre_name << setting << template_post_name << " specialization? It doesn't exist." ); return false; } #else #error "These tests cannot work without Substitution-Failure-Is-Not- An-Error" #endif //========================= The BOOST_NO_SFINAE guards didn't help, compilers still choked on this code. (I guess I'll remove those guards later.) I think that any type that doesn't have an inner "type" will only choose the false- return case. On my computer, types with an inner "type" will choose the true return case, with that case being given priority. The reports are giving errors where, when given a type with an inner "type", the two cases are considered equal, leading to an ambiguity error. How do I restructure this code? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Boost.Spirit based C++ parser
by Bruce Trask 26 Jul '08

26 Jul '08

// note to moderator, I am reposting as my original post seemed have ended up buried in "1.36 documentation" thread. Ok to repost below? Hi, I came across this wiki discussion: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSpiritC… Did this ever move forward or materialize? Thanks in advance. Regards, Bruce

1 0

boost::coroutines and boost::asio
by atkinson julian 26 Jul '08

26 Jul '08

Hi, the combination of asio and coroutines would seem to represent a little bit of magic (layering a linear code model over an async event framework and without the attendant issues involved in multithreading). However the coroutine library seems to be exception throwing in an unanticipated way when performing a wait on a future<> during the execution of an asio async operation. I am following the documention and am reasonably familiar with asio from other projects - but have only just worked through some of the examples from the coroutines documention. i am using the vault freeze version of coroutines from 2006 - i understand from perusing these lists that the library author is currently rewritting boost::coroutine around a continuation framework to simplify and in the hope that the library may be an official boost inclusion. Much kudos for contributing to c++ in a significant way ;-) the documentation seems to have some errors http://www.crystalclearsoftware.com/soc/coroutine/coroutine/asio.html - guidance is given to use shared_coroutine in preference to coroutine in asio context although this is not present in the example - asio uses the boost::system error classes in the boost namespace when not freestanding - the example calls wait() on source which is a socket type rather than a future I have attempted to work up an example which looks logical - but cant get around the throw that occurs at /boost/coroutine/detail/context_base.hpp:213 // linux 2.6.23, g++ (GCC) 4.1.2 // g++ -g main.cpp -lboost_coroutine-mt -lboost_system-mt #include <iostream> #include <boost/bind.hpp> #include <boost/ref.hpp> #include <boost/coroutine/coroutine.hpp> #include <boost/coroutine/generator.hpp> #include <boost/coroutine/future.hpp> #include <boost/asio.hpp> namespace coro = boost::coroutines; using namespace coro; typedef boost::asio::io_service service_type; //typedef coro::coroutine< void()> foo_coroutine_type; //typedef coro::coroutine< void( service_type &service)> foo_coroutine_type; typedef coro::shared_coroutine< void( service_type &service)> foo_coroutine_type; void foo( foo_coroutine_type::self &self, service_type &service) { typedef boost::system::error_code error_type; typedef boost::asio::ip::tcp::resolver::query query_type; typedef boost::asio::ip::tcp::resolver::iterator iterator_type; boost::asio::ip::tcp::resolver resolver( service); query_type query( "www.boost.org", 80 ); coro::future< error_type, iterator_type> future( self); resolver.async_resolve( query, coro::make_callback( future)); assert( !future); // wait throws here --> /boost/coroutine/detail/context_base.hpp:213 coro::wait( future); assert( future); error_type &error = future->get< 0>(); if( error) std::cout << "error resolving " << error.message() << std::endl; else { iterator_type ip = future->get< 1>(); while( ip != iterator_type()) std::cout << ip->endpoint() << std::endl; } } int main() { service_type service; foo_coroutine_type cfoo( boost::bind( &foo, _1, boost::ref( service))); cfoo(); // service.post( boost::bind( &foo_coroutine_type::operator(void ), &cfoo)); service.run(); }

4 4

Phoenix in 1.35.0
by Robert Jones 26 Jul '08

26 Jul '08

My understanding of the state of play with Phoenix is that the lovely Phoenix 2.0 is part of the not-yet-released Boost 1.36.0, and that the current release of Boost, 1.35.0 hosts Phoenix 1.2. Phoenix 2.0 has lovely documentation at http://spirit.sourceforge.net/dl_docs/phoenix-2/libs/spirit/phoenix/doc/htm… but the corresponding documentation for V1.2, at http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/index.html is buried inside the Spirit docs, and is not nearly as good as the v2.0 documentation. In particular the v1.2 docs are very quiet about specific include file paths, which have also changed significantly for v2.0. Is there anything I've missed in all this? ----------- Also looking through the documentation of Boost libraries in general, the quality varies widely. Am I correct in believing this is due to whether the various library authors have found time to write quality documentation? Regards, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

6 9

[1.36.0] Beta release imminent
by Beman Dawes 26 Jul '08

26 Jul '08

The plan is to build the 1.36.0 beta release Sunday. Developers who have permission to make last minute fixes and docs updates should commit those changes by midnight Saturday, UTC. --Beman

5 10

circular_buffer update - merge with 1.36?
by Jan Gaspar 26 Jul '08

26 Jul '08

Hi, I have updated the circular_buffer library in the trunk (I was not able to do it earlier as I have been very busy in the past few weeks). Here are the release notes: - Changed behaviour of the circular_buffer(const allocator_type&) constructor. Since this version the constructor does not allocate any memory and both capacity and size are set to zero. - Added new methods is_linearized() and rotate(const_iterator). - Fixed bugs: #1987 Patch to make circular_buffer.hpp #includes absolute. #1919 Default constructed circular buffer throws std::bad_alloc. #1852 Copy constructor does not copy capacity. The tests passed on trunk (I made the update on Wednesday so it was included in the Friday's report). Not sure it is possible at this stage but it would be great if I can merge it into the release. There was a merge done by Thorsten several days ago but it didn't include the documentation changes (I don't blame him, he did the best he could). So now there is a discrepancy between the code and the documentation in the release branch. Jan __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

1 0

[spirit2] User experience and concerns
by Zach Laine 26 Jul '08

26 Jul '08

I've been eagerly anticipating the new version of Spirit ever since BoostCon 07. I've been using the code from the release branch to play around with it a bit, and I have a few concerns about its usability. I specifically have been using it to replace some rather ugly parsing code in an existing library. This code parses tagged text for use in a GUI, e.g. "Some text, <i>partially italicized</i>." This is very similar to the mini_xml example in the docs, so I used that as a starting point. There are some key differences between the simple_xml format and my needs, and as soon as I started deviating from the example too far I started having troubles. The differences are: 1) A tag can have parameters, and they don't look exactly like xml attributes, e.g. "<color 255 255 255 127>translucent white text</color>". 2) The "<pre>" tag is special. It turns off recognition of all future tags until the next "</pre>" end-tag is seen. 3) Stray "<" characters in the non-tag parts of the input are fine. 1) and 2) were fairly straightforward to implement as changes to simple_xml, but 3) has so far eluded me. 3) requires that all ">" sequence operators be changed to ">>" in the tagged-text parsing, so that more extensive backtracking can be done to ensure a stray "<" is not actually part of a tag. I'll summarize briefly the problems I had in terms of surprises, counterintuitive interfaces, and compilation failures that left me nonplussed. I've attached the full source (only one file, called "test.cpp"), and there are numerous comments in that code that are more direct and explicit. All my efforts were done with various recent revisions, most recently HEAD at the time of this writing -- 47802. Everything was done on a Linux box with GCC 4.1.2. - Auto-assignment seems to work fine for simple expressions, and fail for only slightly more complicated ones that the user would not expect. See Line 61. - Alternative expressions do not seem to work in a greedy fashion in all cases. See Line 70. - The rules for whether a character parser has an attribute or not are sure to seem arbitrary to everyday users. See Line 83. - In at least one case, a rule whose attribute was explicitly declared to be a type I defined (TaggedText) stubbornly insisted its attribute was std::string. See line 117. - Changing the ">" sequence operators (which seem to work nicely with "%=") to ">>" sequence operators makes the use of "%=" produce compilation errors. This forces one to resort to using semantic actions like in Spirit 1. See Line 124. On a different note, two of the Qi examples do not compile. They are actions and calc3_lexer. I did not try to compile the others (Karma, etc.). All tests (for everything -- not just Qi) pass. Zach Laine

2 1

[concept_check] Problem with concept checks and overloads
by Bruno Lalande 25 Jul '08

25 Jul '08

Hello, Barend and I have been facing a problem while integrating concept checks into the Geometry Library. In order to simplify the problem, I reduced it to a very simple test case: template <typename T> struct foo {}; template <class X> struct DummyConcept { typedef typename X::something something; }; template<typename T> BOOST_CONCEPT_REQUIRES(((DummyConcept<T>)), (void)) func(T&) { std::cout << "first overload" << std::endl; } template<typename T> void func(foo<T>) { std::cout << "second overload" << std::endl; } int main() { func(foo<int>()); return 0; } This code doesn't compile because the compiler tries to check foo<int> against the DummyConcept, even though it's supposed to select the second overload, which doesn't carry any concept requirement. Removing the check makes it compile and a run displays "second overload". If I put back the check and add a "typedef void something" into foo, it compiles and displays the same thing. So I deduce that, more generally, a compiler compiles the return type of every candidate overload before selecting the right one, and that's why we have this issue with concept checking. So I have 2 questions: - would there be any way to differ the check until after the right overload has been selected, thus doing the check only for that overload? - if no, is there a better workaround than replacing BOOST_CONCEPT_REQUIRES by a simple BOOST_ASSERT inside the function? Thanks in advance. Bruno

3 10

Re: [boost] [1.36] release blurb? [plus a tip for the authors]
by JOAQUIN M. LOPEZ MUÑOZ 25 Jul '08

25 Jul '08

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Daniel James [daniel_james(a)fmail.co.uk] Enviado el: lunes, 21 de julio de 2008 20:46 Para: boost(a)lists.boost.org Asunto: Re: [boost] [1.36] release blurb? > > On 21/07/2008, JOAQUIN M. LOPEZ MUÑOZ <joaquin(a)tid.es> wrote: > > > > I wonder whether we already have some place to begin adding content > > to the 1.36 release notes--you know, listing the new libraries and > > significant updates. > > http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… > > if you're not comfortable with quickbook, just send what you want to > add to the list. I've just added an entry for multi_index, hopefully I haven't messed anything, would be grateful if you could take a look. Also, I tidied up the previous material in the page according to the following rules, which AFAICS have governed the composition of previous release blurbs: 1. Libraries are listed in alphabetical order. 2. Besides the dedicated entry, the lib name should be added to the [purpose] section at the beginning of the page. Maybe it'd make sense to add these rules as a reminder comment at the beginning of the page (provided Quickbook has some form of comment)? Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 6

Mac OS universal builds: testers needed
by Mat Marcus 25 Jul '08

25 Jul '08

I've made a number of changes to my universal-binary supporting darwin.jam patch (shipping with the Adobe Source Library) in order to address the concerns raised by Rene and others at http://svn.boost.org/trac/boost/ticket/989 : My current version supports invocations like: bjam architecture={combined,x86,power} link={shared,static} address-model={64,32} That is, universal builds are now supported, along with 64 bit builds. I'd like to ask for the help from a few volunteers who'd be willing to test it out, before I submit my patch for consideration. Anyone interested in helping me test it? If so, please contact me off list and I'll send you a couple of boost build files to replace. I still have a bit of cleanup to do. Specifically, on the mac, if a build doesn't specify an -arch parameter, the architecture (and perhaps the address model) of the host machine is used. I'm not really comfortable with the same folder path meaning different things on different machines. So, I plan to do something like the following in darwin.jam (in invented pseudo code) SWITCH(on result of /usr/bin/arch) { # host machine's architecture CASE(ppc) use <architecture>power/<address-model>32 as the default CASE(i386) use <architecture>x86/<address-model>32 as the default CASE(ppc64) use <architecture>power/<address-model>64 as the default CASE(x86_64) use <architecture>x86/<address-model>64 as the default DEFAULT error, unknown arch Thanks, Mat

3 2