March 2005 - Boost - lists.boost.org

RE: [boost] Resigning from Boost.Profiler
by Brian Braatz 02 Mar '05

02 Mar '05

I have been talking to Christopher about this. He has been very helpful in my usage of this lib. I am currently integrating this lib and extending it to fit the purposes of a 1.7million line application. (so far have done initial integration). With Chris's resignation, I am picking up the torch with this library. I intend to continue development of the profiler (I need it for a production system) and also intend to eventually submit it to boost. I will continue working with it, and share changes on this list for peoples ideas and feedback. I will not attempt to formally submit it, until I have used it to great success for the problems I am working on in my production application. It additionally needs full support for other operating systems which will need to be taken into account. I do not have a web page at this point in time. I am looking at setting up a source forge project for continued development. Thanks Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Wednesday, March 02, 2005 9:19 AM > To: Boost mailing list > Subject: [boost] Resigning from Boost.Profiler > > I am going to have to stop development of Boost.Profiler. IMO there is > still > a huge gap between where it is and where it would have to go to be both > robust and simple enough to be appropriate for Boost. Honestly I don't see > it happening without a more robust and portable high_resolution_timer, > which > requires far more time and energy than I am willing to commit. > > Where is the best place to upload my current snapshot, so that others can > take over if they want? > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

serialization archive types: random_iarchive, pretty_oarchive
by troy d. straszheim 02 Mar '05

02 Mar '05

Hey all, Robert specifically -- I've got fascinated with all the uses for this serialize() method, and I'm kicking around ideas for a couple archive types. The use case is an "Event" that occurs in a neutrino detector. This event is very big, it contains containers of smart pointers to containers of maps of smart pointers to... you get the idea. 15k lines of just containers of data. First notion is a pretty_oarchive. Currently I have people implementing operator<<() which calls a member function virtual ToStream() (so reference-to-base works) for debugging/hacking purposes, and if everything has a serialize method anyway, it would be a big savings to forget the ToStream() stuff and say pretty_oarchive(cout) << my_class; where pretty_oarchive is something like xml_oarchive, but with the formatting somehow factored out and modified. I admit that other than the header and start/end tags I haven't looked at this too closely because I assumed it had been discussed, thought I'd check for showstoppers first. random_iarchive (written already): The other issue is that with such a large event, you'd want to be able to verify that it makes the round trip to/from the archive intact. Obviously boost::serialization has thorough test suites, but with people constantly tinkering around in these classes, I was hoping to get a test suite going that does exactly what we're doing. You'd like to be able to just Event written_e, read_e; binary_oarchive oa; binary_iarchive ia; random_iarchive ria; ria >> written_e; oa << written_e; // close, open as input ia >> read_e; assert(written_e == read_e); where random_iarchive sets fundamental types to random values, expands containers to some random length (random() % MAX_RANDOM_LENGTH), and creates a T when it sees shared_ptr<T>. I've written this already. Of course you have to write your operator==()'s so that they have value semantics, that is they compare what is on the ends of their component shared_ptrs, not whether these pointers point to the same object or not. The original idea was to set the serialize() method and the operator==() against one another for verification... but if people forget to modify both, there's no way to tell from the test suites, it seems. It kind of started as an experiment and now that it is written it looks like there's no way to keep users from shooting themselves in the foot like this. Another problem is that if a class contains vector<shared_ptr<Base> >, you'd like to be able to populate this with shared_ptr<Derived>, where Derived is randomly selected from the set of classes that inherit from Base. Since serialization requires these classes to be registered, it seemed to me there might be a way to do this. But maybe its all overkill. Anyhow, this random_iarchive exists (except for the Base/Derived thing, above), maybe it would make a good tutorial case for custom serialization archives, maybe people want to use it for something. I'd be more than glad to write up some tutorial material, I'm sure I'd get a lot out of it. As usual, thanks for your time and for a killer library... -t

2 4

mpl::begin<mpl::vector<...> > performance problem
by Arkadiy Vertleyb 02 Mar '05

02 Mar '05

Hi all, I am having a huge compile performance problem trying to use mpl::begin for an mpl::vector of a large size -- the complexity seems to be far from constant (or even linear) time. The following example demonstrates it (I am using GCC 3.3.3 or 3.4.2) ---------- #define BOOST_TYPEOF_LIMIT_SIZE 200 #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp" #include "boost/mpl/begin_end.hpp" #include "boost/mpl/aux_/config/ctps.hpp" #include "boost/preprocessor/iterate.hpp" #include "boost/preprocessor/if.hpp" #include "boost/preprocessor/repetition/enum.hpp" #include "boost/config.hpp" #if (BOOST_TYPEOF_LIMIT_SIZE > BOOST_MPL_LIMIT_VECTOR_SIZE) #warning started generating namespace boost { namespace mpl { #define BOOST_PP_ITERATION_PARAMS_1 (3,( \ BOOST_PP_INC(BOOST_MPL_LIMIT_VECTOR_SIZE), \ BOOST_TYPEOF_LIMIT_SIZE, \ "boost/mpl/vector/aux_/numbered.hpp")) #include BOOST_PP_ITERATE() } } #warning done generating #endif//BOOST_TYPEOF_LIMIT_SIZE > BOOST_MPL_LIMIT_VECTOR_SIZE #define MACRO(z, n, _)\ boost::mpl::size_t<n> #warning started getting begin typedef boost::mpl::begin<BOOST_PP_CAT(boost::mpl::vector, BOOST_TYPEOF_LIMIT_SIZE)< BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, MACRO, ~) > >::type it; #warning done getting begin main() {} --------------- Thanks in advance for any help. Regards, Arkadiy

3 7

What's up with regression tests?
by David Abrahams 02 Mar '05

02 Mar '05

I only see linux tests at http://boost.sourceforge.net/regression-logs/ What about Win32? Weren't there other platforms, also? -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 12

[mpl] documentation bug (Fibonacci sequence)
by Caleb Epstein 01 Mar '05

01 Mar '05

In the MPL reference manual, in the vector_c section, an example is given: typedef vector_c<int,1,2,3,5,7,12,19,31> fibonacci; These values are not correct. The numbers should be 1, 1, 2, 3, 5, 8, 13, 21, and 34 and the final number that gets push_back'd to make fibonacci2 should be 55. -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: Re: Re: Is there any way to get typeid() to return the derived class name?
by Chris Just 01 Mar '05

01 Mar '05

Jody Hagins wrote: >> I'm using MS Visual C++ 6.0. This is what I'm doing: >> When I look at the type_info object's name(), it always returns >> "CBase", even if it's actually a CDerived object. > > > You have ommitted the most important pieces in your code sample... > > > Compile and run the above on your compiler. If it fails, you have a > problem with your compiler. Otherwise, you probably have a problem with > your code. Note that you only get the most derived type, if the class > is polymorphic (i.e., has at least one virtual function). Thanks, that fixed it. I could have sworn I tried that before, but I guess not... :) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: Singleton is documented!
by Jason Hise 01 Mar '05

01 Mar '05

I just got a message from Michel Decima regarding an interesting problem. What happens when you have to use a library which maintains static or global variables that you don't have control over, and you need your singletons to have access to them? The answer is that you have to make sure that your singletons get destroyed before or as main ends, not after. To do so, you have one of three options: A) Use the dependency_lifetime and make sure not to keep any static or global pointers. B) Explicitly call destroy on each of your singletons before main exits. C) Explicitly destroy the secret singleton boost::singleton::detail::longevity_registry before main exits. I recommend option three, combined with some RAII. For example: struct CleanupSingletons ( ) { ~ CleanupSingletons ( ) { boost::singleton::detail::longevity_registry::pointer ( ).destroy ( ); } }; int main ( ) { CleanupSingletons cleanup; //... return 0; } I wonder if this functionality is useful enough that I should add a non-member function 'cleanup' directly in the singleton namespace which destroys the longevity_registry internally. Thoughts and opinions? -Jason

1 0

Re: MPL integral wrapper failure on gcc4
by Aleksey Gurtovoy 01 Mar '05

01 Mar '05

Jeff Garland writes: > I realize this is an experimental compiler, but I notice date-time > isn't building because of an MPL failure. Similar problem in the > MPL tests. I looked at the code, but I have no idea what the > problem could be, possibly something simple? Just looked into it, and it appears to be a GCC bug: they seem to disallow any cast notation in integral constant expressions, while section 5.19 [expr.const] para 1 explicitly allows type conversions to integral or enumeration types: [...] Floating literals (2.13.3) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration types can be used. [...] If you could verify that the following stripped down version of the code in question is rejected, I'd submit a corresponding bug report: template< int n > struct int_ {}; typedef int_< static_cast<int>(5) > n; -- Aleksey Gurtovoy MetaCommunications Engineering

3 4

Iostreams questions
by christopher diggins 01 Mar '05

01 Mar '05

Several questions, 1) There is the (apparently) undocumented pipe operator http://www.ootl.org/boost/iostreams/pipable.hpp.htm . What does it do exactly? It appears to push filters into a filtering_stream or filtering_streambuf, but I am unsure. 2) Can we use it to write arbitrarily long chains such as: source | input_filter | bidirectional_filter | output_filter | sink? 3) why the name bidirectional_filter when inputoutput_filter (or io_filter) would be apparently more consistent with stl naming convention? 4) what is the url for the latest version and what is the status? Thanks! Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

2 1

Re: [boost] RPC library
by Iain Hanson 01 Mar '05

01 Mar '05

Hi, On Tue, 2005-03-01 at 14:09 +0000, Jarl Lindrud wrote: > Hi all, > > I've searched this list a bit and found a few mentions of rpc's (Remote > Procedure Call), but nothing concrete. > > I've written a library for doing portable C++ RPC's, which can be downloaded at > > http://www.codeproject.com/threads/RMI_For_Cpp.asp > > Is there any interest in Boost for something like this, and if so in what > directions do you all think it should be developed? Nice idea. Unfortunately RPC's ( including Java RMI ) don't scale. Thats why CORBA and J2EE were created. Simple RPC mechanisms like this inevitably end up being extended piece by piece until you have reproduced most of the CORBA functionality. Therefore IMHO I don't think it is a good idea for boost. /ikh

2 1