- Boost - lists.boost.org

Re: [boost] Re: Re: Re: Boost Profiler Proposal
by brangdon＠cix.compulink.co.uk 08 Feb '05

08 Feb '05

In-Reply-To: <001d01c50d76$7f669b20$d9958242@heronnest> cdiggins(a)videotron.ca (christopher diggins) wrote (abridged): > stop() and resume() are not part of the design. > > You would write the above code as: > > { > { > basic_profiler<collecting_policy> p("profile1"); > // some code > } > // some other code we do not want to profile > { > basic_profiler<collecting_policy> p("profile1"); > // continue profiling > } > collecting_policy::generate_report(); > } > } It seems to me the tail is wagging the dog here. The RAII class is no longer a helper but a hinderance that we have to work around. Your suggestion of adding block-scopes will not work if the first code declares variables that are used by the second block. For my own profiling I have a class which is effectively an array of timers, that can be stopped and started arbitrarily. RAII, when I need it, is a thin layer on top of that - but usually I don't need it. What I sometimes need instead is fairly sophisticated interactions between timers, eg starting one timer implicitly pausing the previous one. -- Dave Harris, Nottingham, UK

1 0

[boost] inspect tool updated, violations of min/max guidelines found
by Eric Niebler 08 Feb '05

08 Feb '05

I just updated the Inspect tool to find violations of Boost's min/max guidelines (which you can find at http://boost.org/more/lib_guide.htm#Guidelines) I just ran the tool with the new -minmax switch to find all the violations in CVS-current. I've attached the report. Some of these are false positives -- violations in comments -- but most look legit. Below is the summary: Library Problems -----------------+---------- algorithm 2 archive 2 config 2 conversion 2 date_time 4 detail 1 graph 20 iostreams 16 multi_index 2 numeric 24 program_options 4 regex 14 serialization 1 spirit 6 -- Eric Niebler Boost Consulting www.boost-consulting.com /G53G29: Permission denied

1 1

subgraph test and BOOST_CHECK
by Stefan Slapeta 08 Feb '05

08 Feb '05

Hi all, there are a few cases where I didn't touch the code when replacing BOOST_TEST. One of them is the subgraph test, as there occurs a slightly different problem: It seems to me that this code worked so far: // ...cpp file #include <boost/test/minimal.hpp> // ...some header file #include <boost/test/test_tools.hpp> BOOST_TEST(...); For the code above, the initial declarations of test/minimal.hpp have been used. When you do the same now (after replacing BOOST_TEST), the compiler complains about macro redefinition _and_ you get unresolved externals at linking time. C:\views_cvs\boost\boost\test\test_tools.hpp(81) : warning C4005: 'BOOST_CHECK' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(21) : see previous definition of 'BOOST_CHECK' C:\views_cvs\boost\boost\test\test_tools.hpp(82) : warning C4005: 'BOOST_REQUIRE' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(26) : see previous definition of 'BOOST_REQUIRE' C:\views_cvs\boost\boost\test\test_tools.hpp(92) : warning C4005: 'BOOST_ERROR' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(29) : see previous definition of 'BOOST_ERROR' C:\views_cvs\boost\boost\test\test_tools.hpp(93) : warning C4005: 'BOOST_FAIL' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(31) : see previous definition of 'BOOST_FAIL' Is it intended that these macros are defined differently for the minimal testing facility? If yes, another testing strategy has to be chosen for this case. Nevertheless, I've replaced the occurances of BOOST_TEST now. Stefan

3 5

RE: [boost] A library: out-of-core containers and algorithms
by Brian Braatz 08 Feb '05

08 Feb '05

> -----Original Message----- > On Behalf Of Roman Dementiev > Subject: [boost] A library: out-of-core containers and algorithms > > Hello, > > I am developing a library called Stxxl. > It is an implementation of STL for external memory (out-of-core) > computations, i.e. Stxxl implements > containers and algorithms that can process huge volumes of data that > only fit on disks. > > Currently I have implemented vector, stack, and priority_queue. External > memory map, list, and queue are coming soon. The containers > take only specified (given) fixed amount of main memory, but can contain > more elements than can fit into the main memory. > The containers are compatible with STL algorithms, an example: > > #include <stxxl> > > // ten billion doubles > stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); > std::fill(HugeVector.begin(), HugeVector.end(), 0.0); > [Brian Braatz] Roman- Thank you for submitting this. I am interested in this library and encourage you onward in bringing this to boost. Question: In a nutshell, if you could please describe * How it works * what the implications\dark corners are Are you using memory map files? What other libraries or os specific functions does your library need. Thank You Brian Braatz

3 2

BOOST_CHECK_EQUAL_COLLECTIONS changed?
by John Maddock 08 Feb '05

08 Feb '05

Has BOOST_CHECK_EQUAL_COLLECTIONS been changed to take 4 parameters? I would actually support this change if it makes the macro more robust (it should IMO), but there's been no mention of this on the list as a breaking change, and the Boost.Test docs still refer to the 3 argument version, so at the moment it's not clear what those of us whose test-code has been broken should do about this :-( John.

2 1

Metadata for boost boost.signal and profiling library :was [RE: [boost] Re: Profiling Library suggestion
by Brian Braatz 08 Feb '05

08 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > > How is it better than what boost::timer provide? > > > > Gennadiy > > Hello, > > I was unaware of timer's existance, thanks for pointing it out. I had > searched for "profiling", and "profiler". > > So I just took a look at: http://www.boost.org/libs/timer/timer.htm and I > would humbly submit that perhaps what is lacking in progress_timer is a > policy, and the ability to name profiles. I would like then to propose: > > struct profiler_default_policy { > typedef boost::timer timer_t; > static void on_profiled(const char* name, const timer_t& t) { > double sec = t.elapsed(); > cout << "time elapsed (msec) during profile " << name << " was " << > sec / 1000; > if (sec <= t.elapsed_min()) { > cout << " *underflow* "; > } > if (sec >= t.elapsed_max()) > cout << " *overflow* "; > } > cout << endl; > } > }; > > struct interesting_profiler_policy { > typedef boost::timer timer_t; > static map<string, double> profiles; > static void on_profiled(const char* name, const timer_t& t) { > double sec = t.elapsed(); > profiles[name] = sec; > } > }; > > template<typename policy_t> > class basic_profiler { > public: > profiler(char const* s = "") : name(s) { }; > ~profiler() { policy_t::on_profiled(name, timer); }; > private: > char const* name; > typename policy_t::timer_t timer; > }; > > typedef basic_profiler<default_profiler_policy> profiler; > > This would have an advantage over progress_timer that library users may > modify the behaviour of the profiler, without rewriting the class. It can > also be used with more high-performance timers if the user has one at > their > disposal. > > Any comments or suggestions? > > Christopher Diggins [Brian Braatz] Christopher, I like this idea and thank you for writing that up. I haven't had the time to write it up, but I was going to make a similar request of boost.signals. The main reason for this, I built something on top of boost.signal and it uses a lot of signals\slots, it can be difficult to runtime debug due to not having the ability to query the signal for dumping all that meta-data out. (i.e. give me the debug strings for each slot)- what I do instead is keep a separate vector of those debug strings. This seems to be a similar issue to the profiling metadata suggestion that you have written up. My question to this list: * What do you guys think of Christopher's Suggestion in general for supporting extra metadata for profiling? Boost.Signal? With some libraries some it is easily possible (hahaha boost.variant) for me, I have not figured out how to cleanly do it to a slot yet :) (though honestly I have not had the time to further analyze how that lib works internally) (<< disclaimer in case I missed something dirt simple) Converse argument would be: Put your profiler in a named collection. That might work for profiler (sorry I am not familiar with that lib to know if it supports copy or what the implications of copying one are). For signal- In a few hours of analysis I don't see how to do it yet.

2 1

[graph] Adjacency bug after swapping undirected adjacency_list
by Eelis van der Weegen 08 Feb '05

08 Feb '05

I've stumbled upon a strange bug in the graph library. It seems that swapping an undirected adjacency_list back and forth to a copy of itself somehow causes some internal damage that becomes apparent when observing adjacenct vertices. I've attached a testcase that shows the problem. I'm using Boost 1.32 with gcc 3.4.2. Regards, Eelis #include <algorithm> #include <iterator> #include <iostream> #include <boost/graph/adjacency_list.hpp> int main () { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> G; G g (3); add_edge(0, 1, g); add_edge(0, 2, g); G::adjacency_iterator i, j; boost::tie(i, j) = adjacent_vertices(0, g); std::copy(i, j, std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl; // Prints "1 2", as it should. { // This should not alter g: G t = g; g.swap(t); g.swap(t); } boost::tie(i, j) = adjacent_vertices(0, g); std::copy(i, j, std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl; // Prints "1 2 1 2", while it should still be "1 2". }

2 2

possible bgl problem?
by Maxim Khesin 08 Feb '05

08 Feb '05

I am trying to read a seemingly simple dot file (produced by pygraphlib) with read_graphviz and I am getting 'syntax error' exception. The file looks like this (copy attached). digraph G { "there" []; "here" []; "here" -> "there" []; } boost_1_32_0, OS X Panther Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) thanks, max.

2 1

[iterator + program_options] borland problem
by Vladimir Prus 08 Feb '05

08 Feb '05

Hello, one of program_options' iterators no longer work on borland 5.6.4. The iterator is defined like: class environment_iterator : public eof_iterator<environment_iterator, std::pair<std::string, std::string> > Where eof_iterator is define like this: template<class Derived, class ValueType> class eof_iterator : public iterator_facade<Derived, const ValueType, forward_traversal_tag> So, the ValueType passed to iterator_facade is const std::pair<string, string>. The error produced by Borland is: Error E2034 C:\Users\Administrator\boost\main\boost\boost/iterator/iterator_facade.hpp 326: Cannot convert 'const pair<string,string> *' to 'pair<string,string> *' in function operator_arrow_result<pair<string,string>,const pair<string,string> &,pair<string,string> *>::make(const pair<string,string> &) Error E2342 C:\Users\Administrator\boost\main\boost\boost/iterator/iterator_facade.hpp 326: Type mismatch in parameter 'x' (wanted 'pair<string,string> *', got 'const pair<string,string> *') in function operator_arrow_result<pair<string,string>,const pair<string,string> &,pair<string,string> *>::make(const pair<string,string> &) It happens when instantiating this class. template <class ValueType, class Reference, class Pointer> struct operator_arrow_result { On borland, non-const type is passed as Pointer, which leads to the problem. Looks like the logic which computes the ::reference type confuses borland. On gcc, const type is passed as Pointer. The attached patch fixes the problem, by replacing add_const<value_type>::type with const value_type I haven't used #ifdef, because I think that the change should work on other compilers, too. At least it does not break any iterator tests with gcc. Comments? - Volodya

1 0

Boost 1.32 patches for IBM z/Series S390 Linux
by Jonathan Biggar 08 Feb '05

08 Feb '05

Attached are a couple of patches needed to compile boost 1.32 on S390 running Linux. Can someone apply these to the boost source? -- Jon Biggar Levanta jon(a)levanta.com --- boost/detail/limits.hpp Thu Feb 26 10:26:47 2004 +++ boost/detail/limits.hpp.new Sat Jan 29 13:56:49 2005 @@ -49,7 +49,7 @@ // The macros are not named appropriately. We don't care about integer // bit layout, but about floating-point NaN (etc.) bit patterns. -#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) +#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__s390__) #define BOOST_BIG_ENDIAN #elif defined(__i386__) || defined(__alpha__) || defined(__ia64) || defined(__ia64__) #define BOOST_LITTLE_ENDIAN --- tools/build/v1/gcc-tools.jam Fri Jan 28 21:00:04 2005 +++ tools/build/v1/gcc-tools.jam.new Fri Jan 28 20:55:18 2005 @@ -297,6 +297,11 @@ flags gcc CFLAGS <address-model>32 : -mgp32 ; flags gcc CFLAGS <address-model>64 : -mgp64 -mlong64 ; } +#S390 +if $(OSPLAT) = 390 +{ + flags gcc CFLAGS <threading>multi : -D_REENTRANT ; +} # # define compiler names if not set:

6 15