3. Problem bei Dekleration eines Objektes (error C4430)

Problem bei Dekleration eines Objektes (error C4430)

  • G

    Ich bin gerade auf ein seltsames problem gestoßen, bei dem ich einfach nicht weiter komme.
    Ich wette die Lösung ist lächrlich einfach - aber irgendwie bin ich zu dumm sie zu sehen^^

    Hier meine Frameworkklasse (Singleton):

    #ifndef FRAMEWORK_HPP
#define FRAMEWORK_HPP

#include <iostream>
#include <sstream>
#include <string> 
#include "Text.hpp"
#include "Singleton.hpp"
#include "SFML/Graphics.hpp"
#include "Timer.hpp"

#define g_pFramework CFramework::Get()

class CFramework : public TSingleton<CFramework>
{
  public:

	[...]
  private:
	[..]

	void				DisplayFrames();
	bool				showFrames;
	CText				frametext;
	float				frametime;
	int					nrframes;

};

#endif

    Ich bekomme den Fehler

    c:\projekte_c++\sfml-test\sfml-test\Framework.hpp(39) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'frametext'

c:\projekte_c++\sfml-test\sfml-test\Framework.hpp(39) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.

c:\projekte_c++\sfml-test\sfml-test\Framework.hpp(39) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.

    Hier wär noch meine Text.hpp
    Wenn ihr noch was braucht sagt bescheid 😃
    Danke schon mal für eure Hilfe!

    #ifndef TEXT_HPP
#define TEXT_HPP

#include <iostream>
#include "SFML/Graphics.hpp"
#include "Framework.hpp"

class CText
{
public:

	void		Init	();
	void		Init	(std::string stext, std::string sourcef, sf::Color c, int isize, float x, float y);
	void		setText	(std::string stext);
	void		setFond	(std::string sourcef);
	void		setColor(sf::Color c);
	void		setSize (int s);
	void		setPos	(float x, float y);
	void		Draw	();
	std::string	getText	();

private:

	std::string	text;
	sf::Font	font;
	sf::Color	color;
	int			size;
	float		XPos;
	float		YPos;
	sf::String  sftext;

};

#endif
    0
  • S

    Du inkludierst im Kreis herum.
    Framework.hpp wird in Text.hpp inkludiert, welches wiederrum in Framework.hpp inkludiert wird, welches wiederum...

    0
  • ?

    Naja, eigentlich bricht der Kreis aufgrund der Include-Guards ziemlich schnell in sich zusammen. In diesem Fall wird es wohl so sein, dass Text.hpp eingebunden wird, welcher Framework.hpp einbindet, welcher Text.hpp einbindet, aber vom Präprozessor nichts zurückkriegt, weil Text.hpp TEXT_HPP schon definiert hat.

    0
  • L

    Sind das tatsächlich gegenseitige includes? Ja!
    Der include von "Framework.hpp" in CText ist unnötig. Wenn du das später brauchst, bitte erst dort (CText.cpp) includen.

    Und bitte lass diese "Init()"-Methoden weg - In einer Klasse verwendest du bitte Konstruktoren (außer du hast einen guten Grund für ein separates Init - hier aber nicht).
    Ein Klassenname "Framework" ist auch - hmm - sehr vielsagend...

    #define g_pFramework CFramework::Get()

    macht gar keinen Vorteil, im Gegenteil...

    0
  • Mod

    seldon schrieb:

    Naja, eigentlich bricht der Kreis aufgrund der Include-Guards ziemlich schnell in sich zusammen. In diesem Fall wird es wohl so sein, dass Text.hpp eingebunden wird, welcher Framework.hpp einbindet, welcher Text.hpp einbindet, aber vom Präprozessor nichts zurückkriegt, weil Text.hpp TEXT_HPP schon definiert hat.

    Und Framework.hpp braucht dann aber die Deklaration von CText aus Text.hpp, welche er aber nicht bekommt. Daher der Fehler.

    0
  • G

    Danke erstmal für die vielen Antworten 😃
    Ich kann leider nicht sagen ob's geklappt hat, da ich heute nach Kino keine Lust mehr habe zu programmieren 😉
    Zu den restlichen Posts/Kritiken:
    Ich habe mich in letzter Zeit einduetig zu viel mit Java beschäftigt 😃
    Wo genau würde denn der Konstruktor aufgerufen werden?
    Wo müsste ich den die Parameter übergeben? (Da ich z.B. frametext in der Header deklariere und CFramework nie.
    Das mit dem Init habe ich mir aus diesem C++ für Spieleprogrammierer Buch abgeschaut und bin damit eigentlich ganz gut zurecht gekommen.
    Was spricht denn dagegen außer, dass es objektorientiertgesehen etwas schöner mit Konstruktor ist und dass es mit Init etwas doppeltgemoppelt ist?
    Dann zum Namen Framework - ebenfalls abgeschaut - find ich jetzt persönlich aber passend (auch wenn der Begriff für mich mitlerweile eine andere Bedeutung hat als die Übersetztung)
    Zum #define g_pFramework ... -> Habe ich ebenfalls aus dem Buch - es hilft (mir) der Übersichtshalber - störts denn irgendwo?

    Aber danke für eure Tipps - würde mich auf weiter Antworten freuen 😃
    Niko (alias greece57)

    ----------------------------------------------------
    EDIT
    aja was mir noch eingefallen ist was Ich fragen wollte:
    Kann ich (wenn ja warum kann ich) #include "Framework.hpp" einfach weglassen, wenn ich g_pFramework noch in Ctext verwende (g_pFramework->Render(xy);)?
    Bzw wie soll dann CText auf das Framework zugreifen?

    0
  • L

    greece57 schrieb:

    Wo genau würde denn der Konstruktor aufgerufen werden?

    class Text {
    std::string text;
public:
    void Init(std::string newText) {
        text=newText;
    }
};

    wird zu

    class Text {
    std::string text;
public:
    explicit Text(std::string t)
     : text(t)
    {}
};

// Verwendung:
Text t("Hallo");
// statt
Text t;
t.Init("Hallo");

    Vorteil? Weniger Schreibarbeit, gleichzeitig sichere Verwendung (so ein zwingend notwendiges Init() kann man schonmal schnell vergessen...), und der Code wird auch schneller, da "text" gleich beim Konstruieren mit dem richtigen Wert initialisiert wird, und damit eine unnötige Default-Konstruktion wegfällt.

    Dann zum Namen Framework - ebenfalls abgeschaut - find ich jetzt persönlich aber passend (auch wenn der Begriff für mich mitlerweile eine andere Bedeutung hat als die Übersetztung)

    Der Name sagt einfach nix aus! Framework ist ein allgemeiner Begriff, der mehrere zusammengehörige Klassen und Funktionen bezeichnet, die - wie ein Netz - ineinander greifen, die also zusammengehören und zusammen bestimmte Funktionen bewältigen. Allein haben die meist wenig Sinn. Eine einzelne Klasse namens Framework macht deshalb gleich umso weniger Sinn 😉

    Zum #define g_pFramework ... -> Habe ich ebenfalls aus dem Buch - es hilft (mir) der Übersichtshalber - störts denn irgendwo?

    Ein Macro ist eine Stupide Textersetzung. Das kann zu ziemlichen Problemen führen. Und schneller ist es auch nicht wirklich, vor allem in diesem Fall.
    Vergleiche:

    g_pFramework->render();
CFramework::Get()->render();

    Und jetzt lass das unnötige ungarische "C" am Anfang noch weg, dann sparst du dir wieder einen Buchstaben 😛
    Dank Code-Completion wirst du sowieso mit <5 Tastenanschlägen das Framework::Get() geschrieben haben.

    Was für ein Buch ist das denn? Ich würde dem nicht mehr so viel abschauen 😕

    Kann ich (wenn ja warum kann ich) #include "Framework.hpp" einfach weglassen, wenn ich g_pFramework noch in Ctext verwende (g_pFramework->Render(xy);)?
    Bzw wie soll dann CText auf das Framework zugreifen?

    Wenn du die Klasse verwenden willst, musst du den Header auch einbinden. Da du im Header von CText aber nicht auf das Framework zugreifst, sondern erst in CText.cpp, kannst (und sollst) du erst da den entsprechenden Header einbinden. Das ist eine prinzipielle Regel die du beachten solltest: Nie mehr einbinden als notwendig, arbeite soweit als möglich mit forward-declarations. Das reduziert Abhängigkeiten und beschleunigt den Kompiliervorgang.

    0
  • G

    Danke für die Antwort!!!
    verändern werd ich im Nachhinein zwar nichts mehr ( 😃 ) aber ich merks mir für kommende Projekte!

    0
Anmelden zum Antworten