Da ich darauf hingewiesen wurde, meine String variablen besser durch std::string zu ersetzen habe ich einen test sketch erstellt.
Leider erkenne ich hier keinen Vorteil in bezug auf den Speicher.
Welche Vorteile ergeben sich nun daraus?
//#define USESTL //Uncomment to use.
#define STARTSTR "Str VS str:"
#ifdef USESTL
#include <ArduinoSTL.h>
std::string test = "std::string:";
std::ohserialstream sout(Serial);
#else
String test = "String:"; //+ STARTSTR;
#endif
void printtest()
{
#ifdef USESTL
sout << test << std::endl;
#else
Serial.println(test);
#endif
}
void setup() {
//Initialize serial and wait for port to open:
test += STARTSTR;
Serial.begin(38400);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
printtest();
}
void loop() {
if (Serial.available())
{
test += (char)Serial.read();
printtest();
}
}
Da ich darauf hingewiesen wurde, meine Sting variablen besser durch std::string zu ersetzen
Das kann ich mir kaum vorstellen....
Denn die Arduino String Klasse wurde als schlankere/spezialisierte Alternative zu std::string entwickelt.
std::string kann seine Vorteile ausspielen, wenn du Software für PCs oder ähnliche Geräte entwickelst.
Auf unseren kleinen AVRs ist es nicht ohne Grund deaktiviert.
Ich möchte dafür wetten, dass dir empfohlen wurde, Strings im C Stil zu verwenden!
Stimmt es, oder habe ich recht?
Genauer: ein Null-terminiertes char Array. Auch "C string" genannt
Und die Speicherverschwendung ist nicht das einzige Problem. Die String Klasse ist auch in ihrer Funktionalität stark eingeschränkt. Vor allem bei Formatierungs- und Konvertierungs-Funktionen
Die Bibliothek ist doch etwas zweifelhaft. Da sieht man auch sowas:
int hexToDec(String hexString)
Ein Objekt wird als Wert statt als Referenz übergeben. Das deutet doch sehr auf fehlende Programmierkenntnisse hin
Wenn Du ein lokales Chararray der Länge 0 anlegst und dort 3 Zeichen rein schreiben willst, ist das schon mal auch ohne Kenntnisse völlig unlogisch.
Die lokale Variable hexString existiert nach der Rückkehr nicht mehr, also ist das der 2. Fehler.
Au, au. Da wird wieder mal ein Zeiger auf eine lokale Variable zurückgegeben.
Und was soll ein Array der Länge 0 überhaupt sein?
Ein einzelnes Byte oder einen Integer kannst du auch per Wert übergeben. Aber bei einem Objekt sollte man das nicht tun (ein leeres String Objekt belegt schon 6 Bytes).
Dass strcat() nicht dazu da ist einzelne Zeichen anzuhängen sieht man schon an der Signatur der Funktion
Die Konvertierung nach Hex kann man auch leicht per Hand machen. Da muss man nicht eine sehr umfangreiche Funktion wie printf() bemühen. Ansonsten gibt es auch noch itoa() dafür
@Tommy56
woher soll ich wissen wir lang der string wird, wenn ich noch gar nicht weiß was ich rein schreibe?
wenn ich in setup() char test[0] erstelle geht es aber.
@Serifly
wenn ich return itoa(decValue); nehme kommt ein compilierfehler
too few arguments to function 'char* itoa(int, char*, int)'
wenn ich return itoa(decValue); nehme kommt ein compilierfehler
Du tippst also nur wild Code ein ohne dir mal die Beschreibungen der Funktionen durchzulesen
Und auch hier erwartest du irgendwie dass dir eine Funktion auf magische Art Speicher liefert. So geht das nicht! Bei diesen C Funktion musst du ein ausreichend großes Array als Parameter übergeben. Wenn die Funktionen einen Zeiger als Rückgabewert hat dann ist dass ein Zeiger auf das Array das man von außen übergeben hat
@harryberlin: Bei der von Dir zur Schau gestellten Unwissenheit, die Du aber um jeden Preis verteidigst, solltest Du Dir ein anderes Hobby suchen. Du zeigst, dass Du nicht gewillt bist etwas zu lernen.
harryberlin: @combie
Doch das geht, du musst nur LOW oder HIGH übergeben. arg1 ist nicht nötig. WAKE_PIN ist voerher definiert.
Das weiß ich doch!
Dann formuliere ich das mal um:
Du hast da ein Variadic Macro geschaffen.
Wozu?
Die Eigenschaft darf nicht genutzt werden, und das habe ich dir eben präsentiert.
Damit ist die Definition falsch.
Ein semantischer Fehler.
Und ich möchte nicht, dass sich hier "jeder Anfänger" den Fehler abschaut....
Denke bitte nicht, dass ich grundsätzlich was gegen Variadic Macros habe, denn das stimmt nicht.
Ich habe allerdings grundsätzlich was gegen jede Art von unnötigem Macro!
Und das ist hier der Fall: Unnötig!
Tipp:
Setze den Präprozessor nur für Angelegenheiten ein, die C++ nicht von sich aus leisten kann.
Meine Regel:
Jedes vermiedene #define ist ein gutes #define.
Jedes vermeidbare #define ist ein böses #define
