- Boost - lists.boost.org

[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

[program_options] unknown positional option
by Jeffrey Finkelstein 04 Aug '10

04 Aug '10

Here is some code slightly modified from an example in the documentation for boost::program_options. <code> #include <iostream> #include <vector> #include <string> #include <boost/program_options/positional_options.hpp> #include <boost/program_options/variables_map.hpp> #include <boost/program_options/parsers.hpp> namespace po = boost::program_options; int main(int argc, char ** argv) { po::positional_options_description desc; desc.add("files", -1); std::cout << "Declared positional options." << std::endl; po::variables_map vm; po::store(po::command_line_parser(argc, argv).positional(desc).run(), vm); std::cout << "Stored command line arguments into vm." << std::endl; po::notify(vm); std::cout << "Notified vm that all args have been parsed" << std::endl; std::cout << " num files specified: " << vm.count("files") << std::endl; std::vector<std::string> files = vm["files"].as<std::vector<std::string> >(); for (unsigned int i = 0; i < files.size(); ++i) { std::cout << "file: " << files[i] << std::endl; } return 0; } </code> Linking with version 1.40, the above code, when run with the command line arguments "hello world", produces the following output: <shell> Declared positional options. terminate called after throwing an instance of 'boost::exception_detail::clone_\ impl<boost::exception_detail::error_info_injector<boost::program_options::unkno\ wn_option> >' what(): unknown option files Aborted </shell> Linking with version 1.43, the above code, when run with the command line arguments "hello world", produces the following output: <shell> Declared positional options. Segmentation fault </shell> Am I missing something about how to use positional arguments with this library? I am using Ubuntu 10.04 on x86. The 1.40 version of boost::program_options was installed through the repositories, I compiled the 1.43 version manually. Jeffrey

1 0

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

[mpl] has_xxx.hpp potential problem
by Edward Diener 03 Aug '10

03 Aug '10

I am looking at the trunk version of has_xxx.hpp. The macros BOOST_MPL_HAS_MEMBER_TEMPLATE_SUBSTITUTE_PARAMETER and BOOST_MPL_HAS_MEMBER_TEMPLATE_ACCESS appear to be not defined anywhere. This is OK for the first because it is actually not used anywhere to generate code, although it is being passed around to other macros. If it serves no purpose, perhaps it should be removed as it then only serves to obfuscate the code, unless of course there are future plans to define it. The second, however, is being used to generate code in one instance dependent on some version of a compiler, so it needs to be defined somewhere or else an error will occur. Please check this out if this is going into 1.44.

2 2

[asio][thread] asio and future callbacks
by Will Manley 03 Aug '10

03 Aug '10

Hi All I was thinking of implementing a futures service following the asio model of callbacks. This would essentially allow integrating use of futures in the event based model of asio. I would imagine a class like: class futures_service { public: futures_service(io_service& msg_queue); /// Register for a callback when the value contained in that /// future is ready. When the future is ready the handler will /// get posted to the message queue in a manner equivalent to /// calling io_service::dispatch. /// /// Handler should be a functor with the signature: /// void (Future_T&); template <class Future_T, class Handler> void wait_for_async(Future_T future, Handler cb); }; The futures_service could be implemented using the same techniques as boost::wait_for_any (thus would require access to private members of the boost::future classes. I have not come across anything like this in the boost libraries (either in asio or threads). Has this been considered and rejected for some reason? Would boost be interested in it if I were to write it? Which library would it go into, thread or asio? Thanks Will PS. I posted this to the asio and threads lists but got no response so I'm trying here

1 0

[test]Copy-paste error in unit test documentation
by Benoit 03 Aug '10

03 Aug '10

Hi ! Just wanted to tell you that there is a small copy-paste mistake in http://www.boost.org/doc/libs/1_36_0/libs/test/doc/html/utf/user-guide/runt… (and following versions) "Command line argument name : build_info" in tab "detect_memory_leak" should be replaced by "Command line argument name : detect_memory_leak" Keep up the good work ! Benoît

1 0

[Random] make_variate_ref proposal
by Mostafa 03 Aug '10

03 Aug '10

I propose adding a make_variate_ref helper function to Random library to save typing, so I don't have retype the Distribution type twice, and to help with accidentally forgetting to put "&" in the template parameter. Something along the lines of: template<typename Engine, typename Distribution> class boost::variate_generator<Engine &, Distribution &> make_variate_ref(Engine & engine, Distribution & dist) { boost::variate_generator<Engine &, Distribution &> variate(engine, dist); return variate; } What are your thoughts. -Mostafa

2 3

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

02 Aug '10

> On 8/2/2010 09:00 David Abrahams wrote: > > On Jul 31, 2010, at 2:46 PM, Larry Evans wrote: > > The http://groups.yahoo.com/group/boost/files/LazyMPL/ mentioned > > in that post is no longer there. Anybody have a copy they'd > > care to post to vault so other's can have a look? > > Really wanting to close the vault--Anyone can get a GitHub account. > Here's a link: http://github.com/dabrahams/mpl0x/downloads Thanks; Vesa Karvonen's LazyMPL library is exactly the kind of thing that I am looking for. > On 7/31/2010 13:26 David Abrahams wrote: > On Jul 30, 2010, at 6:48 PM, jcarey(a)jcarey.best.vwh.net wrote: > > > > 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.) > > Not sure what you mean by that last part, ... LazyMPL supplies some ready-made examples: // boost/lmp/pair.hpp: namespace boost { namespace lmp { template<class L> struct first { typedef typename first<typename L::eval>::eval eval; }; template<class H, class T> struct first<pair<H, T> > { // [***Note the "H::eval", which makes // "first<pair<H, T> >::eval" the same // C++ type as "H::eval". That way we // can use first<pair<H, T> > in place // of H in any lazy context. --John] typedef typename H::eval eval; }; } // boost/lmp/op.hpp: namespace boost { namespace lmp { template<template<class> class F> struct op_1 { // [***Because op_1<F>::eval aliases op1_<F>, // "first<pair<op_1<F>, T> >::eval::template with" // works just like "F". Thus we can put functions // in lazy pairs without any special fuss. --John] typedef op_1 eval; template<class X0> struct with { typedef typename F<X0>::eval eval; }; }; } > but you might have a look at Vesa Karvonen's post: > http://lists.boost.org/Archives/boost/2004/10/74984.php > and the ensuing thread, oh, and the update. Actually, > maybe http://tinyurl.com/lazympl is the best place to look. ... [Omitting performance discussion and sieve example.] Off hand I am not sure what the performance trouble would be; it deserves a deeper look, and I wanted to answer other points right away. Meanwhile, let me just mention that the thread included some questions about strictness analysis; and though it is an oversimplification, I think a rule of thumb one could start off with is: "Pre-evaluate an argument if you know that it will be evaluated before return." -- John

1 0

[context][fiber] context migration
by Charlls Quarra 02 Aug '10

02 Aug '10

Hi, I have a question about context; basically it seems that all the yield functionality can be done by simply calling jump_to on the calling context. is that right? I've also been trying to figure out exactly what functionality does fiber implements on top of it; it seems that fiber migration (to another kernel thread? another process?) is implemented (or eventually will be implemented) here? thanks for any lights on this, Charles J. Quarra

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