|
Boost : |
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-10 13:20:47
"George M. Garner Jr." <gmgarner_at_[hidden]> wrote in message
news:chsoo1$nsd$1_at_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_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk