Add compiler compatibility list

[B3rn475]

Can you please add the list of compatible compilers? VS 2013 does not support noexcept while VS 2015 finds "unknown size" errors everywhere.

Severity  Code  Description  Project  File  Line  Suppression State
Error  C2133  ' ?? ?? :: ?? ::derefers': unknown size  ...\include\cppitertools\chain.hpp  72

[ryanhaining]

Visual Studio lags so far behind I've never attempted to support it.

I've stayed pretty consistent on supporting gcc and clang with libstdc++ and libc++. I haven't touched VS in almost ten years, so I'd have to figure out if I can even get it working on any computers I have (the only thing I have with windows is pretty old), idk if they support any linux platforms but I'd be surprised if they did. VS has had a rough history with correctly supporting intense template ~~tricks~~ techniques, so I don't know if it would be possible to hack around all of its mistakes.

[iliocatallo]

I was under the impression that the latest VS releases were quite aligned with the standard. If I'm not mistaken, the latest VS update provides a fully compliant C++14 implementation, and it should even already implement some part of the upcoming C++17.

[ryanhaining]

I haven't bothered keeping up with VS because it's always been so bad. It's of course possible they got it together on 2015 (though "unknown size errors everywhere" makes me doubt it).

[Alexhuszagh]

I tested with the new updates using the compiler flag /std:c++14 added to Additional Options. Microsoft has finally gotten their act together. Works like a dream. I've tested this library on Clang, GCC, Intel MSVC, and MSVC, all work with C++14 support.

(Also, note that these options were not available when the post was originally written, it's only been available in the last month).

https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/

[Alexhuszagh]

EDIT: Sorry, I should revise my statement. Some features (such as product) work, however, for certain starmap still does not work with the /std:c++14 on MSVC.

[dnbaker]

I get the following error when simply including the imap header, not using it with -std=c++17 or -std=c++16 on gcc5.1.0.

In file included from ../cppitertools/zip.hpp:4:0,
                 from ../cppitertools/imap.hpp:4,
                 from itertest.cpp:6:
../cppitertools/internal/iterbase.hpp:334:63: error: non-static data member declared ‘auto’
       friend decltype(auto) operator|(T&& x, const Pipeable& p) {

I have another machine with gcc6 that I plan to test on, but I thought I'd add that 5.1.0 is incompatible.

Full compiling program:

#include <vector>
#include <cstdlib>
#include <cstdio>
#include <utility>
#include <string>
//#include <cppitertools/imap.hpp> Compiles with this commented out.

template<typename T, typename fn>
std::vector<T> range_vec(fn func) {
    std::vector<T> ret;
    for(auto p(0); p < 400; ++p) ret.push_back(func(p));
    return ret;
}

int main() {
    std::vector<int> &&r(std::move(range_vec<int>([](int x){return x*x*x;})));
    for(auto i: r) puts(std::to_string(i).data());
}

[ryanhaining]

master tracks c++14, if you're not using -std=c++14 I wouldn't expect anything using imap on master to compile. Your code with that line uncommented works for me under gcc-5.2 and gcc-6.2. I don't have gcc-5.1 handy so perhaps you can give me the compilation command you are issuing and I can try to determine based on that?

[dnbaker]

Sure.

With -std=c++17:

g++ -I. -I.. -I../cppitertools/ itertest.cpp -O3 -DNDEBUG -Wall -Wunreachable-code -o itertest -lz -std=c++17
In file included from ../cppitertools/zip.hpp:4:0,
                 from ../cppitertools/imap.hpp:4,
                 from itertest.cpp:6:
../cppitertools/internal/iterbase.hpp:334:63: error: non-static data member declared ‘auto’
       friend decltype(auto) operator|(T&& x, const Pipeable& p) {
                                                               ^
make: *** [itertest] Error 1

With -std=c++14:

g++ -I. -I.. -I../cppitertools/ itertest.cpp -O3 -DNDEBUG -Wall -Wunreachable-code -o itertest -lz -std=c++14
In file included from ../cppitertools/zip.hpp:4:0,
                 from ../cppitertools/imap.hpp:4,
                 from itertest.cpp:6:
../cppitertools/internal/iterbase.hpp:334:63: error: non-static data member declared ‘auto’
       friend decltype(auto) operator|(T&& x, const Pipeable& p) {
                                                               ^
make: *** [itertest] Error 1

gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/cm/local/apps/gcc/5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/cm/local/apps/gcc/5.1.0 --enable-languages=c,c++,fortran --with-gmp-include=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-gmp --with-gmp-lib=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-gmp/.libs --with-mpc-include=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-mpc/src --with-mpc-lib=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-mpc/src/.libs --with-mpfr-include=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-mpfr/src --with-mpfr-lib=/root/rpmbuild/BUILD/gcc-5.1.0-obj/../gcc-5.1.0/our-mpfr/src/.libs
Thread model: posix
gcc version 5.1.0 (GCC)

I've found this compiler fails to implement (at least correctly) some C++14 features before, such as std::literals::string_literals. Even though it's available in the C++14 standard, gcc5.1.0 will only compile correctly with -std=c++17.

[ryanhaining]

I still can't reproduce with gcc-5.2, I'll build gcc-5.1 today and get back to you. The error message doesn't even make sense to me, it's obviously not declaring a data member. This is weird. In the meantime if you would try with gcc-5.2 or 6.x that would be helpful

[dnbaker]

It works great on OSX with gcc6 (where I've been testing list comprehension-esque applications).

I've just given up on 5.1 on the cluster. If I decide to use cppitertools for deployment there, I think I'll just have to ask them to install 5.2+.

On Fri, Oct 7, 2016 at 12:39 PM, Ryan Haining [email protected] wrote:

I still can't reproduce with gcc-5.2, I'll build gcc-5.1 today and get back to you. The error message doesn't even make sense to me, it's obviously not declaring a data member. This is weird. In the meantime if you would try with gcc-5.2 or 6.x that would be helpful

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ryanhaining/cppitertools/issues/25#issuecomment-252301049, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHaVQRRd3KDkdTH528St2vstsJbZNsoks5qxnXfgaJpZM4IGZT2 .

[ryanhaining]

Okay just finished building gcc-5.1 and got the same error. This bug says it was fixed in 5.2, it's because of the friend.

To be clear, as of this comment master works on gcc-5.2+

[pfultz2]

Gcc 5.1 has lots of problems/regressions. It's best to declare it unsupported, and use gcc 5.2.

[ryanhaining]

clang-3.7 still works, haven't tried with anything earlier yet

[Alexhuszagh]

@ryanhaining It may be worth checking if MSVC now works: according to the MSVC team, it now fully conforms to the C++ standard

[ryanhaining]

That "But what about…?" section doesn't give me a good feeling. If range-v3 and boost.hana have problems I probably will too. Also need to figure out a way to get and test it with msvc that doesn't slow everything to a crawl. I only boot windows a couple times a year and something is always broken when I do

On Fri, May 11, 2018, 3:21 PM Alexander Huszagh [email protected] wrote:

@ryanhaining https://github.com/ryanhaining It may be worth checking if MSVC now works:

https://blogs.msdn.microsoft.com/vcblog/2018/04/26/announcing-msvc-conforms-to-the-c-standard/?utm_source=newsletter_mailer&utm_medium=email&utm_campaign=weekly

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ryanhaining/cppitertools/issues/25#issuecomment-388500102, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFrWR-GGBH9Ux7G6zMI0O0Y8Z0yB7OFks5txg8DgaJpZM4IGZT2 .

[Alexhuszagh]

@ryanhaining If you would like, I can make a pull request for an AppVeyor configuration file. AppVeyor does free integration testing with MSVC for open-source projects. If not, I just bought a Windows development PC, so I might as well try and give you my results.

[ryanhaining]

Results would be useful. I'll look into appveyor, I hadn't heard about it before

On Fri, May 11, 2018, 3:51 PM Alexander Huszagh [email protected] wrote:

@ryanhaining https://github.com/ryanhaining If you would like, I can make a pull request for an AppVeyor configuration file. AppVeyor does free integration testing with MSVC for open-source projects. If not, I just bought a Windows development PC, so I might as well try and give you my results.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanhaining/cppitertools/issues/25#issuecomment-388504407, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFrWbJ9QcxyJ-XtCa2JJOAQjcTC2ErCks5txhXkgaJpZM4IGZT2 .

[ryanhaining]

Tried Appveyor with VS2017 and it couldn't get past accumulate (the first one)

[Alexhuszagh]

@ryanhaining Thanks, foolish optimism then on my part.

[ryanhaining]

Nbd, it's not the first time Microsoft has made a claim like this

On Fri, May 11, 2018, 6:18 PM Alexander Huszagh [email protected] wrote:

@ryanhaining https://github.com/ryanhaining Thanks, foolish optimism then on my part.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanhaining/cppitertools/issues/25#issuecomment-388520109, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFrWWEbXFG-t-c_zrzUhZUa-rwZ9Qzyks5txjhJgaJpZM4IGZT2 .

[Bulat-Ziganshin]

Are you made sure that AppVeyor compiled with latest 15.7 sub-release?

BTW, I really like the "What about" section. Now MSVC fully conforms to Standard, except that it have the lot of bugs. But seriously, they work on it, and probably it will be finished in next 6-12 months.

[ryanhaining]

Maybe I missed specific option? I just chose 64 bit VS017. If anyone has access to the latest I'd be interested to see the results.

Idk what they think conforming to the standard means. Maybe it's the things they knew they were violating before, and now it's just the things they aren't intentionally violating?

On Fri, May 11, 2018, 10:07 PM Bulat-Ziganshin [email protected] wrote:

Are you made sure that AppVeyor compiled with latest 15.7 sub-release?

BTW, I really like the "What about" section. Now MSVC fully conforms to Standard, except that it have the lot of bugs. But seriously, they work on it, and probably it will be finished in next 6-12 months.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanhaining/cppitertools/issues/25#issuecomment-388530503, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFrWahs992XvVE7ButClvhmHXKLi6Ibks5txm4LgaJpZM4IGZT2 .

[Bulat-Ziganshin]

Well, like Win10, VS2017 compiler is updated each 3-6 months. Since its debut a year ago, we got 15.3, 15.5 and now 15.7 releases that made changes to compiler (even releases are mainly improving the IDE). I have no idea whether AppVeyor provides latest compiler version but the compiler version should be seen in compilation log. Also note that by default VS compiles in C++14 mode and that there is option /permissive- that disables some MS deviations from Standard.

what they think conforming to the standard means

Bugs are just bugs. Hana/Range3 are using C++ tricks like crazy. My understanding is that 99.9% of Standard-compliant code now should compile successfully.

[ryanhaining]

The first line in the cl.exe compiler output is a warning.

Hana/Range3 are using C++ tricks like crazy

So am I. I would've been really surprised if it msvc could compile my code but not range-v3

[ryanhaining]

I got the latest msvc and gave it a shot on my own computer. It exploded pretty bad, though the error is a pretty straight-forward SFINAE issue with msvc. Below is a shortened version of the base code underlying most of the tools that support the pipe syntax, which msvc can't handle though gcc has no problem with it

#include <iterator>

namespace test {
    namespace getters {
        using std::begin;
        template <typename T>
        auto get_begin(T& t) -> decltype(begin(t)) {
            return begin(t);
        }
    }

    template <typename Container>
    using iterator_type = decltype(getters::get_begin(std::declval<Container&>()));


    template <typename T, typename = void>
    struct IsIterable : std::false_type {};

    template <typename T>
    struct IsIterable<T, std::void_t<iterator_type<T>>> : std::true_type {};
}

int main() {
    int a[10]{};
    using Iterator = test::iterator_type<decltype(a)>; // msvc: works fine
    static_assert(test::IsIterable<decltype(a)>::value); // msvc: false!
}

[ryanhaining]

Okay, get ready to have your minds blown. I tried to bring down the size of this, and it looks like msvc fails but the failure depends on the name of the template parameter. If you use a different template parameter name in the type alias than in the struct that uses it for its SFINAE expression, it fails. If you use the same name, it passes. gcc can handle either, obviously. I'm hoping I'm missing something that's right in front of my face here, msvc can't possible be this weird with its failures can it?

#include <type_traits>

namespace tests {
// if 0 to fail, if 1 to pass
#if 0
    template <typename T>
    using func_type = decltype(T{}.func());
#else
    template <typename U>
    using func_type = decltype(U{}.func());
#endif

    template <typename, typename = void>
    struct HasFunc : std::false_type {};

    template <typename T>
    struct HasFunc<T, std::void_t<func_type<T>>> : std::true_type {};
}

struct A {
    int func() const { return 0; }
};

int main() {
    static_assert(tests::HasFunc<A>{}); // msvc: false (when using typename U above)!
}

[ryanhaining]

This is ridiculous: https://medium.com/@ryanhaining/the-weirdest-error-ive-found-in-a-compiler-msvc-2017-ade2e9da0e20

[Bulat-Ziganshin]

I wonder whether you (and goldbolt) are really using 15.7 or year-old basic MSVC 2017 compiler

[ryanhaining]

Godbolt isn't, but I am, and so is this guy

[frboyer]

For those interested, I made a pull request ( #47 ) passing all tests under latest MSVC (tested on Visual Studio 15.9 pre 1; cl 19.15.26726).