- Boost - lists.boost.org

Re: [boost] [bitfield] More portable implementation available inthevault
by Martin Bonner 09 Mar '06

09 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: 09 March 2006 08:09 To: boost(a)lists.boost.org Subject: Re: [boost] [bitfield] More portable implementation available inthevault > "Emile Cormier" wrote >> Bitfield2.zip in >> >> http://boost-consulting.com/vault/index.php?direction=0&order=&directory =bitfield& > > Unfortunately my unzipper wont unzip it. Just says "unknown > compression > algorithm" or some such. > > regards > Andy Little Curious. Have you tried downloading it again? I have just opened it with WinZip 8.0 and it worked fine -- 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

[bitfield] More portable implementation available in the vault
by Emile Cormier 09 Mar '06

09 Mar '06

Bitfield2.zip in http://boost-consulting.com/vault/index.php?direction=0&order=&directory=bi… For now, I didn't bother to adapt my code to Boost's style. I'm using this stuff at work where we have a different coding style. Check out the html folder for the doxygen page, which shows usage examples. I removed Bitfield::operator(), as its purpose was not self-evident. I think this version will not suffer from memory alignment/padding problems as did the previous version. The test code runs fine with GCC MinGW 3.4. I plan on using it on an ARM platform, so I'll confirm if it runs okay on that platform too. Bitfield now accepts a 4th template parameter, R, which is the reference type used by Bitfield to manipulate the word. The only requirements on this reference type are: - Has a default or copy constructor, depending on how you use it - Can be assigned a value of type T - Can be evaluated as a value of type T By default, R=T&, which is convenient for manipulating regular non-I/O-mapped integers. I demonstrate in PortExample.hpp how Bitfield can be used with special types which can interface to memory-mapped I/O ports. I've just read the n1666 "Technical Report on C++ Performance", and it seems like Bitfield would be ready to support the use of <iohw.h> ports. I need to study the proposed <iohw.h> some more to fully understand it, though. I will inspect mixed source+assembly to confirm that this Bitfield mechanism is as efficient as hand-written bit-manipulations. -- Emile Cormier emilecormier(a)mailcan.com

2 1

bcbboost version 0.3 released
by Nicola Musatti 09 Mar '06

09 Mar '06

Hallo, I'd like to inform those of you that use Boost with Borland's BCB2006 product that I just released version 0.3 of bcbboost - the unofficial BCB Boost patches. This is a set of modified sources from Boost 1.33.1 that allow you to build and use some of the libraries from that release with the latest Borland compiler, bcc32 5.8.1 . Bcbboost is available from SourceForge: http://bcbboost.sourceforge.net/ This release contains improvements to date_time, call_traits, compressed_pair, math/octonion, numeric/conversion, optional, random and type_traits. Changes impact also graph, format and possibly other libraries. Many thanks to Alisdair Meredith: most of this release is a backport of the work he's done to add BCB2006 support to Boost's mainline.

2 2

[filesystem] static object throws
by Vladimir Prus 09 Mar '06

09 Mar '06

Hi, an application of mine just suddenly crashed before entering 'main', with the following stacktrace: #5 0xb7eb7106 in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0xb7e6ccb0 in std::__throw_runtime_error () from /usr/lib/libstdc++.so.5 #7 0xb7eb5c8e in std::locale::facet::_S_create_c_locale () from /usr/lib/libstdc++.so.5 #8 0xb7e96554 in std::locale::_Impl::_Impl () from /usr/lib/libstdc++.so.5 #9 0xb7e768e9 in std::locale::locale () from /usr/lib/libstdc++.so.5 #10 0xb78f6922 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /space/NM/boost/libs/filesystem/src/path.cpp:29 And the line in question contains just: 29 std::locale loc(""); This is CVS as of today. The problem was that I incorrectly set the LC_MESSAGES environment variable. However, I think that exception from static object is not so good idea. I can't catch it, so the error reporting just reads "Aborted". Maybe, this can be converted into a function with static variable, so that the static variable is only initialized on the first call? TIA, Volodya

2 4

Re: [boost] [multi_index]boost/boost/multi_index/detail/index_base.hpp:49:error
by JOAQUIN LOPEZ MU?Z 09 Mar '06

09 Mar '06

----- Mensaje original ----- De: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Fecha: Martes, Marzo 7, 2006 6:34 pm Asunto: Re: [boost][multi_index] boost/boost/multi_index/detail/index_base.hpp:49:error > On 3/6/06, Joaquín Mª López Muñoz <joaquin(a)tid.es> wrote: > > [snip] > > > > > > > typedef std::pair<iterator, iterator> iterator_pair; > > > > Here. What is this "iterator" type? What index.equal_range(name) > > returns is a > > typedef headers_multi_index_t::nth_index<1>::type::iterator iterator; [...] > Looks like that's not the problem > Yep, looks like this is OK, and, as you say, the thing works on other compilers. The following is a shot in the dark. Can replace your typedef headers_multi_index_t::nth_index<1>::type::iterator iterator; with something like typedef headers_multi_index_t::nth_index<1>::type::iterator my_iterator; // note, name changed adjust the dependent typedefs and try to compile? Older versions of GCC have sometimes clashing symbol problems with symbols that ought not to clash. Additionally, I'd check the using decls and directives in effect. If this does not shed any light, it'd be extremely helpful if you can isolate the problem into a complete testcase you can post or send to me. I've tried myself to reproduce the issue following your general code outline, but didn't get the compiler to choke as you have reported. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: [boost] bug in filesystem::wpath
by Jan Hermelink 09 Mar '06

09 Mar '06

>> As already reported in >> http://article.gmane.org/gmane.comp.lib.boost.devel/128277, >> narrow_path() doesn't work if short filename generation is disabled. As >> a workaround I have fstream.hpp patched for using the non-standard wide >> char fstream constructors in VC8 (Dinkumware library). Indeed this works >> for VC8 only... > Would you like to contribute your patch? That might be faster and easier > than waiting for me to get around to it! Shure. Patch against current CVS attached. >> Ok, I >> have seen the free function what() but what it's the rationale not >> including it in the exception object? > The what() free function provides more elaborate formatting. The member > what() function is minimal, and so doesn't have as many memory allocation > issues. The approach is take to follow the guidelines at > www.boost.org/more/error_handling.html. I see. It's a pity, it would be fine to have m_path1 and m_path2 provided by the what() member... Cheers, Jan

2 1

[bitfield] More portable implementation available in the vault
by Emile Cormier 09 Mar '06

09 Mar '06

Bitfield2.zip in http://boost-consulting.com/vault/index.php?direction=0&order=&directory=bi… For now, I didn't bother to adapt my code to Boost's style. I'm using this stuff at work where we have a different coding style. Check out the html folder for the doxygen page, which shows usage examples. I removed Bitfield::operator(), as its purpose was not self-evident. I think this version will not suffer from memory alignment/padding problems as did the previous version. The test code runs fine with GCC MinGW 3.4. I plan on using it on an ARM platform, so I'll confirm if it runs okay on that platform too. Bitfield now accepts a 4th template parameter, R, which is the reference type used by Bitfield to manipulate the word. The only requirements on this reference type are: - Has a default or copy constructor, depending on how you use it - Can be assigned a value of type T - Can be evaluated as a value of type T By default, R=T&, which is convenient for manipulating regular non-I/O-mapped integers. I demonstrate in PortExample.hpp how Bitfield can be used with special types which can interface to memory-mapped I/O ports. I've just read the n1666 "Technical Report on C++ Performance", and it seems like Bitfield would be ready to support the use of <iohw.h> ports. I need to study the proposed <iohw.h> some more to fully understand it, though. I will inspect mixed source+assembly to confirm that this Bitfield mechanism is as efficient as hand-written bit-manipulations. -- Emile Cormier emilecormier(a)mailcan.com

1 0

[Boost-bugs] [ boost-Bugs-1445983 ] Win32 windows_name() bug
by SourceForge.net 08 Mar '06

08 Mar '06

Bugs item #1445983, was opened at 2006-03-08 14:22 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=1445983&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: Win32 windows_name() bug Initial Comment: I have tried this with both Borland and MSVC ... trying to instantiate a boost::filesystem::path instance and getting the following error: Invalid name "D:" in path "D:\". One would figure that this should not happen, as that is a valid Win32 path name. My guess is the problem is the ":", since I tried "D\A", "D\A\B", "D\A\B\C", etc. and did not have any problem with them. Initially I thought is was my Borland compiler, but when it did the same thing with MSVC, then I figured that it was a bug somewhere in the library. If someone could point me in the right direction as to which particular file I need to look at I could probably fix the issue myself, but I would prefer a patch from one of the maintainers to keep the codebase the same as everyone else. Thanks. William william.clifford.mit(a)gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445983&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

yet another multimethods library
by Korcan Hussein 08 Mar '06

08 Mar '06

Hi, i'm on the verge of completing a first release of a fully featured multimethods component for C++, one in which i believe goes beyond anything currently available and is very suited to become part of boost. I'm fully aware of Jesse Jones's contribution however his library has not become an offical part of boost and i believe my version takes things much further in thew different ways and i have some nice ideas for the next version to make even better. It's inspired by boost/std::tr1::function and CLOS generic functions and thus works like bost::/std::tr1::function preferred syntax ALA function types e.g: typedef boost::shared_ptr<fuzz> fuzz_ptr; generic_function< void (const foo&, int, bar*, float, fuzz_ptr) > foobar; where foo, bar and fuzz are polymorphic types and automatically are considered for multiple dispatch, detection of which arguments are choosen for dispatch is automated (and yes there already is support for smart/proxy pointers/references in place with std::auto_ptr, boost::/std::tr1::shared/intrusive_ptr working out-the-box). The order and placement of arguments is irrelevant and non-polymorphic arguments are totally allowed, covariant return types comes for free and work similar to covariant return types of virtual member functions. I think i'll just stop writing about the library any further (abit more to it than this) i just like to know if you guys are interested in making this an offical part of boost and to be worked on further by myself and with the help of others. P.S By the way this has been built with boost mpl, preprocessor and type traits from the beginning and interlope with other boost components in mind i.e phoenix, lambda, fusion, bind, function etc, etc.

6 11

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

08 Mar '06

Patches item #1438991, was opened at 2006-02-26 04:54 Message generated for change (Settings changed) made by mclow 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: Jonathan Turkanis (turkanis) 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 13: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