Compatibility with std::string_view

[pwsoftwaredesigns]

I ran into a compatiblity issue between etl and the standard library when working with strings. My existing code uses std::string_view (instead of etl::string_view). It appears that ETL has no conversion between the two types so I cannot, for example, do the following:

etl::string<64> myString;
std::string_view myStringView; //Assume this is provided somewhere else

myString += myStringView;

I noticed the following preprocessor test in string_view.h:

#if ETL_USING_STL && ETL_USING_CPP17
  #include <string_view>
#endif

But, other than include std::string_view, it doesn't seem to do anything with it.

My solution was to make the following changes:

In string_view.h
Wrap the basic_string_view class in a preprocessor check that simply causes etl::basic_string_view to std::basic_string_view

#if ETL_USING_STL && ETL_USING_CPP17
  template <typename T, typename TTraits = std::char_traits<T> >
  using basic_string_view = std::basic_string_view<T, TTraits>;
#else
  template <typename T, typename TTraits = etl::char_traits<T> >
  class basic_string_view
  {
  //EXISTING CODE...

In basic_string.h
Add an implicit conversion operator in ibasic_string to etl::basic_string_view

template <typename T>
class ibasic_string : public::string_base
{
//EXISTING CODE...

//*************************************************************************
/// Conversion operator to etl::basic_string_view.
//*************************************************************************
operator etl::basic_string_view<T>() const
{
  return etl::basic_string_view<T>(p_buffer, size());
}

That way, if std::string_view is available, ETL just uses it directly.

The other option I can think of would be to explicitly add conversion operators and constructors for std::string_view (along with etl::string_view) to etl::ibasic_string.

[mike919192]

I'll just add my opinion that I would not like the first option of substituting etl::string_view with std::string_view. My target has most of std available but I still prefer to use etl types for the error handling configuration. My thinking is that if std types are used that can throw eventually someone will accidentally introduce code that can throw and halt the program. Better to use the etl types that can be configured to never throw.

A few times where I have needed to convert to std string_view, I used the constructor std::string_view(etl_view.data(), etl_view.size()). A member function to_std_string_view() seems fine with me.

[jwellbelove]

I decided to avoid creating converting constructors where the class has the necessary data to use one of the standard constructors i.e. std::string_view(etl_view.data(), etl_view.size()).
I don't like the idea of too many hidden implicit conversions.

A to_std_string_view() & to_etl_string_view() could be acceptable.

[jwellbelove]

I think there is an argument that, if we are going to go down this road of explicit converting constructors or to_xxx conversion functions, it should be applied across the library, rather than on a piecemeal basis.