- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1155439 ] Correction to configuration for Sun C++
by SourceForge.net 02 Mar '05

02 Mar '05

Bugs item #1155439, was opened at 2005-03-02 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1155439&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Correction to configuration for Sun C++ Initial Comment: The BOOST configuration files have settings for early Sun compilers that are not correct for the current compilers. (The early compilers can't compile fair-sized chunks of BOOST in any case.) We intend full support of BOOST in Sun Studio 10 (C++ 5.7) and later. I've attached diffs for the config files. There's a possible hole in these updates, however. The BOOST configuration files currently claim nothing since C++ 5.3 was tested. I am making no claims about C++ 5.4 through 5.6, but only for 5.7 and later. Steve Clamage, stephen.clamage(a)sun.com Sun C++ Project Lead ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1155439&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Iostreams Compile Issue with boost/algorithm/string.hpp was [RE: Compile problem using IoStreams from CVS inside boost v1.32 (VC71)]
by Brian Braatz 02 Mar '05

02 Mar '05

I narrowed this down a bit more- In my code which uses filtered_stream if I have the following headers: #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/operations.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/device/file.hpp> // #include <boost/algorithm/string.hpp> It compiles- but when I uncomment the #include <boost/algorithm/string.hpp> I get the error below > -----Original Message----- > From: Brian Braatz > Sent: Wednesday, March 02, 2005 1:34 PM > To: 'boost(a)lists.boost.org' > Subject: Compile problem using IoStreams from CVS inside boost v1.32 > (VC71) > > I am using VC7.1 (and will also be using VC70 for this code) > > What I did- > > Executed the following from a cmd prompt: > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout > boost > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout > > went into boost\iostreams and boost\libs\iostreams- copied both into temp > area- > > Deleted the CVS folders > > Copied the files into the boost 1.32 dir in my company's internal CVS > server (we have the boost files under revision control to control which > version of which file we are using to build) > > Initially I had to change the files to from namespace io to iostreams. Got > through those compile errors. And Now I have this one: > > > boost\algorithm\string\iterator_range.hpp(288) : error C2874: using- > declaration causes a multiple declaration of > 'boost::algorithm::iterator_range' > > \boost\algorithm\string\iterator_range.hpp(204) : see declaration of > 'boost::algorithm::iterator_range' > > I am digging into this but thought I would throw this out to see if any > one is aware of the issue- > > These errors point to the end of iterator_range.hpp (pointing at the using > clause) > > Here is a snippet from that file: > > template< typename SeqT, typename IteratorT, typename FuncT > > inline SeqT transform_iterator_range( const > iterator_range<IteratorT>& Range, FuncT Func ) > { > SeqT Seq; > std::transform( Range.begin(), Range.end(), > std::back_inserter(Seq), Func ); > return Seq; > } > > } // namespace algorithm > > // pull names to the namespace boost > using algorithm::iterator_range; > using algorithm::make_iterator_range; > using algorithm::copy_iterator_range; > using algorithm::transform_iterator_range; > > } // namespace boost > > > > > >

1 0

Compile problem using IoStreams from CVS inside boost v1.32 (VC71)
by Brian Braatz 02 Mar '05

02 Mar '05

I am using VC7.1 (and will also be using VC70 for this code) What I did- Executed the following from a cmd prompt: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout went into boost\iostreams and boost\libs\iostreams- copied both into temp area- Deleted the CVS folders Copied the files into the boost 1.32 dir in my company's internal CVS server (we have the boost files under revision control to control which version of which file we are using to build) Initially I had to change the files to from namespace io to iostreams. Got through those compile errors. And Now I have this one: boost\algorithm\string\iterator_range.hpp(288) : error C2874: using-declaration causes a multiple declaration of 'boost::algorithm::iterator_range' \boost\algorithm\string\iterator_range.hpp(204) : see declaration of 'boost::algorithm::iterator_range' I am digging into this but thought I would throw this out to see if any one is aware of the issue- These errors point to the end of iterator_range.hpp (pointing at the using clause) Here is a snippet from that file: template< typename SeqT, typename IteratorT, typename FuncT > inline SeqT transform_iterator_range( const iterator_range<IteratorT>& Range, FuncT Func ) { SeqT Seq; std::transform( Range.begin(), Range.end(), std::back_inserter(Seq), Func ); return Seq; } } // namespace algorithm // pull names to the namespace boost using algorithm::iterator_range; using algorithm::make_iterator_range; using algorithm::copy_iterator_range; using algorithm::transform_iterator_range; } // namespace boost

2 1

Resigning from Boost.Profiler
by christopher diggins 02 Mar '05

02 Mar '05

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

2 2

RE: [boost] Re: RPC library
by Brian Braatz 02 Mar '05

02 Mar '05

> > "Jarl Lindrud" wrote: > > > > > 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 [Brian Braatz Writes:] Suggestion: take a look at the BIL library- it looks like a merging of concepts might be a good idea. http://tinyurl.com/4s84a

2 1

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 02 Mar '05

02 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