True, but apparently that's your favorite tune.
Well, OO or not, what's good about C++ is that you aren't limited to one paradigm.
Hah! Yes. That's what I get for being in a hurry.
Did you forget a "no" keyword in there?
'ToUTF16' is alright if the other names in the set also represent a shift in character encoding, but I would couple them by indirection. (Instead of 'utf16_name = my_name.ToUTF16()' you allow for 'utf16_name = my_name.Encoding().ToUTF16()'.) However, I assume, being you, you will also provide methods like 'ToUpper' and 'ToLower' that do not represent a change in encoding. That said, the names imply that it converts the existing string data; I understood that you intended the data to be spawned anew and then converted, and with this in mind, the name of the method should indicate this behavior. As for 'ToANSI', at least change it to 'ToASCII', but that doesn't fit either if you are intending it to imply "Microsoft ANSI".
If they are terrible names, what would you suggest?
But what does an object do? At what point does "what an object can be directed to do" stop implying "what feat an object is capable of"? You said something in another thread about cats meowing. A cat can be directed to do marvelous things; they are fairly intelligent animals, but they will never naturally do anything beyond what is required to survive.
If it part of what the object does, then yes. Neatly organized.
I do not know how "OO" people would do it because "OO" is a garbage buzzword used as an umbrella term for several techniques. Of course, the behavior of an object is usually too closely coupled to the object. Worse, most seem to think that the interface is more important than the mechanic. These two factors lead to code with altogether too many interfaces associated with altogether too many classes. This is a problem. It can be fixed. Instead of, in your case, providing a variety of methods to provide behavior for conversion of every encoding you may find useful, you instead provide a single method for conversion and a constructor/operator pair that changes the 'codec's used by the conversion. You get your "everyone would know where to look", "the object does the work", and even the sexy syntax without polluting the interface, and, this is the important bit, you have made the class infinitively expandable--even at runtime--without creating an impossibly vigorous tree of class relationships. To be said simply: you give the object the dictionary, ask the object to do the translation, and it performs the translation. Lovely.
If classes cannot be extended indefinitely, how do OO people do it? Create several classes built around the same thing?
(In terms of that cat meowing thing, consider this: virtually all animals have some form of vocalization, but different animals in the same species vocalize differently. What I'm suggesting: give the animals a voice--an object describing the characteristics of that voice.)
You are "reinventing the wheel" so that it might be more suitable to your tastes. You have all the slack from me you could ever want. I'm probably one of the few people around who encourages--even demands as a tutor--that one "reinvents the wheel".
But come on, give me some slack here.
C++ is remarkably strait forward. Trust me on this, one can get the design wrong in any language; C++ is one of the few that allows you get the design right!
C++ isn't just straight forward.
Obviously. I am not trying to dissuade you from experimenting; I'm only warning you of mistakes. I don't even care if you make such mistakes. It would possibly be wiser just to listen, but first hand experience is usually invaluable.
I'm testing methods and ways of doing things.
Without experimenting, you won't learn anything.
Tell that to the alchemists. (Occasionally, just listening to the experienced is enough.)