Use of char arrays (C strings) Vs Strings (discussion)

[drmpf]

@Whandall

On a Nano don’t use Strings

Strings are perfectly safe on a Nano, because on the AVR boards they always keep 128bytes of stack free for the program to run. So can easily debug with print()s

For a variety of solutions to read from Serial, that don't use c-strings, see my Arduino Software Solutions

For the python side, this code might give you some ideas
SerialComsPairSendInput.py

And there is also this post Demo of PC-Arduino comms using Python

on any single thread system don’t use delay

While that is very good advice, I have a SerialComs class that is very tolerant of delays in the loop and of course it is difficult to avoid delays on the python side if you ask for user input.

[Mod edit]
I have split this from Data in serial comm going more than expected as it wasn't really in answer the the OP's original question, but worth discussing separately.

[Whandall]

@drmpf

Strings are perfectly safe on a Nano,

I beg to disagree.

[drmpf]

Happy to see an example sketch that illustrates a problem, if you can find one.
You are the third poster I have asked and no takers so far.

My tutorial on Taming Arduino Strings covers using Strings in detail and includes and Out-Of-Memory example on UNO, which just happily keeps running.

[PerryBebbington]

@drmpf
Please can you clarify which of these is true:

Strings can be a problem if not used with the correct precautions and understanding,
or,
Strings don't cause problems.

I ask because if the first is true then folk will see problems with Strings and will ask about them here, maybe the answer is to direct them to your tutorial. If the second is true then whatever problems people see cannot be caused by Strings.

[Whandall]

@drmpf

Happy to see an example sketch that illustrates a problem

@sud_shenoy

void readSerialPort() {
  msg = "";
  if (Serial.available()) {
    delay(10);
    while (Serial.available() > 0) {
      msg += (char)Serial.read();
    }
    Serial.flush();
  }
}

A global String gets concatenated unlimited.

[drmpf]

I'd direct you to my tutorial for the answer. If you find it confusing let me know and I will try and make it clear

[drmpf]

@Whandall

global String gets concatenated unlimited.

Not on AVR boards. Check out my Out-of-memory example in the tutorial.

[Whandall]

@drmpf

Check out my Out-of-memory example in the tutorial.

How does that invalidate the problem of the code in this very thread?

You are free to use Strings on small AVRs, I will not.

[drmpf]

@Whandall

the problem of the code in this very thread

The code you posted will do the best it can with the memory available and NOT crash the sketch.
That to me is very very safe and easy to use.
Using Strings does automatically fix logic errors, but the code does not go boom so you can set about debugging it with print statements.

[Whandall]

@drmpf

The code you posted will do the best it can with the memory available and NOT crash the sketch.

It will do its best to fragment the heap. Where did I claim it would crash the sketch?

IMHO and my experience Strings have no benefit that would outweigh their risks in small AVR environments.

[PerryBebbington]

OK, I've read some of the tutorial, enough to be convinced.

Thanks, I'll keep a link to it.

[drmpf]

@Whandall

It will do its best to fragment the heap ... risks in small AVR

What does that matter if the code runs?
Actually in the example you gave there is no heap fragmentation.
If the heap does fragment (and you can make that happen) then you just run out of memory earlier, still no crash, still able to debug.
My tutorial has guidelines and tools to solve those problems.

The alternative of char[ ] and low level c-string methods are much 'riskier', even for experienced programmers. Microsoft has band their use for that reason.

The BIG benefit Strings have is that they are not 'fragile' like char[] and c-string methods and Strings provide convenient and natural methods that get you up and running fast.
Later you can replace them with my SafeString library of you want to move to fixed sized char[ ] and still keep the safety and similar functionality of Strings.

[Whandall]

@drmpf

The BIG benefit Strings have is that they are not ‘fragile’ like char and c-string methods

You know that that statement is not true.
All char and c-string functions are without any surprises and have a fixed runtime.

I don't like to argue with fundamentalists, so lets stop right here.

[sud_shenoy]

Thank you everyone for making me understand many small details which I missed. I tried a lot of things and I finally could make it work.

[drmpf]

@Whandall

All char and c-string functions are without any surprises

Except when you use one to accidentally write past the end of the array and the code goes boom!@!. Lots of those types of surprises posted on this forum.

[Whandall]

@drmpf

Except when you use one to accidentally write past the end of the array

That is not a feature of the functions, but an error of the user.

Most users manage to do overwrites without using any library calls.

The c-string functions are optimized for speed and do not check their parameters,
they are by no means foolproof and nobody claims that.

It's the simple garbage in - garbage out principle.

[drmpf]

@Whandall

c-string functions are optimized for speed

Not really the issue here is it. The slowest and most inefficient part of any program is the coder.

an error of the user

That is what most of these forum posting are about. Anything that reduces those user errors in an improvement.

Using Strings, as the first goto, get the user to a running program faster.
Getting side tracked into c-string methods which are not documented in the Arduino Language Reference and have to be handled very carefully not to crash your sketch just slows them down.

Arduino choose Strings over c-strings for good reasons, they are easier to get results with for first time users.

[Whandall]

@drmpf

Using Strings, as the first goto, get the user to a running program faster.

Like delay this is only good for some basic tinkering.

@drmpf

Getting side tracked into c-string methods which are not documented in the Arduino Language Reference and have to be handled very carefully not to crash your sketch just slows them down.

There is no Arduino Language, 'just' some APIs and libraries, regardless of Ardunio calling it so.
There is no reason to document the C++ language and the basic library functions here.
You will have to learn at least basic C++ to be successful beyond copy/paste.

@drmpf

Arduino choose Strings over c-strings for good reasons, they are easier to get results with for first time users.

Strings and c-strings are not mutually exclusive, Strings are a dynamic layer on top of c-strings,
so there was no choice to begin with.
I suspect the reason to include Strings was more the Java background of the Arduino creators.

[drmpf]

@Whandall

Like delay this is only good for some basic tinkering.

Except ESP32 uses them extensively in the web support for not just for tinkering

There is no Arduino Language,

Check out the Arduino Language Reference for what new users think of as the Arduino Language. No c-string methods there. Not really much C++ either. Just the minimal to get users up and running.

Strings and c-strings are not mutually exclusive

I agree which why i wrote my SafeString library. I wanted a the safety and functionality of Strings but working with '\0' terminated fixed length char[..]

I wanted to avoid having my code crash every time I got a length wrong, passed a null pointer, missed adding the terminating '\0' or made an off by 1 indexing error.

SafeString gives me nice detailed error messages in those cases, with the name of the variable that has the problem.

I suspect the reason to include Strings was more the Java background of the Arduino creators.

Could be, but could also could be that C++ introduced Strings 20 years ago to overcome the systemic coding errors that were occurring using c-string methods.
When Microsoft band using standard c-string methods, due to persistent coding errors, they recommended using Strings.

[Whandall]

@drmpf

@Whandall

Like delay this is only good for some basic tinkering.

Except ESP32 uses them extensively in the web support for not just for tinkering

We are talking about small AVRs, so that is irrelevant.

@drmpf

There is no Arduino Language,

Check out the Arduino Language Reference for what new users think of as the Arduino Language.

I don't care what misconceptions some people have, that is irrelevant too.

@drmpf

When Microsoft band using standard c-string methods, due to persistent coding errors, they recommended using Strings.

If there is a sufficiently big heap, Strings are much less of a problem and MS does not support AVRs, so again irrelevant.