- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1445242 ] read_write_mutex missing in release?
by SourceForge.net 08 Mar '06

08 Mar '06

Bugs item #1445242, was opened at 2006-03-08 01:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Ãbelacker (huafbauer) Assigned to: Nobody/Anonymous (nobody) Summary: read_write_mutex missing in release? Initial Comment: Is there a reason for removing this files from the release package for at least version 1.33.1? (They are even tagged for version 1.33.1) read_write_mutex.hpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/read_write_m… read_write_lock.hpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/detail/read_… read_write_mutex.cpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/thread/src/read_writ… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445242&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1438991 ] rational::operator<(rational) fails due to overflow
by SourceForge.net 07 Mar '06

07 Mar '06

Patches item #1438991, was opened at 2006-02-26 07:54 Message generated for change (Comment added) made by dbenbenn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1438991&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: rational::operator<(rational) fails due to overflow Initial Comment: Consider boost::rational<long>. Pick two objects of that type at random (that's well defined, since there are only finitely many objects of that type), and pick them to both have the same sign. Call them a and b. Then the expression "a < b" returns the wrong value 50% of the time! The problem is that the calculation in rational.hpp can overflow, and that overflow actually happens most of the time. Here's a patch that implements operator< without overflow. It's somewhat less efficient (I haven't benchmarked it) but it gives the right answer. Possibly the new version of operator< has bugs. I've run a few hundred million random tests, with the right answer every time (I've used bc to check the answers), but there might be a subtle problem. In particular, the new code assumes that integer division always truncates towards 0, even when dividing negative integers. Perhaps that is not true on some obscure platforms/compilers? ---------------------------------------------------------------------- >Comment By: David Benbennick (dbenbenn) Date: 2006-03-07 16:08 Message: Logged In: YES user_id=95581 Here's a new patch that uses std::numeric_limits to select the more efficient, direct comparison method for unbounded types, and only uses the overflow-avoiding method for types that can overflow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1438991&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[parameter] Binding type.
by Rene Rivera 07 Mar '06

07 Mar '06

I've been Boost.Parameter a bit by now and I have some usability feedback. There is one thing that currently bugs be a bit, the type defined by parameter::binding. All my uses so far have been of the form: typedef typename boost::remove_reference< boost::remove_const< boost::parameter::binding<ArgPack,tag::something>::type >::type >::type something_t; something_t s = args[something]; Or equivalent thereof. So every use I have I end up removing the ref and const because I'm really interested in the original type, and hence want to make a copy. Now I understand the rational outlined in "Eliminating Copies" <http://www.boost.org/libs/parameter/doc/html/index.html#eliminating-copies>. But I think that isn't enough of a justification for dirtying up the user interface, as above. I'd rather that the binding type where the value type so that one would have: typedef typename boost::parameter::binding<ArgPack,tag::something>::type something_t; something_t s = args[something]; Having it that way one still has the option of more naturally using the reference type as; something_t const & q = args[something]; And possibly also providing the container standard binding::value_type, and binding::const_reference. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 5

Re: [boost] [bitfield] Initial bitfield proposal available inthevault
by Martin Bonner 07 Mar '06

07 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: 07 March 2006 15:14 To: boost(a)lists.boost.org Subject: Re: [boost] [bitfield] Initial bitfield proposal available inthevault > "Martin Bonner" <martin.bonner(a)pitechnology.com> wrote in message > news:D997BF79D1E92C4793B7FCC04B4F90A51D79B6@pigeon.pi.local... >> ----Original Message---- >> From: Emile Cormier >> >>> The bitfield mechanism relies on this assumption: Unions of >>> non-polymorphic, non-derived objects, having the exact same >>> underlying data member type, will have the same size as this >>> underlying data member type. I'm no language lawyer, so please let >>> me know if this is a safe and portable assumption. >> >> I'm not quite sure what you mean, but given: >> struct a { unsigned char ch; }; >> struct b { unsigned char ch; }; >> union u { a theA; b theB }; >> then you are not guaranteed that sizeof(u) == sizeof(unsigned char). > > Though in practise you can use: > > BOOST_STATIC_ASSERT(sizeof(u) == sizeof(unsigned char)) My point was exactly that you CANNOT use that. (On a certain class of machine). > >> On word addressed machines (which /are/ still being built), it is >> almost certain that the minimum size for a struct is a complete >> word. This is because the C and C++ standards effectively promise >> that pointers to structs are all of the same size (the size of a >> pointer-to-struct does not depend on the contents of the struct). >> It is desirable that a pointer-to-struct be the smaller, >> cheaper-to-dereference pointer to word (rather than the larger >> more-expensive-to-dereference pointer to char), so the smallest >> struct has to occupy a whole word. > > I dont see why the size of a pointer to a struct affects the size of > a struct which in the case of an empty struct is often 1 byte? I don't think you have understood what a word addressed machine is! On most modern archictectures there are 8 bits stored at (for example) 0x100 and another 8 bits at 0x101. The 32 bits at 0x100 cover 0x100, 0x101, 0x102, and 0x103. On a word addressed machine, there may be 36 bits stored at 02000 and another (different) 36 bits stored at 02001. A simple 36-bit pointer can address individual words, but not sub-units within those words. To address individual bytes, you need a double-word pointer. One word identifies the word, and a few bits within the second word identifies which byte you are addressing. On such a machine, it makes sense for an empty struct to occupy a whole word (which is four nine-bit bytes), so that a pointer to struct can (always) be a single word pointer. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[signals + function] tiny style fix
by Pavel Vozenilek 07 Mar '06

07 Mar '06

Latest CVS: boost.signal.hpp: #define BOOST_SIGNALS_MAX_ARGS 10 ==>> #ifndef BOOST_SIGNALS_MAX_ARGS # define BOOST_SIGNALS_MAX_ARGS 10 #endif -------------------- function/function_base.hpp: a style correction (#include ".." -> #include <..>): #ifndef BOOST_NO_SFINAE # include "boost/utility/enable_if.hpp" #else # include "boost/mpl/bool.hpp" #endif ==>> #ifndef BOOST_NO_SFINAE # include <boost/utility/enable_if.hpp> #else # include <boost/mpl/bool.hpp> #endif /Pavel

1 0

[multi_index] boost/boost/multi_index/detail/index_base.hpp:49: error
by Felipe Magno de Almeida 07 Mar '06

07 Mar '06

Hi, I'm having a compiler error with gcc 3.4.4. It compiles cleanly with VC7.1 and gcc4.1. I'm using the CVS version of boost. The code is: header_decode_type and header_encode_type types dont really matter, are just member variables that are passed to header constructor. header headers::operator[](std::string const& name) const // line 57 { headers_multi_index_t::nth_index<1>::type const& index = headers_set_.get<1>(); return header(index.equal_range(name) , header_decode_handler_, header_encode_handler_); } The headers_multi_index_t is: typedef std::pair<std::string, std::string> pair; typedef mi::multi_index_container<pair , mi::indexed_by < mi::sequenced<> , mi::ordered_non_unique < BOOST_MULTI_INDEX_MEMBER(pair, std::string, first) , iless > > > headers_multi_index_t; And the header constructor is: typedef std::pair<iterator, iterator> iterator_pair; header(iterator_pair pair , header_decode_type const& header_decode_handler , header_encode_type const& header_encode_handler); The error message is: ../src/headers.cpp: In member function `mail::header mail::headers::operator[](const std::string&) const': ../../../libs/boost/boost/multi_index/detail/index_base.hpp:49: error: `typedef struct boost::multi_index::detail::index_node_base<mail::pair> boost::multi_index::detail::index_base<mail::pair, boost::multi_index::indexed_by<boost::multi_index::sequenced<boost::multi_index::tag<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >, boost::multi_index::ordered_non_unique<boost::multi_index::member<mail::pair, std::string, &std::pair<std::string, std::string>::first>, mail::iless, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<mail::pair> >::node_type' is protected ../src/headers.cpp:61: error: within this context Any help would be greatly apreaciated, best regards. -- Felipe Magno de Almeida

2 2

Re: [boost] [1.34] Branch for release
by Sylvester-Bradley, Gareth 07 Mar '06

07 Mar '06

> unless there are major issues I'm not sure what counts as major, but I guess most of the issues I raised for Boost.Iostreams probably aren't (given the lack of replies to my previous mail: http://tinyurl.com/mah8f)? IMHO the significant performance problem I reported then for streams on Seekable Indirect Devices *is* a big issue. Is anyone else interested in this issue (or any of the others) and/or reviewing my patch (it maybe too simplistic to cover all use-cases)? FWIW, in a real world test case, using * stream<file_descriptor> (from 1.33.1) resulted in total read bytes of ~250 MB * std::fstream resulted in total read bytes of ~8 MB * patched indirect_streambuf resulted in total read byte of ~8 MB Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sonys global policies and standards

2 1

[Boost-bugs] [ boost-Bugs-1444697 ] change_extension throw an invalid name exception
by SourceForge.net 07 Mar '06

07 Mar '06

Bugs item #1444697, was opened at 2006-03-07 01:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444697&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: filesystem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Beman Dawes (beman_dawes) Summary: change_extension throw an invalid name exception Initial Comment: path change_extension(const path& ph, const std::string& new_extension) { return ph.branch_path() / basename(ph) + new_extension; } If we try with this code : string str = "toto titi.exe"; path p(str, native); path p2 = change_extension(p, ".txt"); Then in change_extension, basename will return a string, and / operator will throw an invalid name as "toto titi" is not a valid path. I made this correction : path change_extension(const path& ph, const std::string& new_extension) { return ph.branch_path() / path(basename(ph) + new_extension, native); } And it seems to be ok now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444697&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Using Threads: Compile Error
by Agarwal, Abhishek 07 Mar '06

07 Mar '06

Hello All, I am new to boost and hence i would like to ask a few questions on multi threading feature of this library. I am ataching a program can some one help to find out why i am getting this error as given follows Master.cpp: In member function `void master::Master::createt()': Master.cpp:17: error: no matching function for call to `boost::thread::thread(<unknown type>)' /opt/boost/include/boost-1_33_1/boost/thread/thread.hpp:35: note: candidates are: boost::thread::thread(const boost::thread&) /opt/boost/include/boost-1_33_1/boost/thread/thread.hpp:38: note: boost::thread::thread(const boost::function0<void, std::allocator<boost::function_base> >&) /opt/boost/include/boost-1_33_1/boost/thread/thread.hpp:37: note: boost::thread::thread() Thanks Abhishek

2 1

[python, v2] select_from_python_test
by Vladimir Prus 07 Mar '06

07 Mar '06

Dave, I really need your help with one of the two remaining Python failures with msvc/Boost.Build V2. The select_from_python_test fails in the recent run with: .\libs\python\src\converter\type_id.cpp(194) : error C2491: 'boost::python::operator`<<'' : definition of dllimport function not allowed See: http://tinyurl.com/grnmg I don't quite understand what this means and why this happens on one test. Can you look into this? Thanks, Volodya

2 2