- Boost - lists.boost.org

data_binding library for boost... Any interest?
by Tom Brinkman 21 Jul '08

21 Jul '08

Unfortunately, posting lots of code on here does not work well. Small snippits of a library work well, but just pasting the file into the message makes it difficult to read. You should just summarize your proposal and put a link to where the code can be found. Try to have a hello-world style example that gives a 5 minute introduction.

1 0

[lambda] Binding to abstract class methods
by Robert Jones 21 Jul '08

21 Jul '08

Is it possible to bind to pure virtual methods? Like this struct S { void methodOfS( ) = 0; }; void f( S & s ) { using namespace boost :: lambda; bind( & S :: methodOfS, _1 )( s ); } My compiler seems to be complaining that s is abstract, which is surely not a real limitation! Thanks, Rob.

2 2

passing ranges or output iterators to virtual functions
by Simon Richter 21 Jul '08

21 Jul '08

Hi, I've written two small class templates that basically "work for me" in the current state, but are not as generic as I'd like. The task at hand: pass a list of objects through a function call with fixed signature (such as a virtual function) without exposing the actual container type used. I'd like to get a bit of feedback on whether these might be a worthwhile addition to Boost (after some cleanup and implementation of features missing so far). I'll start with the simpler class: template<typename T> class output_iterator { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } virtual void operator=(T const &) = 0; wrapper_base &operator*(void) { return *this; } wrapper_base &operator++(void) { return *this; } wrapper_base &operator++(int) { return *this; } }; template<typename O> class wrapper : public wrapper_base { public: wrapper(O o) : o(o) { } virtual void operator=(T const &v) { *o++ = v; } private: O o; }; public: template<typename O> output_iterator(O o) : o(new wrapper<O>(o)) { } output_iterator(output_iterator<T> const &o) : o(new wrapper<wrapper_base &>(*o.o)) { } output_iterator<T> &operator*(void) { return *this; } output_iterator<T> &operator++(void) { return *this; } output_iterator<T> &operator++(int) { return *this; } output_iterator<T> &operator=(T const &v) { *o = v; return *this; } private: std::auto_ptr<wrapper_base> o; }; Basically, that allows code like the following to work: class base { public: virtual ~base(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>) = 0; }; class derived : public base { public: virtual ~derived(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>); }; void derived::get_some_ints(output_iterator<int> o) { *o++ = 5; *o++ = 7; return o; } int main(int, char **) { std::list<int> l; derived d; base &b = d; b.get_some_ints(std::back_inserter(l)); // l now contains {5, 7} } The most obvious problem is that it fails for output iterators that do not advance on assignment, but that can be solved easily with a few more virtual functions in the wrapper. Something that is harder to do is that the return value from get_some_ints should be assignable to a type that is equal to int main(int, char **) { int some_ints[4]; int *next = some_ints; derived d; next = d.get_some_ints(next); } It does work if the returned output iterator is stored in an output_iterator<int>, and passing that to another function works as well. Extracting the int * would probably require RTTI. The third problem is that every time the output iterator is copied, memory is allocated, which is freed only when the last copy goes out of scope (there are some failure cases where memory is freed too early, but I think these are invalid uses of the output iterator). The second class attempts to do the same for range: template<typename T> void intrusive_ptr_add_ref(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { ++e->refcount; } template<typename T> void intrusive_ptr_release(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { if(!--e->refcount) delete e; } template<typename T> class range { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } class enumerator { public: enumerator(void) throw() : refcount(0) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() = 0; virtual enumerator &operator++(void) throw() = 0; virtual bool operator!(void) const throw() = 0; private: unsigned int refcount; template<typename E> friend void intrusive_ptr_add_ref(E *, typename E::enumerator_tag); template<typename E> friend void intrusive_ptr_release(E *, typename E::enumerator_tag); struct enumerator_tag { }; }; virtual std::auto_ptr<enumerator> get(void) = 0; }; template<typename I> class wrapper : public wrapper_base { public: wrapper(I first, I last) : first(first), last(last) { } class enumerator : public wrapper_base::enumerator { public: enumerator(I current, I end) : current(current), end(end) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() { return *current; } virtual enumerator &operator++(void) throw() { ++current; return *this; } virtual bool operator!(void) const throw() { return current == end; } private: I current, end; }; virtual std::auto_ptr<typename wrapper_base::enumerator> get(void) { return std::auto_ptr<typename wrapper_base::enumerator>(new enumerator(first, last)); } private: I first, last; }; public: template<typename C> range(C const &container) : r(new wrapper<typename C::const_iterator>(container.begin(), container.end())) { } template<typename C> range(C &container) : r(new wrapper<typename C::iterator>(container.begin(), container.end())) { } template<typename F> F for_each(F f) { std::auto_ptr<typename wrapper_base::enumerator> e(r->get()); while(!!*e) { f(**e); ++*e; } return f; } class iterator : public std::iterator<std::input_iterator_tag, T> { public: iterator(void) : e() { } iterator(std::auto_ptr<typename wrapper_base::enumerator> e) : e(e.release()) { } T &operator*(void) const { return **e; } T *operator->(void) const { return &**e; } iterator &operator++(void) { ++*e; return *this; } bool operator==(iterator const &rhs) const { if(e.get() && !!*e) return rhs.e.get() && !!*rhs.e; return !rhs.e.get() || !*rhs.e; } bool operator!=(iterator const &rhs) const { return !operator==(rhs); } private: boost::intrusive_ptr<typename wrapper_base::enumerator> e; }; iterator begin(void) { return iterator(r->get()); } iterator end(void) { return iterator(); } private: wrapper_base *r; }; Again, this class is pretty much incomplete, but "works for me". The iterator can only implement the input iterator category as it is not possible to compare two non-singular iterators. More constructors could be added that accept other inputs than containers (I can also see the memory leak, although valgrind can't -- the pointer inside the range<T> class should probably be a shared_ptr or intrusive_ptr). Any comments on these so far? Is the general idea useful? Simon

4 4

[web-site] Bad link...
by Jurko Gospodnetić 21 Jul '08

21 Jul '08

Hi. When you click on the link 'Trunk Issues' (http://www.boost.org/development/tests/trunk/developer/issues.html) on the right side of the http://www.boost.org/development/running_regression_tests.html page. you get two frames with the left one just saying 'File not found'. I'm guessing this is some stale link... Best regards, Jurko Gospodnetić

2 1

Patch for Jamroot on the release branch.
by Jurko Gospodnetić 20 Jul '08

20 Jul '08

Hi Beman. Would it be ok to add an 'import generate ;' statement to the main Boost library Jamroot file (see the attached patch)? That is the module where the 'generate' rule used in that file is defined. Although not strictly necessary this does not change anything for the build but will avoid breaking the build once we remove some extra module imports in Boost Build. I already committed the same change to the trunk. Best regards, Jurko Gospodnetić Index: Jamroot =================================================================== --- Jamroot (revision 47611) +++ Jamroot (working copy) @@ -98,6 +98,7 @@ # - handle boost version # - handle python options such as pydebug +import generate ; import modules ; import set ; import stage ;

1 0

[Boost-users] [multi_array] Everyone, please make your value-types Assignable! (was: Re: more on assignability)
by Daryle Walker 20 Jul '08

20 Jul '08

On Jul 17, 2008, at 3:19 PM, Ronald Garcia wrote: > On Jul 11, 2008, at 6:17 AM, Dr Johann A. Briffa wrote: > >> I realize this topic has been discussed before (I've seen at least >> a thread in 2006 and another in 2007), but I believe there is more >> to add. At issue is the decision that multi_array objects cannot >> be assigned [with the operator=() that is] unless the target is >> already the same size as the source. Further, there is no >> documented way to easily resize an existing array to the same size >> and range as some other array. > > Indeed there is no built-in way to easily resize a multi_array to > be the same size as another multi_array. While there is no resize > member function that takes a pointer, there is one that takes a > model of the Collection concept (classes like boost::array and > std::vector are concepts). Based on this interface, here is a stop- > gap non-invasive solution that can resize a multi_array based on > another model of MultiArray (multi_array, multi_array_ref, etc.): [TRUNCATE] Let's define some stuff here: T: some type you created, probably a class type a: an object of type T; it's valid, i.e. meets its invariants b: another object of type T, also valid; any similarities or differences in its state from a's state is unspecified C: the set of all valid states an object of type T may have Let function F: x -> Y, map a T object state x to a (sub)set of C named Y. This function returns the subset of source states that a given state can receive during an assignment. If there exists at least one x in C such that F(x) = Y < C, then type T is _NOT_ Assignable! In other words, the number of assignment- compatibility classes in T must be exactly one for T to be Assignable. Furthermore, an Assignable type requires that the destination object's observable state post-assignment matches the observable state of the source object. The destination's new state can't be the old state quasi-merged with the source's state. (The destination object's old state must appear to be splattered, but remnants could be cached to the new state.) Fortunately, most types are Assignable. What happens if your type isn't? 1. Users can't use objects of that type in standard containers, which assume to be able to freely copy objects as much as they want. 2. Such objects are a pain to work with. Any containing class must write custom assignment operators to add calls to your custom copying routine. Of course, they have to first check if the source and destination objects are in the same assignment-compatibility class, and reconfigure at least one of those two objects if they're not in the same class. The exception would be if the wrapping class always makes sure that every T object it creates is of the same class. Even that is a pain because the user has to manually confirm that invariant every time s/he changes or adds a mutating function. 3. It isn't safe. You are effectively dumping the responsibility of assignment onto your users, who won't have all the information. The user generally has to test compatibility, reconfigure at least one object, then do call the custom copying routine. These steps are distinct, so if one of the mutating steps throws, the user will probably lose his/her old state forever and have a default-valued object. Your assignment routine would have more information available, so it can structure the assignment with roll-back during throws. (This could be moderated with a swap routine that doesn't care about assignment-compatibility classes. You do have a custom swap, right? And it does work irrespective of class, right?!) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 9

[circular_buffer] release branch still not upated!
by Thorsten Ottosen 18 Jul '08

18 Jul '08

Hi Jan, The default constructor for circular_buffer is still not updated in the release branch, and it is the only reason that ptr_container is failing on the release branch: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_size(0), m_alloc(alloc) { initialize(max_size()); } The one in trunk reads: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_buff(0), m_end(0), m_first(0), m_last(0), m_size(0), m_alloc(alloc) {} Please update as soon as possible, or tell me to do it for you. Thanks -Thorsten

2 4

Boost Build Changes break serialization jamfile and stop regression tests
by Anthony Williams 18 Jul '08

18 Jul '08

Hi, I just tried to run a batch of regression tests against trunk, and found that they failed rather quickly due to bjam aborting with the following error: error: Unable to find file or target named error: 'serialization_test//test_class_info_save_text_archive' error: referred from project at error: '.' This error causes the entire test run to fail before it's even started. It appears this was caused by revision 47536. Please could someone either revert the change or fix the failure. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

3 2

[serialization] Change between 1.33.1 & 1.35
by loic.actarus.joly＠numericable.fr 18 Jul '08

18 Jul '08

1 0

Strange commit failure on release branch.
by John Maddock 18 Jul '08

18 Jul '08

Folks, I'm trying to update the Boost.Math docs on the release branch but I get: Error: Commit failed (details follow): Error: File or directory 'html\math_toolkit\special\expint\expint_i.html' is out of Error: date; try updating Error: The version resource does not correspond to the resource within the Error: transaction. Either the requested version resource is out of date (needs to be Error: updated), or the requested version resource is newer than the transaction root Error: (restart the commit). Now the thing is I *have* made sure that the whole branch is up to date, and in any cases there are no changes to that file in SVN, so I'm stumped. Any ideas anyone? Thanks, John.

2 2