- Boost - lists.boost.org

Proposal to add smart_ptr to the boost library
by David Maisonave 31 Jan '06

31 Jan '06

Since the current smart_ptr (policy_ptr) class at boost vault is on hold, I like to propose adding the following smart_ptr class to the boost library: http://code.axter.com/smart_ptr.h IMHO, the above class has more functional features, than the class in the boost vault, and the class is ready for use. The smart pointer is very exchangeable with each other, and it has easy to use policy options. It has an optional lock policy that can be used on all three main ownership policy types (deep_copy, COW, & Shared). It has three methods of cloning policies that can give different levels of generic coding and/or slicing avoidance. The shared and COW policy, can use reference-count, reference-link, and reference-intrusive polices. In my performance test, the shared and COW policies along with reference-link policy, are able to out perform the boost::shared_ptr. It can be used with non-compliant compilers like VC++6.0 and Borland BCC55. And on more compliant compilers (VC++7.x, 8.0, GNU 3.x, 4.x), it has additional capabilities, which allows it to be exchangeable with different policy types, and derive types (T). Like boost::week_ptr, the smart_ptr supports value (pointee) comparison semantics, so it can be used in an associated container like std::map and std:set. Unlike the boost pointer containers, this smart pointer can be used as the first type in the std::map container. The smart_ptr can be used as a shared-pointer, clone smart pointer, Copy-On-Write pointer, and a synchronized smart pointer. Since there's already a similar class in the boost vault, that indicates that there's already interest in this type of class. So IMHO, the question really should be, should we continue to wait for a class in the vault that might never get completed, and might not have all the functionality available in the above smart_ptr? Or should this class be pushed through in parallel to the current vault policy_ptr class. To see a validation test, and performance test, use the following code: http://code.axter.com/boost_ptr_containers/main.cpp http://code.axter.com/smart_ptr.h http://code.axter.com/shape_test.h http://code.axter.com/copy_ptr.h http://code.axter.com/cow_ptr.h

4 5

Re: [boost] Proposal to add smart_ptr to the boost library
by David Maisonave 31 Jan '06

31 Jan '06

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:<8764o1azuq.fsf(a)boost-consulting.com>... > "David Maisonave" <dmaisonave(a)commvault.com> writes: > >> IIUC, the thread-safety problem with reference-linked > >> implementation > >> isn't that so much that it's hard to achieve -- anyone can use a > >> shared mutex -- it's that it's hard to make a thread-safe > >> implementation efficient. That is to say, you pay for the cost of > >> locking and unlocking a mutex, and there's no way around it (**). > >> Locking and unlocking mutexes is way more expensive than performing > >> the lock-free operations used by boost::shared_ptr. > > > > That's true. But it's been my experience that the majority of > > development don't have objects access via multiplethreads or don't > > run in a multithread environment. In this environment, you're paying > > additional price for using boost::shared_ptr reference-count logic, > > but not getting any benefits from it. > > Not if you're compiling without mt support on; the thread safety > features of shared_ptr just compile away (and I think there's a macro > you can use to force them off). Let's compare apples to apples: your > reflinked implementation will be slower in a MT environment. I'm not > yet convinced it will be faster in a ST environment unless you leave > the MT features of shared_ptr turned on. Currently, my test results don't support your above comment. Please provide the this macro you're referring to. Without this macro, there's no way of testing your claim.

2 1

Why does shared_ptr have a public reset() method
by David Maisonave 31 Jan '06

31 Jan '06

Why does boost::shared_ptr have a public reset() method? Why is this method not private? In reading the introduction for weak_ptr, it seems like its main purpose is to cover up or control this opening to boost::shared_ptr. http://www.boost.org/libs/smart_ptr/weak_ptr.htm If boost::shared_ptr didn't have this type of public access, would there be a need for the weak_ptr? I can not find any example code that would justify the requirement for the weak_ptr other than the code in above link.

3 2

msvc, vc-7_0
by Arkadiy Vertleyb 31 Jan '06

31 Jan '06

Hi all, I can't see a column for one of these compilers even in the full regression view... Does anyone still care to support them? Does anyone care if typeof supports these compilers? Regards, Arkadiy

6 6

Re: [boost] Serialization and disctintion between eof and end of archive
by Oliver.Kowalke＠infineon.com 31 Jan '06

31 Jan '06

>OK, after further investigation it appears that the archive reader is in >fact sensitive to one of these two: > >- end of line >- end of stream Hmmm - I didn't notice the end-of-line issue. Now it works. Please ignore my previous email. Regards, Oliver

1 0

trying to install Boost 1.33.1 on Solaris 5.9 + SunStudio 11
by Xavier.Abulker＠fimat.com 31 Jan '06

31 Jan '06

Hello, I'm trying to install Boost 1.33.1 on a Sun Solaris 5.9 Sunpro 11 and after the command: bjam "-sTOOLS=sunpro" install I receive the error message: >> Assertion: (../lnk/init.cc, line 1032) while processing /ftx/opt/SUNWspro/prod/include/CC/Cstd/rw/messages.cc at line 0. >> Assertion: (../lnk/init.cc, line 1032) while processing /ftx/opt/SUNWspro/prod/include/CC/Cstd/rw/messages.cc at line 0. Do you know how I can solve this problem? It looks like Sun has released a patch to solve the error "Assertion: (../lnk/init.cc, line 1032)" but I can't find it for solaris 5.9 + Studio 11 Regards Xavier ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La FIMAT et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither FIMAT nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

4 3

[serialization] Problem with diamond hierarchy
by Loïc Joly 31 Jan '06

31 Jan '06

Hello, I have a class hierarchy that looks like this : class A {/**/}; // Polymorphic class B1 : virtual public A {/**/}; class B2 : virtual public A {/**/}; class C : public B1, public B2 {/**/}; class D : public C {/**/}; In C, I define the serialize function like this : template <class Archive> void C::serialize(Archive &ar, const unsigned int version) { BOOST_SERIALIZATION_BASE_OBJECT_NVP(B1); BOOST_SERIALIZATION_BASE_OBJECT_NVP(B2); // serialize fields specific to C } When I try to serialize an object of type C, it works just fine. However, when I try to serialize an object of class D, it fails. I have not yet tried to reproduce this problem in fully a toy example, but I'm going to do so ASAP. I'm using VC++8.0. When I try to debug the system, here is the information I get : At one time, I'm in save_pointer_type<xml_oarchive, A*> polymorphic::save in line vp = serialization::void_downcast(*true_type, *this_type, &t); At that place, when I inspect t, all is fine (especially the vfprt). Then I go in this void_downcast, where I can't inspect data, since the pointer has been cast to a void type. Next time I gets back some type info, i when calling : void_downcast( const extended_type_info & derived_type, // D const extended_type_info & base_type, // A const void * const t, bool top) In this function, I get an iterator at some point void_cast_detail::void_caster_registry::const_iterator it; That has the following content: Derived == D, Base == C. Then, it calls void_caster_primitive::downcast with those informations, where it calls boost::smart_cast<const Derived *, const Base *>( static_cast<const Base *>(t) // Derived == D, Base == C However, in this function, declared that way: template<class T, class U> T smart_cast(U u); If I try to look at the content of u, it seems totally broken. For instance, the vfptr contains values such as 0xcdcdcdcd 0x00000000 ... From my (limited) understanding of C++, casting from A* to void* and back to C* is not supposed to work, but I'd like some confirmation. Does someone have any idea about this problem, and if there is a workaround ? Best regards, -- Loïc

2 3

Registry-Listener Pattern
by Dean Michael C. Berris 31 Jan '06

31 Jan '06

Good day, On some of my free time, having been working a few months (close to a year) on an in-house framework for a company here in the Philippines, I have tried actually creating a Registry-Listener pattern template which might be useful to other people. This implementation is from the ground up mine, and in no way being used by my client. I had been contemplating already for a long time whether the boost library is the right place for me to bring forward this implementation, or whether it should be a standalone (open source) project in itself. Having the pattern really not for standards compliance, I however have found a lot of applications where the abstraction between the actual implementation based on variations on the input to be recurring enough and worthy of a template implementation. Though this template implementation was supposed to be sub-classed and used as the base classes for specific listener types, I'm not really sure if it's "boost material" -- however, I'm taking a chance at it and will be offering this (initial) implementation to the Boost community. My question however would be where I should be uploading the files, and whether there are any conventions and regulations that need to be followed for the library to be included maybe under the Boost libraries. I've been on the list (lurking) for a while already, and pointers regarding newbie Boost developer concerns would be most appreciated. Thank you very much and have a nice day! :) -- Dean Michael C. Berris Mobile +639287291459 URL http://mikhailberis.blogspot.com YMID: mikhailberis

2 2

Re: [boost] Serialization and disctintion between eof and end ofarchive
by Oliver.Kowalke＠infineon.com 31 Jan '06

31 Jan '06

Hello Robert, I've the same problem as Maciej. You believe that this problem relies on the streambuf implementation - I think it doesn't. It doesn't matter if you use a buffered streambuf with flushing it or an unbuffered streambuf - the archive blocks in basic_text_iprimitive.hpp, line 80, 'is >> t'. I don't know what do you mean with 'streambuf implementation needs enhancement'? The streambuf reads n bytes from the socket or writes n bytes to the socket as it was requested by its interface. So it reads n bytes from the socket and writes n bytes to the socket as it was passed to the stream which uses the socket_streambuf. It doesN#t make assumptions about the outer context it is used. In the read action it returns 0 if the peer has closed the socket and no more data will be available - so you have to return std::char_traits< char >::eof() in order to indicate the EOF of the stream. If the socket (blocking mode) is still open and you try to read n bytes from a socket you will be blocked until n bytes can be read from the socket (peer has written at least n bytes to the socket). I could verify that boost::archive blocks because it tries to read more bytes than available. The client writes an archive with 29 bytes (printed out from the streambuf - value was '22 serialization::archive 3 0') to the socket in one operation. On the peer socket the archive tries to read 4096 bytes from the socket (also printed out from streambuf operation) in one call. So this must be block because you can only read 29 bytes from the socket! As you can see this problem is raised by the boost::archive. Oliver

1 0

[compressed_pair] Broken compilers workaround suggestion
by Robert Kawulak 31 Jan '06

31 Jan '06

Hi, Recently I've discovered that Digital Mars compiler (version 8.42n) has problems when compiling boost::compressed_pair. The problem is in the member functions first() and second() in cases when compressed_pair is derived from either first or second type. To fix the problem, *this must be explicitly converted to the return type, so the functions would look like this: second_reference second() { return static_cast<second_reference>(*this); } instead of the way they're implemented now: second_reference second() { return *this; } If the problem wasn't mentioned before, then I'd suggest to fix it. The solution is quite easy to introduce and AFAICT has no negative side effects. Does anybody object to this? The changes have to be done in the following lines: 158, 159, 203, 204, 244, 245, 247, 248, 280, 281 of boost/detail/compressed_pair.hpp file. Also, the comment in line 256 is out-of-date after changes made by John Maddock in 25 Jan 2004: // Note does not actually store an instance of T2 at all - // but reuses T1 base class for both first() and second(). This could be removed as well. Best regards, Robert ---------------------------------------------------------------------- Kliknij po wiecej! >>> http://link.interia.pl/f18ed

7 23