Boost logo

Boost :

From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-12-02 02:54:07


On Wed, 1 Dec 2004 21:21:02 -0800, Arkadiy Vertleyb
<vertleyb_at_[hidden]> wrote:
> "Allen Yao" <yaozhen_at_[hidden]> wrote
>
> > (1) Is template template parameter supported?
>
> They aren't.
>
> > (2) In your opinion, is it just *possible* to support complex
> > non-type template parameters suppose no matter how ugly the user interface
> > will be?
>
> It all depends on:
>
> 1) whether it is possible to represent this as a number of compile-time
> integers, and
> 2) whether it's possible to return this as a result of a meta-function.
>
> As far as my knowledge of the current state of template meta-programming
> goes, I don't see how it's possible. OTOH, 3 months ago I thought integral
> template parameters are impossible to support. And now, thanks to Peder, we
> do have them :).
>
>
>
> >
> > In addition, I suggest adding a section in the document of the typeof
> > library
> > to mention the problems about complex non-type template parameters,
> > dependendent
> > non-type template parameters and template template parameters, including
> > whether
> > they are supported or not by the current library, and the possibility or
> > main
> > obstacles for supporting them in the future.
> >
>
> Good idea.
>
> Actually there is one more limitation that keeps bothering me. It is
> related to nested classes, and most unfortunate because of iterators. IOW,
> we can't just register, e.g., std::vector<T>::const_iterator (as we do with
> std::vector<T>), and the user always have to register concrete classes, like
> std::vector<int>::const_iterator, std::vector<short>::const_iterator, etc.,
> separately, as she needs them. This limitation comes from the "non-deduced
> context", and applies at least to the compliant implementation, but I think
> the vintage implementation should have the same problem :(
>

That is correct.
Just a thought on the subject:
If we take the example with iterator deduction:
given a metafunction is_iterator<> there may be a way around this problem:

   template<typename T>
   void deduce_iterator(std::vector<T>::iterator it) {...}
   template<typename T>
   void deduce_iterator(std::list<T>::iterator it) {...}
   template<typename T>
   void deduce_iterator(std::set<T>::iterator it) {...}

struct select_deduce_iterator {
   template<typename T>
   static void deduce(const T& t)
   {
      deduce_iterator<T::value_type>(t);
   }
};

template<typename T>
void deduce_fallback(const T& t)
{
   if_<is_iterator<T>,
      select_deduce_iterator,
      select_report_error,
>::type type;
   type::deduce(t);
}

Problem here of cource is that iterator also needs a difference_type
from the container, which it gets from the allocator. It may be
possible to construct a dummy allocator type with the correct
difference_type just to get the types right.

The above method relies on being hardwired into the system, but it
should be possible to separate this functionality out by using SFINAE.

Regards,

Peder

> Regards,
>
> Arkadiy
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


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