> Ok. For fixed with we require both to and from unicode, and for
> variable length we require only from unicode.
>
> Then I propose that we do this: make both to and from unicode be
> purvirtual in EncodingConverter (I think we perhaps should change that
> name...not important), and create a second class derived from this
> that define from unicode, but not to unicode.
Well, you can do that if you want to, but I think it's ok as it is. The class
is not exactly huge, and it's quite easy to see what is needed. I don't think
we need to enforce a compiler error in this area.
Although I argue that fixed width encoding should convert both to and from
Unicode, I actually think that in some cases it's ok to ignore one way (either
one). This is a bit of a secret, and don't tell anybody, but this is the real
reason I provided the default methods.
Derfor, I planned to add a function
bool canConvertFromUnicode(Encoding)
as well.
Also, it would probably be useful to have a method that could return a vector
of all encodings that support conversion to Unicode, another for those that
support from Unicode, and finally one for all the fixed width encodings.
Then, it's possible to extract all the information in the encoding database.
Greets,
Asger
