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)

template<typename T>
void deduce_fallback(const T& t)
>::type type;

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,
> Arkadiy
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at