- Boost - lists.boost.org

Documentation copyright in Boost
by Jonathan Brandmeyer 11 Aug '04

11 Aug '04

John Maddock's prodding with regard to copyright notices in Boost's sources got me thinking about the copyright notices in its documentation. Currently, some docs have a copyright notice using the Boost Software License, some have a permissive license other than the BSL, and some just say "Copyright (c) DATE AUTHOR". I haven't done a detailed survey; that observation is just based on a random browsing of the Boost docs. I generally believe in using the same copyright license for the documentation as the one used for the software, at least in the context of Free/Open Source Software. That may or may not be entirely appropriate considering the BSL's particular language concerning compiled software. Has this issue been raised in the past? Was there a consensus? If not, what do you think about it, now? Thanks, Jonathan Brandmeyer

2 2

[boost.thread] Allowed lifetime of a thread?
by Roland 11 Aug '04

11 Aug '04

While considering various ways to get rid of the remaining intentional memory leak of the tss implementation, I came upon the following question: How long may a thread access it's tss storage anyway? I did not find anything in the documentation about the topic. Looking into the destructor of thread_specific_ptr reveals ~thread_specific_ptr() { reset(); } which in turn implies, that the thread(s) which are using it should have already terminated, when the main thread has exited (called its dtor list). Now when one has control over the lifetime of the threads this poses no problem, since they simply need to be terminated before main() ends. The situation is completely different when writing a piece of code (a library) that has to use tss and shall work with foreign threads too. The library writer in this case has no control over the lifetime of the threads (native or not). So I am wondering if it is possible to refine the inner workings of the thread_specific_ptr without changing the interface to account for these cases? Perhaps only a static pointer should be embedded that points to dynamic memory that will not be touched by destructor calls, but controlled in lifetime be real thread-detachements. (The last one frees everything which is really global.) How is the situation for other libraries, say e.g. pthreads? Are they allowed to run after main ended? Or is this simply considered bad programm behaviour? Any comments? Roland

2 3

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

11 Aug '04

David Abrahams wrote: >> This seems _very_ strange to me because two-phase lookup should also >> be turned on for Intel 8, so I don't understand why all the tests pass >> on this compiler. >Intel for windows has the "MSVC bug compatibility" switch turned on. >On linux it actually detects 2-phase problems, except insofar as it's >trying to emulate GCC bugs :( Ahhh - mystery solved - thanks for that. Robert Ramey

1 0

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