- Boost - lists.boost.org

[optional] How to use optional to lazy construct obj?
by Mostafa 01 Jul '15

01 Jul '15

I'm interested in doing something along the lines of: lazy_adaptor<obj_type> lz(arg1, arg2, arg3, ...) where then lz.construct() then constructs an object of obj_type with ctor of arguments "arg1, arg2, arg3, ...". So far I have the following: (Am I on the right track?) #include <utility> #include <tuple> #include <string> #include <boost/optional/optional.hpp> template <typename... Args> struct ctor_forwarder; template <typename... Args> ctor_forwarder<Args...> make_ctor_forwarder(Args&&... args) { // Note: The "Args..." template parameter to ctor_forwarder determines how // the caller's arguments are temporarily stored. If it's an rvalue, it's // temporarily stored by value, else it's temporary stored by reference. return ctor_forwarder<Args...>(std::forward<Args>(args)...); } template <typename... Args> struct ctor_forwarder { //TODO: make ctor private. template <typename... A> explicit ctor_forwarder(A&&... args) : m_args( ::std::forward<A>(args)... ) {} /* template <typename Callable> auto forward_to(Callable && caller) -> decltype( caller(::std::forward<Args>(m_args)...) ) { return caller(::std::forward<Args>(m_args)...); } */ template <typename T> void forward_to(::boost::optional<T> & obj) { obj.emplace(::std::forward<Args>(m_args)...); } private: typedef ::std::tuple<Args...> args_t; private: args_t m_args; }; template <typename Obj, typename... Args> struct lazy_adaptor { Obj on_enter() { m_args_forwarder.forward_to(m_obj); } private: ::boost::optional<Obj> m_obj; ctor_forwarder<Args...> m_args_forwarder; }; template <typename Obj, typename... Args> lazy_adaptor<Obj, Args...> make_lazy_adaptor(Args&&... args) { return lazy_adaptor<Obj, Args...>(); } struct Sample1 { Sample1(int num, std::string str) {} }; int main() { auto df = make_ctor_forwarder(10, "Ten"); //ctor_forwarder<int, std::string> df(10, "Ten"); auto lazy_ctor = make_lazy_adaptor<Sample1>(10, "Ten"); return 0; }

1 0

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19

[Boost] [Hana] Formal review for Hana (Submissions closed)
by Glen Fernandes 30 Jun '15

30 Jun '15

Dear Boost community, The period for Hana review submissions has ended. The result will be announced on the list during this week. I would like to thank everyone on this list for your submission of a review: - Edouard Alligand - John P. Fletcher - Niall Douglas - Krzysztof Jusiak - Roland Bock - Vicente J. Botet Escriba - David Sankel - Zach Laine - Kohei Takahashi - Charley Bay - Bruno Dutra - Christophe Henry - David Stone - Lorenzo Caminiti - John Bytheway - Manuel Sánchez As well as the following people for your discussion during the review period: - Phil Endecott - Larry Evans - Abel SInkovics - Gavin Lambert - Jeremy Maitin-Shepard - Joel de Guzman - Edward Diener - Paul A. Bristow - Peter Dimov - Bjorn Reese - Paul Fultz II - Lee Clagett Once again, thank you to Louis for all your work on Hana and submitting it for Boost inclusion. Glen

2 1

[Circular Buffer]Could erase_begin run in constant time for trivially destructible objects?
by Pradhan Kumar 30 Jun '15

30 Jun '15

Hello everyone, The implementation of circular_buffer<T>::erase_begin(n) is tag-dispatched on is_scalar<T>, to use a constant time implementation for scalar types. For non-scalar types, it falls back to using rerase(begin(), begin()+n). Could we change this to dispatch on std::is_trivially_destructible? Examining the generated code, I see that the below loop has not been completed optimized out for a POD-type. (I am using Boost 1.58 and gcc4.9.2. The compile option was g++ -O3 -std=c++11 -g -DBOOST_CB_DISABLE_DEBUG -fno-inline to make it easier for me to understand the assembly.) do { destroy_item(m_first); increment(m_first); --m_size; } while(m_first != p); destroy_item is optimized out, as expected. However, increment has a "modulo" check and this prevents the above while loop from getting optimized to one instruction. template <class Pointer> void increment(Pointer& p) const { if (++p == m_end) p = m_buff; } Thoughts? Thanks, Pradhan

1 0

Change to guidelines for characters in C++ source files
by Beman Dawes 29 Jun '15

29 Jun '15

Since the very early days of Boost the guidelines for acceptable characters in C++ source files has been the 96 characters of C++ standard's basic source character set encoded in 7-bit ASCII. The inspect program also allowed several additional 7-bit ASCII characters that sometimes appear in comments. The rationale was to ensure that Boost code was portable to all compilers available at that time. We had gotten complaints that even a character as innocuous as a copyright sign (U+00A9) was causing compiles to fail on some compiler releases targeting Asian languages. UTF-8 support was far from universal. Times have changed: * Source files encoded in UTF-8 with a leading byte order mark (BOM) of the byte sequence 0xEF,0xBB,0xBF are supported by all C++ compilers that we are aware of, and this has been true for many years now. * As of C++11, the C++ language now includes types and literals directly supporting UTF-8, UTF-16, and UTF-32, and creating code points above 7-bit ASCII in such literals is much easier if UTF-8 source encoding is used. Even editors as dumb as Windows Notepad have supported UTF-8 with BOM for some time now. * As Boost Libraries start to incorporate C++11 Unicode related features, it becomes difficult to write test programs if limited to 7-bit ASCII. For example, incorporating the Filesystem TS into Boost.Filesystem requires test cases with UTF-8, UTF-16, and UTF-32 and that's painful under the current 7-bit ASCII guidelines. So... It looks to me like it is high time to change the Boost guideline for C++ source file encoding to 7-bit ASCII without BOM or UTF-8 with BOM, and to change the inspect program accordingly. Comments? --Beman

9 12

[thread] Change broken on Windows
by Edward Diener 29 Jun '15

29 Jun '15

The 8c974800f90dc5f644895f2d7247364710edcf76 change to thread made on June 23 broke its functionality on Windows. The changes to lines 642 and 659 of thread\include\boost\thread\win32\thread_primitives.hpp is obviously wrong. While I can fix locally easily enough this needs to be fixed on 'develop' ASAP.

3 2

merging from develop to master
by Stefan Seefeld 29 Jun '15

29 Jun '15

Hello, I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

6 6

[Hana] Formal review
by Manu343726 28 Jun '15

28 Jun '15

Here's my formal review of Hana - Whether you believe the library should be accepted into Boost Yes - Your name Manuel Sánchez - Your knowledge of the problem domain. I have been doing TMP side projects as a hobby, including my own tmp library in the same sense of Hana but metafunction based (Like Boost.MPL). - What is your evaluation of the library's: * Design Hana design and wording makes it look more like a Hakell library than a C++ one (All the functional concepts, algorithms etc). I think it's fine since Hana algorithms are about declarative data transformation. C++ needs that change in the way of thinking, but I expect some others (more conservative C++ programmers) to not accept Hana for not being too much "C++ish". About metaprogramming, wrapping types into template variables is a game changer. Some others noticed that doing type and value manipulation with the same code may be confusing since with templates there is a clear line between type manipulation code (templates) and value manipulation code (normal C++). I'm partially agree, but I prefer not to write/maintain two different libraries for exactly the same algorithms. That's the core value of Hana. * Implementation Tmp is usually ugly, but Louis does a great work at making code as clear as possible. Code is well divided and documented. * Documentation The library is documented in depth. I have mainly two issues: More references about basic concepts and navigation. Both are already covered by issues at github, so I will not dive into them here. * Tests Not looked. * Usefulness There are only a few libraries out there that provide this kind of STL-quality set of algorithms. Having those work with types and values worths it. As others said, there's a problem on current compiler support (Only recent versions of Clang). I like the idea of pushing towards compiler vendors, but it's true that since the beginning Boost libraries were designed to work on any C++ platform available. In my opinion, we should give Louis an opportunity, while giving vendors time to update their implementations. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I tried some experiments regarding type manipulation. No special issues raised out. It worked as expected. - How much effort did you put into your evaluation of the review? A few hours playing with the lib, plus a couple of hours to write the review. -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Formal-review-tp4677606.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[hana] Review
by John Bytheway 28 Jun '15

28 Jun '15

This is a somewhat perfunctory review of Hana, because I wanted to get something in before the end of the review period. I have submitted a few issues on GitHub, for minor things that need not be repeated here. Below are the things I found that might warrant more discussion. - Whether you believe the library should be accepted into Boost * Conditions for acceptance Yes it should. No specific conditions. - Your name John Bytheway - Your knowledge of the problem domain. User of TMP for years. Once wrote a source-to-source translator to help me write MPL programs because it was prohibitively difficult to write them correctly by hand. - What is your evaluation of the library's: * Design The design seems reasonable, and I like the adherence to mathematical concepts. The most difficult thing is getting the names right, and I know there's been plenty of debate on that. The name that most concerns me is Range, given that that term is already commonly used in Boost as a concept with a completely different meaning (in the Boost.Range sense). * Implementation Did not look. * Documentation Mostly very good, but of course there is always room for improvement. One particular thing I wanted to raise here is that I struggled to find enough information about Hana-convertibility (i.e. using the 'to' function). For example, I wondered if I could create a Tuple from a Range, and it seems I can. Then I wondered whether I could create a std::Array from a homogeneous Tuple, but it seems I cannot. How should I know these things? (This latter case of converting to an array is something I feel ought to be supported for easing the boundary between runtime and compile-time sequences) * Tests Did not look. * Usefulness Very, although not useful for me personally until I decide to bite the ABI-breaking bullet and recompile all my code in gcc 5.x with the new libstdc++. The biggest risk I see is MSVC support. Microsoft seem to be much more standards-gung-ho than they once were, so I hope it won't take too much longer before we see support. But I do encourage Louis to be wary of taking advantage of any new language features (e.g. a potential change in C++17 lambdas-in-unevaluated-contexts rules, or the compiler extension for compile-time string literals) lest it delay MSVC support. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I played around a bit, mostly with a view to finding out how bad the compiler errors are when things go wrong. The results were promising. I went looking for some code of mine to try porting to Hana, and got sidetracked by one difficulty. The first project I came across using Boost.Fusion was passing a lot of fusion::vectors across function interfaces, but the vector types were specific and the functions not defined in headers. Hana's tuple cannot easily be used in this way since the type is unspecified. I don't think this is a problem, because (a) that code was just poorly written and ought instead to be using adapted structs, which Hana does support, and (b) I can use Hana algorithms with Fusion's tuples anyway. - How much effort did you put into your evaluation of the review? A few hours reading and playing. Thanks very much to Louis for his effort. I look forward to being able to use Hana in the not-too-distant future, and I'll make GitHub issues for any more things I discover in my testing. John

3 6

Hana Views and References
by Joel de Guzman 27 Jun '15

27 Jun '15

Hello Louis, Mario Lang, a Spirit developer, played around with Hana and investigated on it's suitability for Spirit. His conclusion is that "Hana is really quite nice!". Then, he adds that: "However, Hana lacks a way to retrieve the members of a struct as references currently, which will pretty much kill a Hana based Spirit effort." So the question is: will Hana support references without resorting to using reference wrappers? I do appreciate the FP nature of Hana, but please be reminded that we're in C++. I also recall some discussion that Hana also does not support Fusion-like lightweight views. Is there a plan to support them? I haven't fully investigated yet what else Hana does not support that Fusion does, but at least these two important aspects of fusion come to mind. At the very least, I don't think Hana should advertize itself as a superset of Boost.Fusion. Faster runtime performance is also questionable, when lightweight views and reference members come into play. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

5 9