- Boost - lists.preview.boost.org

Boost Hana comments
by Jeremy Maitin-Shepard 21 Aug '14

21 Aug '14

First off, while I haven't thoroughly reviewed the library, I am certainly impressed by a lot of what I see. It is obvious that this library represents a lot of excellent work. Here are my miscellaneous comments: Constant type class: -------------------- Why isn't std::integral_constant an instance? There is no documentation of what the value method actually returns, just that it returns something that is a constexpr. Does value(integral<int,3>)) return int, or does it return integral<int,3> ? Perhaps the Constant type class should be "parameterized" by a type specifying the return type of value. Integral data type: ------------------- It would be better not to duplicate std::integral_constant. However, I recognize that the overloaded operators are useful and you wouldn't be able to do this with std::integral_constant (well, I suppose you still could, but as they wouldn't be found by ADL, they wouldn't be terribly useful). This rationale (assuming it is correct) should be documented though. Logical type class: ------------------- What is really gained by making this a type class at all? It seems that and_ and or_ require that all arguments be of the same "hana datatype", though actually this isn't documented anywhere and this might not even be the precise requirement (but obviously it needs to be documented very explicitly, and this probably applies to almost every method in Hana). Really we really should be able to mix multiple data types in a call to or_ or and_, though. Otherwise the usability is unreasonably limited. Of course there is then the question of return type. However, I would assume most users would be happy getting back either a Hana Integral or a bool, depending on whether it is a compile-time or runtime condition. Certainly this would be better than getting back a compiler error. Another question: how does the performance of and_ and or_ compare to the optimized verions you showed in your MPL11 talk? Pair datatype: -------------- Why duplicate std::pair? Alternatively, why duplicate list? Perhaps list should just define first and second as well? Product type class: ---------------- Why isn't a 2-element List, a 2-element std::tuple, etc. an instance? List type class: ---------------- Just as for Logical, it would be useful to be able to mix datatypes in calls to concat, zip, zip_with. The list function itself shouldn't be documented as part of the type class, since it isn't logically part of it. What about get<N>, get<N,M> accessors? I understand these can be defined in terms of the other methods, but clearly they are useful on their own.

3 4

[Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Mostafa 21 Aug '14

21 Aug '14

On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey(a)rrsd.com> wrote: > Eric Niebler-4 wrote >> On 07/29/2014 05:14 PM, Niall Douglas wrote: >>> I'm all for Concepts as in compiler enforced ones, and I'll add them >>> to AFIO when and only when C++ gets them. But for documentation they >>> don't help. >> >> Wow, I couldn't disagree more. I can't imagine how the standard >> algorithms would be specified without the use of concepts like >> "RandomAccessIterator", for instance. Clustering requirements into >> meaningful abstractions and assigning them names makes it possible to >> document library interfaces without an explosion of verbosity and >> repetition. > > +10 > > Usage of concepts is greatly: > > a) misunderstood > b) misunderestimated as to their value in design AND documentation > d) The word "concepts" is a big contributor to the problem - substitute > "type requirements" or "type constraints" for concepts. -1 to the above term substitutions for concepts. Type requirements/type constrains are not concepts. The reason concepts are misunderstood is because they have not been well defined. FWIW, here's my take on how they should be defined: Concepts are sets of types whose membership are compile-time determinable. Precisely, a concept is any set expressible in the following form: { T | T is a type and p(T ...) } where p is a (n+1)-ary compile time computable boolean function (a function in the mathematical sense, not an actual C++ function). p is said to be (or to express) the type requirements or type constrains for its associated concept. (Note: just as a set membership predicate is not its set, a type requirement is not its concept. For example, the predicate "there exists a,b and a,b are integers and b != 0 and c = a/b" does not denote the set of rational numbers, the symbol Q does.) A type T is said to model a concept C if T is a member of C. In such a case we also say that "T is a C". A concept B is said to be a refinement of a concept A if B is a subset of A. Why use concepts? Because they are helpful in documenting generic code, especially template type parameter requirements. Examples: 1) DefaultConstructible := { T | T has the method "T()" defined and accessible. } // Requirements: // T is DefaultConstructible. template <typename T> struct FooBar { ... }; std::tuple<int> is DefaultConstructible, therefore FooBar< std::tuple<int> > is well formed. Mostafa

14 57

[Container] Provide more guarantees for flat_multimap
by Vinícius dos Santos Oliveira 21 Aug '14

21 Aug '14

Currently, flat_multimap mirrors C++98's multimap concept. I'd like to propose an update to flat_multimap fulfil the C++11's multimap concept. The part I'm particularly interested are guarantees about preserving the insertion ordering for elements with equivalent keys. On ISO/IEC 14882-2011, 23.2.4 - associative container requirements, pages 741 and 742, you can see the effects for a_eq.emplace and a_eq.insert ends with "If a range containing elements equivalent to t exists in a_eq, t is inserted at the end of that range". I see no similar guarantees on the Boost's flat_multimap documentation[1]. This feature is useful, for instance, in HTTP messages, where field reordering is illegal[2] if the keys are equivalent. I did a few tests and it looks to me that flat_multimap already provides these guarantees, but before I go check the source and possibly provide patches, I need to know if there is interest in turning this accidental behaviour into intentional behaviour through documented guarantees. [1] http://www.boost.org/doc/libs/1_56_0/doc/html/boost/container/flat_multimap… [2] http://tools.ietf.org/html/rfc7230#section-3.2.2 -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

7 17

Metadata pull requests
by Daniel James 21 Aug '14

21 Aug '14

Hi, I just created about 100 pull requests to add library metadata to modules that don't already have it. Apart from them all containing the same typo, I think it went okay. I forgot to mention that the file format is documented at: http://www.boost.org/development/library_metadata.html I'll spend a bit of time improving that soon, so let me know if there's anything missing. Also, if it wasn't clear, the idea is that you can update this file if you need to change the library details. It might take a little while for the website to update, as it only happens when I run the appropriate script. thanks, Daniel

5 11

[units] Pull request and RFC: information unit definitions for Boost.Units
by Erik Erlandson 20 Aug '14

20 Aug '14

Link to PR: https://github.com/boostorg/units/pull/3 Description: Adds unit definitions for standard units of information: bit, byte, nat, hartley, shannon. Defines a new unit system boost::units::information for convenient manipulation. Also includes IEC binary prefixes: kibi, mebi, gibi, tebi, pebi, exbi Example code: https://github.com/erikerlandson/units/blob/info_units/example/information.… Unit testing code: https://github.com/erikerlandson/units/blob/info_units/test/test_informatio…

7 14

[type_traits] Interest in is_iterator type trait?
by Beman Dawes 20 Aug '14

20 Aug '14

Back in 2011, Howard Hinnant and I put together an is_iterator type trait based on code Howard had developed and used over a period of time. See http://beman.github.io/is_iterator/is_iterator.hpp for the actual code See http://beman.github.io/is_iterator/is_iterator_test.cpp for a test program. The intent was always to submit is_iterator to Boost, but we never got around to it. Now I need it in Boost.Filesystem, so I'd rather see it go in type traits than just sticking it into boost/filesystem/detail. If there is interest, and John Maddock gives the OK, I'll write docs and integrate into type_traits, then submit a pull request. --Beman

6 20

Ticket system getting spamed
by Mateusz cerkiewny 20 Aug '14

20 Aug '14

#10352 <https://svn.boost.org/trac/boost/ticket/10352> #10351 <https://svn.boost.org/trac/boost/ticket/10351> #10342 <https://svn.boost.org/trac/boost/ticket/10342> #10339 <https://svn.boost.org/trac/boost/ticket/10339> #10335 <https://svn.boost.org/trac/boost/ticket/10335> #10331 <https://svn.boost.org/trac/boost/ticket/10331> #10334 <https://svn.boost.org/trac/boost/ticket/10335> Are spamms

2 1

[log] Problem Building Boost 1.55 With GCC Using C++11 Mode Due to AVX2 Support
by Stewart, Robert 20 Aug '14

20 Aug '14

We've run into a problem building log. It doesn't appear to be a known issue and we're not sure how to work around it. We found a hack to make our builds succeed, but there may well be a better workaround and we're not certain whether there are any issues with what we've done. We tried to build Boost 1.55 with GCC 4.8.1, 4.8.3, and 4.9.1 with the following commands: ./bootstrap.sh --prefix=<prefix> --libdir=<prefix>/lib --with-toolset=gcc ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 install The errors we get come from this command during the build: gcc.compile.c++ bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o "g++11" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fno-strict-aliasing -ftemplate-depth-1024 -m64 -O2 -g -pipe -march=core-avx2 -mavx -mavx2 -fabi-version=0 -m64 -O2 -g -pipe -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o" "libs/log/src/dump_avx2.cpp" There are many lines of output; I've elided similar messages to highlight the unique ones: {standard input}: Assembler messages: {standard input}:611: Error: operand type mismatch for `vpsrldq' ... {standard input}:819: Error: no such instruction: `vextracti128 $0x1,%ymm2,%xmm2' ... {standard input}:1087: Error: no such instruction: `vextracti128 $0x1,%ymm3,48(%r15)' ... {standard input}:1312: Error: operand type mismatch for `vpaddb' While there might be a way to actually get b2 to disable AVX2 support, we hacked libs/log/build/Jamfile.v2 with these commands: sed -i 's:dump_avx2::g' libs/log/build/Jamfile.v2 sed -i 's:<define>BOOST_LOG_USE_AVX2::g' libs/log/build/Jamfile.v2 Those remove dump_avx2 from BOOST_LOG_COMMON_AVX2_SRC and remove the definition of BOOST_LOG_USE_AVX2, which prevents compiling enable_avx2(). Is there a better way to solve or work around this problem? _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Middleware using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[git] Pushing commit(s) after pulling
by Edward Diener 20 Aug '14

20 Aug '14

I share a library with others and make some commit to a branch of that library. Then I try to 'push' the commit, only to be told that there are changes that have been made which I need to 'pull'. So I 'pull' the latest changes for that branch, and luckily there is no conflict(s) with my local commit(s). What do I do now ? I can 'push' my changes successfully but then the history of my particular changes appears to be lost. Am I supposed to revert my changes to the local repository by doing a 'reset' and then reapply those changes ? That seems onerous. What is the right way to 'push' my changes and still preserve the history of each one of them on the remote repository ?

5 9

[mpl] Proceeding with modularization
by Andrey Semashev 20 Aug '14

20 Aug '14

Hi, Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub- library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?

3 3

Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Brian Wood 19 Aug '14

19 Aug '14

Niall Douglas writes: > > Such a design would not make good use of hardware DMA such that use > of the CPU can be completely avoided for bulk data transfers. To > invoke hardware DMA, all i/o must be done from 4Kb aligned memory > buffers. Indeed AFIO can enforce that for you because it's so > important to performance. > > Generally if you're bothering to use async i/o, you have no interest > in *ever* copying memory. That rules out all serialisation usually :) How about calling it OS-level serialization? I don't think the need for message framing goes away. Somehow the length of a message has to be calculated and put in place. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

GSoC: Pipeline status
by Benedek Thaler 19 Aug '14

19 Aug '14

Hi, As GSoC is coming to its end, I'd like to present you the Pipeline library: code: https://github.com/erenon/pipeline documentation: http://erenon.hu/pipeline I'll continue to work on this project, the next big thing is to implement a coroutine based execution. I hope using cooperative scheduling will enable a much better throughput/latency combination over the nice and easy to use interface we currently have. Thanks, Benedek

1 0

[serialize] Noncopyable errors in the latest 'master'
by Edward Diener 19 Aug '14

19 Aug '14

In testing out libraries which use Boost PP, with clang as the compiler, I am seeing a great deal on 'master' of: > ..\..\..\boost/archive/detail/basic_serializer.hpp:35:7: error: 'operator=' is a private member of 'boost::noncopyable_::noncopyable' > class basic_serializer : Does anybody know what this is all about ? It is occuring in a number of libraries using serialization.

1 0

[GSoC] [Boost.Hana] Status update
by Louis Dionne 18 Aug '14

18 Aug '14

Dear Boost, Summer of code is coming to its end, and I think this is a good time to give an update about Hana and what's going to happen next. In early august, I asked for a review of Hana. As a result, I got many comments and questions which helped me improve the library and also take the pulse of the C++ community. Ever since the review, I've been working on improvements and modifications to the library and its documentation. Thanks to all of those who gave comments, and especially to those who experimented with the library and reported problems/thoughts. My initial (personal) objective was to push a new library in Boost by the end of the summer. I now realize that this is unlikely to happen given the amount of work that's left and the amount of time on my hands. That being said, I still think Hana solves the problem of C++ metaprogramming in a very elegant way, and I'm not giving up on its development because GSoC ends. Hence, I will continue working on the project as much as my studies allow it and I plan to ask for informal reviews during fall. Eventually, I still hope to fulfil my initial goal of making Hana available to a wide audience via Boost. I would also like to mention that I will be presenting Hana at CppCon 2014 in september; consider attending if you followed the project this summer. Finally, I would like to thank everyone that was involved with making my participation to GSoC possible; I worked hard, had a lot of fun and I think my work (or at least derivations of it) will be useful to Boost and the wider C++ community given enough time. Regards, Louis

1 0

Debugger Visualizers discussion
by Antony Polukhin 18 Aug '14

18 Aug '14

Hi all, There is project that contains a bunch of XML files. Those files can be used to improve debugging on MSVC: For example: * using this project debug view of `boost::variant<int, float> i(1);` will show `1` instead of raw memory and internals of boost::variant. * optional<boost::container::string> will show string content or `none` instead of ram memory and some unreadable internals Maybe we should embed those files into the Boost? It would be great to have some magic bjam command `b2 install-debug` after which VisualStudio becomes aware of Boost classes. Files for pretty debugging could be also written for GDB. Will it be useful? Link o the project: https://github.com/KindDragon/CPPDebuggerVisualizers Files are located at https://github.com/KindDragon/CPPDebuggerVisualizers/tree/master/VS2013/Vis… -- Best regards, Antony Polukhin

3 3

[git] [filesystem] [system] [timer...] Remove useless SVN branches?
by Beman Dawes 18 Aug '14

18 Aug '14

Boost library repos converted from Subversion are littered with branches created by the conversion process that seem to me to be quite useless. For example, Boost filesystem has 65 branches, yet only 10 or so have any usefulness I'm aware of. A lot of the useless branches have names that begin "sandbox" or "svn-". I go back to the subversion repo when I want to look at pre-git-conversion history. Is there any point in retaining these branches? Does anyone object if I remove these branches from the libraries where I am the maintainer? What are other maintainers doing about stale branches? --Beman

3 2

clang and variadic macro warnings revisited
by Edward Diener 18 Aug '14

18 Aug '14

After making pull requests for a number of Boost libraries in order to reduce the warnings from compilation from clang using the Boost PP library, John Maddock suggested a specific solution, as Niall Douglas had suggested a general one before, that changes in the Boost PP library could get rid of these extraneous warnings. Originally I thought this would be too difficult and intrusive in Boost PP but after reading John's specific suggestion I decided to try to implement it. The suggestion John made was to surround code in Boost PP which uses variadic macros with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wvariadic-macros" # endif // variadic macros # ifdef __clang__ # pragma clang diagnostic pop # endif This was actually easier than expected since all code in Boost PP which uses variadic macros is surrounded by: # if BOOST_PP_VARIADICS #endif // eventually Of course there are many files changed by this but overall it is very straightforward. This technique does work for the diagnostic "-Wvariadic-macros". Hooray ! Unfortunately the second situation involving warnings, where clang warns about: warning: empty macro arguments are a C99 feature [-Wc99-extensions] coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif #define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) # ifdef __clang__ # pragma clang diagnostic pop # endif does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang. The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported. In retrospect, when I changed Boost PP from never supporting variadic macros for clang ( Paul's original conservative choice ) to always supporting variadic macros for clang, I gave in to an outcry that clang users should have variadic macro support in Boost PP. It would have been wiser to follow the gcc method in Boost PP. But that is past and we need a good solution now. Thoughts ? Solutions ? Brickbats <g> ?

3 3

[endian] Was: [Boost-testing] All runners on develop are failing.
by Rene Rivera 18 Aug '14

18 Aug '14

---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Fri, Aug 15, 2014 at 8:13 PM Subject: [Boost-testing] All runners on develop are failing. To: Running Boost regression tests <boost-testing(a)lists.boost.org> It is looking for the endian library...which I have, but is still failing. error: Unable to find file or target named error: '../libs/endian/' error: referred to from project at error: '.' I did a: git checkout develop git pull git submodule update --init on my repository, which caused the previously empty endian directory to be populated, but still getting the error. Thoughts? Tom _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[algorithm] Interface for longest_increasing_subsequence (proposal)
by Curdeius Curdeius 17 Aug '14

17 Aug '14

Hi all, I want to propose a new algorithm to Boost.Algorithm: a well-known longest increasing subsequence <https://en.wikipedia.org/wiki/Longest_increasing_subsequence> (LIS for short). Just for a short info: given a sequence like ( 7 )( 2 )( 8 )( 1 )( 3 )( 4 )( 10 )( 6 )( 9 )( 5 ), the result will be a subsequence ( 1 )( 3 )( 4 )( 6 )( 9 ). The proposed algorithm has O(n log n) time and O(n) complexity, where n - sequence length. I have created a pull request https://github.com/boostorg/algorithm/pull/7. I have however some questions. I am not sure what should be the exposed interface. For the moment, I propose (I base it on the existing interface from algorithm/searching functions): - class longest_increasing_subsequence with methods - operator() - *compute_length* (a better name may be needed) - free function longest_increasing_subsequence_length returning the length of the LIS and taking as arguments: - a pair of iterators (first, last) - or a range - and (optionally) a comparison predicate - *free function longest_increasing_subsequence_search taking the same arguments as _length function and an Output Iterator or a tag.* - free function make_longest_increasing_subsequence taking a range and optionally a comparison predicate and returning corresponding longest_increasing_subsequence object The problematic part is the underlined longest_increasing_subsequence_search function and the way in which I should return the resulting LIS. I see possibilities like the following: 1. taking an OutputIterator argument: the best for me, generic and the most flexible solution, but there is a performance hit as we cannot reserve the memory for the output LIS. 2. returning a container with the subsequence, e.g. std::vector<value_type>: no performance hit with small objects or if the user needs a vector of values. However, not really generic as the user would be obliged to use a vector (in the aforementioned example). 3. returning a container with iterators, e.g. std::vector<InputIter>: good if a container of iterators is acceptable, it has a benefit of avoiding possibly expensive copies of sequence elements. As 2., not really generic. 4. -taking a container as an argument: the worst solution in my eyes, there is no way nice way to write generic code that handles all containers. I have coded possibilities 1-3. Thank you in advance for all the comments, corrections etc. Regards, Marek Kurdej

1 0

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 16 Aug '14

16 Aug '14

Hi all, I considered proposing myself as a maintainer of Boost.Units for some time, but considered too inexperienced to do it on my own. Therefore I am happy that Jürgen proposed himself and I would like to help him by being a co-maintainer if it is possible and needed. As for me, I have been using the library for at least 3 years now and would like to contribute to it. For the moment, I mainly proposed small bug fixes to Boost libraries. Regards, Marek Kurdej -- Ph.D. candidate Hi Matthias, > Am Donnerstag, 31. Juli 2014, 11:25:35 schrieb Matthias Schabel: > > I would love to pass the responsibility for ongoing maintenance of > > Boost.Units on to a new torchbearer. > First a "Thank you very much" for the great library. > > My time to dedicate to this project > > has dwindled to essentially zero, and I believe it would be best for all > > involved to enlist some fresh blood, ideally someone who is using the > > library on a regular basis... Any volunteers? > As no one else has stepped up, I'd like to volunteer. I've been using > Boost.Units with great success for the last five years. For my recent Boost > contributions see https://github.com/jhunold. Mostly small bugfixes, > Boost.Build support over the last decade. > Boost.Units is getting more attentions now as c++11 is getting momentum. > Personally, I'd like to get > https://github.com/boostorg/units/pull/5 > into 1.57. > > As far as Erik's request, I don't have any objections to adding these to > the > > library, though I have not had time myself to verify that they are > correct. > It would be nice if one of the current maintainer could comment on this. > > >> Link to PR: https://github.com/boostorg/units/pull/3 > Seems obsolete, > https://github.com/boostorg/units/pull/6 > it the improved commit. > Feel free to ask questions. > Yours, > Jürgen > -- > * Dipl.-Math. Jürgen Hunold ! > * voice: ++49 4257 300 ! Fährstraße 1 > * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen > * jhunold(a)gmx.eu ! Germany

1 0

[config][type_traits] Support for final keyword in Boost?
by John Maddock 16 Aug '14

16 Aug '14

I have a couple of pull requests to add support for the final keyword in Boost.Config and an is_final trait to type traits, so my questions are: 1) Are these generally useful? 2) Do we need BOOST_NO_CXX11_FINAL_CLASS and BOOST_NO_CXX11_FINAL_OVERRIDE or will a single BOOST_NO_CXX11_FINAL do? 3) The trait appears to be unimplementable via SFINAE (anyone care to prove me wrong?) which means it's only usable on GCC and lookalikes which have an __is_final intrinsic. Should we still add this to Boost or is the answer "use GCC's native features" given that a Boost version effectively adds nothing? Thanks! John.

4 3

[docbook] Add detail namespace to Reference section
by Benedek Thaler 16 Aug '14

16 Aug '14

Hi, I have the following example code fragment: namespace boost { namespace detail { /** documentation */ class implementation {}; } // namespace detail using detail::implementation; } // namespace boost I'd like to have the class `implementation` show up in the Reference section generated by doxygen+docbook-xsl+boost build+docbook+... . Issue is, every namespace which name contains the string "detail" is excluded somehow. The direct output of doxygen has it, but not the docbook version. I couldn't find any EXCLUDE_SYMBOLS setting (it's not set in the doxyfile)or anything relevant amongst the docbook-xsl params or in the boost build scripts. Google search term "doxygen ignores detail namespace" and the like did not help. Adding documentation to the using statement and/or TYPEDEF_HIDES_STRUCT did not help. Thanks, Benedek

2 3

Should intrusive_ptr copy constructors be declared noexcept?
by James Yonan 16 Aug '14

16 Aug '14

Currently, intrusive_ptr's copy constructors are not declared noexcept. This disables the std::function small object optimization when intrusive_ptr objects are passed by value in a lambda closure. The attached patch tries to fix this by making the copy constructors conditionally noexcept, based on the noexcept status of the user-provided intrusive_ptr_add_ref function. James

1 0

[Boost][filesystem] imbue in global constructor crashes
by Peter Bindels 15 Aug '14

15 Aug '14

Hi all, When trying to use a global constructor to set the locale to utf8 for an entire project, the system failed to start due to global constructor ordering making the override happen before the std::locale object itself was initialized. Looking into the boost::filesystem code for imbue it seemed that there were a few different implementations, one of which could work. I've tried to keep the same side conditions and made this same lazy-initialization approach for all platforms, which should keep working in all the same conditions and also work for a global constructor overriding the locale. I've attached the patch. I hope that this change can be integrated into boost::filesystem or that we can have a constructive discussion on what solution we should be making. Best regards, Peter Bindels

2 1