- Boost - lists.boost.org

[type_erasure] any and shared_ptr
by Christophe Henry 16 Oct '12

16 Oct '12

Hi Steven, I need to use the associated types but don't get them to do what I need. Consider struct Pointee : public boost::enable_shared_from_this<Pointee> { void foo() { std::cout << "Pointee::foo called" << std::endl; //shared_from_this(); std::cout << "Pointee::foo end" << std::endl; } }; Pointee needs to be enable_shared_from_this for some reason, which forces me to use it in a shared_ptr. I reused your pointee / pointer structures: template<class T> struct pointee { typedef typename mpl::eval_if< boost::type_erasure::is_placeholder<T>, mpl::identity<void>, boost::pointee<T> >::type type; }; template<class T = _self> struct pointer : mpl::vector< copy_constructible<T>, dereferenceable<deduced<pointee<T> >&, T> > { typedef deduced<pointee<T> > element_type; }; I (naively) tried to define a pointee concept: typedef mpl::vector< pointer<>, same_type<pointer<>::element_type,_a >, relaxed_match, has_foo<void()> > PointeeConcept; // will not compile, shared_ptr<Pointee> has no foo... boost::shared_ptr<Pointee> p (new Pointee) ; any<PointeeConcept> ap (p); ap.foo(); So in the end I had to resort to a wrapper: struct PointeeWrap { PointeeWrap(boost::shared_ptr<Pointee>p):myPointee(p){} void foo() { std::cout << "PointeeWrap::foo called" << std::endl; myPointee->foo(); } boost::shared_ptr<Pointee> myPointee; }; BOOST_TYPE_ERASURE_MEMBER((has_foo), foo, 0); typedef any< mpl::vector< relaxed_match, copy_constructible<>, has_foo<void()> > > AnyPointee; boost::shared_ptr<Pointee> p (new Pointee); PointeeWrap wrap(p); AnyPointee ap(wrap); ap.foo(); But this will become tedious with an increasing number of members. Is there a better way? Thanks, Christophe

2 2

[mpl] Nested BOOST_MPL_ASSERT fails on VC11
by Steven Watanabe 15 Oct '12

15 Oct '12

AMDG I just ran into the following bug: template<class T> struct test : T { BOOST_MPL_ASSERT((T)); }; BOOST_MPL_ASSERT((test<T>)); I've reworked BOOST_MPL_ASSERT to avoid the problem in the attached patch. Okay to commit? In Christ, Steven Watanabe

3 4

[GIL] default_color_converter from float to integer should clamp
by Fabien Castan 15 Oct '12

15 Oct '12

Hi, The conversion from floating point image to 8 bits or 16 bits image should clamp instead of writing arbitrary values... // a floating point image, with some pixel values < 0.0 and > 1.0 boost::gil::rgba32f_view_t HDR; // use default_color_converter to convert this HDR image to 8 bits boost::gil::png_write_view( "LDR.png", boost::gil::color_converted_view<boost::gil::rgba8_pixel_t>( HDR ) ); The 8 bits LDR image contains arbitrary cast conversion values, that are not very nice. The conversion from floating point to integer values has no other valid solution than clamping. So I suggest this patch, for the file "boost/gil/channel_algorithm.hpp": @@ -272,7 +272,13 @@ template <typename DstChannelV> struct channel_converter_unsigned<bits32f,DstChannelV> : public std::unary_function<bits32f,DstChannelV> { DstChannelV operator()(bits32f x) const { typedef typename detail::unsigned_integral_max_value< DstChannelV >::value_type dst_integer_t; - return DstChannelV( static_cast< dst_integer_t >(x*channel_traits<DstChannelV>::max_value()+0.5f )); + + const bits32f convertedValue = x * channel_traits<DstChannelV>::max_value() + 0.5f; + const bits32f clampedValue = std::min( + (bits32f)channel_traits<DstChannelV>::max_value(), + std::max( (bits32f)channel_traits<DstChannelV>::min_value(), convertedValue ) ); + + return DstChannelV( static_cast< dst_integer_t >(clampedValue) ); } }; Regards, Fabien Castan

3 2

[asio::ssl] TLS support
by ToBeKi＠gmx.de 15 Oct '12

15 Oct '12

Hello all, in asio::ssl context/context_base i couldn't find any TLS 1.1/1.2 method implementations. Is it missing/not supported yet? If so is there a roadmap supporting versions 1.1/1.2? Best, kito

1 0

[config] call to destructor of temporary
by Vicente J. Botet Escriba 15 Oct '12

15 Oct '12

Hi, I have had some trouble debugging some code with clang-2.9 c++0x. The reason was a known bug on the compiler as it doesn't call the destructor of temporaries at the end of the expression. Is there a macro stating this missing feature? Best, Vicente

4 4

maybe a bug in boost.iostreams
by leiming2006 15 Oct '12

15 Oct '12

Hello, I'm using boost 1.5.1 in windows 7 with vc 2010 express. today I'm trying using boost.iostreams with audio samples, whose char_type is not char or wchar_t. thought I failed at the end, but I guess that I found a bug in the library. In the file boost\iostreams\chain.hpp, line 136, I wonder if it's typedef linked_streambuf<Ch, Tr> streambuf_type; not typedef linked_streambuf<Ch> streambuf_type; Regards, LeiMing

1 0

[program options] Support for storage to 'optional' objects
by Chris Glover 15 Oct '12

15 Oct '12

Hi, Recently when using the Boost Program options library, I was surprised to find that I was unable to pass a boost.optional object to store supplied options in. For example; namespace bpo = boost::program_options; boost::optional<std::string> opt_str; bpo::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("opt", bpo::value(&opt_str), "Something optional") // Store value of 'opt' in 'opt_str' ; What I expected to happen would be that 'opt_str' would be valid if 'opt' is supplied by the user, and not valid otherwise. However, the above code causes a compile error deep within lexical_cast because, of course, performing such an operation on a boost.optional doesn't make sense. The attached patch to Program Options rectifies the issue by filtering out optional objects within before calling lexical_cast, but to be honest, I'm not sure if this is the correct approach or if this is even a desirable feature. I like the idea of setting an optional object this way instead of testing the variables_map later on, but perhaps there's something I am missing or a better way to accomplish the same thing. Please have a look and let me know your thoughts. Thanks, -- chris

1 0

[contract] concepts: pseudo-signatures vs. usage patterns
by Lorenzo Caminiti 14 Oct '12

14 Oct '12

On Tue, Oct 9, 2012 at 7:16 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote: >> >> I made a first attempt to sketch how N3351-like concepts will look >> into Boost.Contract (just for the find algorithm and its concepts for >> now): >> [...] >> Please tell me what you think now > > Since you asked what I think, > > "pseudo-signatures > usage patterns" Hello all, Can we write down pros and cons for concepts implemented via pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns (N3351 and Boost.Contract)? Who wants to start? Matt, Dave, Andrzej, ... I can compile a qbk table with what we discuss. Thanks. --Lorenzo

10 68

[quickbook] Cross-Referencing Source-Snippets
by Matt Calabrese 14 Oct '12

14 Oct '12

I'm currently documenting the Generic library and the documentation itself imports a lot of code from the source files directly (the best documentation for a concept generally involves showing the concept definition itself, and importing it means the code won't be out of sync with the documentation). This imported source code references other concepts and I'd like to be able to have each one of these referenced concepts be a clickable link that brings the person to the documentation for that concept (I.E. in http://generic.nfshost.com/generic/standard_concepts/concepts/equivalencere… the user should be able to click on "Predicate" in the imported source code to see the documentation for the Predicate concept). So, I tried the simplest solution -- make a quickbook macro called Predicate that results in a link to the corresponding Predicate documentation. After a quick test, everything worked fine with one exception -- the name of the section linked to is also "Predicate" and that seems to be causing the link in the generated table of contents to no longer work properly, pointing to a page that doesn't exist even though it displays the link with the proper name (note that the cross-reference links still seem to work fine, it's just the links in the table of contents that break). I realize that I'm doing something hacky here, so if anyone has a better solution, let me know. If this is the best approach, is there a way that I can keep the name of the section the same as the macro name? I.E. Is there some trick I can use to prevent the macro from being expanded when I use it in the section declaration? Keep in mind that I can't simply use templates here instead of macros because the macros are expanded from within imported, working code snippets. I also can't postpone defining the macro until after the section is declared since sections are presented in alphabetical order, meaning that an earlier section's code may reference a later section's code based on dependencies. -- -Matt Calabrese

2 2

[pointee] partially specialize for pointer types?
by Jeffrey Lee Hellrung, Jr. 14 Oct '12

14 Oct '12

Right now, boost::pointee<T*> is evaluated to T via evaluation of boost::detail::is_incrementable<T*>. Unfortunately, this causes a hard error when T is incomplete. See [1] for motivation on why this might be undesirable. It seems there's no loss in partially specializing boost::pointee for pointer types to allow it to be used for incomplete types. Ditto for boost::indirect_reference. Are there issues with this that I might be missing? As both pointee and indirect_reference seem to fall under the purview of Boost.Iterator, I would take responsibility of making this change and adding appropriate unit tests for the incomplete type case. - Jeff [1] https://svn.boost.org/trac/boost/ticket/5965

1 0