- Boost - lists.boost.org

VC++ 7.1 build options lead to AV
by Ashok Thirumurthi 29 Oct '05

29 Oct '05

Dear Boost, The following call stack leads to an access violation when I link a VC 7.1 DLL to the release build of the boost signals 1_33_0 DLL. In comparison, there is no access violation when I link to the debug build of the same library. Similarly, when I add the signals source to my own release DLL, there is no access violation. I attempted to disable all compiler optimizations in msvc.jam as follows. However, after running bjam -a in signals\build and installing the output, the AV still occurs. # 8.0 deprecates some of the options if ! [ MATCH ^([67].*) : $(version) ] { # flags msvc.compile CFLAGS $(condition)/<optimization>speed : /O2 ; # flags msvc.compile CFLAGS $(condition)/<optimization>space : /O1 ; flags msvc.link.dll MANIFEST : "mt -manifest " ; flags msvc.link.dll OUTPUTRESOURCE : "-outputresource:" ; } else { # flags msvc.compile CFLAGS $(condition)/<optimization>speed : /Ogity /O2 /Gs ; # flags msvc.compile CFLAGS $(condition)/<optimization>space : /Ogisy /O1 /Gs ; } Note that I have a default installation of Visual Studio 2003. How can I alter the release build to avoid the access violation? More information: Access violation reading location 0x00000004 (*((k2).content)).__vfptr is 0x00000000 bool operator()(const any& k1, const any& k2) const { if (k1.type() == typeid(front_type)) return !(k2.type() == typeid(front_type)); if (k1.type() == typeid(back_type)) return false; > if (k2.type() == typeid(front_type)) return false; if (k2.type() == typeid(back_type)) return true; > Colorado.dll!boost::signals::detail::any_bridge_compare<std::less<int>,int>::operator()(const boost::any & k1={...}, const boost::any & k2={...}) Line 54 + 0xc C++ Colorado.dll!boost::detail::function::function_obj_invoker2<boost::signals::detail::any_bridge_compare<std::less<int>,int>,bool,boost::any,boost::any>::invoke(boost::detail::function::any_pointer function_obj_ptr={...}, boost::any a0={...}, boost::any a1={...}) Line 119 + 0x1b C++ boost_signals-vc71-mt-1_33.dll!010a2340() boost_signals-vc71-mt-1_33.dll!010a2c6a() boost_signals-vc71-mt-1_33.dll!010a42be() boost_signals-vc71-mt-1_33.dll!010a4bd0() boost_signals-vc71-mt-1_33.dll!010a4dfc() boost_signals-vc71-mt-1_33.dll!010a5933() Colorado.dll!boost::signal0<bool,boost::last_value<bool>,int,std::less<int>,boost::function<bool __stdcall(void),std::allocator<void> > >::signal0<bool,boost::last_value<bool>,int,std::less<int>,boost::function<bool __stdcall(void),std::allocator<void> > >(const boost::last_value<bool> & c={...}, const std::less<int> & comp={...}) Line 198 + 0x85 C++ ... Do these observations suggest how I might successfully handle this callback from the release boost DLL? Thanks in advance, - Ashok Thirumurthi

2 1

bind/bind_template.hpp + EDG 238 trouble + patch
by Ralf W. Grosse-Kunstleve 28 Oct '05

28 Oct '05

Hi, The changes to boost/bind/bind_template.hpp from 10/25 break the Boost.Python build under IRIX/MIPSpro 7.3.1. The problem is due to a known bug in the old EDG frontend (it is the obscure "ambiguous by inheritance" bug). Attached is a simple patch that restores the Boost.Python build. I've tested the patch on 18 other platforms, incl. Windows, Mac OS X, Tru64 Unix, and a bunch of Linux distributions. If the patch looks reasonable and I get an OK I'd be happy to check it in. Thanks! Cheers, Ralf Index: bind_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind/bind_template.hpp,v retrieving revision 1.6 diff -u -r1.6 bind_template.hpp --- bind_template.hpp 25 Oct 2005 21:01:41 -0000 1.6 +++ bind_template.hpp 28 Oct 2005 17:28:28 -0000 @@ -38,7 +38,8 @@ BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } -#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) +#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) \ + && !BOOST_WORKAROUND(__EDG_VERSION__, <= 238) template<class A1> result_type operator()(A1 const & a1) { @@ -66,7 +67,8 @@ BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } -#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) +#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) \ + && !BOOST_WORKAROUND(__EDG_VERSION__, <= 238) template<class A1, class A2> result_type operator()(A1 const & a1, A2 & a2) { __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

Boost regression notification (2005-10-28 [RC_1_33_0])
by Douglas Gregor 28 Oct '05

28 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-28T15:01:23Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 59 failures in 4 libraries: parameter (1) range (3) serialization (53) thread (2) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_5-darwin gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_5-darwin gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_5-darwin gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_5-darwin gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos test_shared_ptr_132_text_warchive: intel-win32-8_1 |thread| test_mutex: cw-9_4 test_thread: intel-win32-8_1

1 0

Re: [boost] alignment trouble with boost::optional
by Martin Bonner 28 Oct '05

28 Oct '05

----Original Message---- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: 27 October 2005 12:57 To: boost(a)lists.boost.org Subject: Re: [boost] alignment trouble with boost::optional > Michael Shepanski <mshepanski(a)gmail.com> writes: > >> On 10/26/05, David Abrahams <dave(a)boost-consulting.com> wrote: >>> >>> >>> I think the problem is that type_with_alignment can't find a type >>> that has an alignment of 12. Producing an error in that case is the >>> right behavior. We could add the type whose alignment_of<> is 12 to >>> the reperotoire of types being tested by type_with_alignment... >> >> >> >> Don't we need to be sure that type_with_alignment<> can accept *any* >> number that alignment_of<> produces -- or, conversely, make sure that >> alignment_of<> only produces numbers that type_with_alignment<> can >> accept? (I'm assuming that we want boost::optional to work all the >> time, not just for my example.) > > Sure, that's what we want. Can you figure out *how*? That's the > problem. In summary: 1. alignment_of<T> produces a number that is a multiple of the required alignment. 2. type_with_alignment<> cannot deal with all the numbers that alignment_of<> produces. Does anyone know of any platform (including platforms that are no longer in use), where the alignment requirement was /not/ a power of two? If not, then alignment_of<> "just" needs to eliminate the factors from its result which are not a power of two. (That would also allow us to eliminate the special case for long double under Borland). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[shmem] New snapshot available: Review Request
by Ion Gaztañaga 28 Oct '05

28 Oct '05

Hi to all! I've just uploaded a new snapshot of Shmem to Boost Vault/Memory folder. Online documentation, as always, is here: http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html New features: -> Windows API predeclaration so windows.h include is eliminated. Since Shmem is a header-only library, this change should help compile times. -> Null index type: If you don't need named allocations, and you want some space and compilation time, you can use a null index type instead of paying for an index you don't use. -> New synchronization primitive: named_mutex (Similar to Windows named mutex). -> Doxygen reference error corrections thanks a Boostbook Doxygen patch. There are some slight errors from BoostBook but now it looks much better. -> Improved named object destruction performance with destroy_ptr when using node container based indexes (map_index). Now is O(N) instead of O(logN). -> Decoupled red-black tree algorithms from shmem_tree class so that there is a good base for future shared memory intrusive rb_tree containers. -> Documentation corrections. Open issues, future work and references chapters added. -> Bugfixes. Tested in Windows XP with VC.NET 2003 and Suse 10.0 with gcc 4.0.2. I would like to request a review for Shmem to add it to Boost and I only plan to fix bugs until the review starts. I think there are some open issues in Shmem that should be solved (if Shmem is going to be accepted, of course) during the review. The most important ones are related to Boost Thread and the need of avoiding functionality duplication (scoped_locks, time representation, etc...). I've described them in Open Issues chapter of the documentation. If Shmem is considered good enough for Boost, I would like to work with Boost Thread's users and developers to have a common interface and utilities in thread-shared and process-shared synchronization objects, etc... I started Shmem 11 months ago (and the process of placing STL containers in shared memory many months before) and I would like to thank all who have tested the library, for all their ideas, suggestions and help. Regards, Ion

3 4

Re: [boost] Is there any interest in a library that provides containers with virtual destructors?
by Victor A. Wagner Jr. 28 Oct '05

28 Oct '05

At 10:48 2005-10-27, Matt Calabrese wrote: >On 10/27/05, Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > > > OK, fix the core language so that I don't have to write the whole > > batch of forwarding functions, AND I get the new ones automatically > > when std::vector gets updated!! > > No??? don't wanna do that? > > then it ISA std::vector<> (or whatever STL collection I choose)!! > > >Don't use an IS-A relationship just because you want to save time typing. >Use an IS-A relationship if IS-A makes sense. If you really always want all >of vector's operations exposed without additional typing, then just >encapsulate it and make it public. If you want the member functions to be a >direct part of the encapsulating class, then use private inheritance and >promote the member functions and types from the vector base class to your >type's public interface with using-delcarations. and that gains me what? a LOT of typing (why the heck isn't there a using class blah; like we have using namespace widget; ??) that needs to be checked.. and possibly modified every time (well ok, once every decade or so) the library is updated. A major maintenance headache just waiting to happen. and I _have_ to make ALL the methods public and ALL the typedefs because I would like to use my collection with ALL of the stuff in <algorithm> and you're never _quite_ sure what an implementation _might_ do or need. It's not that I'm in love with this idea, I'm just saying that it is NOT always bad to inherit from a concrete class that doesn't have a virtual destructor. That's where this all started. I've done it only in a couple places (from standard library things).. mostly to satisfy some programmers who've convinced management that they can't _possibly_ use a string class that doesn't have (pick one... trim, upcase, whatever) and I'm very likely to do it to attempt to normalize the container libraries in the STL as part of an article attempting to shame the committee into making some changes. >-- >-Matt Calabrese >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

Re: [boost] Is there any interest in a library that provides cont ainers with virtual destructors?
by Martin Bonner 28 Oct '05

28 Oct '05

----Original Message---- From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] Sent: 26 October 2005 15:16 To: boost(a)lists.boost.org; 'boost(a)lists.boost.org' Subject: Re: [boost] Is there any interest in a library that provides cont ainers with virtual destructors? > At 02:51 2005-10-26, Martin Bonner wrote: >> ----Original Message---- >> From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] >> Sent: 26 October 2005 05:36 >> To: boost(a)lists.boost.org; boost(a)lists.boost.org >> Subject: Re: [boost] Is there any interest in a library that provides >> containers with virtual destructors? >> >>> At 10:04 2005-10-25, Andy Tompkins wrote: >>>> I have read a few times that people sometimes wish that std::vector >>>> (or other containers) had a virtual destructor. [snip] >>>> This allows one to write something like: >>>> >>>> struct person { >>>> string first_name; >>>> string last_name; >>>> }; >>>> class people : public virtual_vector<person> >>>> { >>>> public: >>>> //extra methods >>>> }; >>>> >>>> Is this useful? >>> >>> unless I mis-read (or mis-understood...far more likely) a lot of >>> books on how C++ works, I don't believe there is any reason for what >>> _you've_ shown to need a virtual destructor. >> >> You have mis-read or mis-understood (or you need better books). >> Consider: virtual_vector<person>* p = new people; > > I guees I wasn't clear.. I was suggesting that virtual_vector has no > need for existence. > >> delete p; >> That invokes undefined behaviour unless virtual_vector<person> has a >> virtual destructor. > > are you suggesting that if it were class people: public > std::vector<person> {.....}; as above the same would be true? > not "in practice", "in theory". Absolutely. See 5.3.5/1 of the standard where this is explicitly called out as undefined behaviour. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 8

Re: [boost] Is there any interest in a library that provides cont ainers with virtual destructors?
by Martin Bonner 28 Oct '05

28 Oct '05

----Original Message---- From: Matt Calabrese [mailto:rivorus@gmail.com] Sent: 27 October 2005 06:44 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library that provides containers with virtual destructors? > On 10/27/05, Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: >> >> indeed, but there is no dynamic type vs static type in the example. > > > If you have a virtual_vector<person>* which points to an instance of > people, and you call delete with that pointer as an operand, you > have undefined behavior unless virtual_vector<person> has a virtual > destructor since virtual_vector<person> is the static type and people > is the dynamic type. Nit: Actually the static type is virtual_vector<person>*, and the dynamic type is people*. (The standard talks about the static and dynamic types of the operand to delete, not the static and dynamic types of the object pointed to by the operand to delete.) (Given the mess I made of the last reference I made to the standard, I shall be interested to see what I have got wrong THIS time!) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

Boost T-Shirts @ Cafe Press
by Jeff Garland 28 Oct '05

28 Oct '05

Hi All - As everyone is probably already aware, we have a new Boost logo that was created by booster Zoltan 'cad' Juhasz. As part of the final logo refinement process, the moderators asked Zoltan if he could create T-Shirts with the new logo. We also felt it was appropriate that Zoltan be the beneficiary of any proceeds associated with the T-Shirts since it was his tireless work that went into the logo and T-Shirt design. With that in mind, I'm delighted to announce that Zoltan worked out some T-Shirt designs and has set up a couple shops at Cafe Press so that people can purchase Boost T-Shirts. - http://www.cafepress.com/boostlibs - http://www.cafepress.com/boostlibsb If you have suggestions or other ideas you can find Zoltan's contact info at: http://people.inf.elte.hu/cad Jeff

1 0

Re: [boost] Is there any interest in a library that provides container
by brangdon＠cix.compulink.co.uk 27 Oct '05

27 Oct '05

In-Reply-To: <1130423747.22962.246152955(a)webmail.messagingengine.com> atompkins(a)fastmail.fm (Andy Tompkins) wrote (abridged): > I have also realized that (for my purposes) I don't require the > ability to delete people from a pointer to its base class > [code skipped] You might consider having wrap_vector inherit privately from std::vector and adding using-declarations rather than forwarding functions. I don't think using composition gains much, given that you are going to inherit from wrap_vector anyway. Using-declarations would be less code, possibly a lower abstraction penalty and would avoid problems with tracking exactly the std vector declarations. > // overload wrap_vector member functions for different behavior That's risky, because there is an implicit conversion from people to wrap_vector<person> and your overloads won't affect the wrap_vector versions. What I think you really want to do is prevent the derived to base conversion. It's a shame this doesn't work: #include <vector> struct Container : public std::vector<int> { typedef std::vector<int> base; private: operator base &(); operator const base &() const; }; void test() { Container *p1 = new Container; Container::base &p2 = *p1; // Shame this compiles. } Maybe it is worth floating in comp.std.c++. -- Dave Harris, Nottingham, UK.

2 1