- Boost - lists.preview.boost.org

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

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

23 May '04

David Abrahams wrote: > We currently already have a way of expressing that "known to not work on X > compiler" idea in the regression system. We could make the build > system smart about it. I haven't seen that. That would be helpful. How can I specify that its pointless to run tests on a particular compiler. Probably simpler, though, you could just put something in one of your library headers that said: > #if BOOST_WORKAROUND(compiler1) || BOOST_WORKAROUND(compiler2) || ... > # error doesn't work yet > #endif Actually I've done something similar for systems whose support for wide character i/o is insufficient. Its sort of OK but the the test show up as all failures which is slightly miss leading. At it doesn't take all that long but I'd prefer just to skip it. >> from q onward the problem might be manageable if BJAM was could manage >> dependencies from are particular x.hpp -> y.cpp -> test.cpp. > Of course it can and does. >> 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. >Of course they should. >> I realize this is an unrealistic hope but we're allowed to dream. >I clearly don't know what you're talking about here. What I mean is: Test.cpp only depends on module1.cpp which Is in the library. The functions in module1.cpp can only be accessed by including header1.hpp in the test either directly or indirectly. Suppose module2.cpp gets recompilied. This provokes a rebuild of the library which provokes a rebuild of test.cpp and rerunning of the test. This occurs even though this isn't necessary as module1.cpp - the only module the test depends upon - hasn't changed. In other words. The dependency granularity is the library - not the modules within the library. My understanding comes from study of BJAM and observation of my system when I make a change. I would be very pleased to find out that I'm wrong about this. So let me see if I have this right. a) I can check in a different version of runtest that will set my "testing level" appropriate for the state of the library and change it as necessary. b) I can specify which compilers should be included/excluded from the test. (somehow - I don't know how yet) c) If something changes that effects any code/header module used by the library - everything is going to be rebuilt and tested regardless of the dependency of the particular test. OK - given a and b I think this can be made to work with relatively little difficulty. >From another post: >> The same set of tests should be runnable by the regression tester >> and hence associated with the column in the results table. So >> something like: >> >> VC7.1 VC7.1 VC7.1 etc >> release release debug >> dll static dll >> >> test1 Pass fail Pass >> test2 Pass Pass Pass >> ... >> >> Then basic/complete option controls the number of tests run. >That's outta hand, IMO. If it's worth having options, let's keep > them simple. The compiler_status program is a good start but I have a real need for something that can produce the table above driven by a command line configuration string. So much so that that I'm almost up for writing it myself using the current compiler_status program as a staring point. It may happen. My experience is that when I have the debug version all running spiffy, I always have some weird issue with release mode which is compiler dependent. Usually its related to the compiler/linker dropping stuff it doesn't think needs to be instantiated. In practice, once its fixed, it doesn't break until some really major change occurs. So my policy will be to run the relase mode test just once in a very long while. Robert Ramey

2 1

RE: [boost] class properties: request for promotion and/or fast review.
by Reece Dunn 23 May '04

23 May '04

Gennadiy Rozental wrote: >Hi, > >I am using simple class properties facility for some time and found it >quite >useful. Actually it's nothing fancy - simple helper classes to eliminate >repetitive setter/accessor methods (and no need for language extensions). Have you had a look at SC22/WG21/N1615 (C++ Properties -- A Library Solution) by Lois Goldthwaite (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1