May 2012 - Boost - lists.preview.boost.org

[bind][phoenix] unified placeholders, yea or nay?
by Eric Niebler 29 May '12

29 May '12

I'm considering taking on as a side project the unification of the bind and phoenix placeholders, a perennial source of confusion and annoyance. I hesitate before beginning because it necessarily introduces some complexity into boost.bind, a very small, simple, and light-weight library. In particular, the unification would: 1) Cause boost.bind to depend on boost.proto. (I would do what I could to keep that dependency as slight as possible.) 2) Could not be supported on all platforms; e.g. not on borland or (gcc < 4) where the placeholders are actually static inline functions(!). (Peter, is this an ODR thing?) 3) Would introduce Phoenix behaviors into Bind, insofar as _1 is a lambda such that _1(42) evaluates to 42. At this point, it's not obvious to me that the benefits outweigh the costs. Opinions? Peter, I'd especially like to hear your thoughts. -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 13

Re: [boost] [Intrusive] Cleaning up trailing white space
by Brian Wood 29 May '12

29 May '12

Olaf van der Spek <ml(a)vdspek.org> On Thu, May 17, 2012 at 1:12 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> This is probably the easiest way to improve Boost. ?I hope authors will > Really? Why? It can be done with a simple sed script and applied either to individual libraries or all of Boost. It's a small detail, but I hope it gets some attention. I brought it to Ion's attention as I use the Intrusive library and take a number of steps to reduce the need for new hardware. I won't stop using the library if he doesn't do this, but the squeaky wheel gets the oil. Cheers, Brian Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

10 16

[bind]bind question
by Max 28 May '12

28 May '12

Hi, I have the following code: bool do_something_conditional(int *handle, const boost::function<bool(int)> &pred); bool pred_a(int handle); bool pred_b(int handle, int n1, int n2); bool do_something(int *handle, int n1, int n2) { return do_something_conditional(handle, boost::bind(std::logical_and<bool>(), boost::not1(&pred_a), boost::bind(&pred_b, _1, n1, n2))); } But it does not compile. I have been not playing with bind stuff for some time. But I've reviewed the doc and some of my old 'bind' code, it seems correct to me. The error message, you know, is quite complicated for me to find a direct answer. Could anybody please help me? Thanks in advance. I'm using 1.39 with MS VS2008SP1 Best regards Max

4 6

[GettingStarted] request for adding Boost.Chrono
by Vicente J. Botet Escriba 28 May '12

28 May '12

Hi, could Boost.Chrono be added to the list of libraries that need to be built in http://www.boost.org/doc/libs/1_49_0/more/getting_started/windows.html#head… Best, Vicente

1 0

[io_base-utilities] Request for interest and/or comments.
by Vicente J. Botet Escriba 28 May '12

28 May '12

Hi, While refactoring the Boost.Chrono IO (version 2) I've created some utilities that could be of general use. * Manipulator Mixin It is is based on http://www.angelikalanger.com/Articles/Cuj/05.Manipulators/Manipulators.html. http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/manip_base.hpp defines a class manip that can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; * std::ios_base Specific Pointers std::ios_base allows to create specific pointers indexed by xalloc() and retrieved by pword(). http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/ios_base_state… defines a class ios_state_ptr class that provides the same interface that a smart ptr with some minor adaptations to a std::ios_base. template <typename Tag, typename T> class ios_state_ptr; The type T must be CopyConstructible. This class must be used as follows struct mytag {} struct myT { int i; }; ios_state_ptr<mytag, myT > ptr(ios); if (! ptr) { ptr.reset(new myT); } ptr->i =0; This class is not thread_safe and should be protected as other io functions if the user needs to use them in a multi-threaded environment; The user can use also ios_state_ptr for classes T that are DefaultConstructible, so that the type is created implicitly if not already created. ios_state_not_null_ptr<mytag, myT > ptr(ios); ptr->i =0; This class is not thread_safe. Boost.Chrono use it as follows namespace chrono { namespace detail { template<typename CharT> struct ios_base_data_aux { std::basic_string<CharT> time_fmt; std::basic_string<CharT> duration_fmt; public: ios_base_data_aux() : time_fmt(""), duration_fmt("") {} }; template<typename CharT> struct ios_base_data {}; } // namespace detail template<typename CharT> static inline std::basic_string<CharT> get_time_fmt(std::ios_base & ios) { ios_state_not_null_ptr<detail::ios_base_data<CharT>, detail::ios_base_data_aux<CharT> > ptr(ios); return ptr->time_fmt; } template<typename CharT> static inline void set_time_fmt(std::ios_base& ios, std::basic_string< CharT> const& fmt) { ios_state_not_null_ptr<detail::ios_base_data<CharT>, detail::ios_base_data_aux<CharT> > ptr(ios); ptr->time_fmt = fmt; } } The internal single call to xalloc should be done before main() to be thread safe. The library provide a initializer class xalloc_key_initializer that takes as parameter a tag class. namespace chrono { namespace detail { namespace /**/ { xalloc_key_initializer<detail::ios_base_data<char> > ios_base_data_aux_xalloc_key_initializer; xalloc_key_initializer<detail::ios_base_data<wchar_t> > wios_base_data_aux_xalloc_key_initializer; #if BOOST_CHRONO_HAS_UNICODE_SUPPORT xalloc_key_initializer<detail::ios_base_data<char16_t> > u16ios_base_data_aux_xalloc_key_initializer; xalloc_key_initializer<detail::ios_base_data<char32_t> > u32ios_base_data_aux_xalloc_key_initializer; #endif } // namespace } } * ios_flags ios_base allows also to create specific pointers indexed by xalloc() and retrieved by iword(). http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/ios_base_state… defines a class template <typename Final> class ios_flags; providing an interface similar to "27.5.3.2 ios_base state functions [fmtflags.state] fmtflags flags() const; Returns: The format control information for both input and output. fmtflags flags(fmtflags fmtfl); Postcondition: fmtfl == flags(). Returns: The previous value of flags(). fmtflags setf(fmtflags fmtfl); Effects: Sets fmtfl in flags(). Returns: The previous value of flags(). fmtflags setf(fmtflags fmtfl, fmtflags mask); Effects: Clears mask in flags(), sets fmtfl & mask in flags(). Returns: The previous value of flags(). void unsetf(fmtflags mask); Effects: Clears mask in flags() " and that creates implicitly the index of the ios_base::iword() function once for a specific ios_flags<Final>. For example, Boost.Chrono use it as follows to store the use_symbol and use_local flags. class fmt_masks : public ios_flags<fmt_masks> { typedef ios_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; duration_style get_duration_style() { return (flags() & uses_symbol) ? duration_style::symbol : duration_style::prefix; } void set_duration_style(duration_style style) { if (style == duration_style::symbol) setf(uses_symbol); else unsetf(uses_symbol); } timezone get_timezone() { return (flags() & uses_local) ? timezone::local : timezone::utc; } void set_timezone(timezone tz) { if (tz == timezone::local) setf(uses_local); else unsetf(uses_local); } }; The internal single call to xalloc should be done before main() to be thread safe. The library provide a initializer class namespace detail { namespace /**/ { xalloc_key_initializer<fmt_masks > fmt_masks_xalloc_key_initializer; } // namespace } // namespace detail Do you see a design flaw on the design of these classes? Is there an interest to include them in Boost? Could these classes be associated iostreams? Best, Vicente

1 0

Sophisticated Email Virus
by Richard Scott 28 May '12

28 May '12

Good Afternoon All, Early this morning, I was the victim of a email virus which may have captured your email address from my address book. Hopefully, my antivirus software prevented that. If you receive a very terse but generally plausible message from me exhorting you to open an unnamed web site link, DO NOT open that link. This message might be transmitted from a third site using my email address. It will attempt to capture your email addresses and possibly information of an unknown sort and retransmit it to a third site for subsequent use. This could happen either immediately or months from now. For my part, my messages are generally not overly short or cryptic and I generally employ named links. Richard Scott

2 1

[1.50] [Config] Enhancing support of -fno-rtti on clang
by Michel Morin 27 May '12

27 May '12

When using clang with -fno-rtti, the use of `typeid` results in either compile-time errors or run-time errors. But Boost.Config did not define BOOST_NO_TYPEID for that case. So, for example, including any client header of BOOST_SP_TYPEID produced compiler errors on clang trunk with -fno-rtti. This was fixed in r78510 about a week ago: (http://svn.boost.org/trac/boost/changeset/78510) -#if !__has_feature(cxx_rtti) +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_RTTI) # define BOOST_NO_RTTI #endif +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_TYPEID) +# define BOOST_NO_TYPEID +#endif If Boost would like to enhance the support of -fno-rtti on clang, it would be good to merge the fix into the release branch. I ran the test runner (clang trunk with -fno-rtti) for unpatched release branch and patched release branch. There was no regression and more than 1000 test results got improved. Regards, Michel

2 2

[pimpl] links
by Vicente J. Botet Escriba 26 May '12

26 May '12

Hi, where can I get the source and documentation for the proposed Boost.PImpl? The doc link points to a paper and the source link points to github. Best, Vicente

2 1

Schedule link broken for multiprecision doc
by Vicente J. Botet Escriba 26 May '12

26 May '12

Hi, the link http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h…. is broken. Best, Vicente

4 3

committing patches to other libraries (was [1.50.0] Beta schedule)
by Jeffrey Lee Hellrung, Jr. 26 May '12

26 May '12

:: bump :: On Tue, May 22, 2012 at 11:13 AM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung(a)gmail.com> wrote: > On Tue, May 22, 2012 at 5:46 AM, Beman Dawes <bdawes(a)acm.org> wrote: > >> C++Now! is history, so it is high time to get the 1.50.0 beta out the >> door. >> >> Branches/release is now closed for all changes except by permission >> from a release manager. >> > > Request to merge > > https://svn.boost.org/trac/boost/changeset/78501 > > which just takes care of a shadowing warning on gcc. > > Couple things: > (a) I just went ahead and made this change on trunk a few days ago because > I stumbled into this warning myself, searched track, and saw that it was > already reported and had a patch (indirectly) attached; in retrospect, I > apologize if I stepped on anyone's (Jeremy's?) toes, and so I ask: Is there > a formal or informal protocol for applying relatively simple patches like > this one? > (b) Along the same lines, assuming permission is granted and given (a), > should I be merging this to release, or should that fall to the library > maintainer? > > Thanks, > > - Jeff > I was hoping to get some direction regarding the above before continuing to; specifically, what should be done about this particular changeset, and some guidelines for similar situations in the future. (I am aware of the recently revised release schedule, so disregard the "request to merge" in that context.) Thanks, - Jeff

1 0