That's generic programming if I'm not mistaken. It's true - such functions should come first, but then again, they may not be the easiest or pretties to use, so creating wrappers for them if/when you have time seems like a good thing to me.
No. What I offered has nothing to do with generics and everything to do with composition.
You demand:
Code:
my_instance.do_something_very_specific_x();
my_instance.do_something_very_specific_x_only_differently();
Composition (What I offered is a composition hierarchy.):
Code:
something_very_specific instructions1;
something_very_specific instructions2;
some_class my_instance(instructions1);
my_instance.do_x();
my_instance(instructions2);
my_instance.do_x();
This: "But this does give me an idea about trying to break up the class in components and placing those classes as objects inside the main class, as to split up encoding-related functions into an Encoding class, as it seems you were suggestion something in lines of as (obj.Encoding().ToUTF16)." is another form of composition.
Well, I think that's difficult.
Not really; once the class has a method all instances of a class may not understand you've lost the battle. (See class 'duck'. If you put a 'quack' method you've lost. Some ducks species do not quack you see.)
Yay for classes wrapping STL functionality, eh? XD
O_o
How many times have I told you, methods that only wrap functionality that is easily accomplished with free functions are less than useless; such methods only increases coupling, cost of development, and cost of education, and decreases encapsulation, functionality, and cohesion.
There is no fault in the capabilities of the STL nor in the design beyond the usage being rather verbose. Sacrificing capability is not an option. (Your prejudice costs a lot.) The STL interface would benefit from deriving even the mechanics from traits/policies/expressions where possible so that the interface doesn't require specific adapters/functions/parameters to define this behavior. I don't suggest this because I think it would make the source sexy. I suggest it, indeed have even coded it, because it is less verbose.
The difference between warping the existing STL interfaces with countless class specific methods and what I suggest is obvious: My suggestion is not a simple interface change for the sake of a few novice programmers; it would require a more robust implementation mechanism, allowing for a simpler interface, because it would never require the adapters/functions to be written in the first place.
Soma