- Boost - lists.boost.org

[1.38] CMake support added to release branch?
by John Maddock 08 Feb '09

08 Feb '09

I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened? John Maddock.

8 11

function dispatch mismatch in graph_traits
by Sandeep Gupta 08 Feb '09

08 Feb '09

Hi, I am having trouble making leda_graph wrapper for GRAPH<vtype, etype> class. In leda_graph.hpp the wrapper is defined as template<class vtype, class etype> ... vertices(const leda::GRAPH<vtype, etype>& g) { do_something; } Given this definition the right (and only way i think) to invoke it by expression vertices<vtype, etype>(G) My problem is that all internal graph routines invoke the function by expression vertices(G) I would appreciate any ideas about how can i redirect vertices(G) to vertices<vtype, etype>(G) where vtype = vrec etype = erec G = leda::GRAPH<vrec, erec> I am afraid that i might have to rewrite a wrapper for specifically leda::GRAPH<vrec, erec>. Can this be avoided. Thanks sandeep

2 2

Review Request: Boost.Log
by Andrey Semashev 08 Feb '09

08 Feb '09

Hi, I'd like to ask for a formal review for the Boost.Log library. The archive with the library source code, tests and docs is available in the Vault: http://tinyurl.com/cm9lum The online docs are also available on the SourceForge page: http://boost-log.sourceforge.net The latest code snapshot can be downloaded from CVS on the SourceForge project page: http://sourceforge.net/projects/boost-log

1 0

[1.38.0] branches/release frozen
by Beman Dawes 08 Feb '09

08 Feb '09

I plan to do the actual release Sunday. Please make no further commits to branches/release. If there are any known showstoppers, please let me know right away. Thanks, --Beman

6 12

[statechart] rebind -> exception_translator error
by k-oli＠gmx.de 08 Feb '09

08 Feb '09

Hello, I get following compile time error (using gcc version 4.3.1 on Debian/Lenny) for a test async_state_machine: /opt/boost/include/boost-1_37/boost/detail/allocator_utilities.hpp:149: error: no class template named 'rebind' in 'class boost::statechart::exception_translator<boost::statechart::exception_thrown>' regards, Oliver

2 1

build system testing
by Neil Groves 08 Feb '09

08 Feb '09

Hello, I have noticed that work is going ahead to introduce CMake, and possibly SCons build systems alongside bjam. Does this not introduce an explosion in required testing combinations, and is this already being addressed? I fully appreciate the attraction of adding CMake, but would like to ensure we do not add too many build systems due to the potentially excessive requirement on library developer to install a plethora of tools, and perform an enormous amount of testing. I wonder if a static analysis tool might be able to help determine the consistency of bjam to the other build systems. Anyhow, I haven't seen much discussion about testing, and if it's not tested it's probably broken! (At least if I've written it!) Regards, Neil Groves

4 3

[random] Patch for ticket 2703
by Steven Watanabe 08 Feb '09

08 Feb '09

AMDG In lagged_fibonacci_01, the overload of seed that takes a pair of iterators does not always detect the end of the range correctly. The attached patch fixes this and adds a test case. Ok to commit? In Christ, Steven Watanabe

2 1

[format] please add operator String()
by Thorsten Ottosen 08 Feb '09

08 Feb '09

Hi, In code like this: std::string columns() const { return (boost::format("%7s, %7s, %7s, %7s") % "testCost" % "optimalEcr" % "efficiecyEcr" % "testCostEcr").str(); } it is very annoying to have to put () around the whole expression and then call .str() (Just imagine that we are creating a string on the fly to a function). Therefore I suggest that we add operator string_type() const { return str(); } to the interface of basic_format<>. Any comments? -Thorsten

7 8

FW: [filesystem] : basic_path : Feature request
by Rob 07 Feb '09

07 Feb '09

> These seem like reasonable requests, although I'd have to check the > std::back_inserter to be 100% sure. > I have checked this using a wrapper around path as follows template<class String, class Traits> struct rob_basicpath : boost::filesystem::basic_path<String, Traits> { typedef string_type& reference; typedef const string_type& const_reference; inline void push_back(const_reference path) { *this /= path; } }; This allowed me to use the following code as expected (which strips . characters from the path) const boost::filesystem::path path("dir1/./dir2/./dir3"); rob_path rpath; std::remove_copy(path.begin(), path.end(), std::back_inserter(rpath), "."); > Note however that path has some but not all of the characteristics of > a standard container. I'd want to see persuasive use cases for adding > functionality - just making path more like a std container without > good reason is likely to lead to interface bloat without offsetting > benefits. My reasoning for this is as follows: 1. path is wrapper around a string, which is what would be used in the absence of path object. String supports this interface and using path should not be a step backwards. 2. A variety of tasks I envisage on a path can be neatly and succinctly implemented using std algorithms. In particular, I have several uses for copy or remove_copy to create similar paths with a slight difference. The ability to use a back_inserter allow paths to be built up from other paths or any container of strings. Without this, my solution for removing '.' involved the same code but I had to insert into a vector first and later iterate through this to create the new path. > A use case would make this [pop_back()] more compelling. My code above to remove '.' was part of a 'canonicalize' function which removed both '.' and '..' where possible. (This may be a candidate for a convenience function within the library?) My solution was as follows std::vector<std::wstring> parts; BOOST_FOREACH(std::wstring part, path) { if (L"." == part) continue; if (L".." == part && parts.size() && L".." != parts.back()) parts.pop_back(); else parts.push_back(part); } boost::filesystem::wpath simple; BOOST_FOREACH(std::wstring part, parts) simple /= part; return simple; Whilst this is IMO reasonably elegant, I still have the extra step of building my new path in a vector, then creating the path from this. The addition of pop_back() to path would allow the path to be built up without the vector. Given that path allows the path to be considered as a container of path elements, I would like to see this extended. A reverse iterator would be nice to step back from the given path up to the root. Pop_back would equate to stepping back to the parent directory and seems a useful feature. Given that there exists a function to remove the filename, this also seems to be relatively easy to implement (as an inlined function?) I have only recently discovered filesystem::path and, given my current project's requirements for directory manipulation, this is a fantastic help. Cheers Rob

5 5

[thread] Why is thread_interrupted not derived from thread_exception or std::exception?
by Boris Schaeling 07 Feb '09

07 Feb '09

Why is thread_interrupted not derived from thread_exception or std::exception? It might easily slip through a try/catch-block, and if I hadn't looked up the header file now it might have slipped through mine. Boris

4 3