- Boost - lists.boost.org

any smart pointer alternative suggestions?
by Trey Jackson 12 Feb '04

12 Feb '04

All, I'm loving the shared_ptr class, however we have one issue that doesn't seem to be addressed by any of boost's smart pointers, and I'm looking for a work-around/alternative. Any help? The issue is that the smart pointers assume the pointer type to be 'T*', which is fine on a 32-bit system, but means that we get a near doubling of run-time size on our application when we move to a 64-bit application. As a result, we're using the standard technique to have a custom heap, and use our own 'pointers' into that heap that are smaller (typically 32-bits). But of course our ClassOnHeapPtr type does not match a 'ClassOnHeap *', so a boost::shared_ptr<ClassOnHeap> won't work. Are there any other libraries you boosters would recommend? thanks for any info... TJ -- Trey Jackson tjackson(a)ichips.intel.com "This is gonna cost me." -- Homer

5 5

Passing value safely to functions
by Michael D. Borghardt 12 Feb '04

12 Feb '04

This started with looking at sign/unsigned interfaces and how to handle range problems. Now this looks to me to handle any numeric conversion problems. Comments, and criticisms welcome. #include <boost/numeric/cast.hpp> template<typename Target> class numeric_class { public: template<typename Source>numeric_class(numeric_class<Source> &s) { value_ = boost::numeric_cast<Target>(s); } template<typename Source>numeric_class(Source s) { value_ = boost::numeric_cast<Target>(s); } numeric_class(Target s) { value_ = s; } template <typename Resultant> operator Resultant() { return boost::numeric_cast<Resultant>(value_); } operator Target() { return value; } private: Target value_; }; void Bar(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here } numeric_class<float> Foo(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here return numeric_class<float>(ul); } int main () { try { float f = 5.5; numeric_class<unsigned long> ul(f); char c1 = ul; // function interface converts float to unsigned long AND checks to make sure it is in range Bar(f); // function interface converts char to unsigned long AND checks to make sure it is in range // return float that is in range f = Foo(c1); // if we get here we have a valid f } catch(std::exception const &ex) { std::cerr << "EXCEPTION: " << ex.what() << "\n"; } return 0; }

1 0

STL compatible tables
by Arkadiy Vertleyb 12 Feb '04

12 Feb '04

Hi all, I am re-posting this message in hope that the lack of responce is somehow related to incorrect moment I chose for the original post (just hours after 1.31.0 was released). Please indicate if you have any (potential) interest in this library. Thanks, Arkadiy ============================================= Dear Boosters, A while ago we introduced RTL the Relational Template Library a lightweight facility to create relational tables and perform relational operations on them. The main concept RTL operates with is a relation, which has two types of models: tables and operators. Tables can store, in a type safe manner, fields of any types that satisfy requirements imposed by a typical STL container. Operators store references to their arguments, and produce data on the fly. Both provide iterators that can be used in STL algorithms. Any relation (operator or table) can serve as an argument to yet another operator, thus forming an arbitrary complicated expression tree. A relation has a sort order, which is calculated at compile time based on the sort order of its arguments. Range queries are available, based on this sort order. RTL allows to index any relation, which again can be either a table or a relational operator. In this sense our indexing models the ORDERED BY feature, provided by SQL. Therefore a relational expression can contain any number of indexes, used to re-sort tuples to better suite a particular query or queries. The March issue of C/C++ users journal will contain our article about RTL, where we described the library in more depth. This article reflects the state of the library as of about a year ago. NEW FEATURES ============ This time we are offering a significantly enhanced version of the library. The main addition is the TRANSACTION facility, that allows for synchronized updates to one or more tables. The additional very powerful (in our opinion) benefit is the possibility of incremental index update. When a table is changed, all the indexes that depend on this table get invalidated, and need to be updated. RTL takes care of this by calculating deltas on each index, and applying only necessary changes incrementally. We also modified the library interface to use MPL sequences instead of our proprietary type list implementation, and replaced all our meta-programming code to also make use of MPL. RTL allows the user to choose between available table implementations, as well as define new ones. The current in-stock implementation is based on std::vector, and therefore is most appropriate when the updates dont happen too often. We also experimented with indexed_set library to define a set-based implementation. Since the indexed_set is not a part of boost yet, we do not currently supply this implementation. However we do have it, and if anybody has immediate interest, please let us know well make it available (you will have to download the indexed_set library). We struggled to support VC6 up to the last moment, when some of our tests failed to build with Boost release candidate 2. The problems are with quantitative limitations we are getting ISO, and have to brake down our tests in smaller units. Since Microsoft no longer supports this compiler, we also decided to stop supporting it (we may re-consider if there are significant objections). The library has been tested with VC7.1 and GCC 3.3. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip As always, we are looking forward to any feedback. Arkadiy vertleyb(a)hotmail.com Dmitriy dmitriy_arapov(a)hotmail.com _________________________________________________________________ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx

6 10

Boost Test Framework - log and report files
by "Kåsa, Daniel Roy" 12 Feb '04

12 Feb '04

I have just downloaded the latest release of boost so that I could start using the Test Framework. I am part of a fairly large project working on complex software. My project feels as though the boost test framework is beginning to become more mature and we interested in applying it to our test procedures. I have been working on a prototype test environment for my project using the test framework and I have come across some minor problems: 1. I need to have the test log and report written to two separate files in xml format. (It would be nice to have a DTD of both xml formats) I did this by instructing the framework with the command line argument: --output_format=XML. Now that I had both the log and result report in XML format I needed to create two file streams to redirect the output of them to each their own file. This was easy to achieve with the log using the set_log_stream method, but not so trivial with the result report. Calling the singleton of the result report before the test framework has initialized my code first calls a null pointer crashing the test. How should this be done? The documentation states that the interface of the unit_test_result does not need to be used directly, but in my case where I want a file stream instead of the std::err I need to have access to the singleton and preferable in the same place I set up the rest of my test suites. 2. To achieve pt 1 I needed to edit unit_test_framework.hpp (I think). I wanted to add support for my own command line argument which would instruct the framework of the two files I would like to create. So I thought it would be convenient to use the reteive_framework_parameter method to retrieve my custom command argument. Sadly enough I noticed that the method doesn't return the value assigned to my argument unless it is recognized. Is this fair? Daniel R. Kåsa

1 0

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