- Boost - lists.preview.boost.org

[lockfree] arm / iOS builds against Boost.Atomic
by Rich E 19 May '13

19 May '13

Hello, I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well. If this is correct I can file a bug report, provide a test application, or both if requested. cheers, Rich

5 11

[tti] Moving TTI to release
by Edward Diener 19 May '13

19 May '13

Do I have to do anything further to move TTI from the trunk to the release branch for Boost 1.54 ? If so, please inform me of it as I am happy that TTI can be part of the 1.54 release, and I believe that the cutoff date for new libraries is tomorrow. Edward Diener

2 4

[gil] Ok to merge new gil's extension to release branch?
by Christian Henning 19 May '13

19 May '13

Hi, is it ok? The merge would include io, toolbox, numerics and some other changes to gil's code itself. Regards, Christian

6 92

[trac] Request to add TTI library to trac system
by Edward Diener 18 May '13

18 May '13

Would the TTI library pleased be added to the Boost trac system ? I am the owner of the component and my trac ID is 'eldiener'. Edward Diener

2 2

Getting regression test command lines
by Edward Diener 18 May '13

18 May '13

It is not possible in the regression tests I see on the Boost website to get the full command lines for a regression test. The reason for this is that the regression test uses a command response file and the contents of the command response are not being shown. Atypical example might be: cl /Zm800 -nologo @"D:\BoostRT\results\boost\bin.v2\libs\tti\test\test_has_data_compile.test\msvc-9.0~w\dbg\stdlb-stlpr-5.2~9\test_has_data_compile.obj.rsp Without knowing what the command response file contains it is impossible to know what the command options are for the test. This makes it very difficult to duplicate the reason for a failure in the online regression tests.

2 2

[trac] No `tti` component
by Michel Morin 18 May '13

18 May '13

Hi, There is no `tti` component in trac yet. Thanks, Michel

4 4

[1.54.0] [log] Permission to merge to release
by Andrey Semashev 17 May '13

17 May '13

Hi, I'd like to ask for permission to merge Boost.Log to the release branch. All test issues are resolved, although some MinGW testers haven't run the tests for 2 weeks and haven't updated the report. RDC-VC10 tester also didn't clean the previous test results so the report is not showing the actual results (other MSVC testers are green). The util_dynamic_type_dispatcher and util_static_type_dispatcher rows should be ignored, these tests were renamed to util_dynamic_type_disp and util_static_type_disp, respectively.

2 3

[Interprocess] Named Pipe status
by Geoff Shannon 17 May '13

17 May '13

Hi, I'm interested in writing a named pipe implementation for Boost.Interprocess (mostly since I would like to use it myself!). I was curious if anyone knew if there has already been design work done on a desired interface, or if there is actual work underway (I wasn't able to find any evidence of either but I'm normally just a boost user). Also, any comments/suggestions on what would be desired out of such a feature are much appreciated. thanks, -- Geoff Nothing is ever easy.

2 1

[string_ref] Add an equality operator between string_ref and char*
by Nicola Bizzoca 17 May '13

17 May '13

Hi, string_ref currently lacks of a simple and efficient way to compare a string_ref data to a C style string The current way that string_ref promotes is: string_ref_data.compare("boost(a)lists.boost.org") == 0 It's error prone (always checking for 0, < 0, > 0) and involves a series of implicit casting (from char* to string, and from string to string view) The same it's valid for comparing string_ref to string, but is this case an implicit casting from string to string_ref is much less expensive

1 0

[tti] Will TTI be in 1.54?
by Jeremiah Willcock 17 May '13

17 May '13

Is TTI planned to be in the next release? I have some changes to Boost.Graph that have been in the trunk for a while but depend on TTI to enable backwards compatibility, and it would be nice to have them in a release. Will that be available in the release branch soon so I can test against it? Thank you. -- Jeremiah Willcock

3 5

[config] BOOST_FORCEINLINE for clang
by Vicente J. Botet Escriba 16 May '13

16 May '13

Hi, I would like to add the definition of BOOST_FORCEINLINE for clang when __has_attribute(always_inline) // BOOST_FORCEINLINE ---------------------------------------------// #if !defined(BOOST_FORCEINLINE) # if defined(_MSC_VER) # define BOOST_FORCEINLINE __forceinline +# elif defined(__clang__) +# if __has_attribute(always_inline) +# define BOOST_FORCEINLINE inline __attribute__((always_inline)) +# endif # elif defined(__GNUC__) && __GNUC__ > 3 # define BOOST_FORCEINLINE inline __attribute__ ((always_inline)) # else Could I commit it? Best, Vicente

7 11

determine first arg of callable
by Oliver Kowalke 16 May '13

16 May '13

I need some help to extract the type of a callable which is passed as argument to the ctor of X. struct X { template< typename Fn > X( Fn fn) { ... code which evaluates Fn and extracts the type of the first arg of Fn } }; void f( int) {...} struct A { void operator()( char) {...} void g( string) {... } }; The code should evaluate in the ctor to the arguments of the callables: A a; X x1( f); -> int X x2( a); -> char X x3( bind( & A::g, a, _1) ); -> string I could overload the ctor of X for function pointers: template< typename Arg > X( void(*fn)( Y< Arg > &) ) {...} but how to deal with the other two callable types? result_of and function_traits did not work for me. Oliver

7 25

[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

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