- Boost - lists.preview.boost.org

[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

Re: [boost] Git Modularization Ready for Review
by Niall Douglas 13 May '13

13 May '13

> It's a question of degree. Daniel et. al.'s recent work shows that you > can keep that loss pretty low. "Where there's a will there's a way?" Agreed. With enough effort anything is possible. But tough on those tasked with the grunt work. > >> What happens in a few years time when Git is replaced with the next big > > thing? > >> Do we lose the history again? And then again when that gets replaced too? > > > > That's exactly what happens. Bitrot is always inevitable in the long run. > > Here call it "non-fatal bitrot" :) > > > > My only red line is corruption of past and present source code releases. It > > must *always* be possible to check out tag X and build release X. > > So why have a VCS at all? Named tarballs meet your red line. VCS is for workflow and collaboration. Optionally for blaming bugs through automated regression analysis. They can be useful for generating some interesting stats. And yes, I do use named tarballs (or ZFS snapshots more recently) of the VCS store exactly for history preservation. VCSs aren't for history preservation, especially as they're usually not bitrot tolerant. > > Well, the Git way of helping stuff get out of step is that everyone gets > > their own full copy of the whole repo, and their copy is just as important > > as anyone else's copy. You clone, you develop and test, and optionally push > > changes elsewhere which could be your friend, your team, your employer, or > > of course some central authoritative copy. > > That works for a monolithic project. Boost is not monolithic but it's > single repo model was forcing it to act like one. As well as making > life a little easier for library developers, the modularisation effort > should help end users too. For a while now people have been wanting to > take only what they need from Boost and ignore the rest. It's > especially important in commercial environments where manager (rightly > or wrongly) are reluctant to depend on huge quantities of unreviewable > code with unknown interactions. Modularisation won't solve the problem > overnight but it helps. I disagree with pretty much all of this. And I think modularization, as currently proposed if I understand it correctly, actually makes those feared interactions much worse and/or much more work to avoid. > > So I'm afraid I just don't get the present design for a library as > > small and as tightly integrated as Boost. > > You must be talking about some other Boost. It's all subjective. I agree there are a chunk of Boost libraries which are fairly standalone and I have no problem with those being turned into git submodules. > > I'm a great believer in refusing to let programmers commit code which breaks > > other code rather than nagging them later to fix an earlier commit. The > > point of failure notification ought to be as close to cause as > > possible. > > Surely the developer sees the breakage the moment they update the > versions of the other libraries they are working against. And then they > can fix it at their leisure while early adopters get to use their code > with the previous version of the conflicting library. My point is this isn't automatic. It requires programmers not to be lazy. That hasn't been hugely successful in the past. > When you are talking about breakages are you talking about merge > conflicts or compile/test-failures? Up till now I've assumed you mean > the latter. But now I'm thinking you might be asking what happens if > the developer of library X makes a change to header H and developer Y > also makes a change to _the same header_? No that's easily detectable. My concern is when modifications to submodule A and submodule B cause arbitrary C in some submodule D to suddenly fail. > The way the modularisation works, I'm not even sure this is possible. > The libraries are meant to be self-contained so you only ever change > your own headers. It's a good question and one I hand't thought about. > Perhaps the people working on this can weigh in here. Git submodules are too loosely coupled for anything but loosely coupled, fairly standalone libraries. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[chrono/date] name of getters - error: changes meaning of
by Vicente J. Botet Escriba 13 May '13

13 May '13

Hi, Naming the getters with the same name as the type chrono::year year() const; results in a lot of error with gcc <= 4.8.0 ../../../boost/chrono/date/ymd_date.hpp:267:7: erreur: declaration of ‘boost::chrono::year boost::chrono::ymd_date::year() const’ [-fpermissive] ../../../boost/chrono/date/year.hpp:36:11: error: changes meaning of ‘year’ from ‘class boost::chrono::year’ [-fpermissive] When I add -fpermissive I get yet the warning ../../../boost/chrono/date/year.hpp:36:11: attention : changes meaning of ‘year’ from ‘class boost::chrono::year’ [-fpermissive] Do someone how to get ride of this warning/spam? In addition, no way to make it working with gcc-4.2.1. No issue with clang-3.1, 3.2. Not checked with msvc. Is this a bug on gcc? Best, Vicente

2 1

[chrono/date] class names
by Vicente J. Botet Escriba 13 May '13

13 May '13

Hi, I would like to fix the names of date classes for the different representations. I'm not saying that all the representations need to be provided for a first release. Here it is my proposal. The following are unchecked and non contextual dates classes * calendar_date: field based representation of year + month + day. * serial_date: days based representation * ordinal_date: field based representation of year + day_of_year * week_date: field based representation of year + week + weekday Checked dates classes names just add a checked_ prefix to the corresponding unchecked date classes. * checked_calendar_date: field based representation of year + month + day. * checked_serial_date: days based representation * checked_ordinal_date: field based representation of year + day_of_year * checked_week_date: field based representation of year + week + weekday We can also have an alias date template <typename Tag = serial, validity=validity::unchecked> class date; so that date<calendar> ~ calendar_date date<serial> ~ serial_date date<> ~ serial_date ... I'm, open of course, to other defaults for these parameters, if the idea of an alias is accepted. For the time been a single contextual date class should be enough, as all the contextual information is relative to the year/month/day representation. * contextual_date: field based representation of year + month + day + context-meta-data Comments, critics and suggestions are welcome. Best, Vicente

3 9