- Boost - lists.boost.org

Re:Re: [boost] additional boost libraries?
by Robert Ramey 21 Jul '04

21 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. Note that the serialization library relies upon Spirit 100 % for XML parsing. The spirit package included a very complete example by Dan Nuffer for parsing XML. I copied that (along with a 50 line copyright notice !!!) and slimmed it down to my needs. I had to re-organize a little bit to handle botch char and wchar_t characters. And spirit is kind of abstract so it has a learning curve. Then just when I got "done" (the first time) it was announced that development of spirit was being forked - ARRRRGGGGHHH. Since the spirit developers have seen fit to maintain backward compatibility things have worked well. The code compiles on both spirit 1.6 - the "supported old version" as well Spirit 1.8 - so I'm pleased that the serialization package can be use spirit and still support older compilers without me having to write a yet another half-assed home brew xml parser. I suspect that Spirit is under-appreciated and maybe a little bit ahead of its time. It takes patience, It takes effort, it can sometimes drive you crazy, but using it can make your life better in the long run. I guess its sort of like being in love. Robert Ramey

4 4

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

21 Jul '04

>Tilman Kuepper >I'm jumping in, because I am interested in Unicode conversion facets... >> is there a reason why both program_options and serialization contain >> very similar files utf8_codecvt_facet.cpp? >I had a look at the serialization library's converter in >utf8_codecvt_facet.cpp >and noticed that utf8_codecvt_facet_wchar_t::do_in() doesn't check for >non-shortest UTF8-sequences. There might also be some issues on >platforms with 16-bit wchar_t (possible overflow). >I suggest using (parts of) the UTF library in the Boost files area to solve >those problems. This could also be another step towards an officially >supported Unicode library... ;-) >http://groups.yahoo.com/group/boost/files/utf/ We really, really need utf-8 facets to be part of boost. I've been pleased with Ron Garcia's that have been included in both the serialization and program options libraries. The only problems we've had is working through the fact that there is a lot of variation in which namespaces different libraries have put things. There were a couple of similar issues regarding function signatures as well. Ron's library also had a nice documentation page. All I had to do was write a test - even that was a hassle and its still not totally satisfactory - it gives bogus warnings. I've thought about Dave's suggestion about each of incorporating source code from a common spot. I was resolved to go along as I'm pleased to off load a stick but peripheral(to me) piece of code. Now I'm rethinking this and am not convinced that it's a good idea. I would like to a) make an "official" spot for it header/lib/ etc. b) move Ron's library into that spot. It's quite serviceable c) entertain "applications" for maintainers. Presumable it would be improved, and/or replaced with time. d) subject the next version to a review. This library has been looked at by various people and although several have offered ideas on how it can be improved - no one has found that it is lacking in the implementation as to what it does. And we need it now. Ron Garcia - Are you out there? Anything to add? Robert Ramey

4 3

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> Anyway, the technique I suggested, which we use in Spirit, is > better than your trick of hoisting the names into namespace > std which is a hack that should be avoided if there are other ways. Why is it better? Let's compare: I. Hoisting the names into namespace std - require ifdef/endif + names are fully qualified, that prevent possible ambiguity/invalid function resolution (due to ADL for example) - does not allow to use ADL + located in one place + promote uniformity of access to the symbols in std namespace (particularly in a point on use, so I could see where this symbol came from) II. Use using declaration on function level + doesn't require ifdef/endif + allows ADL usage - unqualified name is a possible source of ambiguity/invalid function resolution - needs to be repeated in all functions that refer symbol - may stand out from the rest of std symbols, potentially leading to confusion/errors My personal preference is fully qualified reference everywhere. And I don't see how other solution is any better. > Regards, > -- > Joel de Guzman Regards, Gennadiy.

2 1

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