From: George M. Garner Jr. (gmgarner_at_[hidden])
Date: 2004-09-10 12:36:59
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.
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.
"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> "George M. Garner Jr." <gmgarner_at_[hidden]> wrote in message
>> Actually, the problem was that
>> line_wrapping_output_filter needs to derive from output_wfilter not
>> output_filter for Unicode applications. The code that I posted
>> derives line_wrapping_output_filter<__wchar_t> from output_filter. The
>> that this compiles and works is problematic because it introduces a
>> ambiguity that may bite in the future.
> Like I said, this example was not meant for production use. It was
> designed as a
> simple example of a narrow-character filter.
>> >(You might run into trouble if you use /Zc:wchar_t, I'm not sure.)<
>> That's only a problem if you compile the library with a different setting
>> than the application to which it is linked. I have tried it both ways
>> without problem.
> That's good to know.
>> There is a bug in regex_filter.hpp line 58:
>> basic_regex_filter( const regex_type& re,
>> -- const char* fmt, //
>> ++ const char_type* fmt,
>> flag_type flags = regex_constants::match_default,
>> flag_type fmt_flags = regex_constants::format_default )
> Good catch!
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk