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

RE: [boost] [Boost.Test] New testing procedure?
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

> According to http://tinyurl.com/3f32c tests have been failing > (IIUC for several days if not longer) because of > protected/private access violations in the test library. See > the end of http://tinyurl.com/35ole for details. IMO this > situation is unacceptable, and I'm looking for practical > solutions. Problems with the Boost.Test affect our ability > to get meaningful feedback on the state of other libraries. > > If Gennadiy can't test on more compilers before checking in, > and respond faster to problems introduced in its source, and > if library authors genuinely find Boost.Test useful, maybe we > need to move to a different model wherein the test library's > own tests are run on a CVS branch of the code (?) so that > Gennadiy can see and deal with his problems before they are > merged into the main trunk and break everything else? I do test on as much compilers I have accessible. In this particular case It was working on all compilers but Borland. I posted request for workaround while ago. Still no response. I had to test other configuration and I committed it. Actually I was surprised that so many compilers had an issue with completely innocent using declaration. Anyway I think it should be fixed as of last night. I found some hack that should work on complaining compilers. I will see the results of regression test today. As for creating separate brunch for Boost.Test development, I do not really mind. But I believe it will create an extra headache for regression testers (and me). Essentially we will need to have two copies of development tree. And run Boost.Test unit test in a separate tree. I will need to keep moving files back and forth 2 branches. Also I wonder how it will interact with release procedure. You may noticed that I am trying to introduce modification in Boost.Test in "packages", meaning I do not d code modifications all the time. I am not sure that several days of "no regression test on some compilers", worth all that trouble. Especially since all the developers could always rollback Boost.Test modification locally for development testing. Regards, Gennadiy.

4 10

boost::filesystem with network paths on windows
by Arne.Adams＠t-online.de 25 Aug '04

25 Aug '04

Hi, I am trying to use boost filesystem to copy files from a local directory to a directory on a network server (the latter having a path like \\databaseserver\c$\importfiles\myTabledump.txt <file:///\\databaseserver\c$\importfiles\myTabledump.txt> ) Unfortunately the leading double backslashs (\\) get converted in the constructor of filesystem::path to double slashs - yielding a different meaning. Is there a way to copy files on windows to network servers like this? Regards, Arne Adams Nerotal 23 65193 Wiesbaden Tel.: (+49) 611 3413745 Mobil: 0172 6147473 Mail: inbox(a)arneadams.com

3 2

[Boost.Thread] mutex Win32 implementation changes
by Michael Glassford 25 Jul '04

25 Jul '04

I've just checked in changes to Win32 implementations of the mutex and recursive_mutex classes. They now use a Win32 critical section instead of a mutex whenever possible for the normal and try_ variations, though not for the timed_ variations. These are changes that were started on the mutex classes quite some time back on the thread_dev branch; I've finished the changes and applied them to the recursive_mutex classes as well. In addition, the thread_dev branch has code that allows a mutex to be named, which allows it to be shared between two or more processes. This change was begun by Bill Kempf, but is only implemented for Win32. Any suggestions about the best way to add this feature to the pthreads and MPTasks implementations? Mike

4 35

boost/test/detail/algorithm.hpp: request for promotion and/or fast review
by Gennadiy Rozental 24 Jul '04

24 Jul '04

Hi, I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory): template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 ); template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred ); template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ) template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); Implementation together with doxigen docs is here: http://tinyurl.com/35pfj Test is here: http://tinyurl.com/yvlgu If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace. Gennadiy.

7 13

[filesystem + iterator] directory iterator problem
by Vladimir Prus 08 Jul '04

08 Jul '04

There's a bug report on sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=937606&group_id=7… which boils down to the fact that directory_iterator it(...); path p = *it++; does not work correctly. The exact problem is that the above line return a copy of the iterator, and increments 'it', but both iterators have shared_ptr to the same internal structure, so by time user deferences the copy, it gets the next file in the directory. The filesystem lib sources contain the following comment: The *r++ requirement doesn't appear to apply to the new single_pass_traversal category Thus I'm leaving the proxy out pending confirmation from the N1477 authors I'm not sure I understand that. It seems that *r++ should work, since signle pass iterator requires that r++ should work and return object of type X (call it r2), and the reabable iterator requires that *r2 should work. Am I wrong? And BTW, don't the above requirements mean r++ cannot return a proxy object, but only a real copy of the iterator? - Volodya

2 25

boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
by Christoph Ludwig 03 Jul '04

03 Jul '04

While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

4 21

[MPL] rational_c and fixed_c
by Cromwell Enage 30 Jun '04

30 Jun '04

A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning. Before I attempt to tackle this task anymore than I already have, I should have some questions answered. 1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression. Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input? Do I have to duplicate the functionality as a result? If so, what should be the naming convention for these new metafunctions? 2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this: template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; }; 3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how? 4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

3 7

[BGL] remove_edge bug
by Vladimir Prus 30 Jun '04

30 Jun '04

Jeremy, I think your reversion 1.120 of detail/adjacency_list.hpp: 2004-04-01 05:30 jsiek * detail/adjacency_list.hpp: fixed remove_edge for bidirectional graphs actually breaks remove_edge in a different way. Please take a look at http://zigzag.cs.msu.su:7813/program_graph.cpp The code there add two vertices, an edge between them, and then removes the edge. After that 'num_edges' returns 1, not 0 as expected. I seems like now remove_edge removes elements from out_edges and in_edges storage, but not from global edges vector. Is it possible to fix this problem? TIA, Volodya

2 3

[BGL] Unused parameter "inf" in dijkstra_shortest_paths?
by Douglas Gregor 30 Jun '04

30 Jun '04

Hmmm, this could be a bug, but I don't have time to look into it now: /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, size_t, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::edge_length_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = TravelTimePropertyMap, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' Doug

2 1

Thread lib (good reason for static)
by Peter Danford 11 Jun '04

11 Jun '04

[This is from an email about the impact of not having a static Threads lib available anymore. I wanted to post this here to see if anyone else has similar experiences since I have only seen posts about the problem of distributing RTL dlls so far - not computation time impact.] Hello, I was reading some some of the posts about your thread implementation and the removal of the static RTL option. I understand the technical reason for this, but I wanted to submit another compelling reason (for me) for the need for static RTL linkage even if this means loosing some of the features under win32. Some of the software I develop deals with different types of analysis (such as scientific and financial). The runs can take as much as 20 hours to complete. If I do nothing but change to link with dynamic RTL, the run time is increased on average of 35%. This means and additional 7 hours of run time! So dynamic RTL is really undesirable. Do you see any way of making a more limited static Boost.threads available in the next Boost release? [Above I say "limited" because some of the features of the Thread lib must be implemented via dll to work under win32.] Peter --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger

10 46