Replace estd with ETL

[marcmo]

We are currently relying on estd, our own implementation of an embedded suitable template library that we use instead of the STL.
There is another project that seems to be well-maintained and of good quality which we could consider as an alternative.
https://www.etlcpp.com/
what's your thought on this?

[rolandreichweinbmw]

A great idea in my opinion, since I would use OpenBSW together with ETL anyway. For me, this would be a good choice, preventing multiple embedded template libraries in one single project in parallel.

In some of my recent PRs at https://github.com/ETLCPP/etl , I added some missing interfaces that help switching from ESTD to ETL. I hope John Wellbelove soon releases a new version with those to prevent duplicate work or confusion here.

[filipe-cuim]

I also think it is a good idea. I've worked a good amount with ETL and it offers a very nice replacement to STD for static sized data structures.
Also it offers additional things that STD may not include, and that might be helpful in certain situations (see for example the methods of etl::array).
It also has a nice way to configure the library with the etl_profile.h files, in case you want to have specific behavior for your project (for example, using std's implementation of algorithms that do not rely on the heap).

[christian-schilling]

The use case of typed_mem is very specific and cannot be replaced by optional:
For embedded systems it makes no sense to have destructors for objects in the global scope, but the compiler will still always generate them and increase the binary size even though they will never be executed.
So to save ROM space we wrap global objects in typed_mem which will not call the destructor of the contained type and thus
allow the compiler/linker to omit the destructor from the binary.

[rolandreichweinbmw]

Thanks for the insight! That's how I understood Martin before. And current etl::optional always references the dtors, so can't be used as-is as Christian pointed out. I see 2 major options here:

1. Contribute typed_mem.h to etl and use it from there
2. Move typed_mem.h to libs/bsw/util/include/util/estd/ as I did w/ assert.h (since the goal is to replace libs/bsw/estd with libs/3rdparty/etl altogether)

What would you prefer?

[vladyslavmarkovaccenture]

The use case of typed_mem is very specific and cannot be replaced by optional: For embedded systems it makes no sense to have destructors for objects in the global scope, but the compiler will still always generate them and increase the binary size even though they will never be executed. So to save ROM space we wrap global objects in typed_mem which will not call the destructor of the contained type and thus allow the compiler/linker to omit the destructor from the binary.

Oh, that what was meant by optimizing away the dtr. I misunderstood that part. Then my previous comment is irrelevant 😅

[vladyslavmarkovaccenture]

Regarding ETL alternatives again. I think etl::aligned_storage_as<...>::type might be close.

[rolandreichweinbmw]

Thanks Vladyslav for the hint! Looks like I missed that one. :-)

Since etl::aligned_storage_as doesn't directly support a typed interface similar to estd::typed_mem, how about extending include/etl/alignment.h based on etl::aligned_storage_as like this, to provide a drop-in replacement for estd::typed_mem:

namespace etl
{
  //***************************************************************************
  /// Wrapper class that provides a memory area and lets the user emplace and
  /// instance of T in this memory at runtime. This class also erases the
  /// destructor call of T, i.e. if typed_storage goes out of scope, the
  /// destructor if the wrapped type will not be called. This can be done
  /// explicitly by calling destroy().
  /// \tparam T    Type of element stored in this instance of typed_storage.
  //***************************************************************************
  template <typename T>
  class typed_storage
  {
  public:

    using value_type      = T;
    using reference       = T&;
    using const_reference = T const&;
    using pointer         = T*;
    using const_pointer   = T const*;

    // Constructor
    typed_storage()
      : valid(false)
    {
    }

    //***************************************************************************
    /// Default destructor which will NOT call the destructor of the object which
    /// was created by calling emplace().
    //***************************************************************************
    ~typed_storage() = default;

    //***************************************************************************
    /// Calls the destructor of the wrapped object and asserts if has_value() is false.
    //***************************************************************************
    void destroy()
    {
      ETL_ASSERT(has_value(), ETL_ERROR(etl::typed_storage_error));
      data.template get_reference<T>().~T();
      valid = false;
    }

    //***************************************************************************
    /// \returns true if object has been constructed using emplace().
    /// \returns false otherwise.
    //***************************************************************************
    bool has_value() const
    {
      return valid;
    }

    //***************************************************************************
    /// Constructs the instance of T forwarding the given \p args to its constructor and
    /// asserts if has_value() is true before calling emplace().
    ///
    /// \returns the instance of T which has been constructed in the internal byte array.
    //***************************************************************************
    template<typename... Args>
    reference emplace(Args&&... args)
    {
      ETL_ASSERT(!has_value(), ETL_ERROR(etl::typed_storage_error));
      valid = true;
      return *new (data.template get_address<char>()) value_type(etl::forward<Args>(args)...);
    }

    //***************************************************************************
    /// \returns a pointer of type T and asserts if has_value() is false.
    //***************************************************************************
    pointer operator->()
    {
      ETL_ASSERT(has_value(), ETL_ERROR(etl::typed_storage_error));
      return data.template get_address<value_type>();
    }

    //***************************************************************************
    /// \returns a const pointer of type T and asserts if has_value() is false.
    //***************************************************************************
    const_pointer operator->() const
    {
      return operator->();
    }

    //***************************************************************************
    /// \returns reference of type T and asserts if has_value() is false.
    //***************************************************************************
    reference operator*()
    {
      return *operator->();
    }

    //***************************************************************************
    /// \returns const reference of type T and asserts if has_value() is false.
    //***************************************************************************
    const_reference operator*() const
    {
      return *operator->();
    }

  private:

    typename aligned_storage_as<sizeof(value_type), value_type>::type data;
    bool valid;
  };
}

[rolandreichweinbmw]

I set up a pull request: #58

Still some rough edges, but please have a look by reviewing.

[rolandreichweinbmw]

Some more thoughts about the differences between ETL and ESTD:

What I like about ETL:

• The split of definition and interface (e.g. etl::queue vs. etl::iqueue) follows a simple convention, without an additional "declare" namespace
• Method names in pool implementations follow the intuitive convention of containers of which resources can be allocated: full() and empty(). Even though the switchover needs to be done globally once (full() and empty() semantics are swapped!), it might be helpful in the long run.
• It follows modern STL convention of functionname(source, dest) instead of functionname(dest, source) e.g. for copy
• Some interfaces are closer to STL / std::, e.g.
  • etl::ref (std) instead of estd::by_ref
  • span instead of slice
  • span::subspan like std; estd::slice::subslice is different
  • span constructor available for (pointer, size) - like in std, instead of slice::from_pointer()
  • span supports first() and last() like std::span

What I don't like about ETL:

• Recommends etl::delegate instead of etl::function which is marked as deprecated
• etl::generic_pool definition always needs alignment stated explicitly

[rolandreichweinbmw]

Update: We now have a new function wrapper etl::inplace_function with value semantics, in contrast to etl::delegate.

[rolandreichweinbmw]

In the forseeable future, we still have some deviation from ETL, even though we have most of our adjustment work merged in upstream ETL already.

Some of the contributed features in ETL are still pending for next official ETL release. Probably available in ETL 21.x. A few others still in discussion.

Therefore, I propose setting up a (sub) repo in the OpenBSW project e.g. https://github.com/eclipse-openbsw/etl to be independent of the upstream ETL release process. Just to track latest adjustments and improvements for OpenBSW, still in integration process to upstream ETL.

[rolandreichweinbmw]

ETL finally replaced ESTD in OpenBSW, so this discussion can be closed.