Should I make my own framework?

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

Should I make my own framework?

Uh... no.

I wouldn't really worry about replacing std::vector until there is a business need to do so, because YAGNI.

Answer 2

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.

Answer 3

"Am I reinventing the wheel too much?" - yes. Don't do it.

Answer 4

"it depends" - if you think it is likely that you may in the future change to some other library/libraries, (due to porting to other platforms, for example) then make a framework to suit your needs, but make it a facade, as thin and simple as possible

this is a time/risk trade-off decision which only you can make

Answer 5

See also: http://stackoverflow.com/questions/22795/when-to-notionally-build-your-own-compiler, and perhaps more interestingly Joel's article that triggered the question: In Defense of Not-Invented-Here Syndrome.

But the short answer is: not without a damn good reason.

Answer 6

The biggest benefit will be the learning experience you'll gain.