The HATRED for String objects - "To String, or not to String"

When you're on a horse, you don't expect a steering wheel. An MCU is not a PC.

As far as not knowing C strings, once you understand what a char array with NULL terminator the rest with few exceptions is very straightforward. Yes there is some memorizing of shortened words but strcat() means string concatenation isn't hieroglyphs. Strtok() takes a bit of study but after writing your own array parsing it's no surprise at all. In fact I'd go so far as to say that writing your own version of any of those commands and then refining/rewriting to compact code will teach not only C string but better array handling and coding in general.

The old timers get that an MCU is not a PC. Many of us have written lots of code on both. We know to avoid the traps that the inexperienced walk right into and would rather save others from wasting their time.

I find C++ Strings annoying and unreliable on any platform. In Java I use strings but in C++ I use C-style char arrays.

How is your world of horses, buggies, and telegrams/bag phones?

I saw a feature on TV recently about small-scale logging, using draught horses to extract the timber.
The horses could go where the tractors could not, and their impact on the environment much less, and they could work woodlands too small for ordinary commercial operations.

A reasonable analogy, I think.

The right tool/technique for the right problem.

I'm fairly new to Arduino's, and C coding for that matter as well but have done PHP / MySQL / ASP / HTML coding before.

Can someone please explain to me, what to use if we shouldn't use strings? I see, in many forum posts, where people have problems they're simply being told "don't use strings", and more often than not no sample of an alternative piece of code is given for their problem so the OP in said forum thread doesn't learn anything. And, consequently other newbies don't learn anything useful either and still use strings, since most of the tutorials and forum sample code has them.

C++ Strings are objects that require memory allocation routines (malloc, free) to be called when they are used. For a long time, there was a bug in the implementation of free that the arduino uses that meant that you could run out of memory, so Strings were a dangerous proposition.

More recent versions of the IDE do not have this defect, but manipulating Strings still requires that you free and allocate memory. Given that arduinos have so little RAM, there is still the possibility that you will run out of space or fragment your free memory in such a way that there isn't a big enough contiguous piece to satisfy a request. At this point, your sketch will likely fail in unexpected ways, which will be hard to debug and when you ask for help on the forums you will be told "Don't use Strings".

There's nothing inherently wrong with C++ Strings if you have the memory for them and suitable error handling for dealing with low memory conditions, but for arduino, where you don't have these things, they are not sensible, particularly if your sketch is expected to run in perpetuity. As an alternative, arrays of char let you see exactly what memory you are using without any 'sleight of hand' stuff happening behind the scenes.

RudiAhlers:
I see, in many forum posts, where people have problems they're simply being told "don't use strings" ...

There is a terminology problem here. The posts usually say don't use "String" (which is a specific class) not "don't use strings".

Depending on your requirements you can use an array of characters using the normal C functions like strcpy and strcat. A lot of the Arduinos only have 2048 bytes of RAM, so you don't have a lot of memory for arrays, dynamically allocated strings, or anything else.

At least with manually allocated arrays you know how much memory they are taking. And for constants, you can use strings directly from program memory, eg.

Serial.println (F ("hi there"));

... where people have problems ...

Some problems are caused by the String class, when it had bugs. Some are caused even afterwards because of memory fragmentation. Some are unrelated. However when people post a lengthy sketch, which uses String extensively (as opposed to "strings") one of the first suggestions is to rework without using the String class.

... and more often than not no sample of an alternative piece of code is given for their problem ...

I have examples below which show receiving serial data. They stores strings into static buffers but do not use "String".

RudiAhlers:
Can someone please explain to me, what to use if we shouldn't use strings? I see, in many forum posts, where people have problems they're simply being told "don't use strings", and more often than not no sample of an alternative piece of code is given for their problem so the OP in said forum thread doesn't learn anything. And, consequently other newbies don't learn anything useful either and still use strings, since most of the tutorials and forum sample code has them.

Don't expect any of the "string" advocates to fix your code using the "string" functions, most likely due to the fact that the real code issue rarely ever has to do with using Strings. If persons can't wrap their head around the real issue, or are just stumped, they can always say "praise Jesus, drink more milk, and don't use Stings". Maybe the cure..., maybe not.

zoomkat:
Don't expect any of the "string" advocates to fix your code using the "string" functions

Give a man a fish...

zoomkat:
Don't expect any of the "string" advocates to fix your code using the "string" functions

... because there have been dozens, probably hundreds, of examples posted showing how to do this yourself and it is not hard.

zoomkat:
If persons can't wrap their head around the real issue, or are just stumped, they can always say "praise Jesus, drink more milk, and don't use Stings". Maybe the cure..., maybe not.

I can wrap my head around issues, thanks. When I see something obviously wrong, I mention it. If that doesn't fix it, we can move onto subtle things.

Example: If your care won't start, and it's out of petrol, that's probably the problem. Putting petrol in doesn't guarantee it will start, maybe the spark plugs are bad, but let's fix the simple stuff first.

[quote author=Nick Gammon link=topic=124367.msg1282736#msg1282736 date=1371555985]

RudiAhlers:
I see, in many forum posts, where people have problems they're simply being told "don't use strings" ...

My bad..... I didn't see the Capital S in "Strings", and misread it as "strings"

328P has 2k for heap and stack. That's not much room to have storage elements that copy themselves just to add 1 character, not to mention what that could do in time-critical apps.

I see the String Object school play down awareness of both hardware and what the software is doing. They learn to use/reply on wasteful black boxes and don't bother with simpler more direct code. That's okay when you're not pushing much more than halfway to limits. But step much beyond and then your ability to implement solutions begins with learning what you avoided for however long you did including different approaches to solutions that go with all that.

It's easier to match the tools (commands and techniques) to the environment. AVR's tend to be very small to small. What is trivial on a PC is not always going to fit well on an AVR. A bathtub that goes well in a house will be a poor fit on a bicycle regardless of the fact that yes you can fit a bathtub on a bicycle. Oh well let's be reasonable and just fit on a sink instead shall we?

zoomkat:
Don't expect any of the "string" advocates to fix your code using the "string" functions, most likely due to the fact that the real code issue rarely ever has to do with using Strings. If persons can't wrap their head around the real issue, or are just stumped, they can always say "praise Jesus, drink more milk, and don't use Stings". Maybe the cure..., maybe not.

Better read this then:

http://forum.arduino.cc/index.php?topic=172156.msg1284047#msg1284047

abocanegra:
So reworking the arduino code to utilize C++ chars rather than strings seems to have solved the problem with it acting inconsistently.

Another happy customer, once he removed "String".

What was really said :

So reworking the arduino code to utilize C++ chars rather than strings seems to have solved the problem with it acting inconsistently. The flicker that remained ended up a simple fix. I shortened the length of the wires connecting the buffers as much as physically possible (approximately an inch). I am still unsure why it only was a problem with the Uno and not the Duemilanove. Regardless, it works perfectly on both now. I am attaching a photo of the 1st panel running on the Raspberry Pi with an Uno (Left) and a Duemilanove (Right). All addresses work perfectly and no flicker.

zoomkat:
What was really said :

So reworking the arduino code to utilize C++ chars rather than strings seems to have solved the problem with it acting inconsistently. The flicker that remained ended up a simple fix. I shortened the length of the wires connecting the buffers as much as physically possible (approximately an inch). I am still unsure why it only was a problem with the Uno and not the Duemilanove. Regardless, it works perfectly on both now. I am attaching a photo of the 1st panel running on the Raspberry Pi with an Uno (Left) and a Duemilanove (Right). All addresses work perfectly and no flicker.

The inconsistent behaviour was resolved by removing the use of the problematic String class, as Nick Gammon indicated by his quote. The fact that there was also a hardware issue causing flickering is hardly relevant to this thread.

zoomkat:
What was really said :

So reworking the arduino code to utilize C++ chars rather than strings seems to have solved the problem with it acting inconsistently. The flicker that remained ended up a simple fix. I shortened the length of the wires connecting the buffers as much as physically possible (approximately an inch). I am still unsure why it only was a problem with the Uno and not the Duemilanove. Regardless, it works perfectly on both now. I am attaching a photo of the 1st panel running on the Raspberry Pi with an Uno (Left) and a Duemilanove (Right). All addresses work perfectly and no flicker.

I'm not satisfied with clues but that comes from years of debugging. So I went to that thread and ASKED the poster what that meant. Apparently Strings are Arduino code where char arrays are C++ to the beginner.
There's also the "reworking" part that you might have 'got' if you had looked at the original String-based code and the posts saying to ditch Strings, etc, that should have told you that the post you quoted does NOT actually support your view.

PeterH:

zoomkat:
What was really said :

So reworking the arduino code to utilize C++ chars rather than strings seems to have solved the problem with it acting inconsistently. The flicker that remained ended up a simple fix. I shortened the length of the wires connecting the buffers as much as physically possible (approximately an inch). I am still unsure why it only was a problem with the Uno and not the Duemilanove. Regardless, it works perfectly on both now. I am attaching a photo of the 1st panel running on the Raspberry Pi with an Uno (Left) and a Duemilanove (Right). All addresses work perfectly and no flicker.

The inconsistent behaviour was resolved by removing the use of the problematic String class, as Nick Gammon indicated by his quote. The fact that there was also a hardware issue causing flickering is hardly relevant to this thread.

Perhaps you missed the "I am still unsure why it only was a problem with the " part above. Obviously the OP had two different hardware setups (Uno and Duemilanove) on which he was originally getting different results. He made both code and hardware changes on the uno setup and got his desired results. Probably different microcontrollers on the two boards with different memory capacities requiring "string" usage on the one with less memory or less efficient memory handling.

If you're getting memory corruption then even trivial changes could potentially affect the symptoms - simply choosing a different board type could be enough, if it affects the resulting executable image.

In the posted PDF of the TLC5490 driver there are several errors that could well be a part of the issue. The power supply is a 7805 with minimal I/O bypassing, there is no current limiter/CC supply for the LED's and the comment about lead length's is really snarky... rather than indicate a fix it indicates bypassing problems and/or a lack of terminations (Pull-ups/downs) on the control lines. While Strings are certainly responsible for many of the issues, that the completed design works at all is to me a wonder.. I had to make those mistakes myself many years ago and learn from them.

Doc