boost::interprocess::basic_string 作为 std::string

发布于 2024-12-05 03:53:51 字数 1004 浏览 1 评论 0原文

我试图用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

猫七 2024-12-12 03:53:51

即使 boost::interprocess::basic_string<> 确实转换为 std::basic_string<>,它对于您的目的来说也是完全无用的 - 之后转换时,进程间字符串将被破坏,并且分配器是重要的分配器(即,将数据保存在共享内存中的分配器,我认为这是您切换的动机首先是 basic_string<> 实现)。

因此,最后,您别无选择,只能检查所有代码,将预期结果替换为 ShMemString const& (或 auto const& 如果您的编译器足够新)以支持它)。


为了让将来不那么痛苦,明智地使用 typedef

struct A
{
    typedef ShMemString StrValType;
    StrValType const& StrVal() { return m_str; }
private:
    StrValType m_str;
};

// ...

A a;
A::StrValType const& str = a.StrVal();

这样,只有 A 内部的 typedef 需要更改,并且所有代码都依赖于它会自动使用正确的类型。

Even if boost::interprocess::basic_string<> did have a conversion to std::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 switching basic_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& (or auto const& if your compiler is recent enough to support it).


To make this less painful in the future, typedef judiciously:

struct A
{
    typedef ShMemString StrValType;
    StrValType const& StrVal() { return m_str; }
private:
    StrValType m_str;
};

// ...

A a;
A::StrValType const& str = a.StrVal();

This way, only the typedef inside of A needs to change and all code relying on it will automatically use the correct type.

舟遥客 2024-12-12 03:53:51

问题是我们有一个庞大的代码库依赖于此:

为什么第二个中的 A::StrVal 返回 interprocess::basic_string?它是类 A 的实现细节,它在内部使用 interprocess::basic_string。它的接口使用的实际字符串类不必相同。这只是糟糕的重构。

A::StrVal 应该返回一个 std::string,就像往常一样(当然,不是 const&,但用户代码获胜不需要因此而改变)。因此,A::StrVal 需要在两种字符串类型之间进行转换。这就是正确重构的方式:更改实现,但界面保持不变。

是的,这意味着您将必须复制字符串数据。忍受它。

The problem is that we have a huge code base depending on this:

Why does A::StrVal in the second one return an interprocess::basic_string? It is an implementation detail of the class A that it uses interprocess::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 a std::string, just like always (well, not a const& 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文