- Boost - lists.boost.org

Broken bug reports :-(
by Marshall Clow 01 Jul '08

01 Jul '08

The reporting mechanism in Trac has changed from 0.10 to 0.11; breaking my scripts that generate (most of) the bug reports I send out in the mornings. It will be a few days until I figure out how to fix them. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Re: [boost] [exception] - bug in tutorial -> member 'what' is ambiguous?
by Kowalke Oliver (QD IT PA AS) 30 Jun '08

30 Jun '08

Hi, I revering to http://svn.boost.org/svn/boost/trunk/libs/exception/doc/tutorial_transporti… First example: class my_error: public boost::exception<http://svn.boost.org/svn/boost/trunk/libs/exception/doc/exception.html>, public std::exception { }; //(2) This code line produces the error. Oliver On 6/18/08, Kowalke Oliver (QD IT PA AS) <Oliver.Kowalke <at> qimonda.com> wrote: > Yes I used the latest documentation from trunk: > Tutorial: Transporting of Abritrary Data to the Catch Site: > > class my_error : public boost::exception , std::exception {); > > Does not work with gcc-4.2.4 (compiler bug?). What exactly doesn't work on gcc-4.2.4? All of the examples from the documentation are in this folder: http://svn.boost.org/svn/boost/trunk/libs/exception/example/ The examples compile with msvc and gcc 4.3.1. I also looked at http://svn.boost.org/svn/boost/trunk/libs/exception/doc/transporting_data.h… I don't see a reference to what() in it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode > On Tue, Jun 17, 2008 at 12:09 AM, Kowalke Oliver (QD IT PA AS) <Oliver.Kowalke <at> qimonda.com> wrote: > > Hi, > > I'm using boost.exception from trunk and I get following error (gcc-4.2.4): > > > > error: request for member 'what' is ambiguous > > /usr/include/c++/4.2/exception:64: error: candidates are: virtual > > const char* std::exception::what() const > > /opt/boost/include/boost-1_35/boost/exception/exception.hpp:52: error: > > virtual const char* boost::exception::what() const > > > > I'm using the code from the boost.exception tutorial: > > > > class error > > : > > public boost::exception, > > public std::exception > > {} > > > > ... > > try > > {...} > > catch ( error const& e) > > { std::cout << "error: " << e.what() << std::endl; } > > Where do you read the tutorial you are mentioning? Is it possible that it is out of date? The latest documentation can be accessed directly through the subversion web interface: > > http://svn.boost.org/svn/boost/trunk/libs/exception/doc/boost-exception.html. > > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 3

[spirit] Deprecation warnings, can they be turned off?
by Rene Rivera 30 Jun '08

30 Jun '08

In doing a top-level build of Boost (trunk) I'm seeing many messages like this one: ./boost/spirit/core/composite/actions.hpp:15:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_actions.hpp" In file included from libs/serialization/src/basic_xml_grammar.ipp:22, from libs/serialization/src/xml_wgrammar.cpp:243: Two questions: * Is this something to worry about that the Serialization lib, and perhaps others, are using the deprecated headers? * Assuming Serialization, other libraries, and users want to use the old headers. Is there a way for them to turn off the warning? I don't see anything obvious from looking at the headers themselves. In a world where compiling Boost produces many warnings already in some platforms. It seems bad if we are adding even more onto the fray. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 5

Need help with Boost:Serialization!
by Daniel Kunz 30 Jun '08

30 Jun '08

Hi, I'm very new at Boost and want to develop a project for school with the Boost:Serialization package. I've already read the documantation and serveral other sources. I'm not very good in programming C++, so please excuse that my code looks not perfect. I hope it's ok that I've posted some sourcecode. I've tried to keep it short... *My problem:* I have to create a program to serialise and deserialse a xml-file to a binary-stream. I think to binary stream is already done but the xml-serialisation is not ready and I don't know whats wrong. I have 3 classes: Goal ------------ class Goal { private: enum Scored{home=0, visitors=1}; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & name; ar & minute; ar & shootout; ar & scored; ar & penality; } string name; int minute; bool shootout; Scored scored; bool penality; public: Goal(){}; Goal(const string _name, int &_minute, bool &_shootout, Scored &_scored, bool &_penality); ~Goal(){}; friend ostream & operator<<(ostream &os, const Goal &_goal); }; --------------- Stadium --------------- class Stadium { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & name; ar & city; ar & spectators; } string name; string city; int spectators; public: Stadium(){}; Stadium(const string _name, const string _city, int &_spectators); friend ostream & operator<<(ostream &os, Stadium &_stadium); }; ---------------- and Match ---------------- class Match { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & home; ar & visitors; ar & kickoff; /*lGoals::const_iterator pos; for (pos = goals.begin(); pos != goals.end(); pos++) { ar & pos; }*/ ar & BOOST_SERIALIZATION_NVP(goals); ar & stadium; } string home; string visitors; time_t kickoff; typedef list<Goal> lGoals; lGoals goals; Stadium stadium; public: Match(){}; Match(const string _home, const string _visitors, time_t &_kickoff, Goal _goals[100], Stadium &_stadium); Match& operator = (Match &_match); friend ostream & operator<<(ostream &out, Match &_match); }; ---------------- Now I have to serialise this classes in an xml structure. Therefor I've created the file xml.h/.cpp. I only post the xml.cpp here: ---------------- #include <iomanip> #include <iostream> #include <fstream> #include <string> #include "goal.h" #include "stadium.h" #include "match.h" #include <boost/serialization/base_object.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> //Tracing and Logging module //#include "Logger.h" //#include "Tracer.h" using namespace std; /** * \brief Fuction to Deserialise a xml-file to an object structure * \param const Match &m, const string &filename * \return void */ void save_xml(const Match &m, const string &filename){ // make an archive ofstream ofs(filename.c_str()); boost::archive::xml_oarchive oa(ofs); //fill data to archive oa <<BOOST_SERIALIZATION_NVP(m); ofs.flush(); } /** * \brief Fuction to Serialise an object structure to a xml-file * \param Match &m, const string &filename * \return void */ void restore_xml(Match &m, const string &filename) { // open the archive ifstream ifs(filename.c_str()); boost::archive::xml_iarchive ia(ifs); //restore the data from the archive ia >>BOOST_SERIALIZATION_NVP(m); } ---------------- So thats it and I hope its not all wrong I tried. I hope you can help me finish that project. Thanks!

3 6

[date_time] Documentation Fix (time_period)
by Bryan Petty 30 Jun '08

30 Jun '08

Hi, Attached is a quick patch to switch the placement of the time_period(ptime,ptime) and time_period(ptime,time_duration) examples to their correct locations. Regards, Bryan Petty

2 2

Trac "search" link doesn't work
by Phil Endecott 30 Jun '08

30 Jun '08

Hi All, I've just found that if I go to http://svn.boost.org/trac/boost/ and click on the "search" link (2nd level of the indented list, "search first to avoid creating duplicates"), I get a 404. It links to http://svn.boost.org/trac/boost/trac/boost/search?ticket=on; it should be missing one of the "trac/boost"s. The search box at the top of the page does work though. (Isn't there a link checker somewhere that looks for this sort of thing?) Phil.

2 1

[serialization] Thread safety question.
by Jurko Gospodnetić 30 Jun '08

30 Jun '08

Hi. Some pages on the web (e.g. http://www.rrsd.com/boost/index.htm) and some old news posts seem to indicate that the current trunk version version to be included with Boost 1.36 makes the library 'thread safe'. What exactly does that entail? Can two separate archives be created in two separate threads? Was that not also true with the version included in the Boost 1.35 library release? Many thanks. Best regards, Jurko Gospodnetić

2 1

[intrusive_ptr] 2 questions
by Gennadiy Rozental 30 Jun '08

30 Jun '08

Hi, These might've been ask and answered already - can 't find it though. 1. Why doesn't intrusive_ptr have reset( T* )? 2. Why there is no something like this provided by the header: template<typename Derived> class intrusive_base { protected: intrusive_base() : m_counter( 0 ) {} private: friend void intrusive_ptr_add_ref( Derived* p ) { ++p->m_counter; } friend void intrusive_ptr_release( Derived* p ) { --p->m_counter; if( !p->m_counter ) delete p; } unsigned m_counter; }; to be used like this: class Foo : intrusive_base<Foo> { ... }; This should streamline intrusive_ptr class usage, isn't it? Or there is an alternative way already? Gennadiy

2 2

boost::result_of and C++03
by Eric Niebler 30 Jun '08

30 Jun '08

My experience developing Proto has taught me a hard lesson about the ResultOf protocol that I thought I would share. Maybe someone here can tell me if/where I've gone wrong. There's a part of Proto (proto::call<>) that takes function objects, passes arguments to them and returns the result. I use result_of to compute the return type. Fine. Proto defines a function object, make_foo, whose behavior depends on the lvalue/rvalue-ness of its arguments. So for instance: // Return type of make_foo when passed a rvalue // int and an lvalue float: result_of< make_foo( int, float & ) >::type Like a good citizen, I've written make_foo's function call operator to recognize reference_wrapped and non-const-ref arguments as representing lvalues and all others as rvalues. (This is because C++03 doesn't have rvalue references.) Fine. Now, given some function type F (which may or may not be make_foo) and some arguments a0...an (which may or may not be lvalues), how do I invoke F? The strictly correct thing to do would be to wrap lvalues in reference_wrappers before passing them to F. If I don't, make_foo will do the wrong thing. However, Proto needs to work with function objects in the wild, very few of which do the right thing with reference_wrapped arguments, in my experience. What to do? I don't know. This business of needing to reference_wrap objects to get correct lvalue/rvalue semantics is a deal-breaker for Proto transforms. If I needed to wrap each lvalue argument before forwarding it to the next transform, and unpack each argument within each tranform, it would: a) Make writing transforms extremely tedious. b) Kill compile times with lots of unnecessary mpl::if_, is_reference, reference_wrapper and unwrap_reference instantiations. For these reasons, I've decided that Proto's transforms will use a different function object protocol. None of that will be visible from the outside. Transforms will still look like TR1-style function objects. But transforms will provide a separate interface for internal consumption that doesn't have this rvalue/lvalue problem. The problem, as I see it, stems from the fact that the return type calculation is separated from the function invocation. struct blarg { template<typename This, typename Arg> struct result< This( Arg ) > { // OK, if Arg is a reference, then it's an lvalue! }; template<typename Arg> typename result< make_foo( ??? ) >::type operator()( Arg const & arg ) { // whoops, I don't know here if arg is an lvalue or rvalue } }; If function objects were instead written like this ... struct blarg { template<typename Arg> struct impl { // OK, if Arg is a reference, it's an lvalue typedef ... result_type; result_type operator()(typename add_const_ref<Arg>::type arg) { // The right thing can happen here. } }; }; ... the problem goes away. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 65

[fusion] how to implement fusion_map_from_element for [intrusive]?
by Gordon Woodhull 29 Jun '08

29 Jun '08

Hello, I am hoping to contribute an extension for intrusive to handle fusion containers, so that an intrusive hook can be an element in a fusion container and a fusion container can be an item in an intrusive container. To state more clearly: the adapter will allow fusion containers to "carry membership" in intrusive containers. (like an aclu card ;-) In order to do this, intrusive needs some way to get a pointer to a fusion container from a pointer to a fusion container element. My strategy is to write functions e.g. intrusive::detail::fusion_map_from_element, fusion_vector_from_element, etc., with template parameters for the fusion container type and the index or key, and use/adapt the functions in boost/intrusive/detail/parent_from_member.hpp which hide all the scary pointer arithmetic and compiler-specific stuff. I'll then need to sum up the offsets in a chain of pointers to members, as I explain next. I've attached a first attempt. vector_pointer_to_member successfully fetches a pointer to member for fusion::vector##<>, without having to make any changes to fusion. It's not pretty or good practice, but it works. With this I would be able to write the adapter for vector##<>, as shown partly in fusion_container_from_element.hpp, but this doesn't work for fusion::vector<> itself, never mind fusion::map, because vector## is a private member of vector<> which is a private member of map<>, as it should be. I think I will need to make a change to fusion itself to return a chain of pointers-to-members, and I'm wondering what's the best way to do this. 0. Am I overlooking a simpler solution? 1. I'd like to add this functionality to fusion without changing the public interface. Does this sound reasonable? There would have to be a few unadvertised member {meta}functions, and then perhaps a few free functions in fusion::detail with ugly long names such as chain_of_pointers_to_members_of_element_in_map. Rationale for hidden interface: I can't think of any other legitimate reason why anyone would want pointer/offset-to-member, it totally breaks the nice fusion abstraction, and it is only going to be safe in situations where you know for sure that the element is contained in the container you claim it's in. Intrusive can guarantee safety here because you always insert the full object; it only needs to cast from part to whole internally; and clients are usually unaware of the weird casts. 2. The chain of pointers to members is an oddity I haven't seen before - does anybody know of any implementations? I am thinking to use an mpl sequence of types to generate a sequence one shorter of pointer-to- member types. I hope to also put the pointer-to-member _values_ in an mpl sequence and calculate offsets at compile time. An alternative implementation, simpler in some ways, is to calculate the offset recursively and not use a chain of pointers to members, but I don't like it because offsets are gross and everyone would have to call offset_from_pointer_to_member. OTOH, I don't know of any other use for a chain of pointers to members except for finding offsets! 3. As with parent_from_member, map_from_element isn't specific to intrusive, but I don't know of any other uses and it's slightly dangerous, so it should probably stay in boost::intrusive::detail. Any ideas? Thanks, Gordon P.S. Obviously this technique will only work for contiguous fusion containers, not views.

2 2