Question

我应该通过包装STL类和/或Boost库来创建我自己的框架，这样如果我需要更改字符串，向量，列表等的实现，或者我需要编写MFC，其他的函数图书馆甚至其他平台都需要使用他们的格式，我可以很容易地改变它们以符合标准。这就是我的想法。

// 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 */ }

我是否过多地重新发明轮子？

我会在UI和其他图层之间的UI界面中使用 MyFx :: String 。

Answer 1

在我看来，这样做不会带来很多好处;根据我的经验，使用这些框架的点是让你不再重新发明轮子。如果你发现你需要编写一个新的字符串类或一个新的矢量类，你应该认真思考它，并确保你不仅仅是做错了什么。我不是说从来没有理由写自己的字符串类，我只是说它很少见。鉴于此，我建议直接使用所需的框架。

关于转换函数，我相信编译器不会看到你的ToCString函数与它看到的不同：

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

这是因为C ++ typedef不会创建新类型，只是现有类型的别名。

进一步思考

我认为你在这里表达的关注是非常自然的，我知道它已经在我的团队中出现了好几次。但是，我认为答案仍然如上所述。

虽然STL课程可能并不完美，但它们是由非常聪明的人设计的，他们在这项任务中投入了大量的精力。因此，您需要编写完整替换字符串类的几率非常小。此外，如果不打算任何轻微的话，你（或我）需要很长时间来实现一个强大的通用字符串类，它可以适当地替换std :: string。

考虑它的另一种可能方式是：你会考虑用Java或C＃“替换”String类吗？我认为那里的答案显然是“不”，尽管偶尔会有一些限制区域，你使用String之外的其他东西来表示一系列字符。同样的事情在这里：std :: string和C ++一样接近内置的字符串类，你几乎肯定不需要替换它。

Answer 2

“我是否过多地重新发明轮子？” - 是的不要这样做。

Answer 3

我应该制作自己的框架吗？

呃......不。

我真的不担心替换std :: vector，直到有业务需要这样做，因为YAGNI。

Answer 4

“它取决于” - 如果您认为将来可能会更改其他库/库（例如，由于移植到其他平台），那么建立一个框架以满足您的需求，但是它是一个立面，尽可能薄而简单

这是一个时间/风险权衡决定，只有你可以做出

Answer 5

另请参阅：https://stackoverflow.com/questions/22795/when-to-notionally-build-your-own-compiler，也许更有趣的是Joel的文章引发了这个问题：In Defense of Not-Invented-Here Syndrome。

但简短的回答是：并非没有一个该死的理由。

Answer 6

最大的好处是你将获得的学习经历。

我应该制作自己的框架吗？

6 个答案: