- Boost - lists.boost.org

[Endian] Version 0.10 available - Binary I/O added
by Beman Dawes 16 Sep '09

16 Sep '09

Version 0.10 of the Endian Integers library is available. Docs: http://mysite.verizon.net/beman/endian-0.10/libs/integer/doc/endian.html Zip: http://mysite.verizon.net/beman/endian-0.10.zip Sandbox: http://svn.boost.org/svn/boost/sandbox/endian This version adds binary I/O for both endian integers (<boost/integer/endian_binary_stream.hpp>) and C++ built-in types + std::string (<boost/integer/endian_binary_stream.hpp>). Support for C++0x features has also been added, ensuring that an Endian integer on C++0x is a POD. Comments appreciated! My Endian TODO list is pretty well cleared, so there are comments to the contrary, the library will be submitted for formal review in a few days. --Beman

3 4

(no subject)
by Berserker 16 Sep '09

16 Sep '09

Dmitry Goncharov wrote: > The difficulty that your example demonstrates is caused by the nature > of template template parameters. scoped_ptr should not be blamed for that. I agree, moreover I think that the advantages of this patch (often required in the list) justify the 1% use cases of Andrey Semashev's sample that in my opinion can be simplified in this way: template<typename T, typename P> void make_ptr(P &p) { p.reset(new T()); } _________________________________________________________________ Scopri tutti i servizi Windows Live, guarda i video http://www.windowslive.it/videoGallery.aspx

1 0

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Andrey Semashev wrote: > I'd opt for this change if it wouldn't affect the interface in the breaking way. > Otherwise, I like the way it is. I just tested your sample and thanks to the default template value (boost::checked_deleter) it does compile. Are you sure it breaks the interface? _________________________________________________________________ Scopri tutti i servizi Windows Live, guarda i video http://www.windowslive.it/videoGallery.aspx

3 2

[lexical_cast] lexical_cast does not throw bad_lexical_cast
by Carlos Rafael Giani 15 Sep '09

15 Sep '09

Hi, I've noticed that sometimes lexical_cast does not throw bad_lexical_cast. Instead, it throws 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'. A catch clause expecting a bad_lexical_cast fails here. What seems confusing to me is that the lexical_cast docs do mention "catch (bad_lexical_cast &)" as correct code (http://www.boost.org/doc/libs/1_39_0/libs/conversion/lexical_cast.htm) The solution that worked for me was to catch boost::exception instead. Am I missing something here? I consulted the documentation, but still have no answer. It also seems that I am not alone with this problem; http://www.nabble.com/Porting-from-boost_1_33-to-boost_1_36-exception-td197… and http://archives.free.net.ph/message/20090715.183116.374b4777.en.html at least indicate this for me. regards, Carlos Rafael Giani

2 1

enabling/disabling floating point exceptions
by Gennadiy Rozental 15 Sep '09

15 Sep '09

Hi guys, I am looking to complete cross platform implementation of enabling/disabling logic in boost::execution_monitor. It looks like there is no standard interface available. I'm using _controlfp interface now on Windows. I also found these non-standard extensions: * feenableexcep/fedisableexcept available with glib 2.2 * fesettrapenable avaialble in Dinkumware (implementation of STL?) and HP * sun has something called fex_set_handling. not sure when it's available though * header fpu_control.h. Not sure where it's available though. * MAC OS X has something called _MM_SET_EXCEPTION_MASK in xmmintrin.h It also seems that in some cases the switch is compile time only (using compilation option). Would anyone care to extend this list/comment on it's applicability and/or correctness? Another change I am considering is to split floating point exception catching from other system exceptions. It seems perfectly valid scenario to set catch_system_error to false (thus avoid catching access violations etc) but still willing to catch and process floating point exception. What do you think? Gennadiy

4 4

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Stewart, Robert wrote: > I'm sorry, I read your post too quickly, seeing "shared_ptr" > where you wrote "scoped_ptr." No problem :) > That, of course, requires nothing more than a static member > function in the supplied deleter type as your proposal implies. I suggested a "deleter" (default boost::checked_deleter) instead of a static function because imho an operator()(T *p) is a preferable approach (it doesn't require a "specific" function name) and moreover boost::checked_deleter is already there :) I really hope this patch will be applied. _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

1 0

scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

I know it has been asked in the past, but I still don't understand why scoped_ptr lacks this feature. The "noncopyable nature" of scoped_ptr allows to support deleters with simply an extra template parameter (default value is boost::checked_deleter): this change doesn't require extra memory overhead (like in shared_ptr) and it consists of 2 lines. template<class T, class D = boost::checked_deleter> // first patch line class scoped_ptr { // ... public: ~scoped_ptr() { // ... deleter()(ptr); // second patch line, instead of boost::checked_delete } }; Any hope to apply this patch? _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

3 2

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

A fix to my previous post, the first patch line should be: class D = boost::checked_deleter<T> instead of: class D = boost::checked_deleter Obvously the same implementation is applicable to boost::scoped_array using boost::checked_array_deleter _________________________________________________________________ Le tue Emoticon ti sembrano poche? Scaricane di nuove! http://intrattenimento.it.msn.com/emoticon/

1 0

fixed documentation
by Frank Birbacher 14 Sep '09

14 Sep '09

Hello! I made two small changes to docs: https://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_documentation c56200 spelling in docs for graph c56201 enhancement for asio docs ip v4 and v6 to_bytes() I will notify the maintainers of the projects. Frank

1 0

non-branching min()
by DE 14 Sep '09

14 Sep '09

i'd like to present some kind of micro optimization towards pipelined cpus traditionaly min() has an implementation like template<typename type> inline type min(type a, type b) { return a<b ? a : b; } this function (even if inlined) introduces a branch in a sequence of instructions though branch prediction algorithms do exist they will guess at most 50% of them because routine input is arbitrary since a wrong branch prediction causes pipeline stall i thought that such a useful routine like min() MUST have non-stalling (read 'non-branching') implementation i thought hard and in the end recalled a simple implementation which is called LUT (for 'look-up table') here's what i finally got: template<typename type> inline type min(type a, type b) { const type c[2] = {a, b}; return c[b<a]; } intuitively this implementation should work slower than the first one but in real life it runs faster (roughly by a factor of 2 for 4 byte types on core2duo) here's a test code: #include <vector> int main() { typedef int type; const int n = 1000000; std::vector<type> v1(n), v2(n); //filling v1 and v2 somehow type min = BIG_VALUE; for (size_t i = 0; i<n; ++i) a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 return 0; } however for 'double' it runs ~2% slower (i think it's because creating a lut for 2 elements 8 bytes each is slower than a branch on c2d) nevertheless i think it's a great approach at least for ints also max() can implemented very similar you may skip the rest example of usage imagine we want to implement a symmetric matrix that stores only half of its elements (say upper triangle) a00 a01 a02 --- a11 a12 --- --- a22 then access requests to the lower triangle elements would be redirected to upper triangle ones here we have a constraint that actually we only have access to elements a(i, j) where i<=j must always be true (look at indices above) if we use a branch like //... return i<=j ? a(i, j) : a(j, i); we get a pipeline stall almost every time we want to access an arbitrary element however if we rewrite it carefully as //... const size_t m = min(i, j); //non-branching min() here return a(m, m + abs(int(i) - int(j))); //abs() is also //non-branching we get rid of branches at all! and we can hope a pipelined cpu will handle it better than the other (branched) implementation -- pavel

9 14