- Boost - lists.boost.org

[type traits, mpl] small fix for BCB 6.4
by Pavel Vozenilek 30 Apr '04

30 Apr '04

BCB 6.4 doesnt't like when top level namespace is prefixed with :: type_traits/is_const.cpp contains line BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,::boost::detail::cv_traits_imp<T*>:: is_const) If the leading :: is removed to BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,boost::detail::cv_traits_imp<T*>::is _const) BCB stops complaining. There are few other places there which may be changed similarly. ---------------- The same problem appears in MPL's value_wknd.hpp: # if !defined(BOOST_MPL_MSVC_60_ETI_BUG) # define BOOST_MPL_AUX_VALUE_WKND(C) ::boost::mpl::aux::value_wknd< C > needs to be changed to # define BOOST_MPL_AUX_VALUE_WKND(C) boost::mpl::aux::value_wknd< C > These problems appeared when trying to compile Collection Traits library. /Pavel

2 2

Can libs/regex/build/gcc.mk use $(AR) instead of just "ar"
by Brad Spencer 30 Apr '04

30 Apr '04

When cross compiling, I need to use an "ar" with the correct target and not just "ar". I've patched boost/libs/regex/build/gcc.mk locally as shown in my attachment, but all I really did was replace use of "ar" with $(AR), which I can then override when invoking make. Perhaps this is reasonable to apply to the mainline copy? [BTW, I'm still locally patching iterator/iterator_facade.hpp because of conflicts with system header macros on i386-pc-solaris2.8. That thread seemed to die.] Thanks! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 1

[Boost-bugs] [ boost-Bugs-945000 ] Dereferencing invalid iterator
by SourceForge.net 30 Apr '04

30 Apr '04

Bugs item #945000, was opened at 2004-04-29 18:56 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=945000&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Dereferencing invalid iterator Initial Comment: boost 1.31.0, subgraph.hpp, line 179, function find_vertex(vertex_descriptor u_global) const; return std::make_pair((*i).second, i != m_local_vertex.end()); //if i == m_local_vertex.end() - iterator should not be dereferenced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=945000&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

serialization doc buglet?
by Neal D. Becker 29 Apr '04

29 Apr '04

Serialization18 reference suggests this should work (this is almost verbatim from the section on seperate load/store free function): #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/vector.hpp> template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } namespace boost { namespace serialization { template<class Archive> inline void serialize(Archive & ar, std::complex<double>& z, const unsigned int file_version) { split_free(ar, z, file_version); } }} Claims "load" is not declared. But adding boost::serialization namespace will fix it: namespace boost { namespace serialization { template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } }} This was tested with gcc-3.3.2. Is this a doc bug?

1 0

Re:[boost] Re: Re:RE: shared pointer serialization
by Robert Ramey 29 Apr '04

29 Apr '04

Fredrik Blomqvist wrote > Thinking about smart pointer serialization and how to generalize it, ie. > to allow serialization of any "my_ref_count_ptr", I got this idea. > > -How about extending the tracking system with a case something like: > serialization::track_ref_count? (perhaps using a is_smart_ptr<> traits > function). > Based on this tag the serializer would at load time maintain a > map<pointer_value, my_ref_count_ptr<T> > to enable the ref-copy "bumping" > of all the subsequent my_ref_count_ptrs. > Where pointer_value is used as key and obtained by boost::get_pointer > (assumed to be specialized for my_ref_ptr). > This is essentially the same approach I outlined earlier in my reviews and > seems similar to both what Peter Dimov uses and Gennadiy mentions above. > It would of course require extensions to the code but I think it would > possible to use/adapt the existing pointer code-path to some degree. As far as I can tell, this is exactly equivalent to what the shared_ptr case study in the documentation/code currently do. No special modification to the library was necessary to accomplish this. Indeed, that was the point of the demo and documentation. The question that has been raised is whether even this is more than is necessary. I have yet to address this in detail. In my opinion, any situation which required special support to be added to the library would reveal a flaw in the library design or implementation. In the future - the library will be smaller - not larger. Robert Ramey

1 0

serialization - howto build w/ boost_1_31_0?
by Neal D. Becker 29 Apr '04

29 Apr '04

What is a simple way to build serialization given a boost_1_31_0 tree? This is on Linux/gcc.

1 0

boost::test - example error
by Roman Yakovenko 29 Apr '04

29 Apr '04

Hi. I think I found error within example "The class member function based test cases". The error is in the first example: ts->add( BOOST_CLASS_TEST_CASE( &my_complex_test::test_feature1 ) ); BOOST_CLASS_TEST_CASE macro expects 2 parameters, instance parameter is missing. Roman

1 0

[patch] Iterator library docs
by Jonathan Wakely 29 Apr '04

29 Apr '04

The attached patch should be applied to the docs for the iterator library to correct a typo jon -- "Some people have a way with words. Others...not have way." - Steve Martin

2 1

Re:RE: [boost] shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Gennadiy Rozental wrote: > This is about how I expect it to work. But from this description it's > unclear: > 1. Why would you need to save counter into archive? After all value 10 > has nothing to do with resulting 5. > 2. Why would you need direct access to shared_ptr counter? After all > using regular shared_ptr copy would automatically bump it to proper value. I remember my initial implementation just restored the original state. Thinking better of it I made a change to the current system. Now that you mention it, it wouldn't seem to need the counter anymore. Just for laughs I commented out the serialization of the counter and if failed to build the test. I'll have to look into it. Robert Ramey

2 1

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 28 Apr '04

28 Apr '04

Message: 13 Fredrik Blomqvist > * What is your evaluation of the implementation? > As I mentioned in my previous review I would like to see it handle most of > the STL and core boost components "out of the box". I believe all STL is handled. Serialization of other boost components will have to be the responsibility of their authors or others. > In particular I think the smart_ptrs (including auto_ptr) should have > core-support from the serializer, even special cased if necessary (similar > to boost::bind etc). I believe the current library is capable of implementing serialization for all boost components. Much effort was expended to that the library would not have to have special code for any serialization or archive type. In fact, my interest is just the opposite. I would like to see a significant part of the library moved outside. Anyone who wants to volunteer to take responsibility for any of the component please let us know. The library would be improved by making it smaller. > The code to serialize std::auto_ptr could easily be copied to the official > directory for example. There has been some discussion of where the serialization code for other boost libraries should reside. I don't have strong feelings about this other than I would prefer that it reside outside the serialization library itself. The only exception I would make is for the STL serialization which has no where else in boost to reside and it has a "special" status as and official C++ library. > Regarding shared_ & weak_ptr. If the implementation path Robert outlines > in the documentation is to be used I guess an official patch to > shared_count is necessary. Would be interesting to hear what the smart > pointer experts think. I agree - the silence is deafining. I know there are applications that use my smart pointer serialization code right now. I implemented and tested it but I don't really know for a fact that it addresses all aspects that need to be addressed such as exception safety, threading, and who knows what else. > Otherwise, I still think the solution I outlined in my previous review > that doesn't require modifying shared_ptr could be considered. Downside > being that it most likely adds a special-cased codepath to the serializer, > but as I said I think it would be worth it. I would hope that the developer's maintaining shared pointer will address this. putting special case code inside the serialization library would be a serious mistake. Between code, tests, and documentation, its approaching 30,000 lines. > The code is nicely written altough complex. Highly nested template code > and lots of mpl. All compile-time checks and further factorizations are > valuable. > Nitpick: serialization/scoped_ptr.hpp seems to have a typo. An extra > #pragma once is present outside the #ifdef (_MSC..) block. It also > includes serialization/pfto.hpp but doesn't seem to use it. Thanks - I love picking these nits. Its easy and satisfying - really. > * Parts of the library that might become standalone boost libraries > The library already provides good separation of components. tatic_warning, > strong typedef, pfto, stack_allocate etc are all given candidates that > would just need better documentation and (fast-track?) reviews. A little bit more is going to be required. They've been tested in the context of serialization and that's OK. I think they need to be more polished and that's a little more work than it first appears. Also a separate review would probably fine tune their interface, implementation and capability. * What is your evaluation of the documentation? > I would also like to see an improved reference documentation that clearly > states the requirements on the types/concepts involved. Hmmm - that seems pretty unanimous - pretty much a first for boost as far as I know. > I support the separation of documentation (and implementation) of other > boost components that like to support serialization. A simple index with > links would suffice I think but most importantly a _consistent_ structure > should be agreed upon which new components can follow. I followed the boost document on how to write documentation. The only wrinkle I added was the right hand index/contents window. I'm pretty pleased with this. I would appreciate VC7.1 project files for the examples and tests though. > One of my tests added support for the STL container adaptors std::stack, > queue and priority_queue. I think direct support for them could be > convinient since they hide the native containers. I attach my > implementation. Feel free to comment I took a short look. The name stack_hack sort of begs some sort of comment. The main thing is that any component of this type has got to be submitted with a test. Thanks for taking the time to study the library and submit a review. Robert Ramey

3 5