- Boost - lists.boost.org

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

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:<02e501c625d4$0804e1f0$6507a8c0@pdimov2>... > David Maisonave wrote: > > > On my test, reference-link is over 25% faster than reference-count > > logic for initialization. > > This only matters if the only thing you do is initialize. This is > best-case > scenario for reference-linked for both performance and memory use. How often > is that the case in real code? > > Then there are thread safety, custom deleters, weak_ptr support, > enable_shared_from_this, and competition from intrusive_ptr on the low end, > which should be even faster in ST mode. > One of the main points of doing reference logic, is to increase performance during initialization. So this is a key test when testing reference logic performance. The test showed a big difference in initialization and in copying containers of smart pointers. There was very little difference when iterating through the container, but a big difference when copying the container of smart pointers. The smart_ptr supports thread safety, custom deleters, and intrusive_ptr. I'm not sure how important weak_ptr's are, and I have not seen a good case for their requirement. I'm open minded, and I would like to see someone put a good argument for their required usage. What is ST mode? And what exactly is enable_shared_from_this?

1 0

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

30 Jan '06

"Daniel Wallin" <dalwan01(a)student.umu.se> wrote in message news:<drkmls$kb5$1(a)sea.gmane.org>... > David Maisonave wrote: > > The only advantage I found with reference-count is that it requires > > less memory. Other than that, in my test it performs the worse when > > compared to reference-link and reference-intrusive. > > I don't understand why reference-count was picked instead of reference-link > > for the boost::shared_ptr > > 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. 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% I guess this could be considered not enough of an advantage if 22% to 30% extra efficiency is not that important. But some developers would differ.

4 3

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

30 Jan '06

"Sam Partington" <sam.partington(a)gmail.com> wrote in message news:<546fdb840601300802v13f0e09cg3618caf96a4ea960(a)mail.gmail.com>... > > You can avoid having to make the implementation thread safe by > > making the pointee thread safe. This can be done by using an > > intrusive lock. > > How? The FAQ is talking about making the reference count thread safe, > not the object thread safe. > > class A { }; > > void f(ptr<A> a) { } > > int main() > { > ptr<A> a(new A); > boost::thread t(boost::bind(f, a)); > } > > Which thread does the deallocation of a? What protects both of them > from trying to deallocate it at the same time? > > > I guess this could be considered not enough of an advantage if 22% > > to 30% extra efficiency is not that important. But some developers > > would differ. > > Until there is a thread safe implemenation then any performance > comparisons are irrelevant because you're comparing apples and > oranges. Thanks for the clarification Sam, but I know what the FAQ is talking about. I stand by my statement. The smart pointer can be made thread safe by using an intrusive lock. The idea behind this, is if you lock the pointee, before trying to access the smart pointer's data members, than you have a thread safe smart pointer. With the smart pointer I'm proposing, you can have a 10 reference link smart pointers, and if one of them has the pointee locked, than the others will not be able to access their data members until the pointee is unlocked.

1 0