我是否应该通过封装 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 。
在我看来，这不会有很多好处；根据我的经验，使用这些框架的目的是为了避免重新发明轮子。如果你发现你需要编写一个新的字符串类或一个新的向量类，你应该认真考虑一下，并确保你不只是做错了什么。我并不是说没有理由编写自己的字符串类，我只是说它很少见。鉴于此，我建议直接使用所需的框架。
关于转换函数，我相信编译器不会看到你的 ToCString 函数与它看到的有任何不同：
CString ToCString( const std::string & ) {...}
这是因为 C++ typedef 不会创建新类型，只是现有类型的别名。
进一步的想法
我认为你在这里表达的担忧是很自然的，我知道我的团队已经多次出现过这种担忧。但是，我认为答案仍然如上所述。
虽然 STL 类可能并不完美，但它们是由非常聪明的人设计的，他们在任务中投入了很多心思。因此，您需要编写一个完整的替换字符串类的可能性非常小。此外，在无意中，您（或我）将花费很长时间来实现一个健壮的通用字符串类，该类可以适当地替换 std::string。
另一种可能的思考方式是：您会考虑在 Java 或 C# 中“替换” String 类吗？我认为答案显然是“不”，尽管可能偶尔会在有限的区域使用字符串以外的东西来表示一系列字符。这里也有同样的情况：std::string 与 C++ 与内置字符串类一样接近，而且您几乎可以肯定不需要替换它。
“我是不是在重复造轮子太多了？” - 是的。不要这样做。
“这取决于” - 如果您认为将来可能会更改为其他一些库/库（例如，由于移植到其他平台），那么制作一个满足您需求的框架，但让它成为一个门面, 尽可能的薄和简单
这是一个只有您可以做出的时间/风险权衡决定
另请参阅：https ://stackoverflow.com/questions/22795/when-to-notionally-build-your-own-compiler ，也许更有趣的是 Joel 的文章引发了这个问题：为 Not-Invented-Here 综合症辩护。
但简短的回答是：并非没有该死的充分理由。
最大的好处将是您将获得的学习经验。