Closed mincequi closed 1 year ago
I committed a patch to workaround the problem, I don't have the toolchain to test, please check if it works.
Nice, one more thing:
in model.hpp
you seem to forward declare std::variant
. This causes the following issue:
In file included from /Users/minski/bustache/include/bustache/render.hpp:10:
/Users/minski/bustache/include/bustache/model.hpp:694:33: error: reference to 'variant' is ambiguous
struct impl_compatible<std::variant<T...>>
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/c++/v1/variant:1261:28: note: candidate found by name lookup is 'std::__1::variant'
class _LIBCPP_TEMPLATE_VIS variant
^
/Users/minski/bustache/include/bustache/model.hpp:32:11: note: candidate found by name lookup is 'std::variant'
class variant;
^
/Users/minski/bustache/include/bustache/model.hpp:696:45: error: reference to 'variant' is ambiguous
static value_ptr get_value_ptr(std::variant<T...> const& self)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/c++/v1/variant:1261:28: note: candidate found by name lookup is 'std::__1::variant'
class _LIBCPP_TEMPLATE_VIS variant
^
/Users/minski/bustache/include/bustache/model.hpp:32:11: note: candidate found by name lookup is 'std::variant'
class variant;
^
2 errors generated.
Simply including <variant>
in model.hpp
fixes the issue for me:
#include <functional>
+#include <variant>
#ifdef BUSTACHE_USE_FMT
#include <fmt/format.h>
#elif defined(__cpp_lib_format)
@@ -26,11 +27,13 @@
#include <iterator>
#endif
+/*
namespace std
{
template<class... T>
class variant;
};
+*/
What do you think?
Because the use of std::variant is optional, I tried to avoid unnecessary include if the user doesn't use it. But technically speaking, one should not forward declare standard types 😥. What you proposed is absolutely right.
Hey there, i stumbled across your lib when i was searching for a performant template engine. Compiling with GCC12 is just fine. However, it fails with clang 14 on linux.
Next thing to tackle is macOS compatiblity. clang14 from macOS does not support
std::ranges
. Might there be a workaround for this? In other cases, macOS users would be locked out from your lib.Thanks and best regards