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

[Proposal] A little reasonable modification of boost::bind_t
by Arthur Athrun 16 May '13

16 May '13

Hi, everyone, I'd like to propose a little modification of boost:: bind to expose more information in boost:: _bi:: bind_t. Here is my motivation problem. Suppose this is a function which takes boost: :_bi::bind_t as a parameter. But at the same time, I'd like to enumerate all binded parameters and do something for specific types, like the following pseudo code shows. template< class F> void foo(F & f) { foreach(T& arg, f.arguments()) { if(boost::is_same<T, ID_t>::value) //here ID_t is a user specific type //do something for arg. } } I found that all binded arguments are stored in a listN object. But unfortunately, the list object (L _l in boost::_bi::bind_t) is set to private access and there is no method to boost::_bi::bind_t to access the listN object and the type of listN. I don't know why you developers didn't provide a method to access the listN object. But it seems reasonable to provide a public method in <boost\bind\bind_template.hpp>, like this typedef L argu_type; const L & arguments() const {return l_;} Also, the class "template<class T> class value" in <boost\bind.hpp> doesn't provide any access to T. It will be reasonable to add access of type T, like this public: typedef T val_type; With such modifications, we can access all binded arguments in the boost::_bi::bind_t. Here is a showcase. template<class T, class VT>void Test(VT t, T * p = 0) { //This parameter is not binded, so ignore it! }template<class T, class VT>void Test(VT t, typename T::val_type * p = 0) { //T::val_type is the parameter's type， //and can use boost::is_same<T::val_type, ID_t>::value to check it! std::cout<<"great! we get a value here!"<<t.get()<<std::endl; } template <class R, class F, class A1, class A2>void retrive_args(boost::_bi::bind_t<R, F, boost::_bi::list2<A1, A2> > & f) { Test<A1>(f.arguments()[_1]); Test<A2>(f.arguments()[_2]); } int f(int a, double b) { std::cout<<a<<std::endl; return a; } int main(int argc, char * argv[]) { double t = 1.0; retrive_args(boost::bind(f, _1, 0.2)); //Here will retrive the second parameters only. return 0; } I don't know if I get the right way to implement it. Please let me know if you have another implementation. Any comments or ideas will be appreciated. Thanks. -- Athrun Arthur Cluster and Grid Computing Lab (CGCL) Services Computing Technology and System Lab (SCTS) School of Computer Science and Technology (CS) Huazhong University of Science and Technology (HUST) Wuhan, 430074, China EMail:athrunarthur@gmail.com

4 3

[spirit][lex] remove_referece necessary for lex::less
by Andreas Pokorny 14 May '13

14 May '13

Hi, Can I apply that patch? Index: boost/spirit/home/lex/lexer/support_functions.hpp =================================================================== --- boost/spirit/home/lex/lexer/support_functions.hpp (revision 84231) +++ boost/spirit/home/lex/lexer/support_functions.hpp (working copy) @@ -47,11 +47,13 @@ template <typename Env> struct result { - typedef typename - remove_const< - typename mpl::at_c<typename Env::args_type, 4>::type - >::type - context_type; + typedef + typename remove_reference< + typename remove_const< + typename mpl::at_c<typename Env::args_type, 4>::type + >::type + >::type + context_type; typedef typename context_type::base_iterator_type type; };

2 3

Re: [boost] Embedding manifest into the regression tests (was: [testers] [log] Problems with tests)
by Holger Grund 14 May '13

14 May '13

VC++ 10 and 11 dont use sxs isolation for runtime libs any more. IOW, you dont need a manifest for the CRT in VS2010&2012. Regards -hg Sent from Samsung MobileAndrey Semashev <andrey.semashev(a)gmail.com> wrote:On Monday 13 May 2013 20:39:21 Daniela Engert wrote: > Am 13.05.2013 19:50, schrieb Andrey Semashev: > > On Monday 13 May 2013 16:06:01 Sergey Cheban wrote: > >> [snip] > >> The bjam scripts embed the manifest into the executable if it was > >> generated by the linker. And the linker generates the manifest by > >> default if the /manifestdependency option was specified. > >> > >> May be, it is reasonable to add the "/MANIFEST" to the linker options > >> explicitly. > > > > I know little about Windows manifests, but if I'm not mistaken, > > /manifestdependency describes the dependency to be put in the manifest and > > /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 > > and 11 removed their /manifestdependency then what should be put into the > > manifest? > > Is this really about dependency? In Visual Studio, MSBuild is configured > to insert this into .exe link options by default: > > /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed From MSDN ([1], [2]) this seems to be the default, if manifest is generated. I'm not sure what is the problem with manifests as it seems it should be generated by default. So either it is not generated when there are no /manifestdependency entries or I'm missing something. I hope someone with more experience can comment on this. [1] http://msdn.microsoft.com/en-us/library/f2c0w594.aspx [2] http://msdn.microsoft.com/en-us/library/bb384691.aspx _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 3

[smart_ptr] lost doc link to enable_shared_from_this
by Kim Barrett 14 May '13

14 May '13

In boost 1.53 I can't find any reference to the documentation forenable_shared_from_this. The documentation page exists: http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/enable_shared_from_this… but I can't find any reference to it from anywhere in the smart_ptr / shared_ptr documentation. As late as boost 1.52 there was a reference to it in a note for the template<class Y> explicit shared_ptr(Y * p); constructor, but that note was removed in boost 1.53, and there doesn't seem to be any other reference to enable_shared_from_this. One of the places I expected to find a reference to enable_shared_from_this was the "Programming Techniques" page's entry "Obtaining a shared_ptr from a raw pointer", but I found no mention of it there through boost 1.53.

1 1

[endian] Boost licensed detail/endian.hpp [was: [1.54.0][release] Provisional schedule]
by Beman Dawes 14 May '13

14 May '13

>On Mon, May 6, 2013 at 9:06 AM, Daniel James <daniel(a)calamity.org.uk> wrote: > >> On 6 May 2013 14:15, Philip Bennefall <philip(a)blastbay.com> wrote: >> > I was just wondering if it is possible to get a modified, Boost licensed >> > version of detail/endian.hpp into this next release? It'd be great to get >> > this licensing issue resolved in this next Boost version, if at all >> > possible. >> >> I don't know. I haven't been following that. Did anyone take >> responsibility for it? >> > >It's highly unlikely. There is al alternative implementation in Boost >Predef. But that isn't even fully accepted as a library. I could attempt to >do a standalone port from Predef into detail/endian.hpp but I doubt I could >both get it done and tested to a point that it would be safe to merge into >release. I'm restarting work on the boost endian library, so I'd be willing to take this on. If you send me your Predef port of detail/endian.hpp, I'll see if I can move it along. No promises until I see what you have, however. Thanks, --Beman

3 4

Can anyone take a quick read of an array type?
by Daryle Walker 14 May '13

14 May '13

I banged out a little something at <https://github.com/CTMacUser/ArrayMD>. The "boost::container::array_md<T, N>" class template can be used like the (C++11) std::array. It has the same members (value_type, size_type, difference_type, reference, const_reference, pointer, const_pointer, iterator, const_iterator, reverse_iterator, const_reverse_iterator, at, front, back, operator[], data, begin, cbegin, end, cend, rbegin, crbegin, rend, crend, empty, size, max_size, fill, and swap). It has external functions operator==, operator!=, and swap. It fulfills the Container and Reversible-Container archetypes, with random-access iterators. It lacks: * support for 0 as the length. It combines the type and extent directly as the internal array's type expression, so the compiler will complain if zero-length arrays are used. (You also can't use a function type, reference, or class-type that's marked abstract as element types.) But front, back, and data will always be valid. * The ordered-comparison operators (<, >, <=, and >=). * The get access function, plus helper specializations for std::tuple_size and std::tuple_element. It adds: * 3 class-static constants: dimensionality (= 1), static_size (= N), and static_sizes (a one-element array with value N). * 2 type aliases: direct_element_type (= value_type) and data_type (= direct_element_type[N]). * If value_type is an array type, fill still works, by doing assignments at the inner non-array level. * The apply member functions, that call a function over each element, including the element and its index coordinate with each call. * operator(), which works just like operator[]. * As many member functions work with constexpr and/or noexcept as possible. Array_md is an aggregate type. It is trivially-copyable, trivial, standard-layout, and/or POD if the element type is. It has default-, copy-, move-construction, destruction, copy-, and/or move-assignment if the element type does. (Default-initialization follows the element type's lead if its code-ful or random garbage bits.) Initialize it like a structure with a single member object of type data_type. Indicated by the "md" suffix, the array modeled by this class template can be multi-dimensional. Unlike C-level arrays, which are all nested one-level arrays, this class template lets you express multi-dimensionality flatly. And the arguments are compatible with the comma-separated lists used in variadic stuff. When you add another extent M (BEFORE the others): * ++dimensionality * static_size *= M * static_sizes -> { old static_sizes, M } * direct_element_type = old data_type * data_type = direct_element_type[ M ] * The apply method sends the remote function each element along with all of its index coordinates (dimensionality + 1 arguments total). * operator[] still takes one argument, and returns a direct_element_type&. You can continue to chain-index to the element type just like nested built-in arrays. * operator() and at can take as many arguments as dimensionality. Using that many indices gives an element, using less gives a reference to an intermediate array (which you can use the built-in operator[] on). If you use no indices, then you get a reference to the entire implementation C-level array returned. (I originally had operator() put in since operator[] can't handle multiple direct arguments.) You can crank the recursion backwards, and have an array with no extents. Such a type supports one element (NOT zero, since one is the multiplicative identity). That's another reason not to special-case zero-value extents in, to keep the size non-decreasing with new extents. This degenerate case doesn't support static_sizes (since it would be an illegal zero-length array) or operator[] (since there's no array member object). Added late to the cycle: When perusing the C++11 standard, I noticed that operator[] can take a std::initializer_list argument, although the core language never uses it; it's only for UDTs. I added support for that. I added support for it in the operator() and at methods, for symmetry. The length of the list must equal dimensionality. To-do: Should I implement get, tuple_size, tuple_element, and the ordered-comparison operators? They're very linear-oriented. I'm not sure they're used that much. And I'm not sure what they would even mean for a non-linear container; I may have to apply some sloppy linearity for them to be defined. (I don't think I could make them (get, tuple_size, and tuple_element) multi-coordinate; then they couldn't work with generic code.) I was trying to avoid any linearity, and depend on apply for iteration-related tasks. Then I decided to support the range-for statement. Then it looked weird to have a sloppy & minimal begin/end tacked on, so I put in a full iteration set. Then at that point, I put in so many things like std::array that I put everything else in so they could have source compatibility. (BTW, there are several utility/helper classes and functions. Some are in separate headers, the others near the start of "array_md.hpp".) Versus Boost.MultiArray: (This is from a quick look at BMA.) BMA statically declares the element type and the number of dimensions; the actual extent values (and therefore the element count) and the elements themselves are determined/allocated at run-time. It's like std::vector vs. std::array, the former is more powerful, but may be overkill that limits compile-time opportunities, while the latter can take advantage of compile-time optimizations and can shift memory usage from the heap to the stack. Versus Brian J Smith's Array (at <https://github.com/BrianJSmith/Array>), on the review queue: * (Used to support extent values of 0, but has been removed). * Requires at least one extent, while array_md supports 0 extents. * Implements multi-dimensions as maps::array objects nesting each other, similar to how C-level arrays are made multi-dimensional. The array_md model computes the nested C-level array type and stores that directly. This has big consequences, because of padding. Class types may add padding bytes before(?), between, and after their non-static member data sub-objects. Built-in array types never have padding. So maps::array may end up with lots of padding bytes scattered through it, while array_md has one set of padding and its elements contiguous. This makes implementing the data method possible; it can't work with maps::array unless we get lucky and the compiler doesn't add any padding. (The data method isn't provided by maps::array anyway; the "data" name is used differently.) * Due to the above, maps::array matches nested C-level arrays in that range-for iterates over the immediately-lower level of elements. This is OK when dimensionality is 1, but higher dimensions can't dig into the element type through range-for. The array_md class's range-for support is at the element level, due to being able to define the data method. * There are operators * (unary) and + (binary) overloads. They seem more for iterators than containers; then I figured out that he's simulating the effects of array-to-pointer conversions, which make these operations possible. That decay action is something we shouldn't be exalting. (And there isn't a reversed version for offset + container.) * There's no option to input all the indices at once for "at," instead maps::array needs to chain them. (There's no throw-less version called operator(), needed due to operator[] being limited to one argument.) (There's no initializer-list variants either; but the maps::array code has no C++11 features besides variadic templates.) * There is stream-output code. * There is ordered-relations operator (< > <= >=) code. * Revealing the values for the dimensions outside of the template header differ. * Actually has documentation, as opposed to Doxygen comments. Daryle W.

2 6

[testers] [log] Problems with tests
by Andrey Semashev 14 May '13

14 May '13

Hi, I'm looking at the recent trunk test results (http://www.boost.org/development/tests/trunk/developer/log.html) and seeing a few failures that I cannot explain or reproduce. In particular: 1. RDC-VC10 fails with errors that were fixed quite some time ago (in revision 83986 and the test results correspond to 84238). The headers in the errors are not included in the test code and other testers do not show these errors. I suspect that the tester has some problems regarding SVN checkout or maybe cleaning the previous test results. 2. There are a few testers that fail the util_dynamic_type_dispatcher and util_static_type_dispatcher tests, namely Qt5 jc-bell.com, teeks99-01a- win7-32on64 and DrWeb_x86. The test report says this is a runtime failure but it has no output or just has an exit status. The same tests run successfully for other testers, as well as in my local runs. It may be worth noting that the same code is indirectly tested with other tests (e.g. form_attr and filt_attr) and these tests succeed. I would appreciate any help in researching the problem with these tests. Are there any errors that are not present in the report? Does it crash (what's the backtrace)? Any configuration error (missing libraries)? Thanks.

3 5

Default x86 instruction set
by Andrey Semashev 13 May '13

13 May '13

Hi, I noticed that by default x86 32 bit builds are targeted for i386 (at least gcc toolset and its derivatives explicitly specify -march=i386 in the command line). Is there a reason to target for such an ancient instruction set by default? Frankly, I'm not sure that the current Boost code would even run on a real 80386, since there are at least quite a few places with atomic operations, which I think were not present on that CPU. Also, I would like to use cpuid safely in my library, and this operation appeared only in some i486 and all Pentiums, so I would basically target my code for Pentium at the very least. But perhaps we could raise the default to Pentium Pro (i686)? Most Linux distributions already switched to this target for 32 bit builds because of availability of cmov instructions. Windows and OS X, I think, don't support older architectures either.

6 18

Embedding manifest into the regression tests (was: [testers] [log] Problems with tests)
by Sergey Cheban 13 May '13

13 May '13

On 13.05.2013 13:23, Andrey Semashev wrote:> On Mon, May 13, 2013 at 12:58 PM, Sergey Cheban <s.cheban(a)drweb.com> wrote: >> The problem is related to the fact that MS Windows (at least, Windows >> Server 2012) requires elevation for the execulables with names that >> match the *patch*.exe mask. So, util_dynamic_type_disPATCHer and >> util_static_type_disPATCHer require elevation. > lol, what a wonderful and obvious security policy on MS part, isn't > it? :) I've found that the same tests succeeded for the msvc-9.0 toolset. It is because the manifest file is generated for this toolset. I've found that the "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h" file contais the following: =============================================== #pragma comment(linker,"/manifestdependency:\"type='win32' " \ "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".DebugCRT' " \ "version='" _CRT_ASSEMBLY_VERSION "' " \ "processorArchitecture='x86' " \ "publicKeyToken='" _VC_ASSEMBLY_PUBLICKEYTOKEN "'\"") =============================================== and the "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h" and "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\crtdefs.h" contain no such code. The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified. May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly. Btw, I see the following in the msvc.jam: ================================================ if [ MATCH ^([67]) : $(version) ] { .... } else { .... # Make sure that manifest will be generated even if there is no # dependencies to put there. toolset.flags $(toolset).link LINKFLAGS $(conditions)/<embed-manifest>off : /MANIFEST ; } ================================================ -- Sergey Cheban

3 6

Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
by Niall Douglas 13 May '13

13 May '13

> on Thu May 09 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote: > > Just to be clear and for the record, I have no compelling arguments, > > no plan for migration, and I am in no way criticizing your work, your > > leadership, nor suggesting the throwing away of any planning or > > coding. I apologise unreservedly if anything in my words appeared that > > way. I am absolutely sure that you have given this the very deepest of > > thought and I - as always actually - trust your judgment. I am simply confused. > > OK. I don't know how to un-confuse you, though, sorry. > [snip] > Unfortunately for my workload, the community begs to differ. The lightbulb has switched on: I had been confused because I had thinking the migration was based on technical arguments. I now realize the arguments are mostly non-technical, so I am now deconfused. Thanks for the illumination. > > We can talk about this at C++ Now next week, but if we were to > > coordinate our efforts and I have definite approval and support from > > Boost SC, I have no objection to volunteering for this. > > I don't see what difference approval from the steering committee makes. > If you think it would be helpful, you can go ahead. A two way mirror would need changes to the main Boost SVN installation. Changes which could lose data and cause outages. It's not something I'd proceed with without unanimous support, especially for moral support if data loss did occur. > > That probably is unacceptable to you given your apparent plans. > > Yeah, we want to get this thing over with. Thanks for the suggestions, though. I understand entirely now. Sorry it took a while. Do get in touch if you need it. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0