• q5_739116
  • 37.5KB
  • zip
  • 0
  • VIP专享
  • 0
  • 2022-05-13 08:51
static_vector 具有固定容量和嵌入式存储的可动态调整大小的向量(修订版3) 文件编号:P0843r3。 日期:2019-01-20。 项目:C ++编程语言,图书馆工作组。 观众:LEWG。 回复:Gonzalo Brito Gadeschi <rwth-aachen点de的gonzalo.gadeschi。 目录 5.3破坏 5.4尺寸和容量 5.5元素和数据访问 5.6修饰符 5.7专用算法 6.致谢 7.参考 变更日志 修订4 LEWG建议在超出容量时, push_back应该是UB LEWG建议这应该是一个独立的标头 修订版3 包括有关LEWG的LWG设计问题。 包含LWG反馈。 修订版2 将占位符名称fixed_capacity_vector替换为static_vector 除去at检查元素访问成员函数。 添加更改日志部分。 修订1
  • static_vector-master
  • ci
  • test
  • test.cpp
  • utils.hpp
  • CMakeLists.txt
  • cmake
  • targets.cmake
  • flags.cmake
  • options.cmake
  • packages.cmake
  • include
  • experimental
  • fixed_capacity_vector
  • .clang-tidy
  • .clang-format
  • CMakeLists.txt
  • .travis.yml
  • .gitignore
# static_vector<T> > A dynamically-resizable vector with fixed capacity and embedded storage (revision 3) **Document number**: P0843r3. **Date**: 2019-01-20. **Project**: Programming Language C++, Library Working Group. **Audience**: LEWG. **Reply-to**: Gonzalo Brito Gadeschi <gonzalo.gadeschi at rwth-aachen dot de>. # Table of contents - [1. Introduction](#INTRODUCTION) - [2. Motivation](#MOTIVATION) - [3. Existing practice](#EXISTING_PRACTICE) - [4. Design Decisions](#DESIGN) - [4.1 Storage/Memory Layout](#STORAGE) - [4.2 Move semantics](#MOVE) - [4.3 `constexpr` support](#CONSTEXPR) - [4.4 Exception safety](#EXCEPTION) - [4.5 Iterator invalidation](#ITERATOR) - [4.6 Naming](#NAMING) - [4.7 Potential extensions](#EXTENSIONS) - [5. Technical Specification](#TECHNICAL_SPECIFICATION) - [5.1 Overview](#OVERVIEW) - [5.2 Construction](#CONSTRUCTION) - [5.3 Destruction](#DESTRUCTION) - [5.4 Size and capacity](#SIZE) - [5.5 Element and data access](#ACCESS) - [5.6 Modifiers](#MODIFIERS) - [5.7 Specialized algorithms](#SPEC_ALG) - [6. Acknowledgments](#ACKNOWLEDGEMENTS) - [7. References](#REFERENCES) ### Changelog #### Revision 4 - LEWG suggested that `push_back` should be UB when the capacity is exceeded - LEWG suggested that this should be a free-standing header #### Revision 3 - Include LWG design questions for LEWG. - Incorporates LWG feedback. #### Revision 2 - Replace the placeholder name `fixed_capacity_vector` with `static_vector` - Remove `at` checked element access member function. - Add changelog section. #### Revision 1 - Minor style changes and bugfixes. # Design Questions from LWG to LEWG LWG asks LEWG to re-consider the following two design decisions: * In this document, exceeding the capacity in methods like `static_vector::push_back` is a pre-condition violation, that is, if the capacity is exceeded, the behavior is undefined. LWG suggested that exceeding the capacity in these methods should `std::abort` instead. The trade-offs in this space are discussed in Section [4.4 Exception safety](#EXCEPTION) of this proposal. * In this document, `<static_vector>` is a _free-standing_ header, this is now clarified in Section [5. Technical Specification](#TECHNICAL_SPECIFICATION). LWG suggests that `static_vector` should be included in `<vector>` instead. # <a id="INTRODUCTION" rel='nofollow' onclick='return false;'></a>1. Introduction This paper proposes a modernized version of [`boost::container::static_vector<T,Capacity>`][boost_static_vector] [1]. That is, a dynamically-resizable `vector` with compile-time fixed capacity and contiguous embedded storage in which the elements are stored within the vector object itself. Its API closely resembles that of `std::vector<T, A>`. It is a contiguous container with `O(1)` insertion and removal of elements at the end (non-amortized) and worst case `O(size())` insertion and removal otherwise. Like `std::vector`, the elements are initialized on insertion and destroyed on removal. For trivial `value_type`s, the vector is fully usable inside `constexpr` functions. # <a id="MOTIVATION" rel='nofollow' onclick='return false;'></a>2. Motivation and Scope The `static_vector` container is useful when: - memory allocation is not possible, e.g., embedded environments without a free store, where only a stack and the static memory segment are available, - memory allocation imposes an unacceptable performance penalty, e.g., with respect to latency, - allocation of objects with complex lifetimes in the _static_-memory segment is required, - `std::array` is not an option, e.g., if non-default constructible objects must be stored, - a dynamically-resizable array is required within `constexpr` functions, - the storage location of the `static_vector` elements is required to be within the `static_vector` object itself (e.g. to support `memcopy` for serialization purposes). # <a id="EXISTING_PRACTICE" rel='nofollow' onclick='return false;'></a>3. Existing practice There are at least 3 widely used implementations of `static_vector`: [Boost.Container][boost_static_vector] [1], [EASTL][eastl] [2], and [Folly][folly] [3]. The main difference between these is that `Boost.Container` implements `static_vector` as a standalone type with its own guarantees, while both EASTL and Folly implement it by adding an extra template parameter to their `small_vector` types. A `static_vector` can also be poorly emulated by using a custom allocator, like for example [Howard Hinnant's `stack_alloc`][stack_alloc] [4], on top of `std::vector`. This proposal shares a similar purpose with [P0494R0][contiguous_container] [5] and [P0597R0: `std::constexpr_vector<T>`][constexpr_vector_1] [6]. The main difference is that this proposal closely follows [`boost::container::static_vector`][boost_static_vector] [1] and proposes to standardize existing practice. A prototype implementation of this proposal for standardization purposes is provided here: [``][fixed_capacity_vector]. # <a id="DESIGN" rel='nofollow' onclick='return false;'></a>4. Design Decisions The most fundamental question that must be answered is: > Should `static_vector` be a standalone type or a special case of some other > type? The [EASTL][eastl] [2] and [Folly][folly] [3] special case `small_vector`, e.g., using a 4th template parameter, to make it become a `static_vector`. The paper [P0639R0: Changing attack vector of the `constexpr_vector`][constexpr_vector_2] [7] proposes improving the `Allocator` concepts to allow `static_vector`, among others, to be implemented as a special case of `std::vector` with a custom allocator. Both approaches run into the same fundamental issue: `static_vector` methods are identically-named to those of `std::vector` yet they have subtly different effects, exception-safety, iterator invalidation, and complexity guarantees. This proposal follows [`boost::container::static_vector<T,Capacity>`][boost_static_vector] [1] closely and specifies the semantics that `static_vector` ought to have as a standalone type. As a library component this delivers immediate value. I hope that having the concise semantics of this type specified will also be helpful for those that want to generalize the `Allocator` interface to allow implementing `static_vector` as a `std::vector` with a custom allocator. ## <a id="STORAGE" rel='nofollow' onclick='return false;'></a>4.1 Storage/Memory Layout The container models `ContiguousContainer`. The elements of the `static_vector` are contiguously stored and properly aligned within the `static_vector` object itself. The exact location of the contiguous elements within the `static_vector` is not specified. If the `Capacity` is zero the container has zero size: ```c++ static_assert(is_empty_v<static_vector<T, 0>>); // for all T ``` This optimization is easily implementable, enables the EBO, and felt right. ## <a id="MOVE" rel='nofollow' onclick='return false;'></a>4.2 Move semantics The move semantics of `static_vector<T, Capacity>` are equal to those of `std::array<T, Size>`. That is, after ```c++ static_vector a(10); static_vector b(std::move(a)); ``` the elements of `a` have been moved element-wise into `b`, the elements of `a` are left in an initialized but unspecified state (have been moved from state), the size of `a` is not altered, and `a.size() == b.size()`. Note: this behavior differs from `std::vector<T, Allocator>`, in particular for the similar case in which `std::allocator_traits<allocator rel='nofollow' onclick='return false;'>::propagate_on_container_move_assignment` is `false`. In this situation the state of `std::vector` is initialized but unspecified. ## <a id="CONSTEXPR" rel='nofollow' onclick='return false;'></a>4.3 `constexpr` support The API of `static_vector<T, Capacity>` is `constexpr`. If `is_trivially_copyable_v<T> && is_default_constructible_v<T>` is `true`, `static_vector`s can be seamlessly used from `constexpr` code. This allows using `static_vector` as a `constexpr_vector` to, e.g., implement other constexpr containers. The implementation cost of this is small: the prototye implementation specializes the storage for trivial types to use a C array with value-initialized elements
    • 嵌入式.rar
      1.数字计算机的组成一般如图所示,主要包括运算器、存储器、控制器以及各种外部输入输出设备的适配器,它们之间由系统总线进行互连。通常把( )称为中央处理器。 [1分] A控制器和适配器 B适配器和系统总线 ...
    • BESSy DB:二进制嵌入式存储系统。-开源
      二进制嵌入式存储系统(BESSy)旨在为本地存储提供小型,快速的嵌入式存储库系统。 BESSy数据库是一个完全原子的,可查询的基于文件的数据库。 这是存储任何大小对象的可靠且快速的方法。 该数据库是多线程的,将...
    • 嵌入式系统
      电子科技大学 嵌入式系统设计研究生课程(包含嵌入式系统设计概论、硬件概论_处理器、存储器及IO设备、通信接口、设计实例、软件设计_RTOS等)
    • wickdb:基于Pure Rust LSM树的嵌入式存储引擎
      wickdb:基于Pure Rust LSM树的嵌入式存储引擎
    • 嵌入式Linux的存储技术
    • 嵌入式Linux的存储技术
      嵌入式存储的发展与挑战 嵌入式Linux存储方式的介绍 嵌入式Linux对流行存储设备的支持 嵌入式Linux存储方案的选择策略
    • ioarena:嵌入式存储基准测试工具
      ioarena-嵌入式存储基准测试 ioarena是一种用于评估嵌入式数据库性能的实用程序。 该项目的目标是提供一种标准的,易于使用的基准测试工具,以便任何数据库开发人员或用户都可以引用或重复获得的结果。 基准测试...
    • 嵌入式存储设备的FS
      SD+CF+NandFlash(有点小问题^_^)+ZLG_FFS/FS+UCOS 其中SD和CF都已实现,NandFlash有点小问题.
    • MAX10闪存、模数、嵌入式存储指南.zip
    • GaussDB_100_1.0.1-DATABASE-REDHAT-64bit.tar.gz