# New OpenCyphal Project Proposal: CETL **URL:** \ **Category:** Development & Maintenance\ **Created:** [February 9, 2023, 7:32pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825 "2023-02-09T19:32:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 7:32pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/1 "2023-02-09T19:32:51Z")
As we develop libcyphal and as C++ Nunavut matures there is an emerging need to share some basic container types between the two projects that are either not readily available in STL or not available in STL at our base support level of C++14. As such we have three ways forward: 1. **Write duplicate types for both projects and share nothing.** This is a bad plan since it forces the user to convert between two thread-bare implementations or co-ordinate overrides to their preferred implementations between both projects. 2. **Use Nunavut types in libcyphal directly.** This seems odd and problematic since the Nunavut types don’t exist until nnvg generation has completed and for reasons discussed in the thread below… 3. **Start a new OpenCyphal project: Cyphal Embedded Template Library.** This would be a common dependency of all OpenCyphal C++ code but would remain a disciplined set of types that are _in active use by OpenCyphal projects_. ![CETL](https://forum.opencyphal.org/uploads/default/original/2X/7/7819270e2e2c5d240a12cade5367277d8b3fb136.png) # Project Tenets - CETL does not supplant STL, [ETL](https://github.com/ETLCPP/etl), boost, or any other full-featured support library. It is not a general-purpose C++ support library and is limited to the minimum set of types needed to ensure OpenCyphal C++ projects are agnostic to these larger projects. - All OpenCyphal projects that use CETL shall allow total replacement of CETL types by providing compile-time overrides. - CETL types should support replacement by C++17 and newer concepts. Where a popular library diverges from the C++ standard CETL will prefer the standard (e.g. if ETL’s span and the C++20 span have different interfaces or behaviors CETL will mimic C++20) - CETL types will never require use of the default STL heap. They may require the user to specify an allocator before they can be instantiated. To help clarify, this is how the initial set of dependencies would work: ![CETL dependencies](https://forum.opencyphal.org/uploads/default/original/2X/9/9fda3448a9115ad74737d106442dd0610b20daea.png) I’m sure this list of tenets will grow as we discuss the proposal. Your feedback is requested: @pavel.kirienko , @erik.rainey, @aeriq, @lydiagh ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 7:41pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/2 "2023-02-09T19:41:36Z")
Yet another C++ container library (YTL), yay! The tenets look sensible, but look: > 1. **Use Nunavut types in libcyphal directly.** This seems odd and problematic since the Nunavut types don’t exist until nnvg generation has completed. This would make static analysis of the libcyphal codebase pretty hard. One of the basic tenets for libcyphal was to provide a batteries-included experience compared to the bare-PCB-solder-your-own-power-supply experience offered by libxxxard. Do I get this correctly? One consequence, if so, is that at least the high-level part of libcyphal will inevitably depend on DSDL-generated types. Such as, for instance, the register types, which I mentioned recently on Matrix; or, perhaps, the `uavcan.file.*` types, or diagnostics, and so on. This is already the case for PyCyphal where we also do static analysis, which works by treating DSDL compilation as part of the normal build process. If we accept that building libcyphal requires building DSDL first (which I think is a requirement for any Cyphal application anyway), then the dependency of libcyphal on nunavut-generated support types does not seem like a design flaw. wdyt? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 7:44pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/3 "2023-02-09T19:44:13Z")
This was my initial thought too but there’s an impedance mismatch in relying on Nunavut types for application-layer functions and relying on it for transport or media layer types. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 7:48pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/4 "2023-02-09T19:48:11Z")
Indeed, but even if you attempt to match the impedance inside libcyphal, at one point between the application layer and the transport layer you will have to depend on DSDL-generated types anyway, even if they are not directly exposed to the user (which I think is admissible in at least some cases, but this is a topic for another debate). ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 7:49pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/5 "2023-02-09T19:49:52Z")
One of the design tenets of libcyphal is that we can bring up the transport layer without the application layer. It seems to me this means that layer should be independent of any specific DSDL type and usable without nnvg codegen. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 7:55pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/6 "2023-02-09T19:55:33Z")
Are we sure that this: > _One of the design tenets of libcyphal is that we can bring up the transport layer without the application layer._ Implies this: > _that layer (should be independent of) \<…\> and (usable without) nnvg codegen._ But not this: > that layer (should be independent of) \<…\> and (usable without) CETL. Or, in other words, you don’t want to depend on Nunavut only for the sake of its support library and propose that maintaining a separate small library is the preferred alternative? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 8:06pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/7 "2023-02-09T20:06:34Z")
I do _not_ think that the transport layer should be independent of `TransportLayer[CETL := UserOverride]` > [@pavel.kirienko](#): > > Or, in other words, you don’t want to depend on Nunavut only for the sake of its support library and propose that maintaining a separate small library is the preferred alternative? That’s correct. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 8:10pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/8 "2023-02-09T20:10:27Z")
Okay. Do you already have a set of entities in mind that will be provided by the CETL API? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 8:16pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/9 "2023-02-09T20:16:22Z")
the variable\_length\_array from nunavut (possibly renamed), a span type, and the nunavut variant. We might also want to include an allocator or two so we can use the same memory pool in the libcyphal transport layer for (de)serializing types…perhaps? Definitely just start with the first three though. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 8:25pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/10 "2023-02-09T20:25:07Z")
![image](https://forum.opencyphal.org/uploads/default/original/2X/5/5e2dd91e32a054de357d88a61573ac350d2888b1.jpeg) ---
**Author:** ![erik.rainey](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/erik.rainey/32/20_2.png) [@erik.rainey](https://forum.opencyphal.org/u/erik.rainey)\ **Post date:** [February 9, 2023, 8:35pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/11 "2023-02-09T20:35:46Z")
Looks like `expected`, `unexpected`, too. Are those staying? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 9:34pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/12 "2023-02-09T21:34:33Z")
Does the “okaaaay” face mean you consider CETL a failure of design? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 9, 2023, 9:36pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/13 "2023-02-09T21:36:10Z")
It is my seal of endorsement. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 9, 2023, 9:39pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/14 "2023-02-09T21:39:24Z")
This is my seal of approval: ![image](https://forum.opencyphal.org/uploads/default/original/2X/8/8cac4b5c234f936e4b38a4c15d7931abc125f49b.jpeg) _Looks good to me!_ ---
**Author:** ![aentinger](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/aentinger/32/1428_2.png) [@aentinger](https://forum.opencyphal.org/u/aentinger)\ **Post date:** [February 10, 2023, 5:25am UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/15 "2023-02-10T05:25:59Z")
> [@scottdixon](#): > > - CETL does not supplant STL, [ETL](https://github.com/ETLCPP/etl), boost, or any other full-featured support library. It is not a general-purpose C++ support library and is limited to the minimum set of types needed to ensure OpenCyphal C++ projects are agnostic to these larger projects. I’m feeling/have felt the pain of not having such a thing as CETL and therefore highly endorse it 😉 . ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 10, 2023, 11:36am UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/16 "2023-02-10T11:36:55Z")
> [@scottdixon](#): > > variable\_length\_array from nunavut (possibly renamed), Should we name the types that are drop-in replaceable with `std::` alternatives the same as they are named in std to enhance compatibility? This would mean that the `cetl::variable_length_array` would become `cetl::vector`. ---
**Author:** ![erik.rainey](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/erik.rainey/32/20_2.png) [@erik.rainey](https://forum.opencyphal.org/u/erik.rainey)\ **Post date:** [February 10, 2023, 3:12pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/17 "2023-02-10T15:12:28Z")
The types could be named similarly but don’t need to be. The API however will need to be very similar so that the `std::` types can be dropped in easily with clever `using`s when customers have that available. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 10, 2023, 3:21pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/18 "2023-02-10T15:21:28Z")
Perhaps “compatibility” is a poor choice of word. What I mean is that from naming alone it would be evident that `cetl::vector<>` and `std::vector<>` are meant to be (somewhat) compatible and (mostly) drop-in replaceable, but if the former was named `cetl::variable_length_array<>`, the clarity is gone. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 10, 2023, 4:16pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/19 "2023-02-10T16:16:13Z")
> [@pavel.kirienko](#): > > Should we name the types that are drop-in replaceable with `std::` alternatives the same as they are named in std to enhance compatibility? This would mean that the `cetl::variable_length_array` would become `cetl::vector` Yeah, I agree, where the type can be textually replaced. variable\_length\_array is an interesting case since it does things that vector cannot. > [@erik.rainey](#): > > The types could be named similarly but don’t need to be. I disagree. I think the types should be textually replaceable save the change in namespace. For example, libcyphal could use CETL like this: ```auto #if __cplusplus >= 202002L # include namespace libcyphal { namespace types { template using span = std::span; } // namespace types } // namespace libcyphal #else # include "cetl/span.hpp" namespace libcyphal { namespace types { template using span = cetl::span; } // namespace types } // namespace libcyphal #endif ``` ---
**Author:** ![erik.rainey](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/erik.rainey/32/20_2.png) [@erik.rainey](https://forum.opencyphal.org/u/erik.rainey)\ **Post date:** [February 10, 2023, 4:34pm UTC](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825/20 "2023-02-10T16:34:12Z")
We will have to establish some tenets and guidelines for naming since functionality is not 1:1. Naming things in a similar way communicates correct notions _and_ incorrect notions. Documentation is key here. Some concepts just don’t carry over equivalently since common features are missing (no heap, no exceptions?). Vectors are possibly the _most_ contentious name and the most useful object in this discussion. They are typically thought of as a _dynamically sized_ array. It’s their key feature. If they _aren’t_ dynamic in `cetl` anymore then are they just arrays? Do they map to something in between `std::array` and `std::vector` while not being the same as either? Many of the objects would be 1:1 if they don’t have dynamic allocation in them, like your `span` example. I’m concerned that the `std::vector` drop-in would have to be an object with a templated size, which makes using it with a `using` statement somewhat hard. ETL has this exact problem. > **[vector](https://www.etlcpp.com/vector.html)** > > C++ > ETL > Embedded Template Library > Boost > Standard Template Library > Standard Library > STLA C++ template library for embedded applications > The embedded template library has been designed for lower resource embedded applications. It defines a set... That template definition of their vector is not a drop in replacement for `std::vector`, which has no size\_t field. Fundamentally they aren’t compatible constructions. Obviously some APIs are not possible to implement either in 1:1 fashion like `resize` (which does not return a value on failure). I guess what I’m saying is don’t make a `vector` type. It sets the wrong expectations. [Next page](https://forum.opencyphal.org/t/new-opencyphal-project-proposal-cetl/1825.md?page=2)