- Boost - lists.boost.org

numeric/conversion/detail/meta: void_ in boost::mpl namespace
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Is BOOST_MPL_AUX_VOID_SPEC_PARAM supposed to be used by other libraries than MPL? The conversion library uses it (it is the only one to use it) and it obviously results in an error since void_ is in the boost::mpl namespace. This error is flagged by GCC, CodeWarrior, Como, and Intel (Linux). I won't suggest a patch since I'm not even sure to understand what this macro is supposed to do (is there any documentation or is it an undocumented internal macro?), but it can't be a bad thing to remove any reference to BOOST_MPL_AUX macros from the conversion library. Regards, Guillaume

2 1

Another regression testing problem.
by Martin Wille 19 Jul '04

19 Jul '04

Hi, I ran into another (small) problem with regression testing: Unpacking the tar-ball containing the XSL based reports takes approximately 1 hour on the (not very busy) SF shell server. The tar-ball is only 60MB in size, but it contains ~24000 files, which could explain why it takes that long. Is there any way to reduce the number of files? Regards, m

2 1

RE: [boost] uBLAS regressions
by Michael Stevens 19 Jul '04

19 Jul '04

On Monday 19 July 2004 09:51, Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Unfortunately, it did -- it was producing a composite library name > with back instead of forward slashes ("numeric\ublas" instead of > "numeric/ublas"), and that confused process_jam_log, causing uBLAS > disappear from the report. > > Fixed in the CVS now, together with a test case to prevent future > disturbance ("tools\build\v1\test\test-testing.jam"). Thanks Aleksey! It was noticed by me and a couple of others that it dropped out from the report. Just show people look at the reports everyday. They are very useful and your effort is very much appreciated. The developer format reports are really very clear and informative. One question. The Comeau tests seem to be in VC7 compatability mode. For me this is a bit of a shame as it is the only Comeau regression test and I would love to know how well we do in strict mode! > For no good reason, IMO. To uBLAS maintainers -- can we fix it > sometime after the release? Certainly will. The layout was historical! All the best, Michael

1 0

program_options & mingw - patch
by Janusz Piwowarski 19 Jul '04

19 Jul '04

Hello, i attach a patch which allows to compile program_options library with mingw. Regards, Janusz

2 1

spirit/iterator/multi_pass: end iterator dereferenced
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Lines 572-573 of multi_pass.hpp are: ensure_initialized(); return !data || data->input == InputT(); The code tries to read data in ensure_initialized even when testing for end of file (which means the input iterator is invalid). So here comes a patch. Regards, Guillaume

2 1

RE: [boost] uBLAS regressions
by Aleksey Gurtovoy 19 Jul '04

19 Jul '04

Vladimir Prus writes: > Aleksey Gurtovoy wrote: > > > > local rule get-library-name ( path ) > > > { > > > local match1 = [ MATCH [/\\]libs[/\\](.*)[/\\]test > : $(path) ] ; > > > > > > I'm not sure: > > > > > > ghost@zigzag:/tmp$ bjam -f- > > > ECHO [ MATCH [/\\]libs[/\\](.*)[/\\]test : > > > bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test ] ; > > > numeric\ublas\test1 > > > > > > > > > It's numeric\ublas\test1, not numeric\ublas. > > > > 'get-library-name' will be passed > > "bin\\boost\\libs\\numeric\\ublas\\test1", though, not > > "bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test". > > Well, first of all, when I create a separate test Jamfile for uBLAS > and subinclude it, I get: > > Cannot extract library name from path ../libs/numeric/ublas > > This is because when it's in status, 'get-library-name' just returns > empty string. When it's not in status, the 'get-library-name' rule > is called with > > ../libs/numeric/ublas > > and the first regex does not match because there's no "test" in the > name, and second regex does not match because there is slash between > "numeric" and "ublas". I've applied the attached patch -- since it > strictly adds the set of arguments to 'get-library-name' on which > that function does not fail, I think it should not cause any > problems. Unfortunately, it did -- it was producing a composite library name with back instead of forward slashes ("numeric\ublas" instead of "numeric/ublas"), and that confused process_jam_log, causing uBLAS disappear from the report. Fixed in the CVS now, together with a test case to prevent future disturbance ("tools\build\v1\test\test-testing.jam"). > > Another question whether all libraries should have their test > Jamfiles under "test" directory Yes, http://www.boost.org/more/lib_guide.htm#Directory_structure. > -- which is not what uBLAS does. For no good reason, IMO. To uBLAS maintainers -- can we fix it sometime after the release? > > And now back to original question. As I understand, the > 'get-library-name' rules gets the location of *Jamfile*. No, it is passed the location of the *target output directory*. > The primary heuristic is that location is "libs/ <library-name> / > test / whatever". Why can't this logic be applied to the name of > source file which bjam prints -- and be implemented in > process_jam_log. Nope, see my original posting -- http://article.gmane.org/gmane.comp.lib.boost.devel/105382. > > I'm asking because it seems to be that it's better to have smart > logic in process_jam_log than in jam. Sure, but in this case testing.jam is the only source of the information. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

Dave Abrahams wrote: >Rene Rivera <grafik.list(a)redshift-software.com> writes: >> boost-root/boost/utf8_codecvt_facet.hpp is original. >> boost-root/boost/program_options/utf8_codecvt_facet.hpp + *.cpp >> is slightly modified copy. >> Intention is that utf8_codecvt_facet will become standalone library >> at some time and these files will be replaced. > > Then it should be moved to boost.detail, directory and namespace. >Right. We should never knowingly allow (near) duplicate code in the >repository. I don't think anyone did it knowingly. Something like this should really be subjected to a mini-review and have its own separate test and documentation and reside outside any of the systems that use it. This has been mentioned before by various people. I included Ron Garcia's version in the serialization project because I needed it. I added a test and found that as one moves to other compilers and standard libraries little things keep popping up. E.G. gcc standard library defines wchar_t as 4 byte while others use 2. So the status is "good enough for the serialization library" The serialization review specifically invited reviewers to critique this and no objections were raised that I recall. There have been proposals for an improved version. My response is that I'm glad to use one that gets reviewed and accepted rather than the one we have now. But so far nothing else has been submitted. It does work and navigates through the vagarities of the compilers that we use. Rene's criticism regarding the the resolution of namespace issues has been taken to heart and the code has been updated accordingly and tested. I expect to check in the improved version soon. Robert Ramey

2 1

This afternoon's test run
by Victor A. Wagner Jr. 18 Jul '04

18 Jul '04

I re-ran the boost tests this afternoon and here are the "interesting" lines from the output ...found 34702 targets... ...updating 529 targets... ...can't find 2 targets... ...can't make 4 targets... ...on 100th target... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test71.obj... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test72.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test71.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD... ...on 200th target... ...on 300th target... FAIL :: Caught unexpected exception during Stream in greg_month FAIL :: Caught unexpected exception during Stream in greg_month -- wide streams FAIL :: Bad month exception NOT caught (misspelled name) FAIL :: Caught unexpected exception during Stream in greg_weekday FAIL :: Caught unexpected exception during Stream in greg_weekday -- wide stream FAIL :: Bad weekday exception NOT caught (misspelled name) ...failed execute-test ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.run... FAIL :: Get time of day micro second clock not supported due to inadequate compiler ...failed execute-test ..\bin\boost\libs\date_time\test\testmicrosec_time_clock.test\vc7.1\debug\testmicrosec_time_clock.run... ...failed execute-test ..\bin\boost\libs\graph\test\adjacency_matrix_test.test\vc7.1\debug\adjacency_matrix_test.run... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.run for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe... ...failed execute-test ..\bin\boost\libs\python\test\slice.test\vc7.1\debug\slice.run... ...on 400th target... ...on 500th target... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_save.test\vc7.1\debug\test_demo_xml_save.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_load.test\vc7.1\debug\test_demo_xml_load.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml.test\vc7.1\debug\test_demo_xml.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_shared_ptr.test\vc7.1\debug\test_demo_shared_ptr.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_exception.test\vc7.1\debug\test_demo_exception.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo.test\vc7.1\debug\test_demo.run... ../libs/thread/test/test_read_write_mutex.cpp(205): error in "test_read_write_mutex": test r1.m_value == 10 failed ...failed execute-test ..\bin\boost\libs\thread\test\test_read_write_mutex.test\vc7.1\debug\threading-multi\test_read_write_mutex.run... ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in "test_default_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(30): error in "test_default_delimeter": test *it == "acv ffg" failed [ != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(36): error in "test_default_delimeter": test *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(39): error in "test_default_delimeter": test *it == "1" failed [ != 1] ../libs/test/test/ifstream_line_iterator_test.cpp(51): error in "test_custom_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(53): error in "test_custom_delimeter": test *it == "{ abc d " failed [ != { abc d ] ../libs/test/test/ifstream_line_iterator_test.cpp(56): error in "test_custom_delimeter": test *it == "\n{ d \n dsfg\n" failed [ != ../libs/test/test/ifstream_line_iterator_test.cpp(59): error in "test_custom_delimeter": test *it == "\n" failed [ != ...failed execute-test ..\bin\boost\libs\test\test\ifstream_line_iterator_test.test\vc7.1\debug\ifstream_line_iterator_test.run... ...skipped <@boost!libs!test!test\result_report_test.test\vc7.1\debug>result_report_test.run for lack of C:\Projects\boost\libs\test\test\result_report_test.pattern... ...skipped <@boost!libs!test!test\errors_handling_test.test\vc7.1\debug>errors_handling_test.run for lack of C:\Projects\boost\libs\test\test\errors_handling_test.pattern... ...failed updating 14 targets... ...skipped 20 targets... ...updated 499 targets... The entire output log ( ftp://rudbek.com/pub/boost/status.log ) is available if one of the authors thinks it will be of assistance. The log from the v2 run is there also, but it has so many difficulties I'm not sure how useful it is. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

Memory Pool items
by Mark Deric 18 Jul '04

18 Jul '04

I have been studying Stephen Cleary's boost::pool template and its subclasses with respect to using them for non-array based allocations in our company's product. We don't use many arrays that we need to dynamically allocate or resize except at init time. But we use lots of map-like collections and shared_ptr-like objects. Our use case is allocation of memory for individual objects varying in size from tiny (8 bytes, the case of a minimal impl similar to shared_ptr) to not so tiny (150-250 bytes, the case of comprehensive state tracking of an individual TCP/IP flow). In several cases, the count of allocated objects can be in the 100,000-1,000,000 range. Two items I've been thinking about: 1) The Guaranteeing Alignment doc's "convoluted example where the requested_size is 7, sizeof(void *) == 3, and sizeof(size_type) == 5" caught my attention. The lcm approach yields 105 bytes per chunk "wasting" 98 bytes per chunk, or 93% of the alloc. This was not so offensive in that it doesn't represent a practical use case of significance. But then, I considered a more common use case in which the consumer's object only had a char[13] data member against an lcm(sizeof(size_type), sizeof(void*)) == 4. The char[13] comes from the semantics of the consumer's app. Here, the lcm method would be to alloc a chunk size of 52; and better would be a chunk size of 16. As a practical matter, what regressions would be introduced if the requested size were just increased to the next multiple of lcm(sizeof(size_type), sizeof(void*))? I get the theoretical issue of the next chunk not being on a multiple of 13; but I can't think of a practical case where this would matter. 2) The issue of the array allocation performance at O(free store size) has me wondering whether the pool class should incorporate the "ordered free list" semantics at all. Maybe a separate class that uses a model more like the Linux kernel model would be better (i.e., a tiering of pages, page pairs, pairs of page pairs, etc.). With allocated chunk counts in the 10e5 - 10e6 range; use of the pool classes array semantics could get nasty. Just my two cents worth. BTW, I totally enjoyed studying Mr. Cleary's work; he, like most of the boost contributor's is lot's smarter than me. That's why, when we are working on building our catherdrals in app land, it's great to have a resource like boost to check on the quality of our bricks. Thanks to all. Regards, Mark -- Mark Deric Director, Research and Development Deepnines, Inc. http://www.deepnines.com

1 0

String Algorithm Lib BCB workaround
by John Maddock 18 Jul '04

18 Jul '04

The string algo library is currently failing with Borland's compiler because it uses code like: template< typename T > class has_native_replace { #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION private: static T* t; public: BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_native_replace_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: # if BOOST_WORKAROUND( __IBMCPP__, <= 600 ) enum { value = false }; # else BOOST_STATIC_CONSTANT(bool, value=false); # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION typedef mpl::bool_<value> type; //error here }; Rather than adding yet another workaround, I think this can all be simplified by just using: #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION template< typename T > class has_native_replace { private: static T* t; public: BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_native_replace_tester(t))==sizeof(yes_type) ) ); typedef mpl::bool_<value> type; }; #else template< typename T > class has_native_replace : public mpl::bool_<false> { }; #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and similar for the other traits classes. John.

2 3