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

Cannot close ticket #2373
by Christian Henning 04 Aug '10

04 Aug '10

Hi there, it's been a while since I used trac. When I updated ticket #2373 there were no option for closing the ticket. Do I have to login somewhere? My username is chhenning Regards, Christian

2 3

[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

[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