August 2004 - Boost - lists.preview.boost.org

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

11 Aug '04

Stefan Slapeta wrote: >>Robert Ramey wrote: >> >> CW two-phase lookup threw me for a loop. What I meant was it left me dazed and confused. >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. Please could you mail me a particular test case or code >sequence which you think was failing because of two-phase lookup issues? Is this something that can be turned off/on at will for intel? And/or other compilers? I use boost-build defaults as much as possible. Hmmm - maybe two phase lookup should turned off by default for boost? This experience has convinced me that two phase lookup is a bad idea. A couple of months ago I tested the library with intel 8.0 . After resolving one anomally (related to typeid of const/non-const) things compiled and everything passed. My 30 day license exprired so I haven't been able to test here since. When I went to cw pro version 9, I had the tests for non-intrusive serialization failed. This uses function template overload. This turned out that to be the same problem I had with Commeau. After much effort I came to understand the issue. I made adjustments to address this. This resulted in more changes than I wanted to make at this point. Oh well. It has also resulted in a slightly more complex explanation of how to use non-intrusive serialization portably. This works but it offends my sense of aesthetics. On the other hand, It did force me implement ADL for finding overloads. This was the one feature that had been asked for but hadn't implemented. I didn't see a way to do it without causing a two large ripple effect through the API, docs, etc. Martin Ecker showed me how to fix this so now we have ADL for overloading serialize functions. So I would think that if Intel implements two-phase lookup, things would have failed much sooner. On the other hand, during my 30 test trial of Intel 8.0 I got two?! Notices for updates. It wouldn't surprise me if there are multiple versions named Intel 8.0. In spite of all the pain I've experienced in porting code like this to all such platforms. I've come to appreciate the general high quality of these compilers. They all have quirks and errors. But now having had to delve much deeper into details of C++ than I ever had to before, I have a much better appreciation of how difficult is has to be to write something like this. I think C++ would be much improved if the standards committee would be a little more conservative about "mandating" untested features. Sometimes I wonder if its not just a group of really smart guys sitting around a table thinking up the hardest stuff they can for other people to implement - Sort of like the marketing department. I've had huge difficulties traced to arcane areas of C++ that are really too hard to understand for the normal person. Anyway - one man's two cents. Robert Ramey

2 1

"blank permission" in license_info.html
by Jonathan Wakely 11 Aug '04

11 Aug '04

http://boost.org/more/license_info.html says "blank permission" should be "blanket permission" jon

2 1

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