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. 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. Regards, George. "Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:chqsii$kur$1@sea.gmane.org...
"George M. Garner Jr." <gmgarner@erols.com> wrote in message news:chqr6i$ifu$1@sea.gmane.org...
Johnathan,
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 previously derives line_wrapping_output_filter<__wchar_t> from output_filter. The fact that this compiles and works is problematic because it introduces a certain 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!
Regards,
George.
Jonathan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost