- Boost - lists.boost.org

Re:Re: [boost] serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

Howard Hinnant wrote: >> All tests using utf8-codecvt fail. This includes the test for >> utf8-codecvt >> itself. I have come to believe that its an error somewhere in the MSL >> 9.2 >> implementation of the standard library. >If you can send me an independent demo of anything you believe is a >CodeWarrior bug, I would be most grateful. If your demonstration is >depending heavily on boost, a preprocess is usually the best way to go. >If you can minimize the demonstration by eliminating irrelevant code, >that also helps a lot. The test test_utf8_codecvt in the serialization library is pretty minimal. But I'll strip it down to the minimum, verify that it still fails, and send it along. Thanks for helping me with this. Robert Ramey

1 0

[Serialization] Missing CSS file
by Douglas Gregor 11 Aug '04

11 Aug '04

libs/serialization/doc is missing the stylesheet file style.css. Doug

1 0

RE: [boost] Re: true64cxx and toupper
by Rozental, Gennadiy 11 Aug '04

11 Aug '04

> There must be some difference between my test platform and > the one used > to run the regression tests but I have no idea where to start looking. > > Just to be sure I checked with boost 1.30.0 and the test library > compiles ok with the current toolset. > > Markus I made some fixes since run of regression test. I may've helped unit_test_result compilation. As for compiler crash - no idea. Gennadiy.

1 0

CVS update problem: waiting for david_abrahams's lock
by Aaron W. LaFramboise 11 Aug '04

11 Aug '04

For the past few hours, I have been attempting to update my local CVS tree and have been getting the following message midway through the update: cvs update: Updating tools/build/test/project-test3/lib cvs update: Updating tools/build/test/project-test3/lib2 cvs update: Updating tools/build/test/project-test3/lib2/helper cvs update: [05:36:48] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/test/project-test3/lib2/helper cvs update: [05:37:18] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/test/project-test3/lib2/helper . . . The update appears to hang here, repeating that last message periodically. Aaron W. LaFramboise

2 1

shared_ptr improvement proposal
by Tylo 11 Aug '04

11 Aug '04

shared_ptr improvement proposal by T. Lovset --- note: Parts of this may be long-winded and possible obvious to some of you, but I feel it is needed to support the arguments. Let me know what you think. --- I propose a modification to the smart pointer classes. In my opinion, this modification improves the current smart pointer usage in several respects, although it is not completely backward compatible. However, that is also the main purpose of the modification, because as we know, the explicit constructors that take a raw pointer is dangerous in numerous ways. As an illustration, I show a realistic example that violates the smart pointer preconditions in a subtle (and dangerous) manner. As a background, some quotes from the boost "Proposal to Add General Purpose Smart Pointers to the Library Technical Report" (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html) (1) > A common concern, dating back to [Colvin94], is that it is very easy to violate the preconditions > of smart pointer operations. This proposal attempts to systematically eliminate undefined behavior > possibilities as long as the user is manipulating already valid shared_ptr (and weak_ptr) > instances, but using the pointer constructor correctly is still up to the user. And: > - Widespread existing practice strongly favors the unprotected but powerful pointer constructor > approach. (2) > A. General Principles > 1. "As Close to Raw Pointers as Possible, but no Closer" For auto_ptr and shared_ptr, we are familiar with the form: shared_ptr<Widget> smartWidgetPtr( new Widget(a, b) ); The constructor is made "explicit" in order to avoid implicit and unintentional construction of smart pointers, e.g.: void f( shared_ptr<Widget> const & wp ); would without explicit constructors accept f(rawWidgetPtr) with disastrous results. Still, as mentioned, "explicit" does not make up for all misuses. For example, an inexperienced user could try to call f(shared_ptr<Widget> (rawWidgetPtr)) to make it compile. Fortunately, this is quite easy to spot as an error, and therefore "explicit" does it's mission here. But a much more common and subtle problem may arise when converting from raw pointers to smart pointers: class WidgetUtil { public: WidgetUtil(Widget* wp); private: Widget* m_wp; }; WidgetUtil::WidgetUtil(Widget* wp) : m_wp(wp) { ... } Now converting to shared_ptr: class WidgetUtil { public: WidgetUtil(Widget* wp); private: shared_ptr<Widget> m_wp; }; The unmodified constructor still compiles, but the precondition for m_wp is violated. One must therefore pay close attention to the constructors to make sure that they do not take raw pointer as arguments, which initializes smart pointers. In the case of a big class with a mixture of both smart and raw pointer members, the principle of "using the pointer constructor correctly is still up to the user", lays an unacceptable heavy burden upon the user (in my opinion) - especially when it is possible to avoid this problem. Before I move on to the proposal, I'll address another drawback with the current smart pointer implementations: implicit ctor-initialization and assignment to NULL (which is possible with raw pointers) is not supported. This would make things much easier when converting back and forth between smart and raw pointers. It also breaks the principle of "As Close to Raw Pointers as Possible, but no Closer". My proposal makes this possible, and thus making the usage closer to that of raw pointers, without introducing any side effects. [As a side note, Joe Guttman pointed out to me that with the proposed nullptr and nullptr_t, it will be easy to add these features to the current implementations of smart pointers. However, my proposal does not rely on nullptr.] The Proposal ============ Note that this proposal would be beneficial to most smart pointer implementation, including shared_ptr and auto_ptr. Unfortunately, auto_ptr is already in the standard, so it can't be touched. I propose this usage (for shared_ptr): shared_ptr<Widget> wp1 = NULL; shared_ptr<Widget> wp2 = rawptr(new Widget(a, b)); wp1 = rawptr( new Widget(a, b) ); wp2 = NULL; Current shared_ptr usage: shared_ptr<Widget> wp1( NULL ); shared_ptr<Widget> wp2( new Widget(a, b) ); wp1.reset( new Widget(a, b) ); wp2.reset(); Discussion: 1. As wp1 and wp2 should be raw pointer "look alikes", the proposed usage is more intuitive than the current usage, in my opinion, and allows to assign NULL without side-effects. 2. As noted by others [e.g. Andrei Alexandrescu], member functions in smart pointers should be avoided if possible. The reset() function makes it hard to switch between raw and smart pointers, and also allows mix-ups: wp1.reset(), (*wp1).reset(), wp1->reset(). 3. The rawptr() function makes initialization and assignment explicit using an alternative and better syntax, IMO. E.g., you can verify that every shared_ptr owns a valid raw pointer by investigating instances of "rawptr(" in the code. Typically, you want to see: rawptr(new SomeClass(..)). To do this is not easy with the current implementation. You have to search for: a) "shared_ptr<" stack variable constructions of which takes raw pointers as arguments. b) ".reset(" for re-assigning a new raw pointer. Unfortunately reset() is a commonly used name. c) shared_ptr's in class member initiation lists, as mentioned in the example presented. 4. Most importantly, all raw pointers that are assigned to smart pointers must go through the rawptr() function (or rawptr_t<T> type), always making it "explicit". The problem in the example presented earlier, is therefore eliminated. 5. This proposal introduces no additional overhead, as long as the compiler really inline the rawptr() function (the operator new call is dominant by an order of magnitude in any case). 6. The only obvious problem I see, is the backward compability issue, although it still support the "unprotected but powerful pointer constructor approach", with a slightly different syntax. Implementation for shared_ptr ============================= rawptr.hpp (new file): --------------------- namespace boost { template <class T> class rawptr_t { public: explicit rawptr_t(T * p) : px(p) {} T* get() const { return px; } private: rawptr_t& operator=(const rawptr_t&); T* px; }; template <class T> inline rawptr_t<T> rawptr(T * p) { return rawptr_t<T>(p); } } shared_ptr.hpp (diff from boost 1.31.0): ---------------------------------------- *************** *** 109,114 **** --- 123,129 ---- // Borland 5.5.1 specific workaround typedef shared_ptr<T> this_type; + struct null_tag {}; public: *************** *** 117,130 **** typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(): px(0), pn() // never throws in 1.30+ { } template<class Y> ! explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(p, p, pn); } // --- 132,145 ---- typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(null_tag* = NULL): px(0), pn() // never throws in 1.30+ { } template<class Y> ! shared_ptr(rawptr_t<Y> const & w): px(w.get()), pn(w.get(), checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(w.get(), w.get(), pn); } // *************** *** 226,231 **** --- 241,258 ---- } #endif + shared_ptr & operator=(null_tag *) + { + reset(); + return *this; + } + + template<class Y> + shared_ptr & operator=(rawptr_t<Y> const & w) + { + this_type(w).swap(*this); + return *this; + } void reset() // never throws in 1.30+ { *************** *** 235,241 **** template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(p).swap(*this); } template<class Y, class D> void reset(Y * p, D d) --- 262,268 ---- template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(rawptr(p)).swap(*this); } template<class Y, class D> void reset(Y * p, D d) ------------------------------------------------------------ Få din egen @start.no-adresse gratis på http://www.start.no/

6 9

question re VC 8.0
by Robert Ramey 11 Aug '04

11 Aug '04

The test results for the serialization library show a problem with VC 8.0 which for the life of me I can't understand. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudbe kAssociates-bin-boost-libs-serialization-test-test_array_binary_archive-test -vc8-0-debug.html The corresponding code is below. If someone has any insight here I would love to here it. FWIW - no other compiler complains. - and I can't see anything wrong with it. If it's a bug - how do I work around it? Thanks in advance. Robert Ramey namespace boost { namespace archive { namespace detail { template<class Archive, class T> class iserializer; template<class Archive, class T> class oserializer; } // namespace detail } // namespace archive namespace serialization { // forward declarations namespace detail { template<class Archive, class T> struct member_saver; template<class Archive, class T> struct member_loader; } // namespace detail // use an "accessor class so that we can use: // "friend class boost::serialization::access;" // in any serialized class to permit clean, safe access to private class members // by the serialization system class access { public: // grant access to "real" serialization defaults #ifdef BOOST_NO_MEMBER_TEMPLATE_FRIENDS public: #else template<class Archive, class T> friend struct detail::member_saver; template<class Archive, class T> friend struct detail::member_loader; template<class Archive, class T> friend class boost::archive::detail::iserializer; template<class Archive, class T> friend class boost::archive::detail::oserializer; template<class Archive, class T> friend inline void serialize( Archive & ar, T & t, const BOOST_PFTO unsigned int file_version ); template<class Archive, class T> friend inline void save_construct_data( Archive & ar, const T * t, const BOOST_PFTO unsigned int file_version ); template<class Archive, class T> friend inline void load_construct_data( Archive & ar, T * t, const BOOST_PFTO unsigned int file_version ); #endif

6 8

Boost.Threads static linking status report
by Michael Glassford 11 Aug '04

11 Aug '04

Based on recent work and discussions here, I've checked in changes that implement tss cleanup in statically linked Boost.Thread on Win32 (for VC++ only, so far). I've also used the opportunity to rewrite the rest of the Win32 tss cleanup code and update it to use the Boost copyright. In the process, I eliminated threadmon.cpp, threadmon.hpp, and pe_tls.cpp. They've been replaced by tss_hooks.cpp, tss_hooks.hpp, tss_pe.cpp, and tss_dll.cpp. As suggested by Roland in his posted sample code, the default for VC++ linking of Boost.Threads is now static linking. I also changed all non-Win32 platforms to use static linking by default. I realize this is very late in the regression testing process to make these changes, but it seemed too good an opportunity to miss. If you disagree, please let me know. If the changes cause problems or it turns out to be a wrong decision in people's opinions here, I'll back the changes out quickly until after the release. In any case, many, many thanks to Aaron and Roland for working out this solution and making static linking possible on Win32. Mike

5 8

Sumptin' happened
by Victor A. Wagner Jr. 11 Aug '04

11 Aug '04

I don't know who did what to whom, but my regression test took over 8 hours last time. and now there are some new failures in VC7.1 I started it manually since it had missed the scheduled time to restart and looked at the log from cvs.... seems there are a lot of corrected files this time also. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

Rene, Here is my assessment of the status of the serialization library as it relates to the Metrowerks compiler. all versions of CodeWarrior C++ CW two-phase lookup threw me for a loop. It took me long time to really understand this. Now that I do, I'm strongly convinced that it's a really bad idea. I don't know if its true - but I think I heard that it was implemented in order to make template export work - which looks like another bad idea to me. Oh well. CWPro 9.2 - my home copy All tests using utf8-codecvt fail. This includes the test for utf8-codecvt itself. I have come to believe that its an error somewhere in the MSL 9.2 implementation of the standard library. CWPro 8.3 - your machine The tests which serialize arrays fail - I haven't looked at this too carefully. There might be an issue regarding references to arrays decaying into pointers. Borland also has this problem. test_diamond fails with this compiler - I haven't figured out why it fails only here. CWPro 8.3 and 9.2 Hashed set serialization fails to produce the correct result at runtime. I haven't looked real closely at this. Since its particular to this version of CWpro I suspect it might be a library problem. I don't know how many standard libraries include support for hashed sets so I don't know for a fact that other compilers are in fact testing this. serialization of polymorphic derived pointers. Forward declaration method. I had reorganize code in archive_pointer_oserialize etc and use MSVC specific key words (used by BOOST_FORCE_INCLUDE) in order to get certain things to instantiate static variables whose pre-runtime construction is necessary for this to function. This seems like a bad idea as CW supports lots of other platforms. I tried every alternative I could find but wasn't able to find a better one that worked. "Export" functionality suffers from a variation of the above which I have not been able to overcome. So tests which use export fail. I've spent even more time on this - without success. It seems to me that CW is too smart in eliminating code that it "knows" it won't need. Actually I'm not even sure it's a CW issue. Comeau has the same symptom. That would suggest it's another manifestation of the problem I'm having comprehending two-phase lookup. CW < 8 I believe that these versions will pass 100 % Robert Ramey

4 5

Lock unification (shared vs. upgradable)
by Bronek Kozicki 10 Aug '04

10 Aug '04

Is there any reason for distinction between shared lock and upgradable shared lock? I mean - obviously updgradable shared lock can be upgraded to exclusive one, but do we need separate type for this? What's rationale behind this distinciton? I can easily imagine design (and implementation) where every shared lock is also upgradable one, if it's mutex type support upgrade operation. Under such design one can upgrade shared lock only if it's the only (currently locking) lock on synchromization object (supporting such transition). Implementation of such mutex could be very similar to semaphore (or just using semaphore, if present on platform). Here are some simple use cases: some_mutex_type_not_supporting_shared_locks m1; shared_lock<some...> l1(m1); // compilation error some_mutex_type_fully_supporting_shared_locks m2; shared_lock<some...> l2(m2); // ok exclusive_lock<some...> l3 = l2.try_upgrade(); // ok, non-blocking some_mutex_type_with_limited_support_for_shared_locks m3; shared_lock<some...> l4(m3); // ok exclusive_lock<some...> l5 = l4.try_upgrade(); // compilation error exclusive_lock<some...> l6 = l4.upgrade(); // ok, blocking some_mutex_type_with_minimal_support_for_shared_locks m4; { shared_lock<some...> l7(m4); // ok exclusive_lock<some...> l8 = l7.try_upgrade(); // compilation error exclusive_lock<some...> l9 = l7.upgrade(); // compilation error } exclusive_lock<some...> l10(m4); // ok B.

6 25