- Boost - lists.boost.org

RE: [boost] Re: Perfect moving (almost)
by Powell, Gary 12 Feb '04

12 Feb '04

-------------------------------- If Rani is right about the reference binding I'd like to find some way to library-ize this idiom, so your "ref" converting constructor will come in handy. BTW, you don't need the other "ref" constructor anymore. -- Dave Abrahams ---------------------------------------------------------------------- Ok, reusing Andrei's mojo name I've got the following working: template <class T> class mojo { protected: struct ref { template<class T2> ref(T2 *rhs) : p(rhs) {} // works if there is a conversion. template<class T2> ref(mojo<T2> *rhs) : p( static_cast<T *>(rhs) ) {} // works if there is a conversion. template<class T2> ref(mojo<T2> &rhs) : p( static_cast<T *>(rhs.p) ) {} // works if there is a conversion. T * p; T *operator->() const { return p; } T *operator&() const { return p; } }; mojo() {} // intended to be derived from. public: // Move stuff operator ref() { return ref(this); } }; struct X : public mojo<X> { .... // non-const rvalue X(mojo<X>::ref rhs) : id(++cnt) , owner(rhs->owner) { std::cout << "MOVE X#" << id << " <== X#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } .... }; struct Y : public X, public mojo<Y> { .... // non-const rvalue Y(mojo<Y>::ref rhs) : X ( &rhs ) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE Y#" << id << " <== Y#" << rhs->id << " owner = " << std::boolalpha << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; struct V : virtual public X, public mojo<V> { .... // non-const rvalue V(mojo<V>::ref rhs) : X( &rhs) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE V#" << id << " <== V#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; same for class W. (virtual inheritence) struct U : virtual public V, virtual public W, public mojo<U> { .... // non-const rvalue U(mojo<U>::ref rhs) : X( &rhs ) , V( &rhs ) , W( &rhs ) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE U#" << id << " <== U#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; And it all seems to work correctly. IMO it's not too bad of a "library" module. In any case I like using the operator->() as you can stop referencing the pointer "ref.p". And I chose operator &() but perhaps a "get() member fn of mojo is the right thing to do. As to whether to call it mojo or not...well I didn't have another class name in mind. If you don't have mulitiple inheritence you don't have to specify mojo<Type>::ref, so that's nice as well. Anyway I saw Bjarne's call for items on the list, and IMO, this topic deserves it if nothing more than to clarify that its OK. -Gary-

2 1

RE: [boost] Re: Perfect Forwarding (almost)
by Powell, Gary 12 Feb '04

12 Feb '04

> > I must be dense but I'm not seeing how a move function would give us > > the right type. > > > > template<class T> > > ??? move(T &) > > {... } > > > > X( move (*rhs.p) ) // T is a Y > > // calls X copy if move returns T *. > > > > and we need > > > > X ( X::ref) // and X::ref only takes a X * and X::ref > private to X. > > > > What am I missing here? > > That ref doesn't need to be private in X? > > template<class T> rvalue_ref<T> move(T&); > Ok, but then class X has X (rvalue_ref<X> &rhs) Which IMO is no better.. but each to their own. > > ========================================== > > > >>All in all > >>I like it better than the MOJO soln which IMO was much more > >>invasive. > > > > > > What about the MOJO approach seems more invasive to you? > > =========================================== > > Gary > Well you need to modify both the functions you use > and the class. > > And the class requires more modification. > > It's only more modification because you added a whole lot of > assignment > operators, it's not like the generated one will do the right > thing with > the new approach. > > > // Special return type from an object to use it.... > > // test with binary operator + > > ::mojo::fnresult<Y> operator +(Y lhs, Y const &rhs) { > > return lhs; // do the addition here > > } > > > > vs with move.cpp, no special type necessary.... > > Y operator + (Y lhs, Y const &rhs){ > > return lhs; // do the addition here. > > } > > fnresult is only used to work around the rvalue to const& binding > problem. I'm not sure I understand what Rani has been saying, but it > seems like whatever applies here would apply to Mojo as well. > So AFAICT: > if it works with Dave's code, it should work with Mojo. I > might as well > be wrong though. > I think that without using Dave's approach to removing the const T & constructor you have to have all these other MOJO types. Dave's approach does the right thing for non const r-value's returned by functions. Including the operator=() stuff. Without a special Mojo type mojo does not. The beauty of move.cpp is that you only have to modify the class not the functions which you may not have control of. If the question is whether to use inheritence to gain move semantics, I think I answered that already, and it works pretty well. What fails for both of them is that the const &T contructor has to be visible to the compiler even if its not called or used. And whether that is the correct action is the current point of discussion. Yours, -Gary- PS Sorry about the quoting, I dislike the ">"'s with a passion but this email has them for you.

3 2

Re: Units libraries.,.. (long reply)
by Dan W. 12 Feb '04

12 Feb '04

Haven't been around in a while, I was just checking back to the units threads and saw a bit more discussion 'bout adding temperatures, date and time, absolute vs. relative quantities. Now I suddenly saw the light: "absolute" is a relative term... 0.5f * pun_intended(). I will prove this once and for all time with a simple example of a mechanical drawing. If you've been procrastinating setting a monospaced font for viewing messages, procrastinate no more: ____________ V0 = 000 ("datum" line) | __ | / \ | | | -.- V1 = 150 | \__/ | | __ | / \ | | | -.- V2 = 450 | \__/ | | __ | / \ | | | -.- V3 = 750 | \__/ |____________ V4 = 900 (dimensions are in mils (thousands of an inch) ) assert( V4 - V3 == V1 - V0 ); // no problemo assert( V3 - V2 == V2 - V1 ); // no problemo assert( V1 + V2 + V3 >= V4 ); // uhhhh....??? In other words, dimensions that are all measured to the same edge are "absolute" relative to each other. (See I'm no punster?) So far so good. Now, what happens if I have... a = V2 - V1; b = V3 - V1; //NOT V3 - V2, note... Both we might call "relative", since they are both differences between absolutes, right? I should be able to add them right? WRONG!!! assert( a + b >= b ); // DOH!... a and b are both measured from V1, and therefore, relative to each other, they are, again, you guessed it, "absolute". In other words, forget the whole subject. I regret I brought it up in the first place. Leave it for the PhQS (Philosophical Quantities Library). Cheers!

1 0

Mail Transaction Failed
by kevlin＠curbralan.com 12 Feb '04

12 Feb '04

The message contains Unicode characters and has been sent as a binary attachment.

1 0

RE: [boost] Re: Perfect Forwarding (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

Nice. I think we'd implement a "move" function which could handle that explicitly in any real implementation: Y(ref rhs) : X( move(*rhs.p) ) // <== here , id(++cnt) , owner(rhs.p->owner) { std::cout << "MOVE #" << id << " <== #" << rhs.p->id << std::endl; rhs.p->owner = false; assert(owner); } ========================================== Gary > Thank you! I must be dense but I'm not seeing how a move function would give us the right type. template<class T> ??? move(T &) {... } X( move (*rhs.p) ) // T is a Y // calls X copy if move returns T *. and we need X ( X::ref) // and X::ref only takes a X * and X::ref private to X. What am I missing here? ========================================== > All in all > I like it better than the MOJO soln which IMO was much more > invasive. What about the MOJO approach seems more invasive to you? =========================================== Gary > Well you need to modify both the functions you use and the class. And the class requires more modification. class Y : public ::mojo::enabled<Y> { ..... Y &operator=(Y const & rhs) // source is a non const lvalue { using ::std::swap; Y tmp(rhs); tmp.swap(*this); return *this; } Y &operator=(::mojo::temporary<Y> src) // source is a temporary { src->m_ptr.swap(m_ptr); src->release(); return *this; } Y &operator=(::mojo::fnresult<Y> src) // source is a fn result { return operator=(::mojo::temporary<Y>(src)); } ..... }; // Special return type from an object to use it.... // test with binary operator + ::mojo::fnresult<Y> operator +(Y lhs, Y const &rhs) { return lhs; // do the addition here } vs with move.cpp, no special type necessary.... Y operator + (Y lhs, Y const &rhs){ return lhs; // do the addition here. } I have source code that does a similar set of tests with mojo.h as I did for move.cpp if you want to look at it. Yours, -Gary- powellg(a)amazon.com

2 1

RE: [boost] Re: Perfect moving (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

One other thing that makes writing base class and derived classes easier is to add this to the ref struct class X { .... private: struct ref { ref (X *rhs) : p (rhs) {} template<class T> // new ref (T *rhs) : p(rhs) {} // compiles if T is derived from X. X *p; }; ..... }; Then in the derived class you can call: class Y : public X { .... Y(ref rhs) : X (rhs.p) // no cast needed to call X::ref , id(++cnt) , owner(true) { .... } .... }; Anyway the more I play with this the better I like it. Yours, -Gary-

2 1

RE: [boost] VTL question (sorry if this is slightly off-topic)
by Powell, Gary 11 Feb '04

11 Feb '04

Hello, I was reviewing the View Template Library (VTL) - see http://www.zib.de/weiser/vtl/ ... and have a few questions regarding Views as applied to STL Maps. I was also wondering if Boost was planning to eventually provide a VTL-like framework? ---------------------------------- Gary > Yes, I'm planning on using the new Iterator Adaptors and converting the VTL library to use boost. --------------------------- I'm looking for a type of View that provides read-only access to an STL map, with only const iterators, but also provides limited insertion and removal access as well (as shown below): This new limited View-like map will only allow clients to iterate using const iterators, and also provides only one public insert(const key&) and one erase(const key&) method. These insert and erase member functions need to be implemented as "Template Method Functions", as follows: (see Design Patterns) * Note: these are shown using the latest SGI STL implementation (i.e., the _M_t.insert_unique and _M_t.erase calls) virtual bool preInsert(const value_type&) { return true; } pair<iterator, bool> insert(const value_type& x) { if(preInsert(x) { return _M_t.insert_unique(x); } return make_pair(end(), false); // make compiler happy } virtual bool preErase(const key_type&) { return true; } size_type erase(const key_type& x) { if(preErase(x) { return _M_t.erase(x); } return 0; // make compiler happy } The preInsert and preErase methods are virtual Hook Methods, and derived classes override these to add behavior to the (non-virtual) insert and erase functions.. Another nice addition to this map view would be a const _Tp& operator[](const key_type& k) const function, implemented something like this: const _Tp& operator[](const key_type& k) const { const_iterator i = lower_bound(k); if(i == end() || key_comp(k, (*i).first)) // if i->first is >= k throw SearchError(k); return (*i).second; } * Note: this simple implementation assumes that the key can be converted to a string in the constructor of the SearchError exception object. I have at least three Manager-like (Mediator) classes that can use this pattern (i.e., derived from this Map View class) as well as others that need a vector view with a similar filtered design... ---------------------------------------------- Gary > If you are asking me to write this code, well I'm not likely to get around to it. However I'd be glad to review it as an addition to the library. We generally stayed with the STL model of no virtual functions. In the meantime you might like to look at the Iterator Adaptor library and generate your own special view container. -Gary-

2 1

Re: [BGL] Interest in a random-path algorithm.
by Cromwell Enage 11 Feb '04

11 Feb '04

Oh, yeah, I forgot to mention you could use the random path algorithm, too. And thanks for the credit! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

RE: [boost] Perfect Forwarding (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

Just because I like this sort of stuff, I added a test case with 1 level of inheritence, and it works pretty well. There is a minor amount of trickiness to get the derived class to call the right base class constructor. Just need to remember to use the ref.p. All in all I like it better than the MOJO soln which IMO was much more invasive. (I still like the core soln of adding && to indicate you are taking a move reference though, seems to be less error prone to code IMHO.) tested only on gcc 3.22 (2.93 fails miserably.) Anyway "cool" Dave! Yours, -Gary-

2 1

RE: [boost] Re: future of boost.threads
by Glen Knowles 11 Feb '04

11 Feb '04

From: David Abrahams [mailto:dave@boost-consulting.com] >> Of course you cannot portably pass all exceptions, but you may be able >> to pass all the ones that use standard types. > >And what if the std library or somebody else throws exceptions >*derived* from the standard types? If it is not a recognized corba exception what the ACE TAO does is eat it with a catch(...) and then throws a corba system exception on the other side. Glen

13 35