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

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

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: <6.2.3.4.2.20051026233845.06694ac0(a)mail.rudbek.com> vawjr(a)rudbek.com (Victor A. Wagner Jr.) wrote (abridged): > OK, fix the core language so that I don't have to write the whole > batch of forwarding functions You can use private inheritance and using-declarations, if that helps. > AND I get the new ones automatically when std::vector gets updated!! That's the controversial part. If you inherit from std::vector it is relatively easy for changes to the std library to break your code. The worst case is when the base class adds a virtual function with the same name as one of your private member functions. You might consider using non-member functions which take a std::vector argument instead. It sounds like you are not adding any data or virtual functions, so your new stuff may not actually need to be member functions? -- Dave Harris, Nottingham, UK.

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: <djpuvk$q3d$1(a)sea.gmane.org> simon(a)hand-multimedia.co.nz (Simon Buchan) wrote (abridged): > > Generally when I've wished for that I've also wished for a few other > > virtual functions. For example, a hook which gets called whenever an > > item is added to the vector [...] > > That's what your class would add, presumably. Yes, but as I understand it, I can't usefully add them by inheriting from the proposed class. This is because, eg, virtual_vector::push_back is not virtual. Users could do: my_vec<int> *p1 = new my_vec; p1->push_back( 0 ); // OK, uses my hook. virtual_vector *p2 = p1; p2->push_back( 0 ); // Silent error, does not use my hook. In my view to be useful a virtual_vector would need lots of virtual methods, not just the destructor. > But when you *do* want to write a vector (or whatever) interface > compliant class, it's a bloody pain to do it for each one you do. I can only report my experience, which is that I've never wanted to do that. > His impl has the benefit that you just publicly inherit from this class, > and add the extra stuff in, overriding any methods that you want to do > differently. (I assume the forwarders will be virtual?) I didn't think he did intend that the forwarders be virtual. If it is, then I withdraw my objection. And I am curious as to whether he has: void virtual_vector::clear() { m_vector.clear(); } or: void virtual_vector::clear() { erase( begin(), end() ); } That is, whether I have to override both erase and clear or just erase. And whether things like begin() and end() are also virtual, and whether the iterators they return have virtual methods too. It sounds like it could be a performance hit. > > In general inheriting from anything in the std library has the > > drawback that it injects unknown junk names into your class. > > Inheriting from a boost class is hardly better. > > Actually, his posted impl doesn't do that. He isn't doing, but he proposes that users do. The reason for giving boost::virtual_vector a virtual destructor is so that users can inherit from it. -- Dave Harris, Nottingham, UK.

1 0