我应该通过包装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界面中使用MyFx :: String。
在我看来，这似乎不会有太多好处;根据我的经验，使用这些框架的点是这样，你不会重新发明轮子。如果你发现你需要编写一个新的字符串类或者一个新的向量类，你应该认真考虑它，并且确保你不只是在做别的错误。我并不是说没有理由编写自己的字符串类，我只是说这很少见。鉴于此，我建议直接使用所需的框架。
关于转换功能，相信编译器将看不到你的ToCString功能的任何不同于它会看到这一点：
CString ToCString(const std::string &) {...}
这是因为C++的typedef不会创建一个新的类型，只是一个别名到现有类型。
再思考
我想你说出这里的问题是一个很自然的，我知道它已经出现在我的团队多次。不过，我认为答案仍然如上所述。
虽然STL课程可能并不完美，但它们都是由非常聪明的人设计的，他们对此任务进行了大量的思考。因此，你需要编写一个完整的替换字符串类的几率非常小。此外，如果没有任何轻微的意图，它会花费您（或我）很长时间来实现一个可以替代std :: string的强大的通用字符串类。
另一种可能的方式来思考它会是这样的：你会考虑“替换”在Java或C＃中的字符串类？我认为答案显然是“否”，尽管可能偶尔会有一些地方使用除字符串之外的其他字符来表示字符序列。同样的事情发生在这里：std :: string和C++到达一个内置的字符串类一样近，你几乎肯定不需要替换它。
“我是不是重新发明了轮子？” - 是的。不要这样做。
“它取决于” - 如果您认为将来有可能更改为某些其他库/库（例如，由于移植到其他平台），则可以制定一个框架以满足您的需求，但使它成为一个门面，薄和简单越好
，这是一个时间/风险的权衡决定，只有你可以使
另见：https://stackoverflow.com/questions/22795/when-to-notionally-build-your-own-compiler，也许更有趣的是乔尔的文章，引发了一个问题： In Defense of Not-Invented-Here Syndrome。
但简短的回答是：不是没有一个该死的很好的理由。
最大的好处将是您将获得的学习体验。
如果我需要用别的东西替换std :: string会怎样？ – 2009-01-23 18:27:35