Add compiler compatibility list about cppitertools HOT 32 OPEN

from cppitertools.

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

from cppitertools.

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

from cppitertools.

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)!
}

from cppitertools.

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).

from cppitertools.

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.

from cppitertools.

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.

from cppitertools.

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).

from cppitertools.

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/

from cppitertools.

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.

from cppitertools.

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());
}

from cppitertools.

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?

from cppitertools.

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.

from cppitertools.

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

from cppitertools.

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
#25 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGHaVQRRd3KDkdTH528St2vstsJbZNsoks5qxnXfgaJpZM4IGZT2
.

from cppitertools.

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+

from cppitertools.

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

from cppitertools.

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

from cppitertools.

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

from cppitertools.

from cppitertools.

@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.

from cppitertools.

from cppitertools.

@ryanhaining Thanks, foolish optimism then on my part.

from cppitertools.

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.

from cppitertools.

from cppitertools.

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.

from cppitertools.

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

from cppitertools.

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!
}

from cppitertools.

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

from cppitertools.

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

from cppitertools.

The bug is marked as fixed in MSVC 16.0 https://developercommunity.visualstudio.com/content/problem/252157/sfinae-error-depends-on-name-of-template-parameter.html

from cppitertools.

I've added a travis-ci and appveyor status to the README, this will force me to keep up with what's working and what isn't

from cppitertools.