October 2015 - Boost - lists.preview.boost.org

[tools] updating sun.jam
by Aparna Kumta 27 Oct '15

27 Oct '15

I am not familiar with the syntax to update sun.jam file. In tools/build/src/tools/sun.jam, lines 153-156 contain 153: actions link.dll bind LIBRARIES 154: { 155: "$(CONFIG_COMMAND)" $(OPTIONS) -L"$(LINKPATH)" -R"$(RPATH)" -o "$(<)" -h$(<[1]:D=) -G "$(>)" "$(LIBRARIES)" -Bdynamic -l$(FINDLIBS-SA) -Bstatic -l$(FINDLIBS-ST) -B$(LINK-RUNTIME) 156: } Only if compiling with -std=c+11 or -std=c++14, I need to replace '-G' above with '-G -library=stdcpp,CrunG3' Any help on modifying this is appreciated. Thanks, Aparna

1 0

1.60 closes for major changes next Wednesday
by Vladimir Prus 27 Oct '15

27 Oct '15

1.60 is now closed for new libraries and breaking changes - please don't merge such changes for master. We'll be closed for major changes next Wednesday, Oct 28, at the end of the day. Thanks, -- Vladimir Prus http://vladimirprus.com

3 3

[vmd] Added to new release
by Edward Diener 26 Oct '15

26 Oct '15

I would like to make sure the VMD library is added to the upcoming Boost 1.60 release. Is there anything further I have to do to affect that ?

1 0

[Hana] Postponing release to 1.61.0
by Louis Dionne 24 Oct '15

24 Oct '15

Hi, Some of you might know that I have been pushing hard to deliver Hana with the next Boost release. I have even taken the (soft) engagement to do so at CppCon in last September. However, due to some time constraints, it is now clear that Hana will not be included in Boost 1.60.0, the limit for new libraries being yesterday. I hoped really hard to make it in time for Boost 1.60.0, but the closing of the release branch ~1 month before the release date got me by surprise. All in all, this is not too bad since there are still a couple issues that must be addressed, and I believe that taking more time to address them properly will be beneficial to the community in the long term. Also, while I really wanted to make Hana available to the wider community ASAP, I do not think waiting 3 more months will be very harmful. Given the current level of C++14 support in compilers, only people on Clang >= 3.5 would have been able to use Hana, and I do not think this represents such a huge amount of potential users. As a side note, given my previous announcements, some users might find it strange not to see Hana as part of 1.60.0. Hence, I wonder whether it would be possible to include a short note with a link to this message somewhere in the release notes for 1.60.0? Regards, Louis

3 4

[detail] Compilation broken in develop and some questionable ideas
by Antony Polukhin 24 Oct '15

24 Oct '15

Hi, The commit https://github.com/boostorg/detail/commit/9fcf2ae390c7c21a9b42fd40dd5c0eec1… breaks the compilation of Boost.Filesystem: D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(126): error C2487: 'do_in': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(136): error C2487: 'do_out': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(152): error C2487: 'get_octet_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(156): error C2487: 'get_cont_octet_out_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(189): error C2487: 'do_length': member of dll interface class may not be declared with dll interface According to MSDN only the whole class or class separate members could be decorated with BOOST_UTF8_DECL, not both ( https://msdn.microsoft.com/en-us/library/t72ahzw1.aspx) Now the questionable part... We could theoreticaly avoid duplication of `utf8_codecvt_facet` code in libraries and even avoid code breakage if we: * move `struct utf8_codecvt_facet` to namespace `boost::detail::utf8_codecvt_facet_namespace` * mark all it's functions as inline, even the virtual ones => `inline` will implicitly mark the stuff in `struct utf8_codecvt_facet` as weak symbols, so that multiple occurences of it will be reduced to one by linker * add the using declaration `BOOST_UTF8_BEGIN_NAMESPACE using boost::detail::utf8_codecvt_facet_namespace::utf8_codecvt_facet; BOOST_UTF8_END_NAMESPACE` => using declaration will help the existing code to find class in `BOOST_UTF8_BEGIN_NAMESPACE` defined namespaces. Questionable part number two... Is it time to move Boost.Detail module into Boost.Core/Boost.Algorithm/Boost.MPL? Main points are: * Boost.Detail is really old and many people who maintained it are inactive. Moving it into rapidly developing modules will improve it's support (maybe even docs will appear! or tests!) * Nobody knows what does `Deatil` mean in that particular case. `detail::` namespace is a namespace that user must not use. However there's some cool stuff in Detail module that must be available to users, so the name Detail is obfuscating here. -- Best regards, Antony Polukhin

5 4

Painting a bikeshed ...
by Marshall Clow 21 Oct '15

21 Oct '15

In Sean Parent's CppCon keynote last week, he went through the process of implementing an algorithm he called "sort_subrange", which takes four iterators describing two ranges, one a subset of the other, and sorts the subrange - as if you had sorted the entire range. (See https://www.youtube.com/watch?v=sWgDk-o-6ZE, starting at about 31:30). I have implemented this in Boost.Algorithm (crediting Sean) - called partition_sort. However, while I was doing this, I thought of a different algorithm; one that gathered all the elements into the subrange as if the entire range was sorted, but didn't actually do the sorting. I've implemented that one, too - but I'm having a bit of trouble coming up with a name. I've used "partition_subrange", but that not that clear. Sean has suggested "elements_in_subrange" and "elements_within_subrange". Here's the declaration: template<typename Iterator, typename Pred> void partition_subrange ( Iterator first, Iterator last, Iterator sub_first, Iterator sub_last, Pred p) /// \brief Gather the elements of the subrange [sub_first, sub_last) that is /// inside the range [first, last) as if you had sorted the entire range. Any suggestions? -- Marshall

11 18

(no subject)
by Kabir Sahni 21 Oct '15

21 Oct '15

Hello! I have recently joined the mailing list and i am willing to contribute.Can anyone guide me

2 1

[metaparse] Transferring the repository to Boostorg
by Abel Sinkovics 21 Oct '15

21 Oct '15

Hi, I'd like to transfer my Metaparse repository (https://github.com/sabel83/metaparse) to Boostorg. Based on another thread on Hana, I assume I need temporary admin rights to boostorg to be able to transfer the repository. Please give me temporary admin rights (I've posted an issue for it as well: https://github.com/boostorg/admin/issues/110) or suggest another method for the repository transfer. Thanks, Abel

2 12

[Locale] New utf-8 codecvt facet in master (replacement of boost/details/utf8_codect_facet)
by Artyom Beilis 21 Oct '15

21 Oct '15

Hello, Following previous discussion regarding utf-8 facet in boost. I merged the changes to master branch. New utf8 codecvt facet that properly handles both UTF-16 and UTF-32 encoding for wchar_t (or char16_t/char32_t) is there. The major goal is to replace existing broken (*) utf8 facet existing today in boost/details/utf8_codecvt_facet.hpp/ipp It is implemented in header only so all you need is to include #include <boost/locale/utf8_facet.hpp> And install it as usual: std::locale new_locale(std::locale(),new boost::locale::utf8_codecvt<wchar_t>()); It *does not require* a separate compilation part like the one in details Note it is implemented in terms of boost::locale::generic_codecvt template<typename CharType,typename CodecvtImpl,int CharSize=sizeof(CharType)> class generic_codecvt; That has non-trivial specialization for CharSize=2 and CharSize=4 for UTF-16 and UTF-32 wchar_t/char16_t/char32_t character handling. boost::locale::generic_codecvt provides an interface for creating a range of facets for various character encodings. For example boost.locale uses it to implement various facets: - utf8 codecvt - single byte character set like ISO-8859-* or Windows-125* - wrap ICU ucnv_* and POSIX iconv APIs to create standard codecvt facet. That is why I decided to keep the implementation withing Boost.Locale library as the place that actually deals with different encoding. ----------- Once boost 1.60 will be released I encourage every library maintainer that incorporates broken boost/details/utf8_codecvt_facet.*pp to replace one with proper one from boost.locale Note: it is HEADER ONLY part and does not require any part of compiled library. Artyom Beilis (*) Current implementation does not handle utf-16 properly and can actually produce invalid utf-8

1 0

[Hana] Transferring repository to boostorg on GitHub
by Louis Dionne 19 Oct '15

19 Oct '15

Hi, I would like to know what is required from me to transfer the Hana repository from my GitHub account to boostorg. I reckon I should be added as a member of the boostorg "organization" on GitHub? Regards, Louis

2 14