U.a. habe ich folgende abstrakte Klasse geschrieben. In ihr soll ein Zeiger "pParent" enthalten sein. Leider erkennt der Compiler (gcc) "EditorGUI*" nicht als Typ fuer diesen an (in dieser Klasse), egal wie ich es deklariere.

Der gcc meint immer nur:
ISO C++ forbids declaration of 'EditorGUI' with no type... - Aber EditorGUI ist doch der "Type", Mensch!!! Ich drehe langsam wirklich am Rad, die Information ist so nichtssagend..

Meine erste Vermutung, war eine vergessene Klammer/Semicolon in den EditorGUI Dateien (.cpp/.hpp), hab aber bisher nix gefunden. Vllt hat irgendwer noch irgendwelche Tipps, wo und v.a. nach was ich da eigentlich noch suchen kann?

#ifndef PNOPTION
#define PNOPTION

#include <QtGui>

#include <iostream>

#include "Element.hpp"
#include "EditorGUI.hpp"

class PnOption : public QTabWidget
{
private:
    EditorGUI* pParent; // wird nicht erkannt!!!

public:
    PnOption(){};
    virtual ~PnOption(){};
    virtual void acceptModification()=0;
    virtual void updateContent()=0;

protected:
    void setParent(EditorGUI* p){ pParent = p; };
    QLabel* lbTranslated;
    QLabel* lbUntranslated;
    Element* getElementCopy(){ return pParent->getElementCopy(); };
    void actualizeElement(){ pParent->actualizeElement(); };
    virtual void initGUI()=0;
};
#endif

rm -f moc_EditorGUI.cpp moc_MainGUI.cpp moc_PnCenterResult.cpp moc_PnCenterStart.cpp moc_PnCenterTest.cpp moc_PnOptionVerb.cpp
rm -f qmake_image_collection.cpp
rm -f DataIO.o EditorGUI.o Main.o PnCenterResult.o PnCenterStart.o PnCenterTest.o PnOptionAdjective.o PnOptionCommon.o PnOptionNoun.o PnOptionVerb.o moc_EditorGUI.o moc_MainGUI.o moc_PnCenterResult.o moc_PnCenterStart.o moc_PnCenterTest.o moc_PnOptionVerb.o
rm -f *~ core *.core
g++ -c -pipe -O2 -Wall -W -D_REENTRANT  -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o DataIO.o DataIO.cpp
g++ -c -pipe -O2 -Wall -W -D_REENTRANT  -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o EditorGUI.o EditorGUI.cpp
PnOption.hpp:24: error: ISO C++ forbids declaration of 'EditorGUI' with no type
PnOption.hpp:24: error: expected ';' before '*' token
PnOption.hpp:76: error: 'EditorGUI' has not been declared
PnOption.hpp: In member function 'void PnOption::setParent(int*)':
PnOption.hpp:76: error: 'pParent' was not declared in this scope
PnOption.hpp: In member function 'Element* PnOption::getElementCopy()':
PnOption.hpp:80: error: 'pParent' was not declared in this scope
PnOption.hpp: In member function 'void PnOption::actualizeElement()':
PnOption.hpp:81: error: 'pParent' was not declared in this scope
(...)

wie ist denn EditorGUI deklariert und wohin zeigt der pParent ?

von Ney

Das ist die Implementierungsdatei (ich habe mir schon gedacht, vllt liegt es an der Quervernkuepfung mit den includes, aber es aendert sich kaum was bei weglassen, hinzufuegen oder sonstigen Aenderungen.

#ifndef EDITORGUI
#define EDITORGUI

#include "MainGUI.hpp"
#include "PnOption.hpp"
#include "PnOptionCommon.hpp"
#include "PnOptionNoun.hpp"
#include "PnOptionVerb.hpp"
#include "PnOptionAdjective.hpp"
#include "Element.hpp"
#include <iostream> // TODO rm

class QDialog;
class QVector<class T>;
class QLabel;
class QLineEdit;
class QPushButton;
class QRadioButton;
class QStackedLayout;

class EditorGUI : public QDialog
{
    Q_OBJECT

public:
    EditorGUI( MainGUI*, QVector<Element>* list=new QVector<Element>());
    ~EditorGUI();
    QVector<Element>* editableSelection(){ return pEditableSelection; };
    Element* getElementCopy(){ return pElemCpy; };
    void actualizeElement();

private slots:
    // buttons
    void slotNewWord();
    void slotReset();
    void slotAccept();
    void slotEditWord();
    void slotDeleteItem();
    void slotCancel(){ reject(); };

    // listWidget
    void slotSelect(){ init(listWidget->currentRow()); };

    // radiobuttons
    void slotChangeToCommon();
    void slotChangeToNoun();
    void slotChangeToVerb();
    void slotChangeToAdjective();

private:
    const quint16 NUMBER_OF_TYPES;
    MainGUI* pnParent;
    QVector<Element>* pEditableSelection;
    QListWidget* listWidget;
    Element* pElemCpy;
    QStackedLayout* staOptions;
    PnOption* pnCurrentOption;
    PnOptionCommon* pnOptionCommon;
    PnOptionNoun* pnOptionNoun;
    PnOptionVerb* pnOptionVerb;
    PnOptionAdjective* pnOptionAdjective;
    QLabel* lbTranslation;
    QLineEdit* leTranslation;
    QLabel* lbTranslationContext;
    QLineEdit* leTranslationContext;
    QLabel* lbWord;
    QLineEdit* leWord;
    QLabel* lbWordContext;
    QLineEdit* leWordContext;
    QPushButton *btNew;
    QPushButton *btReset;
    QPushButton *btCancel;
    QPushButton *btOk;
    QPushButton *btEdit;
    QPushButton *btDelete;
    QRadioButton* rb;

    void initGUI();
    void init(qint16);
    void populateListWidget();
    void readElem(const Element& element);
    void writeElem(Element* element);
};

#endif

Die Implementierung enthaelt folgende Includierungen:

#include <QtGui>
#include "EditorGUI.hpp"
#include <iostream> // TODO rm
(...)

Ich bin fuer jeden Tipp, was ich machen koennte oder Vermutung dankbar!!!

PS:
EditorGUI erzeugt eine Instanz einer abgeleiteten Klasse von PnOption. Das Parent dieser PnOption Ableitungen soll die Instanz von EditorGUI sein - auf diese soll auch jeweils der Zeiger (=pParent) dann zeigen (aber soweit kommt das Ding ja noch lange nich).

Fabeltier schrieb:

Hallo,
EditorGUI* pParent; // wird nicht erkannt!!!
[/code]

Diese Deklaration sagt nur, dass pParent auf etwas zeigen soll, was ein EditorGUI ist. Insbesondere wird der Konstruktor der Klasse nicht aufgerufen. (Aber das weist du bestimmt.)

Erst wenn du so etwas hast wie

EditorGUI  etc;
   pParent =  &etc;

funktionierts. Vielleicht erklärt das, warum EditorGUI* pParent nicht erkannt wird.

Muss dann in void setParent(EditorGUI* p){ pParent = p; }; nicht auch & anstelle * stehen? Aufruf: setParent(*p).

vg tesu

class Foo;

class Blaa
{
    Foo* foo;
}

Das muss doch funktionieren.

Was macht den dieses Q_OBJECT Macro? Macros sind böse, böse, böööse

btw, verwendet doch die cpp-Tags.

PnOption.hpp:76: error: 'EditorGUI' has not been declared

Das lässt vermuten das der Compiler den EditorGUI-Typ nicht kennt.

Ausserdem hast du eine zyklische Referenz, in PnOption.hpp includest du EditorGUI.hpp und in EditorGUI.hpp includest du PnOption.hpp:

#include "Element.hpp" 
#include "EditorGUI.hpp" // hier

#include "MainGUI.hpp" 
#include "PnOption.hpp"  // hier
#include "PnOptionCommon.hpp" 
#include "PnOptionNoun.hpp" 
#include "PnOptionVerb.hpp" 
#include "PnOptionAdjective.hpp" 
#include "Element.hpp" 
#include <iostream> // TODO rm

Ich weis nicht ob das Probleme bereitet, hab schon lang kein C++ Projekt geschrieben.

In diesem Fall scheints aber so zu sein, dass der erste Punkt zutrifft:

wenn der Compiler versucht, einen header zu lesen, der editorgui.h includiert, steht für ihn da in etwa folgendes:

...
#include editorgui.h
// hier packt der compiler den text von editorgui.h:
 #ifndef editorgui
 #define editorgui // editorgui ist damit DEFINIERT!
 #include pnoption.h
 // hier dann der text von pnoption.h
  #ifndef pnoption
  #define pnoption
  #include editorgui
  // ah, hier nochmal editorgui
   #ifndef editorgui // hier tut der includeguard was er soll, editorgui ist definiert
                     //wird also übersprungen und NICHT gelesen!
   #endif //ende von editorgui
  ...
  Editorgui* pParent;   //!!!! EDITORGUI ist hier UNBEKANNT!
  #endif  //ende von pnoption
 class Editorgui {...}; //hier wird die Klasse erst bekannt...
 #endif //ende von editorgui

um sowas zu verhindern, gibts zwei wege:

1. wenn du nur Zeiger auf eine Klasse hast und keine ihrer Methoden oder Membervariablen verwendest, ist es nicht nötig, dass der Compiler zu dem Zeitpunkt die ganze definition kennt. eine Deklaration

class EditorGUI;

reint. die eigentliche Definition kann irgendwann anders kommen.
2) Damit bei den Kreisincludes soclhe fehler nicht passieren, kann man am Anfang jeden headers einfach dei KLasse kurz deklarieren, dann die Includes, dann die eigentliche KLassendefinition.

Allerdings halte ich es für nicht besonders schönen Stil, header nur zur Klassendeklaration zu includieren, da dem Compiler dann mehr Quelltext zugemutet wird als nötig.

@tesuji
Ja mir ist schon klar wie man Zeiger initialisiert, darum ging es aber in der Tat nicht. Man denkt vllt zuerst bei der Fehlermeldung an andere Dinge - ich dachte eben an einen vergessenen ; oder ) in einem includeten File, da ich sowas schon hatte - schliesslich wird man langsam wahnsinnig, weil man nichts findet und kontrolliert alles (auch die Initialisierungen) nochmal. Danke trotzdem

@DEvent:
Q_OBJECT Macro - Ich selber arbeite aesserst ungerne mit Macros, auch nicht um Code (etwa template Deklarationen) zu "verkuerzen". Das Macro ist notwendig fuer den Signal/Slot-Mechanismus bei Qt, einer Qt-eigenen Signalsteuerung fuer v.a. die GUI's.
Die "zyklische Referenz" bei den Includes ging voll in die richtige Richtung. Auch hier hatte ich schon einiges ausprobiert mit meinem Halbwissen, allerdings erfolglos.

@pumuckl:
Die Erlaeuterung hat das Problem schliesslich geloest. Mir war gaenzlich unklar was eig der Unterschied zwischen einer #include Anweisung und einer (seichten) Forward Declaration eig ist. In diese Falle bin ich hineingetappt. Nun hab ich die EditorGUI.hpp, EditorGUI.cpp und PnOption.hpp noch einmal gruendlich angepasst, je nachdem, was im .hpp nicht benoetigt wurde (ausser als Pointer) laeuft und per Forward Declaration. Damit kompilierte es dann auch durch - WOW!

Es stellt sich allerdings doch etwas die Frage, bei mir, ob man sowas nicht eig auch mit Praeprozessoranweisungen loesen koennte (auch wenn das vllt etwas exotisch klingt, aber dafuer sind die doch eig auch da, oder?)?

Macht die Headerfiles u.U. einiges kürzer und übersichtlicher.

Ich mache es immer so dass jede Library ein "common.hpp" bekommt, und "common.hpp" inkludiert irgendwo "fwd.hpp" oder enthält selbst die ganzen forward declarations.
Jedes andere Headerfile der Library inkludiert dann als erstes "common.h".

Dadurch ist das Problem mit forward declarations darauf reduziert dass man bei neuen Klassen daran denken muss diese in "fwd.hpp" einzutragen.

Bei grösseren Libraries gibt es u.U. mehrere common.hpp und/oder fwd.hpp, z.B. eines pro grösserem Namespace.

Das kann man aber nur in kleinen Projekten machen. Wenn ich zum kompilieren 2 Stunden brauche nur weil ich eine forward decl. dazugefügt habe werde ich die Deklaration doch in mein eigenes headerfile schreiben

Forward-Deklarationen verlängern doch die Compilezeit nicht.

Doch, so wie templäd es beschrieben hat, und darauf bezieht sich ja hustbaer, d.h. wenn man in die common.h bzw. fwd.h eine neue Klasse (egal ob als Forward Deklaration oder nicht) einträgt, dann wird das ganze Projekt neucompiliert (wäre wie beim MSVC Einträge in der stdafx.h zu ändern)...