Fehlersuche

[gregorss]

Da hast du tatsächlich recht, auch wenn ich das für großen Mist halte.


Aber, hast du eine Variable so benannt wie deine Klasse?

Ja, dieser Fehler taucht vermutlich irgendwo weiter unten in der Liste auf. Ich arbeite Fehlermeldungen immer von oben ab.

combies Schelte steht noch !

Die mit dem testbaren Code? Ich habe alle Dateien des Sketches als PS an #10 angeklebt.

Gruß

Gregor

[michael_x]

Die mit dem testbaren Code? Ich habe alle Dateien des Sketches als PS an #10 angeklebt.

habe eine Fehlermeldung bekommen, die ich nicht beseitigen kann

Dann schmeiss doch einfach mal drei Viertel des Sketches weg.

Wenn du z.B. display.h rausschmeisst und deinen Sketch entsprechend verkleinerst, und der Fehler sollte weg sein, hättest du viel gewonnen. Dann könntest du woanders suchen. Wenn der Fehler noch da ist, würde sich die Chance, dass jemand das Zeug anschaut, erhöhen.

Beim reduzieren auf ein testbares Beispiel würde (einem erfahrenem Programmierer) der Fehler selber auffallen.

[gregorss]

Wenn du z.B. display.h rausschmeisst und deinen Sketch entsprechend verkleinerst, und der Fehler sollte weg sein, hättest du viel gewonnen. Dann könntest du woanders suchen. Wenn der Fehler noch da ist, würde sich die Chance, dass jemand das Zeug anschaut, erhöhen.

Ich weiß nicht, wie groß die Klasse display noch wird, ich schreibe gerade einen Sketch neu. Ich wollte es zunächst „einfach schön aufgeräumt" haben. Auch deshalb alles in einzelnen Dateien.

Naja, und das mit dem Lesen ... ich drucke meine Sachen gerne mal aus und lese bei einer Zigarette auf dem Balkon. Da sind kurze Dateien manchmal handlicher. Geschmacksfrage.

Gruß

Gregor

[michael_x]

Ich meinte nicht, dass du das komplette display.h statt in eine eigene Datei in die .ino packen sollst.
Kleine Dateien sind besser, richtig.

Ich meinte ganz rausschmeissen.
Alles weg bis auf die Zeile mit dem "unerklärlichen" Fehler, und nur das notwendigste drin, dass kein anderer Fehler auftritt.

Es geht ja nicht drum zu bewundern wie deine Matrix blinkt, solange der Code nicht mal compiliert.

[gregorss]

Es geht ja nicht drum zu bewundern wie deine Matrix blinkt, solange der Code nicht mal compiliert.

Wie gesagt, ich schreibe einen Sketch (der funktioniert) neu. Das Geblinke habe ich ständig vor Augen. Wobei Geblinke eh ein falscher Begriff ist, ich meine Bildwiederholrate. Der neue Code compiliert noch nicht, was halt gerade nervt. Wo hattest Du eigentlich einen Fehler gesehen? Ich weiß gar nicht mehr, welche Korrektur in meinem Code auf wessen Hilfe zurückgeht.

Gruß

Gregor

[michael_x]

Sorry, ich dachte in diesem Thread geht es immer noch um 

error: expected primary-expression before '[' token

... den du wohl wegbekommen würdest, wenn du eine Variable
Pixel pixel[8][8];

oder meinetwegen evtl. sogar 

Code: [Select]

pixel pixel[8][8]; // Klasse und Variable haben denselben Namen, damit es nicht so einfach ist

richtig definieren würdest.
Solche grundlegenden Fragen kläre ich lieber in einem Minimal-Beispiel.

[combie]

Seit wann kann ich eine Variable nicht benennen wie eine Klasse? Ist das eine der Spezialitäten von Arduino (Java?)? Der Compiler sollte doch merken, wann eine Variable und wann ein Typ gemeint ist, oder nicht?

Ja, neee.  du irrst nicht und du irrst....

Die Variable ist nicht in dem Namensraum sichtbar, in dem sie verwendet werden soll.
Dort wird nur der Type gesehen.
Darum der Fehler.

Es gelten weder Java, noch Arduino Regeln.
Sondern die C++ Spezifikation.

Und natürlich auch die "weichen" Regeln.
Die StyleGuidelines

Entweder gewöhnst du dich daran, und betrachtest das als Feature, oder du verzweifelst und fluchst.

Suchs dir aus:
Glück, oder Leid.
Es ist deine Wahl!

Übrigens:
Wenn du dich daran gehalten hättest, dann würde es DIESES Problem hier nicht geben.
Zumindest eine andere Meldung.

[combie]

Nachtrag:
(weil der vorherige Beitrag evtl. nicht ausführlich genug war)


Dein Fehler in display.cpp:
Du geschrieben

Code: [Select]

void show()
{
// .........

Du meinst aber:

Code: [Select]

void display::show()
{
// .........

[gregorss]

...
Solche grundlegenden Fragen kläre ich lieber in einem Minimal-Beispiel.
...

Da haben wir's wieder. Die Klasse Display in den Hauptsketch zu übernehmen, würde ihn länger machen. Vielleicht compiliert er dann aber.

Dann wird bemängelt, dass der Sketch lang und unübersichtlich ist.

Irgendwas ist doch immer :-)

Gruß

Gregor

[michael_x]

Vielleicht compiliert er dann aber.

Oder stattdessen eine Klasse TestPixel, mit der du deinem Problem auf die Spur kommen kannst...

[gregorss]

Es gelten weder Java, noch Arduino Regeln.
Sondern die C++ Spezifikation.

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. Aber danke für den Hinweis auf display::show(). Es ist immer wieder interessant (oder nervig, je nachdem), wie das Hirn, das sich etwas ausgedacht hat, Fehler wegbügelt.

Gruß

Gregor

[combie]

Ja, wobei das Arduino-C++ und ISO-C++ unterschiedliche Dinge sind.

Wieso das denn?
Wer hat dir den Mist denn erzählt?
Oder hast du dir das nur ausgedacht?

Der gcc ist ISO C++ plus ein paar Erweiterungen

pixel pixel[5];

kein Problem.

In der Arduino Welt auch nicht!
(wenn man auf die korrekten Sichtbarkeiten/Gültigkeitsbereiche achtet)

Es ist nur eine schlampige Arbeit des Programmierers.
Und diese Schlampigkeit verdeckt die richtige, die aussagekräftige, Meldung.

Das Ei mit den Sichtbarkeiten hast du dir selbst gelegt,
> display::show().
Dazu noch die Schlampigkeit mit dem Klassenbezeichner, und die Meldung führt in die Irre. Und zu Fehlschlüssen in deinem Hirn.



Grundsätzlich:
Wer die Style Guidelines missachtet, nagelt sich selber eine Frikadelle ans Knie.
Es gibt ja Gründe für diese Guidelines, und einen davon hast du jetzt gefunden.

Also nochmal: (im klartext)
Dein Programm, so wie du es gepostet hast, kompiliert perfekt, wenn man an der einen Stelle das display:: hinzufügt.
Dass pixel pixel[5]; nicht funktioniert ist eine Falschaussage von dir.

Besser wäre natürlich wenn die Klasse nicht pixel, sondern Pixel heißt.
Dann wäre die Meldung aussagekräftiger und du hättest den Fehler sicherlich selber gefunden.

[gregorss]

Wieso das denn? [Arduino-C++ != ISO-C++]
Wer hat dir den Mist denn erzählt?
Oder hast du dir das nur ausgedacht?

Der gcc ist ISO C++ plus ein paar Erweiterungen

Arduino-C++ ist kein ISO-C++ (schreibst Du ja selber, „...plus ein paar Erweiterungen"). In ISO-C++ wirst Du z. B. keinen Datentyp finden, der „byte" heißt. Ich brauche niemanden, der mir das erzählt und ausgedacht habe ich mir das auch nicht.

Gruß

Gregor

[combie]

In ISO-C++ wirst Du z. B. keinen Datentyp finden, der „byte" heißt.

Der Gcc kennt den Datentype byte auch nicht.
byte ist keine Spracherweiterung.

Er wird in Arduino.h definiert. Zeile 126
> typedef uint8_t byte;

Dein Argument ist damit widerlegt.
Und es ist damit belegt, dass du dir das nur ausgedacht hast.



Aber ok, offensichtlich bist du schon etwas angepisst...
Also, wenn du dabei bleiben möchtest, werde ich dich ab jetzt mit deinen falschen Annahmen alleine lassen.

Grundsätzlich habe ich nichts dagegen, wenn du auf mich sauer bist.
Auch nicht, wenn du lieber im Irrtum verharren möchtest.

Aber wenn du hier im Forum den Mist dann ausbreitest, dann gibts Kontra.
Denn weiter verbreiten, wollen wir diese Irrtümer dann doch nicht, oder?

[gregorss]

byte ist keine Spracherweiterung.

Du willst Haare spalten. Darauf habe ich keinen Bock.

Gruß

Gregor

PS: In ISO-C++ gibt es new() und delete(). Wenn es die im Arduino-C++ gäbe, gäbe es auch die STL. Die gibt es aber nicht. Wieso denn bitte?!