Joel Falcou wrote:
But there is a few SIMD operator like for example exponent that can take any vec<T> and return a vec<uint32_t>.
Currently the operators/functions use the underlying simd expression info to determine their domain, thus leading to problem like :
exponent(vec<float>) + vec<uint32_t>
failing to compile cause the domain are not the same.
Now that I think of it, there is maybe a more elegant solution than hacking the domain check but i'M a bit short of ideas atm.
Strange, you shouldn't be seeing this error in this case. For operator(), Proto doesn't enforce domains to match -- the resulting expression assumes the domain of the lhs. Consider the following: #include <boost/proto/proto.hpp> namespace proto = boost::proto; template<class E> struct wrap1; template<class E> struct wrap2; struct domain1 : proto::domain<proto::pod_generator<wrap1> > {}; struct domain2 : proto::domain<proto::pod_generator<wrap2> > {}; template<class E> struct wrap1 { BOOST_PROTO_EXTENDS(E, wrap1<E>, domain1) }; template<class E> struct wrap2 { BOOST_PROTO_EXTENDS(E, wrap2<E>, domain2) }; wrap1<proto::terminal<int>::type> _1 = {{1}}; wrap2<proto::terminal<int>::type> _2 = {{2}}; int main() { _1(_2) + _1; // OK // _1(_2) + _2; // ERROR } _1 and _2 are in different domains, but _1(_2) is allowed and is in the domain of _1. That's why the expression "_1(_2) + _1" is permitted, but "_1(_2) + _2" is not. You might have to post your code for us to get to the bottom of this. -- Eric Niebler BoostPro Computing http://www.boostpro.com