October 2004 - Boost - lists.preview.boost.org

*Attention*: ISO 9660/names with multiple dots
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

Gentelmen, Apparently, ISO 9660, including Levels 2 and 3, does not allow names containing more than one dot character (see, for instance, http://www.gnscd.com/iso.htm) The requirement has always been present in our file/directory naming guidelines -- http://www.boost.org/more/lib_guide.htm#Directory_structure, but was never checked/inforced. As the result, currently we have quite a number of files (249!) that will have to be renamed before we can put them on an ISO 9660 CD -- see http://www.meta-comm.com/engineering/boost/names_with_dots.html. Note that this doesn't include BoostBook-generated documentation (since it is not in the current CVS), which uses multiple dots convention for the generated HTMLs all over the place. It's not going to be terribly hard to fix all these issues, but I wanted to bring this to everyone's attention to make sure that there is a consensus that this is a right thing to do, and that the benefits are worth the trouble. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[Poll] New look-n-feel for Boost documentation
by Eric Niebler 03 Oct '04

03 Oct '04

Joel de Guzman and I, with the help of many smart folks on the boost-docs list[*], have been working on improving the look-n-feel of Boost's documentation. We're ready to commit the new style, but wanted to check here first. Volodya was good enough to put up a copy of Boost's docs with the new style applied. You can preview them here: http://zigzag.lvk.cs.msu.su/~ghost/boost_docs/ Please say whether you like the new style or not. If not, be specific about why. If you are the author of Boost documentation, please have a look at your docs in the new style and see if anything is out of place. [*] Thanks to Doug Gregor, Vladimir Prus, Dave Abrahams, Reece Dunn, Jeff Garland, Rene Rivera and others for their valuable feedback regarding the new style. -- Eric Niebler Boost Consulting www.boost-consulting.com

22 52

Order of entries in the Bibliography section?
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

I've noticed entries do not follow any definite order. Print publications are more or less sorted by year, but other sections are seemingly listed at random. I propose the following: * Inside each section, sort lexicographically by year and author, for instance online mentions would get like this [Burnap02] [Curran02] [Siek02b] [Casad03] [Lischner03] [Stein04] * Add this policy in the "How to update this page" section. If people are happy with this, I volunteer to do the changes. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 9

Re: [boost] [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 03 Oct '04

03 Oct '04

In-Reply-To: <e094f9eb040930020665f195c5(a)mail.gmail.com> rogiervd(a)gmail.com (Rogier van Dalen) wrote (abridged): > I'd suggest either not overriding the browser's font settings > for paragraph text, or using a serif font. I feel the same. I find the text a bit too big. It's a bit like reading a children's large-print book. I'd also prefer it not to override my colour settings. My default background is not white. Overall I think it looks better. I had a quick look from my mobile phone, and it worked reasonable well. (You might want to try that yourself, if you haven't already.) -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 03 Oct '04

03 Oct '04

Peter Dimov <pdimov(a)mmltd.net> wrote: > Alexander Terekhov wrote: > > Peter Dimov wrote: <snip> > >> The observable behavior is > >> > >> write volatile @a 1 > > > > nop > > > >> read volatile @a x > > > > nop > > > >> write volatile @a x-1 > > > > nop > > > >> exit(x-1) > > > > push 0 > > call _exit > > > >> > >> in the first case, and > > > > Happy now (debugger notwithstanding)? > > No. A conforming compiler is not allowed to do that. > > > C'mon, volatile is brain-dead. > > Nobody's arguing otherwise. ;-) But a nop it isn't. I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable", the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule. I expect most implementations treat "observable" as "observable by a software or hardware debugger", but of course the standard doesn't and can't say that.

3 4

[type_traits] alignment_of_test problem in Intel Linux
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <: I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp #define ALIGNOF(x) align_calc<x>::get() as #define ALIGNOF(x) align_calc< x>::get() (note the extra blank). OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

Re:[boost] [serialization] test_level_class_info_load*...
by Robert Ramey 03 Oct '04

03 Oct '04

Stefan Slapeta >...is marked as expected failure for all toolsets! Is this really intended? >(What does us tell a test that is expected to fail everywhere?) This is marked with the ref note - "fails intermittently" - the failure is an result of the fact I haven't been able to make Jamfile run tests in a particular sequene. I could remove the markup - but that would leave several failures as expected when in fact I know what they are. Robert Ramey

3 2

[Boost-bugs] [ boost-Support Requests-1039338 ] Visual C++ "Language Extensions" support
by SourceForge.net 03 Oct '04

03 Oct '04

Support Requests item #1039338, was opened at 2004-10-03 02:44 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=1039338&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Visual C++ "Language Extensions" support Initial Comment: The following compiles under Visual C++ .Net with "Language Extensions" enabled, but it fails otherwise: #include <boost/token_iterator.hpp> int main() { return 0; } The received errors are: d:\Programming\boost\boost\detail\iterator.hpp(174) : error C2061: syntax error : identifier 'value_type' d:\Programming\boost\boost\mpl\aux_\preprocessed\msvc70\or.hpp(27) : error C2970: 'boost::mpl::aux::or_impl' : template argument 'C_' : invalid use of non-integral-constant static variable 'value' as non-type argument (and 4 more similar to the last one) How can I fix this? Any help will be appreciated. Hector C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1039338&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

lexical_cast to self
by Maxim Yegorushkin 03 Oct '04

03 Oct '04

In generic code lexical_cast<> is sometimes used as a cast to the same type. I would like to shortcut this rather then going all the way by writing it to a stream and reading back. In my code I use the following workaround: template<class U, class T> inline typename boost::disable_if<boost::is_same<T, U>, U>::type lexical_cast(T const& t) { return boost::lexical_cast<U>(t); } template<class T> inline T const& lexical_cast(T const& t) { return t; } Does it make any sense to put it in lexical_cast.hpp? -- Maxim Yegorushkin

7 12

Constrained genericity at last? (any interest in an operator traits/concept traits library?)
by Terje Slettebø 03 Oct '04

03 Oct '04

Colleagues: Are you tired of long and incomprehensible error messages when using STL, MPL, or some other modern template library? So am I! Up to now, we've had the Boost Concept Check Library, but unfortunately, you may still get long error messages with it (in the case of Intel C++ 6.0 and STLPort, pages and pages long, although the cause of the error is usually more clear, due to words like "concept_check", "function_requires", etc. showing up in the error message), and you can't overload on concepts, i.e. having several overloaded functions taking different kinds of iterators (such as std::advance). However, the invention of enable_if [HJW03] [JWL03] (now part of Boost) opened the door to overloading based on arbitrary properties of types. Now, what we needed was techniques for detecting type properties, which could be used to create "concept type traits". Using this, we could have done, e.g. for std::sort: template<class Iterator> typename enable_if<is_random_access_iterator<Iterator> >::type sort(Iterator begin, Iterator end) { // ... } Besides enable_if, there have also been other discoveries paving the way for constrained genericity (programming with concepts) in the later years. One of them being isAddable [KJSMA03], which could detect if there exists a "+" operator for the values "a" and "b" in "a + b", and gives a true/false result. The operator could be built-in, member function, or free function; it didn't matter. Other work on type property introspection in C++ has been done by other people, notably Paul Mensonides, with techniques for detecting member types, (non-static) member variables and functions, static member variables and functions, etc., using SFINAE to great effect. The original isAddable required exact overload match - no conversion on the arguments was allowed, so int + int gave true, but int + double gave false, even though 1 + 1.0 is well-formed - but using a modified version, it's possible to allow the normal promotions/conversions on the arguments, as well, letting int + double give true. In contrast, the other mentioned detection techniques requires an exact signature match, so these two ways complement each other: The exact match way may be used where the promotions/conversions way can't be used, and vice versa. Last spring (after the introduction of enable_if and isAddable) I realised that we now for the first time had discovered or invented all the components needed for a decent implementation of constrained genericity (or programming with concepts) in the current C++ language (as shown with the code example above)! I therefore started on a library of type traits for detecting the components required for concept checking, which meant detecting such things as operators, constructors (to the degree it's possible), etc. The modified isAddable is a key technique used in this "operator traits" part of the library. When this was complete, I continued with the "concept traits" part of the library, where the aim was to make type traits for all the C++ standard concepts, as well as all the Boost.MPL concepts (for the reasons that MPL is widely known and used, it's part of Boost, it could help a lot with better error messages in such metaprogramming libraries, and as an example of implementing non C++ standard concepts). I was about halfway done with the library last summer, and then I got a new job, where I became very busy, so unfortunately I couldn't continue with it at that time. However, a while ago, I've resumed work on the library, and it's now complete. Besides the mentioned enable_if, isAddable, and the introspection techniques, MPL is a core component of the library. Its lazy evaluation logical operators are indispensible for many of the concept traits, particularly the more complex ones. I couldn't have done it without any of you. Thank you. MPL is also used in the unit tests, generating the test matrix on the fly, testing each trait in a list against a list of types, and comparing the result against a table. The total number of tests generated is several thousand. Other approaches ------------------------- About a year ago, there have been proposals/discussion papers for adding support for concepts to the C++ language (see N1510, N1522 and N1536 at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/) Using this, the above example could have been written as: template<RandomAccessIterator Iterator> void sort(Iterator begin, Iterator end) { // ... } This would also ease implementation of such concept overloading, because it would include the concept of concept refinement and "best match". Using the enable_if solution is a match or no match situation: either a function or class template matches, or it doesn't. Thus, if you want to implement std::advance as several overloaded functions using enable_if, you have to do something like this: template<class Iterator,class Distance> typename enable_if< mpl::and_< mpl::or_< is_input_iterator<Iterator>, is_output_iterator<Iterator> >, mpl::not_< is_bidirectional_iterator<Iterator> > > >::type advance(Iterator i,Distance d) { while(d--!=0) ++i; } The above function template is called if Iterator is either an InputIterator or OutputIterator, but not BidirectionalIterator (or "higher"). I.e. you have to manually exclude the next higher concept in the hierarchy, since BidirectionalIterator is also an InputIterator and OutputIterator (but should then call another overloaded function, not this one). If you also have a std::advance overload for BidirectionalIterator, you would otherwise get an error about ambiguity for the overloads (as they both would match), when called with a BidirectionalIterator. Nevertheless, the operator traits/concept traits library is something that can be used _now_, and which may give us more experience with programming with concepts. If the traits are used with libraries like STL or MPL, it has the potential to give drastically better diagnostics, and thereby making them easier to use. In addition, overloading on concepts is possible. A few of the traits (is_assignable, is_default_constructible and is_copy_constructible) rely on BCCL as a "last resort" when used for user-defined types, as there is no known way of detecting these for user-defined types. The library, including documentation, examples and tests may be found at (http://home.broadpark.no/~terjesl/operator_concept_traits.zip) (Yahoo Files is full, could we perhaps remove some of the stuff there that is now part of Boost?). Here's the synopsis from the documentation: Synopsis ------------- The library contains: - 46 operator type traits, covering all the overloadable (and therefore detectable) operators, as well as detection of default constructor, copy constructor and assignment operator. - 37 C++ standard concepts type traits, covering all the concepts of the C++ standard. - 19 Boost.MPL concepts type traits, covering all the documented concepts of Boost.MPL. - Facilities for defining your own concept type traits. - A complete set of unit tests. - Example programs, demonstrating its use. ------------- Some components may duplicate existing parts of Boost (such as MPL's has_xxx.hpp for member type detection, and mpl::is_sequence), and in other cases, the library includes functionality that may better belong in existing Boost libraries (type traits and MPL), and in those known cases, it's noted in the documentation. An aim is of course to syncronise the libraries, so that duplication is avoided. There may also be other components in the library that duplicate parts of MPL (or other parts of Boost) not noted here, and I'm all ears hearing about that, so that duplication may be eliminated. The operator traits/concept traits is essentially an extension to the Boost type traits library, but due to its specialisation (detecting operators, and generic concepts), as well as its size, it may be better to have as one or more separate components. Compatibility The library has been tested on Intel C++ 7.1, MSVC 7.1 and g++ 3.2. All tests pass on Intel C++ 7.1 and MSVC 7.1. For g++ 3.2, the operator traits tests pass, but most of the concept traits fails (either at compile time, or give wrong result). I intend to work to make the library work for g++ 3.2, as well. Bibliography [HJW03] Howard Hinnant, Jaakko Järvi and Jeremiah Willcock, Function Overloading Based on Arbitrary Properties of Types (http://www.cuj.com/articles/2003/0306/) 2003 [JWL03] Jaakko Järvi, Jeremiah Willcock, Andrew Lumsdaine, boost::enable_if, 2003 [KJSMA03] Dietmar Kuehl, Jaakko Jarvi, Jeremy Siek, Mat Marcus and Dave Abrahams, isAddable (ACCU Conference 2003 slides) (Regarding the salutation, I couldn't help doing a "Mat Marcus" here (http://article.gmane.org/gmane.comp.lib.boost.devel/42877) ;) not at least since Mat is also one of the people behind isAddable, a key technique of this library) Regards, Terje P.S. For those who may be wondering where I've been all this time, the reason was the mentioned new job, which lead to me being away from more or less the C++ community for about a year, until a few months ago. P.P.S. I've also seen the last days there have been discussion on the Boost list on similar facilities (the "Proposal for 'is_dereferenceable' and other templatemetafunctions" thread started by Alex Chovanec). is_dereferenceable<T> is similar to this library's has_dereference_op<T> (in the operator traits part), except that the latter doesn't test for lvalue, etc. Moreover, some of the other existing functionality may work better than the corresponding ones in this library (like MPL's has_xxx.hpp, which, from the comments in the header file is able to detect reference member types, something this library can't), so maybe we could cooperate? P.P.P.S From libraries in the Boost Sandbox, it appears that it's ok, even common, for libraries that are not part of Boost to still use the Boost logo in the documentation. Therefore, that is done in this case, as well. I also hope John Maddock doesn't mind that I used the same kind of tables for these traits, and general style, as for the Boost type traits library. Feedback on this library is very welcome.

11 48

boost::threads' exceptions patch
by Rodolfo Schulz de Lima 03 Oct '04

03 Oct '04

Hi, I've been using boost::threads for some time now and found it to be very useful and elegant in design. The only problem I see is when it throws an exception. No information about the error is fed to the exception constructor, and all we have is a 'boost::thread_resource_error' or a 'boost::lock_error' in std::exception::what, not very helpful. Since boost::thread_exception has a constructor that accepts an error code, I've managed to patch some files and fed (where appropriate) the error code to the exception constructor so that we can have an idea of what is the cause of the exception when we catch it. Not being fully satisfied with the results (we never are), I went a little further and decided to make thread_exception inherit from std::runtime_error, and pass to its constructor an informative message about the exception. This way std::exception::what will show not only the exception class name, but also the reason of the error (if we have an error core). I've modified the other exception classes accordingly. The last thing I did was to remove thread_argument_error since we could use std::argument_error instead. In fact, this class is never used, and in the only place that it would be used, std::argument_error is used. I'd appreciate any comments about those changes... Regards, rod IMPORTANT NOTE: I've just changed the PTHREADS implementation... I do not have good background on winthreads and mptasks, so I count on anyone who knows those systems to update their implementation... // Patch follows Index: boost/thread/exceptions.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/thread/exceptions.hpp,v retrieving revision 1.14 diff -u -r1.14 exceptions.hpp --- boost/thread/exceptions.hpp 8 Sep 2004 15:57:03 -0000 1.14 +++ boost/thread/exceptions.hpp 2 Oct 2004 23:51:50 -0000 @@ -25,11 +25,11 @@ namespace boost { -class BOOST_THREAD_DECL thread_exception : public std::exception +class BOOST_THREAD_DECL thread_exception : public std::runtime_error { protected: thread_exception(); - thread_exception(int sys_err_code); + thread_exception(std::string message, int sys_err_code=0); public: ~thread_exception() throw(); @@ -48,8 +48,6 @@ lock_error(); lock_error(int sys_err_code); ~lock_error() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL thread_resource_error : public thread_exception @@ -58,8 +56,6 @@ thread_resource_error(); thread_resource_error(int sys_err_code); ~thread_resource_error() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL unsupported_thread_option : public thread_exception @@ -68,18 +64,6 @@ unsupported_thread_option(); unsupported_thread_option(int sys_err_code); ~unsupported_thread_option() throw(); - - virtual const char* what() const throw(); -}; - -class BOOST_THREAD_DECL invalid_thread_argument : public thread_exception -{ -public: - invalid_thread_argument(); - invalid_thread_argument(int sys_err_code); - ~invalid_thread_argument() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL thread_permission_error : public thread_exception @@ -88,8 +72,6 @@ thread_permission_error(); thread_permission_error(int sys_err_code); ~thread_permission_error() throw(); - - virtual const char* what() const throw(); }; } // namespace boost Index: libs/thread/src/condition.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/condition.cpp,v retrieving revision 1.20 diff -u -r1.20 condition.cpp --- libs/thread/src/condition.cpp 17 Jul 2004 04:33:59 -0000 1.20 +++ libs/thread/src/condition.cpp 2 Oct 2004 23:51:58 -0000 @@ -340,7 +340,7 @@ int res = 0; res = pthread_cond_init(&m_condition, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } condition_impl::~condition_impl() Index: libs/thread/src/exceptions.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/exceptions.cpp,v retrieving revision 1.10 diff -u -r1.10 exceptions.cpp --- libs/thread/src/exceptions.cpp 8 Sep 2004 15:56:33 -0000 1.10 +++ libs/thread/src/exceptions.cpp 2 Oct 2004 23:51:58 -0000 @@ -69,12 +69,15 @@ namespace boost { thread_exception::thread_exception() - : m_sys_err(0) + : runtime_error("boost;:thread_exception") + , m_sys_err(0) { } -thread_exception::thread_exception(int sys_err_code) - : m_sys_err(sys_err_code) +thread_exception::thread_exception(std::string message, int sys_err_code) + : std::runtime_error(message+(sys_err_code==0 + ? "" : (": "+system_message(m_sys_err)).c_str())) + , m_sys_err(sys_err_code) { } @@ -89,17 +92,16 @@ const char* thread_exception::message() const { - if (m_sys_err != 0) - return system_message(m_sys_err).c_str(); return what(); } lock_error::lock_error() + : thread_exception("boost::lock_error") { } lock_error::lock_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::lock_error",sys_err_code) { } @@ -107,17 +109,13 @@ { } -const char* lock_error::what() const throw() -{ - return "boost::lock_error"; -} - -thread_resource_error::thread_resource_error() +thread_resource_error::thread_resource_error() + : thread_exception("boost::thread_resource_error") { } thread_resource_error::thread_resource_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::thread_resource_error",sys_err_code) { } @@ -125,17 +123,13 @@ { } -const char* thread_resource_error::what() const throw() -{ - return "boost::thread_resource_error"; -} - unsupported_thread_option::unsupported_thread_option() + : thread_exception("boost::unsupported_thread_option") { } unsupported_thread_option::unsupported_thread_option(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::unsupported_thread_option",sys_err_code) { } @@ -143,35 +137,13 @@ { } -const char* unsupported_thread_option::what() const throw() -{ - return "boost::unsupported_thread_option"; -} - -invalid_thread_argument::invalid_thread_argument() -{ -} - -invalid_thread_argument::invalid_thread_argument(int sys_err_code) - : thread_exception(sys_err_code) -{ -} - -invalid_thread_argument::~invalid_thread_argument() throw() -{ -} - -const char* invalid_thread_argument::what() const throw() -{ - return "boost::invalid_thread_argument"; -} - thread_permission_error::thread_permission_error() + : thread_exception("boost::thread_permission_error") { } thread_permission_error::thread_permission_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::thread_permission_error",sys_err_code) { } @@ -179,9 +151,4 @@ { } -const char* thread_permission_error::what() const throw() -{ - return "boost::thread_permission_error"; -} - } // namespace boost Index: libs/thread/src/mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/mutex.cpp,v retrieving revision 1.19 diff -u -r1.19 mutex.cpp --- libs/thread/src/mutex.cpp 29 Jul 2004 14:25:30 -0000 1.19 +++ libs/thread/src/mutex.cpp 2 Oct 2004 23:51:58 -0000 @@ -201,7 +201,7 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } mutex::~mutex() @@ -215,7 +215,7 @@ { int res = 0; res = pthread_mutex_lock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0); } @@ -223,7 +223,7 @@ { int res = 0; res = pthread_mutex_unlock(&m_mutex); - if (res == EPERM) throw lock_error(); + if (res == EPERM) throw lock_error(res); assert(res == 0); } @@ -241,7 +241,7 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } try_mutex::~try_mutex() @@ -255,7 +255,7 @@ { int res = 0; res = pthread_mutex_lock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0); } @@ -263,7 +263,7 @@ { int res = 0; res = pthread_mutex_trylock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0 || res == EBUSY); return res == 0; } @@ -272,7 +272,7 @@ { int res = 0; res = pthread_mutex_unlock(&m_mutex); - if (res == EPERM) throw lock_error(); + if (res == EPERM) throw lock_error(res); assert(res == 0); } @@ -291,13 +291,13 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); res = pthread_cond_init(&m_condition, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } } Index: libs/thread/src/recursive_mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/recursive_mutex.cpp,v retrieving revision 1.22 diff -u -r1.22 recursive_mutex.cpp --- libs/thread/src/recursive_mutex.cpp 16 Sep 2004 17:49:16 -0000 1.22 +++ libs/thread/src/recursive_mutex.cpp 2 Oct 2004 23:52:00 -0000 @@ -300,14 +300,14 @@ assert(res == 0); } if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } # endif } @@ -377,7 +377,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) @@ -456,14 +456,14 @@ assert(res == 0); } if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } # endif } @@ -577,7 +577,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) @@ -641,13 +641,13 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } } @@ -764,7 +764,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) Index: libs/thread/src/thread.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/thread.cpp,v retrieving revision 1.18 diff -u -r1.18 thread.cpp --- libs/thread/src/thread.cpp 5 Aug 2004 17:31:14 -0000 1.18 +++ libs/thread/src/thread.cpp 2 Oct 2004 23:52:00 -0000 @@ -160,7 +160,7 @@ int res = 0; res = pthread_create(&m_thread, 0, &thread_proxy, &param); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); #elif defined(BOOST_HAS_MPTASKS) threads::mac::detail::thread_init(); threads::mac::detail::create_singletons();

1 0

Re: como results?
by Aleksey Gurtovoy 03 Oct '04

03 Oct '04

Hi Bronek, > I have not stopped running regression tests on Comeau compiler; why > its results are no longer displayed on > http://www.meta-comm.com/engineering/boost-regression/developer/summary__re… They are in the reports, but because "como-win32-4.3.3-vc7.1" toolset is not marked as "required" in "status/explicit-failures-markup.xml", they are visible in the full view (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) but not the release view. The links at the top/bottom of each page allow you to switch between two. Currently, the toolset is marked as "required" if either of the following holds: 1) The compiler/configuration is known to be widely used, and/or the majority of Boost developers is committed to supporting it. The current versions of MSVC, Intel, GCC and CodeWarrior all fall into this category. or 2) The compiler/configuration is not widely used, but there are one or more Boost delevopers who consider it important enough to be included in the release criteria, and therefore volunteer to run regression tests for it, fix/mark up its failures, and generally take responsibility for driving things towards the release at reasonable speed. "intel-win32-7.1-vc6-stlport-4.5.3" is one such example. The only reason Comeau hasn't been marked as "required" so far is that it's unclear to me what its position is in regard to these two criteria. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RFI: RMI in C++
by Francis ANDRE 03 Oct '04

03 Oct '04

Hi Listers I am looking for a good C++ package that implements something quite close to Java RMI (NO Corba/IIOP please!) , I have looked at the WWW, and the boost.org but I did not found any serious answer except the article of A Batov in the "C/C++ Users Journal" http://www.cuj.com/documents/s=8206/cujweb0304batov/ Now that the serialization library is part of boost, could this be a item to add the the wishlist at boost.org??? Regards FA

6 11

Python/Linux markup
by Aleksey Gurtovoy 02 Oct '04

02 Oct '04

Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy. -- Aleksey Gurtovoy MetaCommunications Engineering

4 19

basic_cstring_test/vacpp failure
by Gennadiy Rozental 02 Oct '04

02 Oct '04

This test fails in MPL "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp", line 57.48: 1540-0416 (S) "begin" cannot be declared because its name has already been used. "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp", line 46.13: 1540-0426 (I) The name "begin" is used on line 46 of "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp". Any chance for it to be fixed? Gennadiy.

2 1

[serialization] test_level_class_info_load*...
by Stefan Slapeta 02 Oct '04

02 Oct '04

...is marked as expected failure for all toolsets! Is this really intended? (What does us tell a test that is expected to fail everywhere?) Stefan

1 0

Detecting gcc-3.3-darwin regression build
by Michael Stevens 02 Oct '04

02 Oct '04

Dear all, Does anyone know what Boost.Build toolset is used to build these tests? I need to force an ABI version and I was assuming it was the 'darwin' toolset. However <darwin><*><cxxflags>"-fabi-version=0" is not triggering. Thanks, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

3 2

[Test] Current failures
by Aleksey Gurtovoy 02 Oct '04

02 Oct '04

Gennadiy, Could you please take a look at/comment on the current Boost.Test failures as per http://tinyurl.com/5wojs? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

5 18

test_case_template_test / borland-5.6.4
by Gennadiy Rozental 02 Oct '04

02 Oct '04

This fails due to what seems to be some compiler bug with MPL. That this test does is run following test case : template<typename Number> void test0( Number* = 0 ) { BOOST_CHECK_EQUAL( 2, Number::value ); } with all elements of following list: typedef boost::mpl::list_c<int,2,2,2,2,2,2,2> only_2; I expect 0 errors, borland produce 7, meaning that all of the comparisons fail. Any suggestions, Gennadiy.

1 0

Bad links on the web site
by Ben Hutchings 02 Oct '04

02 Oct '04

On <http://www.boost.org/more/links.htm>: "C++ Standards Committee" links to the old committee home page. This works now because of a redirection, but will presumably stop working after a while. "ANSI Store" links to the 1998 standard which is no longer available (online at least). Ben.

2 1

boost-lite
by Andy Little 02 Oct '04

02 Oct '04

Hows about a boost-lite distro? What to include? Specifically only stuff that is a candidate for standardisation. If there is anything that is 'indispensible' but not a candidate, then one should ask why. Ideally Headers only, nothing that requires separate compilation, or bjam. And under (say ) 1MB absolute max. (exclude Docs. These can be pointed via url) Just a thought .... regards Andy Little

2 1

[hash containers in files section]
by Thorsten Ottosen 02 Oct '04

02 Oct '04

Hi Jeremy, I've been working a little with your hash containers. They should definitely be fast-track reviewed! A small problem: std::distance( m.begin(), m.end() ) != m.size() after I have filled the container (more than 100k elements). Could it be due to some caching thing? best regards Thorsten

3 2

Some questions on Boost Threads
by Parameswaran, Vinod 02 Oct '04

02 Oct '04

Hello list, My name is P. Vinod and I am currently debugging an application that was initially written using single thread but later ported to multithreads. The threading has been done using Boost library functions. I am new to Boost library and would like to clarify some of my doubts with you. Please reply to vparameswaran(a)fcg.com I have been studying William Kempf's documentation on Boost threads (http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads .html) and all my questions are based on the references therein: 1. <begin quote> The template thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b oost.thread_specific_ptr.html> is useful in the following cases: * An interface was originally written assuming a single thread of control and it is being ported to a multithreaded environment. <end quote> Is there any other way by which you could port a single threaded interface to multithreaded interface using Boost threads? My debugging approach will be based on your answer to this question. 2. Does anyone have some examples of scenarios wherein each of these classes could be used (would even appreciate reference to relevant docs., if any): a. barrier b. condition c. thread_group d. thread_specific_ptr 3. Assumption: In the case of a condition object, ONLY THE FOLLOWING METHODS could be used to specify the wait condition: a. template<typename ScopedLock, typename Pred> void wait(ScopedLock& lock, Pred pred); b. template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const bool::xtime& xt); c. template<typename ScopedLock, typename Pred>bool timed_wait(ScopedLock lock, Pred pred); Is this correct? 4. <begin quote> A thread object has an associated state which is either "joinable" or "non-joinable". <end quote> Is this state indicated using a type or is merely implied by whether the default or the parameterized constructor is called for the creation of the thread object? 5. Could anyone give examples of the use of void join() and void yield()? (Would even appreciate reference to relevant docs., if any) 6. <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> Does each thread create its own 'object' referred to here and modify its thread_specific_ptr class by invoking void reset(T* p=0) ? 7. <begin quote> The template thread_specific_ptr is useful in the following cases: * Each thread of control invokes sequences of methods that share data that must be logically accessed through a globally visible access point, but are physically unique for each thread, instead of being explicitly passed. <end quote> <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> >From the above statements, I could draw the inference that the thread_specific_ptr object stores the data that is shared amongst the various methods invoked from within a thread; however this data is not shared amongst threads and is unique for each thread. <begin quote> thread_specific_ptr construct/copy/destruct 1. thread_specific_ptr(); Requires: The expression delete get() is well formed. Effects: A thread-specific data key is allocated and visible to all threads in the process. Upon creation, the value NULL will be associated with the new key in all active threads. <end quote> <begin quote> 1. ~thread_specific_ptr(); ..... For this reason you should not destroy a thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_ specific_ptr.html> object until you are certain there are no threads running that have made use of its thread specific storage. <end quote> The above statements seem to contradict the previous quotes, in that a thread-specific data key is visible to all the threads in the process and thread-specific storage is shared amongst multiple threads. Could anyone dispel the apparent ambiguity here? Also, what is the concept of "data key"? Gratefully appreciate your time and advice on the above. Vinod

2 1

Re:[boost] [Serialization] Remaining failures markup
by Robert Ramey 01 Oct '04

01 Oct '04

Aleksey Gurtovoy wrote: >Robert, >Pending msvc-stlport issue aside, I commented this accordingly. >the serialization library reports show >quite a few failures with other toolsets, in particular: > cw-9.3 > borland-5.6.4 > cw-8.3 > msvc > vc7 >I'm sure you've well aware of these; what I'd like to ask you is to >comment on them in the "explicit-failures-markup.xml" in the similar >way you commented on "*_warchive" tests, so that a) the library users >are not scared away by all these yellow cells, and b) the release >manager and everybody else besides the author have a simple way of >telling whether the library is in the OK state or not. I've been looking at this for a while procrastinated doing anything until I was sure what to do. So far this has been an effective strategy. Many times failures just disappeared as arcane tooI set issues were resolved. I still have some doubts about how to handle the remaining cases. Metrowerks compilers (cw*) seem to suffer from over-zealous optimization that eliminates static variables not referred to explicitly by name. Other compilers do this as well, but I've managed to workaround this in various ways. Cw* is the last hold out on this issue. I had hoped someone who is interested in this can test it might be motivated to look into it but it seems that there isn't enough interest. Unless I hear otherwise, I'll mark these tests as "expected". I would love to see this fixed - but for this Metrowerks would have an almost perfect showing. I do think its very high quality product that handles platforms that others don't. Its pains me that the serialization library test don't reflect this. A number of these (msvc, vc7, borland) have been determined to be manifestations of compiler deficiencies so I will mark them so. Some the borland test don't fail on my own test setup - so for me they are indeed "unexpected failures" - I think leaving this yellow is the correct characterization. That leaves a number of miscellaneous failures which really aren't understood or explained. Personally I would like to leave these as they are as to mey they really are "unexpected failures". I realize that some might be dissuaded from using the library because of this - but I think that's better than having someone use the library and not have it meet expectations. Robert Ramey

3 2

ulas / cw 8.3
by Stefan Slapeta 01 Oct '04

01 Oct '04

Is there a particular reason why ublas is marked unusable for cw 8.3? Stefan

1 0