- Boost - lists.boost.org

RE: [boost] STL algorithm for containers (was Re: Re: boost/test/ detail/algorithm.hpp: request forpromotionand/or fast review)
by Max Khesin 24 May '04

24 May '04

There has been an attempt to do something like that here (looks somewhat useful, but far from being 'boosified): http://userpages.umbc.edu/%7Ebcorfm1/easystl.zip Stated goal of this library (from http://userpages.umbc.edu/~bcorfm1/software.html) EasySTL. A supplemental library to the C++ Standard Template Library (STL) that has three main goals. * Eliminate iterators from function calls (where possible). * Enable functional programming by modifying copies of passed containers instead of modifying containers in-place. * Introduce high-level functions (like those in Lisp or Python) for string, file and container manipulation. This library has been tested with Visual C++ .NET only. (I've started moving over to VC++.NET wholeheartedly as their template and STL support is much better now.) m > > Gennadiy Rozental wrote: > > > Why don't we provide container versions of all stl algorithms: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Re: [boost] Re: class properties: requestforpromotionand/orfastreview.
by Reece Dunn 24 May '04

24 May '04

Peter Dimov wrote: >Reece Dunn wrote: > > Peter Dimov wrote: > >> As a relatively simple example, consider a pair of integers (x, y) > >> that has an invariant of x*x + y*y = 25, and try to move from (3, 4) > >> to (4, 3) by using the X and Y properties. > > > > Since the invariant is on both variables, neither can be set > > independant of each other, since you'd assume that changing one would > > invalidate the invariant. Therefore, the properties must be > > *readonly* to prevent modification. You'd have a function to set both > > values at the same time (e.g. moveto). > >Exactly. Which is the C++ model: int x() const, int y() const, void >set(int, >int). Some purists even omit the set(): p = point(4, 3); > >You can, of course, use "read only properties" instead of x() and y() but >this changes nothing but syntax, not necessarily for the better, I might >add. It all depends on what you are using the properties for. I use them regularly when dealing with MS COM objects where the interfaces use get/set methods to interface with the underlying object. So you can use them more intuitively (especially when coupled with smart pointers, exceptions and variant/BSTR helpers): com::msxml::XMLDOMNode node = ...; std::cout << node.nodeName << " = " << node.nodeValue << '\n'; which would look very ugly without properties! Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

[Boost.Test] New testing procedure?
by David Abrahams 24 May '04

24 May '04

According to http://tinyurl.com/3f32c tests have been failing (IIUC for several days if not longer) because of protected/private access violations in the test library. See the end of http://tinyurl.com/35ole for details. IMO this situation is unacceptable, and I'm looking for practical solutions. Problems with the Boost.Test affect our ability to get meaningful feedback on the state of other libraries. If Gennadiy can't test on more compilers before checking in, and respond faster to problems introduced in its source, and if library authors genuinely find Boost.Test useful, maybe we need to move to a different model wherein the test library's own tests are run on a CVS branch of the code (?) so that Gennadiy can see and deal with his problems before they are merged into the main trunk and break everything else? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 2

Safe to combine boost asinh and boost interval?
by Antony Searle 24 May '04

24 May '04

Hi, >From what I can make out of their respective implementations, the interval library assumes that asinh (when it exists) produces values consistent with the floating point rounding mode (i.e. rounding up or down as requested). The boost implementation of asinh doesn't seem to take account of the rounding mode like this [for x < 0 it returns -asinh(-x), which will be rounded the wrong way]. Does this mean that the inclusion guarantee is violated when combining boost interval and boost asinh? Thanks, Antony Searle antony.searle(a)anu.edu.au

3 3

Re: [boost] Re: static sized strings
by Reece Dunn 24 May '04

24 May '04

Rob Stewart wrote: >From: "Reece Dunn" > > Rob Stewart wrote: > > >From: "Reece Dunn" > > > > > > > > Currently, this implementation is missing iterator support (and thus >all > > > > basic_string functionality that relies on begin(), end(), etc). This >is > > > > because I am wondering how to map them from the basic_string adaptor >to > > >the > > > > implementation (knowing that you cannot have const and non-const >virtual > > > > functions). > > > > > >Since when can you not have const and non-const virtual > > >functions? > > > > Let me rephrase: > > > > class char_string > > { > > virtual iterator begin() = 0; > > virtual const_iterator begin() = 0; // oops! begin already in >vtable!! > > }; > >I'm still missing something. Why would you want a non-const mf >to return the const iterator type? That was a typeo! > class char_string > { > virtual iterator begin() = 0; > virtual const_iterator begin() const = 0; > }; That is what I was referring to. You need to change the name of the const version if you are to allow virtual functions. > > > > I have two possible solutions: > > > > [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the > > >problem > > > > with this is that you have 8 virtual functions! > > > > I was meaning to modify the above to: > > > > class char_string > > { > > virtual iterator begin() = 0; > > virtual const_iterator cbegin() = 0; // ok - cXXX variant > > }; > > > > >You'd have those same eight variations with const and non-const > > >virtual functions. > > > > That's the problem -- too many virtual functions. > >But if you need all eight variations, then you need eight virtual >functions. Is it that you're trying to minimize what the derived >class must implement for the adaptor to work? Even if that's the That is indeed what I am trying to do. >case, because the const and non-const functions return different >types, you can't have the derived class implement a const >implementation function that the adaptor can use to provide both >const and non-const interface functions. So what am I missing? Nothing. You do indeed need two functions: iterator iter_offset( difference_type ); const_iterator const_iter_offset( difference_type ) const; these can be used to implement the 8 iterator functions like this: begin() const = const_iter_offset( 0 ); begin() = iter_offset( 0 ); end() const = const_iter_offset( size()); end() = iter_offset( size()); rbegin() const = const_reverse_iterator( const_iter_offset( size())); rbegin() = reverse_iterator( iter_offset( size())); rend() const = const_reverse_iterator( const_iter_offset( -1 )); rend() = reverse_iterator( iter_offset( -1 )); Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

3 3

Re: [boost] Re: static sized strings
by Reece Dunn 24 May '04

24 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Nothing. You do indeed need two functions: > > iterator iter_offset( difference_type ); > > const_iterator const_iter_offset( difference_type ) const; > >Why? This is perfectly valid C++: > > iterator iter_offset(different_type); > const_iterator iter_offset(different_type) const; > >So is there something in how you want to use them that precludes >your overloading them that way? No. I was not aware that it is possible to do this. I have now adopted struct char_string { ... virtual iterator iter_offset(different_type) = 0; virtual const_iterator iter_offset(different_type) const = 0; }; into my implementation. Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0; Because I had assumed that you could not do this, since (1) I haven't read the standard that properly, I have mainly focused on learning from other books (like Stroustrup, 3ed) and (2) I haven't seen any code that uses virtual functions like char_string above or my question. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

5 6

program_options not detecting invalid options
by Neal D. Becker 24 May '04

24 May '04

Not sure what's causing it, but here's what happens: /Test9a --doCancel=0 -e 3.5 --ampl1=0 --ampl2=-300 --freqStep=1.563e-4 --randomFreq=0 --cheatFreq [program running with no complaint...] But --cheatFreq is not a valid option.

2 1

Re: [boost] Re: class properties: request forpromotionand/orfastreview.
by Reece Dunn 24 May '04

24 May '04

Peter Dimov wrote: >It doesn't matter. Properties represent degrees of freedom. They don't >describe dependent data well. > >As a relatively simple example, consider a pair of integers (x, y) that has >an invariant of x*x + y*y = 25, and try to move from (3, 4) to (4, 3) by >using the X and Y properties. Since the invariant is on both variables, neither can be set independant of each other, since you'd assume that changing one would invalidate the invariant. Therefore, the properties must be *readonly* to prevent modification. You'd have a function to set both values at the same time (e.g. moveto). class coord { private: int x, y; public: inline int get_X(){ return( x ); } inline int get_Y(){ return( y ); } inline void moveto( int x_, int y_ ) { assery(( x_ * x_ ) + ( y_ * y_ ) == 25 ); // invariant x = x_; y = y_; } public: // data access property_readonly< int, &get_X > X; property_readonly< int, &get_Y > Y; public: // ... }; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 24 May '04

24 May '04

[David Abrahams] > What *any* book other than the standard says has no bearing > on whether a DR is appropriate. Yes, of course. Very well. Though the Standard is clear to me, apparently it's not clear to everyone, and it should be. So here is a proposed DR. Comments (particularly on the Proposed Resolution)? Once we get this DR into shape, would you like to pass it on to the Committee? ---BEGIN DR--- Library DR [FIXME]. May the functor given to for_each modify its argument? Section: 25.1.1 [lib.alg.foreach] Status: Open Submitter: Stephan T. Lavavej Date: 24 May 2004 for_each is classified (without explanation) in [lib.alg.nonmodifying], "25.1 Non-modifying sequence operations". Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in the sense that neither the algorithms themselves nor the functors given to them may modify the sequences or elements in any way. The guarantee about the algorithms is provided by their descriptions (and implicitly by their classification in [lib.alg.nonmodifying], which is the subject of this DR), while the guarantee about the functors is provided by the fact that they are all Predicate or BinaryPredicate. In contrast, for_each takes a Function. Library DR 290 complains that there are no requirements placed on this Function; this DR complains that there are no guarantees given about what the Function may do. I believe that the intent of the Standard in classifying for_each as a "non-modifying sequence operation" is to say that the algorithm itself does not modify the sequence it is given (in contrast to "mutating sequence operations" such as replace, where the algorithm itself does the modifications), but that the Function given to for_each may modify the elements it operates on. This is supported by the bottom of Page 524 of The C++ Programming Language Third Edition, fifth printing or higher (or any printing of Special Edition). The problem is that no guarantee is given that the Function may modify elements it operates on, so conceivably an implementer could write for_each in such a way as to disallow this, or a programmer may avoid using for_each with element-modifying functors because of the belief that implementers have such latitude. Proposed Resolution: Add the following sentence to the Notes in 25.1.1 [lib.alg.foreach]: "/f/ may apply non-constant functions through the dereferenced iterators it is applied to." The phrasing here is chosen to be consistent with [lib.alg.foreach] Effects ("Applies /f/ to the result of dereferencing every iterator...") and the opposite of the restrictions placed on Predicate in [lib.algorithms] ("/pred/ shall not apply any non-constant function through the dereferenced iterator"). I believe that this guarantee coupled with the requirement proposed in Library DR 290 covers all cases of what the Function passed to for_each may and may not do. Alternatively, phrasing based on the more detailed explanation in The C++ Programming Language Special Edition could be used (it explains that when an element-modifying functor is used, the sequence has to be non-const; I believe that the above phrasing implies this). This guarantee merely clarifies what I believe is already the intent of the Standard. It is related to Library DR 290 but is independent of it, and neither DR relies on the other. ---END DR--- The DR is probably unnecessarily verbose. Stephan T. Lavavej http://nuwen.net

2 1

input_iterator_facade (was: Re: [iterator facade] Why is dereference const?)
by Gennadiy Rozental 24 May '04

24 May '04

Hi, Here is the input_iterator_facade template (similar in nature to Vladimir's eof_iterator ) I am using in Boost.Test development: namespace detail { template<typename T> struct value_type_ident { typedef T value_type; }; template<typename T> struct ref_type_ident { typedef T reference; }; } // namespace detail template< typename ImplPolicy, typename Derived = mpl::void_, typename ValueType = mpl::void_, typename Reference = mpl::void_> class input_iterator_facade : public iterator_facade< typename mpl::if_<mpl::is_void_<Derived>,input_iterator_facade<ImplPolicy>,Derived>:: type, typename mpl::if_<mpl::is_void_<ValueType>,ImplPolicy,detail::value_type_ident<ValueT ype> >::type::value_type, forward_traversal_tag, typename mpl::if_<mpl::is_void_<Reference>,ImplPolicy,detail::ref_type_ident<Referenc e> >::type::reference> { public: // Constructor explicit input_iterator_facade( ImplPolicy const& p = ImplPolicy() ) : m_policy( p ) { m_valid = m_policy.initialize(); increment(); } //!! copy constructor/assignment - should we make rhs invalid after copy?? //!! do we need reset method? protected: // provide access to the derived // Data members ImplPolicy m_policy; private: friend class iterator_core_access; // iterator facade interface implementation void increment() { if( m_valid ) m_valid = m_policy.get(); } bool equal( input_iterator_facade const& rhs ) const { return !m_valid && !rhs.m_valid || m_valid && rhs.m_valid && m_policy.equal( rhs.m_policy ); } reference dereference() const { return m_policy.dereference( m_valid ); } // Data members bool m_valid; }; See full versions with extra comments here: http://tinyurl.com/2x69z There is one specific iterator implemented that used this template located in the same directory (more coming). I actually combine new CRTP and old policy technique here, for later allows me to implement more functionality in common code. Is there interest in adding this to the family of iterator helpers? Or could I move it in boost namespace for convenience? Gennadiy.

3 4