- Boost - lists.boost.org

[interval containers (itl)] found review manager. New release on sourceforge
by Joachim Faulhaber 18 Jan '10

18 Jan '10

Dear list! I am pleased to announce that Hartmut Kaiser now supports my library of interval containers as review manager. Although this was not necessarily intended, the planned date for the review already found it's way into the review schedule. But this is unofficial as long as Hartmut has not done his announcement of the review period. In preparation to the review I have done some improvements mainly for documentation of the extended parts of the itl, so I have uploaded a new release to the itl's project page on sourceforge http://sourceforge.net/projects/itl/ There are a few corrections and additions to the quickbook docs of the core library itl which is submitted for review: http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html For the extended parts there is a doxygen generated documentation http://www.herold-faulhaber.de/itl/index.html that now also contains a commented example for a law based test http://www.herold-faulhaber.de/itl/de__morgan_8cpp.html for people how are interested how this works. Any feed back, comments and suggestions are welcome. Best regards Joachim --------------------------------------------------------------------- Interval Template Library (ITL) | Boost.IntervalContainers --------------------------------------------------------------------- Availability: Project page at sourceforge: http://sourceforge.net/projects/itl/ Boost Vault: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Conta… Boost Quickbook documentation (corelibrary itl) http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Doxygen Documentation (extensions itl_xt, validate) http://www.herold-faulhaber.de/itl/index.html The name ITL is provisional and will probably be changed to Boost.IntervalContainers after the review.

1 0

[property_tree] stream_translator <-> lexical_cast
by Domagoj Saric 18 Jan '10

18 Jan '10

By scanning briefly through the property_tree implementation I noticed that it uses its own stream_translator<> class for string-to-other_type and vice verse conversions. The functionality seems very similar/overlapping to that of lexical_cast (and also uses streams), if this is true this part of property_tree should probably be refactored to use lexical_cast so that it gets implicitly 'fixed' when/if lexical_cast gets fixed (regarding the issues outlined in the previous relevant post). -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

1 0

Boost.Filesystem: basename function is not compatible with POSIX; potential for path-related security issues
by Steve M. Robbins 18 Jan '10

18 Jan '10

Hi, I got the following report [1] for Boost.Filesystem from a Debian user. Before entering into trac, I thought I'd ask whether this deviation from POSIX is by design or is a bug. Thanks, -Steve P.S. The original report is based on Boost 1.40, but I verified the same behaviour on Boost 1.41. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565504 ----- Forwarded message from Roger Leigh <rleigh(a)debian.org> ----- Package: libboost-filesystem1.40.0 Version: 1.40.0-5 Severity: important The basename function is not compatible with the POSIX function by the same name: Path POSIX Boost test.real test.real test /usr/bin/perl perl perl /usr/lib lib lib /usr/ usr usr usr usr / / / . . .. .. . The test program is attached. Just compile with g++ -o testbasename -lboost_filesystem testbasename.cc http://www.opengroup.org/onlinepubs/000095399/functions/basename.html ??? It is not stripping trailing backslashes. ??? "if ph.leaf() contains a dot ('.'), returns the substring of ph.leaf() starting from beginning and ending at the last dot (the dot is not included). Otherwise, returns ph.leaf()". This is wrong, shown by the paths returned for "." ("") and ".." (".") above. The latter could lead to reading and writing using the wrong path, which could have security issues if used in a secure context. This might be justification for raising the severity of this bug. Looking at the API reference, it looks like extension() and basename() may be intended to be complementary and are for splitting a filename into its main part and extension part, *not* the directory and filename components of a path. This should probably be explicitly spelled out due to the dangerous confusion which may result if used inappropriately. In particular, "." and ".." definitely need special casing--these are not extension separators and basename should return them intact; extension() should return an empty string. I noticed this when converting schroot to use the boost convenience function instead of my own. For reference, this is my version: std::string sbuild::basename (std::string name, char separator = '/') { // Remove trailing separators std::string::size_type cur = name.length(); while (cur > 0 && name[cur - 1] == separator) --cur; name.resize(cur); // Find last separator std::string::size_type pos = name.rfind(separator); std::string ret; if (pos == std::string::npos) ret = name; // No separators else if (pos == 0 && name.length() == 1 && name[0] == separator) ret = separator; // Only separators else ret = name.substr(pos + 1); // Basename only // Remove any duplicate adjacent path separators return remove_duplicates(ret, separator); } A POSIX-compatible dirname() function would nicely complement a POSIX-compatible basename() function as an addition to boost::filesystem. It looks like these are orthogonal to the existing functionality, however. Regards, Roger -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost-filesystem1.40.0 depends on: ii libboost-system1.40.0 1.40.0-5 Operating system (e.g. diagnostics ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 libboost-filesystem1.40.0 recommends no packages. libboost-filesystem1.40.0 suggests no packages. -- no debconf information #include <libgen.h> #include <boost/filesystem/convenience.hpp> #include <cstring> #include <iostream> #include <iomanip> int main () { const char *paths[] = { "test.real", "/usr/bin/perl", "/usr/lib", "/usr/", "usr", "/", ".", "..", 0 }; std::cout << std::setw(16) << std::left << "Path" << std::setw(16) << std::left << "POSIX" << std::setw(16) << std::left << "Boost" << '\n'; for (const char **path = &paths[0]; *path != 0; ++path) { char *bpath = strdup(*path); std::cout << std::setw(16) << std::left << *path << std::setw(16) << std::left << basename(bpath) << std::setw(16) << std::left << boost::filesystem::basename(*path) << '\n'; free(bpath); } return 0; } _______________________________________________ pkg-boost-devel mailing list pkg-boost-devel(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-boost-devel ----- End forwarded message -----

2 1

String literals concatenation issue when using BOOST_CURRENT_FUNCTION
by vicente.botet 16 Jan '10

16 Jan '10

Hi, I want to define a macro as #define BOOST_CHRONO_DIGITAL_TIME_FORMAT(F) "\n" F " tokes %d day(s) %h:%m:%s.%n\n" #define BOOST_CHRONO_DIGITAL_TIME_FUNCTION_FORMAT BOOST_CHRONO_DIGITAL_TIME_FORMAT(BOOST_CURRENT_FUNCTION) I have a compile error with gcc(3.4.4 or 4.4.0) (Boost v1.41) in the following sentence const char* c= "\n" BOOST_CURRENT_FUNCTION " %d day(s) %h:%m:%s.%n\n"; C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp: In function `int f1(long int)': C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp:24: error: expected `;' before "__PRETTY_FUNCTION__" as well as const char* c= "\n" __PRETTY_FUNCTION__ " %d day(s) %h:%m:%s.%n\n"; The same code works as I expected with MSVC. The following code works well with gcc const char* c= "\n" "f" " %d day(s) %h:%m:%s.%n\n"; const char* c2= BOOST_CURRENT_FUNCTION; as well as this one const char* c= "\n" __FILE__" %d day(s) %h:%m:%s.%n\n"; Is there something wrong? Does gcc manage __PRETTY_FUNCTION__ and __FILE__ differently? Does someone knows a workaround? Best, _____________________ Vicente Juan Botet Escribá

2 3

[python] const-correctness and get_signature
by Jim Bosch 16 Jan '10

16 Jan '10

I've been working on an idea to provide optional const-handling in boost.python wrapped classes. It's coming along pretty well, but I've run into one major sticking point: the get_signature functions that extract the argument types of member function pointers into mpl sequences remove any cv-qualification on the hidden 'this' argument. This seems to be intentional - from the comments in python/signature.hpp: // Note that cv-qualification is dropped from // the "hidden this" argument of member functions; that is a // necessary sacrifice to ensure that an lvalue from_python converter // is used. This doesn't actually seem necessary; for a normal wrapped class, the special-case lvalue converter will always be the highest priority, and for a const member function, supporting rvalue converters as a fall-back wouldn't do any harm that I can see (and would help me out considerably). Could this be a relic from before wrapped class lvalue conversions were handled as a special case? Anyhow, if my hypothesis is correct, and there isn't a need to drop the cv-qualifiers in get_signature, I'd like to make a ticket and submit a patch to change it - but I wanted to check here first to see if maybe that breaks something else. Thanks! Jim Bosch

1 0

[release] files from previous releases (was: Re: [ Fusion ] Extra files in "release"?)
by Tobias Schwinger 15 Jan '10

15 Jan '10

Joel de Guzman wrote: > Marshall Clow wrote: >> Hey Joel -- >> >> I noticed that there are a bunch of fusion files that only exist in >> the release branch, and not in the trunk. >> Is that on purpose? > Thanks for reporting! Seems a "release procedure issue" to me; the trunk has apparently been copied over an old release where those files were still present and needed. Those files can be deleted from the release branch (gone from trunk since February 09, last changes on Fusion in June 09). I just read that the release branch is about to freeze so posting to boost.devel for the Release Managers to join in. Also, there might be similar issues for other libraries. >> boost/fusion/functional/adapter/detail/pow2_explode.hpp >> boost/fusion/functional/adapter/detail/pt_def.hpp >> boost/fusion/functional/adapter/detail/pt_undef.hpp >> boost/fusion/functional/adapter/unfused_generic.hpp >> boost/fusion/functional/adapter/unfused_lvalue_args.hpp >> boost/fusion/functional/adapter/unfused_rvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_generic.hpp >> boost/fusion/functional/generation/make_unfused_lvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_rvalue_args.hpp >> >> libs/fusion/doc/html/fusion/functional/adapters/unfused_generic.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_lvalue_args.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_rvalue_args.html >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_rvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_rvargs.html >> >> libs/fusion/test/functional/make_unfused_generic.cpp >> libs/fusion/test/functional/make_unfused_lvalue_args.cpp >> libs/fusion/test/functional/make_unfused_rvalue_args.cpp >> libs/fusion/test/functional/unfused_generic.cpp >> libs/fusion/test/functional/unfused_lvalue_args.cpp >> libs/fusion/test/functional/unfused_rvalue_args.cpp >> Regards, Tobias

6 14

[python] patch modules_init.hpp to expand macros
by Neal Becker 15 Jan '10

15 Jan '10

This patch replaces use of ## and # with BOOST_PP_CAT and BOOST_PP_STRINGIZE. This is needed so that python module names can be programmatically generated. https://svn.boost.org/trac/boost/ticket/3843

1 0

how to compile when using read_graphml
by Alexandre de Morais Amory 15 Jan '10

15 Jan '10

Hi, I've been trying to use the function from read_graphml from BGL. I am using the test case in http://lists.boost.org/Archives/boost/2007/04/119804.php as my first case study. Apparently it compiles ok, but there is a link error. See msg bellow: ====== aamory@gaph14:~/reps/test-tools/bgl/test/sandbox-bgl$ g++ reader_test.cc In file included from /usr/include/c++/4.4/backward/hash_set:59, from /usr/include/boost/graph/adjacency_list.hpp:25, from reader_test.cc:1: /usr/include/c++/4.4/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. /tmp/ccgvAjHU.o: In function `void boost::read_graphml<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS> >(std::basic_istream<char, std::char_traits<char> >&, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS>&, boost::dynamic_properties&)': reader_test.cc:(.text._ZN5boost12read_graphmlINS_14adjacency_listINS_4vecSES2_NS_9directedSE11VertexPropsNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEES7_NS_5listSEEEEEvRSiRT_RNS_18dynamic_propertiesE[void boost::read_graphml<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS> >(std::basic_istream<char, std::char_traits<char> >&, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS>&, boost::dynamic_properties&)]+0x3d): undefined reference to `boost::read_graphml(std::basic_istream<char, std::char_traits<char> >&, boost::mutate_graph&)' collect2: ld returned 1 exit status aamory@gaph14:~/reps/test-tools/bgl/test/sandbox-bgl$ ======= I guess there should be some library. Reading the doc in http://www.boost.org/doc/libs/1_38_0/libs/graph/doc/read_graphml.html it says that the lib "bgl-graphml" should be included, but I don't known where to find it. At the /usr/lib there is only the files libboost_graph-mt.a, libboost_graph-mt.so, libboost_graph-mt.so.1.38.0 It seems that the problem is just to correctly define the compilation command ... any help would be much appreciated. configuration: - boost 1.38.0 - ubuntu 9.10 64 bits - g++ 4.4.1 Thanks! Alexandre

2 4

[iterator] iterator_facade reference type problem
by Phil Endecott 15 Jan '10

15 Jan '10

Dear All, I have a problem with boost::iterator_facade. Here's an example: say I'm implementing an associative container that stores a sorted vector of keys and a separate sorted vector of values: template <typename KEY, typename VALUE> class vecmap { std::vector<KEY> keys; std::vector<VALUE> values; I can make an iterator for this that stores one iterator for each of the vectors: class iterator: public boost::iterator_facade<iterator, std::pair<KEY,VALUE>, boost::bidirectional_traversal_tag> { std::vector<KEY>::iterator ki; std::vector<VALUE>::iterator vi; void increment() { ++ki; ++vi; } void decrement() { --ki; --vi; } .... But what do I do about the reference type? I can't use std::pair<const KEY,VALUE>& because I'm not storing the keys and values in that way. It's almost possible to use std::pair<KEY,VALUE> for a const_iterator, but not if you want to allow the user to change the value through the reference. What I think I want to use is std::pair<KEY,VALUE&> i.e. the key is returned by value and only the value is returned by reference. But when I try this I get various cryptic errors about references to references and mpl things. So, has anyone else tried to do something like this? I wonder if boost::reference could be part of the solution. Thanks for any suggestions, Phil.

3 6

[graph][release][1.42] Debug code removal in release branch
by Jeremiah Willcock 15 Jan '10

15 Jan '10

A user reported some debugging code that had been left in Boost.Graph for a couple of releases. It is a simple patch and a really embarrassing bug to leave in. It is change 59005 in trunk: Index: read_graphviz_new.cpp =================================================================== --- read_graphviz_new.cpp (revision 59004) +++ read_graphviz_new.cpp (revision 59005) @@ -764,7 +764,7 @@ typedef boost::detail::graph::node_t vertex; typedef boost::detail::graph::edge_t edge; for (std::map<node_name, properties>::const_iterator i = r.nodes.begin(); i != r.nodes.end(); ++i) { - std::cerr << i->first << " " << props_to_string(i->second) << std::endl; + // std::cerr << i->first << " " << props_to_string(i->second) << std::endl; mg->do_add_vertex(i->first); for (properties::const_iterator j = i->second.begin(); j != i->second.end(); ++j) { mg->set_node_property(j->first, i->first, j->second); @@ -772,7 +772,7 @@ } for (std::vector<edge_info>::const_iterator i = r.edges.begin(); i != r.edges.end(); ++i) { const edge_info& ei = *i; - std::cerr << ei.source << " -> " << ei.target << " " << props_to_string(ei.props) << std::endl; + // std::cerr << ei.source << " -> " << ei.target << " " << props_to_string(ei.props) << std::endl; edge e = edge::new_edge(); mg->do_add_edge(e, ei.source.name, ei.target.name); for (properties::const_iterator j = ei.props.begin(); j != ei.props.end(); ++j) { @@ -782,7 +782,7 @@ std::map<subgraph_name, properties>::const_iterator root_graph_props_i = r.graph_props.find("___root___"); assert (root_graph_props_i != r.graph_props.end()); // Should not happen const properties& root_graph_props = root_graph_props_i->second; - std::cerr << "ending graph " << props_to_string(root_graph_props) << std::endl; + // std::cerr << "ending graph " << props_to_string(root_graph_props) << std::endl; for (properties::const_iterator i = root_graph_props.begin(); i != root_graph_props.end(); ++i) { mg->set_graph_property(i->first, i->second); } May I please put this into the release branch for 1.42? Thank you. -- Jeremiah Willcock

2 2