Question

我有2个退出的c ++项目，我有Sender和Receiver。它们与UDP套接字连接相连，并通过CmakeFile.txt构建

Root
    |→ Sender
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt

现在我想用DDS上下文idl

更改UDP

Root
    |→ Sender
    |   |→ src
    |   |   |→ Publisher.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |   |→ Subscriber.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt


Root
    |→ Sender
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ DDSCom
    |   |→ src
    |   |   |→ Publisher.cpp
    |   |   |→ Subscriber.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt

我的结构应该是什么？

Answer 1

项目结构（源文件）：

您提出的项目结构似乎是合理的。一般来说，我建议更多地通过应用程序的体系结构和逻辑结构来通知源代码的结构，而不是选择通信机制。

但是，将DDS集成到项目中时需要考虑一些因素。特别是，如果您使用IDL（或XML）为应用程序定义DDS数据类型，那么将这些文件放在“公共”区域中通常是有意义的。 DDS IDL编译器将从这些类型定义文件生成代码，这些生成的代码可以编译到库中，或者简单地编译到每个应用程序中。

另外，如果您使用的是版本控制系统（git，svn等），那么我建议控制IDL文件，而不是生成的代码。 [有一些参数可以控制生成的代码，但我认为它几乎总是造成弊大于利。]因此，特别是对于您的项目，我希望在DDSCom /下找到一个或多个IDL（或XML）文件src，DDSCom / include，或者也许是DDSCom / idl，如你所愿。可以创建CMake规则以从IDL生成特定于类型的源代码，作为构建过程的一部分。这可以保证生成的代码与数据类型保持同步，并且可以升级DDS实现。

无论使用的DDS实施如何，这种方法都应适用;例如，CoreDX DDS，OpenSplice或RTI。

源代码结构：

关于内部代码结构（不是“目录”结构），有许多方法可以构建使用DDS进行通信的应用程序。 DDS API允许同步和异步通信模式。

通常，数据生产者创建多个DDS实体以便于编写数据（例如，DDS :: DomainParticipant，DDS :: Publisher，DDS :: Topic和DDS :: DataWriter）。 DataWriter实体支持“write”调用，其他实体提供各种配置点以影响通信行为和结构。

类似地，数据使用者创建相应的DDS实体，使其能够“读取”数据（例如，DDS :: DomainParticipant，DDS :: Subscriber，DDS :: Topic和DDS :: DataReader）。 DataReader支持许多不同的“读取”操作变体，以提供对可用数据的访问。

每个DDS实体都充当其他实体的工厂，每个实体都可以配置各种服务质量（QoS）策略设置。这些QoS设置为DDS提供了一组非常丰富的配置选项，可以影响通信。 “主题”实体定义了按名称标识的数据的逻辑分组，并进一步指定了“类型” 集合中包含的数据。

在一个小项目中，您可能会发现在应用程序中需要的位置创建DDS实体更容易（例如，在main（）例程中）。或者，对于较大的系统，将DDS实体封装在可在不同应用程序中重用的组件中通常是有益的。

什么应该是DDS通信结构？

1 个答案:

项目结构（源文件）：

源代码结构：