February 2018 - Boost - lists.preview.boost.org

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

[type_traits] revisiting is_virtual_base_of
by John Maddock 10 May '18

10 May '18

There is a problem with is_virtual_base_of in that it doesn't work especially well - most of the time it works OK, but can be made to fail catastrophically in a few situations, see for example: https://svn.boost.org/trac10/ticket/11323 Now... it turns out that with C++14 and later we now have is_detected which can test the validity of almost any expression... and I'm wondering if there's a cunning way to press this into action to create a more accurate is_virtual_base_of, but I'm having trouble coming up with anything. Any bright ideas? Note that an explicit static_cast can't be tested for, though we can use is_constructible if required. Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 3

[gsoc18] Seeking a mentor for Boost.Geometry project 2: Nearly antipodal points distance accuracy improvement
by Adeel Ahmad 21 Mar '18

21 Mar '18

Greetings, Congratulations to the Boost community on being selected for GSoC 2018! I recently read through the project ideas listed on the Wiki page, I'm particularly interested in "Boost.Geometry Project 2: Nearly antipodal points distance accuracy improvement". I wanted to know if I should implement a particular algorithm for finding the shortest distance between two points? There are many options, such as the Haversine formula, Equirectangular approximation, and Rhumb line. Or, would any of these be fine? Additionally, could the mentor please let me know on how to share the code? I was thinking of creating a GitHub repository, this would make it easier for the mentor to provide feedback. Would that be alright? I was also a participant in GSoC 2017 with the OpenAstronomy organization. My project was to design and create a Python client for Hierarchical Progressive Surveys. It enabled users to view astronomical figures in an interactive environment. More details of the software package can be found here (https://hips.readthedocs.io/en/latest/getting_started.html). I look forward to your reply. Kind regards, Adeel

2 4

[gsoc18] how to share a competency test
by vardhan gupta 11 Mar '18

11 Mar '18

Hi, My name is Vardhan Gupta. I am a 2nd year undergraduate student from IIT Kanpur. I am interested in working on project #3 of Boost.uBLAS on adding multicore and gpu computations to uBLAS. I have created a private repository of it's competency test on gitlab. Now, I am having trouble in sharing the repository with the mentors since I do not have their email address. how do I share it/find their e-mail address? Thank you, Yours sincerely; Vardhan Gupta

6 10

[foreach][polygon][xpressive][bimap][ptr_container][gil][assign][typeof][msm] PRs for removing executable attribute for files
by Edward Diener 08 Mar '18

08 Mar '18

The following libraries still have PRs, which I have previously submitted, for removing the executable attribute for one or more files: foreach polygon xpressive bimap ptr_container gil assign typeof msm None of these PRs affect anything other than the file attribute, so no testing is needed AFAICS since no code changes. If the maintainers of the above libraries, or someone else with write access to these libraries, can merge the appropriate PR to 'develop', and then merge 'develop' to 'master', we can get rid of having any files with their executable attribute set in the next release.

5 13

Re: [boost] [system] [teeks99] Mass test failures on MSVC-14.0
by Andrey Semashev 08 Mar '18

08 Mar '18

On 02/26/18 17:20, Tom Kent wrote: > On Mon, Feb 26, 2018 at 6:56 AM, Andrey Semashev via Boost > <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: > > On 02/26/18 15:43, Tom Kent via Boost wrote: > > On Sat, Feb 24, 2018 at 3:45 PM, Andrey Semashev via Boost < > boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: > > Hi, > > Most of Boost.System tests are failing on the > teeks99-09-f-win2016-64on64 > tester, MSVC-14.0[1]. The test logs don't show any errors > and I can't > reproduce it locally. I'm seeing similar test failures in > other libraries, > like Boost.Atomic for example, and the links point to > Boost.System. > > Is it possible to get the error log from the tester? > > >> > > Here's all 82MB of it: > > http://boost.teeks99.com/temp/teeks99-09-f-results-bjam-2018-02-26.log > <http://boost.teeks99.com/temp/teeks99-09-f-results-bjam-2018-02-26.log> > > > > But be warned, I just moved the -09 runner onto a new (Win 2016) VM about a > > week ago, and there have been some teething issues. If all goes well, the > > -f run should hit again in the next 24-48hrs. > > The link returns 403: Forbidden. > > Try again now. Sorry about that. I got the log now, thanks. The relevant part seems to be this: msvc.link.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll call "D:\teeks99-09\run\results\boost\bin.v2\standalone\msvc\msvc-14.0\adrs-mdl-64\archt-x86\msvc-setup.bat" amd64 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X64 /MANIFEST /subsystem:console /out:"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll" /IMPLIB:"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib" @"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% Creating library D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib and object D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.exp msvc.manifest.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll if exist "D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.manifest" ( call "D:\teeks99-09\run\results\boost\bin.v2\standalone\msvc\msvc-14.0\adrs-mdl-64\archt-x86\msvc-setup.bat" amd64 >nul mt -nologo -manifest "D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.manifest" "-outputresource:D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll;2" ) 'mt' is not recognized as an internal or external command, operable program or batch file. ...failed msvc.manifest.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb... ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb I think, this problem has been discussed on the list not long ago - `mt` being not found on the system after some MSVC update: http://boost.2283326.n4.nabble.com/build-msvc-14-linker-step-failing-tc4701… Looks like MSVC needs to be reinstalled or installed on a separate machine. Will you be able to fix this?

3 7

[gsoc2018] Project 1.1: Add statistics and machine learning functions
by Dattatreya Mohapatra 07 Mar '18

07 Mar '18

Hi, My name is Dattatreya Mohapatra. I am an undergrad at IIIT Delhi, majoring in CS. I am interested in working on extending the Boost.uBLAS library as a project. I have taken courses on Linear Algebra and Machine Learning in the past, so I have a decent basic understanding of the subject. I have used C++11 in several of my course projects, so I have some familiarity with advanced features like lambdas and template programming. I have gone through the earlier threads on the same, and have started working on the core-competency test (CCT). Can the mentors of this project please guide me as to how should I get the CCT reviewed when its ready? Also, is there anything else I should look at apart from the documentation which would be helpful? Thanks and regards, Dattatreya Mohapatra

2 2

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

[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

[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