Search Results

Search found 6 results on 1 pages for 'typetraits'.

Page 1/1 | 1 

  • How `is_base_of` works?

    - by Alexey Malistov
    Why the following code works? typedef char (&yes)[1]; typedef char (&no)[2]; template <typename B, typename D> struct Host { operator B*() const; operator D*(); }; template <typename B, typename D> struct is_base_of { template <typename T> static yes check(D*, T); static no check(B*, int); static const bool value = sizeof(check(Host<B,D>(), int())) == sizeof(yes); }; //Test sample class Base {}; class Derived : private Base {}; //Exspression is true. int test[is_base_of<Base,Derived>::value && !is_base_of<Derived,Base>::value]; Note that B is private base. Note that operator B*() is const. How does this work? Why this works? Why static yes check(D*, T); is better than static yes check(B*, int); ?

    Read the article

  • C++ STL type_traits question.

    - by Kim Sun-wu
    I was watching the latest C9 lecture and noticed something interesting.. In his introduction to type_traits, Stephan uses the following (as he says, contrived) example: template <typename T> void foo(T t, true_type) { std::cout << t << " is integral"; } template <typename T> void foo(T t, false_type) { std::cout << t << " is not integral"; } template <typename T> void bar(T t) { foo(t, typename is_integral<T>::type()); } This seems to be far more complicated than: template <typename T> void foo(T t) { if(std::is_integral<T>::value) std::cout << "integral"; else std::cout << "not integral"; } Is there something wrong with the latter way of doing it? Is his way better? Why? Thanks.

    Read the article

  • Why `is_base_of` works with private inheritance?

    - by Alexey Malistov
    Why the following code works? typedef char (&yes)[1]; typedef char (&no)[2]; template <typename B, typename D> struct Host { operator B*() const; operator D*(); }; template <typename B, typename D> struct is_base_of { template <typename T> static yes check(D*, T); static no check(B*, int); static const bool value = sizeof(check(Host<B,D>(), int())) == sizeof(yes); }; //Test sample class B {}; class D : private B {}; //Exspression is true. int test[is_base_of<B,D>::value && !is_base_of<D,B>::value]; Note that B is private base. Note that operator B*() is const. How does this work? Why this works? Why static yes check(D*, T); is better than static yes check(B*, int); ?

    Read the article

  • Parameter pack aware std::is_base_of()

    - by T. Carter
    Is there a possibility to have a static assertion whether a type provided as template argument implements all of the types listed in the parameter pack ie. a parameter pack aware std::is_base_of()? template <typename Type, typename... Requirements> class CommonBase { static_assert(is_base_of<Requirements..., Type>::value, "Invalid."); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ parameter pack aware version of std::is_base_of() public: template <typename T> T* as() { static_assert(std::is_base_of<Requirements..., T>::value, "Invalid."); return reinterpret_cast<T*>(this); } };

    Read the article

  • Get result type of function

    - by Robert
    I want to specialize a template function declared as: template<typename Type> Type read(std::istream& is); I then have a lot of static implementations static int read_integer(std::istream& is); a.s.o. Now I'd like to do a macro so that specialization of read is as simple as: SPECIALIZE_READ(read_integer) So I figured I'd go the boost::function_traits way and declare SPECIALIZE_READ as: #define SPECIALIZE_READ(read_function) \ template<> boost::function_traits<read_function>::result_type read(std::istream& is) { \ return read_function(is); \ } but VC++ (2008) compiler complains with: 'boost::function_traits' : 'read_integer' is not a valid template type argument for parameter 'Function' Ideas ?

    Read the article

  • C++ type-checking at compile-time

    - by Masterofpsi
    Hi, all. I'm pretty new to C++, and I'm writing a small library (mostly for my own projects) in C++. In the process of designing a type hierarchy, I've run into the problem of defining the assignment operator. I've taken the basic approach that was eventually reached in this article, which is that for every class MyClass in a hierarchy derived from a class Base you define two assignment operators like so: class MyClass: public Base { public: MyClass& operator =(MyClass const& rhs); virtual MyClass& operator =(Base const& rhs); }; // automatically gets defined, so we make it call the virtual function below MyClass& MyClass::operator =(MyClass const& rhs); { return (*this = static_cast<Base const&>(rhs)); } MyClass& MyClass::operator =(Base const& rhs); { assert(typeid(rhs) == typeid(*this)); // assigning to different types is a logical error MyClass const& casted_rhs = dynamic_cast<MyClass const&>(rhs); try { // allocate new variables Base::operator =(rhs); } catch(...) { // delete the allocated variables throw; } // assign to member variables } The part I'm concerned with is the assertion for type equality. Since I'm writing a library, where assertions will presumably be compiled out of the final result, this has led me to go with a scheme that looks more like this: class MyClass: public Base { public: operator =(MyClass const& rhs); // etc virtual inline MyClass& operator =(Base const& rhs) { assert(typeid(rhs) == typeid(*this)); return this->set(static_cast<Base const&>(rhs)); } private: MyClass& set(Base const& rhs); // same basic thing }; But I've been wondering if I could check the types at compile-time. I looked into Boost.TypeTraits, and I came close by doing BOOST_MPL_ASSERT((boost::is_same<BOOST_TYPEOF(*this), BOOST_TYPEOF(rhs)>));, but since rhs is declared as a reference to the parent class and not the derived class, it choked. Now that I think about it, my reasoning seems silly -- I was hoping that since the function was inline, it would be able to check the actual parameters themselves, but of course the preprocessor always gets run before the compiler. But I was wondering if anyone knew of any other way I could enforce this kind of check at compile-time.

    Read the article

1