- Boost - lists.boost.org

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

[xpressive] Warning from one compiler but not another.
by Dick Bridges 31 Jan '06

31 Jan '06

One of our compilers is giving a warning and I cannot understand why. Maybe I'm missing a #define somewhere? I don't understand how the compiler got past the BOOST_MPL_ASSERT_RELATION macros to even "see" the offending line. Given the following code: #include <boost/xpressive/xpressive.hpp> using namespace boost::xpressive; int main(int argc, char **argv) { sregex re_ = (*_ >> "CALL" >> *_ >> "CONNECTED" >> *_); return(0); } gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) compiles and links successfully with no warnings. On the other hand, our [arm-softfloat-linux-gnu-gcc (GCC) 3.3.3] compiler gives the following warnings: Building file: ../main.cpp arm-softfloat-linux-gnu-g++ -D_REENTRANT -DARCH=ARM -I/usr/local/boost_1_33_1 -O3 -Wall -c -fmessage-length=0 -Wno-non-virtual-dtor -omain.o ../main.cpp [snip...snip,snip...snip] ../main.cpp:7: instantiated from here /usr/local/boost_1_33_1/boost/xpressive/traits/cpp_regex_traits.hpp:241: warning: comparison is always false due to limited range of data type /usr/local/boost_1_33_1/boost/xpressive/traits/cpp_regex_traits.hpp:241: warning: comparison is always false due to limited range of data type Finished building: ../main.cpp Building target: parse_warning arm-softfloat-linux-gnu-g++ -o parse_warning main.o Finished building: parse_warning Build complete for project parse_warning Here is the "offending" code: static bool is_newline(Char ch) { BOOST_MPL_ASSERT_RELATION('\r', ==, L'\r'); BOOST_MPL_ASSERT_RELATION('\n', ==, L'\n'); BOOST_MPL_ASSERT_RELATION('\f', ==, L'\f'); 241 ==> return L'\r' == ch || L'\n' == ch || L'\f' == ch || (1 < SizeOfChar && (0x2028u == ch || 0x2029u == ch || 0x85u == ch)); } Thanks for your time. Any assistance you could provide would be greatly appreciated. Regards, Dick Bridges

2 1

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

30 Jan '06

"Larry Evans" <cppljevans(a)cox-internet.com> wrote in message news:<drl99b$n8d$1(a)sea.gmane.org>... > On 01/30/2006 08:24 AM, Larry Evans wrote: > [snip] > > I'll see what I can do and upload the .zip file to boost vault under > > Memory. I'll let you know when with another post. > Just finished upload to boost vault. Thanks Do I have to wait for a while for it to show up? And I assume that once it's updated, the AGE field will change. Is that correct? Which files did you upload new?

2 1

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

30 Jan '06

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:<874q3ld907.fsf(a)boost-consulting.com>... > "David Maisonave" <boost(a)axter.com> writes: > > > "Daniel Wallin" <dalwan01(a)student.umu.se> wrote in message > > news:<drkmls$kb5$1(a)sea.gmane.org>... > > >> It's in the FAQ: > >> > >> http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ > >> > >> Q. Why doesn't shared_ptr use a linked list implementation? > >> > >> A. A linked list implementation does not offer enough advantages to > >> offset the added cost of an extra pointer. See timings page. In > >> addition, it is expensive to make a linked list implementation > >> thread safe. > > > > > > You can avoid having to make the implementation thread safe by > > making the pointee thread safe. > > One of us here understands nothing about the problem. I don't know > that much about threading, but I think I have a grip on this issue at > least. As I understand the problem, if two neighboring shared_ptr's > in a reference-linked chain are destroyed at the same time, they will > be modifying the same pointer values simultaneously -- without a lock > in your case. I don't see how making the pointee threadsafe is going > to help one bit. IMHO, you don't fully understand my propose solution. Please look at the current smart pointer locking method: http://code.axter.com/smart_ptr.h By using intrusive lock logic, you can lock the pointee, and thereby locking all the shared_ptr objects. Here's the smart pointer destructor: inline ~smart_ptr() throw() { m_ownership_policy.destructor_lock_policy(m_type); CHECKING_POLICY::before_release(m_type); m_ownership_policy.release(m_type, m_clone_fct, m_ownership_policy); CHECKING_POLICY::after_release(m_type); } There's similar logic in constructor and assignment operator. This should work on all three main types of reference policies, to include reference-link. Do you understand intrusive logic? You need to fully understand how intrusive logic works, in order to understand the method. > > This can be done by using an intrusive lock. > > > > On my test, reference-link is over 25% faster than reference-count > > logic for initialization. With BOOST_SP_USE_QUICK_ALLOCATOR defined, > > than reference-link is over 30% faster than reference-count logic > > for initialization. I get the above results using VC++ 7.1, and if I > > use the GNU 3.x compiler, than the difference is even greater in > > favor of reference-link logic. > > With the Borland compiler, the difference is about 22% > > Are you claiming that using BOOST_SP_USE_QUICK_ALLOCATOR actually > slows boost::shared_ptr down on all these compilers? Of course not.... When you define BOOST_SP_USE_QUICK_ALLOCATOR, that does not just increase the performance of boost objects. It increases the performance for all object within the translation unit that has the define, and that is using allocators. So even though shared_ptr gets an increase performance boost, the smart_ptr gets an even greater performance boost, which increases the performance ratio. If you have any thoughts, please feel free to inspect and perform the same test using the following code: http://code.axter.com/smart_ptr.h http://code.axter.com/shape_test.h http://code.axter.com/boost_ptr_containers/main.cpp http://code.axter.com/cow_ptr.h http://code.axter.com/copy_ptr.h I welcome inspection and critiques of my work.

3 2

[serialization] Versioning (or lack thereof) in load_construct_data
by Ben Artin 30 Jan '06

30 Jan '06

As far as I can tell, the version number passed into load_construct_data is not actually useful. This conclusion is based (among other things) on the fact that stack_construct (in serialization/detail/stack_constructor.hpp) always calls load_construct_data_adl with 0U for the version argument. This leads me to believe that in the current implementation if I specialize load_construct_data for one of my classes, I can never change it later, as the class version number from the input archive is inaccessible inside load_construct_data. Am I missing something obvious, or is it really the case that versioning doesn't work for load_construct_data right now? Thanks, Ben -- If this message helped you, consider buying an item from my wish list: <http://artins.org/ben/wishlist> I changed my name: <http://periodic-kingdom.org/People/NameChange.php>

2 2

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

30 Jan '06

"Peter Dimov" <pdimov(a)mmltd.net> wrote in message news:<058c01c625d8$b1f98040$6507a8c0@pdimov2>... > David Maisonave wrote: > > > Please look at the current smart pointer locking method: > > http://code.axter.com/smart_ptr.h By using intrusive lock logic, you > > can lock the pointee, and thereby locking all the shared_ptr > > objects. Here's the smart pointer destructor: > > inline ~smart_ptr() throw() > > { > > m_ownership_policy.destructor_lock_policy(m_type); > > CHECKING_POLICY::before_release(m_type); > > m_ownership_policy.release(m_type, m_clone_fct, > > m_ownership_policy); > > CHECKING_POLICY::after_release(m_type); > > } > > > > There's similar logic in constructor and assignment operator. This > > should work on all three main types of reference policies, to > > include reference-link. > > That's what I thought. But if you have support from the pointee, why > not > just use intrusive_ptr? It should be even faster, on all operations, not > just init. Many programs don't need thread logic, and therefore don't require a synchronize smart pointer. For those programs that do require a synchronized smart pointer, the developer may not want to add the extra logic required for intrusive_ptr, and may only want to make the minimum modifications on their target object. In any case, this policy set allows the developer to choose what's the best combination for their requirement.

1 0