Larry Evans wrote:

[...] I very much sympathize with you; however, I have no answers :( I went through the same confusion with my managed_ptr's nested ownership template class. It was discussed here:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1044dnuf7ojhpc0%40corp.supernews.com [...]

It looks like Gabriel gives the best answer in that thread. My understanding is now that non-deduced contexts occur partly because specializations may be defined after instantiations of a given template class. And this is why simply adding another operator won't work. One way to eliminate non-deducibility would be to require that all specializations be defined before any template of that type is instantiated. However, this would make certain types of code impossible. Another solution would be say that argument deduction proceeds with only the specializations visible at the point of instantiation. However, that would probably be confusing. Another solution would be to have instantiation occur in a separate pass, after all possible specializations have been seen. Then it seems that it should be possible to deduce many contexts that are only non-deducible because of possible specializations. But people are likely to say that that is too expensive for the benefit gained. Dave

Larry Evans wrote:

[...] Do you mean like the :0: operator in

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1072lb8ira3jg41%40corp.supernews.com [...]

I didn't totally follow your reasoning, but I think I might have a more generic solution that I will post in c.l.c++.m. Dave

On Thu, Jul 08, 2004 at 01:44:28PM -0500, Larry Evans wrote:

On 07/08/2004 12:58 PM, David B. Held wrote:

...

This is what I would like to do:

template <class P1, class P2> struct sp { template <typename T> struct nested { }; };

template <typename T> struct less;

template <class P1, class P2, typename T> struct less<sp<P1, P2>::nested<T> > : binary_function<...> { bool operator()(...); };

However, it doesn't work. From my research, it seems that the problem is that T is in a non-deduced context, but I don't see why that would be an issue, since this is how I expect it to get instantiated:

less<sp<p1, p2>::nested<int> > comp;

Thus, I don't see any deduction as being necessary, but obviously I don't exactly understand how to get what I want.

I very much sympathize with you; however, I have no answers :(

Depending on how much control you have over various parts, you maybe can kludge it along the lines of: struct i_am_a_nested_thingy {}; template <class P1, class P2> struct sp { template <typename T> struct nested : public i_am_a_nested_thingy { typedef P1 NestedP1; typedef P2 NestedP2; }; }; template <typename T> struct less; template <typename T> struct less_helper; template <typename T> struct less_helper<T,true> : binary_function<...> { typedef typename T::NestedP1 P1; typedef typename T::NestedP2 P2; bool operator()(...); }; template <typename T> struct less_helper<T,false> { // default impl (if there is one) }; template <class P1, class P2, typename T> struct less<T> : public less_helper<T,is_base_and_derived<i_am_a_nested_thingy,T>::value> { }; ... less<sp<p1, p2>::nested<int> > comp; ... -- -Brian McNamara (lorgon@cc.gatech.edu)

Jonathan Turkanis wrote:

[...] Could you pull the definition of nested outside of sp

template<typename P1, typename P2, typename T> struct sp_nested { };

then use a metafunction within sp:

template<typename P1, typename P2> struct sp { template<typename T> struct nested { typedef sp_nested<P1, P2, T> type; }; }; [...]

For syntax reasons, this is an undesirable solution. Although, you could get pretty close by modifying it a little: template<typename P1, typename P2> struct sp { template<typename T> struct nested : sp_nested<P1, P2, T> { }; };

[...] You can then make less< sp_nested<P1, P2, T> > do pretty much whatever you want; the question is whether you can make the metafunction do whatever you needed the nested template to do.

The problem is that sp_nested<> would be an implementation detail that I would not want to expose to the user. So I would not want the user to have to mention it in order to instantiate less<>. Dave

Larry Evans wrote:

[...] FWIW, there's rm_nondeduced at:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/mana... [...]

So far I like Brian's solution best, even though it's a big hack. I don't really understand how your solution works. Could you give a simple contrived example in 20 lines or less? Dave

"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:cckeh3$fd0$1@sea.gmane.org...

Jonathan Turkanis wrote:

...

[...] Could you pull the definition of nested outside of sp

template<typename P1, typename P2, typename T> struct sp_nested { };

then use a metafunction within sp:

template<typename P1, typename P2> struct sp { template<typename T> struct nested { typedef sp_nested<P1, P2, T> type; }; }; [...]

For syntax reasons, this is an undesirable solution.

I 'm not sure I see the syntax problem; if you mean that it's more cumbersome to use a metafunction, I agree.

Although, you could get pretty close by modifying it a little:

template<typename P1, typename P2> struct sp { template<typename T> struct nested : sp_nested<P1, P2, T> { }; };

Then specializing less< ... > for sp_nested wouldn't affect the implementation of less<nested>. <snip>

The problem is that sp_nested<> would be an implementation detail that I would not want to expose to the user. So I would not want the user to have to mention it in order to instantiate less<>.

I don't see the distinction between template <class P1, class P2, typename T> struct less<sp<P1, P2>::nested<T> > : binary_function<...> { bool operator()(...); }; and template <class P1, class P2, typename T> struct less<sp_nested<P1, P2, T> > : binary_function<...> { bool operator()(...); }; with respect to exposing implementation details. Jonathan

"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:cckhc5$m3l$1@sea.gmane.org...

The difference is that the component is called sp<>::nested<>. It's not called sp_nested<>, because they might want to typedef sp<> and instantiate the nested class over various types. By also exposing sp_nested<>, I'm asking them to call it by two different names depending on usage. It isn't totally evil, but it's less pleasant:

typedef sp<p1, p2> my_sp; my_sp::nested<foo> p; my_sp::nested<bar> q;

less<my_sp::nested<foo> > comp;

Got it. One last try -- a variation on Brian's: struct nested_base { }; template <class P1, class P2> struct sp { template <typename T> struct nested : nested_base { typedef P1 p1; typedef P1 p2; typedef T t; }; }; template <typename T, typename Enabler = void> struct less { }; template<typename T> struct enable_if_nested : boost::enable_if< boost::is_base_and_derived<nested_base, T> > { }; template <typename T> struct less< T, typename enable_if_nested<T>::type > { ... }; Jonathan

Larry Evans wrote:

[...] template <typename T> struct nested { template < typename S //subtype of T' > nested(sp<P1,P2>::nested<S>& a_sp) ; };

Now both P1 and P2 are in a non-deduced context and, AFAICT, there no workaround using some helper class like the above nested_base or Brian's i_am_a_nested_thingy. Maybe I'm wrong. If so, could someone please outline a solution?

We (meaning Andrei and I, since it was his idea) cheated by using an overly general template argument and hoping for the best. I.e.: template <class SP> nested(SP& sp, typename SP::nested_type = 0); Where nested_type is just something we expect to find in SP. Of course, this is not foolproof, and someone could break it. But as you say, there is no foolproof solution in the current language that I can see (at least not one that is lightweight enough to be practical). Dave