August 2009 - Boost - lists.preview.boost.org

boost 1.40.0 release date?
by Zoran Cvetkov 08 Aug '09

08 Aug '09

I would like to know when is scheduled release date for version 1.40 of boos library? Some critical fixes are in there and I'd like to know when we should expect it? Browsing the web site didn't help me, did I missed something? Thanks in advance!

2 1

[1.40] timeline?
by John Maddock 07 Aug '09

07 Aug '09

Do we have a revised timeline for 1.40 yet? I'm asking because the regex lib is ready for a substantial update (provided trunk tests cycle OK obviously!). Thanks, John.

6 13

[BGL] How to stopping prematurely a graph exploration
by Cosimo Calabrese 07 Aug '09

07 Aug '09

Hi to all, I'm searching for a good method to stopping prematurely a graph exploration, e.g. when I've just founded and explored a particular vertex. I think I've to create a visitor to which passing the particular vertex, but I don't know how to configure it. A very brutal method is to wrap the exploration function in a try-catch block, and then throw an exception in the examine_vertex funtion. I want to believe that there's a more elegant method than this... Best regards, Cosimo Calabrese.

4 6

[config] symbols export from shared library (#2114)
by Alexander Arhipenko 07 Aug '09

07 Aug '09

Guys, I've decided to start a new thread on this topic. The messages beyond was taken from the last ticket comments. >--------------------------------------------------------------------- >*** Changed 19 hours ago by johnmaddock *** >--------------------------------------------------------------------- > >Is this nearly ready to go in Trunk now? > >Before it does at the very least we need: > >1) An update for http://www.boost.org/development/separate_compilation.html >2) An update for the Boost.Config docs for each of these new macros. >3) A clear understanding of what BOOST_SYMBOL_FORWARD_EXPORT/IMPORT do. >4) A clear understanding of what needs re-exporting - >IMO BOOST_EXCEPTION_EXPORT is somewhat misleading since as I understand the gcc docs >this may need to be applied to any class that has "vague linkage" whatever that is. >Also do we need to re-export std lib exceptions from our SO's? >Do we have a dependency analysis to know when we need to use these (or that we don't need to)? > >John. > >----------------------------------------------------------------- >*** Changed 3 hours ago by arhipjan@… *** >----------------------------------------------------------------- > >Replying to johnmaddock: > >JFYI, stdcxx library (at least of version 4.1.1 and later) >already have default visibility for std::exception, std::bad_exception, i.e: > >//exception header > >#pragma GCC visibility push(default) > >namespace std { > > class exception {/*...*/}; > class bad_exception {/*...*/}; > >//... > >Also logic_error, runtime_error don't cause abnormal program termination >since they have key functions >(i.e. at least one non-inline virtual function). >--------------------------------------------------------------------- >*** Changed 26 minutes ago by anonymous *** >--------------------------------------------------------------------- > >I forgot one other requirement: we should maybe try and put together a small test case to check that this all works. > >Good to hear that libstdc++ already does the necessary work, does this mean that exceptions that inherit from std::runtime_error (as I think all Boost >exceptions do?) are automatically visable and don't need re-exporting on account of their virtual functions? > >Oops, one other thing (sorry!), how if at all is Boost.Exception effected by this - especially as it's header only? > >Cheers, John. I would like to make some comments: 1) BOOST_EXCEPTION_EXPORT macro In current patch version there is no need for this macro, since all the symbols marked with BOOST_SYMBOL_EXPORT always have default visibility on gcc. (In the original version, they have default visibility when building shared library and hidden visibility when using it in another shared library). 2) >>>>Also do we need to re-export std lib exceptions from our SO's? >>JFYI, stdcxx library (at least of version 4.1.1 and later) >>already have default visibility for std::exception, std::bad_exception >>[snip] >>Also logic_error, runtime_error don't cause abnormal program termination >>since they have key functions >>(i.e. at least one non-inline virtual function). >Good to hear that libstdc++ already does the necessary work, >does this mean that exceptions that inherit from std::runtime_error (as I think all Boost exceptions do?) >are automatically visable and don't need re-exporting on account of their virtual functions? The exceptions that inherit std::exception (or std::runtime_error) are not visible. But throwing such exception from shared library and catching it in another exe or lib doesn't cause abnormal termination (but only if thrown exception have at least one key function)

1 0

Re: [boost] Using channel with boost 1.39.0
by Yigong Liu 07 Aug '09

07 Aug '09

Hello Joaquim, Thanks for your help. I'll soon fix these issues with a new update to vault. Best Regards. Yigong > > However in some samples has appeared warnning about deprecated casts > to transfrom from std::string to char*. I attach to this e-mail the > output of compilation of samples to fix the warnings. > > Thanks and Best Regards, > Joaquim Duran > >

1 0

Boost.Plot? - Scalable Vector Graphics
by Paul A. Bristow 07 Aug '09

07 Aug '09

Jake Voytko started this library during a 2007 GSoC and I have now expanded it quite a bit, and begun to use it for my own purposes (including preparing the plot for the Boost.Math library functions and statistical distributions). Before I do any more work on it, I'd appreciate feedback from Boosters on how useful they think it might be, perhaps as a Boost library? Although it still has plenty of wrinklies (the calculation of positioning of titles, legends, axes labels and ticks labels is intricate - to say the least). And there are not-a-few nasty warts (this may be the 1st version to throw away?), so it is in no way review-ready. But I believe it is working well enough for you to try to use it - and to give me feedback. There are of course hundreds of programs for plotting. What is special about *this* library is that it is in C++ and it has a Boost license. It allows you to add just a few lines of code to the end of your C++ program to take data from any STL container (all or part) and produce a plot as a Scale Vector Graph (.svg) file. (No need to export data to a file and suck into Excel ;-) Applause!) .svg files can be displayed by all good Internet Browsers (and even by IE8 with an Adobe add-in). They are very small but high quality, highly zip compressible, and equally suitable for printing to viewing on mobiles (only the features of Tiny SVG are used.). It takes as little code as svg_2d_plot my_plot; my_plot .plot(map1, "Series 1").stroke_color(blue) .plot(map2, "Series 2").stroke_color(red") .autoscale(map1); my_plot.write("./2d_simple.svg"); but you can have hours of fun trying out hundreds of options to produce some rather fancy plots. For your amusement, attached are a few (mostly contrived) examples (with tasteless garish colors just to highlight the possible options). There are also lots and lots of other examples. (Note that the 20 plots occupy a mere 30 kb when zipped). Unusually, there is lots (too much? - 6Mbyte hyperlinked and indexed PDF!) of documentation, produced using the C++ in QuickBook with Doxygen reference info and John Maddock's auto-indexing. But there are hundreds of options, so you will need all the help you can get from tutorials, examples and indexes. A novel feature is the built-in handling of an 'uncertain' type (based on Evan Marshal Manning, C/C++ Users Journal, March 1996 page 29 to 38) including a double 'most likely' value, an 'uncertainty' estimate, roughly standard deviation, and an estimate of 'degrees of freedom'. This can be used to display confidence ellipses and label values "1.23 +-0.01 (21)", for example. (Of course, you can make much better confidence estimates using the Boost.Math library). You can view and can get code from the Boost sandbox https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization Docs are available to build as html and pre-built as pdf (patience - 6 Mbyte!) https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/libs/svg_plot /doc/pdf/svg_plot.pdf or http://tinyurl.com/coqlbg (or ask if you want zips instead). Paul PS Thanks to all those who have offered support, especially John Maddock of course. It has stress-tested the Quickbook - Doxygen indexing system ;-) I haven't managed to make the index work perfectly yet and I'm sure it can be improved. PPS If I were doing this again, I would not use 'derived' trick to permit re-use of functions by 1D, 2D and boxplots - it causes the Intellisense of MS VisualStudio IDE 'Intelligence Circuits' to melt (and sometimes crash - workaround - delete the .ncb file) making the nice 'goto definition' feature ineffective and makes debugging difficult (as does the use of set and get functions). I suspect it makes compile times longer too. There must be a better way - suggestions welcome. But I *would* use the chaining feature - I think it makes a very nice syntax for the user - but tell me what you think. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

14 36

[Boost.Thread][Boost1.39]:boost::thread& is not accessible from boost::move
by Karun Gahlawat 07 Aug '09

07 Aug '09

Running CC 5.10 to build Boost.Thread using the following command: Referred to this list by boost-build Trying to build Boost.Thread using Sun CC 5.10 on opensolaris. This one looks like a generic error. "CC" +d -library=stlport4 -g -mt -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "/tmp/boost/boost/bin.v2/libs/thread/build/sun/debug/a ddress-model-64/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" Getting this error: "./boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected. -- Karun -

2 2

[function_types] documentation issues
by Sam Partington 06 Aug '09

06 Aug '09

Hi all, I am writing a library that aims to make using dynamic libraries easier across platforms. The aim is the following : dynamic::library lib("sharedlib.so"); dynamic::function<int (int, int> fn(lib, "fn"); int result = fn(1, 2); So to achieve this I needed to implement forwarding functions and I used function_types to make this easier. This all worked fairly well, but in general I really struggled with figuring out how to use function_types. Though simple uses were fairly straight forward, as soon as I came across a STDCALL function it all fell over and I got compiler errors "'value' : is not a member of 'boost::function_types::function_arity<T>". I have managed to fix it, but the route there was far from obvious, and I would put that entirely down to incomplete and misleading documentation. Eventually, I found the Reference->Macros section which discussed calling conventions : BOOST_FT_CC_* Enables a specific calling convention. * dentoes the macro suffix, as defined by BOOST_FT_CC_NAMES or BOOST_FT_BUILTIN_CC_NAMES. The macro expands to a list of restrictions, separated by the | character. Possible items are: callable_builtin member non_member variadic non_variadic If no such macro is defined for a particular calling convention, it is disabled. Example: #define BOOST_FT_CC_STDCALL non_variadic|callable_builtin // enables stdcall calling convention for all non-variadic, // callable, builtin types Ahah! It looked like I needed to #define BOOST_FT_CC_STDCALL non_variadic|callable_builtin, as per the example there. However this caused monstrous compile errors from the guts of function_types initially stating that "'...' requires cdecl". Further reading pointed me to this : BOOST_FT_COMMON_X86_CCs Defining this macro causes the following macros to be defined, if not defined already: #define BOOST_FT_CC_CDECL BOOST_FT_COMMON_X86_CCs #define BOOST_FT_CC_STDCALL non_variadic|BOOST_FT_COMMON_X86_CCs #define BOOST_FT_CC_FASTCALL non_variadic|BOOST_FT_COMMON_X86_CCs So I added the following : #define BOOST_FT_COMMON_X86_CCs But this also failed with more bizarre errors, eventually I experimented with : #define BOOST_FT_COMMON_X86_CCs 1 Which finally worked. But the docs do not indicate that you need to define it with any particular value. The whole problem would have been so much simpler if there was one of more of the following sections in the documentation : "Getting Started", "Calling Conventions", "Common Pitfalls", or an FAQ. Sam

1 0

[program_options] Can this library write config file?
by Guanqiang Liu 06 Aug '09

06 Aug '09

the boost::program_options can read options from config file. But, can this library write opions into config file?

3 2

[BGL] To customize the graph traversing
by Cosimo Calabrese 06 Aug '09

06 Aug '09

Hi to all, I'm studying the BGL, and I've a question. I've noticed that: - the traversing algorithms, like breadth first search, only decide how to traverse the graph, but do not perform specific calculations; - if I want to perform any calculation during the traverse, I can do it passing a custom visitor to the algorithm. But the question is: how can I customize the traverse method? The algorithms always explore enterely the graph. EXAMPLE: every edge (u, v) of a graph have a property "edge_can_traverse_t" that says on which of adjacent edges starting from v I can continue the traverse. _C _F o| /| o / o / A---->B---->D o o o >G \ \ \ \ _\| _\| E H ----------------------------------------- | edge | property edge_can_traverse_t | | | (vector<edge>) | ----------------------------------------- | (A,B) | (B,D) , (B,E) | | (B,C) | empty | | (B,D) | (D,F) , (D,H) | | (B,E) | empty | | (D,F) | empty | | (D,G) | empty | | (D,H) | empty | ----------------------------------------- For example, if I come from the (A,B) edge, I want that the algorithm consider only the (B,D) and (B,E) edge, and skip the (B,C) edge. The solution I found is to modify the breadth_first_search algorithm, adding a predicate to the visitor and performing a control when the algorithm examines the outer edges of the current vertex. Something like this: //============================================================================== // PREDICATE (in the visitor) //============================================================================== template <class IncidenceGraph, class PredecessorMap> bool can_traverse_edge( edge_descriptor e, IncidenceGraph &g, PredecessorMap p ) { typedef graph_traits<IncidenceGraph>::vertex_descriptor VertexDescriptor; VertexDescriptor u = source( e, g ); // select the source of the edge EdgeDescriptor eFrom = edge( p(u), u ); // select the previous visited edge if ( e is contained in the edge_can_traverse_t property of eFrom ) return true; else return false; } //------------------------------------------------------------------------------ //============================================================================== // breadth_first_visit //============================================================================== template <class IncidenceGraph, class Buffer, class BFSVisitor, class ColorMap> void customized_breadth_first_visit (const IncidenceGraph& g, typename graph_traits<IncidenceGraph>::vertex_descriptor s, Buffer& Q, BFSVisitor vis, ColorMap color) { [.....] put(color, s, Color::gray()); vis.discover_vertex(s, g); Q.push(s); while (! Q.empty()) { Vertex u = Q.top(); Q.pop(); vis.examine_vertex(u, g); for (tie(ei, ei_end) = out_edges(u, g); ei != ei_end; ++ei) { if ( !vis.can_traverse_edge( *ei ) ) continue; [.....] } //------------------------------------------------------------------------------ Does it exist a better mechanism to control the traverse with the BGL? Or I must implement my solution? Best Regards, Cosimo Calabrese.

3 13