- Boost - lists.boost.org

[Boost-docs] [quickbook] [MPL] Knowing where you are the wrong way (was: Re: know where you are)
by Daryle Walker 21 Mar '06

21 Mar '06

[I've added the main Boost list to this response so the MPL guys can see it.] On 3/16/06 5:46 AM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > In the link I presented a while ago (http://snipurl.com/no8s) > you might have noticed that the headings are clickable. > Headings now link to itself. Again, this is borrowed from > the MPL docs. This allows you to right click and copy > the URL, for example (especially useful in deeply nested > sections). You know where you are, anywhere. [That URL is <http://spirit.sourceforge.net/dl_docs/quickbook_doc/quickbook/doc/html/quic kbook/intro.html>, BTW. Check out the first word "Introduction" right before the quote for the link Joel is talking about.] I've read on some web design website that this is horrible UI. This is a feature that may be "kewl" for very advanced users, but it's obscure for above-average users, and detrimental to anyone else. 1. This word is an out-link without looking like an out-link. We shouldn't be presenting data like Easter egg hunts. You could counter by saying that the disguise is a good thing to dissuade newbies, but then how could oldbies discover it without looking at the source, scrubbing the page, or reading this e-mail? (It's a variant of guideline #3 at <http://www.useit.com/alertbox/20031110.html>.) 2. Out-links to the same page is confusing to newbies. They'll think "my link click failed," not "it's a mnemonic for my browser's 'copy URL link' contextual-menu function." (It's based on guideline #10 from the web page I mentioned in [1].) 3. You implemented it as: <a name="quickbook.intro"></a><a href="intro.html" title="Introduction">Introduction</a> As I said before, using an empty "<a name>" as an in-link is a bad idea. You need to associate the link with something. AFAIK, nothing prevents an anchor from being an in- and out-link simultaneously: <a href="intro.html" name="quickbook.intro" title="Introduction">Introduction</a> If you don't care about anything before HTML-4, you can use the "id" attribute to mark destinations. (That's why it shares the same namespace as the "name" attribute.) <h2 id="quickbook.intro">Introduction</h2> So my final advice is to remove this mis-feature, and have the MPL docs purge it too. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[Serialization] xml_archive version
by Richard Crossley 21 Mar '06

21 Mar '06

Hi, I'm trying to read in a xml_archive created by a previous version of the serialization library (version="3") with the version from CVS head (version="4"). The reading fails in load_collection here as there is no "item_version" field. if(3 < ar. get_library_version ()){ ar >> BOOST_SERIALIZATION_NVP(item_version); } Shouldn't a xml_archive be doing a set_library_version() based on the version of the archive it's reading, or am I missing something? Regards, Richard.

2 1

[Wave][Serialization] Problems with class versioning
by Hartmut Kaiser 21 Mar '06

21 Mar '06

Hi all, I was trying to add class versioning to the serialization code for the Wave library (for storing macro tables et.al.) but couldn't succeed. I've added a class version to the code by adding: namespace boost { namespace serialization { template< typename Iterator, typename LexIterator, typename InputPolicy, typename Hooks > struct version<boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> > { typedef boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> target_type; typedef mpl::int_<target_type::version> type; // version == 0x100 typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; }} // namespace boost::serialization The save function of the context<> now get's called during serialization with the correct version value. But during load the context<>::load function still get's passed zero as the loaded version. Is this a known behaviour, am I ding something wrong (perhaps essential: context is explicitely marked as 'track_never')? Regards Hartmut

2 2

[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