Project claims to be C++11-compatible but isn't

[main--]

Pretty much all of stringbuilder.h relies on std::make_tuple being constexpr like this:

/*!
 * \brief Allows construction of string-tuples via %-operator, eg. string1 % "string2" % string3.
 */
constexpr auto operator %(const std::string &lhs, const std::string &rhs) -> decltype(std::make_tuple(&lhs, &rhs))
{
    return std::make_tuple(&lhs, &rhs);
}

Correct my if I'm wrong, but AFAICS this assumption only holds for C++14 and not for C++11.

On freebsd (or any llvm-based platform, I'd guess) this library fails to compile as C++11.

[Martchus]

You're right. I've just looked it up and indeed those tuple helpers are not constexpr in C++11 yet: http://en.cppreference.com/w/cpp/utility/tuple/tuple_cat http://en.cppreference.com/w/cpp/utility/tuple/make_tuple

Not sure why g++ and clang++ don't complain when I build it here under Arch Linux. The C++ version should be set correctly via CMake and I also get complaints in other cases, eg. when using std::make_unique or literals for std::string.

Of course I could just replace the constexpr here with inline but I'm not sure whether it is time to just switch to C++14 anyways. Do you actually need this to be C++11 compliant or is this just about the wrong description in the README.md and the wrong setting the the CMake project?

[main--]

Not sure why g++ and clang++ don't complain when I build it here under Arch Linux. The C++ version should be set correctly via CMake and I also get complaints in other cases, eg. when using std::make_unique or literals for std::string.

That's probably because glibc defines it as constexpr regardless of the language version:

  // NB: DR 705.
  template<typename... _Elements>
    constexpr tuple<typename __decay_and_strip<_Elements>::__type...>
    make_tuple(_Elements&&... __args)
    {
      typedef tuple<typename __decay_and_strip<_Elements>::__type...>
        __result_type;
      return __result_type(std::forward<_Elements>(__args)...);
    }

Of course I could just replace the constexpr here with inline but I'm not sure whether it is time to just switch to C++14 anyways. Do you actually need this to be C++11 compliant or is this just about the wrong description in the README.md and the wrong setting the the CMake project?

Right now, I'm trying to make this work on FreeBSD 10.3. I have to use a newer clang from ports anyways to make it compile (or else I get a bunch of ambiguous function call errors), so switching to C++14 is not a big deal for me personally.

[Martchus]

Good, switched to C++14. Wanted to do this anyways in near future so why not now.

[main--]

Thanks!