Char to String?

Is it possible to convert a multiple chars or a char array to string? If so how?

recognize:
Is it possible to convert a multiple chars or a char array to string? If so how?

Well a string (lower case "s") is an array of characters terminated by a null. Is that what you're asking?

If you really want to dance with the devil and use a String, I believe that

char[] chArray = "some characters";
[...]
String str(chArray);

Will do what you want (and give you a String called 'str' that contains the character array)? Or perhaps I didn't understand your question?

Regards,

Brad
KF7FER

recognize:
Is it possible to convert a multiple chars or a char array to string? If so how?

Your title says String, but the question refers to a string.

I recommend using a strings (note the lower case 's'), which is a NULL terminated array of char.

Strings (the String objects) are not usually the best thing to use on a machine with such limited memory, as they are copied every time they are changed, and that will cause memory fragmentation and poor performance due to garbage collection as the String memory is deallocated when a new String is created.

You can do everything with strings that you can do with Strings, and without the grief.
As for putting a char into a string, it's a simple matter of assigning the char to an array element.

char str[] = "Hello";
str[0] = 'J';

str now contains "Jello".

This is where it gets confusing. There are two concepts to grasp here, and the difference is only a single letter being capitalized or not.

There is a "String" which is an object class that does dynamic memory allocation, with lots of argument if this is really appropriate on the limited architecture of the microcontrollers we use with the very limited memory space and no memory management unit to avoid fragmentation. Here is the link to the Arduino documentation for "String"s.

Then there is a "string" which is also called a c-string. It is nothing but an array of char datatype byte that has a null final character (value is zero, also stated as "\0" or 0x00 or 0b00000000). Sometimes the array is full, but often the array is only partially used. Lets say for example you define a c-string as char textSring[] = "Hello";. This would result in the array textString being 6 bytes long. The contents of this array would be:

array
index
element
contents
0 "H"
1 "e"
2 "l"
3 "l"
4 "o"
5 "\0"

When you use this c-string then what ever operation you use that understands c-strings (like Serial.print()) then it will scan through the array and stop retrieving values when it reaches the "\0".

Now if you later change the contents of the c-string to "Hi" the contents of this array would be:

array
index
element
contents
0 "H"
1 "i"
2 "\0"
3 "l"
4 "o"
5 "\0"

Again, when using a function like Serial.print(), it will scan through the array and stop when it reaches the first "\0", so the "lo\0" will be ignored.

Now if you try to change the contents of the string to "Greetings" the contents of this array would be:

array
index
element
contents
0 "G"
1 "r"
2 "e"
3 "e"
4 "t"
5 "i"

I'm not sure if the final "ngs\0" would just be dropped or will overwrite what ever happens to be after this array. Either way would be bad. If "ngs\0" is just dropped then when you use a function like Serial.print() then it would scan until it finds the first "\0", who knows where it will actually end, and what garbage you would get. If the "ngs\0" overwrites then you just overwrote other variables with garbage that could cause really random errors in other places of the program execution. Here is the link to the Arduino documentation for "string"s.

and that will cause memory fragmentation and poor performance due to garbage collection as the String memory is deallocated when a new String is created.

Thought that was fixed a good while back. Had something to do with the implementation of malloc or some such?

zoomkat:

and that will cause memory fragmentation and poor performance due to garbage collection as the String memory is deallocated when a new String is created.

Thought that was fixed a good while back. Had something to do with the implementation of malloc or some such?

I think the only way (or best way) to prevent/limit memory fragmentation is to use the "reserve" method. That will prevent memory fragmentation (until the number of bytes reserved has been exceeded).

Regards,

Brad
KF7FER

Thought that was fixed a good while back. Had something to do with the implementation of malloc or some such?

The problem with free() was fixed. The problem with Strings was not.

Imagine a sheet of cookie dough (your memory). You cut out a small cookie (allocate a String). You need a larger cookie (append a character to a String instance). You cut out a larger cookie, and put the first cookie back. Now, you need a couple more cookies (String instances). So, cut them out. Eventually, if the Strings keep growing, there is no one place to cut out a cookie, even though, overall, you still have plenty of dough. if you could pick the dough up and re-roll it you could cut out the needed cookie, but moving stuff around in memory is not possible.

Eventually, if the Strings keep growing, there is no one place to cut out a cookie, even though, overall, you still have plenty of dough. if you could pick the dough up and re-roll it you could cut out the needed cookie, but moving stuff around in memory is not possible.

Eventually if a c-string keeps growing, it will exceed its allocated space... crash. Moving stuff around in memory is not possible if those are the rules you set. I would think dynamic allocation would be much more efficient with memory management if done correctly. A memory management program probably has a certain amount of additional overhead, but it should also have the capability to in effect bit shift in the memory registers to maintain the registers filled without gaps. As long as the management system knows where the data segments are located, the dynamic allocation should be more memory efficient. Allocating memory in set static boxes [ ] [ ] [ ] seems inefficient if the memory needs for each allocation site vary widely.

I would think dynamic allocation would be much more efficient with memory management if done correctly.

No argument there. The problem is that the Arduino does not have any memory management except that done in malloc() and free(), which can leave memory looking like swiss cheese - plenty of memory available, but no contiguous block large enough to satisfy an allocation request.

A memory management program probably has a certain amount of additional overhead, but it should also have the capability to in effect bit shift in the memory registers to maintain the registers filled without gaps.

After handing back a pointer to memory, the memory management software can't change where that pointer points. Therefore, it can't move allocated blocks around (to different addresses) to make for a contiguous block of memory. Doing that would require that malloc() and free() deal with pointers to pointers.

As long as the management system knows where the data segments are located, the dynamic allocation should be more memory efficient. Allocating memory in set static boxes [ ] [ ] [ ] seems inefficient if the memory needs for each allocation site vary widely.

One of the tradeoffs that needs to be made when a system doesn't have an operating system and terrabytes of memory...