- Boost - lists.boost.org

Generic try, catch in boost::lexical_cast
by Jeroen Habraken 20 May '11

20 May '11

Hi, Whilst updating SVN today I spotted a change to boost::lexical_cast, https://svn.boost.org/trac/boost/changeset/71958, which introduces a try { } catch(...) { } construction. I'm curious as to why this catch-all is needed since it seems to be there to deal with boost::numeric_cast exceptions and whether it could lead to a std::bad_alloc being rethrown as a bad_lexical_cast. Kind regards, Jeroen Habraken

3 5

[local] this_ or _this?
by Lorenzo Caminiti 19 May '11

19 May '11

Hello all, Boost.Local uses a special name `this_` to access the object `this` bound from the enclosing scope. Shall this name be `this_` or `_this` according to Boost practices? struct c { void g(int x) { ... } void f() { void BOOST_LOCAL_FUNCTION_PARAMS( (int x) (bind this) ) { this_->g(x); // <<<<<<<<< Shall this be `_this->g(x);` instead? ... } BOOST_LOCAL_FUNCTIO_NAME(l) ... } ... }; In particular, some library uses _ postfix for statements like mpl::if_ (not mpl::_if) while other uses _ prefix for variables like phoenix::local_names::_f (not local_names::f_). Thanks a lot. -- Lorenzo

12 21

Forum created for IDL to C++0x work
by Johnny Willemsen 19 May '11

19 May '11

Hi, Last year I posted on the boost list about ideas for a new IDL to C++0x language binding for CORBA/CCM/DDS. The OMG has issued a RFP for this (see www.omg.org) In order to share technical ideas, we have opened a forum on http://www.orbzone.org, the community portal for Corba, CCM, and related middleware technologies. If you have any ideas, please share them on ORBzone. Regards, Johnny Willemsen Remedy IT

1 0

anonymous svn checkout
by Mathieu Champlon 19 May '11

19 May '11

Hi, http://svn.boost.org/svn/boost seems to be asking for credentials, is it on purpose ? Thanks, MAT.

1 1

Fwd: [ICL] some improvement proposals
by Denis 19 May '11

19 May '11

Hi 1. (questionable because it changes the visible interface): rename `left_open` and `right_open` to `right_closed` and `left_closed`. Reason: interval_bounds is used in bitwise operations with bit=1 means `closed`. `left_closed() | open()` resulting in `left_closed()` is more readable than `right_open() | open()` resulting in `left_closed()`. Also, there are checkers `is_left_closed()` and `is_right_closed()` but not for *_open I had to use `class bounded_value` in my program (as in Icl details: calculating lower and upper bound of interval separately, then constructing the interval, bitwise or'ing bounds) and I commented every usage of `right_open()` as `left closed` in order to explain why I use `interval_bounds::*right*_open()` in constructing the *left `*bounded_value` of the interval. This resulted in the idea of renaming. Maybe making bit=1 mean `open` would be less painful for other users ? 2. define `contains(interval, elt)` as `!below(interval, elt) && !above(interval, elt)` allowing the user to use `below()` and `above()`. Sometimes it is useful. Anyway, all the versions of `contains()` are made of checking for both bounds. 3. It would nice if the functions taking two intervals will have versions taking an element as second argument. I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all the list at the moment) Constructing temporary `close_interval` object in order only to pass it into those functions is cheap with ints but would be expensive with heap-allocated domains (blobs, strings, etc).

1 0

[iostreams] OK to patch Mac OS X config problem?
by Beman Dawes 19 May '11

19 May '11

The following path fixes a problem that causes a B-tree compile failure on Mac OS X. Does anyone know any reason not to apply this? --Beman PS: Thanks to Marshall Clow for testing this. --- C:\Users\Beman\AppData\Local\Temp\rtl.hpp-revBASE.svn000.tmp.hpp 2011-05-18 22:23:07.000000000 -0400 +++ C:\boost\trunk\boost\iostreams\detail\config\rtl.hpp 2011-05-18 22:21:21.000000000 -0400 @@ -42,13 +42,13 @@ # define BOOST_IOSTREAMS_FD_OFFSET __int64 # else // Borland, Metrowerks, ... # define BOOST_IOSTREAMS_FD_SEEK lseek # define BOOST_IOSTREAMS_FD_OFFSET long # endif #else // Non-windows -# if defined(_LARGEFILE64_SOURCE) && \ +# if defined(_LARGEFILE64_SOURCE) && !defined(__APPLE__) && \ (!defined(_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64) || \ defined(_AIX) && !defined(_LARGE_FILES) || \ defined(BOOST_IOSTREAMS_HAS_LARGE_FILE_EXTENSIONS) /**/ /* Systems with transitional extensions for large file support */

1 0

[boostcon][proto] Suggestion for LIAW session: fixed-point numbers
by Ravi 19 May '11

19 May '11

Hi, Are there any proto-based ideas for the library-in-a-week sessions? If not, would building a fixed-point data type be of interest? The domain is narrow enough that something useful can be accomplished in 4 sessions, but of large enough scope to present opportunities for exploring proto in depth. A fairly simple design follows representing a number: fixed_number<int width, int ulp, // 2^{ulp} is the smallest increment possible bool signed, template assigner<first, last, signed> > 'assigner' handles rounding/truncation/wrapping/etc when assigning another number (floating-point or fixed-point) to the current one. Internally, each fixed-point number would be represented by a boost::uint64_t or a boost::int64_t (limiting the maximum precision allowed). As an example, fixed_number<5, -3, false> would represent a data type that would go from 0 to 3.875 in steps of 0.125. Proto would be used for creating all arithmetic operations since the return type of a+b could be different from the type of either a or b. A bonus would involve getting the fixed-point data type to play well with std::complex (and, yes, I am aware that std::complex is not designed to work with anything other than double and float, and will require specialization in the std namespace). If there is sufficient interest, I could even provide a starting point with +,-,* implemented; / would take more time. The design above is intended as a starting point for discussion and I am most definitely not wedded to it. I am a tyro when it comes to proto, and hence would need someone with more proto expertise to guide the discussion. Regards, Ravi

8 24

[mutex] move / merge
by Phil Bouchard 18 May '11

18 May '11

Hi, Although Block Pointer is now thread safe it could use some optimization. To do so it'll need some special operations on mutexes such as move and merge. The operations need to be atomic as well. I was wondering if this was already attempted. Thanks, -Phil

5 15

Bug #3831
by Chris Wilson 18 May '11

18 May '11

Hi there, I'm attempting to use the JSON parser to read in a JSON file, but I am running up against the problem described in bug #3831<https://svn.boost.org/trac/boost/ticket/3831>, even though this bug has been marked as fixed. The milestone on the ticket is marked as 'Boost 1.42.0', but is has a score through it and I'm not sure if that means it's been fixed in that milestone or if it's been retargeted at a different milestone. I am using version 1.42.0-4ubuntu2 of the libraries so I am wondering if I have an outdated installation, or if there's another reason why I don't have the patched version. Can anyone shed some light this please? Thanks, Chris

3 3

[range] strange behavior of operator== with iterator_range
by Bryce Lelbach 18 May '11

18 May '11

Can someone tell me if the behavior demonstrated in the following program is intentional or a bug in Boost.Range? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

3 2