- Boost - lists.boost.org

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

[Range] Interest in range concept checks
by Daniel Walker 07 Mar '06

07 Mar '06

Hello, I've been using the Boost Range library a lot lately and felt the need for some compile-time concept checks. They're pretty simple to write using the Boost Concept Check library. So, I wrote concept checking classes for the four range concepts mentioned in the documentation. To illustrate their usage, the following checks if a type X models the ForwardRange concept. function_requires<ForwardRangeConcept<X> >(); I've been checking the value access property of the range separately using iterator concept checks on the range's iterator. So, for a ForwardReadableRange ... function_requires<ForwardRangeConcept<X> >(); function_requires< ReadableIteratorConcept< typename range_iterator<X>::type > >(); Implementing the concept checking classes is pretty straight forward using the range documentation. As an example, here's my implementation for BidierctionalRange. template<typename X> struct BidirectionalRangeConcept { typedef typename range_reverse_iterator<X>::type range_reverse_iterator; typedef typename range_const_reverse_iterator<X>::type range_const_reverse_iterator; void constraints() { function_requires<ForwardRangeConcept<X> >(); function_requires< boost_concepts::BidirectionalTraversalConcept< typename range_iterator<X>::type > >(); i = rbegin(a); i = rend(a); const_constraints(a); } void const_constraints(const X& a) { ci = rbegin(a); ci = rend(a); } X a; range_reverse_iterator i; range_const_reverse_iterator ci; }; Anyway, I hope there's enough interest to include concept checks like these in the Boost Range library for a future release. I'd be glad to submit a file containing my implementations. Please, let me know what you think! Thanks, Daniel Walker

3 3

[bitfield] Initial bitfield proposal available in the vault
by Emile Cormier 06 Mar '06

06 Mar '06

You can download the code at the Boost vault: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=b… test.cpp contains a regression test that you can try on your compiler. Please let me know if it works, as I've only tested this on MinGW GCC 3.4. 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. Let me know if things aren't sufficiently self-explanatory, or if things can be improved. -- Emile Cormier emilecormier(a)mailcan.com

1 0

[regression] what happened to the sun compiler?
by Thorsten Ottosen 06 Mar '06

06 Mar '06

Hi, I used to be able to see the regression results for sun's compiler. It seems to be gone, but why? -Thorsten

1 0