3. Typ aus namespace nicht deklariert trotz include

Typ aus namespace nicht deklariert trotz include

  • J

    Hm,

    ich verstehe gerade nicht warum der Compiler da nölt:

    Datei global.h mit namespace global

    namespace global {
     /**
     * Hilfsobjekt zur Entropie-Spaltenberechnung, Spalten starten bei 1
     */
    struct singleColumnEntropyItem {    
        int column;                  
        double entropy;
    };
...
}

    Datei

    #ifndef RESULTS_H
#define	RESULTS_H
#include "global.h"
class Results {
public:
    /** Liste aller Entropien, H(x) */
    std::vector<global::singleColumnEntropyItem> singleEntropiesList; 
...

    Der Compiler sagt:
    In file included from global.h:7,
    from main.cpp:151:
    results.h:16: error: ‘global’ was not declared in this scope
    results.h:16: error: template argument 1 is invalid
    results.h:16: error: template argument 2 is invalid

    Ich verstehe das nicht, denn durch das include müsste das struct doch sichtbar sein und den namespace spreche ich doch so an: meinnamespace::meintyp .

    Danke vorab.

    0
  • O

    schau mal deine include guards in global.h nach. Oder hast du gar keine?

    0
  • J

    Ah sehr gut, da ist was ... da ist results.h rot unterstrichen, die include-Guards sind da. Jetzt muss ich noch rausfinden, warum results.h da problematisch ist. Mal schauen ...

    #ifndef GLOBAL_H
#define	GLOBAL_H

#include "properties.h"
#include "results.h"
    0
  • J

    http://www.c-plusplus.net/forum/70581

    Okay, das scheint das gleiche Problem zu sein ...

    0
  • P

    aalso. Du bindest irgendwo global.h ein. Der Präprozessor liest die include-guards GLOBAL_H. Dann wird resolts.h eingelesen -> include-guard RESULTS_H (namespace global ist hier noch nicht bekannt). Dort wird global.h wieder eingebunden. GLOBAL_H ist schon definiert, also Header wieder verlassen. (namespace global ist immernoch nicht bekannt).
    vectorglobal::... (global ist IMMERNOCH nicht bekannt)

    Google mal nach circular includes udn forward-declaration.

    0
  • J

    Tricky das Thema, da darf man dann in der bekannt gemachten Klasse auch wieder nur Zeiger nutzen und muss also in dem Thema auch gut drin sein. Vielleicht gelingt es mir ja, den namespace global komplett überflüssig zu machen, das wäre wohl das geschickteste.

    0
  • P

    Jay1980 schrieb:

    Vielleicht gelingt es mir ja, den namespace global komplett überflüssig zu machen, das wäre wohl das geschickteste.

    Nein, das löst das Problem nicht, dann wäre das gleiche Problem mit singleColumnEntropyItem am Start. Wozu musst du in global.h überhaupt results.h einbinden? Ist aus deinem Code nicht erischtlich.

    0
  • J

    Naja, vorher arbeitete ich mit globalen Variablen, die lagen im Namespace global. Jetzt habe ich daraus ein results-Objekt herausgerissen. Es gibt aber noch Funktionen im globalen Namespace, die etwas berechnen und dann das mitgegebene Results-Objekt bestuecken. Vorher gabs kein Results-Objekt und keine Probleme.

    Ich dachte ich bringe nun die Hilfstrukturen in der Datei results.h mit unter. Am Ende muss dann global.h weiterhin results.h inkludieren aber results.h braucht kein global.h mehr. So mein erster Gedanke.

    0
  • Mod

    Ich wiederhole meinen Rat aus dem anderen Thread: Neu machen. Alle Bruchstücke die du hier hin und wieder zeigst deuten auf totales Murksdesign hin. Und jetzt steckst du noch mehr Gemurkse rein, damit es überhaupt compiliert. Meinst du, da kommt am Ende etwas anderes als Murks raus?

    Ich verlange ja gar nicht, dass du deinen kompletten Code wegwirfst. Die Teile davon, die tatsächlich etwas tun wirst du größtenteils wiederverwenden können, mit kleinen Änderungen. Eventuell sogar ohne Änderungen wenn sie gut allgemein geschrieben waren (wovon ich jetzt mal nicht ausgehe). Aber der Code der bei dir die Klassen, Funktionen und ihre Abhängigkeiten beschreibt solltest du neu machen. Also das allgemeine Design. Denk noch einmal da drüber nach, was in deinem Programm die Objekte sind, was sie für Attribute haben, welche Memberfunktionen sie haben und welche Funktionen global auf diesen Objekten arbeiten.
    Zum Beispiel ist "Hilfsobjekt zur Entropie-Spaltenberechnung" etwas was eigentlich so gar nicht nach einem Objekt klingt. Objektorientiert heißt nicht, dass alles einer Klasse angehört!

    0
Anmelden zum Antworten