- Boost - lists.boost.org

Explicit markup notes
by Aleksey Gurtovoy 30 Jun '04

30 Jun '04

Could I ask that every time we are adding an explicit failure to "status\explicit-failures-markup.xml" or, even more so, marking up a library as unusable, we also provide a note explaining the markup? We don't have to come up with a specific wording for every single failure -- there are a few standard notes at the end of the document that fit many common situations, and can be simply referenced by their ID (e.g. <note refid="3"/>), but not saying anything at all significantly defeats reports' usefullness. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Library doc link is broken
by Jeff Garland 30 Jun '04

30 Jun '04

The current CVS doc link seems to have gone down... Not Found The requested URL /regression-logs/cs-win32_metacomm/doc/html/libraries.html was not found on this server. Jeff

2 1

[Formal review result] Tribool
by Thomas Witt 30 Jun '04

30 Jun '04

Hi, I am happy to report that the "Tribool" library by Doug Gregor has been ACCEPTED into boost. Other than this there is very little to be said. Reviews were generally in favour of the library and the issues surfaced during the review have been addressed by Doug. There were some comments regarding the scope of the library. While I agree that an broader coverage of 3-valued logic might be good to have, I do not think it justifies delaying acceptance of the library. Regards Thomas Review Manager Tribool -- Thomas Witt witt(a)acm.org

1 0

Bug in token_functions.hpp
by Joe Gottman 30 Jun '04

30 Jun '04

I have found a bug in token_functions.hpp. I have a hello-world program that looks like this: ----------begin file #include <boost/token_functions.hpp> int main(int argc, char* argv[]) { boost::char_separator<char> sep; printf("Hello World!\n"); return 0; } ----------end file It fails under MSVC 6.0 with the following error messages: c:\jobs\boost\token_functions.hpp(261) : error C2065: 'is_pointer' : undeclared identifier c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2275: 'Iterator' : illegal use of this type as an expression c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2059: syntax error : ',' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(264) : error C2238: unexpected token(s) preceding ';' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(266) : error C2653: 'cat' : is not a class or namespace name c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled I believe the problem is that we need to add the line #include <boost/type_traits/is_pointer.hp> to token_functions.hpp. If I add this line to my program before including token_functions.hpp, everything compiles fine. Joe Gottman

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Hurd, Matthew 29 Jun '04

29 Jun '04

> Behalf Of Batov, Vladimir > > > bool foo(bool threadsafe) > > { > > mutex::scoped_lock l(m, !threadsafe); > > } > > I am not sure if the example above is appropriate and indicative of the > problem we are trying to solve. Thread-safety should not be a run-time > configurable property. Like we do not decide on the fly (at run-time) if > our ref.-counting class is to be thread-safe or not. All that is > resolved at compile time. >" Thread-safety should not be a run-time configurable property." I think this is somewhat incorrect as absolutes usually are. I currently have a design where I use both an interface that supports locking and an interface which does not. It is an important feature of the design. Using such a run time parameter is not my choice because I am especially sensitive to performance but it might be a better design for others given other requirements. Non-locking versions are also useful when you want to combine operations. Take a lock, do stuff, and then release lock. Repeatedly locking has deficiencies which may or may not matter to you. $0.005, Matt Hurd. FWIW I wrap boost mutexex and locks in my own policy-like stuff. E.g: ___________________________________________________________ struct shareable { protected: struct adapted_mutex : public boost::rw_mutex { adapted_mutex( lock_priority::type lp = lock_priority::exclusive ) : rw_mutex( convert( lp) ) {} ~adapted_mutex() {} }; struct adapted_try_mutex : public boost::try_rw_mutex { adapted_try_mutex( lock_priority::type lp = lock_priority::exclusive ) : try_rw_mutex( convert( lp) ) {} ~adapted_try_mutex() {} }; struct adapted_timed_mutex : public boost::timed_rw_mutex { adapted_timed_mutex( lock_priority::type lp = lock_priority::exclusive ) : timed_rw_mutex( convert( lp) ) {} ~adapted_timed_mutex() {} }; public: typedef adapted_mutex mutex; typedef adapted_try_mutex try_mutex; typedef adapted_timed_mutex timed_mutex; typedef shareable_lock<mutex> lock; typedef shareable_lock<try_mutex> try_lock; typedef shareable_lock<timed_mutex> timed_lock; typedef atomic_op_interlocked atomic_op; }; ___________________________________________________________ So I can parameterise classes with a synch policy. (Less than ideal but I haven't got around to making it nicer yet.) For the interface where I need to support single threaded and multi-threaded usage of the same object ( as opposed to type ) I use this approach... ___________________________________________________________ template < class S = synch::shareable > class instrument : public synch::monitor<S> { SYNCH_SIMPLE_ATTRIBUTE( susquehanna_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( exchange_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( underlying, std::string ); SYNCH_SIMPLE_ATTRIBUTE( bid, double ); SYNCH_SIMPLE_ATTRIBUTE( bid_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( ask, double ); SYNCH_SIMPLE_ATTRIBUTE( ask_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( last, double ); SYNCH_SIMPLE_ATTRIBUTE( last_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( prior_settlement, double ); }; ___________________________________________________________ This way I can use an object in the following manner: ___________________________________________________________ te::instrument<> i_sample; i_sample.exchange_code<true>("hello"); // locking { te::instrument<>::lock lk( i_sample.guard() ); i_sample.exchange_code<false>("hello"); // non-locking } i_sample.exchange_code("hello"); // locking std::string hello = i_sample.exchange_code(); // locking hello = i_sample.exchange_code<false>(); // non-locking hello = i_sample.exchange_code<true>(); // locking hello = i_sample.exchange_code_ref(); // non-locking by nature ___________________________________________________________ I could also specify te::instrument< synch::no_synch > // locking is elided te::instrument< synch::simple > // exclusive locking te::instrument< synch::no_synch > // allows recursive locking te::instrument< synch::shareable > // allows shared or exclusive locks (think r/w) The interface to the non-locking version is still valid. User must code to shareable concept for everything to work for all concepts. Where SYNCH_SIMPLE_ATTRIBUTE defines a bunch of simple attribute helpers and looks like: #define SYNCH_SIMPLE_ATTRIBUTE( VAR_NAME, VAR_TYPE ) \ \ public: \ template< bool > \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ if ( boost::needs_lock<VAR_TYPE>::value ) { \ lock lk(guard_ ); \ VAR_NAME<false>( new_ ## VAR_NAME); \ } else { \ VAR_NAME<false>( new_ ## VAR_NAME); \ } \ } \ \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME < true > ( new_ ## VAR_NAME ); \ } \ \ template< > \ void \ VAR_NAME<false> \ ( \ boost::call_traits<VAR_TYPE>::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME ## _ = new_ ## VAR_NAME; \ } \ \ template< bool > \ VAR_TYPE \ VAR_NAME( ) const \ { \ if ( boost::needs_lock< VAR_TYPE >::value ) { \ lock lk(guard_, synch::lock_status::shared ); \ return VAR_NAME<false>( ); \ } else { \ return VAR_NAME<false>( ); \ } \ } \ \ VAR_TYPE \ VAR_NAME( ) const \ { \ return VAR_NAME<true>( ); \ } \ \ template< > \ VAR_TYPE \ VAR_NAME <false>() const \ { \ return VAR_NAME ## _; \ } \ \ boost::call_traits<VAR_TYPE>::const_reference \ VAR_NAME ## _ref( ) const \ { \ return VAR_NAME ## _; \ } \ \ private: \ VAR_TYPE VAR_NAME ## _; \ SYNCH_SIMPLE_ATTRIBUTE includes an extra thing boost::needs_lock<VAR_TYPE>::value that checks if the size of the type is > pointer size which means, for Intel & AMD, that locking is not required as the assignment of aligned types is atomic. Copy constructors, assignment and cloning are further issues ;-) IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Proposal: signed.hpp
by Jeffrey C. Jacobs 29 Jun '04

29 Jun '04

Based on Dave Abrahams' recent notes, may I suggest the following draft for revision? http://starship.python.net/crew/timehorse/signed.hpp Thanks! Jeffrey

2 1

ReL[boost] Re: 1.32 release preparation
by Robert Ramey 29 Jun '04

29 Jun '04

David Abrahams <dave(a)boost-consulting.com> writes: >> Robert, I'm very happy to have your contributions in this discussion, >> but it's hard to take your diagnosis of where the problem lies all >> that seriously when you haven't even been through a single Boost >> release with a library of your own! >I hope I didn't squash the discussion with this remark; I'm really >interested in exploring the possibilities here. I guess I should've >asked how you formed your impressions of the problem's cause. As I recall, the previous release was scheduled for beginning November. I was working on the serialization library at the time and using the development tree at the time. When the release was announced, lots of new stuff was added. There were a couple of tweaks in the new iterators which required changes for me to keep up. Trying to develop new stuff based on he development tree became inconvenient but I needed features not it 1.30 . Then about the middle of January "is_abstract" was dropped in. This was an evolved version of one I had adapted from ?R Sharoni's code. It was slightly different from the original in the way compilers not supported. So we didn't have real good knowledge about which platforms supported it and what value it should return on platforms that didn't support it. I was considered a very small change but consumed maybe a week of back and forth. It became clear that I could not submit a proposed serialization library based on the development tree that could be reviewed by large number of members downloading the library over an extended period without users encountering a lot of frustration and my trying to keep up with a morphing main trunk. As soon as it was released, I switched to maintain compatibility with the released 1.31 and it has worked out well. Based on this experience, it is my perception that the main development trunk was at least somewhat fluid over a period of 2 to 3 months and this made development more difficult. These are just the things I happen to run into first hand. The traffic on the list left me with the impression that my experience wasn't unique. That is how I formed my impression of the problem's cause. It is my reluctance to contribute to this problem which has discouraged me from checking in the serialization library until it is at a point where I believe there are no undocumented bugs/deficiencies. That is why the serialization library is not yet checked in. At this point nothing in boost depends on the serialization library. Should that change in the future, this discussion convinces me that before checking in any non-trivial changes, I should re-run the whole test suite on my local setup. In the case of MPL, I would think that it would be prudent to run that part of the test suite that depends upon MPL on one's local environment before checking it in - given that we don't use a branch for untested code. Robert Ramey

2 1

1.32 release preparation
by Aleksey Gurtovoy 29 Jun '04

29 Jun '04

Hi All, I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input: June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule, make regression reports to reflect the actual status of the main trunk, setup nighly runs of the inspection report (http://tinyurl.com/2vo5p) construct a "Release Progress" page publishing the milestones, the collective TODO list, and links to all the reports. June 27-July 16: Use regression reports to identify and resolve the outstanding issues with the main trunk. Walk through and deal with all the patches and bug reports submitted to the list/SourceForge tracker since the last release. In accordance with the TODO list, track the progress of individual developers. By July 15, 24:00 US Central Time every line of code that is intended to be put into this release should be in the CVS, and the next round of regression reports should show no regressions against the then-current expected failures markup. July 16: Branch for release. Switch regression tests to run on the branch. July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch. July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat. July 21: Release according to the http://tinyurl.com/2meuh procedure. As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject. As usual, any other comments/suggestions are more than welcome. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

14 29

typo in boost::thread
by Janusz Piwowarski 29 Jun '04

29 Jun '04

Hello, Numerous files of boost::thread has CR+CR+LF as line ending. I noticed it happens regularly, maybe there's a way to prevent this? Also, there's a typo in try_lock member of scoped_timed_lock<TimedMutex> class: is: return (m_locked = lock_ops<TryMutex>::trylock(m_mutex)); should be:? return (m_locked = lock_ops<TimedMutex>::trylock(m_mutex)); Regards, Janusz

2 2

RE: [boost] The Test Tools Docs, Concept Checking
by Rozental, Gennadiy 29 Jun '04

29 Jun '04

I could add proposed text, once somebody prepared it. Gennadiy. > Hi, > > I have been reading the Test Tools docs. Would it be a > good idea to add ConceptChecking to the list of alternative > methods of reporting errors, in > /test/doc/index.html#introduction ? A recent post on boost > alluded to the fact that Concepts (ie What is a concept? ) > can be difficult to understand. Well ... ConceptChecks are > the medium for pinning down Concepts in C++ code and are > probably the most effective means of error reporting at > compile time, but are not used as much as they could be. The > Boost Test Library would seem to be as good a place as any to > promote them, which could help to remove some of the mystery. > > regards > Andy Little

3 2