Создание класса стиля кортежа, который оптимизирует неиспользуемые разделы

Это больше вопрос того, как компилятор C ++ обрабатывает вызовы const typeid.

Здравствуйте! Я пытаюсь создать класс в стиле кортежа, настроенный таким образом, чтобы мне не приходилось переписывать кучу кода со специализациями.

Так что это общая идея:

struct null_type{};

template <typename T1,typename T2=null_type,typename T3=null_type>
class ptestclass
{
private:
template<typename K1,typename K2,typename K3>
class barclass
{
public:
static inline void bar(std::tuple<K1,K2,K3>& vals,K1* otherval1,K2* otherval2,K3* otherval3)
{
Foo(tr1::get<0>(vals),*otherval1);
Foo(tr1::get<1>(vals),*otherval2);
Foo(tr1::get<2>(vals),*otherval3);
}
};
template<typename K1,typename K2>
class barclass<K1,K2,null_type>
{
public:
static inline void bar(std::tuple<K1,K2,null_type>& vals,K1* otherval1,K2* otherval2,null_type* otherval3)
{
Foo(tr1::get<0>(vals),*otherval1);
Foo(tr1::get<1>(vals),*otherval2);
}
};
template<typename K1>
class barclass<K1,null_type,null_type>
{
public:
static inline void bar(std::tuple<K1,null_type,null_type>& vals,K1* otherval1,null_type* otherval2,null_type* otherval3)
{
Foo(tr1::get<0>(vals),*otherval1);
}
};

/*
*Old Bar function...much more readable than bar class, but you cannot partially specialize
*member functions of a class
*
void inline bar(std::tuple<T1,T2,T3> otherval)
{
if (typeid(T1) != typeid(null_type))//constant check hopfully optomized out
{
Foo(vals.get(1),otherval.get(1));
}
if (typeid(T2) != typeid(null_type))//constant check hopfully optomized out
{
Foo(vals.get(2),otherval.get(2));
}
if(typeid(T3) != typeid(null_type))//constant check hopfully optomized out
{
Foo(vals.get(3),otherval.get(3));
}

}
*/
std::tuple<T1,T2,T3> vals;template<typename K>
void static inline Foo(K& val,K& otherval)
{
//inlineable, short function that is called many (millions) of times per iteration
val += otherval;
}

template<>
void inline Foo<null_type>(null_type& val,null_type& otherval)
{
//inlineable, short function that is called many (millions) of times per iteration
throw "Foo called on null type";
}

public:
ptestclass()
{
printf("made object");
}
void one_iteration(T1* otherval1,T2* otherval2,T3* otherval3,size_t count)
{
for (int i = 0; i < count; ++i)
{
barclass<T1,T2,T3>::bar(vals,otherval1+i,otherval2+i,otherval3+i);
}
}
};

//exposed public class with specialized one_iteration interfaces
template <typename T1,typename T2=null_type,typename T3=null_type>
class testclass : public ptestclass<T1,T2,T3>
{
public:
void one_iteration(T1* otherval1,T1* otherval2,T1* otherval3,size_t count)
{
ptestclass::one_iteration(otherval1,otherval2,otherval3,count);
}
};

template <typename T1>
class testclass<T1,null_type,null_type> : public ptestclass<T1,null_type,null_type>
{
public:
void one_iteration(T1* otherval1,size_t count)
{
ptestclass::one_iteration(otherval1,NULL,NULL,count);
}
};

Итак, мой вопрос: возможна ли такая оптимизация в C ++? Если нет, то для меня, вероятно, будет более целесообразно использовать модель наследования на дочерних узлах, а не шаблон на этом уровне. Однако я стараюсь избегать постоянной проверки количества указанных типов и стоимости косвенного обращения.

Я собираюсь начать углубляться в сборку, чтобы посмотреть, делает ли это компилятор … На всякий случай, если это не стандартизированное поведение, я использую Microsoft Visual C ++ Compiler 10.0.

0

Решение

Я думаю, что я неправильно понял ваш вопрос, когда я поставил свой предыдущий комментарий.

Предполагая, что вы можете использовать C ++ 11 или Boost, вы можете использовать что-то вроде !std::is_same< T1, null_type >::value /*or boost::is_same...*/ вместо typeid (T1)! = typeid (null_type). При этом используется TMP для преобразования в константу времени компиляции, которую большинство компиляторов без проблем оптимизируют.

Это больше вопрос того, как компилятор C ++ обрабатывает вызовы const typeid.

Я не ответил на этот конкретный вопрос, но если я понимаю, что вы на самом деле искали, вышеприведенного должно быть достаточно.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]