March 2006 - Boost - lists.preview.boost.org

[asio] Formal review results status
by Bulygin, Sergey 21 Mar '06

21 Mar '06

Hello! Let me come up with a question of curiosity. As [asio] formal review began on Dec'10 2005, there was a hope, that [asio] would become a part of Boost 1.34. Then it was taking weeks, but the review result is yet to be announced. Doubts arise of [asio] inclusion into Boost 1.35 already. Could the review manager or [asio] author give a clarification, what is the current state of [asio] formal review? What are the main reasons for formal review results delay? Are the issues raised in the formal review being addressed at that time? But according to the formal review process, this should happen right after the review completion. Sorry for impatience. :) Best Regards, Sergey Bulygin

4 3

[spirit] scanner_value_type_tests
by Vladimir Prus 21 Mar '06

21 Mar '06

Hello! The above test fails on large number of platforms, because of unresolved reference to char_traits<bool>::various_functions. I suppose that char_traits is explicitly instantiated for char and wchar_t for those compilers, so using it with 'bool' just does not work. Looks at the standard, it seems that non-specialized char_traits is not required to provide any member functions at all, so test that relies on any member functions in char_traits<bool> is wrong. Can somebody look into this, and fix the test? Thanks in advance, Volodya

2 1

A bug in smallest_last_vertex_ordering
by Roman Dementiev 21 Mar '06

21 Mar '06

Hi, I believe that boost::smallest_last_vertex_ordering has a bug. I tested the implementation with the CVS version from today. This is one of the graphs where it produces the wrong output: int n = 14; Edge edge_array[] = { Edge(0, 13), Edge(1, 5), Edge(1, 9), Edge(2, 6), Edge(3, 10), Edge(3, 4), Edge(7, 9), Edge(8, 12), Edge(11, 13) }; The attached picture bad_graph.jpg (ignore the directions) is a drawing of this graph. I have attached also a source file with a program that computes a smallest-last vertex ordering. Its output: Smallest-last vertex order: 2 6 10 4 3 5 1 7 9 0 13 11 8 12 The algorithm implementation removes nodes 12, then 8, 11, 12, 13, 0. But then it removes node 9 that has degree 2 at that moment, which is wrong, because nodes with a smaller degree exist (nodes 10,4,2,6,7,5). Can anyone fix this bug? With best regards, Roman #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/vector_property_map.hpp> #include <boost/graph/smallest_last_ordering.hpp> //#include <boost/graph/sequential_vertex_coloring.hpp> using namespace boost; typedef int Node; typedef std::pair<Node, Node> Edge; int main(int argc, char * argv[]) { typedef adjacency_list<listS, vecS, undirectedS> Graph; typedef graph_traits<Graph>::vertex_descriptor vertex_descriptor; typedef graph_traits<Graph>::vertices_size_type vertices_size_type; typedef property_map<Graph, vertex_index_t>::const_type vertex_index_map; int n = 14; Edge edge_array[] = { Edge(0, 13), Edge(1, 5), Edge(1, 9), Edge(2, 6), Edge(3, 10), Edge(3, 4), Edge(7, 9), Edge(8, 12), Edge(11, 13) }; int m = sizeof(edge_array) / sizeof(Edge); Graph g(edge_array, edge_array + m, n); std::cout <<"Number of nodes: "<<num_vertices(g) << std::endl; std::cout <<"Number of edges: "<<num_edges(g) << std::endl; std::vector<vertices_size_type> degree_vec(num_vertices(g)); std::vector<vertices_size_type> marker_vec(num_vertices(g)); vector_property_map<vertex_descriptor> order(num_vertices(g)); typedef iterator_property_map<vertices_size_type*, vertex_index_map> degree_i_map_type; iterator_property_map<vertices_size_type*, vertex_index_map> degree(&degree_vec.front(), get(vertex_index, g)); iterator_property_map<vertices_size_type*, vertex_index_map> marker(&marker_vec.front(), get(vertex_index, g)); typedef boost::detail::vertex_property_map<Graph, vertex_index_t>::type ID; typedef bucket_sorter<vertices_size_type, vertex_descriptor, degree_i_map_type, ID> BucketSorter; BucketSorter degree_bucket_sorter(n, n, degree, get(vertex_index, g)); smallest_last_vertex_ordering(g, order, degree, marker, degree_bucket_sorter); std::cout << "Smallest-last vertex order: "; for(int i=0;i<n;++i) std::cout << get(order,i) <<" "; std::cout << std::endl; return 0; }

2 4

[functional] boost::hash with 64-bit types
by Alexei Alexandrov 20 Mar '06

20 Mar '06

Hi boosters, I believe this question should already have been raised but I can't find any info on this: Why boost::hash is not specialized for 64-bit types by default? Is there any reasonable reason for that? Thanks a lot for the answer and for Boost itself. -- Alexei Alexandrov

3 7

[Filesystem] Getting default directories
by Hartmut Kaiser 20 Mar '06

20 Mar '06

Hi all, are there any plans to add functions to Boost.Filesystem to get different default directories such as get_user_home_dir(), get_app_config_dir(), get_system_config_dir() et.al.? On Windows these probably would map directly to the SHGetFolderLocation() function, on *nix based systems these could map to some equivalent environment variable (i.e. $HOME) or some convention (i.e. system config files are in /etc/...). Surely there are some conventions for other systems as well. Regards Hartmut

3 3

[ptr_container] building tests
by Roland Schwarz 20 Mar '06

20 Mar '06

While trying to run the tests for the MS vc6 compiler I found that the build is aborted when trying to build the serialization test. When I put toolset::require-boost-spirit-support into the Jamfile the build is correctly skipped instead of aborted. My version below: rule sc-serialization-test ( name : requirements * ) { return [ run $(name).cpp <lib>../../test/build/boost_unit_test_framework <lib>../../serialization/build/boost_serialization : : : toolset::require-boost-spirit-support ] ; } Since I do not yet know boost.build very good, I cannot tell if this works by accident or if it is correct. I figured this out by comparison with similar cases from other libs. I suspect this issue is not specific to the vc6 build, but might fail in other cases too. If there are no objections I will check this into CVS. (After the release branch.) Roland

1 0

1.33.1 Bugs, With Patches
by Stephan T. Lavavej 20 Mar '06

20 Mar '06

Hi, Boost 1.33.1 contains a number of constructs which cause warnings when compiled with GCC 3.4.2 (and other versions) using some warning flags. The majority of warnings are -Wshadow warnings and are easily correctable. One is a C cast that should be written as a const_cast. The most severe one is an omission of "const" that produces a warning under -Wcast-qual. I maintain a local patch that fixes these things (as otherwise I can't use these warning flags on my own code), but it'd be really nice if they were fixed in Boost mainline. The C cast and -Wcast-qual problems have obvious fixes. My fixes for the -Wshadow warnings involve prepending x_ to variable names, since I don't need to be inventive. Better names should probably be chosen. I reported these problems against 1.33.0, but they appeared unchanged in 1.33.1. My patch is here: http://stl.nuwen.net/boost-1.33.1.patch * The following files have shadow warnings: boost/date_time/gregorian/gregorian_io.hpp boost/date_time/period_formatter.hpp boost/date_time/time_duration.hpp boost/date_time/time_system_counted.hpp boost/format/format_implementation.hpp boost/regex/v4/basic_regex_creator.hpp boost/regex/v4/match_results.hpp * This file has shadow warnings, and a redundant typedef that causes a shadow warning: boost/regex/v4/basic_regex_parser.hpp * This file has a C cast that should be a const_cast: boost/range/detail/implementation_help.hpp * This file omits a "const", which causes a nasty -Wcast-qual warning: boost/token_iterator.hpp The omission of the const is not intentional, if you look at the template carefully. The warning that this generates is here: http://stl.nuwen.net/boost-warning.txt * This file says "bash" when it should say "sh". MSYS bash appears under "sh" but not "bash". This is really minor, since in 1.33.1 I don't even need to execute gcc_gen.sh, but it'd be nice to have it fixed. libs/regex/build/gcc_gen.sh Finally, Boost Regex's gcc.mak causes problems for MinGW MSYS. It really doesn't like trailing slashes. The patch for this is here: http://stl.nuwen.net/boost-1.33.1-gcc.mak.patch I believe that other systems don't require trailing slashes, but I'm not sure. (I am only concerned with the -I../../../ here; the optimization settings are purely for myself and should not be put into mainline.) Thanks! Stephan T. Lavavej

3 2

[asio] On Solaris
by Tomas Puverle 20 Mar '06

20 Mar '06

Hey, I just wanted to ask about the state of ASIO on Solaris. Looking at the docs, the library claims to use select() to check for events. May I suggest that you consider using /dev/poll? Starting with Solaris 10, there is also a new event completion framework. Thanks, Tom

2 2

[serialization] Archive reuse
by Marcin Kalicinski 20 Mar '06

20 Mar '06

I'm using serialization library to create UDP packets. My program is sending/receiving hundreds of these each second. I'm currently creating iarchive/oarchive for every packet sent/received. This is quite a performance bottleneck. Is it possible to reuse single binary archive object for all UDP packets? I.e. somehow reinitialize underlying stream with new data and read/write to the same archive again? thank you, Marcin

3 2

[Boost-bugs] [ boost-Patches-1452743 ] [regex] fixes warning on mingw
by SourceForge.net 20 Mar '06

20 Mar '06

Patches item #1452743, was opened at 2006-03-17 21:00 Message generated for change (Comment added) made by johnmaddock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Baraclese (baraclese) Assigned to: John Maddock (johnmaddock) Summary: [regex] fixes warning on mingw Initial Comment: [regex] [current cvs] mingw automatically defines NOMINMAX in bits/ os_defines.h to protect some standard headers. Compiler thus emits a warning about redefinition of NOMINMAX in static_mutex.cpp. [solution] Add #undef NOMINMAX before #define NOMINMAX to file libs\regex\src\static_mutex.cpp(27) Other files which define this are: libs\regex\src\regex.cpp(31) libs\regex\src\w32_regex_traits.cpp(27) ---------------------------------------------------------------------- >Comment By: John Maddock (johnmaddock) Date: 2006-03-20 10:33 Message: Logged In: YES user_id=14804 This will be fixed in cvs shortly. John Maddock ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0