#include <Arduino.h>
#include "test.h"
MyClass myClass;
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial.println(myClass.getString());
Serial.println(myClass.getCharPointer());
Serial.println(myClass.getAnotherCharPointer());
}
void loop() {
// put your main code here, to run repeatedly:
}
I have these doubts that I would like to ask for suggestions.
Is returning the String class in Header files, not a good idea? For ESP32/ESP8266 they are okay as they have big memory but for Arduino Uno boards I see a lot of discussions about not using String because it is bad and causes memory fragmentation etc.
Is returning char * the safest way to make it compatible and useful to all MCU boards?
Next question in char pointer, I often see this pattern done when returning char pointers like in this Time.cpp wherein a static buffer is used and defined at the implementation file (test.cpp) and all functions(getCharPointer, getAnotherCharPointer) that needs to return a char pointer just manipulates the static char buffer by using strcpy. Is this the proper way to go in Arduino programming?
answer to 1 is does throwing more than you have to on an AVR's return stack seem like a good idea? You can do it, but not very far.
answer to 2. You can overload the class, the compiler only includes what's used in the hex.
answer to 3. Make a class that you point to and init, point it at the buffer. When you use default SD it has a 512 byte buffer you can work from. 40 years ago I did the same with drive buffers on S-100 work machines and SD runs the same basic way.
The String class wastes cycles and RAM for only convenience with guardrails.
C strings and pointers are next to the metal and far, far more flexible.
There's people here who can show you how to task on a single thread with No OS.
➜ return a const char * (if you don't want the caller to mess around with your buffer). If the caller wants a String, they can always do so by storing the returned value into a String instance.
note that there is a difference between the String version and the char * version. In the String version you always return a different String (copy). In the char * version, you always return the same pointer to the same buffer. So the way this needs to be coded depends on your needs too
You can also pass the address of your buffer or a pointer to your buffer to your function as an argument.
You can add the buffer size as well so the function will not write outside the buffer.
You will not need a return value then (as the return value is in the buffer argument).
Instead you can return a bool to confirm that the function succeeded.
This way you will not depend on a global buffer. You can also have multiple buffers if needed.
Functions of the string manipulation library often use this method.