- Boost - lists.boost.org

Revelations at C++Now!?
by Lars Viklund 29 May '12

29 May '12

Hi list. Rumor has it that C++Now! is now over, and people are slowly returning to reality. What I wonder is if anything relevant to our lives was discussed or revealed at the conference. I know how easy it is at a conference or workshop to completely forget about the people out there that are not present when things are discussed or presented. If I recall correctly, there were to be some modularisation/VCS presentation from the Steering Committee, and I'm sure that you lads all had some lovely brainstorms and fistfights over beer and pizza. Come on, spill the beans. What did you all decide that will have an influence on the lives of us mortals going forward? -- Lars Viklund | zao(a)acc.umu.se

8 10

[filesystem] Create poisoned directory?
by Beman Dawes 29 May '12

29 May '12

Ticket #6932 identifies error reporting bugs in the filesystem create_directories() function. To run test cases I'd like to create a directory is OK to delete, but is poisoned against as many other operations as possible. How can this be done via the POSIX API? How can this be done via the Win32 API? Thanks, --Beman

2 1

[Spirit] Possible regression (certainly a behavioural change) regarding sequential-or with optional rhs
by adam.butcher＠selexelsag.com 29 May '12

29 May '12

Hi Hartmut, Joel, It seems that the new optional-collapsing behaviour in Spirit 2.5.1 overly simplifies the attributes of certain productions, transforming a tristate 'optionality' (optional<optional<S>>) into a simple boolean (optional<S>). This effectively flattens the two 'omitted' states into one -- in some cases (the use case below for example) they need to be distinguished (unless there is a better way to specify the rule). Ref our previous discussion on this ( http://lists.boost.org/Archives/boost/2009/12/159680.php) (in fact it is exactly this example that is causing us the problem with the latest version). Adam Butcher wrote on 2009-12-04 at 13:19:51: > [snip] > The [array subscript] grammar spec is > > (start || (':' >> -start)) > > and not > > (start || (':' >> start)) > > I would expect optional<S> for both only in the latter case. > In the former I am deliberately allowing the specifier to the right of > the colon to be omitted -- within the already optional right-hand-side > of the sequential-or. This allows for input such as > > (1) $x // $x (assume it references a sequence) > (2) $x[7] // element 7 of $x > (3) $x[7:] // a slice of $x beginning at element 7 > (4) $x[:7] // a slice of $x up to element 7 > (5) $x[2:7] // a slice of $x beginning at 2 ending at 7 > (6) $x[:] // equivalent to $x (unspecified bounds) > > In the action function, wrt to right-hand-side of the sequential-or, I > need to determine: > a) whether a range specifier has been provided at all > (given by (bool) at_c<1>(access_spec)) > b) whether the range specifier includes an explicit bound > (given by (bool) *at_c<1>(access_spec)) > > The left-hand-side of the sequential-or is either an (optional) > 'range_begin' index if a range specifier is given or a lone 'index' > specifier if no range specifier is given. > > If the two optionals on the right-hand-side were collapsed would I not > lose the ability to distinguish between (2) and (3)? The attached program demonstrates the issue. With boost 1.47 (2.5) it works fine, with 1.48 (2.5.1) it breaks. I've attached the source file but included the comment at the top in this mail for convenience. Kind regards, Adam // Change of behaviour in Spirit 2.5.1 regarding collapsing optionals // in sequential-or productions. // // Previous discussion from 2009 related to this: // http://lists.boost.org/Archives/boost/2009/12/159680.php // // // Given the STDIN // // s[:] // // the program below is expected to produce the following output: // // Have range spec... // No begin specified, using container begin. // No end specified, using container end. // Got: 'Range[B:E)' // // However, with 2.5.1, it produces the following: // // Have range spec... // No begin specified, using container begin. // Have range end '' // Got: 'Range[B:)' // // 2.5.1 also fails with the simpler STDIN: // // s[7] // // the program is expected to output: // // Have plain index 7 // Got: 'Index[7]' // // but with 2.5.1 it outputs: // // Have range spec... // Have range begin '7' // No end specified, using container end. // Got: 'Range[7:E)' // // This can be remedied to an extent by switching the #if 1 below // to be #if 0 enabling the collapsed optional code; however this // makes the presence of range-end indistinguishable from the // presence of a range-spec. // ----------------------------------------------- This email and any attached files contains company confidential information which may be legally privileged. it is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.

1 0

[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