search for: declval

Trying to build LLVM 3.8 (or trunk) with the 2016 Intel C++ compiler. It fails on the std::declval feature: llvm-3.8/include/llvm/ADT/iterator_range.h(63): error: namespace "std" has no member "declval" iterator_range<decltype(begin(std::declval<T>()))> drop_begin(T &&t, int n) { An isolated std::declval example shows that this compiler doesn't...

...--- type_traits (revision 164877) +++ type_traits (working copy) @@ -1187,10 +1187,15 @@ #endif // _LIBCPP_HAS_NO_VARIADICS +template <class _Fst, class _Snd> +struct __select_2nd { + typedef _Snd type; +}; + // is_assignable template <class _Tp, class _Arg> -decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) +typename __select_2nd<decltype(_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>()), true_type>::type #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES __is_assignable_test(_Tp&&, _Arg&&); #else @@ -1209,7 +1214,7 @@...

...> @@ -1187,10 +1187,15 @@ > > #endif // _LIBCPP_HAS_NO_VARIADICS > > +template <class _Fst, class _Snd> > +struct __select_2nd { > + typedef _Snd type; > +}; > + > // is_assignable > > template <class _Tp, class _Arg> > -decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > +typename __select_2nd<decltype(_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>()), true_type>::type > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > __is_assignable_test(_Tp&&, _Arg&&); > #else &...

On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Reduced testcase: > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > template<typename T> struct B { > struct C { typedef typename A<C*>::type type; }; > typedef typename A<C*>::type type; > }; > B<int> b; > > ... produces ...

...g, but may not work with other compilers. Here is an example: template <class T> struct has_output { private: static double test(...); #if __has_feature(cxx_access_control_sfinae) template <class U, class X> static auto test(U& u, X& x) -> decltype(U::output(std::declval<const X&>(), std::declval<llvm::raw_ostream&>()), char()); #else template <class U, class X> static __typeof__(U::output(std::declval<const X&>(), std::declval<llvm::raw_ostream&>()), char()) test(U& u, X& x); #endif public: static const...

Hey Nick, what's the status on YAML IO? The other thread seems to have died. -- Sean Silva

...;' > > typename map<K,Member*>::iterator it; > > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ > > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of > > member class 'Templ8<int>::Member' requested here > > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > > ^ > > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting > > deduced template arguments into function template > > '__is_assignable_test...

..., creating a dependency cycle between the two instantiations). I'm not at all clear on whether that is permissible behavior for a standard library implementation, but it still seems to be a problem in some cases. libc++'s is_assignable implementation uses SFINAE on this: decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) Now, our case was: _Tp = Member*&, _Arg = Member*. In that case, we use the built-in assignment operator, which produces an lvalue of type Member*. Then we perform argument-dependent lookup looking for an overloaded 'operator,'...

...onst int, Templ8<int>::Member *>>>' typename map<K,Member*>::iterator it; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of member class 'Templ8<int>::Member' requested here decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) ^ /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting deduced template arguments into function template '__is_assignable_test' [with _Tp = Templ8<int>::Me...

...typename map<K,Member*>::iterator it; >> > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ >> > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of >> > member class 'Templ8<int>::Member' requested here >> > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) >> > ^ >> > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting >> > deduced template arguments into function template >> > '__is...

...:Member > *>>>' > typename map<K,Member*>::iterator it; > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of > member class 'Templ8<int>::Member' requested here > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > ^ > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting > deduced template arguments into function template > '__is_assignable_test' [with _Tp = Te...

...ommon interface for accessing >> successors/predecessors in various IR units, such that a type such as >> `typename NodeT::succ_iterator` could be used in templated code. >> > > I /think/ this can be achieved with the existing API by using > "decltype(succ_begin(std::declval<NodeT>()))" instead of the typename > you've got as an example (it looks like succ_begin is the extension point - > but the problem you're having is naming its return type? decltype would be > one option) - you could make a trait wrapper around that or the like if you &g...

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlockBase and clang::CFGBlock. The least invasive

...uccessors/predecessors in various IR units, such that a type such as >>>> `typename NodeT::succ_iterator` could be used in templated code. >>>> >>> >>> I /think/ this can be achieved with the existing API by using >>> "decltype(succ_begin(std::declval<NodeT>()))" instead of the typename >>> you've got as an example (it looks like succ_begin is the extension point - >>> but the problem you're having is naming its return type? decltype would be >>> one option) - you could make a trait wrapper around th...