- Boost - lists.preview.boost.org

[review] Review of Outcome (starts Fri-19-May)
by charleyb123 . 28 May '17

28 May '17

Hi Everyone, The formal review of Niall Douglas' Outcome library starts today (Fri-19-May) and continues until Sun-28-May. Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/download/ boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

17 70

[review] Review of Outcome (ends Sun-28-May)
by charleyb123 . 27 May '17

27 May '17

Hi, Everyone, First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground. Thus far: (a)- some 300+ emails discussing Outcome (and more emails off-list) (b)- participation from: *- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone) (c)- Some points-of-discussion relate to: *- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes (d)- Reviews to date (sent publicly to the list): *- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May) (e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed. The review continues for several more days, ending Sun-28-May. Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

8 16

Detail headers moved
by Belcourt, Kenneth 26 May '17

26 May '17

Hi, I’m trying to build Boost.Graph and running into missing header files that used to live in boost/detail and now live elsewhere. Here’s a couple of examples of headers that moved and the code that still expects to find them there: detail/container_fwd.hpp libs/functional/include/boost/functional/hash/extensions.hpp: #include <boost/detail/container_fwd.hpp> libs/lambda/include/boost/lambda/detail/operator_return_type_traits.hpp: #include "boost/detail/container_fwd.hpp" libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_list.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_map.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_set.hpp: #include <boost/detail/container_fwd.hpp> detail/indirect_traits.hpp libs/iterator/include/boost/iterator/detail/facade_iterator_category.hpp: #include <boost/detail/indirect_traits.hpp> libs/iterator/include/boost/iterator/indirect_iterator.hpp: #include <boost/detail/indirect_traits.hpp> It seems that indirect_traits.hpp was moved from detail into python/detail, and container_fwd.hpp into container. Just curious but was it intentional to make many Boost libraries depend on Python through boost/iterator/iterator_facade.hpp? Noel

2 4

[outcome] some problems compiling
by Andrzej Krzemienski 26 May '17

26 May '17

So, I am trying to run my first test program with Boost.Outcome. The library fails to compile with GCC 6.3.0 on MinGW on Windows 7. I have filed the issue: https://github.com/ned14/boost.outcome/issues/36 But also, I can see in file <boost/outcome/outcome_v1.0.hpp>, lines 1267 to 1279 ``` #ifdef __cplusplus namespace { #endif typedef struct _IMAGEHLP_LINE64 { unsigned long SizeOfStruct; void *Key; unsigned long LineNumber; wchar_t *FileName; unsigned long long int Address; } IMAGEHLP_LINE64, *PIMAGEHLP_LINE64; ``` 1. Why do you check for __cplusplus? Is it a copy-and-paste of some Windows headers? 2. This class and subsequent functions are defined in anonymous namespace. This means they are redefined and recompiled in each translation unit, and remain a per TU definition. Is that intent? Regards, &rzej;

5 11

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Andrzej Krzemienski 26 May '17

26 May '17

It looks like part of the discussion accidentally went into a private conversation. So, here we are back. 2017-05-25 22:39 GMT+02:00 Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr>: > Le 25/05/2017 à 18:40, Andrzej Krzemienski a écrit : > > > > 2017-05-25 17:32 GMT+02:00 Vicente J. Botet Escriba < > vicente.botet(a)wanadoo.fr>: > >> Le 25/05/2017 à 13:18, Andrzej Krzemienski via Boost a écrit : >> >>> 2017-05-25 9:44 GMT+02:00 Vicente J. Botet Escriba via Boost < >>> boost(a)lists.boost.org>: >>> >>> We have now the possibility for uninitialized variables, but static >>> analysis tools will help here. >>> >>> So, more specifically, I understand that you propose the following: >>> >>> - Default constructor works: no T or no E is construced (similar what >>> outcome<> does) >>> >> I was not aware of this. Do you know that from this reference >> documentation? >> >> constexpr outcome () noexcept(is_nothrow_default_constructible) >> Default constructor. >> > > Well, I just assumed that since outcome<> has this empty state, it is > exactly for the purpose of giving semantics to the default constructor. But > now that you have asked, I looked at the docs. They say nothing about what > happens in the default constructor. I tried to look in the code, but was > confused with these policies. So, I just run a small test program, and yes: > default constructor creates an empty state. > > Niall, please could you add an issue in order to document default > constructors (if it doesn't already exists). > This is already logged in https://github.com/ned14/boost.outcome/issues/26 > > >> >> Sorrty, I couldn't interpret it as you. >> But, if it is the case, yes, as outcome does. >> >>> - You can assing to and and destroy such an objetc (similar what >>> outcome<> does) >>> >> I don't catch what you mean here. Are you referring to the conversion >> between expected with convertible value type and error types? >> > > No, I am saying that the following should work: > outcome<T> o; // default-constructed > o = some_outcome<T>(); // this should be safe to execute > > This works already with expected even if it doesn't defaults to empty. > Ok, and you expect it to continue to work. > > >> - You will probably need to add an observer function that checks for >>> this singular state, like `is_singular()`. If not for anything else >>> it >>> would be used for assisting the static analysis tools. (again, >>> similar what >>> outcome<> does) >>> >> No. There will be no such observer. This is essential. There is no >> visible empty state. >> Or do you consider that chrono::duration should tell you if it was >> initialized or not? >> The user know if it is initialized or not, but there is no tool to check >> it. >> This could be against safe programming, but we are here in C++ and we >> should provide first the raw tools and then build on top of them when we >> want more. >> >>> - other observer functions (has_value(), value(), has_error(), >>> error()) >>> cause UB when `is_singular() == true. (this is the only difference >>> from >>> outcome<>) >>> >> Not the only one. >> outcome fixes its error types. I'm proposing an extension to the current >> expected so that it can take care of the Outcome use cases and needs. >> >>> >>> Did I understand your intentions correctly? >>> >> Not completly. I don't want an observer that tells me, attention you have >> not initialized your variable, or you have moved from. This is essential. > > > Very daring. It would be easier to accept if you could show a tool that is > capable of statically analying this kind of "used unintialized" bug for > `expected`. > > > Static analysis to check if uninitialized variables are used (read) works > very well already . I don't remember if it si with clang-tidy that I have > seen this kind of warnings. > Ok. Now I am thinking, another thing you can do, is to internally store something like varient<T, Y, Empty> but do not expose this Empty in the interface. Instead, rewrite observer functions like this: ``` bool has_value() const { if (BOOST_UNLIKELY(_is_in_empty_state())) __builtin_unreachable(); return _is_in_valued_state; } ```

3 12

[outcome] expected<T&>, result<T&>
by Andrzej Krzemienski 25 May '17

25 May '17

Niall, Are Boost.Outcome monads intended to work with references (at least lvalue references)? If I try to compile the following program that tries to use an `result<T&>` (on GCC 6.3.1): ``` #include <boost/outcome.hpp> namespace out = BOOST_OUTCOME_V1_NAMESPACE; int g_count = 0; out::result<int&> get_ref() { return out::result<int&>(g_count); } int main () {} ``` I get lots of compiler errors. But the messages ("constructor cannot be overloaded") indicate that it was just an omission and not a design decision. If I try it with `outcome::expected` I also get these messages, but I also get a static assert saying that as per LWG decision T must be default constructible. Vicente, does this mean you cannot use `std::expected` to return references? Regards, &rzej;

5 8

Re: [boost] [outcome] expected vs. result
by Niall Douglas 25 May '17

25 May '17

> It would be very helpful to have a documentation for comparing all types, > expected, option, outcome, and result, showing the use cases and best > practices. I have some hard time to understand what one can do and the > other can not and in which cases I should prefer one. One thing very obvious in this review so far is how overwraught it has made that choice seem. I think as soon as you start writing some code using Outcome, you'll find the choice flows naturally. Using this library in your code is far, far, far easier and more intuitive than this review makes it seem. They are very simple objects, and very easy to use. Often the simpler the object, the more bikeshedding and strong opinions and noise result. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[outcome] Ternary logic -- need an example
by Andrzej Krzemienski 25 May '17

25 May '17

Niall Douglas wrote: > Finally, if you did have some special E value to mean empty, you would > have to write special checks for it in Outcome in order to give it the > stronger abort type semantics it has - if you don't have it being given > alternative semantics, then there is no point in having an empty state. > If you are writing special checks, then you might as well just have a > formal empty state in the first place. > > This argument can be generalised into the argument in favour of ternary > logics over binary logics. Sure, 90% of the time binary logics are > sufficient, but binary is a subset of ternary. And *you don't have to > use* the "other" state in a ternary logic just because it's there. Just > don't use it, so long as its implementation signals its unintentional > usage with a very loud bang, it's a safe design. > > (There is an argument that Outcome's "very loud bang" isn't loud enough. > I'd be pleased to hear feedback on that) Niall, you mention "ternary logic" here, and I guess it has to do with 'module' `tribool` exposed by Outcome library. But I do not believe I have seen in the documentation (I mean the tutorial section) how I am supposed to use it, and how it improves my programs. Or I might have just missed it. Could you give me an example? Regards, &rzej;

7 46

Re: [boost] Boost.Outcome review - First questions
by Hartmut Kaiser 25 May '17

25 May '17

Andrzej, Thanks for attempting to additionally clarify what you said before. > Again, sorry to reply on behalf of Niall, but it is my description that > might have caused the confusion. I'm glad you try to answer my questions as I know I will not get any from Niall directly. > There is still this case where you want to avoid exceptions in one part of > the program, but still use exceptions in other parts of the program. For > one example. in one "task" you launch another task with a callback > function `f`. You might want to throw from `f` and this is valid. But the > framework for launching tasks cannot afford to spill exceptions, so they > have to catch and somehow transport the exception (e.g., by exception_ptr) > then in the other task, you might want to re-convert to an exception. > (something similar to what std::future does.) I understand what you're saying, std::future needs a (conceptual) variant<T, exception_ptr> to store its state. So if I hear you correctly, outcome::expected<T, exception_ptr> could be used for that. > Other situation, is when you are using a third-party library, which throws > exceptions. You want to wrap it into a component that does not throw. > Boost.Outcome also supports in a convenient way this transition from and > to exceptions. Ok. > Also, maybe you will find of use the following example that tries to > illustrate the basic use case of the library: <snipped code example> Thanks, I think I've seen this in the docs. All of this could have been done with a variant<T, some_error_type> without changing the semantics, yes? So I guess the next question I would like to ask is: what is the benefit of using outcome::result<T> over std::optional<T>, and outcome::expected<T, E> over std::variant<T, E>? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3

Re: [boost] Boost.Outcome review - First questions
by Hartmut Kaiser 25 May '17

25 May '17

Andrzej, > Thanks, I think I've seen this in the docs. All of this could have been > done with a variant<T, some_error_type> without changing the semantics, > yes? > > So I guess the next question I would like to ask is: what is the benefit > of using outcome::result<T> over std::optional<T>, and > outcome::expected<T, E> over std::variant<T, E>? > > At some conceptual level, yes, `outcome::expected<T, E>` is like > `variant<T, E>`. Two other types from this library could also be described > in terms of variant: > `outocome::result<T>` is like `variant<T, outcome::error_code_extended, > empty_state>` > `outocome::outcome<T>` is like `variant<T, outcome::error_code_extended, > std::exception_ptr, empty_state>` > Technically, you could use variant everywhere, but the tools from > Boost.Outcome offer an interface tailored to the use cases, loike > contextual conversion to bool. Also, a more focused scope than variant > offers room for optimizations. All of those could be equally well provided by a set of free-standing generic functions. There is no need to introduce yet another inventory type. As said elsewhere, a 'using expected<T, E> = variant<T, E>;' would do us the same in this case. > Having this `empty_state` is under debate. I hope at least the empty state gets dropped on the floor, even if I think the whole expected<> business is overkill and introducing a minimally necessary set of monadic helper functions (Vicente mentioned PossibleValue, MonadError, etc.) would be sufficient in many ways. With those functions a simple variant<T, E> would give us all we need. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Boost.Outcome review - First questions
by Vicente J. Botet Escriba 25 May '17

25 May '17

Hi, I've tried to read the tutorial, but it is too long for my taste. I will try it later on :( A minor issue * "As inferred in the example code cases earlier, you can check if an |expected<T, E>| has an expected value via a simple test for boolean true or more explicitly via |.has_value()| before retrieving the value using |.value()|." This is not correct. It is correct for the de-reference operator, but .value() don't needs any check with .has_value(). Instead of some deviation, I would expect a report of all deviations and a rationale explaining why it is better to do this way. # "Types |T| and |E| cannot be constructible into one another. This is a fundamental design choice in basic_monad to significantly reduce compile times so it won't be fixed." * "Note though that |expected<void, void>| is permitted (which is legal in the LEWG proposal)." What are the compile time cost |associated the std::experimental::expected<T,E>? | I don't see what |expected<void, void> could mean. | # |unexpected_type<E>| is implemented as an |expected<void, E>| and it lets the basic_monad machinery do the implicit conversion to some |expected<T, E>| through the less representative to more representative conversion rules. Note that our Expected passes the LEWG Expected test suite just fine, so you probably won't notice this implementation detail in your code. The test of my POC implementation couldn't be complete, so this is not a sign of compatibility. Which operation allow to convert expected<void,E> to expected<T,E> and what is the expected behavior if expected<void,E> has a value? # Our |expected<T, E>| defaults E to |std::error_code| rather than |std::error_condition| (the LEWG proposal fixes this in P0323R2). I don't have a strong opinion on which default would be the best. As you suggested, I have added it to the next revision. We don't implement the ordering and hashing operator overloads due to https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/. The fact the LEWG proposal does as currently proposed is a defect (it will be discussed by LEWG with P0323R2 in Toronto). As for optional this could be considered a defect. The question is if we want expected to differen from the optional interface. If we considered it a defect, I don't believe that we should remove comparison, but IMHO we should make the constructor from T explicit. I don't expect the committee to fix this for expected and let the issue for optional. We will see. # We don't implement |make_expected_from_call()| as we think it highly likely to be removed from the next version of the proposal due to it conferring little value. This is possible and the function can be implemented very easily. I can live with and without it. # Our |make_expected()| and |make_unexpected()| functions deviate significantly as we believe the LEWG ones to be defective in various ways. This topic will be discussed in Toronto and reconciliation later is highly likely. Please, could you tell how those are defective so that we can fix them? Otherwise I don't see what we could discuss in Toronto. # Our |value_or()| member functions pass through the reference rather than returning by value (we don't understand why the LEWG proposal does except that |std::optional<T>| does, which itself is a bad design choice and it should be changed). Well, what is the advantage to returning by reference? Rather than |void|, our |value_type| and |error_type| typedefs are set to a descriptive compiler error generating type if the Expected is configured with |void|. If you want to know if no type was configured, use the static constexpr bools at |expected<T, E>::has_value_type| and |expected<T, E>::has_error_type| or use |raw_value_type| and |raw_error_type|. The reason for this deviation is to make metaprogramming using Outcome's transports much easier and less error prone. Sorry. I don't understand what is the issue. Could you elaborate? # Our Expected always defines the default, copy and move constructors even if the the type configured is not capable of it. That means |std::is_copy_constructible| etc returns true when they should return false. The reason why is again to significantly improve compile times by hugely reducing the number of templates which need to be instantiated during routine basic_monad usage, and again this won't be fixed. Instead use the static constexpr bools at: Defining these operation when they can not be implemented means that you cannot use SFINAE on this type. Maybe I'm wrong, but I believe we want to check if a type is constructible, ... using the C++ standard type traits. Next follow the first questions I have mainly from the reference documentation of expected<T,E>. In general I find most of the operation not specified enough. I would like to have something in line with the standard way of specifying an interface. * it is not clear from the reference documentation if expected<void,E> is valid? |* |is expected<T,E> the sum type of T, E and empty? and exception_ptr? |"outcome<T>| can be empty, or hold an instance of a type |T|, or hold an instance of |error_code_extended|, or hold an instance of |std::exception_ptr|. This saves you having to wrap an error code into an exception pointer instance, thus also avoiding a memory allocation." std::experimental::expected requires that its Error type to be no throw constructible, copyable and movable. What are the exception warranties for |error_code_extended? | What are the exception warranties for |outcome<T>||? | * inplace construction What is the difference between: constexpr expected (value_t _) noexcept(std::is_nothrow_default_constructible< value_type >::value) Implicit constructor of a valued monad (default constructed) and constexpr expected (in_place_t, Args &&... args) noexcept(std::is_nothrow_constructible< value_type, Arg, Args... >::value) when there is no Args. IMO the second subsumes the first and so there is no need fro the first overload and the value_t tag. * default constructor constexpr expected () noexcept(is_nothrow_default_constructible) Default constructor. This doesn't say what the default constructor does. * Shouldn't constexpr expected (in_place_t, std::initializer_list l) noexcept(std::is_nothrow_constructible< value_type, std::initializer_list>::value) Implicit constructor from an initializer list. be constexpr explicit expected(in_place_t, initializer_list il, Args&&... args); * What is void_rebound and where it is defined constexpr expected (const void_rebound &v) noexcept(std::is_nothrow_copy_constructible< error_type >::value) Implicit constructor from an identically configured basic_monad<void> by copy. * construction from error type What is wrong with template <class... Args> constexpr explicit expected(unexpect_t, Args&&...); template <class U, class... Args> constexpr explicit expected(unexpect_t, initializer_list, Args&&...); Why do you prefer an implicit conversion. This deviation must be in the rationale of the differences. constexpr expected (const error_type &v) noexcept(std::is_nothrow_copy_constructible< error_type >::value) Implicit constructor from a error_type by copy. constexpr expected (error_type &&v) noexcept(std::is_nothrow_move_constructible< error_type >::value) * raw types It is not clear what is the difference between xxx and raw_xxx typedef value_storage_type::value_type value_type The type potentially held by the monad. typedef implementation_policy::value_type raw_value_type The raw type potentially held by the monad. typedef value_storage_type::error_type error_type The error code potentially held by the monad. typedef implementation_policy::error_type raw_error_type The raw error code potentially held by the monad. typedef value_storage_type::exception_type exception_type The exception ptr potentially held by the monad. typedef implementation_policy::exception_type raw_exception_type The raw exception ptr potentially held by the monad. * What is the "The exception ptr potentially held by the monad"? * what is the sizeof expected <T,E>? * is basic_monad something proposed or an implementation detail? If the first, this should be renamed, if the second this class should not appear in the documentation and the word monad should be banned. * What is expected<Policy> in template<class Policy , typename = typename std::enable_if<std::is_same<typename implementation_policy::value_type, typename Policy::value_type>::value || std::is_void<typename Policy::value_type>::value || std::is_constructible<typename implementation_policy::value_type, typename Policy::value_type>::value>::type, typename = typename std::enable_if<std::is_same<typename implementation_policy::error_type, typename Policy::error_type>::value || std::is_constructible<typename implementation_policy::error_type, typename Policy::error_type>::value>::type, typename = typename std::enable_if<std::is_same<typename implementation_policy::exception_type, typename Policy::exception_type>::value || std::is_constructible<typename implementation_policy::exception_type, typename Policy::exception_type>::value>::type> constexpr expected (expected< Policy > &&o, explicit_conversion_from_different_policy=explicit_conversion_from_different_policy()) Explicit move constructor from a basic_monad with a differing implementation policy. For this constructor to be available, value_type, error_type and exception_type must be identical or constructible. * move constructor/copy constructor The reference documentation doesn't says what this does. * Missing move/copy assignment * bool conversion should be explicit * is_ready has nothing to be with expected. * Shouldn't value_or return by value? otherwise what would be the difference between get_or and value_or? * emplace. Missing overload template <class U, class... Args> void emplace(initializer_list, Args&&...); * swap: What is the meaning of swapping an expected with an option? swap must follow the standard signature. * Missing preconditions on the observers, which make them wide operations. Saying that they return an address makes them wide operations however accessing to the contents of this address will be undefined behavior. I prefer the standard way, defining a narrow function and stating clearly the pre-conditions. * what error_or <https://ned14.github.io/boost.outcome/structboost_1_1outcome_1_1v1__xxx_1_1…> returns if it contains an exception? * what is the difference between get_error_or and error_or? https://github.com/ned14/boost.outcome/issues/19 * Missing overload for get_unexpected. In addition it doesn't return an unexpected_type. constexpr const E & get_unexpected () const; Best, Vicente

12 63

boost.interprocess atomic uint64?
by dnj0496 24 May '17

24 May '17

Hi, I am looking at interprocess/detail/atomic.hpp file and all atomic operations seem to be dealing with uint32. Does boost interprocess not support uint64 types? Can it work similar to std::atomic<type>? Thanks. Dk. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-interprocess-atomic-uint64-tp46945… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[outcome] expected vs. result
by Andrzej Krzemienski 24 May '17

24 May '17

Niall, I am trying to summarize differences between `expected<T, error_code>` and `result<T>`. So far, I have identified the following: 1. API/ABI stability guarantees. 2. `result` has empty state - `expected` does not. 3. `result` uses error_code_extended for more error details in the ring-buffer. 4. No ordering (operator<) for `result` Is the above list complete? Regards, &rzej;

2 1

issue in using vector in version 1.64
by Rishabh Arora 24 May '17

24 May '17

Hello, I just build the latest version of boost (1.64) I tried running the following code: http://ideone.com/n6FSKr It didn't compile and instead gave the following error: https://usercontent.irccloud-cdn.com/file/Pf0b8F8L/Screenshot%20from%202017… Can someone please help in understanding and rectifying it. Thanks in advance, Best Regards, Rishabh

4 3

Request for endorsements for mp11
by Peter Dimov 24 May '17

24 May '17

Would anyone be so kind as to formally endorse mp11 as a candidate for Boost? As a reminder, mp11 is a simple C++11 metaprogramming library, available at https://github.com/pdimov/mp11/ CSS-less documentation can be viewed at https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html

9 15

std::auto_ptr in public interfaces
by Daniela Engert 23 May '17

23 May '17

Hi everybody, you are probably aware of the fact that the upcoming C++17 standard is going to remove std:auto_ptr (and other deprecated features), and that MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed features when compiling in a 'later than C++14' mode (i.e. /std::c++latest or /std:c++17). Today I've learned that latest versions of libc++ also no longer supply std::auto_ptr when compiled in C++17 mode. Some time ago I've talked about an in-house version of Boost which no longer requires these deprecated features and builds and passes tests in C++17 mode. As of yesterday I've completed my pull-requests against all those libraries using any of these features (¹), to deal with this situation where required - except for two libraries: locale and ptr_container. These two remaining libraries use std::auto_ptr in their public interfaces and replacing std::auto_ptr with std::unique_ptr is not as easy as a replacement of std::auto_ptr used in the bowels of a library or in test code. It would impose respective changes to user code as well. In our company we just got rid of all traces of std::auto_ptr and happily keep on using locale and ptr_container just as before. So guys, what's your opinion of how to deal with this situation? Ciao Dani ¹ algorithm, asio, assign, bimap, container, gil, graph, icl, interprocess, intrusive, lockfree, msm, phoenix, polygon, random, range, regex, statechart, test, typeof, wave, xpressive -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

10 19

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[review] PolyCollection formal review results: ACCEPTED into Boost
by Ion Gaztañaga 23 May '17

23 May '17

Hi, Thank you for your participation in the PolyCollection review. I'll try to collect all votes and summarize the agreed changes on the library. ----- Votes ----- I count 8 (all positive) reviews and votes from Pete Bartlett Andrzej Krzemienski Hans Dembinski Thorsten Ottosen Vinnie Falco Edward Diener Brook Milligan Steven Watanabe -------- Comments -------- Additionally the following boosters did some positive comments on the library and made some questions Dominique Devienne Adam Wulkiewicz Myself No comment was blocking for the acceptance of the library so Boost.PolyCollection is accepted into Boost, congratulations to Joaquín! I recommend committing the library to the boostorg repo as soon as possible in order to start regressions and try to include the new library in Boost 1.65. Many of the proposed changes are one-liners in the documentation and code and hopefully will be ready for Boost 1.65. Deeper changes can wait until Boost 1.66. --------------------------------------- Summary of agreed comments and changes: --------------------------------------- ------------------ Dominique Devienne (positive comment) https://lists.boost.org/Archives/boost/2017/05/234672.php ------------------ "I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage" Joaquín will try to play with this idea to see how it fares performancewise. ------------------ Pete Bartlett (positive review) https://lists.boost.org/Archives/boost/2017/05/234669.php ------------------ "It may be worth remarking in the docs what facilities are used for the type registries that are presumably behind the scenes. From the reference section I think RTTI is required. Is this a hard limit or could Boost.TypeIndex be used?" Additional comment from the review manager: Consider making RTTI customizable. Boost.TypeInfo should be easily usable. In any case document the use of RTTI in the documentation. Joaquín will consider the customizable RTTI, will document that RTTI is required by the library. ------------------ Andrzej Krzemienski (positive review) https://lists.boost.org/Archives/boost/2017/05/234716.php ------------------ [1] "Based on my experience OO-inheritance solutions are faster that using `variant`. As you say below, I was suggesting the alternative design: `variant_collection`." Joaquín: "Some have asked for a variant_collection to be part of Boost.PolyCollection roadmap." [2] "I am not comfortable with per-segment functions having the same name as container-wide functions" Joaquín: "On the contrary, I like name overloading better, because it looks terser yet sufficiently expressive" [3] "I observed that the following small program crashes (assertion fails). According to the documentation this should throw an exception upon insertion rather than firing assertions" Joaquín: I think the assertion will be removed. [4] Commenting c.insert(x) / c.insert(it,x) reference: "And maybe it is just me, but I cannot make the sense of it" Joaquín: There is a typo that will be fixed. Will reword the reference sections into a more digestible form. ------------------ Ion Gaztañaga (positive comment) https://lists.boost.org/Archives/boost/2017/05/234729.php https://lists.boost.org/Archives/boost/2017/05/234745.php ------------------ [1] Model-based polymorphism: "Wouldn't be a good idea to make this model-based polymorphism (or a refined one) public? Maybe the current model needs more work to support additional polymorphism models." Joaquín: I'd be really conservative here and withhold such a big move until real use cases are found. The problem is once this is made public the design of the lib becomes effectively frozen. Will study it for the future if there's demand. [2] Optimize memory-indirection caused by unique_ptr: "segment_type could directly hold the class derived from segment_backend as packed_segment/split_segment will need the same size and alignment requirements regardless of the ConcreteType they hold (as long as they use std::vector). This could improve insertion times and other operations. This optimization could also make easier to fix the following section (allocator propagation)." Joaquín: In principle if the optimization is reasonably implemented t'd be welcome. [3] Allocator propagation: The library does not correctly propagate the allocator to support the scoped allocator model. Joaquín will fix this. [4] In many operations the dynamic type of the object to be inserted or manipulated can be known at compile, so the internal virtual call overhead can be optimized. Specially in "insert" and "emplace", but many other operations that work with a single segment can be optimized as well. Joaquín will review operations and will try to "staticfy" as much as possible. [5] Documentation should reflect some operations, like size<T>(), empty<T>() and others are not constant-time cheap operations. Thorsten suggested: The documentation should defin k = # of segments in container and add in those operations "Complexity: linear in k" as the explanation. Joaquín will document it. --------------- Adam Wulkiewicz (comment, but positive) https://lists.boost.org/Archives/boost/2017/05/234662.php --------------- [1] Polycollection doesn't meet the requirements of C++ container as defined in the standard, specially section (23.2.1.3). Joaquín: The part about 23.2.1.3 is not listed among the differences, will include it. --------------- Hans Dembinski (positive review) https://lists.boost.org/Archives/boost/2017/05/234694.php --------------- [1] "boost::function_collection was not so clear to me. It is nice to keep the narrative of game development going, but like someone said before, I think it would help to give a simpler example" Joaquín will improve the explanation [2] "I felt that the benefit of using boost::function_collection was not so clearly presented as for boost::base_collection. The function pointers are all the same size, so how exactly does the optimisation enter" Joaquín will improve the explanation. [3] "I tried to compile the tests on a Mac with Apple-clang 8.0.0. It worked after I manually specified "cxxflags=-std=c++11" Note from the review manager: No fix was discovered, I suggest working on this as many Apple users will have this problem. --------------- Thorsten Ottosen (positive review) https://lists.boost.org/Archives/boost/2017/05/234697.php --------------- [1] "OO programming and copyability of classes is not something that everybody is going to like. (...) Would it be possible for the library to pick up a private or protected copy-constructor when needed, possible via a friend declaration? (...) being able to have your hierarchy non-copyable while allowing copyability within the container is important IMO." Moveability is already required to store classes in the segment. Joaquín will study the possibility of using a copying traits class to let users customize this point. [2] "I miss range versions of the various iteration patterns so I can use them directly with a range-based for. E.g. instead of" Joaquín will implement it. [3] "Inside the segments you store std::vector. I could easily imagine the need to store something else, (...) Therefore I would love to have a second defaulted argument set to std::vector" Element contiguity is a key property and this customization requires a lot of work. Deferred for the future if there is demand for it. [4] "Implementation of equality: do we need to be set like semantics (two-pass)? Why don't you just delegate to the segments after checking the size?" Joaquín proposed a new slightly better implementation. [5] "tutorial: consider using override where appropriate" Joaquín will review code to use it. [6] "why ==,!= but not <,>,>=, <=" Joaquín followed the interface of std::unordered_set, [Review manager's comment: Consider explaining this in the documentation] [7] "Clarify that boost::poly_collection::for_each <warrior,juggernaut,goblin,std::string,window>( //restituted types c.begin(),c.end(),[&](const auto& x) loops over all elements or only the specific" Joaquín will clarify it. [8] "It could be good to have a performance test of erase in the middle/front." Joaquín will test it. [9] "using the identifier "concept" may require change in the near future?"s Joaquín will change it. [10] "I wouldn't mind seeing separate graphs for 0-300 elements." Joaquín will add it. [11] 2clarify test are without use of reserve" Joaquín will clarify it. [12] The test are testing best possible scenario; a more realistic test would be to copy pointers to an std::vector<base*>, shuffle it and run update on that. Joaquín will consider this, maybe additionally for 1-1000 elements. --------------- Vinnie Falco (Positive review) https://lists.boost.org/Archives/boost/2017/05/234704.php --------------- [1] "Iterators returned by begin<T>() produce a long, ugly compile error when compared against iterators returned by begin() or end()." Joaquín will study the issue. He's not sure if this can be improved. --------------- Edward Diener (positive review) https://lists.boost.org/Archives/boost/2017/05/234762.php --------------- [1] "It is also hard to understand what the advantage of a poly collection of these objects entail over a more normal C++ collection ( vector, array etc. ) of std::function<Signature> objects, since the latter object type already represents a generalized callable construct in C++." Joaquín will think about how to make the intro part more accessible. [2] "I have mentioned previously that I think the documentation should be more specific about the types being used for the boost::function_collection" Joaquín will take these points, and try to improve docs so as to make these aspects clearer. --------------- Brook Milligan (positive review) https://lists.boost.org/Archives/boost/2017/05/234872.php --------------- [1] "The only problem was that the following test cases needed -std=c++14 (rather than c++11) because std::make_unique is not defined for c++11 on that compiler: algorithms, basic_function, and segmented_structure. Perhaps a mention of the need for c++14 in some examples?" Joaquín will fix in the corresponding Jamfile.v2 and will mention it in the examples. --------------- Steven Watanabe (positive review) https://lists.boost.org/Archives/boost/2017/05/234877.php --------------- [1] Several documentation fixes Joaquín will apply recommended fixes [2] Change type_erasure::is_subconcept<type_erasure::assignable<>,Concept2>::value as Boost.TypeErasure was recently extended to support move assignment. [3] Fix "type_erasure::is_subconcept<type_erasure::typeid_<>,Concept>::value " with "typeid_<remove_cv_t<remove_reference_t<T>>> " [4] Fix "static void* subaddress(T& x){return boost::addressof(x);}" as it does not support multiple inheritance [5] Fix "return r(std::forward<Args>(args)...);" that does not correctly handle "void" return types. Joaquín will fix all of them [6] "make_index_sequence<N>" can be implemented more efficiently: Joaquín will find a better implementation. Review manager's comment: see https://stackoverflow.com/questions/17424477/implementation-c14-make-intege… [7] poly_collection is defined in namespace detail, internal functions can be found by ADL Joaquín will try to limit what ADL can find.

3 2

[config] Need help with clang config
by John Maddock 22 May '17

22 May '17

I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone? Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 8

Re: [boost] Request for endorsements for mp11
by Bjorn Reese 22 May '17

22 May '17

I endorse mp11.

1 0

base64 ?
by Greger 22 May '17

22 May '17

Hi all, First: As an introduction: I am new on this list. Joined a few weeks ago. Second:is there any interest in base64? I have a library for encoding and decoding, which I could contribute. Thank you, tc Greger

6 7

Boost.Outcome and the C++ standard proposals
by Vicente J. Botet Escriba 20 May '17

20 May '17

Hi, for those that will follow the Boost.Outcome review I wanted to share some links related to the standard: The draft of the next revision : * D0323R2 -*A proposal to add a utility class to represent expected monad *(Revision 4) - https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r… The monadic interface draft proposal * DXXXX - *C++ Monadic inteface* - https://github.com/viboes/std-make/blob/master/doc/proposal/monads/Monads.md This is based on Hana customization in its pre-Boost version. And last a very draft paper I don't pretend to send to the standard meetings, at least not yet, about how FileSystem TS could be adapted to take in account the proposes status_value and expected classes. * DXXXX -*Refactoring FileSystem TS using **|expected|**or **|status_value|*||- https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DXXXXR… This paper show that there is not silver bullet solution to reporting errors, but that making abstractions as status_value or expected makes the interface more clear, composable and readable (for me at least) than using out parameters error codes. The paper show also that wanting to have exception interfaces and non-exception interface forces to double the interface. Using expected could reduce it at the price of using .value(). I have an POC implementation in https://github.com/viboes/std-make/tree/master/include/experimental/fundame… Look for expected, functor, applicative, monad, monad_error folders for the implementation and std for the customization. My intention is to show that there is something on-going on the standard aside the expected proposal as requested by the committee. Note these drafts are of course not reviewed yet by the committee and I don't know if they will like the direction. We will see in Toronto next July Best, Vicente P.S. The dead line for next meeting is the 19 Jun. Any feedback is welcome, but as this is not C++ standard ML, I will prefer to have this feedback either privately or vi a the std-proposals ML.

2 1

[outcome] Changelog of all changes made since review announcement one week ago
by Niall Douglas 20 May '17

20 May '17

Dear list, The Outcome review begins later today, but so much feedback has landed this past week already that I had better announce what has changed in develop branch to prevent people reraising already fixed things: ## 20170519 boost_peer_review4: - Issue #13 The opcode counting CI tests in test/constexprs was severely broken on POSIX. Thanks to Tom Westerhout for finding the problem and supplying its fix. - unittests.cpp had become clang-tidy unclean, fixed. - Issue #15 Move `outcome::expected<T, E>` into `outcome::experimental::expected<T, E>`. Thanks to Vicente J. Botet Escriba for persuading me to do this. - Issue #14 Removed all the static asserts in the Expected implementation apart from the nothrow move constructor check, which is now correct unlike the incorrect assert from before. Thanks to Vicente J. Botet Escriba for explaining Expected's semantics. - Issue #21 Correct misspelling of `extended_error_code` with `error_code_extended` in the docs. Thanks to Deniz Bahadir for reporting this. - Issue #17 Give credit to Paul Bristow for the name "Outcome". Thanks to Peter Dimov for finding the correct person. - Issue #18 `result<T>` had a `.set_exception()` which it should not have had. Thanks to Peter Dimov for reporting this. - Issue #19 Remove observers `.is_ready()`, `.get_error_or()`, `.get_exception_or()`. Thanks to Peter Dimov and Andrzej Krzemienski for suggesting this. - Issue #20 Rename: - `monad_error` to `bad_outcome` - `monad_errc` to `bad_outcome_errc` - `monad_category` to `bad_outcome_category` - `BOOST_OUTCOME_THROW_MONAD_ERROR` to `BOOST_OUTCOME_THROW_BAD_OUTCOME` Thanks to Peter Dimov, Andrzej Krzemienski and Paul Bristow for suggesting this. If anyone prefers to see these changes in a tarball, you can get a tarball at https://github.com/ned14/boost.outcome/releases/tag/boost_peer_review4 or the boost_peer_review4 tag in git. Note that this tarball was generated straight off develop branch from my laptop and MAY NOT WORK well. I didn't get a chance to implement these outstanding issues before the review began: - https://github.com/ned14/boost.outcome/issues/11 Expected should never have a valueless state - https://github.com/ned14/boost.outcome/issues/12 Copy assignment gets instantiated even when type T cannot be copied - https://github.com/ned14/boost.outcome/issues/16 Default constructor of T is sometimes compiled when T has no default constructor Thanks in advance for your feedback and reviews. As I hope the above shows, it makes a big difference. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

[context] Windows x64 fiber local storage GS offset
by Elbert Mai 20 May '17

20 May '17

The Windows x64 implementation of Boost.Context saves fiber local storage from GS:[0x18]. For example, in jump_x86_64_ms_pe_masm.asm: ; load NT_TIB mov r10, gs:[030h] ; save fiber local storage mov rax, [r10+018h] mov [rsp+0b0h], rax However, this is the NT_TIB struct as defined in winnt.h typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; union { PVOID FiberData; DWORD Version; }; PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; This implies that fiber local storage is found in GS:[0x20], not GS:[0x18]. The Windows x86 implementation uses FS:[0x10], which is consistent with the NT_TIB struct. Am I missing something, or does Boost.Context save/restore fiber local storage at the wrong address in Windows x64?

3 3

[Beast] Discussion
by Vinnie Falco 20 May '17

20 May '17

A desire was stated in the 2015 formal review for Boost.Http, that the author would engage the community during the development of the library. I've been doing that throughout the development of Beast and I will continue to do so. So I am inviting you and anyone else who would like to participate in the design and evolution of this library to weigh in with comments on anything that you would like, ahead of the Beast formal review (scheduled July 1st). Your feedback can help make the library better! On Sat, May 20, 2017 at 8:19 AM, Bjorn Reese via Boost <boost(a)lists.boost.org> wrote: > On 05/20/2017 04:17 PM, Vinnie Falco via Boost wrote: > >> I hope readers are convinced that HTTP requests and responses should >> be modeled as self-contained objects with all necessary fields >> prescribed by rfc7230, and that the HTTP status should be neither >> separate nor stored in an error_code. > > > Not really, but that is the subject for a review of a different library. Here's a nice new thread for the discussion.

1 0

[math] Chebyshev polynomial
by Bjorn Reese 20 May '17

20 May '17

Does Boost.Math contain functions for Chebyshev polynomials? Preferably a recurrent chebyshev_next(). I can find functions for Legendre, Laguerre, and Hermite polynomials, but not Chebyshev.

3 3

[review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by charleyb123 . 19 May '17

19 May '17

Hi Everyone, ** HEADS UP, NEXT WEEK ** The formal review of Niall Douglas' Outcome library starts next week (Fri-19-May to Sun-28-May). Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/ download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

14 92

[outcome] Fix with support for VS2017 Update 1
by Niall Douglas 19 May '17

19 May '17

Earlier today Vinnie Falco found that the peer review edition of Outcome does not compile on Visual Studio 2017 Update 1. I do apologise for this. Update 1 came out a few days before the peer review edition was set in stone. I didn't know it had until now, and I tested against VS2017 RTM, not Update 1. I have applied a fix to develop branch and cherry picked just this fix to the frozen master branch. You can find that fixed peer review edition at this branch: https://github.com/ned14/boost.outcome/tree/master_vs2017_fixed I hope that this does not inconvenience people too much, and once again, sorry. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 3

[offtopic] Who has the power to create Trac accounts nowadays?
by Niall Douglas 19 May '17

19 May '17

Sorry for asking boost-dev, but had no reply on boost-steering. I've got some new GSoC mentors wanting to contribute to https://svn.boost.org/trac/boost/wiki/SoC2017 but they need a Trac login to do so. Who has that power, and can they grant me the power to create Trac accounts as this comes up every year? I'm ned14 on Boost Trac. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

Any Projects that need significant contribution?
by GuillermoReyes 19 May '17

19 May '17

Hi all, My name is Guillermo - I am currently looking to significantly contribute to the boost library. In fact, I recently applied for gsoc17. I am willing to work on the nearly antipodal points issue (astroid problem), but am open to contributing to others as well. I have accepted an internship offer, so my time may be limited to part time work. I really want to contribute to the library :) Thanks Again, Sincerely, Guillermo Reyes -- View this message in context: http://boost.2283326.n4.nabble.com/Any-Projects-that-need-significant-contr… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[review] Review of PolyCollection is finished, thanks!
by Ion Gaztañaga 18 May '17

18 May '17

Hi, The review period for PolyCollection has come to an end. Thanks to all participants for submitting their reviews, and sharing their insights. All votes have been positive, so congratulations to Joaquín, PolyCollection will be accepted. I will collect all the suggestions, fixes and change proposals during this weekend and post an official result announcement in a few days. I encourage everyone to continue discussing further issues that can improve the library in the mailing list. Best, Ion, review manager

2 1

[dynamic_bitset] Comparison operators without assertions
by Pavel Kretov 18 May '17

18 May '17

Hi all. Looking through boost::dynamic_bitset code, I found a interesting inconsistency between its operator== and operator<. Namely, the first works well with bitsets of different size, while the second triggers an assertion: boost::dynamic_bitset<> a(std::string("111")), b(std::string("1110")); a == b; // false a < b; // Assertion `a.size() == b.size()' failed. This means that we cannot reliably use dynamic bitset within ordered containers like std::set or std::map. Since the standard library has distinct concepts of equality and equivalence (see [1]), it's fine to have different comparison behaviors in dynamic_bitset. However, as far as I can judge, equivalence is a metaphysically broader concept than equality, we shouldn't restrict it to bitsets of the same size only. So, the questions: 1. May I remove that assertion? (It won't be a breaking change, after all). 2. How about doing the same thing to bitwise operators, too? Instead of throwing an assertion if sizes don't match, it may be worth to generalize the operators definitions. I can see several possible schemes, but not all of them are consistent enough. 3. Shouldn't BOOST_ASSERT be used instead of the one from assert.h? ――― Pavel K. [1]: http://en.cppreference.com/w/cpp/concept/EqualityComparable

8 25

[poly_collection] Memory allocation and allocator propagation
by Ion Gaztañaga 17 May '17

17 May '17

Hi Joaquín, Some additional comments about the design: ///////////////////////// // Memory indirections ///////////////////////// If I understand code correctly, the internal structure of a poly collection is approximately: 1) poly_collection stores an unordered_map<type_index, segment_type> 2) segment_type stores a unique_ptr<segment_backend> and segment_backend_is an abstract class, so roughly equivalent to unique_ptr<packed_segment/split_segment> (both packed_segment/split_segment derive from segment_backend. 3) packed_segment/split_segment stores a vector of concrete types. So we need 3 memory hops to navigate between the "this" pointer of a PolyCollection to a pointer to a concrete type: poly_collection -> unordered node -> segment in unique_ptr -> vector value. I think the data structure could be optimized to save one indirection. segment_type could directly hold the class derived from segment_backend as packed_segment/split_segment will need the same size and alignment requirements regardless of the ConcreteType they hold (as long as they use std::vector). This could improve insertion times and other operations. This optimization could also make easier to fix the following section (allocator propagation). *Main question 1*: Do you find think PolyCollection should implement this optimization? ///////////////////////// // Allocator propagation ///////////////////////// As mentioned in Adam Wulkiewicz's review PolyCollection currently does not propagate the allocator from the constructor argument of poly_collection to the concrete type. From a practical point of view, the key requirement is that all intermediate memory until the concrete type must be allocated using the same root allocator passed when a poly_collection was constructed, and that allocator must be propagated also to the concrete type. I think this should also be the case of all memory used for auxiliary data like the index vector of split_sequence. Clause 23.2.1.3 was mentioned although I don't think this clause was designed with compound containers in mind, as IMHO all auxiliary data, including metadata that needs dynamic memory should receive the allocator and should be constructed using allocator_traits or a container that uses allocator_traits (yes, even the non-value parts of a node). Otherwise, the original intention of the new standard allocator model (use a single source of memory and propagate it transparently) wouldn't be feasible. I think that a unique memory source for all internal structures and the correct propagation of the allocator using allocator_traits is a very interesting feature for PolyCollection. Even Bjarne Stroustrup commented on this when Joaquín's article was published in isocpp ( https://isocpp.org/blog/2014/05/fast-polymorphic-collections-joaquin-m-lope…) "One thing caught my eye: The elements could be allocated using stack allocators, rather than a general new. That would make the technique applicable to hard real-time systems where general dynamic memory is banned" *Main question 2*: Do you think PolyCollection should support stateful allocator using the scoped allocator model? Some specific notes that might show places where the scoped allocator model has problems.: - PolyCollection uses operator new to allocate the packed/split_segment implementation stored in unique_ptr and also when the segment must be copied. If unique_ptr is avoided and the concrete segment is in-place constructed inside "segment" then all memory will be allocated from the original allocator. - I think "segment" is missing an extended copy and move constructor taking an additional allocator. It also would need an internal allocator_type typedef so that uses_allocator_v is true and unordered_map calls these new constructors when needed. These new constructors should be propagated to split_segment/packed_segment so that these call the extended constructors of internal vectors. - The concrete type wrappers (e.g. value_holder) also would need to support allocators with extended copy/move constructors. - The "emplace" operation uses a placement new to wrapped in a lambda which is type-erased with a captureless lambda. It looks to me that instead of delegating the work into the value_holder, the type erasure arguments should be treated by the segment so that internal vectors propagate the allocator when needed. A test to make sure everything is correctly propagated: -> Create an instance of monotonic_buffer_resource passing a big enough static buffer. -> Create a base_collection< Base, std::polymorphic_allocator<Base> > passing the address of the monotonic_buffer_resource -> Insert types Derived1 and Derived2 in the container, both of which hold a vector<int, polymorphic_allocator<int> > (for Derived1 and Derived2 are uses_allocator_v is true and they propagate the memory resource to the vector). -> After filling base_collection, no heap allocation is made and all objects are constructed in the static buffer. Best, Ion

3 8

Re: [boost] Hello Again From Facebook Engineering
by Yurii Zubrytskyi 16 May '17

16 May '17

Hi Scott, I appreciate the email. Things are going great here, and I'm really happy with Google. Anyway, even if I wanted to change jobs I wouldn't consider Facebook until it opens an office on the Eastside - commuting into Seattle is just too uncomfortable, so I'm not considering any company there Thanks! ________________________________ From: Scott Shay <scottshay(a)fb.com> Sent: Tuesday, April 18, 2017 10:03:15 AM To: Yuriy Zubritsky; boost(a)lists.boost.org Subject: Hello Again From Facebook Engineering Hi Yuriy, Sending a note to say hello again from Facebook! My great teammate, Camila, mentioned that I should reach out and see how things at Google have been going for you? Have you had some time to consider what's next in your career? I understand if this is not the right timing, kindly let me know how we can best keep in touch for when it makes more sense. Thanks a lot and I look forward to hearing back from you. P.S. in case you're curious, here's a resource that highlights some of the technical problems we tackle. https://code.facebook.com/ Scott Shay Engineering Sourcer | Recruiting M: (650) 785-6142 [id:image001.png@01D298C9.4BBDBCE0] facebook.com/careers<https://www.facebook.com/careers>

1 0

crc // wrong poly for crc_xmodem_type
by Sergei Nikulov 16 May '17

16 May '17

Hello All, I've discovered that current typedef crc_xmodem_type uses wrong poly. Current release and master branch: > typedef crc_optimal<16, 0x8408, 0, 0, true, true> crc_xmodem_type; Should be (ref: http://reveng.sourceforge.net/crc-catalogue/16.htm#crc.cat-bits.16) > typedef crc_optimal<16, 0x1021, 0, 0, false, false> Develop branch already have some changes which address this error (for ex. https://github.com/boostorg/crc/commit/328bf50f666c463901e2179aa2d890916c3b…) but master and boost release does not. Who currently owns boost::crc and can fix this issue? Thank you. -- Best Regards, Sergei Nikulov

2 2

[Convert] convert<float> doesn't respect input size
by Olaf van der Spek 15 May '17

15 May '17

Hi, const char* a = "42"; boost::string_ref b(a, 1); float c = boost::convert<float>(b, boost::cnv::strtol(), -1); // returns 42 assert(c == 4); https://github.com/boostorg/convert/issues/29 -- Olaf

1 0

Re: [boost] [http] Boost.Http review report
by Vinnie Falco 15 May '17

15 May '17

On Aug 27, 2015 at 12:21 PM, Bjorn Reese <breese_at_[hidden]> wrote: > The outcome of the formal review of Boost.Http is that the library is > NOT accepted for inclusion into Boost this time. > ... > Judging from the reviews, the following additions will > make a future submission more likely to succeed: > > 1. Involve the community more during the development. This will > both solicit earlier feedback on the design, and help to align > community expectation. I've been trying to involve the community for several months now, offering opportunities to weigh in on design decisions, provide feedback on pull requests, perform code reviews on pending merges. The response has been, to put it nicely, minimal. In particular I have not heard from anyone involved in the other proposed libraries such as Boost.Http or cpp-netlib except some initial contacts in early 2016.

2 3

Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by Bjorn Reese 14 May '17

14 May '17

On 05/11/2017 06:19 PM, charleyb123 . via Boost wrote: > GitHub: > https://github.com/ned14/boost.outcome The code has a "boost-lite" submodule. Is that part of the review?

5 13

Win10 now allows symlink creation without elevated privileges
by Niall Douglas 14 May '17

14 May '17

In case the list didn't know, from the Creator's Update onwards Windows 10 allows normal users to create symlinks if the machine is put into Developer mode: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ I don't know about others, but this will be a major time saver for me at least, I had been using hard links on Windows which are prone to accidental data loss. Niall

5 4

[poly_collection] User-defined polymorphism model
by Ion Gaztañaga 14 May '17

14 May '17

Hi Joaquín and all reviewers, Before we reach the end of the review period, I wanted to comment an (IMHO) interesting feature used in the internal design of PolyCollection. The library offers three of polymorphism models: base-derived, boost::any and signature-sharing callable types. Under the hood, the library abstracts those polymorphic models into a generic class in the detail namespace: template<typename Model,typename Allocator> class poly_collection; and each concrete container is just implemented in terms of poly_collection: template<typename Base,typename Allocator> class base_collection : public detail::poly_collection<detail::base_model<Base>,Allocator> The first template parameter (Model) is the abstraction ("concept") that implements the non-generic part of each polymorphism model. A model implements the following types and operations (comments on each attribute are my interpretation, they can be completely wrong): template<class ModelArg> class Model { // //Value-related attributes // //The type we want to expose as value_type of the container using value_type= ...; //Is T a subtype of the general type (acceptable as value)? template<class T> using is_subtype= ... //Is T the "most refined type"? template<class T> using is_terminal=... //Id of a value template<class T> static const std::type_info& subtypeid(const T& x); //Obtain a type-erased pointer to the value template<class T> static void* subaddress(T& x); template<typename T> static const void* subaddress(const T& x); // //Segment-related // //Segment iterators that point to type_erased value_types using base_iterator=... using const_base_iterator=... //const<->non-const conversions static base_iterator nonconst_iterator(const_base_iterator it); template<typename T> static iterator<T> nonconst_iterator(const_iterator<T> it); //Concrete iterators for Derived template<typename Derived> using iterator=...; template<typename Derived> using const_iterator=... //Generic type, comparable with base_iterator. //base_iterator == the last returned base_sentinel //means that base_iterator points one-past the last //element of a segment. using base_sentinel=...; using const_base_sentinel=... //Construct a segment for type T using the given allocator and //return it type-erased. template<typename T,typename Allocator> static detail::segment_backend<Model>* make(const Allocator& al); }; I have several questions on this polymorphism model. 1) Wouldn't be a good idea to make this model-based polymorphism (or a refined one) public? Maybe the current model needs more work to support additional polymorphism models. Of course requirements for each operation in a model should be detailed. A correct abstraction to define user-provided polymorphism models is hard but this seems really a great feature that makes this library more valuable for users. 2) If understand this model abstraction correctly, each Model chooses the segment type to store values (it could be any sequence type, I guess). The segment_backend abstraction does not only abstract ConcreteTypes from value_types (using void pointers that will be casted to real types in the implementation of the virtual function), but also the segment type (the sequence holding the concrete values). Current implementation uses two segment types: split_segment (stores Concrete types and generic value_type's in two separate vectors) and packed_segment (stores ConcreteTypes which already contain value_type's as a subobject). function_collection and any_collection use the first segment, base_collection uses the second. Why are different segment types needed? Can't we store value_types and ConcreteTypes in a struct and use only one type of segment? If this is possible, I guess iteration performance would be improved for function_collection and any_collection. Model definition could be simplified. On the other hand, if the sequence type can be left out of the model definition, the underlying sequence type (change vector with deque, small vector or any other) could be made configurable. Would this be useful for users? 3) I understand that caching a base_sentinel in each segment is an optimization to avoid a virtual function call when iterating with base_iterators. Is this assumption correct? Why is a different base_sentinel type needed to mark the end of each segment? Wouldn't a "base_iterator" pointing to that on-past-the end position suffice? Is an optimization (maybe base_sentinel is cheaper) or a must have? Thanks, Ion PD: I have more design questions related to other topics but I will post a different thread for each one.

2 2

Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
by Glen Fernandes 13 May '17

13 May '17

Gavin Lambert wrote: > On that note, do you know of a more-comprehensible-than-standardese guide > on how allocator_traits is supposed to be used for node-based custom > container types? I've tried to figure it out a couple times but I'm sure I'm > missing important points. What do you want to know? 1. The storage for the node should be allocated with the Allocator's 'allocate()', for an allocator instance 'a' whose value_type is the containers node type (i.e. 'a' can be achieved by rebinding an existing allocator instance in the normal way). 2. The node object itself would be constructed in the normal way - e.g. placement new to construct the node object. 3. The containers' value_type object within the node must be constructed by allocator_traits::construct(u, p, args...) where u of type U is a rebound copy of the allocator such that the allocator's value_type is the container's value_type. 4. Similar to 3, for destruction of the container's value_type object should be destroyed by allocator_traits::destroy(u, p) 5. Similar to 2, the node object is destroyed in the normal way - e.g. invoking the destructor of the node type. 6. Similar to 1, the storage for the node is deallocated with the Allocator's deallocate() (for an allocator instance whose value_type is the container's node type). Glen

1 0

[poly_collection] Andrzej's review
by Andrzej Krzemienski 12 May '17

12 May '17

Hi Everyone, Some comments from me about PolyCollection library, First, Joaquín, thank you for writing and sharing this library. I am not an an expert in the domain. In my programs I never needed this optimization. But I have seen it described in a number of publications, and I am convinced it deserves a place in Boost libraries, so that people are not forced to reinvent it. [1] Now, because I have no practical experience with the problem, what I say in this paragraph might be incorrect. But I have a problem here. You will use this library for improved performance, maybe for a game implementation, yet because a game needs super-performance, can a programmer afford to use dynamic dispatch, or RTTI or exceptions? I always imagined taht such library, rather than resembling `ptr_vector` would resemble `vector<variant<A, B, C>>`, that is: I decide and fix the container on a set of types I will be storing inside. This set of tyes is embedded in the type, so I can detect many mis-usages at compile time. The implementation can be faster, because the number of segments is fixed (no segment management), and no registration checks need to be performed. Then, iterate over such collection with a static_visitor (from Boost.Variant). Of course, this would be constraining: I need to know all the types I will be using ahead of time. But maybe in practice this is often the case? If you disagree, maybe it is wort discussing it in the rationale. [2] I am not comfortable with per-segment functions having the same name as container-wide functions, and being only overloaded based on function or template parameters, like `cc.size()` and `cc.size(index)`. These two functions do different things, so they deserve different names. Maybe `cc.segment_size(index)`, or `cc.serment(index).size()`? [3] I downloaded it and tried toy examples with GCC 6.3 on Windows with -std=c++11, and clang 3.8.1 on Fedora with -std=c++11. It compiIes fine. I observed that the following small program crashes (assertion fails): ``` #include <boost/poly_collection/base_collection.hpp> struct Iface { Iface() = default; virtual ~Iface() = 0; }; inline Iface::~Iface() {} struct Type1 : Iface { Type1() = default; Type1(Type1&&) = delete; }; struct Type2 : Iface { Type2() = default; Type2(Type2&&) {} // throwing move // no move assignment }; int main () try { boost::base_collection<Iface> c; c.insert(Type1{}); // fires an assert c.insert(Type2{}); // fires an assert } catch (std::exception const& e) { } ``` Admittedly, `Type1` and `Type2` are not "acceptable", but according to the documentation this should throw an exception upon insertion rather than firing assertions. [4] The documentation is good. As to implementation, I did not look at it in detail. Regards, &rzej;

2 2

[poly_collection] Small review
by Pete Bartlett 11 May '17

11 May '17

> > Dear Ion, Joaquin and boost mailing list, > > I hope this brief review is of some value to you. I don’t expect to be a recognised name on the mailing list but have contributed to it intermittently over the years. I have also used the author’s MultiIndex library in production for about a decade. > > I would recommend that PolyCollection be accepted into Boost. > > I think the design pattern is common enough to be Boost-ified. I have done something very similar to boost::base_collection myself in the past and have achieved useful speed ups over a solution like boost::ptr_vector in a production system. My speed-ups were not quite as good as Joaquin documents, but I can’t tell if this was due to the ineptitude of my own solution or due to lab conditions of the Boost.PolyCollection tests. > > I spent a couple of hours reading the docs and running basic examples on my default compiler (VS2015 x64) and did not experience any significant problems. > > It may be worth remarking in the docs (sorry if I missed it) what facilities are used for the type registries that are presumably behind the scenes. From the reference section I think RTTI is required. Is this a hard limit or could Boost.TypeIndex be used? > > NB the reference section has a note “REVIEW THIS DESIGN DECISION” in it. > > Personally I would attach value to the fact that the author has been a great servant to Boost over the years (as have many others) so it is likely that this would be a well-maintained library. E.g. if algorithms were added to <algorithm> in the future, they would likely end up in <boost/poly_collection/algorithm.hpp> too. > > Regards, > Pete >

3 4

[review][poly_collection] Review period EXTENDED until May 17th
by Ion Gaztañaga 11 May '17

11 May '17

Dear boosters, Some have requested a bit of time to extend the review period in order to have time to submit reviews or issue technical comments. With the approval of Review Wizards, the review of PolyCollection is extended until May 17th. Please feel free to submit review and comments. Best, Ion

1 0

[poly_collection] Two remarks
by Dominique Devienne 10 May '17

10 May '17

Just as Pete Bartlett mentioned, I'm also a fan of Joaquín's Multi-Index, which I'm used in production for many years as well. My only complaint about his proposed Poly-Collection is the fact I can't leverage and thus benefit from the performance of it, in a multi-index scenario, but as Joaquín already answered a few months ago, that's off-topic and by design, I know :) Many of my BMIs have a by-type index, and the type-partitioned storage of those in contiguous memory for by-type scans would be (greatly?) beneficial. I'd be willing to give up some iterator guarantees BMI provides, as a node-based container, for intelligent contiguous storage of elements, without myself having to maintain by-value homogeneous containers with a manually maintained BMI of polymorphic pointers to those containers' elements. My second remark is about parallelism. I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage. And perhaps even on the write side, rather than having to make the whole container thread-safe, but external mutexing for example, provide ways for a more granular thread-safety by type or segment perhaps. Again, probably off topic, but hardly something you can "add from the outside" I think, and why I mention it here and now. As merely a user of Boost, I don't feel qualified as a reviewer, beyond the two above remarks. Thanks, --DD

5 4

[build] please review the long standing pull request
by Konstantin Ivlev 10 May '17

10 May '17

Hello, There's a 2 month old pull request https://github.com/boostorg/build/pull/169. Please review and let me know any feedback.

1 0

[Thread] What is the meaning of BOOST_THREAD_USE_LIB?
by Frédéric Bron 09 May '17

09 May '17

Hi, I always use boost as static libraries. For a long time, I have been used to define macro BOOST_THREAD_USE_LIB on windows when cross-compiling from linux to windows with mingw. I have now made a new cross-compiler conformant with pthread (the previous one had only win32 api) but then boost does not build (with threadapi=posix). It seems that not defining BOOST_THREAD_USE_LIB helps. I do not remember why I used to define BOOST_THREAD_USE_LIB a long time ago and cannot find any help in the doc (http://www.boost.org/doc/libs/1_64_0/doc/html/thread/build.html) What is the meaning of BOOST_THREAD_USE_LIB? Frédéric

2 1

gsoc17 and boost.ublas
by Rishabh Arora 09 May '17

09 May '17

Hi Everyone, My name is Rishabh Arora and I have been selected to work with the BoostC++ libraries on the the project, "dataframes in ublas" as a part of GSoC '17. It will be great if someone could provide me with suggestions on how to get started with it. Thank you in advance Best Regards, Rishabh Arora

2 1

[GSOC'17] Project: Optimising Multiplications in uBLAS
by mohammad sharique 09 May '17

09 May '17

Hello Boost Community, My name is Mohd Sharique. I have been selected to work with Boost C++ Libraries under Google Summer of Code '17. My project is "Optimising Multiplications in uBLAS". It would be great if I could get some starting point for the same. Thank you, Your's sincerely, Mohd Sharique

2 1

[integer] Please fix build/test errors..
by Rene Rivera 09 May '17

09 May '17

The Integer library is causing general CI failures: < https://travis-ci.org/boostorg/boost/jobs/230199520#L6396> Please rectify ASAP. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 8

[poly_collection] throws upon insertion
by Andrzej Krzemienski 09 May '17

09 May '17

Hi, I am looking at the documentation of poly_collection. I will not be able to thoroughly review and test the library. But judging from the documentation, the problem is worth solving, and the approach to solve it is sound. I have one question/observation though. I am trying to figure out how preventing an incorrect insert() works. In the docs ( http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec…) it says that it will sometimes throw if it cannot determine the most derived type. In the class reference, I get: ( http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… ) ``` (1) c.insert(x) (2) c.insert(it,x) Effects: If the type of the subobject of t is not registered, then if this type is T and T is acceptable, does the registration, otherwise throws. If t is not a non-const rvalue expression and the type of its subobject is not CopyConstructible, throws. Inserts an element with a subobject move constructed or copy constructed from the subobject of t: (1) at the end of the corresponding segment; (2) just before the position indicated by it, if it points to the corresponding segment, or at the end of the segment otherwise. Returns: An iterator to the newly inserted element. Complexity: Amortized constant time plus linear in the distance from the insertion position to the end of the segment. ``` And maybe it is just me, but I cannot make the sense of it. First, it refers to 't' but in the signatures we have an 'x'. Next, the first sentence has two "if"s and one "otherwise" and I do not know which "if" the "otherwise" binds to. I read it as saying: if T is derived from the interface (like class `warrior`) but is not movable (which implies that T is not "acceptable"), then the program will compile fine but will later throw an exception. Is my interpretation correct? But if so, why not refuse to compile instead? Maybe it would be better tom make the prose longer in "Effects" clause, but to make it harder for misinterpretation. Regards, &rzej;

2 3

[Boost.Test] access to boost::unit_test::framework::master_test_suite().{argc, argv} outside from BOOST_TEST
by Olaf Peter 08 May '17

08 May '17

Hello, my test program uses boost.test datasets. I've wrote a filesystem loader for the input and expected data. Now I run into the problem, that boost::unit_test::framework::master_test_suite().{argc, argv} is only setup inside the tests self. My loader isn't a test case ... I can check it by using a simple mock, like struct app_mock { app_mock(); int const argc; char** const argv; }; app_mock::app_mock() : argc(boost::unit_test::framework::master_test_suite().argc) , argv(boost::unit_test::framework::master_test_suite().argv) { } BOOST_AUTO_TEST_CASE( app_mocker ) { app_mock app; std::cout << "Count = " << app.argc << '\n'; for(int i = 0; i != app.argc; i++) std::cout << "Arg = " << app.argv[i] << '\n'; } $ my_test -- my_args Count = 2 path/to/exe my_args these works, but as mentioned: dataset_loader::dataset_loader(fs::path const& path) { app_mock app; std::cout << "ARGC = " << boost::unit_test::framework::master_test_suite().argc << '\n'; read_files(path); } is always zero. How can I read the argc/argv values? Thanks, Olaf

2 4

[gsoc17] welcome Ruoyun
by Vissarion Fisikopoulos 05 May '17

05 May '17

Hi Ruoyun, congrats and welcome! As mentioned by GSoC this is the community bonding period. So you can start reading the documentation: http://www.boost.org/doc/libs/1_64_0/libs/geometry/doc/html/index.html This wiki is also useful: https://github.com/boostorg/geometry/wiki check for example https://github.com/boostorg/geometry/wiki/Contribution-Tutorial We can also start now discussing and refining you project goals. Best, Vissarion. ---------- Forwarded message ---------- From: Google Summer of Code <summerofcode-noreply(a)google.com> Date: 4 May 2017 at 19:35 Subject: GSoC 2017: You are a mentor for Ruoyun Jing To: fisikop(a)gmail.com [image: Google Summer of Code] Congratulations, you will be spending the next few months working with Ruoyun Jing on GSoC2017 Boost.Geometry:Filtering of compare distance predicates Proposal <https://summerofcode.withgoogle.com/dashboard/organization/4839090517180416…> . Please welcome <http://write.flossmanuals.net/gsoc-mentoring/community-basics/> your student into your community and work with them to plan the milestones they will need to meet. Setting clear expectations early is one of the best ways to help your student succeed. You can read the Mentor Manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/> for some great tips on how to communicate with your student and make a project plan. If you have any questions please contact our Google Open Source Programs team at gsoc-support(a)google.com or email the mentors mailing list if appropriate. -Google Open Source Programs team This email was sent to fisikop(a)gmail.com. You are receiving this email because of your participation in Google Summer of Code 2017. https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile <https://summerofcode.withgoogle.com/dashboard/profile/> and request deletion of your program profile. For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. © 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

1 0

[1.64] [ublas] Broken/regession due to Boost.Serialization changes
by Peppard 05 May '17

05 May '17

Hi, since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp gives an error like "no member named 'make_array' in namespace 'boost::serialization'", according to the official(?) test overview (http://www.boost.org/development/tests/master/developer/numeric-ublas.html) on a lot of systems. There have been discussions on this mailing list in Nov/Dec 2016 probably at least related to this ([boost] [serialization][ublas][test] failures in serialization causing regressions) and in Feb 2017 ([boost] [serialization][uBlas] Serialization still breaking anything that uses uBlas?), also there are several pull requests on GitHub, e.g. https://github.com/boostorg/ublas/pull/46. (I assume you are aware of this already, but I wonder why there was a release with a regression like this, maybe due to a maintainer missing? How are cases like these handled?) Thanks! (Sorry if this is a double post but the list address seemed to change from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)

3 2

[beast] 1.0.0-b35 has been merged to master
by Vinnie Falco 05 May '17

05 May '17

Beast 1.0.0-b35 has been merged to the master branch. Changes include: API Changes * New HTTP interfaces This version has a freshly written HTTP parser which improves on the performance of the previous parser. New interfaces are provided to allow incremental reading of HTTP messages and better handling for Expect: 100-continue. These are API breaking changes. Beast is a C++11 header-only HTTP and WebSocket library built on Boost.Asio, scheduled for Boost formal review starting July 1st. Official repository: https://github.com/vinniefalco/Beast Documentation: http://vinniefalco.github.io/beast/index.html Stakeholders and interested parties may review version the pull request for 1.0.0-b36 if desired, all feedback welcomed: https://github.com/vinniefalco/Beast/pull/330 Thanks!

1 0

Boost macros for Android
by Vicente J. Botet Escriba 04 May '17

04 May '17

Hi, I would like to inhibit some failing test on Android. Are there any specific BOOST macros for Android? Best, Vicente

3 3

Test - ignore
by Michael Caisse 03 May '17

03 May '17

-- Michael Caisse Ciere Consulting ciere.com

1 0

GMane reflection of Boost mailing list messages
by Edward Diener 03 May '17

03 May '17

I am a user of GMane in regard to Boost mailing lists and it appears that GMane is no longer picking up Boost mailing list changes or allowing users to respond to mailing list posts through the corresponding GMane ng. Does anyone know how to rectify this situation ? I recall that Boost might have changed who was hosting the mailing lists and I am wondering if this is the reason that GMane no longer works with Boost mailing lists. The GMane website appears to be in transition, and all links for contacting anyone at GMane have been removed. I did try to contact Lars Magne Ingebrigtsen, who has been running GMane, but I do not know if this will produce any results.

4 9

Fwd: [clang] clang-cl expansion of macros
by degski 01 May '17

01 May '17

On 16 April 2016 at 17:58, Edward Diener <eldiener(a)tropicsoft.com> wrote: > What I strongly suspect will finally happen is that clang will not fix > these emulation problems because they are too tricky and numerous to do. > Instead they will probably declare that their emulation is good enough for > the majority of preprocessor constructs and that Boost PP, which pushes the > preprocessor to its limits, is not meant to work with their flawed VC++ > emulation. I hope I am wrong about that supposition, but having spent much > time in Boost PP and Boost VMD trying to workaround VC++ non-standard > preprocessor behavior I can envision that having to code "down" to that > behavior in numerous complicated instances will be too much time consuming > work for the clang developers who have chosen to work with VC++ > preprocessor emulation. > I've successfully built boost-1.64 with VC1410 (from the developer command prompt). Trying to use boost with a project using Clang 4.0.0 (both the LLVM and C2 backends) gives me the following PP error messages: 1>------ Rebuild All started: Project: test, Configuration: Debug x64 ------ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(59,7): error : too many arguments provided to function-like macro invocation 1> 2 1> ^ 1> z:\vc\x64\include\boost/preprocessor/facilities/expand.hpp(26,10): note: macro 'BOOST_PP_EXPAND_I' defined here 1> # define BOOST_PP_EXPAND_I(x) x 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected a qualified name after 'typename' 1> BOOST_MPL_AUX_NA_SPEC2( 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(166,44): note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC2' 1> #define BOOST_MPL_AUX_NA_SPEC2(i, j, name) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(64,11): note: expanded from macro '\ 1> 1> BOOST_MPL_AUX_NA_SPEC_MAIN' 1> BOOST_MPL_PP_PARAMS(i, typename T) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/preprocessor/params.hpp(58,11): note: expanded from macro 'BOOST_MPL_PP_PARAMS' 1> , BOOST_MPL_PP_AUX_PARAM_FUNC \ 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected ',' or '>' in template-parameter-list Up till now I was using a hacked boost-1.62. So in order to see what would happen, I also built boost-1.63. Apart from a small change in type_with_alignment.hpp (adding a ckeck for _MSC_VER not to exist if __clang__ does exist in line 87), boost-1.63 compiles without a problem (no specific (relevant to the emulation) command line parameters). Is there a macro I should define or is there something else I should set/do in order to use boost-1.64 with Clang 4.0.0 on windows? Any other suggestions? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 13

[review] Review of PolyCollection will start in a few days
by Ion Gaztañaga 30 Apr '17

30 Apr '17

Dear Boost community, The formal review of Joaquín M López Muñoz's PolyCollection library will start on Wednesday, May 3rd and ends on May 12th. This library implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. If you are interested, you can start preparing your review with the following information: Repositories: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html See you on Wednesday! Ion

1 0

[integer][math]Heads up on revised gcd/lcm code
by John Maddock 30 Apr '17

30 Apr '17

First some history.... Some time ago, the old gcd/lcm code was moved from Boost.Math to Boost.Integer as a means of reducing inter-library dependencies. Unfortunately a number of tasks were never completed: the docs weren't added to Boost.Integer, and the Boost.Math code never got updated to redirect to the moved headers. Fast forward a couple of years and when Jeremy Murphy contributed a new version of the gcd/lcm code as part of supporting polynomial gcd, and since I'd completely forgotten about the move, this got integrated into Boost.Math leaving us with two divergent versions. As part of sorting this mess out, I've now pushed to Boost.Integer a "best of both" version of this code, so far as I can tell, all dependent libraries are unaffected by the change, though I do need to do some more work on supporting obsolete compilers I no longer have access to. The main enhancements are: * New mixed binary/Euclid algorithm added, this seems to be the best performing algorithm in most cases, and is now the default for most integer types (performance is deeply dependent on the input though, so your mileage may vary). * In addition to integer and rational support, polynomial gcd is now supported via boost::math::polynomial. * There are new range based gcd-lcm algorithms for calculating the gcd/lcm of all the values in an iterator range, this is primarily for polynomial gcd support. * There are new variadic overloads of gcd/lcm for calculating gcd/lcm over more than 2 values. * The gcd/lcm functions are now constexpr in C++14 land, this means that the old compile time calculation traits classes are rendered obsolete for current compilers. * The gcd/lcm functions are now noexcept where appropriate. * Compiler intrinsics are now used speed up binary-gcd steps where possible, sadly this is incompatible with constexpr support since the intrinsics aren't yet constexpr :( Please do let me know if you find any snags, best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 17

Boost MultiIndex slow mass insertion
by miticodonati＠libero.it 29 Apr '17

29 Apr '17

I have the following structure: typedef boost::multi_index_container< MyClass, boost::multi_index::indexed_by< boost::multi_index::hashed_unique<boost::multi_index::member<MyClass, int, &MyClass::label>>, boost::multi_index::ordered_non_unique<boost::multi_index::member<MyClass, double, &MyClass::dist>> > > MyClassSet; If i populate it in a loop: MyClassSet all: for (int y = 0; y < input.rows; ++y) { MyClass c; // .... all.insert(c); } the insertion time is quite slow. It probably need to continuously re-order the underlying implementation. Anyway i would expect that populating it with a single call it would be faster (e.g. sorting the whole set only at the end). Example: std::vector<MyClass> vec; // ... MyClassSet all(vec.begin(), vec.end()); BUT... the times are almost equal. My question is: is this intended behaviour? Is there a faster way to mass populate the container (e.g. not enforcing the invariants/orderings at each 'insert')?

3 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[quickbook] diagnosing a missing [endsect]?
by Peter Dimov 28 Apr '17

28 Apr '17

I just noticed a missing [endsect] in the middle of one of the .qbk files in the Core documentation. The main .qbk file contains [include addressof.qbk] [include checked_delete.qbk] [include demangle.qbk] [include enable_if.qbk] [include explicit_operator_bool.qbk] [include ignore_unused.qbk] [include is_same.qbk] [include lightweight_test.qbk] [include no_exceptions_support.qbk] [include noncopyable.qbk] [include null_deleter.qbk] [include ref.qbk] [include scoped_enum.qbk] [include swap.qbk] [include typeinfo.qbk] and in the middle of lightweight_test.qbk an [endsect] was missing. The end result of it was that the following includes went into the [section] opened in lightweight_test.qbk, as subsections. This wasn't noticeable from a cursory look so it went unnoticed for a while. Is it worth diagnosing this problem in some way? We probably can't disallow unbalanced sections in an [include], but this could be a warning? (If someone pays it any attention, of course.) Presumably, at the end of the file there'll be a [section] left open? This could be made an error so it'd be harder to miss.

4 23

[core] [noncopyable] Add nonmoveable?
by Viktor Sehr 27 Apr '17

27 Apr '17

In addition to noncopyable, I sometimes want to force classes to be nonmoveable as well (mainly node-type classes in tree structures which other classes point to). Therefore I'd suggest adding a cousin to noncopyable; boost::nonmoveable which simply prevents an instance to be nonmoveable (as well as noncopyable). Note; even due the delete modifier were added in C++11 I still think inheriting boost:noncopyable\nonmoveable syntactically nicer than manually marking the copy\move constructors\assignment operators delete. /Viktor Sehr

4 8

[1.64][python] not building for Visual x64
by Raffi Enficiaud 27 Apr '17

27 Apr '17

Hi, I have some trouble building boost.python for the freshly released boost 1.64: there is no boost.python binary generated, and "bin.v2/libs" does not contain any folder named "python". Maybe related: the machine has python2.7 and 3.4 installed. The command for building: b2 toolset=msvc-14.0 --layout=versioned --build-type=complete --without-log -j 4 address-model=64 threading=multi runtime-link=shared The same command was used for 1.63 with no issue. What am I missing? Let me know if this is a chair-to-keyboard problem. Best, Raffi PS: logs of the second run attached (the number of messages for the first run is flooding the console).

2 2

[stacktrace] Two days remaining before review ends
by Niall Douglas 27 Apr '17

27 Apr '17

Current summary of votes cast so far: * Peter Dimov: Unconditional acceptance * Vladimir Batov: Unconditional acceptance Am I missing any? If you are going to make a review and a recommendation, please do so soon. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 9

[release] Epic fail: Numeric cast in 1.64 does not match trunk
by Antony Polukhin 26 Apr '17

26 Apr '17

Hello, File https://github.com/boostorg/numeric_conversion/blob/master/include/boost/nu… does not match the one in release 1.64 That file was fixed and merged to master a long time ago, however boost_1_64_0.7z archive still has on outdated version (one with std::unary_function). This looks like an issue within some release scripts. Issue was noted here: https://svn.boost.org/trac/boost/ticket/12972 -- Best regards, Antony Polukhin

4 4

How to contribute??
by Saurabh Singh 25 Apr '17

25 Apr '17

Hey, This is Saurabh from New Delhi, India. I want to contribute to Boost and help you guys in fixing bugs. Can you please help me to get started in doing so. Thanks

3 2

[release] 1.65.0 open for merging
by Rene Rivera 24 Apr '17

24 Apr '17

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 3

[context] - Boost.Context fails to build -> Call of overloaded 'callcc(...) is ambiguous'
by Carlos Ferreira 24 Apr '17

24 Apr '17

I was trying to compile Boost 1.64.0 for OpenWRT when the build failed for Arm Cortex A7 (Raspberry Pi 2) using Gcc 5.2 with Musl 1.1.16. The build output with the error follows. Any ideas on what it could be ? gcc.compile.c++ bin.v2/libs/fiber/build/gcc-arm/release/abi-aapcs/boost.locale.iconv-on/boost.locale.posix-off/link-static/threading-multi/context.o libs/fiber/src/context.cpp: In constructor 'boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)': libs/fiber/src/context.cpp:236:14: error: call of overloaded 'callcc(const std::allocator_arg_t&, const boost::context::preallocated&, const default_stack&, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>)' is ambiguous }); ^ In file included from ./boost/fiber/context.hpp:28:0, from libs/fiber/src/context.cpp:7: ./boost/context/continuation.hpp:469:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::preallocated; Fn = const boost::context::basic_fixedsize_stack<boost::context::stack_traits>&; Arg = {boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}] callcc( std::allocator_arg_t, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:483:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>; Arg = {}] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:514:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn) { ^ ./boost/context/continuation.hpp:457:1: note: candidate: boost::context::continuation boost::context::callcc(Fn&&, Arg ...) [with Fn = const std::allocator_arg_t&; Arg = {boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}; <template-parameter-1-3> = void] callcc( Fn && fn, Arg ... arg) { ^ -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

2 2

Supporting boost 1.64 for Visual Studio 2017
by Evgen8 23 Apr '17

23 Apr '17

The "NuGet" system indicates that BC 2017 is supported. *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: Win32, x64.* But attempts to use this package end with nothing. Regardless of how I install the "boost_locale" - do I get the same result manually or using "NuGet"? Attempts to install it on another machine ran out the same. Is this a bug? /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>E:\Yandex.Disk\Projects\OS\Release\Devs.exe : fatal error LNK1120: 2 unresolved externals/ -- View this message in context: http://boost.2283326.n4.nabble.com/Supporting-boost-1-64-for-Visual-Studio-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Re: [boost] Supporting boost 1.64 for Visual Studio 2017
by Andrey Semashev 22 Apr '17

22 Apr '17

On 04/23/17 00:11, Nadtochiy Evgeniy wrote: > 22.04.2017, 21:07, "Andrey Semashev" <andrey.semashev(a)gmail.com>: >> >> On 04/22/17 20:29, Evgen8 via Boost wrote: >> >> The "NuGet" system indicates that BC 2017 is supported. >> *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: >> Win32, x64.* >> But attempts to use this package end with nothing. Regardless of >> how I >> install the "boost_locale" - do I get the same result manually or >> using >> "NuGet"? Attempts to install it on another machine ran out the >> same. Is this >> a bug? >> >> /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: >> unresolved external symbol "class boost::system::error_category >> const & >> __cdecl boost::system::system_category(void)" >> >> >> The missing symbols are from Boost.System. Since you're linking static >> libraries, you'll have to specify Boost.Locale dependencies manually to >> link with in your project. >> > How can i do this? There was always enough installation with NuGet... I don't know what NuGet is or how it works, but the libraries to link with are typically specified in VS project settings (look for the linker parameters tab). PS: Also, please, don't top post.

1 0

[1.64][process] Windows line endings in headers
by Andrey Semashev 22 Apr '17

22 Apr '17

Hi, I can see some of the headers in Boost.Process (for example, boost/process/cmd.hpp, boost/process/env.hpp) contain Windows line endings. Regarding 1.64, Windows line endings are also present in the .tar.bz2 package, which is supposed to be targeted for POSIX systems. 1. Could Windows line endings be removed in git? 2. Could the release procedures be updated to ensure that foreign line endings don't creep into the released packages? I understand that 1.64 has sailed, but I think at least a note (preferably, with a patch) would be appropriate in the release notes.

7 11

[Stacktrace] Second review begins today 17th Mar ends 26th Mar
by Niall Douglas 22 Apr '17

22 Apr '17

I am pleased to announce the second review of the proposed Boost.Stacktrace library running from today until Sunday 26th. Stacktrace is an optionally header-only library providing multiple implementation backends. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= This is a second review of this library with many changes implemented in response to feedback from the previous review. My previous review report can be found at http://lists.boost.org/boost-announce/2017/01/0486.php where I made the following conditions for acceptance: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. Antony hasn't entirely met my conditions, hence this second review. He has instead implemented this changelog: * Reimplemented boost::stacktrace::basic_stacktrace class to accept allocators and to have a small size * Added outputting of the path to the binary object into the stacktrace, when source location is not available * Allowed to use `libbacktrace` - a defacto standard for GCC/CLANG backtracing that does not fork and has a permissive license * Optimized stacktrace and frames ostreaming * Removed backends and made the default tracing to have only platform basic functionality. Added macros to enable additional functionality. * Fixed (theoretically) MinGW compilation * Added functions for async-safe dumping into memory or descriptor * Changed signal handling example to be async-signal-safe * Allowed users to choose how many frames to skip during stack capture * Removed `boost::stacktrace::stacktrace` functions and other internals from printed stack traces * Updated docs: * examples now use Boost.Exception * removed all the references to "backend" * reduced macro count * "Build, Macros and Backends" section was rewritten and became "Configuration and Build" * added note that library is C++03 * added examples on storing traces into shared memory * updated all the human readable dumps It is up to the Boost community as to whether this revised library is now acceptable without any conditions, or with conditions. Reviews should be submitted to the developer list (boost_at_[hidden]), preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

9 44

Locating Visual Studio 2017 on disk
by Andrew Pardoe 20 Apr '17

20 Apr '17

Folks, We had a number of conversations about the fact that VS 2017 could be installed in any location, or multiple locations, and no longer created a registry key pointing to an install location. There's also the problem that an installation of VS 2017 may or may not contain C++ tools (as was the case with VS 2015.) The solution proposed by the VS team-creating a tool called VSWhere-was inadequate for some scenarios such as Boost's because it would have required either caching a binary in your source enlistment or compiling code to locate the compiler. A number of people on this list asked for a more straightforward solution. I'm happy to tell you that your feedback was heard. We're going to start shipping the VSWhere tool in a known location on any machine that has VS 2017. More details can be found in this blog post: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed… This doesn't fix the problem for all the versions of VS 2017 that are installed already. And this doesn't help our version numbers to make any more sense (although I'm pushing to fix that as well.) But at least in the future you'll be able to locate VS installs from a scripted environment. Thanks for being loud and reaching out to us. As always, I'm happy to help you with any issues you might have with MSVC-just ask. Andrew Pardoe MSVC compiler & tools

1 0

[stacktrace] Please for into boostorg repo
by Antony Polukhin 20 Apr '17

20 Apr '17

Hi, Stacktrace library was accepted into the Boost http://www.boost.org/community/review_schedule.html Please fork the repo https://github.com/apolukhin/stacktrace into boostorg and give me admin rights to that repo. -- Best regards, Antony Polukhin

2 4

Boost Library Incubator Statistics
by Robert Ramey 20 Apr '17

20 Apr '17

In the course of updating the Boost Library Incubator website, I gathered some summary statistics which some might find interesting. 40 Number of libraries submitted 2 libraries not accepted into the incubator of lack docs, test, etc. 11 libraries reviews by boost 9 accepted 2 rejected All in all, I'm thinking these numbers aren't too bad for boost and the incubator. I would like to see more submissions - but the submissions we've received seem to be better than average quality and worthy of consideration. Hopefully this has made the review process more efficient. A couple of libraries have also been accepted (and rejected) without having been placed in the incubator. The number is small. I think this validates the incubator as useful, but not necessary and libraries authors should continue to be encouraged, but not required, to submit library candidates to the incubator. Other than the above, I'm not going to try to draw any conclusions from the above admittedly anecdotal data. I would also remind boosters that if you're logged into the incubator, you can display statistics on viewership for a particular library by using the "Display Statistics" button on the library page. This is a crude but someone engaging way to get an idea of how many people have looked at the library page. The attached shows visits to the safe numerics library page in the last 90 days. Robert Ramey

3 5

List-Id mail header
by Christoph Ludwig 20 Apr '17

20 Apr '17

Hi, starting yesterday, the List-Id header in the mails I get from the Boost mailing list changed. It used to be: List-Id: Boost developers' mailing list <boost.lists.boost.org> Now it is: List-Id: Boost developers' mailing list <boost.wowbagger.crest.iu.edu> Due to this change, the mail filter I have used for years fails to identify the messages as boost mailing list traffic. Therefore, the messages end up in my regular inbox instead of the dedicated folder I have for the mailing list. Of course, I can easily update my mail filter, that's no big deal. I just want to know: Did I miss an announcement, was this change intended? Will the List-Id use the wowbagger identifier from now on? Cheers, Christoph

2 1

[release] Boost 1.64.0
by Rene Rivera 20 Apr '17

20 Apr '17

Release 1.64.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/history/version_1_64_0.html> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.64.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[release] Boost 1.64.0 Release Candidate 1
by Rene Rivera 19 Apr '17

19 Apr '17

The release candidates for the 1.64.0 release are now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.rc.1/> The SHA256 checksums are as follows: 49c6abfeb5b480f6a86119c0d57235966b4690ee6ff9e6401ee868244808d155 boost_1_64_0_rc1.7z 7bcc5caace97baa948931d712ea5f37038dbb1c5d89b43ad4def4ed7cb683332 boost_1_64_0_rc1.tar.bz2 0445c22a5ef3bd69f5dfb48354978421a85ab395254a26b1ffb0aa1bfd63a108 boost_1_64_0_rc1.tar.gz b99973c805f38b549dbeaf88701c0abeff8b0e8eaa4066df47cac10a32097523 boost_1_64_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

9 8

[Trac] Spam and suspicious attachments
by Mateusz Loskot 19 Apr '17

19 Apr '17

Hi, I'm not sure what is the correct admin contact to report spam on Trac, so posting here. Number of suspicious attachments (.exe, .jpg) have been submitted to this ticket during recent period of 3 years https://svn.boost.org/trac/boost/ticket/8070 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[ranges] Please merge the long standing pull request
by Antony Polukhin 18 Apr '17

18 Apr '17

Hello, There's a year old pull request https://github.com/boostorg/range/pull/44 Please merge it to the develop branch. The pull request is a blocker for improving Boost.Algorithm (https://github.com/boostorg/algorithm/pull/35) https://github.com/boostorg/range/pull/44 changes were adopted into C++17 standard library.So the change is not innovative. -- Best regards, Antony Polukhin

2 2

Serialization support for colony container
by Brian Wood 17 Apr '17

17 Apr '17

Shalom It's looking like Matthew Bentley's colony container -- http://plflib.org -- is going to pass over Boost on it's way to the standard. I've added serialization support for this container to the C++ Middleware Writer and added some code that tests that support to my repo -- https://bitbucket.org/webenezer/onwards . I enjoyed Jon Kalb's CppChat show where he talked to Matthew about this container -- http://www.slashslash.info/cppchat/ https://www.youtube.com/watch?v=SFAJ238rBNw -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Guinea pigs for testing GSoC submission ranking
by Niall Douglas 16 Apr '17

16 Apr '17

Google have removed the ability for the community to rank proposals plus they force proposals to be sent to us in the highly unuseful PDF format. I've come up with a stopgap solution, and need guinea pigs for testing it. If you're game, please send me your google login name and I'll send you instructions. My thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

[metal] Formal Review - Request for Endorsement
by Bruno Dutra 16 Apr '17

16 Apr '17

Dear Community, I'd like to formalize what has been known to many for some time now and request the formal review of Metal, a modern C++14 library designed to make template metaprogramming intuitive and effectively replace Boost.MPL. Klemens Morgenstern has kindly offered to manage the review process. The library is available on github at https://github.com/brunocodutra/metal The full documentation is available online at http://brunocodutra.github.io/metal/ Up to date benchmarks are uploaded daily to metaben.ch Great effort has been put into making Metal as portable to different compilers as possible. Currently, the following compilers are tested in continuous integration using Travis and Appveyor: * GCC 4.7 and above * Clang 3.4 and above * Xcode 6.4 and above * Visual Studio 14 (2015) and above * MinGW 5 and above Complying with the new Boost policy, I'd like to kindly request those interested in seeing Metal in boost to take a look at it and endorse this request for formal review. Regards, Bruno

5 6

[config] What to call macros to indicate deprecated/removed components
by John Maddock 16 Apr '17

16 Apr '17

We now have several former C++ features which are removed in C++17: auto_ptr random_shuffle binders unary/binary_function And we're getting requests for configuration macros for these, the question is what to call them? We could stick with the (easy to implement) existing naming and just use: BOOST_NO_<FEATURE> or we could use: BOOST_<STD>_REMOVED_<FEATURE> which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating. Any other suggestions/preferences? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 6

[typeof][scope_exit] VS2017 and option /permissive-
by Daniela Engert 16 Apr '17

16 Apr '17

Hello, late last year, VS2017RC gained a compiler option /permissive- which disables some non-conforming behaviour. Source code that was accepted by previous versions of msvc, and still is accepted by msvc 14.1 without this compiler option, is rejected and flagged as an error if /permissive- is engaged. For more on this see https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/. While checking our company's codebase for possible problems related to that I noticed compile errors in Boost.Log and traced the problem back to Boost.Typeof and in particular "libs\typeof\include\boost\typeof\msvc\typeof_impl.hpp". Therein is code emulating the missing __typeof__ keyword by taking advantage of a silent msvc compiler 'bug' as a 'feature'. Parts of this code are duplicated in a msvc-specific workaround in Boost.Scope_Exit. This compiler bug is no longer silent with /permissive- in place but rather a hard error. As it turns out, I'm not the first to be bitten by this: ticket #12900 tells the same story. Many other Boost libraries use Boost.Typeof directly or indirectly and therefore suffer from the same problem (like Boost.Log in my particular case). I've implemented a possible solution and created two pull-requests: - https://github.com/boostorg/typeof/pull/7 - https://github.com/boostorg/scope_exit/pull/3 The patches only affect msvc 14.1. With these patches applied, the test results of the full Boost testsuite are the same as without these patches. I don't know enough about __typeof__ to decide if my emulation is compatible in every aspect, but at least it's good enough to pass the testsuite. There are two other compile failures introduced with /permissive- in place which are compiler bugs which need to be addressed by Microsoft's compiler team. Fortunately these are very specific to just two libraries, Boost.Spirit.Repository (one test case) and Boost.Geometry (two test cases caused by one single function). -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

2 8

Boost licensing information
by Fabrizio Riente 15 Apr '17

15 Apr '17

Dear Boost Members, I'm Fabrizio Riente and I'm a researcher from the Politecnico di Torino in Italy. I'm using some part of boost libraries in our application. In particular we are using boost spirit, odeint and serialization. In the next future, we would like to release this tool for free for research purposes. I read that at the moment boost is released under Boost license. I was wandering if under this license it is possible to distribute the application for free to other universities and interested people without sharing the source code. Thanks in advance for your time. Best regards. Fabrizio Riente -- Fabrizio Riente, Postdoctoral Research Associate Politecnico di Torino, Dept. of Electronics and Telecommunications C.so Duca degli Abruzzi 24, I-10129, Torino, Italy Phone: +39 011 090 4241, Email: fabrizio.riente(a)polito.it

15 43

Header Inclusion practices
by Robert Ramey 15 Apr '17

15 Apr '17

As long as I can remember, it's been my practice to write program code to minimize dependencies on the environment in which it is built. By environment I mean things external to the code itself like environmental and command line variables, directory context etc. As part of this I use rules for header file inclusion: a) use #include "header.hpp" for files in the same directory as the current source file. b) use #include "other directory/header.hpp" for files which are known to be in a specific place relative to the current file. This shows up in things like: #include "../include/header.hpp" for tests and examples. c) use #include <boost/serialization/xml_archive.hpp> for files which are found by looking in directories listed in "-I" switches and environmental variables (INCLUDE). I generally try not to depend upon any environmental variables as I always forget to set them or even how to set them. Come to think about it. I don't know how my build system finds the boost libraries. I presume it's through some IDE/Bjam/CMake setting which I can never remember. d) use #include <iostream> for standard library components. Presumably these are routed to some directory relative to the compiler. So some of my source files look like: // interval.hpp header for safe numerics library #include <limits> #include <cassert> #include <type_traits> #include <array> #include <initializer_list> #include <boost/logic/tribool.hpp> #include <boost/core/demangle.hpp> #include "utility.hpp" // log #include "checked_result.hpp" #include "checked.hpp" and // example using he safe numerics library #include <iostream> #include <limits> #include <boost/integer.hpp> #include "../include/cpp.hpp" #include "../include/exception.hpp" #include "../include/safe_integer.hpp" #include "../include/safe_range.hpp" This has raised consternation in some quarters - but I don't see anything wrong with it. It basically means that only the <boost libraries are depended on the whole b2 business. I didn't want the incubator version of the the safe numeric library to depend on the library having been accepted into boost have have b2 run. Also I don't like adding the library to boost - and having to change all the headers. What if someone want's to run the tests/examples outside of the boost tree. As far as I know this question has never been asked before and I'm curious to know what others might have to say about this. Robert Ramey

10 21

gil: extension/numeric missing in tarball(s)
by Tim Blechmann 14 Apr '17

14 Apr '17

hi all, the complete folder with the gil numeric extensions is not included in the tarball ... is this a bug or a feature? https://github.com/boostorg/gil/tree/develop/include/boost/gil/extension/nu… thnx, tim

4 6

[release 1.64] - BOOST_NO_CXX17_STD_APPLY missing in documentation
by Oliver Kowalke 14 Apr '17

14 Apr '17

I checkted the documentation of boost-1.64 beta2 and it seams that the documentation lost the description of BOOST_NO_CXX17_STD_APPLY. May I provide a patch that gets merged into the 1.64 release? Oliver

3 3

[config] defect macro for chrono literals
by Oliver Kowalke 14 Apr '17

14 Apr '17

boost.config defines BOOST_NO_CXX11_USER_DEFINED_LITERALS but I believe this defect macro could not be used for detecting chrono literals support. Should the new BOOST_NO_CXX14_CHRONO_LITERALS depend on the compiler or stdlib version? AFAIK chrono literals are available since gcc-4.9.3 (clang?, intel?, msvc?). Oliver

2 2

[CallableTraits] Closing the review period
by Louis Dionne 13 Apr '17

13 Apr '17

Dear Boost, The review period for CallableTraits is about to conclude (in about one hour, PST). So far, I have counted 5 formal reviews, alongside with other valuable feedback. All 5 formal reviews recommend acceptance (along with improvement suggestions, but I read none of them as being conditional). I will weight the different comments received through formal and informal reviews and come back with a decision regarding CallableTrait's inclusion in Boost by the end of next week. Thanks for everyone's involvement in the review. Louis P.S.: If you have a late review, submit it ASAP and I will consider it!

1 0

[release] 1.64.0 closed for all changes.
by Rene Rivera 13 Apr '17

13 Apr '17

The Boost 1.64.0 master branch is now closed for all changes. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[CallableTraits] The formal review begins today
by Louis Dionne 13 Apr '17

13 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library begins today, April 3rd, and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost, and conditions for acceptance if any - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! Regards, Louis

12 28

Formale Review: Callable Traits
by Peter Dimov 13 Apr '17

13 Apr '17

I think that the Callable Traits library should be ACCEPTED. The design of the library is sound, although I'm not fond of the ad-hoc metaprogramming part in "parameter list features". This is no fault of the author though, as without a modern type-metaprogramming library in Boost, everyone has to solve this problem in some way. Still, I think that most of these should be removed. Getting the arguments as a tuple that includes the class type as a first parameter raises the obvious question of void(foo::*)(float, char, int) -> tuple<foo&, float, char, int> void(foo::*)(float, char, int) & -> tuple<foo&, float, char, int> I understand why that is, but it still makes args lossy and the original can't be recreated from the tuple. Trailing varargs also have the same problem, as (float) and (float, ...) map to the same tuple. The obvious theoretically consistent approach here is void(foo::*)(float, char, int) -> tuple<foo, float, char, int> and void(float, ...) -> tuple<float, ct::varargs_t> which would be fully reversible but could possibly be less convenient in practice. I've a feeling that it might also be useful to provide an extractor that, for member pointers, returns just the arguments without the class. In "member qualifier features", I'm missing remove_member_cv_ref (obvious semantics) and copy_member_cv_ref (copies cv+ref from one member pointer to another.) In "member pointer features" we have the same problem in qualified_parent_class_of as in args, void(foo::*)() -> foo& void(foo::*)() & -> foo& It makes more sense for the first to yield 'foo', although this again may make the trait less convenient in practice. It would also _probably_ make sense to provide apply_qualified_member_pointer, which, given void(float) and foo const&, would yield void (foo::*)(float) const&. I did not look at the implementation. I ran the test suite on Windows under Cygwin g++ 5 in 11/14/1z, Cygwin clang 3.9 11/14/1z, msvc-14.0, msvc-14.1. The tests passed. Took a look at the tests themselves, the coverage looks excellent. The reference documentation is very good, although as already noted, it uses the terms of art "implementation defined" and "undefined behavior" incorrectly, this must be fixed. The non-reference portion is a bit thin. It would be improved considerably by presenting a few real-world use cases. All in all, a solid library that solves a real problem, even though the problem remains somewhat of a mystery for the uninitiated. :-)

4 4

Libraries and C++ compliance
by Edward Diener 12 Apr '17

12 Apr '17

I would like to ask people who present new libraries to Boost, in whatever stages they are, to please specify in the documentation to the library and/or in messages regarding the library, what level of C++ compliance is needed to use the functionality of that library. This plea is not being directed at any particular current library being mentioned by anyone on the mailing list, but is a general plea regarding developers and their efforts. I realize it is a real pain that C++ as a language, and as it continues to evolve, has a number of popular levels of C++ compliance. This is largely because C++ is offered by a number of different vendors in a number of different supported releases, each particular implementation supporting a number of levels of C++ compliance and sometimes only partially supporting a particular level of C++ compliance. But given this sometimes difficult situation I do not see it as enough for library docs/information to simply say "this library supports some-vendor/some-release" because this is actually fairly meaningless to me when I know that "some-vendor/some-release" supports a number of levels of C++ compliance through some compiler parameter ( often -std=something ). Therefore docs/information of "the library supports "some-implementation" or "the library is compliant with "more than one level of C++ compliance" tells me as much as if some one told me that the moon is yellow. So I am begging, pleading, entreating library authors to be specific about the C++ features or the C++ level of compliance needed to use their library, even if it is just a one-liner that succinctly explains what the end-user needs to know. Furthermore, for any given library could we please have specific information about what will happen if I use the library, or some feature of the library, without the desired minimum level of C++ compliance. While I would assume compile-time compiler errors as the norm another possibility, especially given the excellent support in Boost Config to compiler conformance, are more readable preprocessor errors. Finally a library might offer some level of advanced C++ compliance but fall back to a lower level if possible. Please, please library authors this is important. No end-user or tester of your library wants to spend extended time trying to figure out why some compile fails when the answer turns out simply to be one of inadequate C++ conformance level for a particular compiler implementation being used with a particular level of conformance.

13 29

Re: [boost] [proposed][histogram]
by Bjorn Reese 12 Apr '17

12 Apr '17

On 04/12/2017 11:37 AM, Hans Dembinski via Boost wrote: > The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. Given that the compression is lossy, I am wondering how it compares with a distribution estimator like: https://arxiv.org/abs/1507.05073v2 A common use-case when collecting numerical data is to determine the quantiles. Boost.Accumulators contains an estimator (extended_p_square) for that. The advantage of such estimators are that they execute in constant time and with constant memory usage, where the constant depends only on the required precision. PS: I am aware that this is a non-trivial question, so I do not expect an answer.

3 4

[proposed][histogram]
by Hans Dembinski 12 Apr '17

12 Apr '17

Dear Boost community, after another year of work, I hope to raise your interest once again in a much improved version of "histogram", a library proposed for inclusion in Boost. https://github.com/HDembinski/histogram http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582 The library can be build either with b2 or cmake. It compiles successfully with several versions of clang and gcc and has 99 % test coverage (the remaining 1 % are basically un-hittable branches). Boost-style documentation is available. The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. A histogram implements a quantisation of a space of input values. The space is divided into non-overlapping cells. Instead of remembering the exact values of a tuple in that space, one just increases a counter in the corresponding cell. This is the lossy compression, you only remember the count in the cell and not the original values. There are subtleties related to the counting if you want it to be safe and efficient. The library handles this for you. The standard policy implements intelligent counters which are fast, conserve memory, and are guaranteed to not overflow or get capped (capping happens when you use floating point numbers to count, like some implementations do). This is one of the two main feature of the library. The other main feature is that the library allows you to seamlessly create one or multi-dimensional histograms using various schemes to divide the input space. A so-called axis class handles the division into cells along each dimension. There are several ways how you might want to define the cells that divide the input space, and library offers you interesting options. For example, if one of your inputs is an angle, the library provides a special axis class for periodic input values. What's new: - Static polymorphism: The original version of the library solely used dynamic polymorphism to support different axis classes. This variant still exists, but the current version also allows you to use static polymorphism, implemented internally with boost::mpl and boost::fusion. This provides a speed-boost, which makes this library faster than the open-source competitors I tested (CERN's ROOT framework, the GSL, and numpy.histogram), in addition to the enhanced flexibility. - Arbitrary-precision counters: Counter overflow is now completely avoided by switching automatically to boost::multiprecision::cpp_int when the capacity of standard integer types is exhausted. - Extensibility: The library is now much more extensible and configurable. All relevant behaviour can be exchanged by using another (possibly user-defined) policy. The library provides default trade-offs that should work for almost everybody, but you can chose your own trade-offs. The new features were inspired by comments I got from the community. Now I am again at a point where I see the library in a very solid state. Best regards, Hans

1 0

[gsoc17] Help review Google Summer of Code proposals
by Niall Douglas 11 Apr '17

11 Apr '17

Dear Boost, Student proposals for Google Summer of Code are submitted, please help us decide which have the most merit. I have reduced the fifty something proposals submitted down to twenty seven which have some chance. To be able to view and rank the student proposals, please do the following: 1. Send to gsoc-admin(a)boost.org your Google login. We will invite you to view the student proposals on the Boost Google Drive. Until you receive the invitation email, you won't be able to view the proposals. 2. Go to https://goo.gl/forms/EVppdHsHMnjkcUoD3 which is a Google form where you can score the proposals. We have linked each proposal there to the Google Drive item and there you can rank a proposal between 1 and 5. Make sure you use the same email as your Google login in the form, otherwise we will ignore any forms submitted to prevent gaming the results. 3. Even if you can't rank all twenty seven proposals, try to do as many as you can and then PRESS SUBMIT at the end of the form (forgetting to press SUBMIT means we never get your rankings). The proposals are presented in random order per person so any work you do will be useful. 4. Please try to have your rankings done by Monday 10th. You may find reviewing the page at https://svn.boost.org/trac/boost/wiki/SoC2017 useful. 5. Finally, if you'd like to mentor any of the proposals, send to gsoc-admin(a)boost.org your Google login so we may invite you onto the Google website as a mentor. Many thanks in advance. Niall & Bryce

4 5

[Review Queue] SIMD Review on Hold -- Attn: wizards
by Michael Caisse 11 Apr '17

11 Apr '17

Hello Wizards - We need to postpone the review for Boost.SIMD while I compile answers to questions raised about the IP. I will report on my findings as soon as possible and either reschedule the review date or ask for the library to be removed from the queue. I apologize for the inconvenience and disruption of the queue. Take care - michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[release] 1.64.0 post-beta merges
by Rene Rivera 11 Apr '17

11 Apr '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> -- The Boost Release Team

13 56

[simd] Hardware support
by Bjorn Reese 10 Apr '17

10 Apr '17

Boost.SIMD only supports x86. Are there plans for ARM NEON and/or MIPS SIMD? What does Boost.SIMD currently do on unsupported platforms? Revert back to SISD?

13 41

[flat_set] When to sort?
by Vladimir Batov 10 Apr '17

10 Apr '17

I've been using boost::container::flat_set with quite a success until recently when I profiled my app to see that 30-50% of the run-time was spent in insert() for a container of around 50,000 in size. So, I had to replace boost::container::flat_set with a vector variation which inserts as a vector (no sorting). However, when it is the time to call begin(), end(), find(), it sorts once. That shaved the mentioned overhead off. Say, one run is down from 17s to 10s and the likes. I wonder if that should be the boost::container::flat_set default behavior rather than sorting the underlying container with every insert(). After all, as a user I do not care if the underlying container is sorted... until I start using/traversing it, right? Or maybe I am missing something in boost::container::flat_set which already allows me to do something of that sort?

11 37

Announcing CallableTraits' formal review next week (April 3rd)
by Louis Dionne 09 Apr '17

09 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library starts Monday, April 3rd and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Regards, Louis

4 4

Mathias Gaunard / NumScale relationship
by Joel FALCOU 08 Apr '17

08 Apr '17

Hi Niall, hi Andrey, I'm taking on to send you an email in private w/r to your questions on the list regarding Boost.SIMD, Mathias Gaunard and its relationship with NumScale. I'm adding Michael in CC: as he knows about the whole ordeal already and will corroborate my claims. Mathias has been one of the engineer I hired and then associate with to fund MetaScale, the company that will later become NumScale. He let the company after being ousted by one of our early investor for basically running the company into the wall and generally not knowing how to do business. He left for Bloomberg and started actually speaking about Boost.SIMD *as if* the internal information he gathered from within NumScale could be released to the public without our consent inclding internal benchmark report and road-map information. I imagine you understand why the cease&desist letter was then send. We have a bunch of other people using Boost.SIMD and they're doing fine (including other company and a bunch of OS project). I dont see why we'll be suing people using our open source software, which is different from using piece of the software he should not have. Since being laid off, Mathias kept trying to make our company and effort within open source fails by playing the victim and basically retelling history as he see fit. Also note that Mathias verbally threaten me that he will make this review a failure for us. This is the factual story of the whole thing: - 2003-2006 I worked in my PhD on something called E.V.E which was a EDSL in C++ able to supp0rot SIMD operations on PPC Altivec. - 2008 I'm now an assistant professor and work on a project called NT2 (that has been spoken about on the list a bunch of time) in collaboration with Jean-Thierry Lapresté which works on a huge amount of libm vectorisation code. Inside NT2, a remnant of E.V.E lingers and get worked on to support x86. - 2010 or some such, We start isolating the SIMD layer from NT2. At the same time, the university authorizes the release and open exploitation of NT2 as a whole in open source. NT2 and its internal soon-to-be Boost.SIMD is released under a Boost Licence. - around 2011, *I hire* Mathias to work on some part of NT2 and related project that culminates in 2012 at the creation of MetaScale. - We start speaking of NT2 and Boost.SIMD separately and it's probably around this time I raise the idea to make an actual submission to Boost. - 2014 for reasons that has no value being exposed here, Mathias leaves MetaScale and NumScale is funded to replace it. - 2015 The amount of people actively working on NT2 plummets and NumScale's team decide to reuse parts of Boost.SIMD into what bSIMD will become. - 2016 the rewrite is complete and the lack of support on NT2 make me pull the plug on the project. NumScale decide to open source back some parts of bSIMD, leaving this new Boost.SIMD made out of bSIMD be the sole remnant of this. And as your concerns goes Andrey about NumScale blocking PR or w/e coming into Boost.SIMD, The key point here is that Mathias is no longer affiliated with NumScale and has no information nor actual reason to speak on our behalf. NumScale has no plan to at short term release ITS OWN support for some architectures. This does not preclude anybody trying to undertake the effort to support an other architecture as long as yes, it is not Mathias pulling up the files we own he scavenged before leaving. We had had someone from ETH Zurich starting a port on QPX, something we also started but never finished due to other constraints. If this ever completes then, yeah it'll probably go inside the Open Source version if it's of enough good quality. We have various plan and discussion going on with different vendor and open sourcing more is planned at later date and depending on things I can not legally speak of because NDA. I'm planning to write or have Michael answer those issues publicly in a way I don't spread too much information that has nothing to do in public. I would appreciate if this line of discussion stay private for now until we address this properly in public. Meanwhile, I'm open to answer your other question. Best regards Joel

3 3

Re: [boost] [release] 1.64.0 post-beta merges
by Oliver Kowalke 08 Apr '17

08 Apr '17

Am 08.04.2017 1:44 nachm. schrieb "Daniel James via Boost" < boost(a)lists.boost.org>: On 8 April 2017 at 10:47, Oliver Kowalke via Boost <boost(a)lists.boost.org> wrote: > > I'd like to update > > - boost.context: updating documentation regarding to property > context-switch, apply property context-switch to Jamfiles in sub-directory > example I don't know enough about boost build for this one, but the change to 'include/boost/context/execution_context.hpp' seems unnecessary. It doesn't look like it will fix anything. The patch applies property 'context-switch' to the example code Jamfiles - no need to specify it at the cmd line. The definition of property context-switch was adapted to the public APIs of boost.context.

1 1

[gsoc17] GSoC next steps (was: Re: [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing)
by Niall Douglas 07 Apr '17

07 Apr '17

> Sorry for disturbing you at this time, I experienced a very bad thing > that Satyam Pandey, a student who sent proposal yesterday copied too > many sections of my proposal. I marked the sections red in the given > PDF.*I think the same pattern of GSoC proposal is common, and it does > not matter, but his proposal has too many same description as me. * Thank you for reporting this issue. It is unavoidable in Google Summer of Code that students copy one another and indeed sometimes pay another to write their competency test for them. We actually encourage students to study one another's applications and submit an even better application, this happened several times this year with the static map proposal. But we frown on failure to attribute sources, including failure to mention when the community or stackoverflow gave them help. And students who are later prove to be incapable of programming code at the level they advertised in their proposal are lifetime banned not just by us, but by Google. Last night I read every application and pre-eliminated half of them as I do every year so the Boost community doesn't waste their time with them. The calibre at the top this year is even higher than in past years, we have at least three truly superb candidates per project. It will be very hard to choose between them, and we will have to reject two superb candidates for no good reason other than only one student can do one project. You should see an announcement regarding community ranking soon. Watch this space. Niall

2 3

[gsoc2017] Please review my code for Proficiency test.
by Satyam.Pandey 06 Apr '17

06 Apr '17

I have completed my Proficiency Test. Please review the code and suggest anything that you think should be improved. Here is the link to my git repository : https://github.com/sa91/ProficiencyTest I will be really glad to have your suggestions. It would be great help, if someone can suggest me some good testdata for testing my code. Thanks Satyam Pandey -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc2017-Please-review-my-code-for-Profi… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[VS2017][release] vswhere.exe
by Mateusz Loskot 06 Apr '17

06 Apr '17

Hi, This is regarding issues with locating VS 2017 toolset(s). >From CMake ml, I learned about vswhere utility being developed by Microsoft https://github.com/Microsoft/vswhere vswhere.exe (390 KB) is downloadable from https://github.com/Microsoft/vswhere/releases I'm not sure how exactly, but perhaps it would solve some of the Boost.Build's headache (eg. particular PowerShell version required). For example, it can find all VS versions I've got installed (10.0, 11.0, 12.0, 14.0, 15.0): vswhere.exe -legacy find a particular version: vswhere -legacy -version [11.0,12.0) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

15 38

program options - adding new functionality
by Sutera Systems 06 Apr '17

06 Apr '17

Hi all, I have just started using boost.program_options for my windows apps. I have a need to add a new functionality. I would appreciate some guidance as to how to do so. Cheers, Larry

2 1

[mailing list] No Reply-To in messages?
by Andrey Semashev 05 Apr '17

05 Apr '17

Hi, Sometimes I can see messages from the mailing list that have no Reply-To header. For example, this is the headers from a recent email from the ML: Delivered-To: andrey.semashev(a)gmail.com Received: by 10.223.171.174 with SMTP id s43csp1184445wrc; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) X-Received: by 10.233.239.75 with SMTP id d72mr28079608qkg.313.1490097251746; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Return-Path: <andrey.a.davydov(a)gmail.com> Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com. [2607:f8b0:400d:c09::233]) by mx.google.com with ESMTPS id 5si5329794qty.259.2017.03.21.04.54.11 for <andrey.semashev(a)gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) client-ip=2607:f8b0:400d:c09::233; Authentication-Results: mx.google.com; dkim=pass header.i=(a)gmail.com; spf=pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) smtp.mailfrom=andrey.a.davydov(a)gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: by mail-qk0-x233.google.com with SMTP id y76so54702989qkb.0 for <andrey.semashev(a)gmail.com>; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=oPSYU2baFZEWMUKF/s2hay278FTdFBfitQp4TNz5piq0zMWNqePuZaXbUD5SPP0Cnp He9gQzhynjuN/Lf4fpUtqjOWyntF2BSSrdpYbCSmaWnnSQjTz5s53EkOSVgojqHCfmVr A3CSJNK5QdAwkNAm+JQRIShSRO/YpWtK90Lhoa9lKlWF+JtIMwCgFG3h5vN1vw+W1xAB pNoHymY5rZ7Uh0WUHMlpEF/tmkD/tZzDss++3j/lKZNgX66VefCpi510BjKKkFfU2xdy zBba1I5hOOohBUzhlkYf5fSxZ1BkC6FSOizONZr1Mlx8AXLhl2MvmfW6KtR9nt9rjmSa Sfhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=OAFamTGJr76H6gmaG7LGcCRyHIp+Kj1SEs188yLqxEQGCvhYYdB8wMs6GsOYL0wYSY 9M1gYeXwexivqs+WF5Reg9CCh2mnkCUWTM6nSu9/B05sXFBUL/sVyEr7OuSXJpzVqOxl cZorectxLhbWqIqClTxYjSDNDKPJB9n+3OntHKp5l2gJY3mMPaILXbXRh6XXCMHxpYIy w1um18ndeJ0Ed7/nkhGKlzD2HvyPpkVPhjM+hhWmb+lxnVNhbpBFsoor28Yx5arAnVWb 0JndOFeqB3tfjv9DA5x/kuSStkSuG2Q439Fvd/2UuWKsqaR4JhaBejrE7jEnJgrN69on 8wfQ== X-Gm-Message-State: AFeK/H24Tvn8HI3rOm/9DXmcPc8Hok/lT3XOC2lfnuuWDiN5TsbtV56nLqNTPypggKQsasFDZvOER50I+HaBMH84 X-Received: by 10.55.15.195 with SMTP id 64mr28730703qkp.131.1490097251370; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.157.129 with HTTP; Tue, 21 Mar 2017 04:54:10 -0700 (PDT) In-Reply-To: <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> References: <CAN1iZb7pGGaFe9OKyDKxMB0Nryiqa3pxk5hLQY+1ybUCMNrZBQ(a)mail.gmail.com> <D5F339D7-3F03-4363-A2A5-F611FE8C76F0(a)gmail.com> <CAN1iZb54emhE_G9McfCmO2nN6D-qWqQSgSC-w1HdRqCAh08c8Q(a)mail.gmail.com> <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> From: Andrey Davydov <andrey.a.davydov(a)gmail.com> Date: Tue, 21 Mar 2017 14:54:10 +0300 Message-ID: <CAN1iZb6VHEUJvt9h8JN_1EubOcYponiEjdXWQGcGZ+VjU_hKJA(a)mail.gmail.com> Subject: Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter? To: boost(a)lists.boost.org Cc: Andrey Semashev <andrey.semashev(a)gmail.com> Content-Type: multipart/alternative; boundary=001a1146f4805976ff054b3c4d27 As a result, when I press Reply, the reply is addressed to the original email sender instead of the mailing list, which is really easy to miss before sending the message. Is it possible to ensure that every email from the ML contains boost(a)lists.boost.org in its Reply-To header? PS: I'm not a guru in email protocols, so if there is another more appropriate way of doing this then that would be fine with me.

13 35

Re: [boost] Official boost macro to determine endianess?
by Frédéric Bron 05 Apr '17

05 Apr '17

> You should check the macro values instead of testing if they are defined > (i.e. use #if instead of #ifdef). Oh thanks, I have to check if it is positive. Now I get the right BOOST_ENDIAN_LITTLE_BYTE (the only one positive). Frédéric

1 0

Re: [boost] Official boost macro to determine endianess?
by Andrey Semashev 05 Apr '17

05 Apr '17

Re-posting. On 04/05/17 16:51, Andrey Semashev wrote: > On 04/05/17 15:29, Frédéric Bron wrote: >> Sorry, I should not have used #elif, in fact ALL macros are defined! >> BOOST_ENDIAN_BIG_BYTE >> BOOST_ENDIAN_BIG_WORD >> BOOST_ENDIAN_LITTLE_BYTE >> BOOST_ENDIAN_LITTLE_WORD >> What does this mean? > > That's how Boost.Predef works: > > http://www.boost.org/doc/libs/1_63_0/doc/html/predef/using_the_predefs.html > > You should check the macro values instead of testing if they are defined > (i.e. use #if instead of #ifdef). > > Also, please, don't top-post. >

1 0

Official boost macro to determine endianess?
by Frédéric Bron 05 Apr '17

05 Apr '17

What is the official boost macro to determine endianess? And what is the header to include to get it? I cannot find any help in the documentation of boost.endian but I can find those macros by grepping in boost: BOOST_LITTLE_ENDIAN, BOOST_BIG_ENDIAN, BOOST_ENDIAN_BIG_BYTE, BOOST_ENDIAN_BIG_WORD, BOOST_ENDIAN_LITTLE_BYTE, BOOST_ENDIAN_LITTLE_WORD, BOOST_PDP_ENDIAN Thanks, Frédéric

4 9

Re: [boost] Official boost macro to determine endianess?
by Andrey Semashev 05 Apr '17

05 Apr '17

Sent this privately by accident. Again. On 04/05/17 13:14, Andrey Semashev wrote: > On 04/05/17 12:45, Frédéric Bron wrote: >>> I think the modern way to do this is to use Boost.Predef. >> >> Great, thanks! >> >> By the way, why does the predef library not follow the boost policy >> [1] on file names, i.e. saying that header files should have .hpp >> extension and not .h? > > Because it is also usable from C. >

1 0

fix in boost/gil/channel_algorithm.hpp for clang 3.9.1
by Frédéric Bron 04 Apr '17

04 Apr '17

Hi, When compiling with clang 3.9.1, I get an error: /softs/osx32-clang-3.9.1/release/boost/include/boost/gil/extension/io/../../channel_algorithm.hpp:54:85: error: non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long long' [-Wc++11-narrowing] struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; Patch is attached. Frédéric

1 0

Re: [boost] [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing
by Ruoyun Jing 03 Apr '17

03 Apr '17

*NO ! I REJECT !* *Plagiarism is plagiarism!* 2017-04-03 19:04 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: > Sorry for using such harsh words earlier. I'm little frustrated now, I > really want to work in this project and I did not start earlier so , I have > to complete everything in a hurry. As yours and mine background was very > similar (professionally (i.e we do competitive and all)). I used your > proposal as a reference for preparing mine. I would have really thanked > you if you would have helped me to make my proposal better as anyhow we are > working on different projects, so it does not matter even if our proposal > have some similarity. We could have helped each other rather than making > all this mess. > > Thanks > Satyam Pandey > > > On Apr 3, 2017 3:37 PM, "Ruoyun Jing via Boost" <boost(a)lists.boost.org> > wrote: > > Hi Boost, Vissarion, Adam, Niall, David > > Sorry for disturbing you at this time, I experienced a very bad thing that > Satyam Pandey, a student who sent proposal yesterday copied too many > sections of my proposal. I marked the sections red in the given PDF.* I > think the same pattern of GSoC proposal is common, and it does not matter, > but his proposal has too many same description as me. * > > And I received two emails from google docs. I will transmit these two > emails in the following emailsThe meaning of one email is Satyam Pandey do > a replace:replace “Dev Environment Visual Studio for C# development Eclipse > for JAVA development Code Blocks, Sublime T…” to“`+” > > The meaning of another email is Satyam Pandey reject the comment of > "Proposal" from his own, replace “Dev Environment Visual Studio for C# > development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” > > I sent an email to him, but he did not think he did the copy work. But the > actually thing is* he forked the whole proposal and then change some words > to fix his condition.* > > 2017-04-03 7:42 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: > > > Hello Ruyong, > > I just wanted to explain my part here. I did not copy as per what I > > understand.I have tried answering your queries.I hope you will read it > > calmly and would try to understand. > > > > > > 1. As far as I could guess we share similar background of competitive > > programming and have no experience in contributing to any large orgs > . So I > > used your proposal as reference for writing my proposal. > > > > > > 1. Our Programming interest are same cause they are, I will end it > > here. This cannot be called a copy-case because thats-what I feel are > the > > things that I like. How can you question that? Every guy that loves > maths > > and programming would have written it in the same way and I'm not > faking my > > interest toward them as you can check by following the links that I > have > > given about different contest that I have participated in. Or do you > want > > to say no-one other than you can like both. > > 2. The Timeline was, one feature that I liked in your proposal, so I > > used it. How its copying ? Your exact timeline will not even make > sense for > > me,cause we are applying for different Projects. > > 3. And I did not understood "And you did not code for programming > > competency test, but have the same idea of implement of test" . What > > does this mean ? . Firstly I haven't read your proposal after you > start > > describing "*far enough*" . So ,I did not know what you were doing in > > your test. Even if I knew what you have done or written there, do you > > think, you have claimed that way of solving the problem by putting it > in > > your proposal ? And even after reading your proficiency test idea, the > > only thing that matches with my idea is the Basic-Distance function > which > > is the first result that we get after googling the problem ? So , > have we > > both copied from google ?? > > > > > > I do not think this means reference, he just use my discription directly > and change some similar words.* This means COPY. * > > > > And please before going public with this, you could have at-least talked > > to me personally. I don't think Boost-Developer mailing list is meant for > > such discussions. Mailing list are made for communication that concerns > the > > whole org not any individual. You could have directly mailed to me, > before > > creating this nuisance. > > Genuinely you should be happy that people are following your style and if > > not, at least think a little before calling someone cheat because > borrowing > > ideas are not equivalent to cheating , in anyway. > > > > I apologize to all for spamming their mail-boxes > > > > *I do not accept his apologize. I want to be given impartial judgement for > this disgusting COPY.* > > Thanks all for reading.:) > > Best regards. > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman > /listinfo.cgi/boost > > > -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Re: [boost] [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing
by Ruoyun Jing 03 Apr '17

03 Apr '17

*plagiarism is plagiarism, regardless project, and stop acting like a 3 years old!* 2017-04-03 18:57 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: > Hello Ruoyun, > Sorry,I m not good with Chinese names So, I used he. I'm not acting as 3 > year old but I think you are, using your idea in writing proposal by taking > a reference is very popular and is always encouraged. If you believe the > ideas that you get are so unique that no one else can think it by > themselves. You could have send your proposal personally to them. > And you know you have given even the edit accesses on your doc, please > remove it else someone can mess up with your doc. I wrote my proposal by > myself according to me, so it will be better if you can leave it upto > mentors to decide whether I copied or not. > *reference implies quotation or citation of your original work, which in this topic, was neither. as the resemblance between two proposals is simple too obvious to consider anything other than full copy of the origin * > On Apr 3, 2017 4:16 PM, "Ruoyun Jing" <jingry0321(a)gmail.com> wrote: > >> plagiarism is plagiarism, regardless project, and stop acting like a 3 >> years old >> >> 2017-04-03 18:41 GMT+08:00 Ruoyun Jing <jingry0321(a)gmail.com>: >> >>> “She” please. >>> >>> 2017-04-03 18:33 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: >>> >>>> Hi all, >>>> >>>> I don't know why Ryoung is so fixated on the matter ? The comment that >>>> I made in his doc was an accident, so I removed it .That's why he got such >>>> mail later. >>>> * Secondly, We are applying for "different projects " . Copying his >>>> exact proposal will not even make sense for me.* >>>> What I used was his style of writing with some other older proposal . I >>>> am adding them as reference here too. >>>> I really feel this is too frustrating why this guy don't even >>>> understand that we are doing 2 different projects, so I can't copy him . >>>> And Sorry to tell you, I used used Moss on our proposal and there is less >>>> than 10% match is our proposal, if you claim that I have just changed a few >>>> words come with some proof as moss is telling something different. >>>> >>>> Please someone look into it. It is very irritating. >>>> >>>> Thanks >>>> Satyam Pandey >>>> >>>> >>>> >>>> On Apr 3, 2017 3:37 PM, "Ruoyun Jing via Boost" <boost(a)lists.boost.org> >>>> wrote: >>>> >>>> Hi Boost, Vissarion, Adam, Niall, David >>>> >>>> Sorry for disturbing you at this time, I experienced a very bad thing >>>> that >>>> Satyam Pandey, a student who sent proposal yesterday copied too many >>>> sections of my proposal. I marked the sections red in the given PDF.* I >>>> think the same pattern of GSoC proposal is common, and it does not >>>> matter, >>>> but his proposal has too many same description as me. * >>>> >>>> And I received two emails from google docs. I will transmit these two >>>> emails in the following emailsThe meaning of one email is Satyam Pandey >>>> do >>>> a replace:replace “Dev Environment Visual Studio for C# development >>>> Eclipse >>>> for JAVA development Code Blocks, Sublime T…” to“`+” >>>> >>>> The meaning of another email is Satyam Pandey reject the comment of >>>> "Proposal" from his own, replace “Dev Environment Visual Studio for C# >>>> development Eclipse for JAVA development Code Blocks, Sublime T…” >>>> to“`+” >>>> >>>> I sent an email to him, but he did not think he did the copy work. But >>>> the >>>> actually thing is* he forked the whole proposal and then change some >>>> words >>>> to fix his condition.* >>>> >>>> 2017-04-03 7:42 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: >>>> >>>> > Hello Ruyong, >>>> > I just wanted to explain my part here. I did not copy as per what I >>>> > understand.I have tried answering your queries.I hope you will read it >>>> > calmly and would try to understand. >>>> > >>>> > >>>> > 1. As far as I could guess we share similar background of >>>> competitive >>>> > programming and have no experience in contributing to any large >>>> orgs . So I >>>> > used your proposal as reference for writing my proposal. >>>> > >>>> > >>>> > 1. Our Programming interest are same cause they are, I will end it >>>> > here. This cannot be called a copy-case because thats-what I feel >>>> are the >>>> > things that I like. How can you question that? Every guy that >>>> loves maths >>>> > and programming would have written it in the same way and I'm not >>>> faking my >>>> > interest toward them as you can check by following the links that >>>> I have >>>> > given about different contest that I have participated in. Or do >>>> you want >>>> > to say no-one other than you can like both. >>>> > 2. The Timeline was, one feature that I liked in your proposal, so >>>> I >>>> > used it. How its copying ? Your exact timeline will not even make >>>> sense for >>>> > me,cause we are applying for different Projects. >>>> > 3. And I did not understood "And you did not code for programming >>>> > competency test, but have the same idea of implement of test" . >>>> What >>>> > does this mean ? . Firstly I haven't read your proposal after you >>>> start >>>> > describing "*far enough*" . So ,I did not know what you were doing >>>> in >>>> > your test. Even if I knew what you have done or written there, do >>>> you >>>> > think, you have claimed that way of solving the problem by putting >>>> it in >>>> > your proposal ? And even after reading your proficiency test idea, >>>> the >>>> > only thing that matches with my idea is the Basic-Distance >>>> function which >>>> > is the first result that we get after googling the problem ? So , >>>> have we >>>> > both copied from google ?? >>>> > >>>> > >>>> > I do not think this means reference, he just use my discription >>>> directly >>>> and change some similar words.* This means COPY. * >>>> >>>> >>>> > And please before going public with this, you could have at-least >>>> talked >>>> > to me personally. I don't think Boost-Developer mailing list is meant >>>> for >>>> > such discussions. Mailing list are made for communication that >>>> concerns the >>>> > whole org not any individual. You could have directly mailed to me, >>>> before >>>> > creating this nuisance. >>>> > Genuinely you should be happy that people are following your style >>>> and if >>>> > not, at least think a little before calling someone cheat because >>>> borrowing >>>> > ideas are not equivalent to cheating , in anyway. >>>> > >>>> > I apologize to all for spamming their mail-boxes >>>> > >>>> >>>> *I do not accept his apologize. I want to be given impartial judgement >>>> for >>>> this disgusting COPY.* >>>> >>>> Thanks all for reading.:) >>>> >>>> Best regards. >>>> >>>> _______________________________________________ >>>> Unsubscribe & other changes: http://lists.boost.org/mailman >>>> /listinfo.cgi/boost >>>> >>>> >>>> >>> >>> >>> -- >>> Northwest University of China >>> Software Engineering >>> jingry0321(a)gmail.com <jingry0321(a)163.com> >>> >> >> >> >> -- >> Northwest University of China >> Software Engineering >> jingry0321(a)gmail.com <jingry0321(a)163.com> >> > -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Re: [boost] [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing
by Ruoyun Jing 03 Apr '17

03 Apr '17

Hi Boost, Here are two emails google docs sent to me.Sorry for my language The meaning of one email is Satyam Pandey do a replace:replace “Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” ---------- Forwarded message ---------- From: Satyam Pandey (Google 文档) <d+MTA0OTYzMTEyNjU1MDQ4ODM2NjY 4-MTE2NjIwMzk2NDMwMjUwNDI3MDcx(a)docs.google.com> Date: 2017-04-02 21:03 GMT+08:00 Subject: Proposal - 替换：将“Dev Environment Visual Studio fo... To: jingry0321(a)gmail.com Satyam Pandey拒绝了“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”中的建议 [image: Satyam Pandey] Satyam Pandey 替换：将“Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…”替换为“`+” [image: Satyam Pandey] Satyam Pandey *已拒绝建议* 打开 <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 您收到此邮件是因为您订阅了有关“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”的所有讨论。更改 Google 文档向您发送的内容。 <https://docs.google.com/document/docos/notify?id=1wj9xPSmdehh9MzE-3MGHMu7cw…> 您可以通过回复此邮件来参与讨论。 The meaning of another email is Satyam Pandey reject the comment of "Proposal" from his own, replace “Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” ---------- Forwarded message ---------- From: Satyam Pandey (Google 文档) < d+MTA0OTYzMTEyNjU1MDQ4ODM2NjY4-MTE2NjIwMzk2NDMwMjUwNDI3MDcx(a)docs.google.com> Date: 2017-04-02 21:03 GMT+08:00 Subject: Proposal - 替换：将“Dev Environment Visual Studio fo... To: jingry0321(a)gmail.com Satyam Pandey拒绝了“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”中的建议 [image: Satyam Pandey] *Satyam Pandey* 替换：将“Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…”替换为“`+” [image: Satyam Pandey] *Satyam Pandey* *已拒绝建议* 打开 <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 您收到此邮件是因为您订阅了有关“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”的所有讨论。更改 Google 文档向您发送的内容。 <https://docs.google.com/document/docos/notify?id=1wj9xPSmdehh9MzE-3MGHMu7cw…> 您可以通过回复此邮件来参与讨论。 -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Fwd: Proposal - 替换：将“Dev Environment Visual Studio fo...
by Ruoyun Jing 03 Apr '17

03 Apr '17

Hi Boost, Here is the first email google docs sent to me. ---------- Forwarded message ---------- From: Satyam Pandey (Google 文档) < d+MTA0OTYzMTEyNjU1MDQ4ODM2NjY4-MTE2NjIwMzk2NDMwMjUwNDI3MDcx(a)docs.google.com> Date: 2017-04-02 20:06 GMT+08:00 Subject: Proposal - 替换：将“Dev Environment Visual Studio fo... To: jingry0321(a)gmail.com Satyam Pandey向“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”添加了一条建议 [image: Satyam Pandey] *Satyam Pandey* 替换：将“Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…”替换为“`+” 打开 <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 您收到此邮件是因为您订阅了有关“Proposal <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> ”的所有讨论。更改 Google 文档向您发送的内容。 <https://docs.google.com/document/docos/notify?id=1wj9xPSmdehh9MzE-3MGHMu7cw…> 您可以通过回复此邮件来参与讨论。 -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Re: [boost] [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing
by Ruoyun Jing 03 Apr '17

03 Apr '17

Hi Boost, Vissarion, Adam, Niall, David Sorry for disturbing you at this time, I experienced a very bad thing that Satyam Pandey, a student who sent proposal yesterday copied too many sections of my proposal. I marked the sections red in the given PDF.* I think the same pattern of GSoC proposal is common, and it does not matter, but his proposal has too many same description as me. * And I received two emails from google docs. I will transmit these two emails in the following emailsThe meaning of one email is Satyam Pandey do a replace:replace “Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” The meaning of another email is Satyam Pandey reject the comment of "Proposal" from his own, replace “Dev Environment Visual Studio for C# development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” I sent an email to him, but he did not think he did the copy work. But the actually thing is* he forked the whole proposal and then change some words to fix his condition.* 2017-04-03 7:42 GMT+08:00 Satyam Pandey <satyampandey0009(a)gmail.com>: > Hello Ruyong, > I just wanted to explain my part here. I did not copy as per what I > understand.I have tried answering your queries.I hope you will read it > calmly and would try to understand. > > > 1. As far as I could guess we share similar background of competitive > programming and have no experience in contributing to any large orgs . So I > used your proposal as reference for writing my proposal. > > > 1. Our Programming interest are same cause they are, I will end it > here. This cannot be called a copy-case because thats-what I feel are the > things that I like. How can you question that? Every guy that loves maths > and programming would have written it in the same way and I'm not faking my > interest toward them as you can check by following the links that I have > given about different contest that I have participated in. Or do you want > to say no-one other than you can like both. > 2. The Timeline was, one feature that I liked in your proposal, so I > used it. How its copying ? Your exact timeline will not even make sense for > me,cause we are applying for different Projects. > 3. And I did not understood "And you did not code for programming > competency test, but have the same idea of implement of test" . What > does this mean ? . Firstly I haven't read your proposal after you start > describing "*far enough*" . So ,I did not know what you were doing in > your test. Even if I knew what you have done or written there, do you > think, you have claimed that way of solving the problem by putting it in > your proposal ? And even after reading your proficiency test idea, the > only thing that matches with my idea is the Basic-Distance function which > is the first result that we get after googling the problem ? So , have we > both copied from google ?? > > > I do not think this means reference, he just use my discription directly and change some similar words.* This means COPY. * > And please before going public with this, you could have at-least talked > to me personally. I don't think Boost-Developer mailing list is meant for > such discussions. Mailing list are made for communication that concerns the > whole org not any individual. You could have directly mailed to me, before > creating this nuisance. > Genuinely you should be happy that people are following your style and if > not, at least think a little before calling someone cheat because borrowing > ideas are not equivalent to cheating , in anyway. > > I apologize to all for spamming their mail-boxes > *I do not accept his apologize. I want to be given impartial judgement for this disgusting COPY.* Thanks all for reading.:) Best regards.

1 0

Re: [boost] [gsoc2017] Please review my proposal for project "Nearly antipodal points distance accuracy improvement. "
by Satyam Pandey 02 Apr '17

02 Apr '17

Hello Ruyong, I just wanted to explain my part here. I did not copy as per what I understand.I have tried answering your queries.I hope you will read it calmly and would try to understand. 1. As far as I could guess we share similar background of competitive programming and have no experience in contributing to any large orgs . So I used your proposal as reference for writing my proposal. 2. Our Programming interest are same cause they are, I will end it here. This cannot be called a copy-case because thats-what I feel are the things that I like. How can you question that? Every guy that loves maths and programming would have written it in the same way and I'm not faking my interest toward them as you can check by following the links that I have given about different contest that I have participated in. Or do you want to say no-one other than you can like both. 3. The Timeline was, one feature that I liked in your proposal, so I used it. How its copying ? Your exact timeline will not even make sense for me,cause we are applying for different Projects. 4. And I did not understood "And you did not code for programming competency test, but have the same idea of implement of test" . What does this mean ? . Firstly I haven't read your proposal after you start describing "*far enough*" . So ,I did not know what you were doing in your test. Even if I knew what you have done or written there, do you think, you have claimed that way of solving the problem by putting it in your proposal ? And even after reading your proficiency test idea, the only thing that matches with my idea is the Basic-Distance function which is the first result that we get after googling the problem ? So , have we both copied from google ?? And please before going public with this, you could have at-least talked to me personally. I don't think Boost-Developer mailing list is meant for such discussions. Mailing list are made for communication that concerns the whole org not any individual. You could have directly mailed to me, before creating this nuisance. Genuinely you should be happy that people are following your style and if not, at least think a little before calling someone cheat because borrowing ideas are not equivalent to cheating , in anyway. I apologize to all for spamming their mail-boxes Thanks Satyam Pandey On Mon, Apr 3, 2017 at 5:12 AM, Satyam Pandey <satyampandey0009(a)gmail.com> wrote: > Hello Ruyong, > I just wanted to explain my part here. I did not copy as per what I > understand.I have tried answering your queries.I hope you will read it > calmly and would try to understand. > > > 1. As far as I could guess we share similar background of competitive > programming and have no experience in contributing to any large orgs . So I > used your proposal as reference for writing my proposal. > 2. Our Programming interest are same cause they are, I will end it > here. This cannot be called a copy-case because thats-what I feel are the > things that I like. How can you question that? Every guy that loves maths > and programming would have written it in the same way and I'm not faking my > interest toward them as you can check by following the links that I have > given about different contest that I have participated in. Or do you want > to say no-one other than you can like both. > 3. The Timeline was, one feature that I liked in your proposal, so I > used it. How its copying ? Your exact timeline will not even make sense for > me,cause we are applying for different Projects. > 4. And I did not understood "And you did not code for programming > competency test, but have the same idea of implement of test" . What > does this mean ? . Firstly I haven't read your proposal after you start > describing "*far enough*" . So ,I did not know what you were doing in > your test. Even if I knew what you have done or written there, do you > think, you have claimed that way of solving the problem by putting it in > your proposal ? And even after reading your proficiency test idea, the > only thing that matches with my idea is the Basic-Distance function which > is the first result that we get after googling the problem ? So , have we > both copied from google ?? > > > And please before going public with this, you could have at-least talked > to me personally. I don't think Boost-Developer mailing list is meant for > such discussions. Mailing list are made for communication that concerns the > whole org not any individual. You could have directly mailed to me, before > creating this nuisance. > Genuinely you should be happy that people are following your style and if > not, at least think a little before calling someone cheat because borrowing > ideas are not equivalent to cheating , in anyway. > > I apologize to all for spamming their mail-boxes > > Thanks > Satyam Pandey. > > > > > On Mon, Apr 3, 2017 at 3:13 AM, Ruoyun Jing <jingry0321(a)gmail.com> wrote: > >> Hi Satyam, >> Your proposal is same as me especially on milestone and programming test. >> I received two emails from google docs. Sorry for my language is Chinese. >> The meaning of this email is Satyam Pandey do a replace:replace “Dev >> Environment Visual Studio for C# development Eclipse for JAVA development >> Code Blocks, Sublime T…” to“`+” >> >> On Sun, Apr 2, 2017 at 8:06 PM, Satyam Pandey (Google 文档) < >> d+MTA0OTYzMTEyNjU1MDQ4ODM2NjY4-MTE2NjIwMzk2NDMwMjUwNDI3 >> MDcx(a)docs.google.com> wrote: >> >>> Satyam Pandey向“Proposal >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> ”添加了一条建议 >>> [image: Satyam Pandey] >>> Satyam Pandey >>> >>> 替换：将“Dev Environment Visual Studio for C# development Eclipse for JAVA >>> development Code Blocks, Sublime T…”替换为“`+” >>> >>> 打开 >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA >>> >>> 您收到此邮件是因为您订阅了有关“Proposal >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> ”的所有讨论。更改 Google 文档向您发送的内容。 >>> <https://docs.google.com/document/docos/notify?id=1wj9xPSmdehh9MzE-3MGHMu7cw…> >>> 您可以通过回复此邮件来参与讨论。 >>> >> >> >> >> -- >> Northwest University of China >> Software Engineering >> jingry0321(a)gmail.com <jingry0321(a)163.com> >> >> The meaning of this email is Satyam Pandey reject the comment of >> "Proposal" from his own, replace “Dev Environment Visual Studio for C# >> development Eclipse for JAVA development Code Blocks, Sublime T…” to“`+” >> 2017-04-02 21:03 GMT+08:00 Satyam Pandey (Google 文档) < >> d+MTA0OTYzMTEyNjU1MDQ4ODM2NjY4-MTE2NjIwMzk2NDMwMjUwNDI3 >> MDcx(a)docs.google.com>: >> >>> Satyam Pandey拒绝了“Proposal >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> ”中的建议 >>> [image: Satyam Pandey] >>> Satyam Pandey >>> >>> 替换：将“Dev Environment Visual Studio for C# development Eclipse for JAVA >>> development Code Blocks, Sublime T…”替换为“`+” >>> >>> [image: Satyam Pandey] >>> Satyam Pandey >>> >>> *已拒绝建议* >>> 打开 >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA >>> >>> 您收到此邮件是因为您订阅了有关“Proposal >>> <https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb…> >>> ”的所有讨论。更改 Google 文档向您发送的内容。 >>> <https://docs.google.com/document/docos/notify?id=1wj9xPSmdehh9MzE-3MGHMu7cw…> >>> 您可以通过回复此邮件来参与讨论。 >>> >> >> I think I need you to give some explanation. >> >> -- >> Northwest University of China >> Software Engineering >> jingry0321(a)gmail.com <jingry0321(a)163.com> >> > >

1 0

[gsoc] Project Proposal Review Request for Static_Map Class
by Baber Khalid 02 Apr '17

02 Apr '17

Dear Niall Douglas, I am a third year B.Sc Computer Science student and I am planning to apply for the idea of developing a static_map in C++ which does not generate any code at runtime including the code for lookups. Here is my first proposal draft: https://docs.google.com/document/d/1rwiIsmsMWGz4mMwIIQ00k5uw3G71d6L0ofC8jPi… Any feedback would be appreciated! Regards, Baber Khalid

1 0

[gsoc2017] Please review my proposal for project "Nearly antipodal points distance accuracy improvement. "
by Satyam.Pandey 02 Apr '17

02 Apr '17

Hi all, I want to contribute to the project "Nearly antipodal points distance accuracy improvement." I have attached my proposal in the mail. I request the mentors to review my proposal. I know I'm pretty late to start. But it would be great help if you can review my proposal and suggest the changes if required. Proposal : https://docs.google.com/document/d/19WYR0RHINxqhtu0SIN0ZUxYMNKxAf1LOBPGl7j7… Thanks Satyam Pandey -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc2017-Please-review-my-proposal-for-p… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

equivalent for 'pause' mnemonic on ARM - or boost.pref?
by Oliver Kowalke 02 Apr '17

02 Apr '17

Hi, does someone know an equivalent of x86 'pause' mnemonic for ARMv6? Raspbian (-march=armv6) and Debian armel (-march=armv4) seam no to accept The 'yield' mnemonic seams no to be right in both cases. Or does boost.predef's BOOST_ARCH_ARM give a hint for both cases? ty, Oliver

2 2

BOOST license & GPL
by Oliver Kowalke 02 Apr '17

02 Apr '17

Hi, I encountered a open source project that is released under GPL and uses Boost - that's OK, because GPL and Boost license should be compatible. But the developers of those project copied code from Boost into their own library. The question is, is this new library now GPL or Boost license? Additionally, because they copied the code from several Boost files into one, they mixed up copyright statements. As a result, some people get copyright on code they never wrote. Seams to me that's not correct. Oliver

4 15

[gsoc17] My proposal
by GuillermoReyes 01 Apr '17

01 Apr '17

Dear Vissarion and Adam, My name is Guillermo- a Computer science student at UCLA. I am excited at the possibility of contributing to such a useful library! My application is not yet complete, but I will post my draft on here to demonstrate my intent to participate in the program. For the competency test, I began to implement a representation of points on earth and used the great-circle formula to calculate the shortest distance between two points. I will have a more in-depth explanation of the code by the final iteration of the draft along with the complete proposal and application. Sincerely, Guillermo R. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-My-proposal-tp4693288.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[Stacktrace] Review 2 Manager report
by Niall Douglas 31 Mar '17

31 Mar '17

Many thanks to all those who participated in the second review of proposed Boost.Stacktrace. I received the following formal reviews: 1. Peter Dimov (ACCEPT) 2. Vladimir Batov (ACCEPT) 3. Artyom Bellis (CONDITIONAL ACCEPT) 4. Bjorn Reese (ACCEPT) 5. Edward Diener (ACCEPT) Extensive comments without a formal recommendation were also made by: 1. Mark Bartosik 2. Florian Weimer Some of the more important conditions for acceptance as judged by the review manager are: * Problems on FreeBSD (and by inference OS X?). * Per frame execution of addr2line rather than calling it once. * Throw-with-trace was asked for by a lot of people. * One reviewer suggested that the addr2line backend was async signal unsafe. My reading of the code is that it is async signal unsafe to parse a stacktrace (and unavoidably so on any platform), but the capture of backtraces is now fully async signal safe. * Some disliked the bringing in of windows.h and the COM headers on Windows. For a header only library I consider this acceptable, Stacktrace when configured in non-header only mode does not inject windows.h into everything including stacktrace. Congratulations to Antony on getting yet another library of his into Boost! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[Beast] Redesigned HTTP algorithms and parser!
by Vinnie Falco 31 Mar '17

31 Mar '17

Background: Websocket connections start with an HTTP UPGRADE request/response sequence. Often people want to customize this handshake so I added code in Beast to read and write HTTP messages. Upon reviewing the HTTP RFC (rfc2616 and rfc7230) it seemed to be logical that the HTTP message could be modeled as a single class. And there could be free functions implementing the algorithms to serialize and deserialize these messages in th HTTP/1 format. I took this as far as I could and I was pretty happy with the result. You have functions like read, async_read, write, and async_write which take beast::http::message objects as parameters. Example: http://vinniefalco.github.io/beast/beast/ref/http__read/overload3.html The innovation here is the "Body" template type which controls not only the type of container used to represent the body but also the algorithms used to transfer bytes from the message body on the wire into and out of that container. The Body concept, and its nested Reader and Writer concepts, are documented here: http://vinniefalco.github.io/beast/beast/ref/Body.html http://vinniefalco.github.io/beast/beast/ref/Reader.html http://vinniefalco.github.io/beast/beast/ref/Writer.html Previous efforts and HTTP implementations focused heavily on the representation and parsing of the headers. To my knowledge Beast is the first implementation to provide caller flexibility in the body representation. Now the Beast websocket implementation has a reasonable set of primitives it could use to perform the handshake, and users could get control of that process. The Problem: Unfortunately, while treating the message as an object that can be read/written atomically works great for example programs and trivial use-cases, it fails in the real world. These are issues with it: * The caller must commit to a Body representation before receiving the HTTP Header * No way to properly read and respond to Expect: 100-continue * An efficient HTTP relay function (one that does not buffer the entire body up front) cannot be implemented by the caller * The caller cannot reasonably set a timeout, for example what if the body is 2 gigabytes received over a slow connection? * The parser interface forces algorithms to perform an unnecessary buffer copy for body containers that are entirely stored in memory (e.g std::string or boost::asio::streambuf). These issues sparked quite a bit of discussion on GitHub: https://github.com/vinniefalco/Beast/issues/154 https://github.com/vinniefalco/Beast/issues/265 In October of 2016 these problems became apparent. I tried a lot of different ideas to improve the design to solve it, but none of them worked. Some of my co-workers looked at it but we didn't really find anything great. One user in particular, on GitHub, had strong ideas involving the concept of "completion conditions" to augment the read/parse algorithms but it didn't feel right to me. The Solution: After suffering from writer's block for 5 months inspiration hit and I tried a combination of interface changes that got the design to where it needs to be to solve these problems. * The Reader concept is refined into two types: "indirect" readers, and "direct" readers. This is described here: http://vinniefalco.github.io/stage/beast/beast/ref/Reader.html * The parser exposes a small number of internal states, informing callers of where it is at and giving the caller control over if and when the parser advances to the next state: https://github.com/vinniefalco/Beast/blob/http/include/beast/http/basic_par… * The parser is rewritten to work only on linear buffers (allowing it to be optimized to become 20 times faster if SSE2 instructions are allowed). To facilitate this requirement, the flat_streambuf class is provided which works just like a basic_streambuf except it guarantees a single buffer. If the parser is given multiple buffers, it allocates memory to flatten it: https://github.com/vinniefalco/Beast/blob/http/include/beast/core/flat_stre… * New functions parse_some and async_parse_some allow the caller to perform incremental parsing. This allows for the implementation of relay functions, or reading just the header (for Expect: 100-continue): https://github.com/vinniefalco/Beast/blob/http/include/beast/http/parse.hpp… With these changes callers can get control of the inner loop that reads the body off the socket or stream, so they can do whatever custom steps are necessary if they want. They can set timeouts, and write their own loop that calls parse_some repeatedly. I think it solves all of these issues. I've written some test code which demonstrates how direct and indirect body readers are implemented, and what calling code looks like. I've also written a prototype "relay" function (read a message from one socket and efficiently write it to another socket). And there's an example of how Expect: 100-continue might be implemented. These prototypes are located here: https://github.com/vinniefalco/Beast/blob/http/test/http/design.cpp#L30 How to Help? These are some controversial changes and I think they could use some polish and vetting before I merge it to the master branch. Maybe there is something I haven't thought of, or a use-case it doesn't address. Perhaps there is a better way, or perhaps there are tweaks to make it even more usable and understandable. If some kind soul(s) would look through it and offer some feedback, positive or negative, that would be enormously helpful. The formal review for Beast is now scheduled for the first week of July and like an expectant father I am anxious and would like everything to go just right! My only objective is to polish up the library and its documentation so it is in the best possible shape for review. Thanks for listening!

1 1

[release] Boost 1.64.0 Beta 2
by Rene Rivera 31 Mar '17

31 Mar '17

Boost release 1.64.0 beta 2 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/source/> The SHA256 checksums are as follows: 49c9339b9d8e7b2610ef84c80cd10b2252c119ebcc3222450beb0e94c1da1522 boost_1_64_0_b2.7z 92ec7cbf1e77c5979e381dd8104f9e96c0471c276e566272751a981d806db94b boost_1_64_0_b2.tar.bz2 da5670892b7b572808491b13a7b9421c3c18e6f395d6a5ec822466db466eda01 boost_1_64_0_b2.tar.gz 61d6e29e8a1d7503fe13a9d916842f0ec2e625f733b98b29ce563f8cbdb482bf boost_1_64_0_b2.zip The notable difference from Beta 1 is the inclusion of the missing Boost Process library. For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 5

[gsoc17]Proposal draft shared of Boost.Geometry Project 1
by Ruoyun Jing 30 Mar '17

30 Mar '17

Hi Adam, Vissarion, boost all: I have finished my proposal of Boost.Geometry Project 1, I am very pleasure you to give me more advice of my proposal! :) Any aspect of the proposal is OK! I would like to get feed back from you! Looking forward from you! :) Thanks all and Best Regards. Google docs: https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb… Ruoyun Jing -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Boost.SIMD review
by serge guelton 30 Mar '17

30 Mar '17

Hi Boost Dev, I'm the core maintainer of Pythran[0], a python-to-native-code compiler focused on numeric computations. For more than 3 years, we've been using Boost.SIMD [1] as a generic backend for SIMD code generation, without much worries. Basically our compiler generates C++ code that includes Boost.simd calls. The big plus to us are: + Performances. The generated code runs at the same speed as the one written with intrinsics; + Target abstraction, esp. concerning the vector size and the various arithmetic operations; + Complete libm API, vectorized, which is a big plus when porting existing code (or when matching an existing API as we do); + Header only, which actually makes it easier for us to ship; + Low requirements (it does not require us to ship a large part of boost).? The compilation time is sometimes a worry, but it has decreased over the year. We don't use complex data movement like shuffle or pack, so I don't have any feedback on that. All in one, if that ever matters, I would be happy to have it integrated in Boost! ++ Serge [0] https://pythonhosted.org/pythran/ [1] https://github.com/NumScale/boost.simd

1 0

NuDB: A fast key/value insert-only database for SSD drives in C++11
by Vinnie Falco 30 Mar '17

30 Mar '17

I just released version 1.0.0 of my header-only C++11 library NuDB. Its quite a mature library, haven't had to make any changes in a while. Its been running on production servers for 2 years or so with no problems, managing ever-growing databases of 2TB. I'm wondering what the level of interest, if any, there would be for making this a part of Boost. You can check it out here: https://github.com/vinniefalco/NuDB

11 91

Problem creating mapping from string to vector_expression
by SHIVAM MITTAL 30 Mar '17

30 Mar '17

Hi, I have been trying to create a mapping from string to ublas::vector_expression. template <class T> boost::unordered_map<std::string, vector_expression <T> > c; vector<int> v (10); for (unsigned i = 0; i < v.size (); ++ i) v (i) = i; c <int>["first"] = v; I have been getting this error : error: no match for ‘operator=’ (operand types are ‘boost::unordered::unordered_map<std::__cxx11::basic_string<char>, boost::numeric::ublas::vector_expression<int>, boost::hash<std::__cxx11::basic_string<char> >, std::equal_to<std::__cxx11::basic_string<char> >, std::allocator<std::pair<const std::__cxx11::basic_string<char>, boost::numeric::ublas::vector_expression<int> > > >::mapped_type {aka boost::numeric::ublas::vector_expression<int>}’ and ‘boost::numeric::ublas::vector<int>’) columns <int>["first"] = v; Please help.

1 0

[build][geometry][regression] Geometry develop regression tests are blank
by Adam Wulkiewicz 29 Mar '17

29 Mar '17

Hi, Boost.Geometry develop tests (http://www.boost.org/development/tests/develop/developer/geometry.html) stopped showing around 22.03. The first blank run (teeks99-03-dc3.9-1z-Docker-64on64) is from Wed, 22 Mar 2017 01:20:13. Do you have an idea what may be the cause? I see that many changes in Build and Regression was done around 22.03. Geometry was also modified that day but the first commit is from 12:40+1 so later than the first blank run. I checked the XML of one of them (teeks99-09-n-win2012R2-64on64) and it seems that the revision attribute of <test-log> tag is not set for the most of the tests. I'm currently running the regression.py myself in hope of finding the cause. I see that in bjam.log the only tests that are dumped are: boost-test(RUN_PYD) "geometry/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN_PYD) "geometry/extensions/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN) "geometry/index/varray_old" : "libs/geometry/index/test/varray_old.cpp" boost-test(RUN) "geometry/index/varray" : "libs/geometry/index/test/varray.cpp" boost-test(RUN_PYD) "geometry/index/__boost_check_library__" : "status/boost_check_library.py" varray tests are the only ones that are run at the most top level of Geometry Jamfiles (of sublib geometry/index in this case) with test-suite: https://github.com/boostorg/geometry/blob/develop/index/test/Jamfile.v2#L24 The rest of the tests is run with build-project, also for the main part of the library: https://github.com/boostorg/geometry/blob/develop/test/Jamfile.v2#L26 The varray tests results are shown on the regression page and can be found in bjam.log and in XML file with revision set. The rest of the tests is neither dumped nor has the revision set, however they are run during regression testing so can be found in bjam.log and also in XML file but with empty revision. Adam

2 5

Broken link to conversion library
by Antony Polukhin 29 Mar '17

29 Mar '17

Hello, There is a broken link to Conversion library on the changelog page: http://www.boost.org/users/history/version_1_64_0.html Can not figure out what's the problem. Could someone take a look? -- Best regards, Antony Polukhin

3 3

[Boost.Test] Custom DataSet compiler error with no match for »operator^
by Olaf Peter 29 Mar '17

29 Mar '17

Hello, I run into a compile problem with [Boost.Test] DataSet. I can reduce it by re-using the example provided by the docs: http://www.boost.org/doc/libs/1_62_0/libs/test/doc/html/boost_test/tests_or… #define BOOST_TEST_MODULE dataset_example68 #include <boost/test/included/unit_test.hpp> #include <boost/test/data/test_case.hpp> #include <boost/test/data/monomorphic.hpp> #include <sstream> namespace bdata = boost::unit_test::data; // Dataset generating a Fibonacci sequence class fibonacci_dataset { public: // Samples type is int using sample=int; enum { arity = 1 }; struct iterator { iterator() : a(1), b(1) {} int operator*() const { return b; } void operator++() { a = a + b; std::swap(a, b); } private: int a; int b; // b is the output }; fibonacci_dataset() {} // size is infinite bdata::size_t size() const { return bdata::BOOST_TEST_DS_INFINITE_SIZE; } // iterator iterator begin() const { return iterator(); } }; namespace boost { namespace unit_test { namespace data { namespace monomorphic { // registering fibonacci_dataset as a proper dataset template <> struct is_dataset<fibonacci_dataset> : boost::mpl::true_ {}; }}}} // Creating a test-driven dataset BOOST_DATA_TEST_CASE( test1, fibonacci_dataset() ^ fibonacci_dataset(), fib_sample, exp) { BOOST_TEST(fib_sample == exp); } error: no match for 'operator^' (operand types are 'boost::unit_test::data::result_of::make<fibonacci_dataset>::type {aka fibonacci_dataset}' and 'fibonacci_dataset') fibonacci_dataset() ^ fibonacci_dataset(), My use case has to load input and expect files provides by two datasets. How to fix it? Thanks, Olaf

3 3

Re: [boost] [Boost-users] Going insane trying to build boost for android
by Robert Dailey 29 Mar '17

29 Mar '17

On Mon, Mar 27, 2017 at 11:54 AM, John Maddock <jz.maddock(a)googlemail.com> wrote: > >> That won't do me any good because I'm already using this toolchain >> perfectly fine via CMake and ndk-build. bjam isn't working, maybe >> because I haven't set up the config.jam file properly. I'm not sure at >> this point. Boost is the only thing not working here. > > > Then if you compare the compilation command line generated when building > under b2 and when building under cmake the error should be obvious? I took your advice and compared a real build that worked using CMake (using a simple test cpp file) and what I got from b2. Here is the command line used to build the sample app using CMake. Note that the compilation succeeded: C:\android\ndk\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe --sysroot=C:/android/ndk/platforms/android-15/arch-arm -Dndk_test_EXPORTS -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -march=armv7-a -mthumb -mfpu=vfpv3-d16 -mfloat-abi=softfp -funwind-tables -no-canonical-prefixes -fexceptions -frtti -g -fPIC -std=gnu++14 -MD -MT CMakeFiles/ndk_test.dir/main.cpp.o -MF CMakeFiles\ndk_test.dir\main.cpp.o.d -o CMakeFiles/ndk_test.dir/main.cpp.o -c ../main.cpp And here is the command line from b2: "C:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++" -c -x c++ -O3 -Wno-inline -Wall --sysroot=C:/android/ndk/platforms/android-15/arch-arm -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -std=c++14 -fno-strict-aliasing -D__GLIBC__ -DANDROID -D__ANDROID__ -D_GLIBCXX__PTHREADS -D__arm__ -D_REENTRANT -O2 -DNDEBUG -H -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_SOURCE -DBOOST_ATOMIC_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o" "libs\atomic\src\lockpool.cpp" The build for boost still fails. Note I also passed the -H option, so I could see the include searches performed by clang as it was building boost. The output is long, but I've included it below. Can anyone help me identify why boost still won't build? clang-linux.compile.c++.without-pth bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o "C:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++" -c -x c++ -O3 -Wno-inline -Wall --sysroot=C:/android/ndk/platforms/android-15/arch-arm -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -std=c++14 -fno-strict-aliasing -D__GLIBC__ -DANDROID -D__ANDROID__ -D_GLIBCXX__PTHREADS -D__arm__ -D_REENTRANT -O2 -DNDEBUG -H -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_SOURCE -DBOOST_ATOMIC_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o" "libs\atomic\src\lockpool.cpp" . C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\cstddef .. C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\__config .. C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ... C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include/__stddef_max_align_t.h .. C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\__nullptr . .\\boost/config.hpp .. .\\boost/config/user.hpp .. .\\boost/config/select_compiler_config.hpp .. .\\boost/config/compiler/clang.hpp .. .\\boost/config/select_stdlib_config.hpp .. .\\boost/config/stdlib/libcpp.hpp .. .\\boost/config/select_platform_config.hpp .. .\\boost/config/platform/linux.hpp ... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\cstdlib .... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stdlib.h ..... C:/android/ndk/sources/android/support/include\\stdlib.h ...... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\stdlib.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/cdefs.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/cdefs_elf.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\android/api-level.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........ C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........ C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\string.h ........ C:/android/ndk/sources/android/support/include\\string.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\string.h .......... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\malloc.h ........... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\alloca.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\strings.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/types.h ......... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h .......... C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ......... C:/android/ndk/sources/android/support/include\\stdint.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\stdint.h ........... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/_types.h ............ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\machine/_types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/posix_types.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/stddef.h ........... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/compiler.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\asm/posix_types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\asm/types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\machine/kernel.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/sysmacros.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\memory.h In file included from libs\atomic\src\lockpool.cpp:16: In file included from .\boost/config.hpp:57: In file included from .\boost/config/platform/linux.hpp:15: C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:108:9: error: no member named 'strtold' in the global namespace using ::strtold; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:126:9: error: no member named '_Exit' in the global namespace using ::_Exit; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:149:9: error: no member named 'at_quick_exit' in the global namespace using ::at_quick_exit; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:150:9: error: no member named 'quick_exit' in the global namespace using ::quick_exit; ~~^

2 1

[review queue] What to do about the library review queue?
by Niall Douglas 28 Mar '17

28 Mar '17

Dear Boost, I see that new candidate Boost libraries entering the review queue have exploded in recent years, with no less than *twenty-three* proposed libraries awaiting a review. As the ongoing strength and vitality of Boost is inextricably linked to new growth, I think that waiting around for years for someone to volunteer to manage a review is not healthy. If a library author has invested the very significant effort to develop a Boost-quality library, the least Boost can do is to try harder to provide timely reviews and that means persuading more people to volunteer to manage reviews. In the past people have argued that for every library you submit for review, you should manage a review in return. Myself, Antony and a few others have adhered to that rule, and if every library author did so there would be no outstanding review queue. However there are problems in that in itself in terms of moral hazard, and also because the review manager needs to usually be fairly expert in a library being reviewed, else it can be very hard to judge the worth and validity of reviews. A shortage of suitably expert review managers will always be a problem for some types of library. I therefore ask boost-dev what to do? Some options: 1. Pay US$1000 (one thousand) dollars to each person who manages a review. In case you're worried Boost doesn't have the money, it does in spades, that's not a problem. For $23,000 we could clear the current review queue assuming none of the problems mentioned yet. 2. Pay US$1000 dollars to the manager and 2x $500 dollar payments to those writing the top two most useful reviews as judged by the review manager. That makes the cost $2000 per library accepted or rejected, or $46,000 to clear the current review queue. 3. In my own opinion from reviewing the review queue, a good 25% of the libraries in the queue are not ready for review due to obvious glaring deficiencies in the documentation or code. Spending a grand on those libraries which will very obviously be rejected isn't worth the money. What should we do about those? One approach could simply be to trust review managers to not abuse the thousand dollar fee. Another could be that before each new review, the prospective manager needs to write a single line comment on why they did not choose the other libraries in the queue and publish that here before starting a review. That would quickly identify those libraries in the queue which a majority of managers think have serious problems and could never pass any review. If say a library in a queue accumulates three single line black marks, the author might be encouraged to withdraw it. 4. Finally there is the problem of libraries of high quality, but not a good fit for Boost because they are so esoteric and niche that nobody could provide a useful review, and without useful reviews the review manager can't really recommend acceptance. This will be an increasing problem with time anyway as more of the low hanging C++ library fruit is picked, but I suppose one could just kick that decision can down the road and see if 2x $500 payments might help scare up more high quality reviews. 5. We could try guilting more people into review managing, and redouble banging the drum to scare up more volunteers. I look forward to seeing what people think. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

29 104

[1.64] Can't configure msvc-14.1
by John Maddock 28 Mar '17

28 Mar '17

So... I have in my user-config.jam: using msvc : 14.1 : "M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/cl.exe" ; And this did work at one point, but both with latest develop and master I now get: M:/data/boost/boost/tools/build/src/tools\msvc.jam:1103: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup ? : default-global-setup-options : default-setup ) * called with: ( 14.10.25017 14.10.25017 : M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64 : M:\Compilers\VC2017\VC\Tools\MSVC\14.10.25017\bin\HostX64 : <command>M:\Compilers\VC2017\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe <command>M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/cl.exe : i386 : : x86 : vcvars32.bat ) * extra argument 14.10.25017 M:/data/boost/boost/tools/build/src/tools\msvc.jam:811:see definition of rule 'generate-setup-cmd' being called M:/data/boost/boost/tools/build/src/tools\msvc.jam:201: in configure M:/data/boost/boost/tools/build/src/tools\msvc.jam:153: in msvc.init M:/data/boost/boost/tools/build/src/build\toolset.jam:43: in toolset.using M:/data/boost/boost/tools/build/src/build\project.jam:1052: in using C:\cygwin64\home\John\user-config.jam:46: in modules.load M:/data/boost/boost/tools/build/src\build-system.jam:249: in load-config M:/data/boost/boost/tools/build/src\build-system.jam:389: in load-configuration-files M:/data/boost/boost/tools/build/src\build-system.jam:524: in load M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build M:\data\boost\boost\boost-build.jam:17: in module scope Anyone any ideas? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

1 0

Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
by Paul A. Bristow 28 Mar '17

28 Mar '17

I am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0 I am using the CodeBlocks IDE (though I don't think that is relevant). The code indirectly uses next.hpp and prior.hpp There are several warnings like this (after adding the -Wignored-attributes option) C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\immintrin.h|45|warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes] I:\modular-boost\boost\mpl\next_prior.hpp|44|error: too many arguments provided to function-like macro invocation| Following suggestions in this thread, I have added -Wno-invalid-token-paste http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.h… and also -DBOOST_PP_CONFIG_FLAGS=1, but I get a blizzard of errors - see below It would seem that this may be because of a misconfiguration in Boost mpl? If I understand right, the thread above suggests that this is MS pre-processor-specific MPL code because of code in boost/preprocessor/config/config.hpp that determines the MPL code? Is this correct? Target: x86_64-pc-windows-msvc -triple x86_64-pc-windows-msvc19.0.24123 Complete log attached in case this helps. Can anyone say what I am doing wrong and/or suggest a workaround for this? Thanks Paul Compile line is clang++.exe -Wall -fexceptions -Wignored_attributes -D"BOOST_PP_CONFIG_FLAGS()"=1 -m64 -v -Wignored-attributes -Wno-invalid-token-paste -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -c J:\Cpp\Misc\lambert_w_single\lambert_w_single.cpp -o .objs\Misc\lambert_w_single\lambert_w_single.o clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "C:\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123 In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/preprocessor/facilities/expand.hpp:26:10: note: macro 'BOOST_PP_EXPAND_I' defined here # define BOOST_PP_EXPAND_I(x) x ^ In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:1: error: expected a qualified name after 'typename' BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:64:11: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_PARAMS(i, typename T) \ ^ I:\modular-boost\boost/mpl/aux_/preprocessor/params.hpp:58:11: note: expanded from macro 'BOOST_MPL_PP_PARAMS' , BOOST_MPL_PP_AUX_PARAM_FUNC \ ^ ... I:\modular-boost\boost/mpl/void.hpp:71:1: error: expected ',' or '>' in template-parameter-list I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:65:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:38:37: note: expanded from macro 'BOOST_PP_REPEAT_1' # define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d) ^ I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:43:39: note: expanded from macro 'BOOST_PP_REPEAT_1_I' # define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d) ^ <scratch space>:64:1: note: expanded from here BOOST_PP_REPEAT_1_BOOST_PP_REM ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

4 53

Constructing string_ref from rvalue string
by Simon Sasburg 28 Mar '17

28 Mar '17

I've just tested our codebase with the 1.64.0 master snapshot, and i've encountered an issue which i've tracked down to this commit: https://github.com/boostorg/utility/commit/9960d9f395b79ee860e39064cd4696 1f76d2cb55 Basically this removes the constructor which allows constructing a boost::string_ref from an rvalue std::string. I am wondering if this is really that dangerous. In our codebase we almost exlusively use boost::string_ref as function parameters, with the understanding that passed string_refs parameters are only valid within the function body. (so you need to copy it into an std::string if you need to access it afterwards) With these constraints i think it is OK to construct a string_ref from an rvalue std::string because the temporary should live long enough. (but please correct me if i'm wrong here) Is the safety (?) added by this commit worth it if it breaks working code? Simon

11 20

Undefined refs when compiling trivial example
by Florian Lindner 28 Mar '17

28 Mar '17

Hello, I took the trivial example from http://www.boost.org/doc/libs/1_63_0/libs/log/example/doc/tutorial_trivial.… and try to compile it. boost 1.63 is compiled by myself without any special options, besides --prefix. % echo $LD_LIBRARY_PATH /home/lindnefn/software/boost/lib: % echo $LIBRARY_PATH /home/lindnefn/software/boost/lib: % echo $CPLUS_INCLUDE_PATH /home/lindnefn/software/boost/include: the LIBRARY_PATH contains all the *.so and *.a files, the INCLUDE_PATH/boost all the headers. but compiling fails: lindnefn@helium ~ % g++ -std=c++11 -DBOOST_ALL_DYN_LINK -pthread -lboost_log_setup -lboost_log -lboost_thread -lboost_filesystem boostlog_trivial.cpp /tmp/ccUc6CtH.o: In function `main': boostlog_trivial.cpp:(.text+0x48): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x76): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0xe8): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x116): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x188): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' /tmp/ccUc6CtH.o:boostlog_trivial.cpp:(.text+0x1b6): more undefined references to `boost::log::v2_mt_posix::trivial::logger::get()' follow /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::record::reset()': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix6record5resetEv[_ZN5boost3log11v2_mt_posix6record5resetEv]+0x23): undefined reference to `boost::log::v2_mt_posix::record_view::public_data::destroy(boost::log::v2_mt_posix::record_view::public_data const*)' /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::record boost::log::v2_mt_posix::sources::basic_composite_logger<char, boost::log::v2_mt_posix::sources::severity_logger_mt<boost::log::v2_mt_posix::trivial::severity_level>, boost::log::v2_mt_posix::sources::multi_thread_model<boost::log::v2_mt_posix::aux::light_rw_mutex>, boost::log::v2_mt_posix::sources::features<boost::log::v2_mt_posix::sources::severity<boost::log::v2_mt_posix::trivial::severity_level> > >::open_record<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::severity, boost::log::v2_mt_posix::trivial::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::severity, boost::log::v2_mt_posix::trivial::severity_level const> const&)': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix7sources22basic_composite_loggerIcNS2_18severity_logger_mtINS1_7trivial14severity_levelEEENS2_18multi_thread_modelINS1_3aux14light_rw_mutexEEENS2_8featuresIJNS2_8severityIS6_EEEEEE11open_recordINS_9parameter3aux15tagged_argumentINS1_8keywords3tag8severityEKS6_EEEENS1_6recordERKT_[_ZN5boost3log11v2_mt_posix7sources22basic_composite_loggerIcNS2_18severity_logger_mtINS1_7trivial14severity_levelEEENS2_18multi_thread_modelINS1_3aux14light_rw_mutexEEENS2_8featuresIJNS2_8severityIS6_EEEEEE11open_recordINS_9parameter3aux15tagged_argumentINS1_8keywords3tag8severityEKS6_EEEENS1_6recordERKT_]+0x3c): undefined reference to `boost::log::v2_mt_posix::core::get_logging_enabled() const' /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::aux::record_pump<boost::log::v2_mt_posix::sources::severity_logger_mt<boost::log::v2_mt_posix::trivial::severity_level> >::~record_pump()': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix3aux11record_pumpINS1_7sources18severity_logger_mtINS1_7trivial14severity_levelEEEED2Ev[_ZN5boost3log11v2_mt_posix3aux11record_pumpINS1_7sources18severity_logger_mtINS1_7trivial14severity_levelEEEED5Ev]+0x4b): undefined reference to `boost::log::v2_mt_posix::aux::unhandled_exception_count()' [...] I also tried to omit -DBOOST_ALL_DYN_LINK, add -static instead or use clang++ instead of g++. I also tried to shuffle the order of -l ... All gives the same error. Build machine is a Ubuntu 16.04.4 , g++ 5.4.0. What could be wrong? Thanks, Florian

2 1

Re: [boost] [gsoc17]The implement of Programming competency test From Ruoyun Jing
by Ruoyun Jing 28 Mar '17

28 Mar '17

Hi Adam and Vissarion, During these days I discussed the ideas of project 1 and begin to write my proposal. Here are what I learn about these project. 1.For the approach of compute the 3D cartesian distances first and if these numbers are not "far enough" then fall back to expensive geographic distance calculation otherwise return the result by comparing those numbers obtained by less expensive cartesian compuation. The main problems is declare the "far enough". To figure out this problem, I would implement the method, test the result between function compare_distance and this method, then adjust parameter to limit deviation in an acceptable range(maybe it would be 1e-6 correapongs, the accurate value should be discussed by specific condition) 2.For the approach of perform a local spheroid approximation and return the 2D distance. The main problem is to test the acceptable range of using spheroid approximation. The solution is same as answer above. 3.For the approach of getting 2 intersections of plane (which would be ellipse) with the help given points and compute the respective distances using those ellipses. In my understand of these approach, it means we need to get cross-section through the center of ellipsoid and the geodesic segments. But I am not sure that the geodesic segments of two points whether can get a cross-section through the center of ellipsoid, and whether the cross-section is ellipse that we can calculate the sectorial area easy to compare. After check out the geodesic knowledge from differential geometry for a long time. I got some prove, but I think it isn't very reliable. 4.I have an reliable approach is that we could use the algorithms in "map projection" just like Lambert Conformal Conic, Gauss–Krüger projection, Mercator projection...etc, Those projections make the point on 3D to 2D with reliable functions, although most of these projections use longitude and latitude, we could transform our cartisian coordinate into Spherical coordinate then transform them into longitude and latitude then use the projection to approximately calculate. All of above is what I discussed during these days, Could you please provide me some advise about them so I can strenthen my proposal?And if there has any problems about my poor English description please tell me, I will try my best to explain more clearly:) Thanks all for your reading! Looking forward from you.:) Ruoyun -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

2 3

My Proposal for GSoC
by Mukund Chandra 28 Mar '17

28 Mar '17

Dear Sir, I want you to review the draft of my proposal and suggest me what I should do so that I can work with this project. The project is Project 1 for Boost.Geometry about filtering of compare distance predicates. Here is the link for my Proposal Draft : https://github.com/MukundChandra/Programs-For-GSoC/blob/MukundChandra-patch…

2 1

[gsoc2017] Applying for Boost.Geometry Project 1
by NowhereMan 28 Mar '17

28 Mar '17

Hello, I wish to pursue a path in GSOC 2017 with boost, specifically Project 1 which involves optimization of compare distance predicates. My name is Cody Glassman, a first-year student at my local Community College in Southern California, on a path to obtaining my BS in Computer Science from the University of California system. I am currently working hard developing a concise, yet thorough competency test and am hoping to establish contact with a mentor. Thank you! Cody -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc2017-Applying-for-Boost-Geometry-Pro… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

small_vector alignment
by Tobias Loew 28 Mar '17

28 Mar '17

Hi, I wanted to use a boost::container::small_vector for 64-bit aligned doubles (to be used with SSE): But it seems that the "small-buffer" has a fixed calculated alignment which only depends on the value-type and does not consider the alignment of the (dynamic) allocator. Is this intended or is it a bug in the implementation? best regards Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/small-vector-alignment-tp4692694.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[geometry] Documentation garbage (Re: [Boost-announce] [release] Boost 1.64.0 Beta 1)
by Mateusz Loskot 28 Mar '17

28 Mar '17

On 23 March 2017 at 15:11, Rene Rivera <boost(a)lists.boost.org> wrote: > Boost release 1.64.0 beta 1 is now available at: > [...] > Please download the beta, give it a try, and report any problems you > encounter. I noticed, the package consists of intermediate files from docs generation process of Boost.Geometry: /libs/geometry/doc/doxy/doxygen_output/html_by_doxygen /libs/geometry/doc/doxy/doxygen_output/xml May I ask how documentation of individual library makes it into the package? /libs/geometry/doc/Jamfile.v2 calls our custom make_qbk.py script which is known to not to do any post-generation clean-ups of intermediate files. Shall we add such cleanup to make_qbk.py or it is not relevant for release process? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[gsoc17]Dynamic Shortest Path Computation
by A.I 28 Mar '17

28 Mar '17

Hi, everyone, I am Donghyuk Kim, a Ph.D. Student at KAIST(Korea Advanced Institute of Science and Technology) in South Korea. I've been studying motion/path planning algorithm and I'd like to contribute to a specific algorithm, "Dynamic Shortest Path Computation" in Boost graph library as a google summer code project. It is a tree-based data structure for maintaining single-source to all destination shortest path. It is also known that it outperforms the recomputation of Dijkstra or A* where insertion and deletion of vertex/edge can frequently happen. Here you can check my brief CV including educational/programming background and my interests. https://www.linkedin.com/in/donghyuk-kim-54223355/ Most of my source codes (research/project-purpose things) are in a private repository by our policy, for this reason, the only thing I can share is the below one: https://github.com/aidyk/SGMP The concept of "Dynamic Shortest Path Computation" was originally introduced in [Fully Dynamic Algorithms for Maintaining Shortest Paths Trees] by D. Frigioni, et al. (http://dl.acm.org/citation.cfm?id=338900) I've already implemented a prototype for my research, but testing, coding style unification and much more c++ style modification are required for general purpose. I hope someone find it interesting and be a mentor in this journey. Thanks in advance! Best Regards, Donghyuk Kim a.i(a)acm.org -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-Dynamic-Shortest-Path-Computation… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

GSOC Project
by Umar Ali 28 Mar '17

28 Mar '17

I am a Computer Science student trying to apply with MariaDB in GSOC. I have a basic knowledge of SQL and a deeper understanding of C++, and was wondering whether I would have to come up with a project idea inorder to file a proposal or can i submit a proposal inorder to learn without any deeper understanding of programming languages

3 2

[review queue] Beast Review Date - Request
by Michael Caisse 28 Mar '17

28 Mar '17

Hello Wizards! We would like to schedule the Beast review (already in the queue) for the week of July 1 - July 8. Thanks! michhael -- Michael Caisse Ciere Consulting ciere.com

2 1

[release] Boost 1.64.0 Beta 1
by Rene Rivera 27 Mar '17

27 Mar '17

Boost release 1.64.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/source/> The SHA256 checksums are as follows: 8f0ba6b73fad15115049f9b3e7e27eae43be10a94b51a57142f3a27e55ef4beb boost_1_64_0_b1.7z b5c5abf127a3f723dafcc7cf55876c1bda9f014fb1b117f6a7f769e3cc407c4f boost_1_64_0_b1.tar.bz2 a7fe98a9a9f615f6fa68d8ea09ce725d19e3a4fe4719c21c9db29dff88b3b6e3 boost_1_64_0_b1.tar.gz 593005661af8dfe132b2b16bc2cd41339e6acd58456913f353d765090d7868f7 boost_1_64_0_b1.zip For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

11 26

Going insane trying to build boost for android
by Robert Dailey 26 Mar '17

26 Mar '17

How many months has it been of lost google searching, trying to beat b2 into submission. I have no idea at this point how to build boost for Android. Really hoping I get some help here... So to start, here are the versions I'm using: - Android NDK r14b - Boost 1.63.0 I'm doing all of this on Windows 10, through command prompt. I want to use clang and libc++ to build boost for API 15. I figure the easiest way is to generate a standalone toolchain using the NDK, so I did that first: > %ANDROID_NDK%\build\tools\make_standalone_toolchain.py --arch arm --api 15 --stl libc++ "C:\android\_toolchains\arm-api-15" This generated the appropriate toolchain (I think). I then temporarily added this location to PATH: > set PATH=C:\android\_toolchains\arm-api-15\bin;%PATH% Then I ran bootstrap: > bootstrap.bat --with-toolset=clang Then I tried to build boost itself: > b2 --toolset=clang cxxflags="-stdlib=libc++ -std=c++14" threadapi=pthread --prefix=..\boost_android_arm --builddir=./ target-os=linux define=BOOST_FILESYSTEM_VERSION=3 --without-python link=static runtime-link=shared threading=multi variant=release install -j8 However I get failures when it tries to run the clang command: 'C:\code\_third_party\boost_1_63_0\\clang38++.exe' is not recognized as an internal or external command I'm not sure why it's appending that absolute path (that's where my current directory is set to, and where boost source is). It should just be trying to use "clang++" but doesn't look like it is. >From the output, it looks like it's trying to use clang correctly I think: "clang++" -c -x c++ -stdlib=libc++ -std=c++14 -O3 -Wno-inline -Wall -pthread -stdlib=libc++ -std=c++14 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG -I"." -o "bin.v2\libs\wave\build\clang-linux-android\release\link-static\target-os-linux\threadapi-pthread\threading-multi\cpplexer\re2clex\aq.o" "libs\wave\src\cpplexer\re2clex\aq.cpp" Am I going about this all wrong? How in the heck can I build boost for android using the settings I specified above?

2 4

[SIMD] Pre-review questions
by Artyom Beilis 26 Mar '17

26 Mar '17

Hello, I have several questions regarding Boost.SIMD (for pre-review) 1. What is boost::simd::pack::storage_type I can't find it in documentation. Is it the "native register" like __m128i for pack<int,4>? If the answer is no, how do I get access to underlying type? 2. I can't find in documentation how to performs casts between different types: I see in docs split_low (actually after I grepped for _mm_unpacklo) but I failed to find how to use one - there is no documentation regarding conversion/casting operation or at least I failed to find one. 3. Is there more convenient way to perform basic saturated operation for example if I want to calc abs diff of two bs::pack<unsigned char,16> values a,b I need to write bs::saturated_(be::minus)(a,b) + bs::saturated_(bs::minus)(b,a) It is quite inconvenient especially when most of operations you want to do are saturated. 4. Why Boost.SIMD is restricted to C++11? Most of the stuff is implementable withing C++2003, it severely limits the usability of the library for existing projects that can't trivially switch to new C++ standard (and there are too many in the "real world" industry) Thanks, Artyom

2 3

Boost Logo usage questions
by Antony Polukhin 26 Mar '17

26 Mar '17

Hello, What are the rules for the Boost logo usage? Can I use the Boost logo on a cover of the Boost related book ? What are the permissions for the library logos (for example https://github.com/boostorg/test/blob/develop/doc/html/images/boost.test.lo… )? -- Best regards, Antony Polukhin

1 0

[asio]ssl::detail::stream_core is accessed after destruction
by Takatoshi Kondo 26 Mar '17

26 Mar '17

Hello, I'm using Boost.Asio. I compiled some TLS client with clang address sanitizer. (I attached the result the last part of this mail.) It indicates that the following `expires_at` member function calling is bad: https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… So I insert debug print "stream_core() address" to the constructor of ssl::detail::stream_core https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… "~stream_core() address" to the destructor, https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… and "io stream_core address of core_" to `expires_at` calling point: https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… And then, I got the following result: stream_core() 0x6120012beb60 constructor ~stream_core() 0x6120012ca6e0 connected. previous session = false stream_core() 0x6120012ba060 ~stream_core() 0x6120012beb60 destructor io stream_core 0x6120012beb60 call Is seems that `expires_at` at https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… is called after core_ 's destructor is called. The problem happens a part of big project. The client connects to the server as TLS-stream, then server shutdown the stream, then client connects again. The program does the sequence repeatedly. The error happens the client side. I'm trying to write a minimal and complete code that reproduces the problem, but not yet. So I report the result only as the first report. The result of clang address sanitizer ---------------------------------------------------------------------------------- SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/boost/asio/basic_deadline_timer.hpp:344:27 in boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::expires_at(boost::posix_time::ptime const&) Shadow bytes around the buggy address: 0x0c248024fd20: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x0c248024fd30: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c248024fd40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c248024fd50: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x0c248024fd60: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd =>0x0c248024fd70: fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd 0x0c248024fd80: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0c248024fd90: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c248024fda0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c248024fdb0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa 0x0c248024fdc0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11437==ABORTING ---------------------------------------------------------------------------------- heap use after free occurs the following code: ---------------------------------------------------------------------------------- ==11437==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120012bebb0 at pc 0x000000749b30 bp 0x7ffccc310470 sp 0x7ffccc310468 READ of size 8 at 0x6120012bebb0 thread T0 #0 0x749b2f in boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::expires_at(boost::posix_time::ptime const&) /usr/include/boost/asio/basic_deadline_timer.hpp:344:27 #1 0x748e21 in boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::write_op<boost::asio::mutable_buffers_1>, boost::asio::detail::write_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, mqtt::endpoint<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::io_service::strand, std::mutex, std::lock_guard>::write_completion_handler, boost::asio::detail::is_continuation_if_running> > >::operator()(boost::system::error_code, unsigned long, int) /usr/include/boost/asio/ssl/detail/io.hpp:260:32 #2 0x7590e7 in boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >,boost::asio::ssl::detail::write_op<boost::asio::mutable_buffers_1>, boost::asio::detail::write_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, mqtt::endpoint<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::io_service::strand, std::mutex, std::lock_guard>::write_completion_handler, boost::asio::detail::is_continuation_if_running> > > >::operator()(boost::system::error_code const&, unsigned long, int) /usr/include/boost/asio/impl/write.hpp:269:9 Thanks, Takatoshi Kondo

1 0

Re: [boost] Formal Review Request: mp11
by Bjorn Reese 25 Mar '17

25 Mar '17

On 03/17/2017 03:06 PM, Peter Dimov via Boost wrote: > https://github.com/pdimov/mp11/ A few comments... Most algorithms take the typelist as the first argument, but others do not, e.g. mp_transform<F, L...>. If possible, I would like to see all algorithms take typelist as the first argument. It looks like the current order is dictated by the requirements of mp_tranform_impl. Would it be possible to swap the types where the algorithm is declared? For example: template<class L, template<class...> class F> using mp_transform = typename detail::mp_transform_impl<F, L>::type; Apropos mp_transform, would it be possible to extend it such that we can pass a type-trait directly to it? For example: using const_list = mp_transform<std::add_const, typelist>; instead of using std::add_const_t. The reason I ask is that I have lots of my own domain-specific type-traits that does not come with a _t version, so this is mainly for convenience. The reference documentation is a bit terse and obscure. For example, the documentation for mp_find tells us in a convoluted way that it returns the index of a type in a typelist. It could also mention that it is the dual algorithm to mp_at, which returns a type at an index in a typelist.

3 9

I want to hire you to write some docs!
by Vinnie Falco 25 Mar '17

25 Mar '17

I'm interested in hiring someone for a contract to finish up the NuDB documentation (repository is here: https://github.com/vinniefalco/NuDB) Its not a tremendous amount of work but I don't want to shift gears from Beast, and this could be a launching point for future doc work. Feel free to reach out to my email, its listed on my GitHub page (https://github.com/vinniefalco) Thanks!!!

1 0

[stacktrace] Review
by Bjorn Reese 25 Mar '17

25 Mar '17

I vote for the unconditional acceptance of Boost.Stacktrace. The design is sound. The separation of stacktrace and frame is just right, and safe_dump_to is an elegant solution to handle async-safety (much better than the fork-exec alternative.) The implementation (I did not look at the Windows parts) looks solid. There are details that looks platform-specific -- e.g. "/proc/self/exe" in detail/addr2line_impls.hpp is not Posix -- but I did not notice anything that cannot be ported if needed. The documentation is well-structured. I appreciate that the reference documentation contains both complexity and async-handler-safety comments. This library is very useful to developers. I spent a couple of hours going through the documentation and source for the review. Prior to that I have followed the development of this library, and used an earlier version in a commercial product. I have in-depth knowledge of the Posix side (having once implemented an async-safe stacktrace.) Wishlist: Make throw_with_trace of the API. Put it in a separate header so there is no dependency on Boost.Exception unless this header is included. In order to be consistent with Boost.Exception I suggest that the throwing function is called stacktrace::throw_exception(). Add an example with basic_stacktrace that uses a custom allocator. Add a simpler example that uses std::terminate(). The current one is rather overwhelming. Notice that I am not asking for the current example to be removed. Minor comments: Add a note to Getting Started that the stored backtrace.dump only is valid if the program has not be re-compiled between runs, as this is what developers do all the time. I have no opinion about windows.h.

1 0

[stacktrace] library review
by Artyom Beilis 25 Mar '17

25 Mar '17

Hello, There is my review. Note: I reviewed the library in previous round and voted no. So the current review was mostly review of the problems I found. - What is your evaluation of the design? The design is solid and minimalist as it suppose to be for such a library. Good separation for different backends. I still lack the out of the box "throw exception with stacktrace"/catch and print trace as I written in previous review but I don't think it is show stopper. i.e. "throw_with_trace" as shown in examples should be part of the library as it is one of most useful features. - What is your evaluation of the implementation? The implementation is OK but there are several issues (mostly in backend) I need to point out: I used this trivial program for run time testing #include <boost/stacktrace.hpp> #include <iostream> void foo() { std::cout << boost::stacktrace::stacktrace() << std::endl; } void bar() { foo(); } int main() { bar(); } Addr2Line Backend: --------------------------- In order to get the stacktrace the addr2line is called for each frame - i.e. stack of 4 functions results in 4(!!!) forks need to be fixed This is sample of stace output for trivial example, it can be reduced to 2 fork/exec at most [pid 7985] execve("/usr/bin/addr2line", ["addr2line", "-Cpe", "./a.out", "0x000000000040AFC2"], [/* 75 vars */]) = 0 [pid 7986] execve("/usr/bin/addr2line", ["addr2line", "-Cpe", "./a.out", "0x000000000040B02D"], [/* 75 vars */]) = 0 [pid 7987] execve("/usr/bin/addr2line", ["addr2line", "-Cpe", "./a.out", "0x000000000040B039"], [/* 75 vars */]) = 0 [pid 7988] execve("/usr/bin/addr2line", ["addr2line", "-Cpe", "/lib/x86_64-linux-gnu/libc.so.6", "0x00007EFD582A6830"], [/* 75 vars */]) = 0 [pid 7989] execve("/usr/bin/addr2line", ["addr2line", "-Cpe", "./a.out", "0x000000000040AEB9"], [/* 75 vars */]) = 0 This is something easy to fix and I expect it to be fixed before library is delivered to the official release. Libbacktrace Backend: ------------------------------ Linux: using libbacktrace without debug information results core dump - seems, the dump happens in ::backtrace_pcinfo happens for both g++ 4.8 and 5.4 Please make sure you can workaround this problem. This MUST be fixed. Windows/MinGW I build libbacktrace for mingw (tested it to make sure I can get traces using its API) However when I used boost.stacktrace with libbacktrace the program crashed every time in any configuration I used (with or without debug information) it worked with default build (without) but its usability is limited. This MUST be fixed (or if impossible mark as libbacktrace unusable for MINGW32) OS Support FreeBSD ------------------------------- FreeBSD - 100% unusable at this point - also I must say for FreeBSD it may be tricky due to : I needed to do some changes in CppCMS's backtrace library recently due to shift of latest freebsd to clang Take a look: https://github.com/artyom-beilis/cppcms/commit/18c3f05bfa9e4008aeac39322e8a… https://github.com/artyom-beilis/cppcms/blob/master/booster/lib/backtrace/s… It also may say that you WILL have problems with Mac OS X. $ c++ -v FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: x86_64-unknown-freebsd11.0 Thread model: posix InstalledDir: /usr/bin $ uname -a FreeBSD freebsd11 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ c++ -I ../boost_stacktrace/include/ -I ../boost_1_63_0/ -Wall -O0 -g st.cpp In file included from st.cpp:1: In file included from ../boost_stacktrace/include/boost/stacktrace.hpp:15: In file included from ../boost_stacktrace/include/boost/stacktrace/frame.hpp:205: In file included from ../boost_stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:36: ../boost_stacktrace/include/boost/stacktrace/detail/safe_dump_posix.ipp:36:63: error: use of undeclared identifier 'S_IFREG' const int fd = ::open(file, O_CREAT | O_WRONLY | O_TRUNC, S_IFREG | S_IWUSR | S_IRUSR); ^ ../boost_stacktrace/include/boost/stacktrace/detail/safe_dump_posix.ipp:36:73: error: use of undeclared identifier 'S_IWUSR' const int fd = ::open(file, O_CREAT | O_WRONLY | O_TRUNC, S_IFREG | S_IWUSR | S_IRUSR); ^ ../boost_stacktrace/include/boost/stacktrace/detail/safe_dump_posix.ipp:36:83: error: use of undeclared identifier 'S_IRUSR' const int fd = ::open(file, O_CREAT | O_WRONLY | O_TRUNC, S_IFREG | S_IWUSR | S_IRUSR); ^ In file included from st.cpp:1: In file included from ../boost_stacktrace/include/boost/stacktrace.hpp:15: In file included from ../boost_stacktrace/include/boost/stacktrace/frame.hpp:205: ../boost_stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:75:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ st.cpp:3:14: warning: treating Unicode character as whitespace [-Wunicode-whitespace] void foo() { std::cout << boost::stacktrace::stacktrace() << std::endl; } ^ st.cpp:3:17: warning: treating Unicode character as whitespace [-Wunicode-whitespace] void foo() { std::cout << boost::stacktrace::stacktrace() << std::endl; } ^ st.cpp:4:14: warning: treating Unicode character as whitespace [-Wunicode-whitespace] void bar() { foo(); } ^ 3 warnings and 4 errors generated. I have another suggestion regarding testing. I didn't run them but since you didn't catch crash with libbacktrace without debug mode you probably have all compiled with debug information I suggest to modify the set of tests that you run on entire matrix: {backend}x{debug mode on/off/external PDB/debug information}x{rdynamic on/off} - What is your evaluation of the documentation? Documentation is fairly good - What is your evaluation of the potential usefulness of the library? VERY useful one the bugs are fixed. - Did you try to use the library? With what compiler? Yes: I tested on Linux gcc 5.4/4.8/clang++ Windows MinGW 5.x; FreeBSD clang 3.8 > Did you have any problems? Lots - see notes above. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Several hours running code reading backeds code. - Are you knowledgeable about the problem domain? Yes I had written one for CppCMS that runs on many platforms. And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Yes, Subject to: - Fix of build/run issues on all major platforms including MINGW and FreeBSD - it was too easy to find issues I really concerns me - it is show stopper for the library to be released as part of boost. - FIx crashes with libbacktrace - Fix of addr2line performance - no need to fork/exec for each frame Note: I understand that it is hard for the author to fix all stuff on all platforms - but stacktrace by definition is doing something non portable in portable way. Best Regards, Artyom Beilis

1 0

Boost MSM parallel behavior with delayed self-transitions?
by Christophe Henry 24 Mar '17

24 Mar '17

Hi Danylo, >Hi Christophe, > >Thanks for your input. I'm going to use std::thread for the parallel >functionality, I think. it will work with synchronization. For simple cases it's manageable. >How stable/complete is Asynchronous? Can I rely on >it, or would I still have a moderate chance of running into bugs? It's very stable and used intensively in production code (in the industry) since 2 years. You might find some bug of course, but no stability problem has been found since a long time. > >Best, > >Danylo. > >PS. I love your documentation! What do you use for state machine diagrams - >MagicDraw? Enterprise Architect. Regards, Christophe

2 4

[Stacktrace] - review comments
by mbartosik 24 Mar '17

24 Mar '17

There are a few major uses of a stack trace library which have differing needs. 1) Fast signal-safe gathering of the stack frames the current thread (something that can run in either a Windows VectoredExceptionHandler or a unix Signal handler). 2) Gather of the stack frames for an exception in the current thread. 3) Gathering of stack frames for the current thread even if it means remote loading of symbol files. 4) Gathering of the stack frames for a paused thread (could even be in a different process). 5) Resolving symbols which is a VERY heavy weight task, potentially resolving symbols long after the target process for which the stack trace was made has exited. e.g. deserializing a stack trace from a log file and creating an annotated version with symbols added. In the case where I what to gather a stack trace for the current thread while handing a seg-fault or first-chance exception call I want to gather a code pointer for each stack frame efficiently (meaning no more than one pointer per frame, and no unnecessary calls or remote symbol loads) I believe that the library does address this, however, I am unsure of whether it can be requested to be more or less aggressive in what it does to walk the stack of highly optimized code, for example, in the most aggressive case it could cause symbols to be remotely downloaded from a webserver (e.g. http://msdl.microsoft.com/download/symbols) to download Microsoft .PDB files which contain information necessary to walk the stack of highly optimized code. I would like to see some control over how aggressive it is in walking the stack. On x86 the least aggressive would be walking the ESP / EBP+retaddr singly linked chain, the most aggressive would be to remote download .PDB files and use one of the Microsoft APIs to do the walking. I am unsure that it can gather a stack trace from a different thread. This is admittedly a less common case, and possibly not worth holding up the library for, although it would be good to hear how the author thinks such a library interface would look. Is there / should there be, any control over what is included in the frame to_string() e.g. should all arguments be included, should full path of source file be included? If so how is this to be controlled? If not then should what going in there be documented? Now for the major issue. I asked earlier at what point does symbol resolution happen, and I was told it is on-demand and that the storage per frame is a single pointer, implying that there is no caching. Since resolving symbols is very very expensive it is desirable to have caching of function/frame names. I can certainly image a developer streaming a frame to the a log file multiple times and then being surprised when his/her program slows down orders of magnitude. Caching of frame names is contrary to the idea of having just one pointer stored per frame. This makes me wonder if the underlying OS or library calls provide sufficient caching to avoid the cost of a second call to boost::stacktrace::frame::to_string being too great? Resolving of the symbols requires not just an absolute address, but if symbols are to be resolved 'after exit'/post mortem by another process it requires the RVA (relative virtual address) and the module for code (e.g. path to shared library / dll, etc.) This can be deduced from the absolute virtual address in the process, plus the module load address (which maybe different each time the module loads). What I would like to see is the ability to have an efficient stack trace object that requires only one pointer per frame. Plus something that is able to resolve symbols,* including post-mortem after a process has exited*. These two goals I think result in multiple classes. A light weight stacktrace class, in here to_string() would yield a pointer value. A symbolic_stacktrace class, in here to_string() would yield a human readable symbol resolved string. For the case of creating a symbolic_stacktrace from a serialized stacktrace post-mortem a module_list would also be required, in the case that the same process is used a symbolic_stacktrace would be creatable only from a stacktrace. Whether boost::stacktrace::frame stores a void * or a function pointer is a little interesting -- as technically the pointers are not function pointers but usually code pointers as they do not point to the beginning on a function. Having said all this, the current design does cover a simple case. Summary: * Control of how aggressive stack walking is. * Ability to walk stack of another thread including in another process. * boost::stacktrace::frame::to_string should be efficient for 2nd and 3rd and multiple calls, but not require more than a single pointer to be stored in the boost::stacktrace::frame. This implies either a different class for symbol resolution or external caching. * Control over what boost::stacktrace::frame::to_string includes (or define it). * Ability to work with post-mortem data. e.g. serialize a boost::stacktrace plus other information (a list of modules) and then deserialize and resolve symbols after the process has exited. * Work with boost serialization - Mark -- View this message in context: http://boost.2283326.n4.nabble.com/Stacktrace-review-comments-tp4692904.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Using clang 4.0.0 with b2/bjam fails missing cstddef in boost/config/select_stdlib_config.hpp
by Paul A. Bristow 24 Mar '17

24 Mar '17

I have installed the shiny new Clang at c:\llvm\ with MS Visual Studio 2015 update 3 I have added Clang to my user-config.jam thus using clang ; or in full detail: using clang : # version 4.0.0 : # location Clang compiler .exe location. # from http://llvm.org/releases/download.html dated 9Mar2017 c:\\LLVM\\bin\\clang++.exe : # options <warnings>on <cxxflags>-v ; and tried to invoke it thus I:\modular-boost\libs\hello_boost\example>b2 toolset=clang-4.0.0 -d2 --debug-configuration > clang40_24Mar17.log (.log file attached in case that helps). It starts well but comes to a terminal halt missing cstddef in boost/config/select_stdlib_config.hpp clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: c:\LLVM\bin "c:\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file "I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\ \debug\\hello_boost.gcno" -resource-dir "c:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -internal-isystem "c:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wno-unused-local-typedef -Wno-dll-attribute-on-redeclaration -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility -fms-compatibility-version=19.0.24123 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc #include "..." search starts here: #include <...> search starts here: ..\..\.. c:\LLVM\bin\..\lib\clang\4.0.0\include C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt End of search list. In file included from hello_boost.cpp:15: In file included from ..\..\..\boost/config.hpp:44: ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef> I have two versions of cstddef C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstddef exists and refers to other files. contains // cstddef standard header #pragma once #ifndef _CSTDDEF_ #define _CSTDDEF_ #include <yvals.h> and another at C:\programfiles\mingw-w64\x86_64-6.3.0-win32-seh-rt_v5-rev1\mingw64\lib\gcc\x86_64-w64-mingw32\6.3.0\include\c++; My PATH has (amongst other items) C:\Programfiles\mingw-w64\x86_64-6.3.0-win32-seh-rt_v5-rev1\mingw64\bin; C:\programfiles\mingw-w64\x86_64-6.3.0-win32-seh-rt_v5-rev1\mingw64\lib\gcc\x86_64-w64-mingw32\6.3.0\include; C:\programfiles\mingw-w64\x86_64-6.3.0-win32-seh-rt_v5-rev1\mingw64\lib\gcc\x86_64-w64-mingw32\6.3.0\include\c++; C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include; Is this expected (rather than clang-msvc-14.0)? notice: will use 'clang++' for clang-linux, condition <toolset>clang-linux-4.0.0 Anyone can give a clue as to what I am doing wrong? Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

[build] VC++ 2017 version number?
by Beman Dawes 24 Mar '17

24 Mar '17

Boost.build in develop is treating VC++2017 RTW (aka RTM) as msvc-14.1. Yet the Visual Studio 2017 RTW Help "About Microsoft Visual Studio" shows the version as "15.0.0-RTW+26228.4" Shouldn't boost.build follow Microsoft's numbering? Seems like calling 2017 RTW anything except 15.0 is a recipe for confusion. --Beman

12 15

Re: [boost] Constructing string_ref from rvalue string
by Mathias Gaunard 24 Mar '17

24 Mar '17

On 23 Mar 2017 7:02 am, "Jonathan Müller via Boost" <boost(a)lists.boost.org> wrote: I've just blogged about this topic: http://foonathan.net/blog/2017 /03/22/string_view-temporary.html (Planned that post before this thread) In my opinion I think `boost::string_ref` and `std::string_view` are two different things, They're not. They were always supposed to be the same thing. There is a lot of code out there that uses std::string_view and boost::string_ref interchangeably depending on which is available.

3 2

Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
by Glen Fernandes 24 Mar '17

24 Mar '17

peterkochlarsen wrote: > Also an unmaintained library should be marked as such as should > libraries that are deprecated, replaced by standard C++ features > (shared_ptr comes to mind) shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated. It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17. (Interesting aside: That functionality above was even, and still is used, in certain Microsoft projects, where boost::shared_ptr is used instead of std::shared_ptr). The same goes for other Boost libraries like Boost.Thread. They: - May have features not in the C++ standard library equivalent - May be evolving past the current C++ standard - Are in use by actual projects and shouldn't be removed Glen -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-librar… Sent from the Boost - Dev mailing list archive at Nabble.com.

15 51

Is there any interest in type-safe container of bool flags with noexcept guarantees?
by Роман Орлов 23 Mar '17

23 Mar '17

Hello Boost community, I'd like to determine interest in this kind of container. Motivation For managing sets of bool flags developers often use std::bitset or c-like manual bit manipulations. Each approach brings problems. Some disadvantages of using std::bitset: * unpredictable and greedy allocation of bit storage; * setters/getters can throw exceptions; * it operates in low-level terms like "a bit number"; * we can easily assign one instance of std::bitset to another with the same number of bits but semantically they may differ. Proposal Instead of managing bits via numbers let's manage them via types. So start by declaring some types class eats_meat; class eats_grass; class has_tail; Then bind these types to flag identifiers typedef typed_flags<eats_meat, eats_grass, has_tail> animal; Unlike std::bitset the 'animal' instance allocates a minimal possible storage (in this case sizeof(animal) == 1). Create flags from scratch animal wolf; wolf.set<eats_grass>(false); wolf.set<eats_meat, has_tail>(); wolf.set(flag<has_tail>{1}, flag<eats_meat>{1}); Create flags with a flexible human-readable constructor wolf = animal{flag<has_tail>{1}, flag<eats_meat>{1}, flag<eats_grass>{0}}; I have implemented a minimal working prototype in my github repo https://github.com/compmaniak/typed_flags If you're interested you can try it online here http://melpon.org/wandbox/permlink/55g1czUjwSFO8LS1 Expected benefits * delegating calculation of a bit position for a certain type to compiler gives us a strong type safety and prevents typos; * noexcept guarantee of setting and getting bit values; * we shouldn't take care of bits because we work in terms of typed properties; * great readability, taking a short glance on a type definition tells you what this type is about. Some people on reddit (https://redd.it/601upg) found this library useful. Any thoughts on the idea of the container would be much appreciated. -- Roman

8 13

[release] 1.64.0 please test master snapshot
by Rene Rivera 23 Mar '17

23 Mar '17

Looks like 14.1/141 won out the version hysterics. And I've merged in the PRs for that change. Please give the latest master snapshot archives a try. And report both failures and success: <https://dl.bintray.com/boostorg/master/> If nothing Earth shattering comes up this will become the beta on Wednesday 22 (before 24:00 CDT). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 5

Re: [boost] [release] 1.64.0 please test master snapshot
by Rene Rivera 22 Mar '17

22 Mar '17

On Tue, Mar 21, 2017 at 12:36 PM, Tom Kent <lists(a)teeks99.com> wrote: > It looks like the boostorg/boost:master commit this snapshot was based off > doesn't have the latest boostorg/config:master submodule commit. I think > updating this is a manual process at this point in the release cycle? (Thus > the autolink file is still looking for vc150). > Grr.. Forgot to do that for config. I did it for build though :-) It's done now.. Just need to wait again for the new archives. > As an aside, I had a difficult time figuring out what the snapshot I > downloaded referred to. I was able to use the boost_1_64_0_snapshot.tar.bz2.json > file to determine that I had the correct boost_1_64_0_snapshot.tar.bz2, but > bintray doesn't make it super clear what git commit this snapshot download > refers to. > > Would it be possible to add a file to snapshots/releases that contains the > git commit hash? > Can't promise I'll do it right this second... But I'll add the commit hash to the json data for the archives. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

7 14

Boost MSM parallel behavior with delayed self-transitions?
by Christophe Henry 22 Mar '17

22 Mar '17

Hi Danylo, >Hi community, > > I am using Boost MSM (basic and functor front-ends) and am trying to >implement the following state machine (https://i.stack.imgur.com/K79qk.png ): Ok, State1 is itself a state machine (also called composite). See: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch02s02.html#d0e151 and: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch03s02.html#d0e529 Then you have 2 active states, which are called orthogonal regions. See: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch03s02.html#d0e577 >I am using Boost MSM (basic and functor front-ends) and am trying to >implement the following state machine: enter image description here > >In words: < snip > > >I would like to know the way to create this state machine in Boost MSM. The above link has an example. >There are two tricks here which I cannot figure out how to do: > > - Execution in parallel (i.e. running action_A does not stop running >action_B at the same time) It depends what you mean with "in parallel". Having 2 active states means that the actions execute only logically at the same time, meaning within the same process_event call. But as you have just one thread, they will execute after each other. If you mean in different threads, then no, the library does not support this. But my next library, Asynchronous does ( https://github.com/henry-ch/asynchronous) I have examples with state machines, timer, etc. >- Delayed transition (i.e. the transitions which happen after 2 >seconds for state A and after 5 seconds for state B). Neither delay >should be blocking! The transitions should just "fire" after this time. Sorry, this is out of scope of the library as it would involve threads. You can do one of the following: - use your own timer (Boost.Asio offers one) and handle thread safety yourself. - have a look at Asynchronous. Sorry if it looks like advertising, but the library was written for this kind of things. >Thank you very much for helping, > >Danylo. HTH, Christophe

3 4

Re: [boost] [gsoc17] Project1: Static map: Can I implement the competency test in g++-7?
by Vic Luo 22 Mar '17

22 Mar '17

Hi, In the last few days I finished a toy implementation with continuous integration at https://github.com/htfy96/gsoc-static-map, which has been tested on g++5/6 and clang++3.8/3.9. Current test failure is as expected due to g++-5's incomplete constexpr optimization. Besides, my proposal draft has been submitted which includes a very tiny benchmark with boost::hana on compile-time lookup performance on map<int, int> structure. Any kind of suggestion is welcomed at https://gist.github.com/htfy96/0bd9b3200d9a0e67f449edc40bfa43b5*. * Thanks,* * -- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a

1 0

Re: [boost] [release] 1.64.0 please test master snapshot
by Olaf van der Spek 22 Mar '17

22 Mar '17

On Wed, Mar 22, 2017 at 12:45 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >> Right, boostorg doesn't have tickets enabled though.. where should I >> open a ticket? > > > Probably, in Trac: I hate Trac. > https://svn.boost.org/trac/boost/newticket?component=algorithm;version=Boos… > > Although since it's fixed in develop and there is a PR for merge to master, > I'm not sure there's much point in a ticket. I meant in general. -- Olaf

1 0

Re: [boost] [release] 1.64.0 please test master snapshot
by Andrey Semashev 22 Mar '17

22 Mar '17

And once again, this went to Olaf directly instead of the list. Re-sending. On 03/22/17 14:45, Andrey Semashev wrote: > On 03/22/17 13:45, Olaf van der Spek wrote: >> On Wed, Mar 22, 2017 at 11:05 AM, Andrey Semashev via Boost >> <boost(a)lists.boost.org> wrote: >>> On 03/22/17 11:59, Olaf van der Spek via Boost wrote: >>>> >>>> VC2015 /std:c++latest: >>>> >>>> struct to_lowerF : public std::unary_function<CharT, CharT> >>>> >>>> boost\algorithm\string\detail\case_conv.hpp(33): error C2143: syntax >>>> error: missing ',' before '<' >>> >>> >>> This seems to be fixed in develop but not merged to master. I've >>> created a >>> PR to do the merge: >>> >>> https://github.com/boostorg/algorithm/pull/34 >>> >>>> https://github.com/mclow/String-Algo/issues/7 >>> >>> >>> That ticket is for a fork, not the boostorg repo. >> >> Right, boostorg doesn't have tickets enabled though.. where should I >> open a ticket? > > Probably, in Trac: > > https://svn.boost.org/trac/boost/newticket?component=algorithm;version=Boos… > > > Although since it's fixed in develop and there is a PR for merge to > master, I'm not sure there's much point in a ticket. >

1 0

Re: [boost] GSoC proposal
by Vissarion Fisikopoulos 22 Mar '17

22 Mar '17

Hi Rasul, thanks for your interest in Boost.Geometry. I guess you have already read this https://svn.boost.org/trac/boost/wiki/SoC2017 There are two possibilities: either you provide a library (with some standards described in the webpage) or you do the test. My opinion is that doing the test (even if not needed) will first strengthen your application and second will give you a good overview of the problem you are going to work on, if selected. >From your repo what is the library that you propose for your application and meets the requirements described in the webpage above (e.g. no coursework, more than 6 months old etc)? The tests are described here: https://svn.boost.org/trac/boost/wiki/SoC2017#a3.Boost.Geometry Depending on what (?) project you prefer to pursue there is a corresponding test. Best, Vissarion ps. I copy the message to boost list so the community can follow and provide feedback if needed On 22 March 2017 at 12:00, Rasul Kerimov <rkerimov(a)std.qu.edu.az> wrote: > Hey Mr. Fysikopoulos, > > I'm really interested in Boost GSoC 2017 project proposal, but I don't > know how to pass Programming competency Test. > > I have a github repo with all my codes that I wrote in C++, but I > don't know if it's enough to pass test. > > Github page: https://github.com/CoderINusE/ > Github repo: https://github.com/CoderINusE/Algorithms-data-structues > > I will be grateful for any response. Thank you!

1 0

[release] 1.64.0 Delayed because of Microsoft (version numbers)
by Rene Rivera 21 Mar '17

21 Mar '17

Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame. To address the situation the beta release will be published when one of the two tasks below are completed: (A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with. Or: (B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means: 1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be. 2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least: <https://github.com/boostorg/config> <https://github.com/boostorg/build> <https://github.com/boostorg/boost> <https://github.com/boostorg/website> People have until 17:00 CDT Monday March 20 to submit those PRs. 3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20. 4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

17 26

[stacktrace] Review
by Peter Dimov 21 Mar '17

21 Mar '17

I think that the Stacktrace library should be ACCEPTED. The design is good. It's unfortunate that to get a stacktrace class that stores the capture internally in a fixed-size array, as the first iteration did, one has to write a special allocator, more so because such an allocator isn't readily available (we don't have one in Boost, for instance). This could easily be addressed by templating basic_stacktrace on a container (default std::vector<frame>) instead, which would allow boost::container::static_vector to be used. The implementation is good. The main problem here, as already discussed in detail, is that under Windows clients of the library that don't make use of the facilities that require windows.h and COM headers to be included still suffer the penalty of this inclusion. Fixing this will be a significant increase in usability. The documentation is adequate, although it could use some editing by a native speaker. The library is potentially very useful. Assert handlers, exceptions and termination handlers can (and should) all make use of it. Wide use under Windows is however hampered by the limitation described above. I tested the library under Windows with msvc-14.0, 14.1, Cygwin g++/clang++. Under Cygwin there is no libbacktrace, but defining BOOST_STACKTRACE_USE_ADDR2LINE worked. I invested a fair chunk of time into my evaluation of the library, and am reasonably knowledgeable about the problem domain.

1 0

Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter?
by Andrey Davydov 21 Mar '17

21 Mar '17

On Tue, Mar 21, 2017 at 4:11 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: > On 03/21/17 14:54, Andrey Davydov wrote: > >> On Tue, Mar 21, 2017 at 2:15 PM, Andrey Semashev via Boost >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On 03/21/17 12:54, Andrey Davydov via Boost wrote: >> >> On Tue, Mar 21, 2017 at 12:00 PM, Richard Hodges >> <hodges.r(a)gmail.com <mailto:hodges.r@gmail.com>> wrote: >> >> What is required, more than simply creating a type-erased >> deleter? >> >> >> Also deleter must capture pointer, because pointer which was >> passed to >> constructor can differ from the pointer which will be deleted. >> For example, >> >> struct Base { /* ... */ }; >> struct Derived : Base { /* ... */ }; >> >> ptr<Derived> p1(new Derived); >> void * raw_p1 = p1.get(); >> ptr<Base> p2 = std::move(p1); >> void * raw_p2 = p2.get(); >> assert(raw_p1 != raw_p2); >> >> >> The above piece of code strikes me as very unsafe and better be >> avoided in the first place. Designing new tools to handle this case >> is IMHO misguided. >> >> Why this code is very unsafe? If change `ptr` to `shared_ptr` this will >> become perfectly valid and widely used pattern. >> > > Because comparing the void pointers is not safe in general. The above code > in particular will probably work (although not sure if even that's > guaranteed, depending on whether Base and Derived qualify as standard > layout classes), but if the class hierarchy is different, that code will > silently break. I agree, I wrote this code just to demonstrate that deleter must capture pointer because it can be changed due to upcasting. > But, of course, nothing stops you from saving the state in the deleter. > > struct poly_deleter > { > template< typename T > > poly_deleter(T* p) : m_p(p), m_delete(&poly_deleter::do_delete< T >) > { > } > > void operator() (void*) const noexcept > { > m_delete(m_p); > } > > private: > template< typename T > > static void do_delete(void* p) noexcept > { > delete static_cast< T* >(p); > } > > void* m_p; > void (*m_delete)(void*); > }; > > This will work even if you form std::unique_ptr<void, poly_deleter> (i.e. > don't have a universal base class). > Your poly_deleter implementation is the same as I used inside my smart pointer implementation, but there is an issue with std::unique_ptr<T, poly_deleter>, namely it is not constructible from std::unique_ptr<T, std::default_delete<T>> because poly_deleter must capture pointer and so it is not constructible from std::default_delete. -- Andrey Davydov

4 5

[smart_ptr] Is there any interest in unique_ptr with type erased deleter?
by Andrey Davydov 21 Mar '17

21 Mar '17

It is widely known that deleter type is part of std::unique_ptr type. It is the most effective decision, but sometimes not very convenient. The most important use cases (for me) when std::unique_ptr<T, std::default_delete<T>> doesn't work are following: 1. unique_ptr to incomplete class struct MyClass; unique_ptr<MyClass> create(); auto ptr = create(); // compilation error 2. upcast to base without polymorphic destructor struct Base { // ... // no virtual ~Base() here }; struct Derived : Base { // ... }; unique_ptr<Base> ptr = make_unique<Derived>(); // compiles by leaks! 3. unique_ptr with non-default deleter unique_ptr<FILE, int (FILE *)> open_file(std::string const & path) // works but looks ugly, why should the fact that fclose returns `int` be visible from the signature of the function `open_path`? { return { std::fopen(path, "r"), &std::fclose }; } Of course, all this examples could be fixed if unique_ptr would be replaced by shared_ptr, but the semantic of the shared ownership is not desirable often. I have implemented smart pointer with semantics of unique ownership and type erased deleter (https://github.com/AndreyG/unnamed) It has size of 3 pointers and it doesn't require additional memory allocations for the case when deleter is empty class (for example, std::default_delete or non-capturing lambda) and for the case when deleter is known at compile time function (for instance, fclose). The are some simple examples of usage and tests in the repo. Why don't just use unique_ptr<T, function<void (void *>>? The main reason is that due to the small object optimization std::function has rather big size. For instance, sizeof(unique_ptr<T, function<void (void *>>) == 72 for MSVC x64! Results for the other platforms can be found in the repo README. Does it seem useful? -- Andrey Davydov

5 11

[GSOC17] Regarding project Boost.uBLAS
by SHIVAM MITTAL 21 Mar '17

21 Mar '17

Hi, I am *Shivam Mittal*, a sophomore student of *Computer Science & Engineering *discipline of *Indian Institute of Technology, Ropar, India.* I wish to contribute to *Boost.uBLAS*, and develop cool and useful things with the community in GSOC 17. While going through the ideas list, I found the project *Data.Frames in boost.uBlas *very interesting and suitable for me. I think I am well prepared for the task as described in the requirement section. I am very comfortable in C/C++ and fairly comfortable in MATLAB, Python, HTML, CSS, PHP, SQL. I have more than 6 years of experience coding in C++. I have been developing data structures, algorithms, hardware simulators, artificial intelligence programs, and miscellaneous things in C++. The coursework (relevant to this project) which I have completed is : 1. Introduction to computing (in C++) 2. Data structures (in C++) 3. Linear Algebra Some of my selected projects are uploaded on github: https://github.com/shivam5 Please have a look at them. Some projects which I have implemented in C++ are: 1. Simple_RISC plagiarism checker 2. Simple_RISC functional and pipeline simulator 3. Pattern matching system by implementing hash tables. 4. Implementing graphs 5. Implementing AVL and Red black trees 6. Solcvng combinatorial auctions 7. Room booking system 8. Sudoku Solver I have implemented the programming competency test and sent the mentor on personal mail. Can you guide me further on how should I proceed and increase my chances of getting selected. Thank You, Shivam Mittal B.Tech Computer Science & Engineering, IInd Year Indian Institute of Technology Ropar Phone: +91-9888927245, +91-9899461223

1 0

Boost MSM parallel behavior with delayed self-transitions?
by Danylo Malyuta 21 Mar '17

21 Mar '17

Hi community, This is my first post, so I'm sorry for any mistakes in style. I have also posted this question on StackOverflow: http://stackoverflow.com/questions/42920777/boost-msm-parallel-behavior-wit…. I am using Boost MSM (basic and functor front-ends) and am trying to implement the following state machine (https://i.stack.imgur.com/K79qk.png) enter image description here I am using Boost MSM (basic and functor front-ends) and am trying to implement the following state machine: enter image description here In words: 1. Enter state State1 2. Enter state A and execute action_A. After 2 seconds, print "Trying again..." and re-execute state A (i.e. call its entry action). This loops forever... 3. At the same time as 2 (i.e. "in parallel"), enter state B and execute action_B. After 5 seconds, print "Trying again..." and re-execute state B (i.e. call its entry action). This loops forever... I would like to know the way to create this state machine in Boost MSM. There are two tricks here which I cannot figure out how to do: - Execution in parallel (i.e. running action_A does not stop running action_B at the same time) - Delayed transition (i.e. the transitions which happen after 2 seconds for state A and after 5 seconds for state B). Neither delay should be blocking! The transitions should just "fire" after this time. Thank you very much for helping, Danylo.

2 1

Fwd: [gsoc17] Regarding Boost.Geometry
by Aditya Gupta 21 Mar '17

21 Mar '17

Hi I am Aditya Gupta, IInd Yr. B. Tech. Computer Science at IIT Ropar and I wish to work on Project 3 of Boost.Geometry (Nearly antipodal points distance accuracy improvement.) I have completed the competency test <https://github.com/adityagupta1089/earth-geometry>, but I think maybe it was too small or have I misinterpreted, anyways. I have an initial draft of my [GSoC proposal](https://gist.github. com/adityagupta1089/39863577e1716c55d86c98ff57623893) I have also attached my CV.

2 1

Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter?
by Andrey Semashev 21 Mar '17

21 Mar '17

For some reason my email went directly to Andrey instead of the mailing list. I'm re-sending the message below. PS: This has happened to me multiple times now after we moved the ML infrastructure. Is there a way to protect oneself from such mistakes? Am I the only one so inattentive to have this problem? On 03/21/17 16:11, Andrey Semashev wrote: > On 03/21/17 14:54, Andrey Davydov wrote: >> On Tue, Mar 21, 2017 at 2:15 PM, Andrey Semashev via Boost >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On 03/21/17 12:54, Andrey Davydov via Boost wrote: >> >> On Tue, Mar 21, 2017 at 12:00 PM, Richard Hodges >> <hodges.r(a)gmail.com <mailto:hodges.r@gmail.com>> wrote: >> >> What is required, more than simply creating a type-erased >> deleter? >> >> >> Also deleter must capture pointer, because pointer which was >> passed to >> constructor can differ from the pointer which will be deleted. >> For example, >> >> struct Base { /* ... */ }; >> struct Derived : Base { /* ... */ }; >> >> ptr<Derived> p1(new Derived); >> void * raw_p1 = p1.get(); >> ptr<Base> p2 = std::move(p1); >> void * raw_p2 = p2.get(); >> assert(raw_p1 != raw_p2); >> >> >> The above piece of code strikes me as very unsafe and better be >> avoided in the first place. Designing new tools to handle this case >> is IMHO misguided. >> >> Why this code is very unsafe? If change `ptr` to `shared_ptr` this will >> become perfectly valid and widely used pattern. > > Because comparing the void pointers is not safe in general. The above > code in particular will probably work (although not sure if even that's > guaranteed, depending on whether Base and Derived qualify as standard > layout classes), but if the class hierarchy is different, that code will > silently break. > >> Now, I can understand the need to perform casts on smart-pointers, >> but they should still provide some level of safety, at least the >> same level that is provided by pointer casts in the core language. >> But supporting casts should not require a new smart-pointer. And >> indeed it doesn't: >> >> template< typename U, typename T, typename D > >> std::unique_ptr< U, D > static_pointer_cast( >> std::unique_ptr< T, D >&& p) >> { >> D d = p.get_deleter(); >> return std::unique_ptr< U, D >( >> static_cast< U* >(p.release()), >> std::move(d)); >> } >> >> What is `D`? If it is std::default_delete<T> then function result type >> will be std::unique_ptr<U, std::default_delete<T>> and unlikely this >> type is very useful (even if it compiles). > > Ok, that won't work with std::default_delete<T>. But it will work with > this deleter: > > struct static_polymorphic_deleter > { > template< typename T > > void operator() (T* p) const noexcept > { > std::default_delete<T>()(p); > } > }; > > And it should work with a runtime polymorphic deleter that can be > written to implement your proposal (see below). > >> The other part of your proposal, which is polymorphic behavior with >> a deleter knowing the type to call the destructor on, can be solved >> by a custom deleter. I'm not sure a generalized version of such >> deleter would have a large demand, given that there is the >> alternative TONGARI J suggested, but I'm not opposed to a proposal. >> >> May be I doesn't understand what TONGARI J suggested, but >> how can `unique_ptr<T, void(*)(T*)>` hold stateful deleter? > > It doesn't, unless the required state is contained within the object > itself. But just to implement runtime polymorphism, no additional state > is required. > > struct base > { > protected: > ~base() = default; > }; > > struct derived : base > { > }; > > template< typename T > > void poly_deleter(base* p) noexcept > { > delete static_cast< T* >(p); > } > > template< typename T > > using poly_unique_ptr = std::unique_ptr< T, void(*)(base*) >; > > template< typename T > > poly_unique_ptr< T > make_poly_unique() > { > T* p = new T(); > return poly_unique_ptr< T >{ p, &poly_deleter< T > }; > } > > poly_unique_ptr< derived > pd1 = make_poly_unique< derived >(); > poly_unique_ptr< base > pb1 = std::move(pd1); > poly_unique_ptr< derived > pd2 = > static_pointer_cast< derived >(std::move(pb1)); > > But, of course, nothing stops you from saving the state in the deleter. > > struct poly_deleter > { > template< typename T > > poly_deleter(T* p) : m_p(p), m_delete(&poly_deleter::do_delete< T >) > { > } > > void operator() (void*) const noexcept > { > m_delete(m_p); > } > > private: > template< typename T > > static void do_delete(void* p) noexcept > { > delete static_cast< T* >(p); > } > > void* m_p; > void (*m_delete)(void*); > }; > > This will work even if you form std::unique_ptr<void, poly_deleter> > (i.e. don't have a universal base class). >

1 0

Problem with using matrix library with unit test library
by SHIVAM MITTAL 21 Mar '17

21 Mar '17

Hi everyone, I have been developing something, and basically it requires the two boost libraries - the matrix library and unit test library. I have a file test.cpp : #include <boost/numeric/ublas/matrix.hpp> #include <boost/numeric/ublas/io.hpp> #include <boost/test/included/unit_test.hpp> #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MODULE test BOOST_AUTO_TEST_SUITE(Integer_matrices) BOOST_AUTO_TEST_CASE(Constructors) { BOOST_CHECK(2 == 2); } BOOST_AUTO_TEST_SUITE_END() I am compiling this with: g++ -I <path to boost_1_63_0> test.cpp I'm getting the following error: /tmp/ccnxRzsf.o: In function `main': test.cpp:(.text+0x18aa1): undefined reference to `init_unit_test_suite(int, char**)' collect2: error: ld returned 1 exit status Any help will be greatly appreciated. Thanks.

2 1

[Convert] std::isspace requires unsigned #28
by Olaf van der Spek 21 Mar '17

21 Mar '17

Hi, > boost\convert\base.hpp(112): warning C6330: 'const char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'. > boost\convert\base.hpp(115): warning C6330: 'const char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'. https://github.com/boostorg/convert/issues/28 IMO the code should be fixed and it's not a documentation issue. What do you think? -- Olaf

6 17

Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)
by Tom Kent 20 Mar '17

20 Mar '17

Sorry all, I meant to send this to the list but only replied to Daniel. This adds an option 4 and 5. On Sun, Mar 19, 2017 at 3:58 PM, Tom Kent <lists(a)teeks99.com> wrote: > > > On Sun, Mar 19, 2017 at 10:17 AM, Daniel James <dnljms(a)gmail.com> wrote: > >> On 19 March 2017 at 13:10, Tom Kent via Boost <boost(a)lists.boost.org> >> wrote: >> > >> > Option 1 - 14.10 Use microsoft toolset version based on cl.exe version >> -5. >> > This is the official version of the c++ toolset that microsoft has been >> > pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", >> this >> > macro is not available in previous versions of visual studio. >> > >> > build bootstrap would use bootstrap.bat vc1410 >> >> [snip] >> >> > Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses >> for >> > their toolset version. The $(PlatformToolsetVersion) macro is "141". In >> > VS2015 this was "140". >> >> [snip] >> >> > I *think* that is all the reasonable options. Let the consensus form! >> >> I disagree, I think we should limit ourselves to values that Microsoft >> actually uses. As far as I'm aware, they don't use 1410, and they >> don't use 14.1. There are already too many ways of writing the version >> number, adding more will just add to the confusion. >> > > So 2-a would meet these requirements. However, I did overlook the mixed > options: > > Option 4 (141 and 14.10) - > build bootstrap would use bootstrap.bat vc141 > build of source would use b2 toolset=msvc-14.10 > build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_ > 64.lib > config would auto-link libraries of the same format > (4-a is the same as 2-a) > > Option 5 (1410 and 14.1) - > build bootstrap would use bootstrap.bat vc1410 > build of source would use b2 toolset=msvc-14.1 > build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- > 1_64.lib > config would auto-link libraries of the same format > (5-a is the same as 1-a) > > Tom > >

1 0

About all these metaprogramming libraries
by Louis Dionne 20 Mar '17

20 Mar '17

Dear Boost, We've seen two metaprogramming libraries ask for a formal review on the list recently. I expect a third (Brigand) might join the party soon, and maybe even a fourth (Eric Niebler's meta). I think it would be wise to have a plan for how we're going to deal with this. Before going further, I'd also like to clear something out. Some people have asked whether "classic" metaprogramming libraries still had their place given that we now have Hana. As the author of Hana, I think the answer is yes. While Hana is (IMHO) easier to use and more powerful, it also has an important shortcoming. Hana is too slow when dealing with very large inputs. This is due to the fact that it can also handle values, which is much heavier than dealing with types only. This can be alleviated to some extent, but the truth is that our execution model (the compiler) simply has to do more work when handling values. Hence, I think Boost does need a modern classic TMP library to handle these cases where a library writer needs to handle gigantic type lists. I think marketing such a library as an advanced tool for library writers would be a service to the overall C++ community, but that's an orthogonal concern. However, Boost needs one such library, not four. I think we can't just do 4 reviews and include all the libraries that pass in Boost; that would be a huge disservice to our users, who will be left with the burden of choosing. Heck, if we can't even make our mind, how can they? So, how do we pick? Have we ever been in a similar situation where we have multiple competing libraries solving _exactly_ the same problem? Louis -- View this message in context: http://boost.2283326.n4.nabble.com/About-all-these-metaprogramming-librarie… Sent from the Boost - Dev mailing list archive at Nabble.com.

16 39

Newcomer Contributor to Boost C++ Libraries
by Aman Gupta 20 Mar '17

20 Mar '17

Hello everyone, I am Aman Kumar Gupta, an undergraduate 1st year student from International Institute of Information Technology, Bhubaneswar, India. I'm a newcomer to Boost C++ community. I have ,what i think, medium to good C++ coding background as i've been coding in C++ since past 5-6 years and have won some coding competitions as well. I have a good C++ STL knowledge and am very keen and interested in contributing to Boost's STL libraries. But as i'm a newbie to this community, i'm little confused where and how to start. I would be very glad and thankful if anyone would please help me and guide me through.

2 1

Re: [boost] [gsoc17]The implement of Programming competency test From Ruoyun Jing
by Ruoyun Jing 20 Mar '17

20 Mar '17

Hi Vissarion, 2017-03-20 20:29 GMT+08:00 Vissarion Fisikopoulos <fisikop(a)gmail.com>: > Hi Ruoyun, > > > - The main work I should do during GSoC about project 1 is just to > improve > > the algorithms of compare two distances of two point pairs or try to > > consider different situations which used compare distance predicates to > > avoid calculation? > > the project is about algorithms that does not compute the actual distance > but an approximation (as rough as possible) that suffices to accurately > compare the lengths of two geodesic segments on the ellipsoid > > Thanks for your answer, I have the correct point of these project and will continue to write my proposal. > > - Do "In some algorithms there is the need to compare two distances of > two > > point pairs" this means compare two points distances on Earth? Or on > every > > ellipsoid model? > > the later (see answer above) > > > - Do I need to find the approaches of filter by myself? Could you please > > help me get more information about these? Like the implement detail about > > the predicate compare_distance function, mathematical calculation papers > > about compare distance on ellipsoid? > > Well we give one approach on the website (there is another proposal of > another > candidate on the list). My opinion is that if you understand these > approaches > (pos and cons, differences etc) that will help you towards a solid > application. > Having another idea for an approach will definitely strengthen you > application. > Thanks for your help. I can get the point of those approaches and will try to have new ideas. :) > > - In my view, just like compute the shortest distance between two given > > points on Earth, the background approach can be used. And I used > cartisian > > coordinate to avoid many trigonometric function calculation, but I can > not > > find more improve with my lacking knowledge, could you give me some > aspects > > to get more approaches? > > Please see answer above > > At this point I think it is better to jump to boost list because our > discussion > could interest more people. I will not copy anything of our private > conversation > there but feel free to do the jump and I will continue answering there. > > Btw, any news from you test and comparison with Boost.Geometry. > > I reply you and jump to boost with your advice. Hope this will help more people. :) Vissarion > > ps. you can send questions whenever you want, I will answer them a.s.a.p. > my zone is UTC+2 > > Thanks for your answer. Best regards. Ruoyun -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Re: [boost] [geometry] [gsoc17] boost.geometry
by Vissarion Fisikopoulos 20 Mar '17

20 Mar '17

Hi Aman, thanks for your interest in Boost.Geometry and projects 1, 3 in particular. Do you have particular preference between 1 and 3? I think you should specify in your application. Regarding you idea, indeed that could be an option. Do you expect that would be faster or more accurate than the one proposed in the boost GSoC ideas webpage? How would you compare the two approaches? To be clear, I am not testing you but answering that questions could lead to a stronger application. Regarding application there are two options, either you do the competency test or you send a link of a project of you. Please read https://svn.boost.org/trac/boost/wiki/SoC2017 (and links therein) also for details on how to proceed, that is on how to write your proposal. Best, Vissarion. ps. I copy to the boost list for potential feedback from the community On 20 March 2017 at 13:07, Aman Gupta via Geometry <geometry(a)lists.boost.org > wrote: > Respected sir/ma'am > I, Aman Gupta, want to contribute in Boost.Geometry; mainly in Project 1(Filtering > of compare distance predicates) and Project 3( Nearly antipodal points > distance accuracy improvement) . > I have good knowledge in geometry and want to learn more . > > For the problem given in Project 1, another approach I can suggest is to > get 2 intersections of plane (which would be ellipse) with the help given > points and compute the respective distances using those ellipses. > > I hope to get selected for the project work. > > Thanking You. > AMAN GUPTA > resume: https://drive.google.com/open?id=0B9HCqOWnVVvDcm9PQkYtczFjVmM > > _______________________________________________ > Geometry mailing list > Geometry(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/geometry > >

1 0

[gsoc17] boost.geometry
by Aman Gupta 20 Mar '17

20 Mar '17

Respected sir/ma'am I, Aman Gupta, want to contribute in Boost.Geometry; mainly in Project 1(Filtering of compare distance predicates) and Project 3( Nearly antipodal points distance accuracy improvement) . I have good knowledge in geometry and want to learn more . For the problem given in Project 1, another approach I can suggest is to get 2 intersections of plane (which would be ellipse) with the help given points and compute the respective distances using those ellipses. I hope to get selected for the project work. Thanking You. AMAN GUPTA resume: https://drive.google.com/open?id=0B9HCqOWnVVvDcm9PQkYtczFjVmM

1 0

Formal Review Request: mp11
by Peter Dimov 19 Mar '17

19 Mar '17

I'd like to request a review for mp11, a simple C++11 metaprogramming library. The library implements the approach outlined in my two articles http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html and is available at https://github.com/pdimov/mp11/ It supports g++ 4.9 and above, clang 3.6 and above, msvc-12.0, 14.0, 14.1. The library is in Boost format and is intended to be placed in libs/mp11 in a Git clone of Boost. There is documentation in doc/html/mp11.html, it can be viewed locally, or with https://htmlpreview.github.io/?https://github.com/pdimov/mp11/master/doc/ht… Please excuse the lack of .css in that link. Thanks in advance for any interest, comments or suggestions.

4 9

[safe_numerics] review results
by Andrzej Krzemienski 19 Mar '17

19 Mar '17

Hi Everyone, This is to inform you that safe_numerics library by Robert Ramey is *CONDITIONALLY ACCEPTED* to Boost. The list of conditions can be found down below. I would like to congratulate Robert for getting the library into Boost, and thank him for the effort to develop a useful library for the community. I also would like to thank everyone who participated in the review and shared their useful feedback. I recorded five reviews with a yes/no vote: - Paul A. Bristow (yes with conditions) - Steven Watanabe (yes with conditions) - John Maddock (yes with conditions) - Antony Polukhin (yes) - Barrett Adair (yes) And three without a vote: - Vicente J. Botet Escriba - John McFarlane - Peter Dimov We also got some feedback from an individual nicknamed "scatters" at Reddit (https://www.reddit.com/r/cpp/comments/5x1z67/boostsafe_ numerics_formal_review_starts_today/deew1kq/), and from Tomasz Kaminski in private conversation. There was a general consensus that the problem of surprises with C++ ints deserves a solution. Some people observed that there are other ways to approach the same problem, but it was agreed that the approach taken by safe_numerics is sound. The acceptance conditions mostly revolve around documenting micro-decisions made by the library, and fixing bugs. They apply to the reviewed GIT commit 3bcfabe1cafb8ef6edf08d3bd8730a1555b1c45d, but I know Robert is already working on fixing them, and has most of them fixed locally. *Acceptance conditions:* - Comply with Boost formal requirements: 1. index.html in root directory that redirects to doc/. 2. all headers in folder include/boost/numeric/. 3. Macro safe_literal: either remove it or let it follow Boost macro naming conventions: BOOST_NUMERIC_SAFE_LITERAL(). - Automatic promotion policy: either just remove it, or fix it so that: - it can see the range of safe_base in order to allow for slower increase in sizeof(), - it is clear from documentation how the promotion mechanism works. - in particular, what type gets selected for bit-wise operators &, | - The division bug (see below) is fixed. - Decide and document up front how the library addresses each of the following different situations: - overflow upon arithmetical operation, - unexpected promotion to unsigned when comparing signed with unsigned number, - arithmetic operation on unsigned int with negative value versus a signed value (-1 + 1u). - bit-wise operation on negative signed integers (unless they are removed), or that would produce one as the result. - division by zero, - operations upon default-constructed int type with indeterminate value, - conversion from float to int, when float contains non-integral value. - conversion from float to int, when float contains an integral value that would overflow upon native conversion - operator% where one operand is negative (for native ints it is implementaiton-defined) - leftshift by 32 bits (on 32-bit int) - Decide and document what safe's default constructor does. - Document upon which operations safe<> throws exceptions (or, signals arithmetic error at run-time). IOW, document in which cases safe<> never throws exceptions (signals run-time failure) because it is able to say that the operation will always succeed. - Document what happens when you invoke an operation on two instances of safe<> with different policies. - Resolve name conflict with interval, which already exists in namespace boost::numeric::interval. Either use a different namespace or a different name. - Remove anonymous namespaces from the header files. Use namespace detail and inline functions instead. - Improve test cases, so that they also check if numeric values of computations are correct (not only whether an operation throws or not). - Use enable_if (or similar) tricks to constrain the overload resolution for your arithmetical operations, so that they only work for numeric types rather than "any type T". - Fix the division bug: safe<signed, automatic> a {-1}; safe<unsigned, automatic> b {2}; auto c = a / b; // this returns 2147483647 <%28214%29%20748-3647> - Either document that safe<T> only works for scalar types (rather than any T that models concept Integer<T>), or provide alternate implementation of safe_base, as described in https://github.com/robertramey /safe_numerics/issues/44 - Fix linker errors when building a program from two cpp files that include safe_numerics headers. The error is caused by non-inline full specializations of operator<<. - Either entirely remove the support for bit-wise ops on signed types (make it a compiler error), or provide a consistent implementation that detects any UB or surprising results. - `++i` should return by reference; `i--` should return by value. *Other important issues* The following are *not *conditions for library acceptance, but I still recommend addressing them before the initial release. - Concepts: what do you need them for? Any other type except built-in scalars does not work anyway. Do you want to show how close safe<T> resembles T? In this case, they need to be changed. If you want to extend safe<T> to other T's, they need to be fixed: https://github.com/robertramey/safe_numerics/issues/46 <https://github.com/robertramey/safe_numerics/issues/46> - IOStreams interoperability needs fixes: - Move to a separate header, so that it does not affect compilation times when not needed (but provide forward declarations, so that implicit conversions to int do not make IOStreams work with unintended semantics) - Fix other problems as per https://github.com/robertramey /safe_numerics/pull/35 - safe<>'s interface is not documented - Make the library compile with -fno-exceptions: https://github.com/robertramey/safe_numerics/pull/31 <https://github.com/robertramey/safe_numerics/pull/31> - Some people fail to see how this library is better than just using rar ints but compiling with a UB-sanitizer. Address this in the documentation. - Prevent inadvertent ADL by putting safe into a nested namespace boost::numeric::save_types, and then in boost::numeric import: `using boost::numeric::save_types::safe`. This way boost::numeric::safe still works, but inadvertent ADL of everything inside namespace boost::numeric is prevented. - Does it make sense to apply bitwise operations on two different types? If so, document the semantics. - Fix header names and paths in documentation. - Consider adding support for saturation policy upon overflow. - Expression `safe<int>{4} ^ 1` does not compile due to overload resolution ambiguity. - Fix constexpr usages. - If possible, make workarounds in order to make the library work with MSVC. - Document that operations on safe<> do not thorw exceptions other than these thrown by exception policy. *Suggestions* The following summarizes other useful suggestions for improving the library in the future. - operation `safe<signed>{INT_MIN} + safe<unsigned>{UINT_MAX}` throws even though the mathematical result would fit in either signed or unsigned int. This is correct according to what policies describe, but is at the same time surprising, given that comparison `safe<signed>{INT_MIN} < safe<unsigned>{UINT_MAX}` just gives a mathematically correct answer rather than throwing an exception. Document this behavior explicitly. - Remove underflow_error from the policies: it sends the wrong message, that som form of an underflow is checked in this library. - Expose functions like add(), divide() in public interface, they might be useful on their own. - Expose the constructor with check disabled in the public interface, like `safe<int>{1, checks_sisabled{}}` this helps to locally disable the checks where the user knows that certain chain of operaitons will not overflow, and checks are redundant, but the library cannot see it. - Issues reported with bit-shift operators - unary operator- on unsigned type with pormotion policy `automatic` could return a signed type. - Use BOOST_NORETURN wherever possible, e.g. in throwing policies. - Use BOOST_LIKELY, BOOST_UNLIKELY for the policy tests. - Add support for statful policies. - Maybe drop the support for automatic type widening, to simplify the interface and the scope of the library, and let some other library handle the widening, maybe BigInt. Regards, Andrzej Krzemienski

3 3

[release] 1.64.0 Decision on VS2017 version number?
by Rene Rivera 19 Mar '17

19 Mar '17

> (B) The community decides what version number we should be using and the > appropriate PRs are filed and applied and tested for all the repos > involved. Which means: > 1. The community has until 12:00 CDT US March 18 to decide on what the vc > version number and tag should be. > It's now past that time.. Is there consensus on what version number Boost should use for identifying the VS2017 toolset? If there is.. People need to start submitting PRs for the changes ASAP.. > 2. The community must post PRs for the places where we reference VS2017 > version numbers to the new number. Those are at least: > <https://github.com/boostorg/config> > <https://github.com/boostorg/build> > <https://github.com/boostorg/boost> > <https://github.com/boostorg/website> > People have until 17:00 CDT Monday March 20 to submit those PRs. Thanks. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 4

Project R-tree Serialisation
by Kabir Sahni 19 Mar '17

19 Mar '17

Hi everyone, I am midway through my competency test.I wanted to know whether working of serialisatjon for n dimensional point is the only thing to be demonstrated in main.cpp file. Thanks

3 2

Re: [boost] Advanced find() for associative containers
by Bjorn Reese 19 Mar '17

19 Mar '17

On 03/16/2017 06:18 PM, Boris Rasin via Boost wrote: > 2. Where exactly should it fit in the boost? The most appropriate place would be Boost.Algorithm, so that is Marshall's domain. > Public interface consists of a single free function template: > > template <typename C> > auto find(C& c, const typename C::key_type& key); Your find() function deviates on several accounts from std::find() so it should probably be renamed, e.g. to find_key. Can you elaborate on why you have a specialization that uses lower_bound()? What is the minimal C++ version required? Looks like C++14 from the auto return type.

2 1

Visual Studio multi-toolset support (was: [release] 1.64.0 please test master snapshot)
by Mateusz Loskot 18 Mar '17

18 Mar '17

On 18 March 2017 at 14:27, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Mateusz Loskot wrote: > >>> No, VS 2015 can build with v140, v120, v110, v100, v90, as long as you >>> have the earlier versions installed. (VS 2017 can build with v140 even if >>> you don't have VS 2015 installed.) >> >> >> I understood VS2017 is first version with multi-toolset support. > > > The first version with multi-toolset support is VS 2012, although the only > two toolsets supported are v110 and v110_xp, which share the same version. > VS 2013 supports v90 - v120. VS 2015 supports v90 - v140. I always used the 'default' toolset of particular VS version, hence fostered ignorance about that multi-toolset support. > Wait, no, VS 2010 supports v100 and v90. :-) :-) Thank you for the enlightenment. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[release] 1.64.0 please test master snapshot..
by Rene Rivera 18 Mar '17

18 Mar '17

After help from various sources to get the VS2017 building working the latest master snapshot should at least try and build with VS2017. Assuming nothing horrible shows up today we will release the first beta tonight. Hence, please smoke test the latest master snapshot found at: <https://dl.bintray.com/boostorg/master/> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

10 34

[review process] candidate library maintenance disturbs the review
by Andrzej Krzemienski 17 Mar '17

17 Mar '17

Hi Everyone, In the context of the discussion around review process improvements, I wanted to report another problem that I do not know how to solve. But maybe you do. Extending the review period by allowing the review on the BLIncubator looks like a good idea, but it also comes with a problem. The review applies to a particular commit (if we use GItHub terms), that is, to the state of the library on a particular branch at a particular point in time. If I see a review on BLIncubator (not that I see many of them), how do I know what commit it applies to and if it is even irrelevant. It might be partially relevant, but it puts me in an uncomfortable situation, that I will be investing my time in something that is likely to turn out to be useless. Also, I might consider submitting a review into BLIncubator, but what chances I have that it will be considered in the formal review, given that the formal review may work on a different commit: possibly on a quite different library by now? Regards, &rzej;

3 3