- Boost - lists.boost.org

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 25 Jul '08

25 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

[test] Gennadiy, did you notice...?
by Daryle Walker 25 Jul '08

25 Jul '08

This is about the Boost.Test library files just uploaded to our Subversion repository, revision 47797. I like the fact that support headers are now automatically #included, but I noticed that "boost/ test/unit_test_suite.hpp" and "boost/test/test_case_template.hpp" #include each other. (The #include guards prevent infinite recursion.) You may want to fix that. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[test] Broken header (via indirect #includes)
by Daryle Walker 25 Jul '08

25 Jul '08

I was fixing up a test file, and the compilation failed complaining that "'type' is not a member of 'boost'" within the innards of a "BOOST_AUTO_TEST_CASE_TEMPLATE" line. I figured out that the error was referring to the obscure boost::type class template in "boost/ type.hpp". I included that file, and then the compiler complained saying that "'template_test_case_gen' is not a member of 'boost::unit_test::ut_detail'." Doing a multiple-file search, I realized the true problem. 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 3. template_test_case_gen is defined in "boost/test/ test_case_template.hpp", which happens to #include "boost/type.hpp" 4. Neither of the appropriate headers are directly #included in "unit_test_suite.hpp" 5. I guess that one or both headers were indirectly #included in "unit_test_suite.hpp", but that indirect header purged the headers I needed, and the author _forgot_ that another header was counting on the old indirect #include. I worked around the problem for now by directly #including "boost/ test/test_case_template.hpp" in my test file. But I shouldn't have to do this. Worse, this has happened before with Boost.Test, in regards to the floating point comparison tests. Those test macros called a function that wasn't in the same header, nor #included; i.e. the user has to add an extra #include for the floating-point test macros to work. The floating-point incident was a deliberate design decision, but I guess that my problem here was caused by accident. The point: DIRECTLY #include everything a macro needs in that macro's header. I'm sick & tired of hunting all the extra headers I need. Worse, I'll have to re-hunt when my test program craps out if/when the author re-arranges all the macros & headers. My point [5] is only a guess because I wasted two hours searching the trac/subversion site for where & when the author broke the build. I didn't find it, and I figured that I shouldn't have to. When you fix this, let me know so I can remove the extra #include from my test file. (Apologies in advance if the real problem is that my subversion working copy is severely fried.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 4

[test] RFC: speed up BOOST_CHECK by not formatting the check description if it isn't written anywhere
by Ji�� Pale�ek 25 Jul '08

25 Jul '08

Hello, I have a test that uses many BOOST_CHECKs (~ 10 thousands or so). Running that test is very slow and I have noticed most of the time is spent by formatting the description string to be passed to check_impl, only to be ignored, because I don't want to log successful checks (and they are successful). I have improved this by using some kind of expression template for this (called lazy_output). It works like this: lazy_output is a class that implements an expression template for "x << y << z" expressions. The expression o << a << b << c << (make_lazy_output() << x << y << z) is the same as o << a << b << c << x << y << z which is similar to o << a << b << c << (wrap_stringstream().ref() << x << y << z).ref() The difference is that, in the call f(make_lazy_output() << x << y << z), the data is formatted only if f outputs them to an ostream. This reduced the time needed for running my test from ~12 minutes to ~7 minutes. There is more room for similar (but more complicated) improvements. Any comments or suggestions? Regards Jiri Palecek

3 5

Re: [boost] [Boost-testing] Patch for sigaltstack failure on Leopard with XCode 3.0
by Juergen Hunold 25 Jul '08

25 Jul '08

HI Jeroen ! On Sunday 13 July 2008 17:33:04 Jeroen van der Wulp wrote: > Hello everyone, > The cause seems to be that the implementation of sigaltstack() on > Leopard requires the ss_size of a stack_t structure to be MINSIGSTKSZ at > least. > > The attached patch accomplishes just this. Well, it actually sets the size to BOOST_TEST_ALT_STACK_SIZE. But this should be big enough, shouldn't it ? ;-)) I'm CC'ing Gennadyi and the Boost devel list in case he missed this. I'll take a look at the current regressions for trunk and commit this patch tomorrow evening (CEST) if no one is faster ;-)) Merging Boost.Test to release is another business :-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Test] [gcc] more checking for Test tests
by Juergen Hunold 25 Jul '08

25 Jul '08

Hi ! I've just fixed some "-pedantic" warnings from gcc. http://svn.boost.org/trac/boost/changeset/47423 I'd like to raise the warning level for gcc when running the Boost.Test testsuite by always adding "-pedantic". Unfortunately, this will issue errors due to gcc's own stdlib (at least for gcc < 4.2) because of the unprotected use of "long long" from the C99 standard. Thanks to Steven Watanabe for pointing this out. I've had to add "-Wno-long-long" to disable those warnings again. Please find a patch including an explanatory comment attached. Comments ? Wait until 1.36 is out ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1