Provide StringView

[Paulo Cabral Sanz]

Hey,

In c++17 std::string_view was added with great benefit, now functions that generally received a `char*` can basically access std::string const methods.

And other types of strings can be passed around to functions that just need a view to a c_str, being it a stack based string with const generics, a PROGMEM stored `char*`, or many others. With a implicit StringView construct for those it becomes transparent to the user.

In the Arduino ecosystem it's common to pass `String&` around to be able to access the const methods the String has. Like searching, comparing, copying a substring, etc.

But in a lot of those functions it's a simple std::string_view that's needed. So if the user has a PROGMEM char* they will have to allocate and copy it, just to call a function that uses the `String&` const API.

And since Arduino.cc is the core to many environments adding a StringView to it is a must as it allows most libraries to slowly move to it, avoiding unnecessary allocations. And ecosystems like ESP8266/Arduino to include it without breaking compatibility of their libs.

I'm prepared to provide a PR or initial code, but it seems trivial. I'm new to the Arduino.cc community, so it would be great to see if there is community support for the idea and someone to explain how to proceed.

I think there is a lot of content explaining the benefits of std::string_view, so there doesn't seem much for me to say right now in its defense.

[Dennis Lee Bieber]

On Wed, 13 Jan 2021 11:09:42 -0800 (PST), Paulo Cabral Sanz
<paul...@poli.ufrj.br> declaimed the
following:

>
>Hey,
>
>In c++17 std::string_view was added with great benefit, now functions that
>generally received a `char*` can basically access std::string const methods.
>

That likely means an update to the underlying gcc compiler
system/libraries.

Problem: there is already a fairly significant effort to update the
newer gcc backend stages to support AVR chips, which are the chips used on
the Uno and Mega(2560) {the Due uses ARM which gcc will support for some
time -- given all the Beaglebones and Raspberry-Pis are running loose}. The
core gcc developers are dropping support for some calling sequence and
aren't interested in updating the AVR backend.

From what I can find, Arduino is using a custom build of gcc 7.3 for
AVR. gcc 7.3 is only DRAFT C++17 capable (via a command line option).


--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

[Matthew Ford]

This write up
https://www.learncpp.com/cpp-tutorial/an-introduction-to-stdstring_view/
notes a number of things you have to look out for with the new string_view.
Even more holes for a novice Arduino user to fall into
and string_view dispenses with null terminators just to add more
confusion to the mix.

As a robust alternative which has detailed error messages,  I would
recommend my SafeString library.
https://www.forward.com.au/pfod/ArduinoProgramming/SafeString/index.html

You can wrap a char* in as SafeSting similiar to what string_view does
but without all the problems and new possible errors of string_view
and with a lot more functionality .
You can also wrap a char* with its size in a SafeString which allows you
to safely add extra chars to the existing char* but with SafeString's
bounds error checking and error messages.
If you modify the wrapped char*, outside SafeString, then SafeString
detects the changes at the next method call (unlike string_view)
SafeString's maintains it data as valid null terminated c-strings.
SafeString is available now with the current compiler.

matthew

[Paulo Cabral Sanz]

 

We do not need to copy the c++ standard, they do indeed have very diferente requirements than the Arduino framework. But we can learn from it while making na appropriate API that’s closer to String’s API. And while I agree newcomers may have a hard time with ownership and lifetimes we can explicit in the documentation that a StringView should not be stored around, or just not used if you don’t know what you are doing.

 

We should just make it a null terminated non-owning immutable string with String’s API. Most methods don’t need a String, but a StringView anyway.

 

With implicit constructors for general string types the regular inexperienced user won’t even notice, and the more experienced ones will make the wildly used libs taking that advantage.

 

Also a baked type to the Arduino environment is a must, otherwise integration with different libraries won’t be easy.

 

There is an open PR with an implementation already but it seems abandoned. I also have an implementation we have been using in production for some time that may serve as a start. But SafeString can also serve as one. Honestly to me the most importante thing is having a StringView API upstream Arduino, I’m not stuck in a specific implementation. Whatever works best for Arduino while allowing us to use PROGMEM char*, some other char*, String, or even std::string in the environments that’s available.

 

But I am indeed prepared to offer a PR to solve it, at least with a minimal implementation.

 

That improves integration since the user can be from whatever environment, the function doesn’t care who implemented the string they are using, they just have to convert it to a StringView. And builtin strings will do it implicitly.

I don’t see how libraries using StringView in methods can cause trouble to newcomers, they won’t even notice. And a comment can be enough to scare them away from using it wrong. I would argue it’s a safety tool more than a risk. A lot of newcomers have this naive idea that String’s are bad and use char* everywhere, which is even less type-safe without understanding ownership.

 

Paulo

--

You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/5d7ec37e-5670-76b6-87ad-4e058a55cd0d%40forward.com.au.