- Boost - lists.preview.boost.org

[graph] r_c_shortest_paths writes/reads outside allocated memory
by Mateusz Polnik 06 Mar '18

06 Mar '18

Dear Colleagues, The algorithm for computing resource constrained shortest path writes/reads outside allocated memory which may result in segmentation faults. The finding is confirmed using Valgrind. I fixed the bug and opened a pull request. Could you review the pull request and give feedback if there is something more that should be done to meet quality requirements for the merge? The pull request https://github.com/boostorg/graph/pull/93 explains the issue, fixes it and contains a test for preventing regressions. Thank you in advance for your help. Regards, Mateusz Polnik

1 0

GSoc - Request for guidance
by Fady Saeed 06 Mar '18

06 Mar '18

Hello, I’m Fady Saeed. I’m Studying Computer & System Engineering at Faculty of Engineering (3rd year) at Ain Shams University in Egypt I read GSoc projects idea list and it was really interesting and I want to contribute I’m interested in contributing to Boost Geometry, Boost SafeFloat Project 1 So If it’s possible I’d like to connect to a mentor and know what should I do next and If there’s anything I need to read about so I can contribute Thanks in advance

3 2

[filesystem] Boost 1.66 fails to compile under Android NDK r16b
by Robert Dailey 06 Mar '18

06 Mar '18

I'm following a bug reported against boost filesystem here on github: https://github.com/boostorg/filesystem/issues/65 This issue has gone dead. Early on they asserted it was an NDK issue. However, the NDK developers say it's a filesystem issue. I'm not able to build Boost 1.66 with the following configuration: Android NDK Version: r16b Architecture: armeabi-v7a API: 15 Toolchain: Clang STL: libc++ (LLVM) This is blocking my migration away from GNUSTL. Can anyone confirm that this issue is being looked at? Either I'm the only one seeing this, or my toolchain combination exposes the bug but not many people build boost this way.

3 4

Proposed SG14 <system_error2> ready for feedback
by Niall Douglas 05 Mar '18

05 Mar '18

Back after the Outcome discussion died down, I started a thread discussing making breaking changes to Boost.System to test the feasibility of fixing some of the unfortunate design choices now apparent through hindsight in `<system_error>`. I won one argument - constexprification - the others I lost. I said at the time that I'd go off and make a better mousetrap i.e. a proposed `<system_error2>`. That proposed `<system_error2>` is now ready for feedback: Single file include: https://github.com/ned14/status-code/raw/develop/single-header/system_error… Github: https://github.com/ned14/status-code Docs: https://ned14.github.io/status-code/ Lots of detail about the differences between proposed `<system_error2>` and `<system_error>` is in the front page of the docs and pasted after this email, but essentially it fixes all the problems listed in https://wg21.link/P0824, and a few other problems I considered important as well. It works well in C++ 11, is believed to be freestanding C++ (https://wg21.link/P0829) friendly, and generates really lovely and tight codegen. If SG14 smile upon it in the April meeting, it'll be heading to Rapperswil for standardisation. Boost members should be aware that there will be shortly a push by the WG21 leadership to improve the current state of exception and error handling in the C++ standard as it is becoming increasingly obvious that the current design is no longer sufficient. You may see a paper on that from the leadership at Jacksonville, if not then fairly definitely you will at Rapperswil. This proposed `<system_error2>` *may* have a part to play in the reform proposals, if it is felt that this approach is a wise one by SG14, you guys here, and then WG21. So, as a quick introduction given that there is no documentation, instead of `error_code` we have a `status_code<D>` where `D` is the type of the code's *domain*. The domain provides all of the heavy lifting so status code itself can be trivial. Status codes can be type erased of their domain, you can always erase to `status_code<void>` but at the cost that it cannot be copied, moved nor deleted. If your domain's value type is trivially copyable, it can also be type erased into any `status_code<erased<U>>` where `U` is an integer type, and the size of the erased status code is bigger or equal to its unerased form. There is a special status_code called `generic_code`, which is a typedef for `status_code<_generic_code_domain_impl>`. Its value type is `errc`, which is a slight superset of `std::errc`. The reason it is special is because it is the baseline error code, all other codes must be semantically comparable to it, if that is possible. In current STL speak, `generic_code` is what `std::error_condition` with a `std::generic_category` is. On all POSIX platforms, we provide a `posix_code`. Its value type is `int`, as from `errno`. This maps the local POSIX implementation's error coding. It is *not* necessarily equal to `generic_code`, but usually is a superset, so all codes in `generic_code` can exist in `posix_code`, but not the other way round. On Windows, we have three main system error coding systems, so we have `win32_code`, `nt_code` and `com_code`. Their value types are `DWORD` from GetLastError(), `LONG` from `NTSTATUS`, and `HRESULT` from Microsoft COM. On all systems, there is a typedef `system_code` which is to the erased status code sufficiently large that you are guaranteed that all possible system error coding schemes can be safely erased into it. For POSIX, this is `status_code<erased<int>>`, as `int` can hold all possible error codings. For Windows, this is `status_code<erased<intptr_t>>`, as `intptr_t` can hold any of a `DWORD`, a `LONG` and a `HRESULT`. All comparisons between status codes are *semantic*. As in, `operator==()` returns true if the two types are semantically equal e.g. `win32_code(ERROR_SUCCESS) == generic_code(errc::success) == com_code(S_OK)`. Semantic comparison is the only form of comparison, if you want literal comparison, it can be done by hand by comparing value and domain by hand. There is no boolean testing at all, as it is ambiguous as we learned with `std::error_code`. One always writes: `if(sc.failure()) ...` etc. `status_code` can represent success codes, failure codes, and empty. Empty is there to say "no code was set". Empty is neither a success, nor a failure. It is there for code where a virtual function call to determine success/failure is too expensive and where the domain is known for a fact to only ever represent failure. You should only ever use empty as a local optimisation, and never ever expose empty status codes to code that you don't 100% control. And that's basically it. Idiomatic usage is for extern functions to return type erased status codes or to take one by lvalue reference. Code local to the translation unit uses typed status codes, and lets any implicit conversion into the erased form occur as needed. I've copy and pasted relevant excerpts from the Readme.txt below for those not willing to click on a link. If you have any questions, please do shout. My next step is to start work on preparing Outcome for entry into Boost now a month of settling time has passed since the review. Once the Jacksonville meeting has finished and I've done any post-meeting correspondence, I'll be starting on my (currently five!) papers for Rapperswil where I'll hopefully be attending my very first WG21 meeting! Niall --- Readme.md (excerpt) -- Solves the problems for low latency/large code base users with `<system_error>` as listed by [WG21 P0824](https://wg21.link/P0824). This proposed `<system_error2>` library is EXPERIMENTAL and is subject to change as the committee evolves the design. To fetch a drop-in standalone single file implementation: ``` wget https://github.com/ned14/status-code/raw/develop/single-header/system_error… ``` ## Features: - Portable to any C++ 11 compiler. These are known to work: - >= GCC 5 (due to requiring libstdc++ 5 for sufficient C++ 11 type traits) - >= clang 3.3 with a new enough libstdc++ (previous clangs don't implement inheriting constructors) - >= Visual Studio 2015 (previous MSVC's don't implement inheriting constructors) - Aims to cause zero code generated by the compiler most of the time. - Never calls `malloc()`. - Header-only library friendly. - Type safe yet with type erasure in public interfaces so it can scale across huge codebases. - Minimum compile time load, making it suitable for use in the global headers of multi-million line codebases. ## Problems with `<system_error>` solved: 1. Does not cause `#include <string>`, and thus including the entire STL allocator and algorithm machinery, thus preventing use in freestanding C++ as well as substantially impacting compile times which can be a showstopper for very large C++ projects. Only includes the following headers: - `<atomic>` to reference count localised strings retrieved from the OS. - `<cassert>` to trap when misuse occurs. - `<cerrno>` for the generic POSIX error codes (`errno`) which is required to define `errc`. - `<cstddef>` for the definition of `size_t` and other types. - `<cstring>` for the system call to fetch a localised string and C string functions. - `<exception>` for the basic `std::exception` type so we can optionally throw STL exceptions. - `<initializer_list>` so we can permit in-place construction. - `<new>` so we can perform placement new. - `<type_traits>` as we need to do some very limited metaprogramming. - `<utility>` if on C++ 17 or later for `std::in_place`. These may look like a lot, but in fact just including `<atomic>` on libstdc++ actually brings in most of the others in any case, and a total of 200Kb (8,000 lines) of text is including by `system_error2.hpp` on libstdc++ 7. Compiling a file including `status_code.hpp` takes less than 150 ms with clang 3.3 as according to the `-ftime-report` diagnostic (a completely empty file takes 5 ms). 2. Unlike `std::error_code` which was designed before `constexpr`, this proposed implementation has all-`constexpr` construction and destruction with as many operations as possible being trivial or literal, with only those exact minimum operations which require runtime code generation being non-trivial (note: requires C++ 14 for a complete implementation of this). 3. This in turn means that we solve a long standing problem with `std::error_category` in that it is not possible to define a safe custom C++ 11 error category in a header only library where semantic comparisons would randomly break depending on the direction of wind blowing when the linker ran. This proposed design is 100% safe to use in header only libraries. 4. `std::error_code`'s boolean conversion operator i.e. `if(ec) ...` has become unfortunately ambiguous in real world C++ out there. Its correct meaning is "if `ec` has a non-zero value". Unfortunately, much code out in the wild uses it as if "if `ec` is errored". This is incorrect, though safe most of the time where `ec`'s category is well known i.e. non-zero values are always an error. For unknown categories supplied by third party code however, it is dangerous and leads to unpleasant, hard-to-debug, surprise. The `status_code` proposed here suffers from no such ambiguity. It can be one of exactly three meanings: (i) success (ii) failure (iii) empty (uninitialised). There is no boolean conversion operator, so users must write out exactly what they mean e.g. `if(sc.success()) ...`, `if(sc.failure()) ...`, `if(sc.empty()) ...`. 5. Relatedly, `status_code` can now represent successful (informational) codes as well as failure codes. Unlike `std::error_code` where zero is given special meaning, we impose no requirements at all on the choice of coding. This permits safe usage of more complex C status coding such as the NT kernel's `NTSTATUS`, which is a `LONG` whereby bits 31 and 30 determine which of four categories the status is (success, informational, warning, error), or the very commone case where negative numbers mean failure and positive numbers mean success-with-information. 6. The relationship between `std::error_code` and `std::error_condition` is confusing to many users reading code based on `<system_error>`, specifically when is a comparison between codes *semantic* or *literal*? `status_code` makes all comparisons *semantic*, **always**. If you want a literal comparison, you can do one by hand by comparing domains and values directly. 7. `std::error_code` enforced its value to always be an `int`. This is problematic for coding systems which might use a `long` and implement coding namespaces within the extended number of bits, or for end users wishing to combine a code with a `void *` in order to transmit payload or additional context. As a result, `status_code` is templated to its domain, and the domain sets its type. A type erased edition of `status_code<D>` is available as `status_code<void>`, this is for obvious reasons non-copyable, non-movable and non-destructible. A more useful type erased edition is `status_code<erased<T>>` which is available if `D::value_type` is trivially copyable, `T` is an integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you use `status_code<erased<T>>` in all your public interfaces without restrictions. As a pointer to the original category is retained, and trivially copyable types may be legally copied by `memcpy()`, type erased status codes work exactly as normal, except that publicly it does not advertise its type. 8. `std::system_category` assumes that there is only one "system" error coding, something mostly true on POSIX, but not elsewhere. This library defines `system_code` to a type erased status code sufficiently large enough to carry any of the system error codings on the current platform. This allows code to construct the precise error code for the system failure in question, and return it type erased from the function. Depending on the system call which failed, a function may therefore return any one of many system code domains. 9. Too much `<system_error>` code written for POSIX uses `std::generic_category` when they really meant `std::system_category` because the two are interchangeable on POSIX. Further confusion stems from `std::error_condition` also sharing the same coding and type. This causes portability problems. This library's `generic_code` has a value type of `errc` which is a strong enum. This prevents implicit confusion with `posix_code`, whose value type is an `int` same as `errno` returns. There is no distinction between codes and conditions in this library, rather we treat `generic_code` as something special, because it represents `errc`. The cleanup of these ambiguities in `<system_error>` should result in users writing clearer code with fewer unintended portability problems. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 13

Trouble getting feedback on a program_option feature PR
by Eyal Rozenberg 05 Mar '18

05 Mar '18

Hello Boosters, Following a (much) earlier suggestion on this list, I've implemented one of the features I'd like to see in program_option, and created Pull Request for initial review/feedback on GitHub: https://github.com/boostorg/program_options/pull/40 I've noticed, however, that there are 4 other unattended PRs, the earliest being from 2016. Some of them have comments such as "Can you please merge or decline?" urging a response. Also, there have been no commits for the past 4 months. I've also emailed Vladimir (Prus) last month - a short message, merely to ensure he's noticed my PR, not to demand anything; but I've gotten no reply. Now, I don't want to sound accusatory - I'm sure there are perfectly good reasons for the lack of responsiveness, and I'm very appreciate of the work of writing the library and maintaining it over the years. Still, given the situation I thought I'd bring this up here on the list. What would you suggest I do? Eyal

1 0

Gsoc2018/mentor required
by nivyatheresa 05 Mar '18

05 Mar '18

Hello, I am Nivya and I am a btech student from IIT Roorkee. I would like to contribute to the Boost.Real project. I need a mentor to help me to proceed further. Thanks in advance, Sincerely, Nivya. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[serialization] RTTI issue with non-polymorphic types
by Jorge Lodos 05 Mar '18

05 Mar '18

Hi I am trying to use the serialization library for non-polymorphic types without RTTI. In release mode everything works fine, but in debug mode there are problems because dynamic_cast is used for debugging purposes. The code is in smart_cast.hpp, starting in line 87: #if ! defined(NDEBUG) \ || defined(__MWERKS__) // do a checked dynamic cast return cross::cast(u); #else I believe the first line could be replaced with: #if (! defined(NDEBUG) && ! defined(BOOST_NO_RTTI) ) \ Is this something you are willing to consider? I decided to ask before creating any ticket or pull request because there is a number of previous attempts to make serialization work without RTTI for the general case. But this is specific for non-polymorphic types. Thanks. Jorge

3 3

Re: [boost] Proposed SG14 <system_error2> ready for feedback
by Bjorn Reese 04 Mar '18

04 Mar '18

On 02/28/18 23:10, Niall Douglas via Boost wrote: > 7. `std::error_code` enforced its value to always be an `int`. This is > problematic for coding systems which might use a `long` and implement > coding namespaces within the extended number of bits, or for end users > wishing to combine a code with a `void *` in order to transmit payload > or additional context. As a result, `status_code` is templated to its > domain, and the domain sets its type. A type erased edition of > `status_code<D>` is available as `status_code<void>`, this is for > obvious reasons non-copyable, non-movable and non-destructible. > > A more useful type erased edition is `status_code<erased<T>>` > which is available if `D::value_type` is trivially copyable, `T` is an > integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you > use `status_code<erased<T>>` in all your public interfaces without > restrictions. As a pointer to the original category is retained, and > trivially copyable types may be legally copied by `memcpy()`, type > erased status codes work exactly as normal, except that publicly it does > not advertise its type. While I do see the need for providing extensions, I am not sure if status_code<void> is useful given all its "non-" characteristics. Can you elaborate on its use-cases? I propose that the customizable status_code<D> is renamed to basic_status_code<D>. In keeping with the pre-established practices of std::error_code using int, I furthermore suggest that status_code becomes a non-templated alias for basic_status_code<int>.

3 5

Gsoc2018/Mentor required.
by nivyatheresa 04 Mar '18

04 Mar '18

Hi, I am Nivya Theresa Jose, b-tech student from Indian Institute of Technology Roorkee. I would like to contribute to boost.uBLAS project 1, which is to add support for tensors .I would like to connect with a mentor and would like to know about further procedures. Thanks in advance, sincerely, Nivya Theresa Jose. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

Help/Mentor required
by Devika Krishnadas 04 Mar '18

04 Mar '18

Hi, I am Devika Krishnadas, an Undergrad Computer Science student from Amrita University. I am interested in contributing to boost.uBLAS project #1, which is to add Statistics and Machine learning functions. It would be great if anyone could help me proceed further. Thanks in advance, Regards, Devika Krishnads.

2 1

gsoc2018 inquiry and mentor seeking
by fady esam 04 Mar '18

04 Mar '18

Hello, I am Fady Esam student at 3rd year of computer engineering in ASU university in Egypt I want to cobtribute the the project of "Adding multicore and gpu computations to uBLAS" As i was the team leader and main contributer in an open source library for complex-numbers matrices that has the same parsing and interface as matlab and supports all operations like computing inverse by gaussian elimination and determinant by LU decomposition and +, - , * ,/ , .* , ./ and computing power of matrix in a very optimized way That's a github link to the library : https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 I want to know do i have to implement part of the library again in template for the competency test? And is there a mentor that is interested so i can submit a proposal to? Thanks for reading :)

2 2

[interprocess] file_mutex class proposal
by mateusz janek 04 Mar '18

04 Mar '18

Hello boost::interprocess community, During my pet projects development I found that a file access synchronization is a common problem so, I wrote a class that wraps it and thought that it can be useful for wider community. I would like to ask you what do you think about such functionality in boost::interprocess? I'm aware that class from the repo is not ready to release. Just wanted to show about what functionality I'm talking about. Here you can find the repo: https://github.com/stryku/file_mutex You can find there the proposed class and a simple usage example. If you will find it interesting I will prepare more formal merge proposal, update docs, maybe more examples etc. Looking forward to hearing from you what do you think about it. Thank you, Mateusz Janek

1 0

Which headers to include?
by Lakshay Garg 03 Mar '18

03 Mar '18

Hello Boost I am using a few Boost libraries in a project I am working on. I must confess that this is perhaps my first serious use of boost so all this could just be due to lack of familiarity. The one thing that keeps frustrating me about boost is finding out _which headers to include?_ I am not sure if this is a problem with my googling skills or library documentation or maybe I just don't know the proper place to look at but most of the times I need to use a library with lots of headers (I am looking at Boost.Log) I have to go grepping the boost code. Is there something I am missing or is there a better way to go about this problem? Lakshay

3 2

why boost does not have skip list implementation?
by David Frank 03 Mar '18

03 Mar '18

like java concurrentSkipListSet for example. Thanks, David

3 2

past few days coding:=>>makefile generator
by Ggh 03 Mar '18

03 Mar '18

#-------------------------------------------------------------------------------- # # Command Line Options: # # For each argument add a space between the switch and the argument to the switch, # e.g.: # # mkmakefile -tt exe -t targetname # # mkmakefile --help # # -tt <exe|dynamic|objs|static> Target type # -t <targetname> Target name # -i <include directory> Include directory # Include directories can be several. Prepend # each directory with an '-i' # -L <library directory> Library directory # Library directories may also be several, prepend each # directory with an '-L' # -l <library name> Library name, may also be several, prepend each # library with '-l'. # -d <define> Define # May also be several, prepend each define with '-d'. # -hd Header dependencies # This flag makes the generator scan # the source files for header files # included. Creates dependency rules # in the generated makefile. # If a header file is included in a source file # and found in any of the include directories given # it will be listed as a dependency to the source file. # -o <makefile filename> Makefile filename to generate # -c <c compiler> C compiler, the compiler needs to be in the PATH # environment variable. # -cc <c++ compiler> C++ compiler, the C++ compiler needs to be in # the PATH environment variable aswell. # -sl <static library> Link to static library # The number of static libraries can be any. # Prepend each library name with an '-sl' tag. # -wd <target directory> Target directory. The program changes # to the target directory, creates the makefile # and reverts back to the directory it was # started from. The makefile is written # to the target directory. If this argument is # not set then the current directory will be used. # -mk Make the program / library. This option executes # 'make' with the make file given. If no makefile # argument is given it will use 'makefile.mk' by # default # # -help This help information # #--------------------------------------------------------------------------------

1 0

[gsoc18]project1-1: Add statistics and machine learning functions
by SheldonZhang 02 Mar '18

02 Mar '18

Hi, My name is Zhang Bohan(Sheldon Zhang) from China. I am a freshman in Beijing University of Posts and Telecommunications, majoring in Information and Communication Engineering. I want a mentor who can guide me to accomplish the project. I am interested in working for Boost.uBLAS because in my profession there are plenty of calculation about matrix. I believe this will lead me to better understanding about it. And I love machine learning, it is the way to the future. I am taking a machine learning course(taught by Andrew Ng) on coursea. So I know what I am going to do in the project. I do quite well in Linear Algebra. In the exam, I got top 10% in the grade. I have been programming since junior high school. I am familiar to C++-11 and its features(like lambdas and template). I have good command of basic algorithms. I participated in National Olympiad in Informatics and got good grades. Besides, I am a teaching assistant in Program Designing Course. I am googd at English, so there is few difficulty in communicating. I have done the programming competency test https://github.com/ltg001/gsoc18-codeCompetencyTest At last, what should I do in this period? With regard, Sheldon Zhang -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[gsoc18] [Boost.Real] Competency Test
by Parth Mittal 02 Mar '18

02 Mar '18

Hi My name is Parth Mittal, and I'm a third year computer science undergraduate. Here is my attempt at the competency test: (wrt the first, second, and third bullet on the project page) 1. I uploaded my code here (https://github.com/parthmittal/boost_competency_test) I'm not sure how much of it is required to be functional but (of course) I can write more code if required. The current code uses an std::pair of the chosen rational type to represent intervals, it is probably more sensible to replace this with a dedicated type for intervals. Also I have two different ideas for dealing with integers in the binary operators: (i) Wrap them into a "real" number (with an approximation function that always returns the exact value and an error term of 0). (ii) Add a facility for additive and multiplicative rational factors to the class. 2. For sure there is no way to be sure two numbers are equal in finite time, so while checking if a and b are equal, we should pass an integer parameter, say K, and then for every pair of integers i, j between 1 and K, we should check if a(i) = b(j) (of course a(i) = b(j) iff the intervals share a point). This feels somewhat inefficient (it would be nice to eliminate the quadratic runtime with K), but since we don't have a guarantee that a(i + 1) is a subset of a(i), I don't see any obvious way to improve this. 3. To be honest, I had to google for "Small String Optimization" - and the analogue I can see is to store as an array the values of a(k) for all k <= K for some small constant K. I'm not sure how to implement this at compile time; it makes sense that the approximation function(s) for the real number involved be constexpr, but I've never written any code which is constexpr. Perhaps my code in (1) already makes this clear, but I'm not very experienced at writing C++; I've written probably 100k+ lines while doing programming contests, but this was rather simple code which was written once and read never. I can fill in the gaps in my knowledge of the language on an ad-hoc basis (or using the time until the SoC officially begins). Thank you for reading Parth Mittal

2 1

Boost Performance
by Ian Kosen 01 Mar '18

01 Mar '18

Hi, I was looking at this benchmark https://github.com/mloskot/spatial_index_benchmark <https://github.com/mloskot/spatial_index_benchmark> which attempts to compare the performance between Boost and LibSpatialIndex. It caught my eye that Boost was magnitudes faster than LibSpatialIndex. Is there an obvious reason for this? Design considerations and trade offs? Thank you :) Regards, Kosen

2 1

[teeks99-09-p-win2016-64on64][poly_collection] Regression with latest MSVC 14.1 in C++17 mode
by Joaquin M López Muñoz 28 Feb '18

28 Feb '18

Hi, MSVC 14.1 (_MSC_FULL_VER=191225834) in C++17 mode (_MSVC_LANG=201704L) is having a regression when compiling Boost.PolyCollection tests: http://www.boost.org/development/tests/develop/developer/output/teeks99-09-… The problem happens in this seemingly innocent context (https://github.com/boostorg/poly_collection/blob/654018c7ce14674a1c0527206a… ): template< typename ForwardIterator1,typename ForwardIterator2,typename Predicate > bool operator()( ForwardIterator1 first1,ForwardIterator1 last1, ForwardIterator2 first2,Predicate pred)const { ... using difference_type= typename std::iterator_traits<ForwardIterator1>::difference_type; difference_type l1=std::distance(first1,last1); // syntax error (wrongly) signalled here Is there some kind soul with access to this compiler who'd like to try the following workarounds and report the results? // workaround 1 using difference_type= typename std::iterator_traits<ForwardIterator1>::difference_type; typename difference_type l1=std::distance(first1,last1); // workaround 2 typedef typename std::iterator_traits<ForwardIterator1>::difference_type difference_type; difference_type l1=std::distance(first1,last1); Thank you! Joaquín M López Muñoz

2 2

request for comments in a new format library
by Roberto Hinz 28 Feb '18

28 Feb '18

Dear boost community, some time ago I announced a format library I'm working on. I think at that time it was still too incipient for one to evaluate whether it looked promising, thought some few but very useful observation were made ( one regarding i18n and other code bloat ) that made me change many things. Now the library is more evolved and I think it will be ready for review somewhere in the second half of this year, if no big change happens. This is a c++14 text format library with some unique features: - designed to be utf8 friendly - easy to extend for new destination types ( like some different string type ) - able to align (justify) a set of sub-arguments as one ( see joins <https://robhz786.github.io/stringify/doc/html/special_input_types/special_i…> ) - it enables the use of translations tools ( like gettext ), yet the formatting is not specified by a format string. And the problem with format strings that they lead to run time errors (instead of compilation error ) when they are incorrect. Hence I much appreciate any comments, especially if can identify any flaw I didn't realize. repo: https://github.com/robhz786/stringify doc: https://robhz786.github.io/stringify/doc/html/ best regards roberto

3 7

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #13458: 'cl' is not recognized as an internal or external command, operable program or batch file. Failed to build Boost.Jam build engine. Please consult bjam.log for furter diagnostics.
by Andrew Depke 28 Feb '18

28 Feb '18

It looks like you're missing "cl.exe" on your system, or have not included it in your PATH. cl.exe, as seen here <https://msdn.microsoft.com/en-us/library/f35ctcxw.aspx>, is Microsoft's C++ compiler, which can be obtained by downloading the latest version of Visual Studio. Downloading and installing MSVS will automatically place it in your PATH. On Tue, Feb 27, 2018 at 2:28 PM, Boost C++ Libraries < noreply(a)lists.boost.org> wrote: > #13458: 'cl' is not recognized as an internal or external command, > operable program > or batch file. Failed to build Boost.Jam build engine. Please consult > bjam.log for furter diagnostics. > ------------------------------+--------------------- > Reporter: anonymous | Owner: (none) > Type: Bugs | Status: new > Milestone: To Be Determined | Component: None > Version: Boost 1.41.0 | Severity: Problem > Keywords: | > ------------------------------+--------------------- > 'cl' is not recognized as an internal or external command, > operable program or batch file. > > Failed to build Boost.Jam build engine. > Please consult bjam.log for furter diagnostics. > > -- > Ticket URL: <https://svn.boost.org/trac10/ticket/13458> > Boost C++ Libraries <http://www.boost.org/> > Boost provides free peer-reviewed portable C++ source libraries. > > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-bugs > >

1 0

[release] 1.67.0 closed for major changes
by Daniel James 28 Feb '18

28 Feb '18

The master branch is now closed for major changes and will be closed for the beta in a week. Also, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q…> Remember that after editing the file, you need to submit the form to create a pull request. You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

Boost managed_shared_memory not working with C's mmap call on freeBSD
by vijay sharma 27 Feb '18

27 Feb '18

Hi All, I am having two processes and they are sharing shared-memory. - Process-1 (implemented in c++ and using boost::interprocess::managed_shared_memory interface) - Process-2 (implemented in c and using "she_open" and "mmap" interfaces) This code was working fine on Linux But When I deployed same code on FreeBSD. Process-2 (C lang based) is keep on throwing error in mmap. Error is "Bad file Descriptor". Please let me know: 1. Do I need to change the interface while moving from Linux to FreeBSD. 2. Is there any known issue with this design. Code Snippet: Process-1(c++): obj = new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create,<shm_name>, <shm_size>); // to create shm obj->allocate(<data_size>) ; // to write in shm Process-2 (c): int fd = shm_open(<shm_name>,O_RDWR, 0666);void * startpoint = mmap(NULL, <shm_size>, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); // using the startpoint to read data written by process-1. Boost version: Boost.1.63.0 I have raised same on stackoverflow.com and below is the link: https://stackoverflow.com/questions/48984703/boost-managed-shared-memory-no… Thanks, Vijay

2 1

[Boost][CMake] Status of cmake support.
by Mike 26 Feb '18

26 Feb '18

Hi everyone, since I couldn't find any official information about that, I wanted to ask if there is any new information about the cmake support in boost (since the initial discussion on the ml after the steering committee's announcement)? Is there some agreement on how to do the transition or at least a popular formal/informal proposal? Is there any place to track which libraries can already be built with cmake? What is the best way for a non library authors like me to help with the transition? IIRC there was talk about a cmake library some time ago, but I haven't heard anything about that in a long time. Is such a library even desired/necessary? Imho getting all of boost to compile with cmake should be pretty simple, but if this is expected to happen in a transparent manner (same output, same workflow including test result upload), a fair bit of boost knowledge, cmake skills and support machinery might be required. Best regards Mike

10 15

[winapi] Bumping default target to Windows 7?
by Andrey Semashev 26 Feb '18

26 Feb '18

Hi, I was thinking about bumping the default target Windows version to 7 in Boost.WinAPI. The current default is Vista, which EOLed in April 2017. There is not much difference from the available API standpoint (in Boost.WinAPI this would enable a few constants related to process management), but there may be some interesting extensions that could be useful to libraries. Note that this will not preclude targeting older Windows versions, just as it doesn't preclude targeting XP or 2000 now. Users will still be able to specify the target Windows version as they can now. Note also that I'm not planning this for 1.67, only 1.68. Any objections/thoughts?

1 0