Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-10 12:09:39


"Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:

> Alexander Nasonov wrote:
>
>> ... and only in there saying:
>> ../../../boost/typeof/typeof.hpp(37): error: more than one partial
> specialization matches the template argument list of class
> "boost::type_of::encode_type_impl<boost::type_of::encode_type_impl<boost::ty
> pe_of::detail::push_back<boost::type_of::detail::push_back<boost::mpl::vecto
> r0<boost::mpl::void_>, boost::mpl::int_<131093>>::type,
> boost::mpl::int_<458770>>::type, const int *const>::type, const int [20]>"
>> "boost::type_of::encode_type_impl<V, const T>"
>> "boost::type_of::encode_type_impl<V, T [N]>"
>
> Hmmm, do you think this is a compiler bug or a standard behavior? const
> int[20] looks to me like an array of const integers, so I would definitely
> expect the second specialization envoked, but maybe it's also legal to view
> it something like a const integer that happens to be here 20 times? Do you
> think similar problems are possible in other contexts?

In the first specialization, T is int[20]. This is due to the
strange way in which cv-qualification "commutes" with array bounds:

  typedef int a20[20];
  typedef a20 const ca20i; // an const array of 20 ints

  typedef int const a20ci[20]; // an array of 20 const ints.
  template <class T> struct X;
  template <class T> struct X<T const> {};
  // template <class T, int N> struct X<T[N]> {}; -- uncomment for ambiguity
  X<ca20i> a; // the same type
  X<a20ci> b;

Here's how you check whether they're equally specialized:

  synthesize unique types and values for T and N in each specialization:
  
    template <class T> struct X<T const> {}; // T = struct Foo {};
    template <class T, int N> struct X<T[N]> {}; // T = struct Bar {};, N = Q

  can "Foo const" match "T[N]"? No.
  can "Bar[Q]" match "T const"? No.

Therefore: they're equally specialized.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk