Repository navigation
Compatibility with std::string_view #1448
Description
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.
Activity
mike919192 commentedon Jun 1, 2026
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 functionto_std_string_view()seems fine with me.jwellbelove commentedon Jun 2, 2026
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 commentedon Jun 8, 2026
I think there is an argument that, if we are going to go down this road of explicit converting constructors or
to_xxxconversion functions, it should be applied across the library, rather than on a piecemeal basis.