August 2005 - Boost - lists.preview.boost.org

serialization as generialized I/O
by Neal Becker 27 Aug '05

27 Aug '05

Looking again at mersenne_twister, one of the objections that has been raised to adding serialization support, is that there is already iostream I/O support. It is in principle possible to leverage iostream to do serialization. Unfortunately, that approach is hardly efficient and rather ugly IMHO. But, what about the other way around? If we have generic archive support, can we use it to eliminate the need for iostream? I think so. In fact, consider this code (assuming serialization suport added to mersenne_twister): typedef boost::mt19937 rng_t; int main() { rng_t rng1; std::ostringstream os; boost::archive::text_oarchive oa(os, boost::archive::no_header); oa << const_cast<const rng_t&>(rng1); std::string st (os.str()); std::cout << rng1 << '\n'; std::cout << st << '\n'; } As it is, the 2 outputs are almost identical. There is only one difference: the text_oarchive (,no_header) output prints 2 leading '0' characters. Is there some way to suppress this preamble? If so, then we have a more elegant solution. All we need to do is put in the serialization support and remove the iostream support, since serialization is just a generalization of i/o.

2 2

Redhat boost rpm update
by Neal Becker 27 Aug '05

27 Aug '05

Well, they ignored me again - this is from the posting: * Fri Aug 12 2005 Benjamin Kosnik <bkoz(a)redhat.com> 1.33.0-1 - Update to boost-1.33.0, update SONAME to 2 due to ABI changes. - Simplified PYTHON_VERSION by Philipp Thomas <pth(a)suse.de>

3 2

optional.hpp problem on AIX and fix (forwarded from boost-users)
by Peter Dimov 26 Aug '05

26 Aug '05

Rich Cook wrote: > That fixed it! Thank you very much for your valuable help. > > To be clear, when I replaced line 388 of optional.hpp: > > get_ptr_impl()->T::~T(); > > with > > get_ptr_impl()->~T(); > > My program compiled fine. > > On Aug 26, 2005, at 2:20 PM, Peter Dimov wrote: > >> Rich Cook wrote: >> >> >>> Ah, but does it work on AIX? :-) >>> Sorry, I couldn't resist. (My posts are getting ignored, so I >>> assume nobody uses boost on AIX. >>> >> >> This might well be the case. Have you tried replacing the problematic >> >> get_ptr_impl()->T::~T(); >> >> construct at line 388 of optional.hpp with >> >> get_ptr_impl()->~T(); >> >> or perhaps >> >> get_ptr_impl()->~value_type(); >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 26 Aug '05

26 Aug '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Thursday, August 25, 2005 9:14 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > BRIDGES Dick wrote: [snip] > > I followed the instructions to build the examples. Changed to the > > example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only > > ran the PingPong* progs. Guess I should have mentioned that. %>] > > Oh, sorry. The fact that you saw the warnings led me to believe that the > examples weren't built with bjam. > Again my exposition was lacking. I built my code and the examples with both bjam and make in unsuccessful attempts to get myself out from between this rock (warnings,warnings everywhere) and that hard place (convincing QA that setting the -Wno-non-virtual-dtor flag for *ALL* of our code that touches the library is acceptable). > > Any chance that, in the absence of some future evidence to the > > contrary, those dtorS can be made virtual in the library? > > I'm at least reluctant to do that. Given the abundance of platforms that > support C++ we can never be sure that there is not one where performance > will suffer significantly when the dtors are made virtual. From the 3 > compilers I use GCC is the only one that a) has such a non-virtual dtor > warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, > the latter will soon be taken care of... I understand. Balancing performance and safety in this dynamic environment of promises and deadlines must be very difficult. I envy your ability and admire what you've accomplished. Just a thought - might it be worthwhile to introduce a policy to allow the user to choose between maximum performance and the comforting consistency of virtual dtorS to go with those virtual functions? :-) > Regards, > > -- > Andreas Huber Regards, Dick Bridges

2 1

Confused about serialization
by Neal Becker 26 Aug '05

26 Aug '05

I don't understand why this simple test doesn't compile. Any hints? #include <iostream> #include <sstream> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> class rng_t { public: friend class boost::serialization::access; // BOOST_SERIALIZATION_SPLIT_MEMBER() template<class Archive> inline void save (Archive &ar, const unsigned int) const { for (int j = 0; j < 10; ++j) // ar << compute(j); ar << int(0); } template<class Archive> inline void load (Archive &ar, const unsigned int) { } template<class Archive> void serialize(Archive & ar, const unsigned int file_version) { boost::serialization::split_member(ar, *this, file_version); } }; void getstate (const rng_t& rng) { std::ostringstream os; boost::archive::binary_oarchive oa(os); oa << rng; } void setstate (rng_t& rng, std::string& st) { std::istringstream is (st); boost::archive::binary_iarchive ia (is); ia >> rng; } g++ -c test.cc test.cc: In member function ‘void rng_t::save(Archive&, unsigned int) const [with Archive = boost::archive::binary_oarchive]’: /usr/include/boost/serialization/access.hpp:93: instantiated from ‘static void boost::serialization::access::member_save(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = const rng_t]’ /usr/include/boost/serialization/split_member.hpp:43: instantiated from ‘static void boost::serialization::detail::member_saver<Archive, T>::invoke(Archive&, const T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/split_member.hpp:69: instantiated from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ test.cc:25: instantiated from ‘void rng_t::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive]’ /usr/include/boost/serialization/access.hpp:109: instantiated from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/serialization.hpp:81: instantiated from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/serialization.hpp:140: instantiated from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/archive/detail/oserializer.hpp:147: instantiated from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive, T = rng_t]’ test.cc:37: instantiated from here test.cc:16: error: no match for ‘operator<<’ in ‘ar << 0’ /usr/include/boost/archive/detail/interface_oarchive.hpp:84: note: candidates are: Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = int, Archive = boost::archive::binary_oarchive]

3 6

Suggestions for new types in the Boost.Any library
by christopher diggins 26 Aug '05

26 Aug '05

Since there has been interest in making changes to boost::any, I thought I would suggest a couple of new types which would be appropriate for the any namespace, which I find useful and use commonly. - A typed_any. This is a type very similar to any with the added restriction that it can not be reset, it must be initialized with a type, and once initialized it can only hold values of that type. I am using a homegrown version an interpreter for a strongly typed scripting language (HeronScript). - any_ptr. The name says it all. Anyone else interested in these types? Christopher Diggins http://www.cdiggins.com

2 1

[ANN] BOOST_FOREACH committed to main CVS
by Eric Niebler 26 Aug '05

26 Aug '05

BOOST_FOREACH was accepted back in May, but the tree was frozen for release. Now that 1.33 is out and the dust is settling, I finally checked it in. It's in boost/foreach.hpp. BTW, is there a guide for adding new libraries to Boost main CVS? I think I got all the bases covered as far as integration with the main docs and the regression test, but I'd like to be sure. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 3

Boost regression notification (2005-08-26)
by Douglas Gregor 26 Aug '05

26 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-26T14:22:15Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 78 failures in 7 libraries: foreach (24) functional/hash (1) graph (7) parameter (4) python (11) serialization (30) wave (1) |foreach| array_byref: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin array_byval: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin cstr_byref: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux cstr_byval: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux pair_byref: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux pair_byval: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux stl_byref: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin stl_byval: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-9_0 msvc vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

[Boost-bugs] [ boost-Bugs-1274143 ] bjam HDRS rule in python tutorial compilation
by SourceForge.net 26 Aug '05

26 Aug '05

Bugs item #1274143, was opened at 2005-08-26 18:10 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=1274143&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leon Oostrijk (ljo_) Assigned to: David Abrahams (david_abrahams) Summary: bjam HDRS rule in python tutorial compilation Initial Comment: When I set HDRS to a value it has no effect. It always produces the value -I"bin/boost" or -I"bin/tutorial". When checked with "-d+7" you can see that the original value is overwritten halfway in the process. As far as I can see nobody uses HDRS in a Boost Jamfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274143&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

undefined behaviour in tuple_io.hpp (bug)(patch)
by Rupert Kittinger 26 Aug '05

26 Aug '05

In the tuple_io.hpp header, there seems to be a slight problem in extract_and_check_delimiter(). The following snippet is problematic: char c; if (is_delimiter) { is >> c; if (c!=d) { is.setstate(std::ios::failbit); } } If c cannot be read because is.eof(), the result of c!=d is undefined. A simple fix is attached. cheers, Rupert -- Rupert Kittinger <rkit(a)mur.at> *** tuple_io.hpp.orig Wed Aug 24 21:05:26 2005 --- tuple_io.hpp Wed Aug 24 21:07:13 2005 *************** *** 349,355 **** char c; if (is_delimiter) { is >> c; ! if (c!=d) { is.setstate(std::ios::failbit); } } --- 349,355 ---- char c; if (is_delimiter) { is >> c; ! if (is.good() && c!=d) { is.setstate(std::ios::failbit); } } *************** *** 443,449 **** CharType c; if (is_delimiter) { is >> c; ! if (c!=d) { is.setstate(std::ios::failbit); } } --- 443,449 ---- CharType c; if (is_delimiter) { is >> c; ! if (is.good() && c!=d) { is.setstate(std::ios::failbit); } }

3 3