- Boost - lists.boost.org

v2.0 of Identification library
by joel 03 Jul '09

03 Jul '09

I've uploaded an updated version of the identification library in the Vault some weeks ago and IIRC I forgot to mention it. From the doc : "Boost.Identification is a library which aims at providing a simple solution for building a textual representation of a type as a string that can be manipulated at run-time. Such a feature is often desirable when someone wants to dynamically debug large template class instantiation or use a easy to use `type string representation` to use in serialization process or exception display. Those tasks are often done using the typeid operator but its output is compiler dependant and often produce strings which are usually hard to decipher." Comments and remarks are most welcome. I'll also ask vicente to add it to the Library In Progress wiki page. Thanks in advance. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

6 8

boost::spirit -- semantic values
by Anand 03 Jul '09

03 Jul '09

I couldn't find a way to associate a semantic value with a non-terminal. Bison/yacc allows this. For example, here is a rule in Bison that says an expression can be the sum of two subexpressions: expr: expr '+' expr { $$ = $1 + $3; } ; The action says how to produce the semantic value of the sum expression from the values of the two subexpressions. Having semantic values for non-terminals is useful to build an expression tree. For, e.g, I can create a new node in the tree by passing in the semantic values of child nodes in the action. expr: expr '+' expr { $$ = makeNode($1, $3, "+"); } ; In this case the semantic value for each expression is of type Node*. Spirit provides parse trees and ASTs and also semantic actions that take the first last iterator pair. But is there some way I can associate a semantic value with each non-terminal and pass in these semantic values to the action for the rule. Thanks, Anand

2 1

Units of data
by Zachary Turner 03 Jul '09

03 Jul '09

Has anyone extended (even privately) Boost.Units to include support for units of data (bits, bytes, KB, MB, etc)? It seems like this would be a useful addition to Boost.Units. Assuming no, what is the minimum amount of work required to do this myself? There's not a lot of info in the docs on how to define new base units, although I've already begun looking over the source code to try to come up with something.

3 12

[BGL] on using visitor in dijkstra_shortest_path
by Sandeep Gupta 02 Jul '09

02 Jul '09

Hi, The example code for extending dijkstra via gives compilation errors. Attached below is the snippet code and the error messages using gcc-4.3.3 and boost_138_0. typedef boost::adjacency_list<vecS, vecS, bidirectionalS > graphImpl_t; //----taken for doc--- template <class PredecessorMap> class record_predecessors : public dijkstra_visitor<> { public: record_predecessors(PredecessorMap p) : m_predecessor(p) { } template <class Edge, class Graph> void edge_relaxed(Edge e, Graph& g) { // set the parent of the target(e) to source(e) put(m_predecessor, target(e, g), source(e, g)); } protected: PredecessorMap m_predecessor; }; template <class PredecessorMap> record_predecessors<PredecessorMap> //error: expected constructor, destructor, or type conversion before ‘<’ token make_predecessor_recorder(PredecessorMap p) { return record_predecessors<PredecessorMap>(p); } ///---end doc-------------- ..... ... vector<vertex_t> p(num_vertices(gg)); dijkstra_shortest_paths(gg, src, predecessor_map(preds).weight_map(weights).distance_map(dists).visitor(make_predecessor_recorder(&p[0]))); Thanks in advance. -sandeep

3 7

[ann] Urdl - a library for downloading web content
by Christopher Kohlhoff 02 Jul '09

02 Jul '09

Hi all, I have just released a new Boost.Asio-based library, Urdl, which can be used for accessing and downloading web content. <http://think-async.com/Urdl> <http://sourceforge.net/projects/urdl> It currently has limited support for the protocols "http", "https" and "file". It provides an easy-to-use extension to standard C++ iostreams and an asynchronous interface for use with Boost.Asio. In addition to (hopefully) being useful, it is intended as an example of using the Boost.Asio and Boost.System libraries. If you're writing protocol implementations using Asio, you might also be interested in how it uses coroutines to simplify the expression of asynchronous control flow. (Note: here coroutines refers to a macro-based system similar to <http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html>, not Giovanni Deretta's GSoC project). Cheers, Chris

11 20

Fixed point implicity
by Soren Holstebroe 02 Jul '09

02 Jul '09

Hi, I'm generalizing my fixed point class and have come across a few design decisions. 1. Return type of additive arithmetic operation between integers and fixed points Example: a 16 bit integer is added to a 16 bit fixed point with 8 bit fraction. I see three possible return types: 16 bit integer, 16:8 fixed point and promoted 32:8 fixed point If return type is 16 bit integer, the fraction is lost. Clearly not an option. If return type is 16:8 fixed point overflow is possible. A return type of 32:8 would eliminate overflow, but promotion quickly becomes problematic for larger integer types, lets say a 32 bit integer added to a fixed point. In that case we would need a 64 bit integer which could cripple performance on many systems. Another problem with promotion is that the arithmetic expression typically would be in a context where the expression is assigned to a fixed point of the type present in the expression. In that case we have an overflow problem again. I think I favor keeping the return type in 16:8. The user would then have to use an explicit cast to avoid overflow. 2. Return type of additive arithmetic operation between float and fixed points Example: fixed_point<int, 16>(10.5) + 5.5f (integer is representing type, 16 bit is the bit reserved for the fraction) What would you expect the return type to be? I think I favor returning a float. The accuracy of the fixed point is compromised anyway. 3. Return type of additive arithmetic operation between different fixed point types Example: fixed_point<int, 16>(10.5) + fixed_point<int, 8>(10.5) Like in case 1 there is the choice between losing precision, risking overflow or promoting (ex. to fixed_point<boost::int_t<16 + 8>::fast, 16>) I think I favor to simply disallow implicit arithmetic between different fixed point types. This would require the user to cast either type. The problem with that choice is less transparent use of the fixed_point type, since changing a type could break existing code where the previous type was in a valid arithmetic operation with another fixed point type. 4. Similar problems exist for multiplication and division If a fixed_point is multiplied with an integer there is a risk of overflow. If a fixed_point is multiplied with another fixed_point there is a risk of overflow and precision will be lost. If a fixed_point is divided by an integer there is a risk of loss of precision. If a fixed_point or integer is divided by another fixed_point there is a risk of overflow and loss of precision. Soren

5 8

Messages lost
by Chard 02 Jul '09

02 Jul '09

I made two posts to this group on 30 June, around 21:00 UTC. Both received acknowledgements, but neither have appeared. A post to the users group, made at about the same time, appeared there immediately. New messages later than my posting time are appearing, so it doesn't look like it's back-log. Are there any known problems? Apologies if this should be directed elsewhere, but at the moment there doesn't seem to be a route open to www.boost.org (to find out); certainly from my ISP...sigh. (Posting this one at 21:30 UTC)

2 2

[task] 0.2.1 Doesn't compile on VC7.1 / older gcc
by Chard 02 Jul '09

02 Jul '09

Hi Oli, As documented, you're testing MS compilation with VC9. We're currently tied to VC7.1 and as we use a threadpool heavily (Philipp Henkel's) I have a particular interest in seeing an 'official' boost threadpool. So forgive me if I keep these coming ;-) There is another VC7.1 compiler conformance issue: static_pool now has the contained pool_base class. The pool_base::submit method constructs a handle<>, however, this has the VC7.1 'friend access to contained class' problem. The handle<> (non-default) constructor is private, granting friend access to static_pool, however, static_pool<>::pool_base requires access, and VC7.1 barfs. I couldn't figure out the friend syntax (that works) to add to class handle<>, so for now I'm working with handle<> (hacked as) public. (Note: earlier versions of gcc, e.g. 3.4.4, will exhibit this problem, too.) I thought this would've been the syntax: # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template <typename Channel> friend class static_pool<Channel>::pool_base; # endif but it doesn't appear to be legal. Is this type of declaration even possible? An alternative would be to move (some or all of) the functionality to the outer static_pool class, and route the inner pool_base class to it, e.g. template< typename R > handle< R > static_pool::pool_base::submit( boost::detail::thread_move_t< task< R > > t_) { static_pool::submit(*this, _t); } template< typename R > static handle< R> static_pool::submit(pool_base &pb_, boost::detail::thread_move_t< task< R > > t_) { ... } Or, perhaps just the handle creation line. However, it may be tidier just to have a detail::create_handle (that is the handle<> friend), seeing as you are just trying to say nobody else should be constructing a handle. Regards, and keep up the good work...

2 1

[task] 0.1 => 0.2.1 removes make_task
by Chard 02 Jul '09

02 Jul '09

Task version 0.1 => 0.2.1 comment. make_task appears to have been removed and the multiple argument mechanism migrated to the task constructor. AFAICT this has removed functionality because the make_task helper had the benefit of determining the return value of the task. The task class is templated on the return type, so the user if forced to declare it (okay, not a great deal, but then we have conveniences like make_pair). e.g. 0.1: task::async(threadpool, task::make_task(TaskFunc)); 0.2.1 (argument order exchanged in 0.2.1): task::async(move(task::task<void>(TaskFunc)), threadpool); I assume the reasoning behind this was the cut-over to using move semantics; if this is the case then the constructor: explicit task( Fn fn, BOOST_ENUM_TASK_MAKE_TASK_FUNC_ARGS(n)) \ : task_( new detail::task_wrapper< \ typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type, \ function< typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type() > \ >( bind( fn, BOOST_PP_ENUM_PARAMS(n, a)) ) ) \ {} may as well not use result_of; is this not just the template argument, R ? Could make_task have been preserved, but modified to return the move-type ?

2 1

boost::interprocess - lnk2005 error due to compiler/linker bug in msvc8
by willem hengeveld 01 Jul '09

01 Jul '09

when using boost::interprocess under win32, i ran into the following problem: in boost/interprocess/detail/win32_api.hpp several static inline functions have a function local class for releasing resources, like 'unlink_file', which defines 2 classes: handle_closer, and auto_ptr due to a compiler bug, as discussed here: http://www.eggheadcafe.com/conversation.aspx?messageid=32706692&threadid=32… you get a LNK2005 error <symbol> already defined in <object> when using boost::interprocess from multiple .cpp files a solution is to use boost::shared_ptr instead of local classes in win32_api.hpp, like this: boost::shared_ptr<void> hiPSAPI = boost::shared_ptr<void>(load_library("PSAPI.DLL"), free_library); attached is the complete patch willem

3 2