Reputation: 190907

Should I make my own framework?

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.

Upvotes: 1

Answers (6)

cherouvim

Reputation: 31903

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

Upvotes: 0

Charlie

Reputation: 45052

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.

Upvotes: 6

dmckee --- ex-moderator kitten

Reputation: 101151

See also: https://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.

Upvotes: 1

Aaron Maenpaa

Reputation: 122850

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.

Upvotes: 3

Steven A. Lowe

Reputation: 61223

"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

Upvotes: 2

duffymo

Reputation: 308733

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

Upvotes: 5

Should I make my own framework?

Answers (6)

Related Questions