Fehlersuche

[combie]

Und du stellst Falschbehauptungen auf.
Darauf habe ich keinen Bock.

Behalte sie für dich, dann ist gut, ansonsten Kontra.

[gregorss]

Und du stellst Falschbehauptungen auf.

Wo?

Gruß

Gregor

[combie]

Wo?

hier z.B.

PS: In ISO-C++ gibt es new() und delete(). Wenn es die im Arduino-C++ gäbe....

Gegenbeweis:

Code: [Select]

void setup()
{
  Serial.begin(9600);
  Serial.println("Start");
  double* zeiger = new double(47.11);
  Serial.println(*zeiger);
  delete zeiger;
  zeiger = nullptr;
}

void loop()
{

}


Und:

Ja, wobei das Arduino-C++ und ISO-C++ unterschiedliche Dinge sind. Ich bin halt eher ISO-C++ gewohnt. In ISO-C++ ist

pixel pixel[5];

kein Problem.

Auch mit Arduino ist das kein Problem.
Man muss nur sorgfältig arbeiten.
Und das hast du nicht getan, darum die Meldung.
Jeder andere C++ Kompiler würde dir das auch um die Ohren hauen.



Und:

Arduino-C++ ist kein ISO-C++

Falsch.

[gregorss]

Gegenbeweis:

Code: [Select]

void setup()
{
  Serial.begin(9600);
  Serial.println("Start");
  double* zeiger = new double(47.11);
  Serial.println(*zeiger);
  delete zeiger;
  zeiger = nullptr;
}

void loop()
{

}

Das compiliert ohne Fehlermeldung. Interessant. New() und delete() sind jedoch nicht in der Referenz erwähnt und ein #include <vector> und #include <vector.h> erzeugen Fehlermeldungen. Die STL gibt es demnach wohl nicht.

Gruß

Gregor

[combie]

New() und delete() sind jedoch nicht in der Referenz erwähnt

In der Arduino Referenz sind nur ein paar Sprachmittel erwähnt.
Für den Rest wird man die ISO C++ Spezifikation zu Rate ziehen müssen.

Die Arduino Referenz ist kein C++ lern Tutorial.

und ein #include <vector> und #include <vector.h> erzeugen Fehlermeldungen. Die STL gibt es demnach wohl nicht.

Gibt es nicht.
Sie ist aber auch nicht Bestandteil der C++ Spezifikation an sich.


Aus anderen Quellen, kann man sich die STL auch auf den Arduino pumpen. Suche bei Github.
Dann tuts auch dein vector

Die Gründe, welche gegen die STL auf AVR sprechen sind vielfältig.
Aber, dass der AVR-GCC nicht standardkonform wäre, das gehört nicht dazu.

Der ESP, hat die STL dabei....

[gregorss]

Die Arduino Referenz ist kein C++ lern Tutorial.

Das habe ich ja auch nicht behauptet. Eine Referenz ist IMO grundsätzlich etwas Anderes als ein Tutorial.

Der ESP, hat die STL dabei....

Der benutzt vermutlich auch nicht die avr-libc.

Gruß

Gregor

[michael_x]

New() und delete() sind jedoch nicht in der Referenz erwähnt

Ja, und das ist gut so.

Erstmal ist new ein Operator. Eine Funktion new() gibt es in C++ und deren üblichen Runtime Libraries nicht.

Zweitens ist vieles in der Referenz der "Arduino-Sprache" nicht erwähnt, was der avr-gcc Compiler kann und was in den verwendeten Libraries definier tist, intern durchaus verwendet wird, und jedem zur Verfügung steht. (Nicht nur combies Lieblingsspielzeug yield() )

Schon wer sich generell für Zeiger und Referenzen interessiert (nicht nur im Zusammenhang mit new), muss weiter lesen, da gibt es absichtlich fast nichts in der Arduino Referenz.

Immerhin ist alles bei Arduino Open Source, da ist eine Referenz der reinste Luxus.

Zwar ist die "Reference" kein Tutorial, aber eine echte Referenz ist es auch nicht. Dafür ist zuviel "Grundsätzliches C++ für Arduino-Künstler" als vereinfachtes Lehrmaterial drin, und absichtlich zu wenig "Komplett-Referenz".

[gregorss]

Ja, und das ist gut so. [dass new() und delete() nicht in der Referenz erwähnt sind]

Das kann man unterschiedlich sehen. Ich finde, dass in einer Referenz alles erwähnt sein sollte, was in einer Sprache möglich ist.

Immerhin ist alles bei Arduino Open Source, da ist eine Referenz der reinste Luxus.

Nach dem Motto „einem geschenkten Gaul guckt man nicht ins Maul"?

Gruß

Gregor

[combie]

Das kann man unterschiedlich sehen. Ich finde, dass in einer Referenz alles erwähnt sein sollte, was in einer Sprache möglich ist.

Es sollten alle Funktionen und anderes Zeugs, was in dem Arduino Framework definiert wird Erwähnung finden.
Und das wird auch gemacht! (nur yield(), da hat sich noch keiner drum gekümmert)

Die Arduino Referenz, ist also eher als Frameworkreferenz zu verstehen und keine C++ Sprachreferenz.
OK, kannst du anders sehen, ist aber neben der Realität, und hilft dir auch nicht aufs Pferd.


Ein vollständiges Abdrucken der C++ Sprachreferenz ist unsinnig.
1. Sie müsste aktuell gehalten werden (wir hatten gerade eben den Hüpfer auf C++11)
2. Findet man das in jedem (guten) C++ Buch.
3. Redundante Information neigt dazu widersprüchlich zu werden. Und dann geht das Geschrei wieder los.


Nebenbei:
Die Referenz kann auch von dir geändert werden. Also lass dich nicht aufhalten. Erweitere sie.
Nicht schimpfen, sondern tu was.

[gregorss]

Nicht schimpfen, sondern tu was.

Wo bitte schimpfe ich?! Ich äußere eine Meinung. Das ist ein Unterschied.

Gruß

Gregor

[combie]

Ok, "schimpfen" ist vielleicht ein bisschen weit gegriffen.
Ersetze es bitte durch "kritisieren"

[postmaster-ino]

Hi

Die Lücken in der Arduino-Referenz sind nicht wegzudiskutieren, Da sind wir uns wohl einig.
Es fängt aber schon viel früher an - man bindet eine Bibliothek ein und muß sich erst Mal durch .h und .cpp Files durchbeißen, um einen ungefähren Überblick zu erhalten, was diese Lib eigentlich kann und wie Diese angeschwätzt werden will.
Klar helfen die Beispiele (sofern vorhanden) - aber eben nur für diesen speziellen Beispiel-Fall.

DAS habe ich im Bezug auf ASM irgendwie anders gelernt (also nicht, daß ich Assembler richtig gelernt hätte, reines Selbststudium) - aber eine Funktion/Unterprogramm zeigt oben drüber, wie man Diese aufruft, welche Register für was benutzt werden und was danach Alles futsch ist (geänderte Register o.Ä.) - wenn irgend welche Seiteneffekte vorhanden sind, kA, Timergeschichten oder so Zeug, sind Diese ebenfalls erwähnt - eben, daß z.B. das Timerregister oder die und die Timergeschwindigkeit benötigt werden.

So Etwas vermisse ich bei den Arduino-Libs - wobei Es, zugegeben, auch etwas Arbeit ist, den ganzen Kram in der eigenen Lib aufrecht zu halten.

Das Schlimme ist aber hier wirklich, daß man Selber daran was ändern könnte - man müsste nur den Arsch aus der Hose bekommen - alleine Übersetzungen ins Deutsche wären, so glaube ich, schon ein großer 'Maker'-Magnet.

... schreibt Einer, Der die Texte per Google-Translater in lesbare Form bringt ...

MfG

[michael_x]

DAS habe ich im Bezug auf ASM irgendwie anders gelernt

Das hat mit ASM nun gar nichts zu tun, außer dass es dort noch schlimmer wäre, wenn keine Doku vorhanden ist, weil viel mühsamer zu verstehen ist, was da gezaubert wird.

An den Anfang einer Funktion zu schreiben, was das ganze soll, welche Parameter mit welchen Wertebereichen erwartet werden, usw. , ist auch bei C++ nicht verboten. Und wird sogar von einer guten IDE unterstützt.

Müsstest halt ein bisschen mehr bezahlen und die Software erst abnehmen, wenn auch die Doku fertig ist.
Und jemand finden, der das freiwillig und ordentlich macht. 

[Serenifly]

Es gibt auch Bibliotheken in denen jede Methode vollständig dokumentiert ist. Das ist aber die Ausnahme.
SdFat und VirtualWire haben sogar Doxygen Dokus die aus den Kommentaren generiert wurden. UFT hat keine gute Doku im Code, aber eine sehr gute externe.
DallasTemperature oder die Time Library sind auch relativ gut dokumentiert

[postmaster-ino]

Hi

Daß Das nicht direkt mit Assembler zu tun hat, ist mir klar - nur fand ich Es äußerst hilfreich, wenn man irgendwo eine Funktion ausgegraben hat, daß man auch versteht, WAS darin passiert und WIE man den Kram anzuwenden hat.
Das kam mir halt so ziemlich bei den ersten Schritten mit Assembler entgegen und ich fand Das ausgesprochen hilfreich - auch beim Verstehen eigener Konstrukte, wenn Mal ein halbes Jahr ins Land gezogen ist.

Aber leider werde ich Da wohl nicht viel hilfreich zu beitragen (können) - wie gesagt, eine abgeschriebene Google-Übersetzung wird kaum mehr liefern, als die eigentliche Google-Übersetzung selber - meine Meinung (macht's auch einfacher, den Kram nicht anfangen zu müssen )

MfG