Fehlersuche

Tommy56: ... wieder nur Fragmente, keinen Link zur Lib, ... .

Ein Link zu Arduino.h?!

Gruß

Gregor

Nö, ich vermutete, dass pixel.h größer ist.

Gruß Tommy

Tommy56:
Willst Du uns jetzt verarschen oder kannst Du Dein eigenes Geschreibsel nicht mehr lesen?

#include "pixel.h"

Nein, wenn ich hier jemanden verarschen möchte, dann nur Dich :slight_smile:

Ich teile den aktuellen Sketch in Tabs ein, in dem es .h und .cpp Tabs gibt. pixel.h steht wie pixel.cpp in #5

Gruß

Gregor

PS: Alle Dateien des Sketches im Anhang

_180708_wunderlampe_II_0_1.ino (891 Bytes)

display.cpp (1.3 KB)

display.h (868 Bytes)

pixel.cpp (246 Bytes)

pixel.h (252 Bytes)

class pixel

Das ist der Anfang des Problems: pixel ist eine Klasse, du verwendest es aber als Variable.

Üblicherweise bekommen Klassen einen Namen, der mit einem Großbuchstaben anfängt, und Variablennamen fangen mit einem Kleinbuchstaben an. Also

class Pixel {};

Pixel pixel[8][8]; //  pixel sind 64 Elemente der Klasse Pixel

Das mit der Groß/Kleinschreibung ist natürlich nur ein Vorschlag, aber den Unterschied zwischen Klasse und Variable musst du schon (irgendwie) machen

michael_x:
Das ist der Anfang des Problems: pixel ist eine Klasse, du verwendest es aber als Variable.

Üblicherweise bekommen Klassen einen Namen, der mit einem Großbuchstaben anfängt, und Variablennamen fangen mit einem Kleinbuchstaben an.

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?

Gruß

Gregor

Bezeichnungen müssen eindeutig sein, egal was sie bedeuten.

Gruß Tommy

Edit: Auch wenn das technisch evtl. gehen sollte, ist es nicht gut für die Übersicht.

Seit wann kann ich eine Variable nicht benennen wie eine Klasse?

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?

combies Schelte steht noch !

michael_x:
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.

michael_x:
combies Schelte steht noch !

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

Gruß

Gregor

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.

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

michael_x: 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

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.

michael_x: 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

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

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.

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.

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

Dein Fehler in display.cpp: Du geschrieben

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

Du meinst aber:

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

michael_x: ... 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

Vielleicht compiliert er dann aber.

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

combie: 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

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.

combie: 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