Question

有没有更好的方法将std::deque的内容复制到字节数组中？似乎STL中应该有这样的东西。

// Generate byte-array to transmit
uint8_t * i2c_message = new uint8_t[_tx.size()];
if ( !i2c_message ) {
    errno = ENOMEM;
    ::perror("ERROR: FirmataI2c::endTransmission - Failed to allocate memory!");
} else {
    size_t i = 0;

    // Load byte-array
    for ( const auto & data_byte : _tx ) {
        i2c_message[i++] = data_byte;
    }

    // Transmit data
    _marshaller.sendSysex(firmata::I2C_REQUEST, _tx.size(), i2c_message);
    _stream.flush();

    delete[] i2c_message;
}

我正在寻找空间或速度或两者的建议......

编辑：应该注意_marshaller.sendSysex()无法投掷。

关注：

我认为值得重新考虑所有内容，因为评论非常有启发性（除了火焰战争）。 :-P

问题的答案......

使用std::copy

更大的图片：

不是简单地增加代码的原始性能，而是值得考虑为代码库添加健壮性和长寿性。

我忽略了 RAII - 资源获取是初始化。通过向另一个方向发展并略微受到性能影响，我可以在弹性方面获得巨大收益（正如@PaulMcKenzie和@WhozCraig所指出的那样）。事实上，我甚至可以将我的代码与依赖项中的更改隔离开来！

最终解决方案：

在这种情况下，我实际上可以访问（并且能够更改）更大的代码库 - 通常不是这种情况。我重新评估了*使用std::deque获得的好处，并将整个底层容器交换为std::vector。从而节省了容器交换的性能，并获得了连续数据和RAII的好处。

*我选择了一个std::deque，因为在发送之前我总是要push_front两个字节来完成我的字节数组。但是，因为它总是两个字节，所以我能够用两个虚拟字节填充向量，并用随机访问替换它们 - O（n）时间。

Answer 1

拥抱C ++标准库。假设_tx实际上是std::deque<uint8_t>，一种方法就是：

std::vector<uint8_t> msg(_tx.cbegin(), _tx.cend());
_marshaller.sendSysex(firmata::I2C_REQUEST, msg.size(), msg.data());

这将分配适当大小的连续缓冲区，从源迭代器对复制内容，然后调用您的发送操作。向量将在scope-exit上自动清理，如果用于构建它的分配以某种方式失败，则会抛出异常。

标准库提供了大量的方法来抛出数据，特别是给定标记位置的迭代器以及停止的位置。不妨利用它来获得优势。另外，让RAII处理这样的实体的所有权和清理而不是手动内存管理几乎总是一种更好的方法，应该受到鼓励。

总而言之，如果你需要连续性（并通过发送呼叫的外观判断，这正是你为什么这样做的话），那么从非连续空间复制到连续空间几乎是你唯一的选择，这需要空间和复制时间。你无能为力避免这种情况。我想偷看std::deque的实现细节，并且可能做堆叠发送调用之类的事情，但我真的怀疑会有任何奖励，并且唯一的节省可能会在多发送调用中消失。

最后，还有另一种选择可能值得考虑。看看所有这些的来源。 std::deque真的有理由吗？例如，当然你在其他地方建造那个容器。如果您可以使用std::vector以尽可能高效的方式执行构建操作，那么整个问题就会消失，因为您可以发送它。

例如，如果您知道（可证明）您的std::deque永远不会超过某个尺寸N，那么您可以预先确定{{1}的大小或类似的连续RAII保护分配，大小为std::vector，在中间启动前后迭代器对，并通过向后走前迭代器来预先添加数据，或者通过向后走向后迭代器来附加数据。最后，您的数据将在前后连续，并且发送仍然是剩余的。虽然仍需要增加空间，但不需要副本。这一切都取决于确定最大消息大小。如果您可以使用它，则可能是值得分析的想法。

将std :: deque内容复制到byte-array

1 个答案: