boost::interprocess::basic_string 作为 std::string
我试图用 const boost::interprocess::basic_string & 替换返回 const std::string & 的类方法。我面临的主要挑战是两个类之间的不兼容性,尽管它们的实现相似。为了更清楚的解释,我将把它放入代码中
class A
{ std::string m_str;
const std::string & StrVal() { return m_str; }
}
现在这个类必须看起来像这样:
typedef boost::interprocess::allocator<char,boost::interprocess::managed_shared_memory::segment_manager> ShmemAllocatorChar;
typedef boost::interprocess::basic_string<char, std::char_traits<char>,ShmemAllocatorChar> ShMemString;
class A
{
ShMemString m_str;
const ShMemString & StrVal() { return m_str; }
}
问题是我们有一个巨大的代码库取决于这个:
A a;
const std::string & str = a.StrVal();
// Many string specific operations go here, comparing str with other std::strings for instance
即使我检查所有代码,用 const ShMemString & 替换预期结果; ,修复随后的用途将是一项更加艰巨的工作。我惊讶地发现 boost 的字符串不包含 std::string 的任何比较/构造方法。
关于如何解决这个问题有什么想法吗?
I am trying to replace a class method which returns const std::string & with const boost::interprocess::basic_string &. The main challenge I am facing is the incompatibility between the two classes despite their implementation similarity. For more clear explanation I will put that into code
class A
{ std::string m_str;
const std::string & StrVal() { return m_str; }
}
Now this class has to look like this:
typedef boost::interprocess::allocator<char,boost::interprocess::managed_shared_memory::segment_manager> ShmemAllocatorChar;
typedef boost::interprocess::basic_string<char, std::char_traits<char>,ShmemAllocatorChar> ShMemString;
class A
{
ShMemString m_str;
const ShMemString & StrVal() { return m_str; }
}
The problem is that we have a huge code base depending on this:
A a;
const std::string & str = a.StrVal();
// Many string specific operations go here, comparing str with other std::strings for instance
Even If I go over all the code replacing the expected results with const ShMemString &, it will be an even harder work to also fix the uses that follow. I was surprised to find out that the boost's string does not include any comparison/construction methods from std::string.
Any ideas on how to approach this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
即使
boost::interprocess::basic_string<>
确实转换为std::basic_string<>
,它对于您的目的来说也是完全无用的 - 之后转换时,进程间字符串将被破坏,并且其分配器是重要的分配器(即,将数据保存在共享内存中的分配器,我认为这是您切换的动机首先是basic_string<>
实现)。因此,最后,您别无选择,只能检查所有代码,将预期结果替换为
ShMemString const&
(或auto const&
如果您的编译器足够新)以支持它)。为了让将来不那么痛苦,明智地使用
typedef
:这样,只有
A
内部的typedef
需要更改,并且所有代码都依赖于它会自动使用正确的类型。Even if
boost::interprocess::basic_string<>
did have a conversion tostd::basic_string<>
, it would be completely useless for your purposes -- after the conversion, the interprocess string would be destroyed, and its allocator is the important one (i.e., the one holding the data in shared memory, which I assume is your motivation for switchingbasic_string<>
implementations in the first place).So, in the end, you have no choice but to go over all the code replacing the expected results with
ShMemString const&
(orauto const&
if your compiler is recent enough to support it).To make this less painful in the future,
typedef
judiciously:This way, only the
typedef
inside ofA
needs to change and all code relying on it will automatically use the correct type.为什么第二个中的
A::StrVal
返回interprocess::basic_string
?它是类A
的实现细节,它在内部使用interprocess::basic_string
。它的接口使用的实际字符串类不必相同。这只是糟糕的重构。A::StrVal
应该返回一个std::string
,就像往常一样(当然,不是const&
,但用户代码获胜不需要因此而改变)。因此,A::StrVal
需要在两种字符串类型之间进行转换。这就是正确重构的方式:更改实现,但界面保持不变。是的,这意味着您将必须复制字符串数据。忍受它。
Why does
A::StrVal
in the second one return aninterprocess::basic_string
? It is an implementation detail of the classA
that it usesinterprocess::basic_string
internally. The actual string class it's interface uses does not have to be the same. This is simply poor refactoring.A::StrVal
should return astd::string
, just like always (well, not aconst&
of course, but user code won't need to change because of that). And therefore,A::StrVal
will need to do the conversion between the two string types. That's how proper refactoring is done: you change the implementation, but the interface stays the same.Yes, this means you're going to have to copy the string data. Live with it.