Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add compiler compatibility list #25

Open
B3rn475 opened this issue Apr 13, 2016 · 32 comments
Open

Add compiler compatibility list #25

B3rn475 opened this issue Apr 13, 2016 · 32 comments

Comments

@B3rn475
Copy link

B3rn475 commented Apr 13, 2016

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
Copy link
Owner

ryanhaining commented Apr 13, 2016 •
edited
Loading

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
Copy link

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
Copy link
Owner

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
Copy link

Alexhuszagh commented Aug 3, 2016 •
edited
Loading

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
Copy link

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
Copy link

dnbaker commented Oct 6, 2016

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
Copy link
Owner

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
Copy link

dnbaker commented Oct 7, 2016

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
Copy link
Owner

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
Copy link

dnbaker commented Oct 7, 2016

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
.

@ryanhaining
Copy link
Owner

ryanhaining commented Oct 7, 2016 •
edited
Loading

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
Copy link

pfultz2 commented Oct 7, 2016

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

@ryanhaining
Copy link
Owner

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

@Alexhuszagh
Copy link

Alexhuszagh commented May 11, 2018 •
edited
Loading

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

@ryanhaining
Copy link
Owner

ryanhaining commented May 11, 2018 via email

@Alexhuszagh
Copy link

@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
Copy link
Owner

ryanhaining commented May 11, 2018 via email

@ryanhaining
Copy link
Owner

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

@Alexhuszagh
Copy link

@ryanhaining Thanks, foolish optimism then on my part.

@ryanhaining
Copy link
Owner

ryanhaining commented May 12, 2018 via email

@Bulat-Ziganshin
Copy link

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
Copy link
Owner

ryanhaining commented May 12, 2018 via email

@Bulat-Ziganshin
Copy link

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
Copy link
Owner

ryanhaining commented May 12, 2018 •
edited
Loading

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
Copy link
Owner

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
Copy link
Owner

ryanhaining commented May 14, 2018 •
edited
Loading

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
Copy link
Owner

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

@Bulat-Ziganshin
Copy link

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

@ryanhaining
Copy link
Owner

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

@frboyer
Copy link
Contributor

frboyer commented Sep 10, 2018

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

@ryanhaining
Copy link
Owner

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

@ryanhaining
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@ryanhaining @pfultz2 @frboyer @Bulat-Ziganshin @B3rn475 @iliocatallo @dnbaker @Alexhuszagh