- Boost - lists.boost.org

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

I've been looking through the template instantiation trace, and I can't figure out where the choice to use the intrusive mechanism is made. I'll keep looking a little more, and I've appended the trace below: ------ Build started: Project: NewClient, Configuration: Debug Win32 ------ Compiling... EnhancedMessageHandler.cpp c:\D2\API\NewClient\EnhancedMessageHandler.cpp(151) : warning C4244: '=' : conversion from 'uintptr_t' to 'unsigned long', possible loss of data c:\new_boost\boost\boost\serialization\access.hpp(107) : error C2039: 'serialize' : is not a member of 'Jrs::SmartPtr<T>' with [ T=D2::Message ] c:\new_boost\boost\boost\serialization\serialization.hpp(81) : see reference to function template instantiation 'void boost::serialization::access::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\serialization.hpp(140) : see reference to function template instantiation 'void boost::serialization::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(152) : see reference to function template instantiation 'void boost::serialization::serialize_adl<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\extended_type_info_typeid.hpp(71) : while compiling class-template member function 'void boost::archive::detail::oserializer<Archive,T>::save_object_data(boost:: archive::detail::basic_oarchive &,const void *) const' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(236) : see reference to class template instantiation 'boost::archive::detail::oserializer<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(235) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard: :invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessageP tr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(294) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard ' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(282) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(534) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\basic_text_oarchive.hpp(78) : see reference to function template instantiation 'void boost::archive::save<Archive,T>(Archive &,T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\interface_oarchive.hpp(89) : see reference to function template instantiation 'void boost::archive::basic_text_oarchive<Archive>::save_override<T>(T &,int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\D2\API\NewClient\EnhancedMessageHandler.cpp(115) : see reference to function template instantiation 'Archive &boost::archive::detail::interface_oarchive<Archive>::operator <<<const D2::MessagePtr>(T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ]

3 2

[iostreams] example_test and newline_test loop on gcc-3_3-darwin
by Douglas Gregor 19 May '05

19 May '05

The iostreams example_test and newline_test seem to be looping. I've killed them on the OSL tester, but now symmetric_filter_test is currently taking a really long time to run... with the exception of newline_test (which has been failing for a while), all of these tests were passing before yesterday's flurry of iostream modifications. Doug

5 19

Big integer library
by Marcin Kalici�ski 19 May '05

19 May '05

Tracking the disussion on n1774 'Big integer library proposal for C++0x' I see there is a lot of controversy about it, and it will probably need much tweaking before (if ever) it is accepted. Wouldn't that be a good idea to have a big integer added to boost so that we can create a 'working practice' before anything gets standarised? I have some preliminary source code, some spare time, and would volunteer to work on it if there's enough interest. cheers, M.

11 10

[Iterator] advance and distance that understand new iterator concepts?
by Douglas Gregor 19 May '05

19 May '05

Do we have counterparts to std::advance and std::distance that are optimized for random_access_traversal_tag instead of std::random_access_iterator_tag? Doug

2 1

[Wave] Boost Inspection Report
by Hartmut Kaiser 19 May '05

19 May '05

Hi all, the boost inspection report claims that one of the Wave test files contains tabs. And this is correct! But: it needs to contain tabs because it's a testcase... Should I ignore this warning? Or is there a way to tell the inspect program to ignore tabs in this particular file? Regards Hartmut

4 10

xpressive not in boost.1.33, but what about 1.34?
by Bronek Kozicki 19 May '05

19 May '05

I suppose xpressive has not been accepted into boost yet (or I missed library review). This would mean that we will not see it in boost 1.33. Is there any chance we would see it in boost 1.34? B. -- Bronek Kozicki brok(a)rubikon.pl http://b.kozicki.pl/

8 13

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 18 May 2005 16:54 > To: boost(a)lists.boost.org > Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > By extensive error trace I mean the whole chain of > instantiations with lines like "instanciated from" ... > Sometimes this chain is dozens of lines long. Its the > compile-time version of a call stack. This can be used to > trace back through the chain of calls to determine which one > didn't work as expected. How do I access this trace? I've never seen such a thing. > Robert Ramey > > > Perhaps I don't know enough about VC 7.1, but what > extensive error > > trace? > > > > c:\new_boost\boost\boost\serialization\access.hpp(107): error C2039: > > 'serialize' > >> is not a member of 'Jrs::SmartPtr<T>' > > with > > [ > > T=D2::Message > > ] > > > > is all that I get. I can't begin to imagine how I would go about > > diagnosing the cause of the error. > > > > > > >

2 1

[Boost-bugs] [ boost-Bugs-1204688 ] Document copy_component
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204688, was opened at 2005-05-18 21:18 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=1204688&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Document copy_component Initial Comment: It's in boost/graph/copy.hpp, and useful, so we should document it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204688&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1204684 ] random_vertex/random_edge are unnecessarily inefficient
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204684, was opened at 2005-05-18 21:12 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=1204684&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: random_vertex/random_edge are unnecessarily inefficient Initial Comment: random_vertex and random_edge should require constant time for RandomAccessTraversal iterator, but they are still linear time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204684&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[operators] Improved workaround for BOOST_NO_OPERATORS_IN_NAMESPACE
by Daniel Frey 18 May '05

18 May '05

A new version of operators.hpp is available in the sandbox at <http://boost-sandbox.sourceforge.net/vault/index.php?&directory=daniel_frey>, it contains an improved workaround for compilers that need BOOST_NO_OPERATORS_IN_NAMESPACE. Other compilers should not be affected, but hey, you never know :) I'd like to ask for people to test the new version. In particular, the following compilers set BOOST_NO_OPERATORS_IN_NAMESPACE in their config-files (see boost/config/compiler/...) for some versions: - GCC < v3 - Borland - Digital Mars - ACC (hp_acc) If you (still) have one of these compiler with the affected versions, please test the new operators.hpp. Besides running the regression tests, which obviously must work, you can try to compile the following examples with the old and the new version: Example1.cpp: #include <boost/operators.hpp> using namespace boost; class a:addable1<a>{ public: a& operator+=(const a&){return *this;}; }; int main(){ } Example2.cpp: #include <boost/operators.hpp> bool addable1; int main(){ } Both examples previously failed to compile on (some of?) the compilers that had BOOST_NO_OPERATORS_IN_NAMESPACE defined, the new version should fix that. Also, reviews of the patch are also welcome. One final note: The new version will not go into 1.33.0, which is why I choose to put the new version in the sandbox first. Once 1.33.0 is out and given that the initial tests look positive, it will go into CVS to make sure the full regression testing is applied and the regression test will be improved to check for the above examples. Out of curiousity: Will the new version (with the appropriate define set) improve the situation for the VC7? Anyone care to check that, too? (If it shows an improvement, I honestly have no clue why ;) Thanks for you time. Regards, Daniel

1 0