🚀 go-pugleaf

Roman Lechtchinsky wrote:
> 
> Hi,
> 
> sorry for being curious but I'm only human... My question is: when declaring
> templates, why isn't it required to declare what one expects of the
> template's parameters? Let's create a template function:
> 
> template<class T> bool equal( const T& t1, const T& t2 )
> {
>   return t1==t2;
> }
> 
> Now, personally I would prefer to write something like:
> 
> template<class T { bool operator==( const T& t ) const; }> ...
> 
> This would make both the development and the use of templates much easier (
> to me, at least ). No need for writing lots of comments explaining what
> interface T should provide; no need for reading the source code of "equal" if
> it is part of a third-party library with poor interface documentation; no
> need to worry about implicit conversions - sounds like a lot of advantages.
> Then again, I imagine that this approach would make templates more efficient
> and easier to implement.
> Now, what I'd like to know is if something like this has been considered and
> rejected ( and why ) and what other people think about it ( would this be
> really easier to use in practice; do you consider it more elegant than the
> current approach ). Thanks in advance.
> 

I can't answer whether this has been considered (or rejected), 
but I can see a problem with your proposal.  What if a template 
required ten, fifteen, twenty mfs in its parameterizing type?  
What if those mfs have many parameters?  The resulting list of 
mfs and parameters would become quite ungainly.

Perhaps you could declare a class with the exact interface you 
expect and provide that as a model for the parameterizing type?  
This still leaves issues like equivalence.  Are implicit 
conversion allowed in mfs of a parameterizing type in order to 
match the model?  At what point do you decide there is no match?

What about the template code?  What if it you misuse the 
parameterizing type relative to your model?  Is the model wrong 
or is your code wrong?

There's probably a lot more I haven't thought of yet.

-- 
Robert Stewart		| My opinions are usually my own.
Datalytics, Inc.	| stew@datalytics.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]