- Boost - lists.boost.org

[probing interest]AssocVector (and other parts of Loki)
by Mikhail Glushenkov 08 Feb '05

08 Feb '05

>From my experience, the main parts of Loki that people are missing in Boost are: a) Singleton b) policy-based smart_ptr c) AssocVector d) Factories e) (rarely)Visitor Nobody uses multimethods apparently. Since there are people working on a, b, d and e, I would like to ask the following questions: 0) Are you interested in adding AssocVector to Boost? (there seems to be at least _some_ interest[1]) 1) Is there interest in additional interfaces(set, multiset, multimap) described in [1] or is std::map-like container enough? 2) What other parts of Loki you would like to see in Boost? [1]http://article.gmane.org/gmane.comp.lib.boost.devel/116873

5 8

Type mismatch warning in multi_array::subarray
by Mark Ruzon 08 Feb '05

08 Feb '05

In boost_1_32_0, I often get a type mismatch warning in the MSVC++ 7.1 compiler in the end function of multi_array::sub_array: iterator end() { return iterator(*this->index_bases()+*this->shape(),origin(), this->shape(),this->strides(),this->index_bases()); } index_bases() appears to return a signed quantity (index*), while shape() appears to return an unsigned quantity (size_type*). Their sum is unsigned, but iterator takes a signed type as its first argument. Does anyone see a problem with casting the result to type index until a fix is made? I don't like disabling warnings.

1 0

io state and multi-restore
by Gennadiy Rozental 08 Feb '05

08 Feb '05

Is there a way to use io state savers in single save/multiple restore mode? Gennadiy

3 9

Re: More on Serialization Link Issue
by Jared McIntyre 08 Feb '05

08 Feb '05

> If you do discover that this is indeed the problem, you would have two > choices: > > a) rebuild the libraries with wchar_t set to be the same as a 16 bit > integer. > b) alter your app to use wchar_t as an intrinsic type. > > Personally I would recomment the latter. VC 8.0 uses wchar_t as an > intrinsic type so you're going to be on the losing side of the tide of > history if you don't make the change. Your program will be more correct and > more portable as well. And you'll have less problems like this in the > future.. I am using VC7.1, and I ended up having to go with solution A. I agree with you that solution B is a much better solution, but I'm afraid I will have to deal with that another day -- when management is more malliable 8-) Thanks for the help and the excellent library, Jared

1 0

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