- Boost - lists.preview.boost.org

BGL bidirectional adjacancy_list problem
by Hugo Duncan 28 Oct '04

28 Oct '04

We just updated to a recent cvs version of boost, and an algorithm that was taking three minutes is now running for over an hour. I think there are two problems, but am not at all sure of the analysis: The proximate cause seems to be the correction of the remove_edge function for bidirectional adjacancy_list based graphs in around June. Trying to see how to speed things up, I have run into these problems i) remove_edge is now O(E), due to the edge properties being stored on the graph rather than on a vertex. ii) removing properties from the edges changes nothing, a container of no_property's is still maintained. As I am not too familiar with the adjacancy_list implementation, can anyone confirm this? Hugo

2 5

Why no conversion from weak_ptr<T> to bool?
by Jonathan Biggar 28 Oct '04

28 Oct '04

It seems straighforward, it would just return !expired(). Any reason why not? -- Jonathan Biggar jon(a)levanta.com

2 1

Re: Boost Digest, Vol 894, Issue 1
by Michael Stevens 28 Oct '04

28 Oct '04

Hi Bronek, On Thursday 28 October 2004 08:42, Bronek Kozicki <brok(a)rubikon.pl> wrote: > I know that question is little off-topic here, but I hope there is > someone who can answer it. Could you recommend some C++ library for > matrix calculation that supports matrix inversion? Blizt++ does not have > it, neither boost.ublas. Or I missed it. Ideas? Linear algebra libraries generally avoid such inverse functions. This is because there are many algorithms possible depending on the properties of the matrix. The procedure is generally in two steps: decompose (factorise) the matrix in to simpler factors solve the linear equations using the factors Generally the above is done with LAPACK Have a look at "Linear Algebra with uBLAS" http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Linear_Algeb… As mentioned there uBLAS also has an experimental "lu.hpp" which provide the LU factorisations (for square non-singular matrices) directly. These functions are experimental and without documentation so any feedback would be appreciated. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

[Q]: What is the recommended logging facility for boost: log4cpp or ??
by Francis ANDRE 28 Oct '04

28 Oct '04

Hi I am wondering what is the logging facility recommended by the boost community: We are using log4cpp and are quite satified for now of its functionnalities. But as usual, it is a separate package, not anymore maintained and out of the boost foundry... What 's your opinion on this subjet?? Cheers Francis -- A good friend will come bail you out of jail.......... but, a true friend....will be sitting next to you saying: "...that was fun."

15 43

[thread] doc formatting
by Vladimir Prus 28 Oct '04

28 Oct '04

There is a minor problem with Boost.Thread docs. On http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… the "Boost.Thread" header is in bold, while is different from names of all other libraries. On http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads.html "Boost.Thread" is also in bold. That is causes by the declaration of Boost.Thread entity in libs/doc/thead/entities.xml file. Is it possible to either change the definition of the entity of its usage? At least, the <title> should not be in bold. - Volodya

1 0

Boost libraries naming convention
by Tony Juricic 28 Oct '04

28 Oct '04

Just checking on my understanding of the motivation for current library names, prompted by some work on updating Visual Studio IDE projects. I assume that Boost version, build (i.e. debug or release) and CRT specific names like: libboost_serialization-vc71-mt-1_32.lib, libboost_serialization-vc71-mt-gd-1_32.lib and similar are intended for binary distribution of libraries, where end user is not even expected to use bjam, but simply link with the library that she needs. OTOH, the executables link with version, build and CRT-linkage independent library names like: libboost_serialization.lib. I assume that this is done simply for build convenience, since library is nothing else but a packaged set of object modules, whatever name you give to it. In fact, when I build boost with VC++ 7.1, using command: bjam -sTOOLS=vc-7_1<RETURN> (VC++ 7.1 environment variables are assumed set at this point) in my "...bin\boost\libs\test\build\libboost_test_exec_monitor.lib\vc-7_1\debug\th reading-multi" directory I see both libboost_test_exec_monitor-vc71-mt-gd-1_32.lib and libboost_test_exec_monitor.lib libraries, and, as I would expect, they are exactly identical. The *only* case where both libraries are *not* built is for "runtime-link-static\threading-multi" build, where I see only version-specific library, such as libboost_test_exec_monitor-vc71-mt-sgd-1_32.lib, for example. Am I missing some deep rationale behind the build logic and names given to the libraries, or? Tony

2 1

boost::signals - member-functions as slots
by Dirk Gregorius 27 Oct '04

27 Oct '04

Hi, I have a short question regarding the boost::signals library. Is it possible to connect a member function to a signal or must the passed slot be either static or be a function object? If yes what would be the syntax to pass the function and the associated object reference? -Dirk

3 2

Re: pqs - physical quantities library
by Patrick Kowalzick 27 Oct '04

27 Oct '04

Hi Andy, I just read your post in boost.devel list, and took a brief look on your angle page: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/angles.html I searched for the question: "Should angles be modulo? (IOW should 361 degrees ---> 1 degree etc.)" and was not really surprised to find it. I wanted to know how you treat this problem :). Here just my opinion: -we encountered here a problem with weights in calculations, meaning an angle was weighted via its a-priori error, which is an angle as well. Setting this angle to 360 degree was fatal. The programm crashed setting the error back to 0, what is not recommend in a division 1/error (hihi). It was fatal, but 361 degree would have been even worse, producing a result what is definitly not expected. -So we discussed if an angle bigger than 360 degree exists, and IMO - yes. Imagine you turn yourself 2 times, than you have a rotation of 720 degree and not 360 degree. I like more your idea with the modulo function, but keep in mind, that some applications use -180 to 180 degree and other 0 to 360 degree. And last, what is your opinion here: you might use clockwise-angles or counter-clockwise-angles. Is it necessary to distinguish these types? Thanks, regards, Patrick "Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote in message news:<clapov$vpe$1(a)sea.gmane.org>... > Hi, > > I have been continuing with my physical-quantities library over the last > year, > http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html > and I am now seeking feedback as to whether it is worth putting this forward > as a boost library proposal.... > > *Overview* > > The physical-quantity type-family provides methods for modeling > physical-quantities in C++ programs. The advantages and extra functionality > over inbuilt types used in the role include, compile time > dimensional-analysis checking, automatic conversion between units and an > increase in source code comprehensibility. The type family includes two > types, firstly a type where the units are fixed at compile-time referred to > in the text as a ct-quantity and secondly a type where the units can be > run-time modified, referred to in the text as an rt-quantity. > > The ct-quantity has many similar features to an inbuilt-type: > > - concrete type with simple,consistent semantics close to those of > inbuilt-types. > - aims for speed and code size performance close to that of in-built types. > - requires no special framework to use. > > *Application areas* > > The application areas are very wide, including scientific-engineering, CAD, > 3D games programming among many others. > > *Future directions* > > 2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics > interface (eg OpenGL), splines and curve analysis, successive approaximation > , piecewise differentiation and integration algorithms. finite element > analysis, etc etc. > > Issues from the previous thread on the library and physical quantities in > general > > http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782 > > issue: Angles. > > current status: Angles are implemented.There are two types, irrational (ie > radians) and > rational fractions of revolution ie degrees minutes etc). radians are what > you might call a 'weak type'. (Though this behaviour can be modified by a > macro switch). They will implicitly decay to (say) double and can be > implicitly cast to double. However they also allow implicit conversions to > and from degrees etc. hence an implicit conversion from degrees to radians > can occur if a function has a radians argument, but not a double argument. > They are also useful for output of units. > --------------------- > issue: Differentiating different but dimensionally equivalent types. > > current status: This is implemented. > --------------------- > issue: Implicit conversions between units. > > current status: Implicit conversions are intrinsic. They are practical > instinctive and > useful. > --------------------- > issue: You should be using mpl. > > current status: Hopefully I will be able to get hold of the metaprogramming > book soon, at > which point I can decide whether there are advantages. > --------------------- > > regards > Andy Little > > > > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

3 2

[mpl] need help with 'extended template parameter matching'
by Jonathan Turkanis 27 Oct '04

27 Oct '04

Dear All, I'm trying to write a metafunction rebind which, when fed a specialization T<P1,...,Pn> of an n-ary template T, returns T<mpl::_, ...., mpl::_>. This is straightforward if default template arguments are not considered when matching template template parameters. (See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#150.) E.g., template<typename T> struct rebind { typedef T type; } template<template<typename> class T, typename P> struct rebind< T<P> > { typedef T<mpl::_> type; }; template<template<typename, typename> class T, typename P1, typename P2> struct rebind< T<P1, P2> > { typedef T<mpl::_, mpl::_> type; }; etc. On GCC 3.4.1 (and I assume earlier versions too) this leads to ambiguity errors. To workaround this problem, I've resorted to using enable_if and mpl::aux::template_arity, e.g., template<typename T, typename Enabler = void> struct rebind { typedef T type; } template<template<typename> class T, typename P> struct rebind< T<P>, typename enable_if< mpl::equal_to< typename mpl::aux::template_arity< T<P> >::type, mpl::int_<1> > >::type > { typedef T<mpl::_> type; }; I have two questions: 1. is my analysis correct? 2. is there a better solution? Best Regards, Jonathan

2 2

regression report out of sync?
by Joaquín Mª López Muñoz 27 Oct '04

27 Oct '04

Seems like the developer report at http://www.meta-comm.com/engineering/boost-regression/developer/index.html is out of sync with the uploaded tests at ftp://fx.meta-comm.com/boost-regression/RC_1_32_0/ Although the developer report is being rebuilt every two hours or so, its contents are a couple of days older than the stuff at the FTP directory. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1