- Boost - lists.boost.org

[Graph] LEDA adapter - concept check VertexListGraph fails
by Jens Müller 01 Jan '12

01 Jan '12

Hi everyone, when running the tests for Graph, the first concept check in leda_graph_cc.cpp fails: gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:9:0: ../../../boost/graph/graph_concepts.hpp: In destructor 'boost::concepts::VertexListGraph<G>::~VertexListGraph() [with G = leda::GRAPH<int, int>]': ../../../boost/graph/graph_concepts.hpp:168:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::VertexListGraphConcept<leda::GRAPH<int, int> >]' leda_graph_cc.cpp:21:5: instantiated from here ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' ../../../boost/graph/graph_concepts.hpp:189:9: note: candidate is: ../../../boost/graph/graph_concepts.hpp:45:48: note: template<class T> typename T::ThereReallyIsNoMemberByThisNameInT boost::vertices(const T&) (among some further errors, but I'd like to ask just about this one now) Apparently it cannot find a vertices() function: ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' But there is one in leda_graph.hpp: template <class vtype, class etype> inline std::pair< typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator, typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator > vertices(const leda::GRAPH<vtype,etype>& g) { typedef typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator Iter; return std::make_pair( Iter(g.first_node(),&g), Iter(0,&g) ); } So, can someone enlighten me why it isn't found? Has it something to do with #ifdef BOOST_VECTOR_AS_GRAPH_GRAPH_ADL_HACK // dwa 2003/7/11 -- This clearly shouldn't be necessary, but if // you want to use vector_as_graph, it is! I'm sure the graph // library leaves these out all over the place. Probably a // redesign involving specializing a template with a static // member function is in order :( using boost::vertices; #endif ? Best regards, Jens

2 8

Many Boost.Test unit tests fail
by Barend Gehrels 01 Jan '12

01 Jan '12

Hi, Since today or yesterday, many regression tests fail. http://www.boost.org/development/tests/trunk/developer/summary.html I believe on platforms that are recently added, at last on platforms that were not present at December 17. 1) on clang/darwin, message ../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' 2) on clang/linux, message /usr/bin/ld: skipping incompatible /sierra/Sntools/extras/compilers/gcc-4.4.4/lib/libstdc++.so when searching for -lstdc++ We have these errors in Boost.Geometry but I also noticed them in many other libraries. Regards, Barend

2 2

[filesystem] path thread safety fix impact on POSIX systems
by Beman Dawes 01 Jan '12

01 Jan '12

Class path locale initialization has suffered from a data race for several releases. See https://svn.boost.org/trac/boost/ticket/6320 for an example of code that suffers as a result. The problem was introduced when locale initialization was changed from namespace scope initialization to function scope initialization. For Windows and Mac OS X, the fix is simply to change back to namespace scope initialization. For non-BSD based POSIX systems such as Linux, the problem is more complex. These system need std::locale(""), "the locale-specific native environment". Considerations: * std::locale("") will throw if environmental variables are configured incorrectly. For example, setting LANG=foo on my Ubuntu system causes std::locale("") to throw. * std::locale("") is only needed if conversions between wide and narrow character paths occur in the program, so it would be unfortunate to have programs throw that don't actually do any such conversion. * With GCC, std::locale("") at namespace scope will throw before main() has started! That prevents catching the exception in the user code, and was what led to moving the initialization to a function scope static. Initialization as a function scope static also meant that the exception only occurred if user code actually performed wide - narrow conversions. I can see two possible fixes: (A) Use function scope locale initialization, using boost/detail/lightweight_mutex.hpp to prevent data races. (B) Use namespace scope locale initialization, defaulting the codecvt facet to UTF-8 if std::locale("") throws. The advantage of (B) is that path always initializes without throwing, and that's what users seem to expect. The initialization is correct for all those whose environments are configured correctly, and for those uses who want UTF-8 even if their environments are misconfigured. The POSIX users who prefer an exception on a misconfigured environment can always add a std::locale("") at the start of main(). Comments or opinions? --Beman

4 6

Re: [boost] matrix and vector iterators
by Larry Evans 31 Dec '11

31 Dec '11

On 06/12/01 14:50, David Abrahams wrote: > > ----- Original Message ----- > From: "Larry Evans" <jcampbell3(a)prodigy.net> > > >> David Abrahams wrote: >> >>> One problem with this is that it requires much more of the iterator in > some >>> cases than it otherwise might. In an array stored as vectors of vectors >>> of... vectors, each iterator would need to have references to all of the >>> containing vectors. >> >> Couldn't the iterator just contain a vector of indices of length == rank, >> and a pointer to the vector of vectors of... vectors (VofV), and then just > index into >> the VofV with the vector of indices. > > When you start talking about iterators containing vectors, I get worried. > >> I guess bad thing about that is that it takes longer. > > That's putting it mildly. Iterators should be lightweight. > > -Dave > > Another type of iterator which essentially flattens a multi-dimensional array and *may* be more lightweight is implemented here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/b… and demonstrated here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… A more realistic demonstration is in the Partial Differential Equation example here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which uses an axes rotation feature that, IIUC, was requested by Petros here: http://article.gmane.org/gmane.comp.lib.boost.user/68017 Its also used here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which is probably a bit easier to follow than the array_dyn.diff_pde.cpp one ;) I've done no benchmarks; hence, I can't say how lightweight it is; however, since all it does is keep a stack of indices in a data structure instead of on the stack, I would think it wouldn't be that much more heavyweight than simply a nested for loop nested N deep where N is the array dimensionality. BTW, Petros, in a private email to me, has indicated he has some other method for solving the rotated axes problem; however, I've no idea if that's more or less lightweight than this one. -regards, Larry I've run no benchmarks to show how lightweight it may be. Petros, in a private email to me, says he has another way of

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 31 Dec '11

31 Dec '11

Dave Abrahams: > > No post-hock marshalling? You should be able to add marshalling to a > class without modifying its declaration. > If a class is popular enough, I often do. For example, the C++ Middleware Writer (CMW) has support for the standard containers, std::complex, multi_index_container, stable_vector and others. [...] > > No argument; I'm just sayin'. I don't have to go to any great lengths to find tests where the performance of executables that use Boost Serialization lags behind CMW based executables. I just think up a test and write it. The tests are quite basic. > > That's a fundamentally intrusive design; being able to add serialization > non-intrusively was a major design goal for Boost.Serialization. I see. One thing I didn't mention yesterday is support for stream- based constructors: class Base { template <typename R> explicit Base (ReceiveBufferFile<R>& buf); ... }; Does the Boost Serialization library have support for that? Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Pool lost singleton_default -- replacement?
by Steve M. Robbins 31 Dec '11

31 Dec '11

Hi, Prior to 1.48, Boost.Pool's singleton_pool class used a helper class singleton_default. This was hidden in a detail header <boost/pool/detail/singleton.hpp>, yet I found 3 programs in the Debian distribution that used it directly to instantiate their own singletons. I didn't find any direct replacement for singleton.hpp in Boost 1.48. Is there any plan to introduce this later? Thanks, -Steve

3 2

Boost 1_41 Binary archive exceptions
by KARAN 31 Dec '11

31 Dec '11

I am porting from Linux 32 bit to 64 Bit(x86_64)(Boost Version :1_41). I am facing an Binary archive exceptions mainly (std::bad_alloc,St12length_error-basic_string::resize). There are no exception during the file saving, but when I do a restore I am facing the above exceptions. The same works very well if I change it to text archives. How can I make it work with binary files? The exception is happening in the below code block .Any comments please template<class Archive> void Serialise (Archive & aArchive, const unsigned int aVersion=0) { aArchive & this->A; aArchive & this->B; aArchive & this->C this->p.Serialise(aArchive, aVersion); } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-41-Binary-archive-exceptions-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[interprocess] Timed locks
by Edward Diener 29 Dec '11

29 Dec '11

In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ? I think an end-user calculation is usually one in which he says that a certain lock needs to be acquired in so many seconds ( or milliseconds ) and a boost::posix_time::time_duration would fit that calculation better.

4 5

[MPL] "Unwrap" metafunction
by Robert Kawulak 29 Dec '11

29 Dec '11

Hi, I need a metafunction to check if a type is wrapped as an argument of a template and "unwrap" it if so. Something like: template <template <typename> class T, typename C> struct unwrap { typedef C type; static const bool is_wrapped = false; }; template <template <typename> class T, typename C> struct unwrap<T, T<C>> { typedef C type; static const bool is_wrapped = true; }; So both unwrap<x, int>::type and unwrap<x, x<int>>::type are int, while unwrap<x, y<int>>::type is y<int>. Of course I can use the code above, but I'm just curious - does Boost.MPL already provide a utility that can be used to achieve the same? Thanks and best regards, Robert

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

Robert Ramey: > This first came up several years ago and I spent a little time looking at > it. > I was sort of intrigued in that the usage of TMP driven inline code should > be optimal for cases where tracking wasn't involved. And in these test > cases there isn't any tracking. So I looked a little at the tests on the > page. > > a) first I couldn't compile them so I couldn't repeat the results. > Something > was missing (I forget what now). I believe you are referring to something from several years ago here. > b) so I inspected the code. My conclusion was that the being used was > that in the i/o itself rather than the serialization. Boost serialization > relies > on streambuf to do it's i/o and the time is sensitive to things like buffer > sizes > etc. It seems that brian's code uses some other method which whose > source isn't visible to me. (SendBuffer, etc). This sounds like the present. Did you download and build the archive here -- http://webEbenezer.net/build_integration.html ? (Also in an earlier note today I mentioned recent changes to the test archive here -- http://webEbenezer.net/comp/tests.tar.bz2 .) > c) Brian did point out some cases where boost serialize could be improved > particularly using hints in std collections. These were incorporated. I > also > implemented the binary i/o in terms of streambuf rather than stream which > was a noticible improvement. Yes, now it would probably not be difficult to add support for ::std::move. I'm asking for someone to open a ticket for that so someone doesn't ask me to. ;) [...] > e) So, given tat the timings aren't that far apart, and lacking any other > information, I'm inclined to attribute any discrepencies to the way i/o is > handled > in the different systems. If one had nothing else to do he could make > a replacement for streambuf which focused on fast i/o perhaps at the > expense of portability. In particular, an asyncronous memory mapped i/o > library might be an interesting addition to boost. And that would be cool > to plug in the serialization library. While true that the timings aren't real far apart, I note that the timings of the (slightly) more complicated tests are worse for the Boost Serialization library than the simpler tests. Real uses have more than a vector<deque<double> > of complication. So there may be a compounding effect, but I'm just speculating. > Finally, I think that the scale and breadth of brian's library is much, much > smaller than boost serialization library. The breadth is smaller. I don't support text or XML based serialization. > Then there is the fact that the > distribution model is totally different than that of boost and open source > libraries in general. I just don't see how these packages/approaches > could be considered comparable in any way. While the distribution models are different, I think the binary part of the Boost Serialization library is comparable to the Ebenezer approach. Thanks for mentioning the distribution model. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0