July 2010 - Boost - lists.preview.boost.org

Any interest in creating new CORBA IDL to C++ mapping?
by Johnny Willemsen 10 Aug '10

10 Aug '10

Hi all, We are talking with various users of TAO to see if we can create a new modern IDL to C++ mapping. The idea is to drop all old compilers which lead to the current mapping and make a new IDL to C++ mapping that is using the latest draft C++0x standard. We want to use full STL, shared_ptr, r-value, and everything else we could need. The idea is to prototype this first in TAO and than see if on the long term we can propose a new IDL to C++ V2 mapping to the OMG I did find some discussions on this list about 2 years ago, are people interested in this effort, any input is welcome. Johnny Willemsen Remedy IT www.theaceorb.nl

12 22

[1.44] Release notes
by Daniel James 09 Aug '10

09 Aug '10

Hello, If you haven't done so yet, with the beta coming out it's a good time to add your entries to the release notes so that people know what to test. You can edit the file in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. If you're able to build the release notes, I better warn you that I've changed the build system a little. Recent versions of quickbook are generating slightly different mark up, and if that's used for old entries, they can appear as new in rss feeds. So to avoid that, it now stores a hash of the quickbook files to only update their entry if the source changes. It should just work, you just need to commit the '*-hashes.txt' files at the same time as the rss files. If you want to force an update, you can delete the appropriate line in the text file. thanks, Daniel

5 7

[mpl] BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF
by Edward Diener 09 Aug '10

09 Aug '10

I found the BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF macro in the latest has_xxx.hpp of mpl on the trunk. Is BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TEMPLATE_DEF ) scheduled to be added to Boost in an upcoming release ? I find it useful for TMP introspection in much the same way as BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF ).

5 10

[intrusive] recursive intrusive data structures
by Tim Blechmann 09 Aug '10

09 Aug '10

hi all, is there an easy way to define recursive data structures? something like: struct my_node: boost::intrusive::list_base_hook<> { boost::intrusive::list<my_node> children; }; i am currently using a base class as helper, which causes very dirty code, since i explicitly need to cast from the base to the main class all over the place: struct my_node_base: boost::intrusive::list_base_hook<> {}; struct node: my_node_base { boost::intrusive::list<my_node_base> children; }; thanks, tim -- tim(a)klingt.org http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius

2 4

[bcp] Bcp namespace rename causes compile errors on multiple libraries (type_traits, range, spirit, foreach, regex, iostreams) in 1.43
by Cliff Green 04 Aug '10

04 Aug '10

Has bcp namespace renaming been tested against all Boost libraries in 1.43? I'm getting compile errors in (or caused by) the following libraries: type_traits, range, spirit, foreach, regex, iostreams (more details later in this message). The compile errors are from a full bjam build of Boost. I haven't compiled tests or built against my work project code, so I suspect there's more errors in header-only libraries. I'm using g++ 4.1.2 on Linux (although these errors are not compiler specific - I'll also be compiling with VC++ 8.0 at some point). All of these errors are easily fixed, and are "boost" text substitution problems. I was able to get all libraries to build after my changes, but I would rather not use hacked-up source (I prefer to work with the Boost developers and install non-modified Boost source into our Clearcase COTS VOB). However, with these (obvious) compile errors, I'm wondering if the bcp namespace facilities are being tested with all Boost libraries? If not, can I work with John Maddock or someone to set up a test process? Besides doing a full extract / rename and build of the libraries, as many examples and tests as possible should also be compiled to find errors in header-only libraries not brought in to the library source build. Of course it's possible all of the errors I've found have been introduced with new code in 1.43 (which still brings up the need to do a full bcp test before a Boost release), or that I somehow incorrectly used bcp, or there's fixes that haven't been applied to the mainline in SVN. My use case is a perfect fit for the bcp namespace facilities - my work team delivers an SDK (which links to and uses various Boost libraries) to another group which also links to and uses Boost libraries in their own application (everything builds into the same executable). Currently our work team is constrained to using the same Boost version, but we'd like to break this constraint (in particular, for other groups to use our SDK). We use (or will use) enough Boost libraries that bcp on the ones we care about pulls in about 80% of Boost, so I went ahead and ran bcp on all of Boost. Details of the compile failures: -- In type_traits: integral_promotion.hpp, promote.hpp, floating_point_promotion.hpp, header guard probs - original code #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_boost_type_traits_integral_promotion_hpp_INCLUDED After running bcp with "MyProj_Boost" for the namespace, the header guard is: #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_MyProj_Boost_type_traits_integral_promotion_hpp_INCLUDED -- In range/config.hpp there's two macros where bcp namespace substitution is incorrectly being applied to the "boost" prefix in boost_range_array: #define BOOST_RANGE_ARRAY_REF() (boost_range_array) #define BOOST_RANGE_ARRAY_REF() (&boost_range_array) Similarly, in range/detail/implementation_help.hpp, the following lines have incorrect substitution: boost_range_silence_warning( boost_range_array ); -- In Phoenix and Wave, there's a bit of namespace substitution problems, where "namespace phoenix" (in multiple files, such as spirit/home/classic/phoenix) is being replaced with "MyProjectphoenix", and in wave/grammars/cpp_intlit_grammer.hpp and cpp_chlit_grammar.hpp there's "namespace phx=phoenix". -- In regex/v4/regex_traits.hpp: BOOST_MPL_HAS_XXX_TRAIT_DEF(boost_extensions_tag) The "boost" prefix in boost_extensions_tag is improperly substituted. -- In foreach.hpp, "boost_foreach_argument_dependent_lookup_hack_value" is not substituted in the enum, but in macros where the enum is used, the substitution is occurring. In iostreams/close.hpp, close_boost_stream on line 143 is being improperly substituted. --- As already mentioned, there's easy changes for each of these. But, is a better answer to make the bcp search and substitution smarter? (I have no idea how easy or hard that would be.) Cliff

3 5

[GIL] color_convert
by fabien.castan＠free.fr 04 Aug '10

04 Aug '10

Hi, I use the GIL extension: HSL. I need to make conversions from hsl to other colorspaces. So I define generic default conversion using intermediate rgb colorspace. I define 2 templates: * default_color_convert<C1,hsl_t> * default_color_convert<hsl_t,C2> But it creates an ambiguity with rgba_t, because it defines the same thing for rgba_t: * default_color_convert<C1,rgba_t> * default_color_convert<rgba_t,C2> So default_color_convert<hsl_t,rgba_t> is ambiguous. The only solution I see is: * to remove default_color_convert<C1,rgba_t> * to define gray_t->rgba_t, rgb_t->rgba_t * to remove default_color_convert<C1,hsl_t> * to define default_color_convert<cmyk_t,C2> So all colorspaces have to: * define a generic conversion to another colorspace using an intermediate rgb colorspace conversion * redefine the conversion for colorspaces we want to make a direct conversion Best regards, Fabien Castan /// \ingroup ColorConvert /// \brief Converting CMYK to any pixel type. Note: Supports homogeneous pixels only. /// /// Done by an intermediate RGB conversion template <typename C2> struct default_color_converter_impl<cmyk_t,C2> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef cmyk_t C1; typedef typename channel_type<P1>::type T1; typedef typename channel_type<P2>::type T2; pixel<T2,rgb_layout_t> tmp; default_color_converter_impl<C1,rgb_t>()(src, tmp); default_color_converter_impl<rgb_t,C2>()(tmp, dst); } }; /* /// \ingroup ColorConvert /// \brief Converting any pixel type to RGBA. Note: Supports homogeneous pixels only. template <typename C1> struct default_color_converter_impl<C1,rgba_t> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef typename channel_type<P2>::type T2; pixel<T2,rgb_layout_t> tmp; default_color_converter_impl<C1,rgb_t>()(src,tmp); get_color(dst,red_t()) = get_color(tmp,red_t()); get_color(dst,green_t())= get_color(tmp,green_t()); get_color(dst,blue_t()) = get_color(tmp,blue_t()); get_color(dst,alpha_t())= channel_convert<T2>(alpha_or_max(src)); } }; */ /// \ingroup ColorConvert /// \brief Converting grayscale pixel type to RGBA. Note: Supports homogeneous pixels only. template <> struct default_color_converter_impl<gray_t,rgba_t> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef gray_t C1; typedef typename channel_type<P2>::type T2; get_color(dst,red_t()) = get_color(src,gray_color_t()); get_color(dst,green_t())= get_color(src,gray_color_t()); get_color(dst,blue_t()) = get_color(src,gray_color_t()); get_color(dst,alpha_t())= channel_convert<T2>(alpha_or_max(src)); } }; /// \ingroup ColorConvert /// \brief Converting grayscale pixel type to RGBA. Note: Supports homogeneous pixels only. template <> struct default_color_converter_impl<rgb_t,rgba_t> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef rgb_t C1; typedef typename channel_type<P2>::type T2; get_color(dst,red_t()) = get_color(src,red_t()); get_color(dst,green_t())= get_color(src,green_t()); get_color(dst,blue_t()) = get_color(src,blue_t()); get_color(dst,alpha_t())= channel_convert<T2>(alpha_or_max(src)); } }; /// \ingroup ColorConvert /// \brief Converting RGBA to any pixel type. Note: Supports homogeneous pixels only. /// /// Done by multiplying the alpha to get to RGB, then converting the RGB to the target pixel type /// Note: This may be slower if the compiler doesn't optimize out constructing/destructing a temporary RGB pixel. /// Consider rewriting if performance is an issue template <typename C2> struct default_color_converter_impl<rgba_t,C2> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef typename channel_type<P1>::type T1; default_color_converter_impl<rgb_t,C2>()( pixel<T1,rgb_layout_t>(channel_multiply(get_color(src,red_t()), get_color(src,alpha_t())), channel_multiply(get_color(src,green_t()),get_color(src,alpha_t())), channel_multiply(get_color(src,blue_t()), get_color(src,alpha_t()))) ,dst); } }; /// \ingroup ColorConvert /// \brief Converting HSL to any pixel type. Note: Supports homogeneous pixels only. /// /// Done by an intermediate RGB conversion template <typename C2> struct default_color_converter_impl<hsl_t,C2> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef hsl_t C1; typedef typename channel_type<P1>::type T1; typedef typename channel_type<P2>::type T2; pixel<T2,rgb_layout_t> tmp; default_color_converter_impl<C1,rgb_t>()(src, tmp); default_color_converter_impl<rgb_t,C2>()(tmp, dst); } }; /// \ingroup ColorConvert /// \brief Unfortunately HSL to HSL must be explicitly provided - otherwise we get ambiguous specialization error. template <> struct default_color_converter_impl<hsl_t,hsl_t> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { static_for_each(src,dst,default_channel_converter()); } };

2 2

Re: [boost] [GIL] kth_channel_view
by fabien.castan＠free.fr 03 Aug '10

03 Aug '10

>A good example of using kth_channel_view is this: > > rgb8_image_t img( 100, 100 ); > typedef typename kth_channel_view_type< 0, const rgb8_view_t>::type view_t; > view_t first = kth_channel_view<0>( const_view( img )); Another interesting possibility is: typedef kth_channel_view_type< 0, const rgb8_view_t> KthChannelView; typename KthChannelView::type first = KthChannelView::make( const_view(img) ); It can be a good thing to directly use channel type, like this: typedef channel_view_type< red_t, const rgb8_view_t>::type view_t; view_t first = channel_view<red_t>( const_view( img )); I have written some code to do that, based on kth_channel_view_type. It's maybe intersting to include in gil. Regards, Fabien namespace boost { namespace gil { template <typename Channel, typename View> struct channel_type_to_index { static const int value = gil::detail::type_to_index< typename color_space_type<View>::type, // color (mpl::vector) Channel // channel type >::type::value; //< index of the channel in the color (mpl::vector) }; template <typename Channel, typename View> struct channel_view_type : public kth_channel_view_type<channel_type_to_index<Channel,View>::value, View> { static const int index = channel_type_to_index<Channel,View>::value; typedef kth_channel_view_type<index, View> parent_t; typedef typename parent_t::type type; static type make(const View& src) { return parent_t::make(src); } }; /// \ingroup ImageViewTransformationsKthChannel template <typename Channel, typename View> typename channel_view_type<Channel,View>::type channel_view(const View& src) { return channel_view_type<Channel,View>::make(src); } }}

2 1

Any interest in trap_exceptions functionality?
by Andy Venikov 02 Aug '10

02 Aug '10

Hi, I often find myself wanting a generic way to catch and process exceptions. For example, imaging having to export "C" interface from a C++ library. You would create a bunch of extern "C" functions that would invoke the right C++ code. One of the things that needs to be done in every such function is to catch and process all exceptions. Most of the exceptions-handling code would look the same or very similar (the same list of exceptions to catch, same way to handle given exception types). C++ to C is not the only place where you'd need this. Most of the module boundaries might want to trap exceptions. The first thing that developers do in these cases is they start generalizing the handling part. I.e., you'd create a separate function/functor that would handle an exception of a certain kind. Unfortunately it still leaves you with a barage of try/catch() statements in every function that doesn't want to leak exceptions. This creates not only the unpleasant look of a lot of catches (one might argue this point), but it creates a lot of repetition - you need to create catch statement for every exception you want to handle. It would be nice if I could assemble all the exceptions I want to handle (honoring their order) and the way to handle them in one single place under a single object. And then invoke that object on all functions that need to be called. I recently took a crack at this task and came up with a generic way to trap exception. Here's a brief API: trap_exceptions(<list-of-exception-handlers>); The previous line would create a callable object. The parameters are a variable number of exceptions handlers that could be either function pointers, references to functions or functors. One thing they have in common though is the signature: the signature should be "void(T)", where T is the type of the exception that the handler will handle. This "T" type is what the trap_exceptions-created callable object will use in the "catch" statements. Other important notes: the order of handlers is important as this will be the order of "catch" statements (i.e., trap_exceptions(HandleBase, HandleDerived) will hide all Derived exceptions). Whether the exception is caught by reference or by value is also controlled by the handler's signature. Signature "void()" means catch all exceptions indiscriminately. Specifying an empty parameter list will also mean to catch all exceptions indiscriminately. The result of the trap_exceptions call can be assigned to a variable: auto ex_trap = trap_exceptions(HandleEx1, HandleEx2, HandleEx3); //BOOST_AUTO can be used too. And I think it will be possible to use //it without registering HandleEx1 etc.) This object can now be used on multiple functions of any arity and any return type. Functors are supported too. ex_trap(func1); //will create a delayed-call object that upon invocation will call func1 and catch exceptions Ex1, Ex2 and Ex3 So, if func1 has signature int(int, char*, float), then ex_trap(func1)(1, "abc", .5); will call function func1 with the given set of arguments and catch afore-mentioned exceptions. The return type undergoes a significant transformation though. Since the return from this delayed function call now returns more information than before (the additional part being whether an exception has been thrown or not), this additional information is conveyed through the use of boost::optional. In the case of ex_trap+func1, the result will be boost::optional<int>. Functions/functors returning void have a special treatment though since unfortunately it's illegal to instantiate boost::optional<void>. For functions that return void, the return type of the delayed call will be a simple bool. There are some return types that have a special value that indicates "error" and could be used to indicate that an exception occured. In this case, just for convenience purposes, it'll be possible to specify this value and the return type will become the return type of the inner function, not optional<T>. I.e: //Let's say that -1 can be used to indicate that an exception has //occured, then ex_trap(func1, -1)(1, "abc", .5);//will have a return type of int. //-1 will be returned if an exception has been thrown and now all places that had return func1(1, "abc", .5); could simply be replaced with return ex_trap(func1, -1)(1, "abc", .5); //without using boost::optional I think one other use of this functionality can be in functional-style programming in C++. While it's trivial to convert syntactic constructs like "if", "while", "switch", and "for" to functional representations (i.e. if_(f1(), f2(), f3()); which means if (f1()) f2(); else f3(); ), it's a lot harder to create a functional representation of try/catch construct. trap_exceptions is an attempt at that. To illustrate that point more, say we have a tuple (or a fusion-like container) which contains a collection of functions/functors. Using fusion::transform it's possible to add certain qualities to these functions. With trap_exceptions, it'll be possible to add a "no exception leak" quality to this set of functions. Do you think a functionality like that will be useful for boost? Any comments are appreciated. Thanks, Andy. P.S. Currently I implemented this functionality in terms of C++0x. But I think it should be possible to use Boost to make it C++03 compatible.

3 5

Proposal for New Multiple-Precision/ Arbitrary-Precision Numbers Library
by Reetesh Mukul 02 Aug '10

02 Aug '10

Hi, I know the purposes and necessities of a Multiple-Precision and Arbitrary Precision Numbers Library in C++ have echoed many a times in BOOST mail chain. Moreover in past and in present many such efforts have been on to address these needs( Google SoC, XINT, and many others ). I too have a long, consistent interest in this area and so is this proposal. I am putting some of the points in Q & A format. Q. What does Numbers mean here ? A. As a long standing definition, Numbers would mean a “Set”. However for most of the practical reasons, and in particular in relation to Natural Numbers/Integers, it would mean a set with Peano’s Arithmetic or Principle Ideal Domain or Finite Field ( ‘or’ here is in inclusive sense). In most of the cases these Sets will be generated out of Rings. As an example, Natural Numbers can be created by mapping Set of “unsigned int”s (which can be treated as Finite Field) to an Indexed Family of “unsigned int”. One such mapping is “radix” (a0 + a1*r + a2*r^2 + a3*r^3+ ...) based arithmetic. Clearly the library has long term intention to provide support for such mappings which has flavors of being generic. Q. What does Multiple-Precision and Arbitrary precision means here ? A. If the cardinality of indexing set (mentioned above) is finite and known at compile time then it will be the case of multiple-precision else it will be arbitrary precision. Both Arbitrary and Fixed precision have a meaning that they are multiple of a unit precision. We will use the term multiple-precision as an alias to fixed precision, however I see chances of debate over this topic. In its implementation paradigms, the current library has notions of multiple-fixed-precision and multiple-unfixed-precision. In current writing I am denoting multiple-fixed-precision as fixed/multiple precision while multiple-unfixed-precision as arbitrary-precision. That multiple-precision maps to cardinality of indexing set additionally asserts that unit of computation will be Elements of Rings of a given kind and bits/bytes will be of particular interest only. To give additional meaning to finiteness of multiple-precision arithmetic, like specifying it in terms of bits, bytes or range of values that the generated number would have, will mean creating compositions of mapping described in last question. Q.What are some basic APIs that the library will expose? A. This is yet to be finalized. However some design paradigms are settled. I already described the core Mathematics in last two questions. There will be a conception of “varch”(Virtual Architecture). This would mean providing a set of functions like mov, add, addto, or, xor, ... which underlying processor provides. Thus one can do - addto(unsigned int* dest, unsigned int* src, unsigned int n), which adds “src” to “dest” (like operator+=) assuming “unsigned int” is a “finite field” and the “pointers” and “n” means n-sized indexed family of “unsigned int”. Definitely there will be “addto”s corresponding to each of the Ring and Mappings. The “arithmetic concepts” corresponding to each “addto” will be deduced based on types involved, and in case “arithmetic concepts” thus deduced are ill-formed or wrong or void, compile time errors will be generated. These varch functions will be provide very low level interface(with respect to intended library) and internally they will be fine-tuned for underlying processor, system, compiler and algorithms. Numbers will be represented as an object via a kernel called basic_mint (which in turn will use varch’s function):- template<typename SignedType=varch::U, typename IntegerType=unsigned int, std::size_t InitialSize=0, precision::value_type P=default_precision<InitialSize>::value, typename IntegerTraits=integer_traits<IntegerType>, typename Allocator=allocator<IntegerType> > struct basic_mint; Further there will be conception of “generators” which will handle Algebra of underlying types. Q. How much is done ? A. Not much. However some of the above ideas have been implemented. One can see pieces of codes here:- http://sourceforge.net/p/spring-math/svn/. A very large portion of code is to be implemented. I thought, before I go too far, too far where design and implementation buckles, I should get “concept-check” by BOOST Gurus. Q. Will it be wrapped around GMP ? A. No, No and No. C++ has richer Algebraic content. Q. Is there any final API where user can use it the way int/char/float are used is specified. A. Not yet. But at most it will be a thin compile time wrapper around basic_mint. Q. Why I came here? A. For guidelines, help, ideas, warnings, disciplines, lectures, volunteers and inherent desire to register initials of my work :). With Regards, Reetesh Mukul

3 4

[MPL] More lazy evaluation, for ease of use?
by jcarey＠jcarey.best.vwh.net 02 Aug '10

02 Aug '10

According to Boost MPL documentation, "Every Integral Constant is also a nullary Metafunction, returning itself." Put another way: redundant evaluation of an Integral Constant is harmless. This handy guarantee encourages Metafunctions to evaluate their integral arguments upon demand. As others have pointed out before, such lazy evaluation reduces "typename ...::type" syntactic clutter, makes it easier to avoid instantiating a template with parameters it does not support, and tends to increase compilation speed. However, other Boost MPL concepts do not impose this self-return requirement, and many Boost MPL standard data types do not provide such a guarantee. In particular, I think it would be helpful if all Sequences, Iterators, and Lambda Expressions were also nullary Metafunctions returning themselves. (In particular, it would be nice if generic containers designed for lazy data could accommodate Lambda Expressions.) Furthermore, it would be helpful if more standard Metafunctions evaluated their arguments. In particular, if boost::mpl::eval_if were to evaluate its condition argument, then nested ifs would be much easier to write, because nested conditions would not have to be legal for all template parameters. Perhaps the reason for not evaluating certain arguments is backward compatibility? Personally, I think the convenience of widespread lazy evaluation would outweigh the costs of a transition to new Metafunctions and concepts. In particular, uniform lazy evaluation would reduce the burden on beginners to figure out which arguments must be evaluated, and which must *not* be evaluated. Instead, beginners could learn the simple rule to leave arguments unevaluated unless there is some good, documented reason to do otherwise. One special note: It is useful for MPL Metafunctions to be able to reason about arbitrary C++ types, even if those types do not happen to be nullary Metafunctions. For example, a canonical use of MPL is to compute the type returned by a function template. To that end, we could wrap arbitrary types just as we wrap integral values in Integral Constant types, and then unwrap them only at need. For example, we could define: template< typename X > struct box { typedef box type; typedef X content; }; template< typename B > struct open : B::type::content {}; and then compute with "box" instances instead of raw types, and apply "open" only when a raw type is actually required. What do you all think?

4 4

[ptr_container] ptr_vector transfer from C array of pointers documentation
by Number Cruncher 02 Aug '10

02 Aug '10

The documentation for ptr_vector::transfer( iterator before, T** from, size_type size, bool delete_from = true ) implies that the operation "delete [] from" is executed, but having examined the source, I don't think it is. This is actually the behaviour I need. I'm trying to convert a std::vector<T*> to a boost::ptr_vector<T*>, i.e. I have a vector of pointers which is solely responsible for "owning" the objects being pointed to, and I want to create a ptr_vector which will automatically clean up the objects when it goes out of scope. I need to do the transfer so that no memory leaks in the event of an exception. As far as I can see, this is exactly what ptr_vector::scoped_deleter is doing: it will delete any of the copied pointers, but it never actually deletes the "from" pointer; presumably because you don't know whether operator new[] was used when allocating it. Can anyone clear up/confirm that this will work: std::vector<T*> v1; v1.push_back(new T); boost::ptr_vector<T> v2; if (!v1.empty()) { v2.transfer(v2.end(), &v1[0], v1.size(), true); } // from this point, don't care about v1 and v2 will handle deletion of T objs Thanks, Simon

2 2

[date_time] Constructing ptime object from ISO 8601 compliant strings
by Rush Manbert 31 Jul '10

31 Jul '10

A variation on this question was asked by Allen Cronce back in May, but I didn't see any answer posted. The Posix Time description begins: "Defines a non-adjusted time system..." I assume that this means it is not adjusted for time zone? I need to construct ptimes from ISO 8601 compliant strings that may contain time zone information, such as this: "2010-08-17 12:34:56-07:00" If I constructed a ptime using this string, then used to_iso_string() to convert it to a string, I would expect to see "2010-08-17T19:34:56", but I don't. Rather, what I see is "2010-08-17T12:34:56" because the time zone portion of the string was ignored. Does anyone have a suggestion for dealing with this situation? I have some ideas, but would be interested to hear what others have done. Thanks, Rush

1 0

Please, remove me from Trac and maintainers.txt
by Gennaro Prota 30 Jul '10

30 Jul '10

Hi, I received a notification for the following Trac ticket. <https://svn.boost.org/trac/boost/ticket/4495> Apparently this request <http://lists.boost.org/Archives/boost/2010/06/168338.php> got just ignored, so I'll try to be clearer: I don't want to have anything to do with Boost; can anyone put an end to this annoyance? Thanks. -- Gennaro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 5

Patches for OpenVMS support for Boost (Asio mostly)
by Artyom 30 Jul '10

30 Jul '10

Hello, I want to submit patches for Boost, mostly Asio for better support of OpenVMS IA64 for 32 and 64 bit builds. The fixes come from an organization I work for that prefers to stay anonymous for security reasons. We've mostly concerned about Boost.Asio and we've managed to compile and run all Boost.Asio unit tests actually giving VMS very good Asio support. The fixes cover several independent libraries that should be fixed in order to make them compile: - Boost.Asio - mostly, configuration and 64 bit quirks - Boost.Test - 64 bit issues and compiler issues. - Boost.Config - added new vms.hpp platform config. - Boost.DateTime - 64 bit fixes. - Boost.Thread - compiler issues workarounds. - Boost.Function - 64 bit fixes as sizeof(size_t) < sizeof(void *); I understand that many library maintainers should be involved in integration of these patch. And it is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler. Questions: - How should I submit so wide patch that covers many libraries? Artyom. P.S.: The patch is attached.

4 10

[context] new version
by Oliver Kowalke 30 Jul '10

30 Jul '10

I've uploaded a new version which takes care of the FLS on Windows. Oliver

2 4

[interprocess] Superfluous "volatile" in atomic_add_unless32
by Capehart, Nolan 29 Jul '10

29 Jul '10

In this: inline bool atomic_add_unless32(volatile boost::uint32_t *mem, boost::uint32_t value, volatile boost::uint32_t unless_this) I think "volatile" on the last argument has no purpose and probably reduces speed slightly. Will it not merely cause the compiler to fetch the formal argument from memory every time it's needed? And isn't that of no use since nothing is modifying the formal argument during the function execution? So: 1) Caller puts actual argument on stack. 2) Caller calls atomic_add_unless32. 3) atomic_add_unless32 treats stack variable as volatile, wasting time (not much) because variable isn't actually changing.

1 0

[gsoc] boost.heap update
by Tim Blechmann 29 Jul '10

29 Jul '10

hi all, i've uploaded a new snapshot of boost.heap. it includes some of the proposed changes and i have also added a benchmark sections. during the final time for the gsoc, i'd like to get the library ready for a review ... therefore, i uploaded a new snapshot [1] and an updated documentation [2]. feedback welcome ... cheers, tim [1] http://tim.klingt.org/code/attachments/download/31/boost_heap_280710.tar.gz [2] http://tim.klingt.org/boost_heap -- tim(a)klingt.org http://tim.klingt.org Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs

3 8

Phoenix3 port to proto complete
by Thomas Heller 29 Jul '10

29 Jul '10

Ladies and Gentlemen, I proudly announce that the port of phoenix3 is completed! All testcases pass! (some with minor modifications) So, What is next? Here is my proposed schedule: - fix some minor issues - improve boost.bind compatibility: make all boost.bind testcases pass - implement all boost.lambda testcases and make them pass, as far as it is reasonable - add support for C++0x lambdas - make interoperability testcases for std::function, boost::function - adapt the documentation - clean up code (some parts are a little messy as of now) - improve compile time Did I miss something? This is a very tight schedule, I may not be able to finish all points during the GSoC period. Any help will be appreciated. Additionally a review of the current code is highly appreciated to point out some defects that might exist. The code can be checked out at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3 I will be happy to answer your questions! Additionally I would like to thank Joel de Guzman and Eric Niebler for their great assistance and initial designs! Best Regards, Thomas Heller

16 37

review request for boost.context
by Oliver Kowalke 29 Jul '10

29 Jul '10

Hello John, hello Ronald, could you add boost.context to the review queue please. boost.context allows to switch between execution contexts. The state of the context which will be left is saved and maybe resumed later. It is a kind of POSIX ucontext (fallback on POSIX platforms for boost.context) but provides assembler for some platforms (faster and some platforms doesn't implement POSIX ucontext because it is deprecaded -> ARM). thanks an best regards, Oliver

10 29

[Boost] [Thread] Query: Stack Size
by Alapkumar Sinha 29 Jul '10

29 Jul '10

Hi, How can I change the default stack size for each new thread being created? Secondly is there a mechanism to set the stack size while creation? I read somewhere that the default stack size is 8MB which is heavy for my application. Please suggest. Regards, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

3 4

[Interprocess] Query on Message queue
by Alapkumar Sinha 29 Jul '10

29 Jul '10

Hi, I have a requirement to have message type based receiving functionality, like the one provided by linux ipc "ssize_t msgrcv(int msqid, struct msgbuf *msgp, size_t msgsz, long msgtyp, int msgflg); " But the messagequeue implementation in boost only allows to set a priority of the message and does not provide a mechanism to wait on a messagequeue based on message type. Can someone tell me if there is a way out to get the above functionalities through boost as well. Regards, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

1 0

[serialization] Padding for base64 dataflow iterators ?
by Timothy Madden 29 Jul '10

29 Jul '10

Hello Could the documentation page for dataflow iterators in the serialization library please state that: 1. using base64 iterators will /not/ add the padding '=' characters in the encoded data, that are present in the canonical encoding in RFC4648 (The Base16, Base32, and Base64 Data Encodings) ? 2. binary string to be encoded should be null-terminated, or the iterators will not pad the input stream of bits with 0s to reach a multiple of 6 bits, but rather use whatever bits follow after the last encoded byte in memory ? Just so the user knows she either has to ensure padding, or otherwise she should not expect the result to exactly follow the RFC, and the result might not be suitable for data interchange between applications, etc ... Or maybe the examples could be changed to include padding, which would be even better ... :) Thank you, Timothy Madden

2 2

[placeholders]
by Andrzej Krzemienski 29 Jul '10

29 Jul '10

Hi, I have a problem with Boost.Bind placeholders. Namely, once I include the <boost/bind.hpp> it automatically brings placeholders _1, _2, .. into scope and I cannot use placeholders from other libraries like Spirit.Qi any more. I.e. I can but I need to qualify them like qi::_1, qi::_2, which is annoying. I include <boost/bind.hpp> in a precompiled header, so I have no option of not including it. Boost.Bind could define them in namespace boost::bind_placeholders and we could control their visibility with namespace using directive. This is what Spirit does, and it is cute. I guess I would not be able to convince anyone that Bind should do the same. But would it be possible to define placeholders _1, _2, ... as something more generic in Boost, unrelated to any particular library? Then boost::bind, would treat it as its own placeholders, Spirit semantic actions would treat them as its own placeholders, but they would be exactly same placeholders. Regards, &rzej

5 5

[interprocess] cmake files on trunk
by Eric Niebler 28 Jul '10

28 Jul '10

Looks like some CMake build files were inadvertently committed to boost trunk (changeset https://svn.boost.org/trac/boost/changeset/64331) I say "inadvertent" because there's no way these files can work in isolation, considering that all other CMake support has been removed from boost trunk. Ion, can you please remove these files? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

thread_safe_ptr class interest request
by Philippe Vaucher 28 Jul '10

28 Jul '10

Hello, I've made a thread_safe_ptr class available at http://codepad.org/PxDEGaFm The idea is to use it like so: std::string data = "Hello world;"; thread_safe_ptr<std::string> data_ptr(&data); void thread1() { data_ptr->resize(3); } void thread2() { *data_ptr = "yeah"; } boost::thread t1(&thread1); boost::thread t2(&thread1); t1.join(); t2.join(); Do you see an obvious show-stopper for me not to continue developping this class? What's still to be done is worry about ownership of objects, my idea is to eventually somewhat model it after boost::shared_ptr that way it's easier to pass those around. When I'll be satisfied with the result, my plan is to "boostify" it (namespaces, license etc) and maybe propose it for inclusion in the smart pointer library. What are your thoughts? Philippe

4 5