- Boost - lists.boost.org

[policy_ptr]source, sink policies proposal
by Larry Evans 14 May '05

14 May '05

Currently, policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… constains a conversion policy which determines whether or not to contain an implicit conversion to the raw pointer via the smart_ptr</*polcies typelist*/>::to<Referent> method: operator automatic_conversion_result(void) const; where: typedef typename conversion_policy::result_type automatic_conversion_result; However, since smart_ptr<...>::to<Referent> is derived as: class smart_ptr<P1, P2, P3, P4>::to : public detail::policy_ptr::conversion_policy_ couldn't the automatic conversion operator just be defined (in the case of allow_conversion) or not (in the case of disallow conversion) in the conversion policy itself? In addition, instead of allowing the raw pointer to escape from the "protection" of the smart_ptr via the storage policy's get_impl, why not delegate this decision to a "sink" policy, which decides how the pointee is exposed to outside use? IOW, rename the conversion policy to the sink policy which decides whether 'operator pointer_type()' or 'get_impl' are publicly exposed. This would allow for a "safer" smart pointer. Along the same lines, why not allow a "source" policy which decides the "inputs" (the CTOR args) to the smart pointer. Currently, for smart_ptr<...>::to<Referent>, the only "source", IIUC, is Referent*. (By source, I mean any CTOR arguments that don't include another smart pointer ). This would also allow for a "safer" smart pointer since the sole source could be something like David Abraham's auto_ptr_new: http://lists.boost.org/MailArchives/boost/msg42996.php

2 5

[Formal review] Singleton library
by Pavel Vozenilek 14 May '05

14 May '05

The formal review of Singleton library written by Jason Hise starts today, May 5th, and lasts 10 days. The library is available at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The singleton documentation can be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ Singleton is feature rich library: - ensuring single instance of a class and global access point to this instance - with policies specifying: - when the instance gets created (manually, immediatelly, when first used, ...) - how is the instance created (by new, malloc, in static memory, ...) - when the instance gets destroyed (never, by priority, after another singleton, ...) Parametrized singleton called Multiton is provided City::pointer p1("Chicago"); City::pointer p2("Brussels"); will create two different "singletons" of the same type. Another feature is ability to register resources (like shared pointer) who will get destroyed in controlled order, when the application exits. Not yet implemented features are: - MT safety - self-destroying singleton with timeout - bjam compatible tests The library is known to work with several newer compilers, VC7.1 among them. Help with other compilers is welcomed. When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. /Pavel

18 58

[program_options] Fix for 64 bit platforms
by Markus Schöpflin 14 May '05

14 May '05

Hello, attached patch has just been committed to program_options/src/cmdline.cpp. It fixes the test failures observed on Tru64 for the cmdline_test test and probably applies to all 64 bit platforms. As a side note, there are many other incorrect uses of unsigned in this file which also should replaced by the correct size_type, but currently these uses don't cause a test failure. Markus Index: cmdline.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/src/cmdline.cpp,v retrieving revision 1.18 diff -u -r1.18 cmdline.cpp --- cmdline.cpp 6 May 2005 07:48:45 -0000 1.18 +++ cmdline.cpp 13 May 2005 11:21:38 -0000 @@ -351,7 +351,7 @@ { string name, adjacent; - unsigned p = tok.find('='); + string::size_type p = tok.find('='); if (p != tok.npos) { name = tok.substr(2, p-2);

2 1

[website] New design is in CVS.
by Rene Rivera 14 May '05

14 May '05

The new design is now in CVS! But before people start saying.. "We don't like it! Why dis you put it in?" ... It was decided that having something now was better than having to wait for another release and have no progress shown on the website. Hence expect the design to continue to evolve after the release. Yell if you do an update, and find any problems. One WARNING, if you update either of the two new pages, index.htm and more/version_history.html, please process them with: tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict [file] So as to ensure no errors creep in, and to make the formatting consistent. I'm trying to find a place to an instruction to that effect, but I can't readily see a place for it. Anyone have a suggestion where I should document running of tidy? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 5

[Boost-bugs] [ boost-Bugs-1201779 ] compiler error on Mac implementation of threads
by SourceForge.net 14 May '05

14 May '05

Bugs item #1201779, was opened at 2005-05-13 21:36 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=1201779&group_… Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: compiler error on Mac implementation of threads Initial Comment: e-mail: myoula(a)videotron.ca With CW 9.4, Carbon (no Mach-O), and BOOST_HAS_MPTASKS defined I got: Error : illegal use of incomplete struct/union/class 'boost:: function<long, long>' safe.cpp line 50 boost::function<OSStatus, Duration> oWaitOnSemaphore; The error statement is marqued below by --> OSStatus safe_wait_on_semaphore(MPSemaphoreID pSemaphoreID, Duration lDuration) { -->boost::function<OSStatus, Duration> oWaitOnSemaphore; oWaitOnSemaphore = bind(MPWaitOnSemaphore, pSemaphoreID, _1); return(safe_wait(oWaitOnSemaphore, lDuration)); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1201779&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=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[range] vc support update
by Jonathan Turkanis 13 May '05

13 May '05

[My email to Thorsten bounced, so I'm posting it here] Thorsten, I finally got around to Boost.Range today. Sorry for the long delay. I've been able to get all the regression tests to pass on VC6, and all the tests to compile on VC7.0. I can't run the tests on the latter platform because of errors in Boost.Test. There are two points which deserve mention: 1. Array support only works for arrays of fundamental types. This should be mentioned in the docs, since it's not apparent from the regression test results. 2. With VC6, the function template arguments to range_end<>::fun() and range_size_<>::fun() were not deduced properly, leading to compiler errors. Since explicitly specifying the arguments caused internal errors, I used a trick from iostreams, and put the static function fun() in a nested class template whose template argument can be explicitly specified without problem; e.g.: template<> struct range_end<std_container_> { template< typename C > struct inner { static BOOST_RANGE_DEDUCED_TYPENAME range_result_iterator<C>::type fun( C& c ) { return c.end(); }; }; }; .... template< typename C > inline BOOST_DEDUCED_TYPENAME range_result_iterator<C>::type end( C& c ) { return range_detail::range_end<range_detail::range<C>::type>:: inner<C>::fun( c ); } This workaround is applied only for VC6. My question is: does this interfere with the extension protocol? If so, I think I can fix it, but only by adding another level of indirection. If you approve, I'll commit these changes. I haven't started working on Borland or GCC 2.9x yet. Jonathan P.S. I ended up not using the collection_traits headers -- the new dispatch mechanism made that unnecessary.

2 5

[1.33] README: Lots of files with no license/copyright
by John Maddock 13 May '05

13 May '05

There are currently quite a few source files showing up with no recognised license or copyright holder information: boost/graph/simple_point.hpp boost/wave/util/flex_string.hpp libs/date_time/example/local_time/local_date_time.cpp libs/date_time/example/local_time/seconds_since_epoch.cpp libs/graph/src/graphviz_digraph_parser.hpp libs/graph/src/graphviz_graph_parser.hpp libs/mpl/book/chapter1/binary.hpp libs/mpl/example/fsm/player2.cpp libs/ptr_container/test/algo_test_data.hpp libs/ptr_container/test/cast.cpp libs/ptr_container/test/concept_check_data.hpp libs/ptr_container/test/convert.cpp libs/ptr_container/test/indirect_vector.cpp libs/ptr_container/test/map_value_iterator.cpp libs/ptr_container/test/null_object.cpp libs/ptr_container/test/ptr_unordered_map.cpp libs/ptr_container/test/ptr_unordered_set.cpp libs/ptr_container/test/sequence_point.cpp libs/ptr_container/test/stack_example.cpp libs/ptr_container/test/tut5.cpp libs/ptr_container/test/vector_size.cpp libs/ptr_container/test/xml_tree_test.cpp libs/python/test/cltree.cpp libs/python/test/tuple.cpp libs/range/test/compat1.cpp libs/regex/performance/time_dynamic_xpressive.cpp libs/test/test/boost_check_equal_str.cpp libs/test/test/config_file_iterator_test.cpp libs/test/test/config_file_test.cpp tools/build/jam_src/filesys.c tools/build/jam_src/hcache.h tools/build/jam_src/subst.c tools/build/v2/test/boostbook/a.hpp tools/build/v2/test/dependency-test/src1/z.h tools/build/v2/test/unused/b.cpp And one file has both, but no date on the copyright: boost/ptr_container/detail/default_deleter.hpp Fixes would be much appreciated, before the release! Thanks, John.

11 26

Re: [ptr_container] memory corruption in ptr_set test
by Caleb Epstein 13 May '05

13 May '05

On 5/12/05, Thorsten Ottosen <nesotto(a)cs.aau.dk> wrote: > I can't easily deduce what the error should be from that file. Unfortunately I > don't have any of the failing compilers. > > Could the problem be related to dynamic cast and not enabling RTTI in the > compiler? No, thats definitely not it. Gcc enables RTTI by default. It looks to me like this call is the problem (for the instantiation of ptr_set_test< ptr_set<Base>, Base, Derived_class >): associative_test_data.hpp:108 i = c.find( *t ); According to valgrind, the memory location pointed to by t was previously deleted. Indeed, I added some debugging output to the Base class ctor and dtor methods, and this is what is happening: Running 1 test case... Base::Base @ 0x1bb45770 Derived_class @ 0x1bb45770 Base::Base @ 0x1bb45c58 Derived_class @ 0x1bb45c58 Base::Base @ 0x1bb46140 Derived_class @ 0x1bb46140 Base::Base @ 0x1bb46628 Derived_class @ 0x1bb46628 Base::~Base @ 0x1bb45c58 Base::~Base @ 0x1bb46140 Base::~Base @ 0x1bb46628 Base::~Base @ 0x1bb45770 Base::Base @ 0x1bb47d90 Derived_class @ 0x1bb47d90 Base::Base @ 0x1bb48798 Derived_class @ 0x1bb48798 Base::Base @ 0x1bb48c80 Derived_class @ 0x1bb48c80 ==15713== Invalid read of size 4 [...] ==15713== Address 0x1BB45770 is 0 bytes inside a block of size 24 free'd ==15713== at 0x1B904CA8: operator delete(void*) (vg_replace_malloc.c:155) ==15713== by 0x8062A4E: Derived_class::~Derived_class() (result_iterator.hpp:59) ==15713== by 0x8063A43: void boost::checked_delete<Base const>(Base const*) (checked_delete.hpp:34) ==15713== by 0x8063A22: void boost::delete_clone<Base>(Base const*) (clone_allocator.hpp:32) ==15713== by 0x8063A0E: void boost::heap_clone_allocator::deallocate_clone<Base>(Base const*) (clone_allocator.hpp:50) ==15713== by 0x80639FA: boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::set_config<Base, std::set<void*, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false>::deallocate_clone(Base const*) (reversible_ptr_container.hpp:112) The address 0x1BB45770 corresponds to the first Base object, which comes from "t = new T" on line 56 of associative_test_data.hpp. This operation seems to be causing it to be deleted: associative_test_data.hpp:66 c3.clear(); > Running 1 test case... > unknown location(0): fatal error in "test_set": std::bad_typeid: Access > violation - no RTTI data! > > ^^^^^^^^^^ > > or is the compiler trying to say that it has seen a null pointer > ("location(0)") ? I assume it is due to the runtime zeroing out memory after it is freed, so the vtable of this object is overwritten. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 13 May '05

13 May '05

I'm trying to use the serialization and archive libraries, and I'm having a bit of trouble getting non-intrusive serializaton to work; I keep getting the error "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: 'serialize' : is not a member of 'D2::Message'". My guess is that for some reason the "long int" hack isn't working properly. I have serialize methods in the boost::seralization namespace like this: namespace boost { namespace serialization { template<class Archive > static void serialize(Archive & ar, const D2::Message& g, const unsigned int version) { //... } } }; Which are textually before any use of the library, as far as I can tell. Any help would be much appreciated. Marcin Tustin IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK tel: +44 23 8076 0834 fax: +44 23 8076 0833 mailto:mt@it-innovation.soton.ac.uk http://www.it-innovation.soton.ac.uk

2 1

[ublas] 1.33 regressions in test4 and test5
by John Maddock 13 May '05

13 May '05

I don't know who (if anyone?) is maintaining ublas at present, but test4 and test5 are failing *on every single compiler* at present. I've partly traced the problem: an exception is being thrown in banded.hpp line 192, in : boost::numeric::ublas::banded_matrix<double,boost::numeric::ublas::basic_row_major<unsigned int,int>,boost::numeric::ublas::unbounded_array<double,std::allocator<double> > >::operator()(unsigned int i=0x00000000, unsigned int j=0x00000001) Line 192 + 0x34 C++ The cause is that the member data member _upper has been initialised to zero, which means any attempt here to access members of the matrix results in an exception being thrown! At present I'm stumped, I haven't been able to figure out what the code is supposed to do well enough to even begin to suggest a fix, so I'm just hoping this will ring a bell with someone, who'll know what to do :-) Regards, John.

2 2