July 2004 - Boost - lists.preview.boost.org

wrong order of test-suites in status/Jamfile
by JOAQUIN LOPEZ MU?Z 20 Jul '04

20 Jul '04

As per the policy of keeping the test-suites in alphabetical order, multi_array and multi_index appear in the wrong place --after numeric/ublas, when they should be following math. Anyone sees a problem with fixing this? I can commit the change tomorrow morning (CET time), if no one does it before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[random] Building the random libraries
by Jody Hagins 20 Jul '04

20 Jul '04

Boost version 1.31.00, g++ 3.3, RedHat 9. When I build everything: # bjam -sTOOLS=gcc -builddir=./BUILD -stagedir=./STAGE stage I do not get the random library built. Worse, when I go to libs/random, there is no src directory and no build directory. Is there an easy way to get Boost.Random built like all the other boost libs? Thanks!

2 2

wrong order of test-suites in status/Jamfile [part 2]
by JOAQUIN LOPEZ MU?Z 20 Jul '04

20 Jul '04

Also, algorithm/minmax and numeric/conversion are misplaced. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

boost & STLport
by François Dumont 20 Jul '04

20 Jul '04

Hello boosters I am trying to build boost 1.31.0 with STLport 5.0 RC1 using MSVC 6 SP5. I already spend quite a long time on a very mysterious issue with no result, I hope you will be able to help me. When I build the boost libraries I have the following error messages: vc-C++ bin\boost\libs\filesystem\build\libboost_filesystem.lib\msvc-stlport\debug\s tlport-iostream-on\exception.obj exception.cpp C:\PROGRA~1\MICROS~4\VC98\include\objidl.h(9909) : error C2668: 'memset' : ambiguous call to overloaded function C:\PROGRA~1\MICROS~4\VC98\include\objbase.h(443) : error C2668: 'memcmp' : ambiguous call to overloaded function C:\PROGRA~1\MICROS~4\VC98\include\objbase.h(467) : error C2668: 'memcmp' : ambiguous call to overloaded function "cl" /Zm800 -nologo -GX -c -D_STLP_DO_IMPORT_CSTD_FUNCTIONS=1 -D_STLP_DEBUG=1 -D _STLP_DEBUG_UNINITIALIZED=1 /Z7 / Od /Ob0 /GX /GR /MDd -I"bin\boost\libs\filesystem\build" -I"C:\Utils\boost_1_31_0" -I"C:\ Utils\STLport-5.0.0\stlport" -I"C:\Utils\boost_1_31_0" -I"C:\PROGRA~1\MICROS~4\VC98\include" -Fo"bin\b oost\libs\filesystem\build\libboost_filesyst em.lib\msvc-stlport\debug\stlport-iostream-on\exception.obj" -Tp"C:\Utils\b oost_1_31_0\libs\filesystem\build\../src/exc eption.cpp" This only happen during boost build process with STLport 5.0. When I use both boost and STLport 5.0 in a simple test that call memset there is no ambiguity. Is there any special treatment within boost code for memset and memcmp? I also notice, looking at the command line, that STLport include path is not first. Is there a special reason not to have it first? If I want to test how can I make it first? Bests

1 0

[patch] minor docs clean up
by Jonathan Wakely 20 Jul '04

20 Jul '04

Hi all, The attached patch fixes several trivial spelling and markup errors, mostly in HTML files, that I came across while reading. It also updates the comment about DR 214 in libs/bind/bind.html, since that DR has been moved to WP status and is on the cwg_defects page, not cwg_active. Is it premature to say it's been "resolved" in the comment? Should the hostname for the defect list be changed to www.open-std.org as well? I assumed it should be. Affected files: libs/bind/bind.html libs/config/configure libs/date_time/doc/DesignGoals.html libs/date_time/xmldoc/date_time_autodoc.boostbook libs/date_time/xmldoc/design_goals.xml libs/filesystem/src/exception.cpp libs/program_options/doc/rationale.dox libs/regex/doc/match_flag_type.html libs/serialization/doc/archive_reference.html libs/serialization/doc/headers.html libs/serialization/doc/serialization.html libs/serialization/doc/traits.html libs/signals/doc/rationale.xml libs/test/src/supplied_log_formatters.cpp libs/test/src/test_tools.cpp I don't have write access, so if anyone cares whether these are fixed before the next release they'll have to commit them themselves. Jon T. Pedant P.S. while I'm being pedantic, has anyone else who owns a copy of the hardback ISO 14882 book, published by Wiley, noticed that one of the signatures* is bound upside down? * "Signature" meaning a bundle of paper folded together and bound to to other signatures to form a book. Have I got the right term? -- "Strange how potent cheap music is." - No�l Coward

2 1

Boost.test: minor fix
by Vladimir Prus 20 Jul '04

20 Jul '04

I've took the liberty of comitting the following change, which make "m_value" visible on compilers with two-phase lookup (like gcc 3.4) However, the token_iterator_test still fails to compile on 3.4 saying: token_iterator_test.cpp:47:38: converting to execution character set: Invalid or incomplete multibyte or wide character token_iterator_test.cpp:48:31: converting to execution character set: Invalid or incomplete multibyte or wide character token_iterator_test.cpp:48:42: converting to execution character set: Invalid argument token_iterator_test.cpp:48:49: converting to execution character set: Invalid argument token_iterator_test.cpp:48:55: converting to execution character set: Invalid or incomplete multibyte or wide character Looks like the text in L"" literals is not 7-bit, and that's why compiler errors out. Is it possible to change the test somehow? - Volodya Index: token_iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/detail/iterator/token_iterator.hpp,v retrieving revision 1.3 diff -u -r1.3 token_iterator.hpp --- token_iterator.hpp 19 Jul 2004 12:29:57 -0000 1.3 +++ token_iterator.hpp 20 Jul 2004 12:45:47 -0000 @@ -309,7 +309,7 @@ typedef ut_detail::token_assigner<BOOST_DEDUCED_TYPENAME iterator_traversal<Iter>::type> Assigner; Iter checkpoint; - Assigner::clear( m_value ); + Assigner::clear( this->m_value ); if( !m_keep_empty_tokens ) { while( begin != end && m_is_dropped( *begin ) )

3 3

Re:[boost] Re: Serialization and tmpnam
by Robert Ramey 20 Jul '04

20 Jul '04

Guillaume wrote: >Le mar 20/07/2004 ` 08:06, Vladimir Prus a icrit : >> Robert Ramey wrote: >> > >> [1] As does the manpage say: "Never use this function". >> > > >> > >Depending on the version, you may even see a more helpful message in >the >> > >manpage. >> > > >> > > >> > >BUGS >> > > Never use this function. Use mkstemp(3) instead. >> > >> > Well, not helpful enough. Making a stream from a file descriptor is code I >> > don't have. >> >> Maybe, you should take a look at the code I've posted... you don't need >to >> create fstream from file descriptor. You can open the file using the name >> mkstemp returns via the in/out parameter. >No, using mkstemp this way is no different than using tmpnam. Even if >the file is already open, there is no reason for it to still be linked >in the directory. So you may end up with a different file, and chaos >ensues. So what course of action do you recommend? Also, as I understand the problem, If I don't use tmpnam but just assign a fixed name like "xyz", the same issues re race conditions and potential flaws are still present - are they not? This is sort of an interesting question but seems way beyond the scope of what can be addressed by a program whose function is to test a library during development. Perhaps you want to conjure up a definitive solution and submit for consideration as part of the filesystem library. Robert Ramey

2 1

Re: Boost.test: minor fix
by Gennadiy Rozental 20 Jul '04

20 Jul '04

> patch attached > > jon > Thanks. - utf::wstring_token_iterator tit( L"?????? ?? ? ???" ); - wchar_t const* res[4] = { L"??????", L"??", L"?", L"???" }; + utf::wstring_token_iterator tit( L"\317\356\367\345\354\363 \341\373 \350 \355\345\362" ); + wchar_t const* res[4] = { L"\317\356\367\345\354\363", L"\341\373", L"\350", L"\355\345\362" }; But could you please explain why do I need that and what is wrong with original? Gennadiy.

1 0

Re:Re: [boost] Re: Multiple files utf8_codecvt_facet.cpp
by Robert Ramey 20 Jul '04

20 Jul '04

Vladimir Prus wrote: >David Abrahams wrote: >> > It seems reasoable, because it's not templated code. Creating a library >> > will lead to a set of other problems. If both serialization and >> > program_options need to use utf library, then, should they link to that >> > new library, or ask that users link to the new library themself? >> > >> > Since it case of static libraries it's not possible to link utf into >> > program_options, seems like the user would have to link utf manually. >> > Hmm... that's not good, but I don't see better solution. >> >> For now you could put it in an unnamed namespace and just compile it into >> both of the libraries via #include. >>Yeah, I think that's possible. So I'm going to: >1. put new header to boost/detail >2. put new source to libs/detail/utf >3. #include new source in program_options. Fine. I'll #include new source in serialization as well so we'll all be in the same page. Question. Does this not mean that this if an application includes both the serialization package as well as the program options package that some linkers will fail to links with a duplicate symbol message? I would also like to see 1. The documentation page and test moved to a neutral spot. 2. Could you examine my version and your version and reconcile any differences. Given Rene's observations, I made a pass and fixed the issues he mentioned. It's a could of changes but they are small and make things much more transparent and reliable. I've also tested them on a variety of compilers and feel much better about it. Robert Ramey

2 1

Re: [boost] additional boost libraries?
by Igor Kholodov 20 Jul '04

20 Jul '04

Vladimir Prus wrote >> and, just out of curiosity: >> xml/html parsing > >None so far. In fact, it seems unlikely that somebody will come along and >implement all the XML stack (DOM, XPath, XML Schema, XSTL, whatever) right >now. One chance would be is somebody boostify some existing XML toolkit -- >but which one? > >Another chance is to initially create "tiny XML" library. In fact, both >regression tools and serialization have their own tiny XML parsers and users >aksed about XML support for program_options, so such library might really be >usefull. Here is another example of non-validating XML stream parser: http://cttl.sourceforge.net/xml/index.html Igor Kholodov http://cttl.sourceforge.net/

1 0