"George M. Garner Jr." <gmgarner@erols.com> wrote in message news:chsoo1$nsd$1@sea.gmane.org...
Johnathan,
Actually, I think that this is a design flaw. The fact that line_wrapping_output_filter<__wchar_t> derived from output_filter both compiles and runs means that the template character type is being derived using *implicit* rules that may not always lead to the intended result.
I didn't look at your example closely enough. Let me quote the relevant part: "George M. Garner Jr." <gmgarner@erols.com> wrote:
template<class CHAR_TYPE> class line_wrapping_output_filter : public output_filter { public: typedef CHAR_TYPE char_type;
The problem is here ^^^^^^^ The point of deriving from the convenience base classes is that you don't have to specify the char_type and category. Here the category inherited from output_filter is correct, and you've hidden the incorrect inherited char_type. If you want to define a filter templated on the char type, you should inherit from the class template filter (http://tinyurl.com/5o8uh): template<typename Ch> class line_wrapping_output_filter : filter<output, Ch> { ... }; the typedefs typedef filter<input> input_filter; typedef filter<output> output_filter; typedef wfilter<input> input_wfilter; typedef wfilter<output> output_wfilter; are supposed to represent the most commonly used specializations of filter.
There should be no ambiguity about character type given the central role that character type plays in template selection. What you really need is to *explicity* pass character type as a template argument. Thus output_filter and output_wfilter should be output_filter<char_type>. Ambiguities tend to bite you in the ass sooner or later.
I tend to think this is a problem with my documentation: I should give at least one prominent example where I use the templated base classes filter and resource. Your thoughts?
Regards,
George.
Jonathan