s*******d
发帖数: 59 | 1 为什么不直接引入对type的操作呢?
比如_Iter_random(Const _Iter1&, Const _Iter2&)返回random_category如果
_Iter1, _Iter2都是random iterator, 否则返回forward_category.
目前的做法是
template
class _Iter_random_helper
{
public:
typedef forward_iterator_tag _Iter_random_cat;
};
template<>
class _Iter_random_helper
iterator_tag>
{
public:
typedef random_access_iterator_tag _Iter_random_cat;
};
template | s*******d
发帖数: 59 | 2 再加上typename关键词来定义类型，比如
typename GetIteratorCategory(typename myType)
{
return iterator_traits::iterator_category;
} | c*****e
发帖数: 11 | 3 considering the efficiency for the two different implementation,
this is finished when compiling period,
the other is determined when run-time
there should be many such cases in stl, otherwise we can just use our own
library.
【在 s*******d 的大作中提到】
: 为什么不直接引入对type的操作呢?
: 比如_Iter_random(Const _Iter1&, Const _Iter2&)返回random_category如果
: _Iter1, _Iter2都是random iterator, 否则返回forward_category.
: 目前的做法是
: template
: class _Iter_random_helper
: {
: public:
: typedef forward_iterator_tag _Iter_random_cat;
: };
| s*******d
发帖数: 59 | 4 typenames are constants during compile. so type1 == type2
doesn't involve runtime check.
And partial specialization is indeed simply comparing types.
What's more, there are already some typename manipulation
keywords such as __is_base_of, __is_class, which are not
standard but frequently used.
So adding one more extension "==" won't be a problem.
Then allowing typename expressions and statements will be
fully reasonable. | c*****e
发帖数: 11 | 5 o, if so, sorry for my statement about efficiency:)
besides, maybe it can be explained from the maintainance cost for the lib
by partialspecialization, maybe it is a little easier to extend current
library, however, using typename, we should change the source code for each
extension. maybe later, we will still add some more specialization into the
library.
【在 s*******d 的大作中提到】
: typenames are constants during compile. so type1 == type2
: doesn't involve runtime check.
: And partial specialization is indeed simply comparing types.
: What's more, there are already some typename manipulation
: keywords such as __is_base_of, __is_class, which are not
: standard but frequently used.
: So adding one more extension "==" won't be a problem.
: Then allowing typename expressions and statements will be
: fully reasonable.
|
|
