Add compiler compatibility list

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

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.

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.

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

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/

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.

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

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?

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.

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

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 notifications@github.com
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
.

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+

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

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

@ryanhaining

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

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

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

@ryanhaining

@ryanhaining Thanks, foolish optimism then on my part.

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

…

On Fri, May 11, 2018, 6:18 PM Alexander Huszagh ***@***.***> 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 <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFrWWEbXFG-t-c_zrzUhZUa-rwZ9Qzyks5txjhJgaJpZM4IGZT2> .

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.

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

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.

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

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

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

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

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

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

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

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

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

Navigation Menu

Repository navigation

Add compiler compatibility list #25

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add compiler compatibility list #25

Description

Activity

ryanhaining commented on Apr 13, 2016

iliocatallo commented on Apr 13, 2016

ryanhaining commented on Apr 13, 2016

Alexhuszagh commented on Aug 3, 2016

Alexhuszagh commented on Aug 4, 2016

dnbaker commented on Oct 6, 2016

ryanhaining commented on Oct 7, 2016

dnbaker commented on Oct 7, 2016

ryanhaining commented on Oct 7, 2016

dnbaker commented on Oct 7, 2016

ryanhaining commented on Oct 7, 2016

pfultz2 commented on Oct 7, 2016

ryanhaining commented on Oct 8, 2016

Alexhuszagh commented on May 11, 2018

ryanhaining commented on May 11, 2018

2 remaining items

ryanhaining commented on May 12, 2018

Alexhuszagh commented on May 12, 2018

ryanhaining commented on May 12, 2018

Bulat-Ziganshin commented on May 12, 2018

ryanhaining commented on May 12, 2018

Bulat-Ziganshin commented on May 12, 2018

ryanhaining commented on May 12, 2018

ryanhaining commented on May 14, 2018

ryanhaining commented on May 14, 2018

ryanhaining commented on May 14, 2018

Bulat-Ziganshin commented on May 14, 2018

ryanhaining commented on May 14, 2018

frboyer commented on Sep 10, 2018

ryanhaining commented on Sep 11, 2018

ryanhaining commented on Oct 28, 2018

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions