- Boost - lists.boost.org

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

Re: [boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 24 May '04

24 May '04

Jeff Garland wrote: > Well as soon as Robert wants to run the torture test he's going to get it > at all sites if he controls it via his Jamfile. So we need some > boost-wide option to define these variations. Hopefully my other email > clarifies the idea. My concern was raised base on the following scenario: a) I get things working to taste on the 3 or 4 compilers I have installed. b) I check in to CVS c) Test is run - takes a long time d) But shows some problems in the 5 compilers I don't have e) Now I start to fix stuff - more or less one compiler at a time f) Now much computer resource are used to no good purpose. I can't stop the test from running on the compilers that I know will fail anyway. g) Now my interest shifts to another compiler and a whole different set of wasted effort is done. .... q) Now everything is spiffy r) test runs - but only those tests that are dependant on something that has changed. The situation is tolerable - until something changes that changes the library - then caos from q onward the problem might be manageable if BJAM was could manage dependencies from are particular x.hpp -> y.cpp -> test.cpp. But as it is now, if one *.cpp file in the library has to be rebuilt, all the test that depend on any portion of the library have to be run. I realize this is an unrealistic hope but we're allowed to dream. So checking in a new Jamfile to customize at test is OK but it still leaves me with doing all the compilers even though I know it's a waste of time. Robert Ramey

3 2

RE: Re:[boost] [Boost.Test] New testing procedure?
by Roman Yakovenko 24 May '04

24 May '04

Aleksey Gurtovoy wrote: > a) incremental cylces, with a full rebuild once a week or > something similar > (here at Meta, for instance, are currently doing full > rebuild on every > cycle); > > b) distributed testing of libraries, with the following > merging of results > into a single report. I agree with Aleksey. I am using boost a lot in my work. So I would like to give something back. I can test CVS version of boost on WinXP + compiler of MS Visual Studio 7.1. And at home on "Fedora Core 2" gcc 3.4. The question is what should I send back? Roman

2 1

[Boost-bugs] [ boost-Support Requests-959156 ] boost for ARM platform?
by SourceForge.net 24 May '04

24 May '04

Support Requests item #959156, was opened at 2004-05-23 16:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=959156&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=959156&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

wrap_stringstream status
by Gennadiy Rozental 23 May '04

23 May '04

Hi, I finished anothher round of modification in wrap_stringstream makeing it more generic (actually it now template basic_wrap_stringstream and specializations). Is there still interest in putting it uner boost/utility and do we need a fast review for it? If yes I will prepare doc page. Gennadiy.

3 6

Re:[boost] [Boost.Test] New testing procedure?
by Robert Ramey 23 May '04

23 May '04

Dave Abrahams wrote: > 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? Clearly, test the test (meta-testing ?) is a special category. I needs to be staged to be tested itself before being used to test other stuff. I believe boost testing is going to be an issue in the near future do the fact that testing time is getting longer and longer and longer. I believe we will have to move to an "on demand" model for most testing while reserving "total coverage" testing for just prior to release. Although this wouldn't definitively address the issue raised it would help. As only those libraries currently being tested would suffer due to dependencies on other code. It would also save lots of time and permit test time to keep from becoming an issue. Robert Ramey

5 17

IMPLICIT_CAST macro
by Gennaro Prota 23 May '04

23 May '04

Hi, I was grep'ing for my name in the boost repository in order to update any old license reference and found the following definition in implicit_cast.hpp: // Macro for when you need a constant expression (Gennaro Prota) #define BOOST_IMPLICIT_CAST(dst_type, expr) \ ( sizeof( implicit_cast<dst_type>(expr) ) \ , \ static_cast<dst_type>(expr) \ ) This wasn't the form I submitted though, as the comma operator isn't allowed in a constant expression and I remember pointing out on this list that this was a case where it would be useful :) Maybe the above was simply copied from this post: http://lists.boost.org/MailArchives/boost/msg42102.php where I was saying that it *doesn't* work and that I had to use the check_helper<> template. Genny.

2 5