声明后添加好友类

发布于 2024-12-15 06:32:40 字数 2151 浏览 0 评论 0原文

我正在尝试用 C++ 编写一个命名管道服务器。我有一个名为 client_pool 的类,其中包含管道实例的容器,以及一个公共成员函数 write,该函数将数据异步发送到所有连接的客户端。

问题是,客户端往往会意外断开连接。发生这种情况时,对 WriteFileEx 的调用将失败并显示 ERROR_NO_DATA。当发生这种情况时,我想转到 client_pool 类并告诉它关闭客户端句柄并将其从容器中删除。然而,由于 WriteFileEx 太难用了,我在匿名命名空间中创建了一个名为 write_context 的帮助器类。

所以最终的结果是,我想从类 write_context 中调用 client_pool 中的私有方法,该方法在 clients.h 中声明,它在 clients.cpp 中声明。类似的东西(省略细节/错误处理):

clients.h

class client_pool {
    struct implementation;
    std::unique_ptr<implementation> pimpl;
public:
    void write(uint8_t *data, size_t size);
};

clients.cpp

struct client_pool::implementation {
    set<HANDLE> connected;
    // ...
    void disconnect(HANDLE victim)
    {
        CloseHandle(victim);
        connected.erase(victim);
    }
};

namespace { struct write_context {
    OVERLAPPED overlapped;
    client_pool *owner;
    HANDLE target;
    const uint8_t *buffer;
    size_t total_size;
    size_t written;
    // ...
    void next_chunk()
    {
        if(!WriteFileEx(/* ... */, write_context::completion_routine)) {
            if(GetLastError() == ERROR_NO_DATA) {
                // I want to do something like
                owner->pimpl->disconnect(target);
            }
        }
    }
    static void CALLBACK completion_routine(DWORD errcode, DWORD transferred, LPOVERLAPPED overlapped)
    {
        auto self = reinterpret_cast<write_context*>(overlapped);
        self->written += transferred;
        if(errcode == ERROR_MORE_DATA) {
            self->next_chunk();
        } else {
            delete self;
        }
    }
}; }

void client_pool::write(uint8_t *data, size_t size)
{
    for each handle in pimpl->connected {
        auto context = new write_context(this, handle, data, size);
        context->next_chunk();
    }
}

显然,行 owner->pimpl->disconnect(target) ; 无法编译,因为 pimpl 是私有的。我能做什么/我有什么选择?

I am trying to write a named pipe server in C++. I have a class called client_pool which contains a container of the pipe's instances, and a single public member function write, which asynchronously sends data to all connected clients.

Problem is, clients have the tendency to disconnect unexpectedly. When this happens, the call to WriteFileEx fails with ERROR_NO_DATA. When that happens, i want to go to the client_pool class and tell it to close the client handle and remove it from the container. However, since WriteFileEx is so fricking hard to use, I created a helper class called write_context in an anonymous namespace.

So the end result is, that I want to call a private method in client_pool, which is declared in clients.h, from the class write_context, which is declared in clients.cpp. Something like that (details/error handling omitted):

clients.h

class client_pool {
    struct implementation;
    std::unique_ptr<implementation> pimpl;
public:
    void write(uint8_t *data, size_t size);
};

clients.cpp

struct client_pool::implementation {
    set<HANDLE> connected;
    // ...
    void disconnect(HANDLE victim)
    {
        CloseHandle(victim);
        connected.erase(victim);
    }
};

namespace { struct write_context {
    OVERLAPPED overlapped;
    client_pool *owner;
    HANDLE target;
    const uint8_t *buffer;
    size_t total_size;
    size_t written;
    // ...
    void next_chunk()
    {
        if(!WriteFileEx(/* ... */, write_context::completion_routine)) {
            if(GetLastError() == ERROR_NO_DATA) {
                // I want to do something like
                owner->pimpl->disconnect(target);
            }
        }
    }
    static void CALLBACK completion_routine(DWORD errcode, DWORD transferred, LPOVERLAPPED overlapped)
    {
        auto self = reinterpret_cast<write_context*>(overlapped);
        self->written += transferred;
        if(errcode == ERROR_MORE_DATA) {
            self->next_chunk();
        } else {
            delete self;
        }
    }
}; }

void client_pool::write(uint8_t *data, size_t size)
{
    for each handle in pimpl->connected {
        auto context = new write_context(this, handle, data, size);
        context->next_chunk();
    }
}

Obviously, the line owner->pimpl->disconnect(target); doesn't compile because pimpl is private. What can I do / what are my alternatvies?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(4

清晰传感 2024-12-22 06:32:40

直接在 client_pool::write 方法中直接访问 pimpl->connected 和 write_context 与 pimpl 习惯用法的要点有点相反。你可能会提出其他的理由,直到你遇到这样的问题。

我只想创建一个implementation::write 方法,您可以为其传递参数和指向client_pool 的指针。

Directly accessing pimpl->connected and write_context directly in your client_pool::write method is kinda contrary to the point of the pimpl idiom. You could probably make a case otherwise, until you run into a problem just like this.

I would just create an implementation::write method for which you can pass through the arguments and a pointer to client_pool.

年少掌心 2024-12-22 06:32:40

我认为如果您使用命名名称空间而不是匿名名称空间,您可以将此行放在类定义中:

friend void namespace_name::next_chunk()

或者将所有额外的内容作为类中的静态函数放置在匿名名称空间中。由于静态方法和结构不会更改 ABI,因此您可以通过预处理器技巧对所有其他实例隐藏它。

或者是残酷而恐怖的:

#define class struct
#define private public
#define protected public

I think if you use a named namespace instead of a anonymous namespace you could place this line inside the class definition:

friend void namespace_name::next_chunk()

Or there's placing all that extra stuff in the anonymous namespace as static functions inside the class. Because static methods and structs don't change the ABI, you can hide it from all other instances via a preprocessor trick.

Or there's the brutal and horrifying:

#define class struct
#define private public
#define protected public
浅紫色的梦幻 2024-12-22 06:32:40

write_context成为implementation的朋友。将 pimpl 作为 write_contextowner 传递。

Make write_context a friend of implementation. Pass pimpl as the owner of write_context.

擦肩而过的背影 2024-12-22 06:32:40

抱歉,但这不是使用 PIMPL 惯用语的最佳方式。

PIMPL 隐藏其所有者的实现细节,并且只能通过其所有者接口进行访问。因此,如果您想调用“client_pool::implementation”方法,则应将其移至“client_pool”接口,并且其实现应将工作委托给“client_pool::implementation”类。在其他情况下,这看起来像是设计错误。

Sorry, but this is not the best way to use PIMPL idiom.

PIMPL hides implementation details of it's owner and should be accessed only through its owners interface. So, if you want to call "client_pool::implementation" method than it should be moved to "client_pool" interface and its implementation should delegate work to "client_pool::implementation" class. In other case this looks like design bug.

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