String Objekt vermeiden

International Deutsch
#1

Hallo Allerseits.

Folgendes Codefragment verbraucht mehr als 1,5kB Programmspeicher, wohl weil es das einzige Stringobjekt ist :(

    String name = "In";
    name += char(49 + input);
    name += " Pr";
    name += char(49 + set);
    name.toCharArray(g_act_Preset_s.g_Name,8);

Hat jemand eine Idee, wie man das elegant nur mit char[] lösen kann? Ich habe schon einige Varianten probiert, doch die führen leider immer zu diversen Fehlern, oder ist alles andere als elegant. Würde mich freuen, wenn mir jemand da einen kleinen Anschub geben könnte.

Besten Dank & Gruß

Lena

#2

Ganz einfach:

byte input = 1;
byte set = 2;
char buffer[] = "In* Pr*";
buffer[2] = input + '0';
buffer[6] = set + '0';

Geht natürlich nur für einstellige Ziffern

Zwei andere Tipps: 1.) Wenn man Strings nur mit der Arduino Print Klasse druckt, kann man sie einfach stückeln. Sie müssen nicht immer in einem String stehen 2.) toCharArray() braucht man nur für Schreibzugriff. Für Lesezugriff gibt es c_str()

#3

Bist du sicher, dass du char(49) = ‘1’ meinst und nicht ‘0’ ?

Was du mitg_act_Preset_s.g_Name willst, klären wir wenn du dazu mehr zu verrätst.
Evtl. ein strcpy, oder das kann man sich ganz sparen.

#4

Hallo Serenifly, vielen Dank für die schnelle Antwort. Ich könnte schwören, dieser Konstruckt war auch bei meinen erfolglosen Versuchen, aber offensichtlich war wohl doch ein Detail anders. Ich werde das gleich mal ausprobieren. Die beiden Variablen "Input" und "Set" bleiben auf jeden Fall einstellig. Ob die verwendete I2C-OLED-Lib verwendet print als Parent, also das sollte von daher gehen, doch das Array wird als Teil eines Struct auch im EEPROM abgelegt. Den zweiten Tip habe ich nicht ganz verstanden. Auf xy.name brauche ich später noch Schreibzugriff. Ach ja, jetzt sehe ich, was ich anders gemacht habe - ich habe stat eines neuen Arrays char buffer[] gleich xy.name genommen und da hat er mich ich glaube wegen illegaler Zuweisungen angemault. Muss ich denn bei Deinem Ansatz nicht buffer mit einer Loop nach xy.name kopieren?

#5

Nein, die 1 ist schon gewollt - das ist der angezeigte Name. preset ist ein Struct diverser Parameter und von diesen Presets werden insgesamt 16 im EEPROM abgelegt. .name ist halt der Name des individuellen Sets. An strcpy habe ich ach schon gedacht. Also den ganzen Namen im Constructor char name[8] aufbauen und dann mit strcpy nach g_act_Preset_s.g_Name kopieren - richtig? Das wäre genau was ich mir so vorgestellt habe.

#6

Auf xy.name brauche ich später noch Schreibzugriff.

Auf das String Objekt. Aber nicht auf das resultierende char Array. Wenn man das char Array nur zur Anzeige braucht reicht immer c_str(). Was anderes wäre z.B. strtok(), da die Funktion das Array verändert.

#7

Nein, genau umgekehrt. Das String Objekt existiert nur in dieser Funktion, aber auf das resultierende Array wird auch von anderen Funktionen schreibend zugegriffen. Der Namen kann später individuell eingegeben werden.

#8

Das String Objekt existiert nur in dieser Funktion, aber auf das resultierende Array wird auch von anderen Funktionen schreibend zugegriffen

Ok. Dann hätte es gepasst :) Das wäre eine korrekte Verwendung der Methode. Viele Leute verwenden es aber falsch. Genauso wie die String Klasse generell sehr oft falsch verwendet wird.

Also den ganzen Namen im Constructor char name[8] aufbauen und dann mit strcpy nach g_act_Preset_s.g_Name kopieren - richtig?

Das wäre in diesem Fall vernünftiger:

strcpy(g_act_Preset_s.g_Name, "In* Pr*"); 
g_act_Preset_s.g_Name[2] = ...
g_act_Preset_s.g_Name[6] = ...

Man kann das aber auf mehrere Arten lösen. Was am besten ist hängt davon ab wie der Rest des Codes genau aussieht.

#9

Nein, die 1 ist schon gewollt - das ist der angezeigte Name.

Also, wenn du diese Werte hast:

int input=1;
int set =2;

willst du diesen Namen haben für   g_act_Preset_s.g_Name :  "In2 Pr3"

Na, gut. Du verstehst dass ich mich wunderte ? ;)

Das wäre in diesem Fall vernünftiger: ... Man kann das aber auf mehrere Arten lösen. Was am besten ist hängt davon ab wie der Rest des Codes genau aussieht.

Da hat Serenifly natürlich recht. Die zusätzliche VariableString name;stört nur.

#10