在 c++ 中动态添加过滤功能

发布于 2024-10-20 08:27:20 字数 648 浏览 8 评论 0原文

我有以下(简化的)架构:

客户端 -->保镖-->服务器

客户端向服务器发送命令。 “保镖”对客户端发出的命令执行健全性和其他检查,并防止错误命令到达服务器。例如,bouncer可能有如下代码:

bool Bouncer::someCommand(const someCommandArg& arg) {
    if (arg.x < 100) {
        return false;                              
    }

    if (arg.y > 10) {
        return false;
    }
    // more checks ...

        return server->someCommand(arg);
}

这种方式的问题是bouncer条件必须一一硬编码,不够灵活。我正在寻找一种在某些配置文件中定义这些条件的方法,保镖将在创建时加载该配置文件,并将循环遍历所有配置文件 调用 someCommand 时的条件。此外,测试循环本身必须很快。

如果是 C#,我想我会使用它的即时编译功能,并在配置文件中用纯代码编写我的 if 子句。您对 C++ 有什么建议?

I have the following (simplified) architecture:

client(s) --> bouncer --> server

The clients send commands to the server. The 'bouncer' performs sanity and other checks on the commands issued by the client, and prevents faulty commands from reaching the server. For example, the bouncer may have the following code:

bool Bouncer::someCommand(const someCommandArg& arg) {
    if (arg.x < 100) {
        return false;                              
    }

    if (arg.y > 10) {
        return false;
    }
    // more checks ...

        return server->someCommand(arg);
}

The problem with this approach is that the bouncer conditions have to be hard-coded one by one, and is not flexible enough. I'm looking for a way to define these conditions in some configuration file, which the bouncer will load when created, and will loop through all the
conditions when someCommand is called. Moreover, the test loop itself has to be fast.

Were it C#, I guess I would have used its compile-on-the-fly capabilities, and have my if clauses written in plain code in the configuration file. What do you suggest for C++?

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

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

发布评论

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

评论(2

青巷忧颜 2024-10-27 08:27:20

选择包括:

  • 创建一个解释环境,将传入消息的可测试方面传达给它,并从要评估的配置中加载一些谓词表达式/函数
    • 嵌入语言(例如 LUA、Ruby)
    • 下载许多更简单的表达式评估库中的任何一个
    • 创建您自己的(也许使用 boost Spirit)
  • 让保镖以共享对象(.so、.dll -无论你的操作系统如何称呼它们)使用 dlopen/dlsym 等。
    • 仅需要重新编译谓词/规则
    • 不需要将整个应用源代码分发给想要指定谓词的用户
    • 谓词执行速度相当快

什么是最好的,很大程度上取决于有用谓词的复杂性、性能要求、部署实践等..

Choices include:

  • create an interpretive environment, communicate the testable aspects of the incoming message to it, and load some predicate expression/function from your config to be evaluated
    • embed a language (e.g. LUA, ruby)
    • download any of many simpler expression evaluation libraries
    • create your own (perhaps using boost Spirit)
  • have the bouncer load the predicates in the form of a shared object (.so, .dll - whatever your OS calls them) using dlopen/dlsym etc..
    • only the predicates/rules need be recompiled
    • don't need to distribute the entire app source to users wanting to specify predicates
    • pretty fast predicate execution

What's best depends a lot on the complexity of useful predicates, performance requirements, deployment practices etc..

信仰 2024-10-27 08:27:20

您可以使用插件方法。让保镖成为一个插件,然后使用管道/责任链模式通过多个保镖传递命令?不同的保镖插件可以检查不同的条件,并通过链接它们,您可以定义应用于命令的最终规则。您可以使用配置文件来指定应加载哪些插件以及如何设置链。

这仍然意味着必须先编译插件,然后才能加载它们,但如果确实有要求,您可以在程序运行时动态加载它们。至少添加新插件不需要重新编译您的应用程序。

You can use a plugin approach. Make the bouncer a plugin and then use a pipeline/chain-of-responsibility pattern to pass a command through multiple bouncers? Different bouncer plugins can check for different conditions and by chaining them, you define the final rule applied to the command. You can use a config file to specify what plugins should be loaded and how to setup the chain.

This still implies that the plugins have to be compiled before you can load them, but you can dynamically load them while your program is running if this is really a requirement. At least adding new plugins doesn't require your application to be recompiled.

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