Question

Should I make my own framework by wrapping up the STL classes and/or Boost libraries so that if I need to change the implementation of the string, vectors, lists, etc. or I need to write functions that MFC, other other libraries or even other platforms would need to use their format, I can easily mutate them to meet the criteria. this is what I’m thinking.

// In my framework: namespace MyFX {      typedef std::string String; };  // Port specific (MFC in this case) CString ToCString(const MyFx::String &str) { /* magic */ }  // Port specific (.NET specific) System::String^ ToManagedString(const MyFx::String &str) { /* magic */ } 

Am I reinventing the wheel too much?

I would use the MyFx::String in UI interfaces between the UI and the other layers.

Answer 1

It seems to me like there won’t be a lot of benefit to this; in my experience, the point of using these frameworks is so that you don’t go reinventing the wheel. If you find that you need to write a new string class or a new vector class, you should think really hard about it, and make sure you’re not just doing something else wrong. I’m not saying there’s never a reason to write your own string class, I’m just saying it’s rare. Given that, I would suggest just using the desired frameworks directly.

Regarding the conversion functions, I believe the compiler won’t see your ToCString function any differently than it would see this:

CString ToCString( const std::string & ) {...} 

This is because a C++ typedef does not create a new type, just an alias to an existing type.

Further Thoughts

I think the concern you voice here is a very natural one, and I know it has come up in my team several times. However, I think the answer is still as stated above.

While the STL classes are probably not perfect, they were designed by very smart people, who put quite a lot of thought into the task. Thus, the odds of you needing to write a full replacement string class are very small. Furthermore, and without intending any slight, it would take you (or me) a very long time to implement a robust general-purpose string class that could suitably replace std::string.

Another possible way to think about it would be this: would you consider ‘replacing’ the String class in Java or C#? I think the answer there is clearly ‘no’, although there may be occasional limited areas where you use something other than a String to represent a sequence of characters. Same thing goes here: std::string is as close as C++ gets to a built-in string class, and you almost assuredly don’t need to replace it.