es geht um etwa folgenden Code:

product.h

...
class Product
{
    ...
};

tree.cpp

#include "product.h"
...

Tree::Tree()
{
    Product p;
}

Hierbei erhalte ich beim Kompilieren den Fehler:
tree.cpp:xx: Fehler:'p' was not declared in this scope

Ein "Product* p;" geht genauso wenig.

Ich denke er hat irgendein Problem mit der Klasse Product. Ich probiere schon eine ganze Weile und komme einfach nicht dahinter. Bin ich blind und übersehe einen groben Fehler?

es geht um etwa folgenden Code:

Ist ja fein. Und um welchen Code geht es wirklich? Siehe dritter Link in meiner Signatur.

Erfahrung flüstert mir auch ohne passenden Code: Zyklische Abhängigkeit.

Erfahrung flüstert mir auch ohne passenden Code: Zyklische Abhängigkeit.

Jap, ich wette tree.h und product.h inkludieren sich direkt oder indirekt gegenseitig....

tree.h inkludiert nicht product.h. product.h inkludiert tree.h nicht.
Jedoch leitet die Klasse Product von Entity ab, und treeitem.h inkludiert entity.h, und tree.h inkludiert dann treeitem.h.
entity.h inkludiert product.h aber nicht!

Kann es auch ein Problem mit Basisklassen geben? Mich interessiert allgemein, wann ein solcher Fehler auftreten kann.

Es hat auch nicht geholfen, den Include von product.h in tree.cpp zu entfernen und stattdessen dort eine Klasse product.h zu definieren.

Gibt es mehr als zyklische Abhängigkeiten, die einen solchen Fehler produzieren können?
Doch mehr Code rein?

-> heißt inkludiert

product.h -> entity.h
entity.h -> nur Standardimports (QString, QSqlQuery)
treeitem.h -> entity.h (neben QList, QVariant, QVector)
tree.h -> nur Standardimports aus Qt sowie eine Vorwärtsdeklaration (class TreeItem;)
tree.cpp -> product.h, tree.h, treeitem.h

Ich werd nicht schlau drauß..

Hallo Forum,

es geht um etwa folgenden Code:

product.h

...
class Product
{
    ...
};

tree.cpp

#include "product.h"
...

Tree::Tree()
{
    Product p;
}

Hierbei erhalte ich beim Kompilieren den Fehler:
tree.cpp:xx: Fehler:'p' was not declared in this scope

Das ist schon mal gelogen (bzw. unvollständiger Code).
Der Compiler findet p nicht. Dass muss er hier aber auch gar nicht, schließlich zeigst du uns nur eine Deklaration von p.

zum Rätsel Raten dient dieses Forum allerdings nicht. Wenn du den Fehler nach intensiver Suche nicht findest, muss es uns umso schwerer fallen ohne den entsprechenden Code.

camper schrieb:

Das ist schon mal gelogen (bzw. unvollständiger Code).
Der Compiler findet p nicht. Dass muss er hier aber auch gar nicht, schließlich zeigst du uns nur eine Deklaration von p.

zum Rätsel Raten dient dieses Forum allerdings nicht. Wenn du den Fehler nach intensiver Suche nicht findest, muss es uns umso schwerer fallen ohne den entsprechenden Code.

Doch weiß man als Laie nicht immer was nun Rätselraten ist, oder was für einen Geübten einfach genannt werden kann.

Ich habe den Fehler gefunden, es lag an einem enum:

enum TreeItemType {
    Product,
    ...
};

Mir war nicht klar, dass ein solcher Enum-Wert für den Compiler in Konflikt gerät mit einem Klassennamen.

VG

Ich habe den Fehler gefunden, es lag an einem enum:

enum TreeItemType {
    Product,
    ...
};

Mir war nicht klar, dass ein solcher Enum-Wert für den Compiler in Konflikt gerät mit einem Klassennamen.

Weil in c++ ein enum AFAIK kein Typ darstellt. In C++0x/C++11 gibt es "enum class" dann hast du einen konkreten tyy.

Weil in c++ ein enum AFAIK kein Typ darstellt. In C++0x/C++11 gibt es "enum class" dann hast du einen konkreten tyy.

Wieso sollte ein enum keinen Typen definieren? Wenn es kein Typ wäre, könntest du doch auch kein Objekt davon erzeugen.

Doch weiß man als Laie nicht immer was nun Rätselraten ist, oder was für einen Geübten einfach genannt werden kann.

Und genau deshalb sollst du auch Code posten, der das beobachtete Verhalten auch zeigt. Ganz sicher ist es unmöglich, den Fehler zu finden, wenn der relevante Code unbekannt bleibt.

Zeeke schrieb:

Mir war nicht klar, dass ein solcher Enum-Wert für den Compiler in Konflikt gerät mit einem Klassennamen.

Ein Erbe aus C.
Eine Klasse- oder Aufzählungsname kann im gleichen Scope durch die Deklaration einer Funktion, eines Objekts oder einer Aufzählungskonstanten verdeckt werden.
Durch Verwendung des entsprechenden Schlüsselwortes kann in solchen Situationen trotzdem auf den Klassennamen zugegriffen werden.

class Product p;

Besser ist es allerdings, die Namenskollision von vornherein zu vermeiden.

firefly schrieb:

Weil in c++ ein enum AFAIK kein Typ darstellt. In C++0x/C++11 gibt es "enum class" dann hast du einen konkreten tyy.

Wieso sollte ein enum keinen Typen definieren? Wenn es kein Typ wäre, könntest du doch auch kein Objekt davon erzeugen.

Es geht nicht um den Enum an sich, sondern um einen Wert innerhalb des Enums! Das finde ich nicht so klar.

camper schrieb:

Zeeke schrieb:

Doch weiß man als Laie nicht immer was nun Rätselraten ist, oder was für einen Geübten einfach genannt werden kann.

Und genau deshalb sollst du auch Code posten, der das beobachtete Verhalten auch zeigt. Ganz sicher ist es unmöglich, den Fehler zu finden, wenn der relevante Code unbekannt bleibt.

Stimmt, hätte hier geholfen ;).

camper schrieb:

Zeeke schrieb:

Mir war nicht klar, dass ein solcher Enum-Wert für den Compiler in Konflikt gerät mit einem Klassennamen.

Ein Erbe aus C.
Eine Klasse- oder Aufzählungsname kann im gleichen Scope durch die Deklaration einer Funktion, eines Objekts oder einer Aufzählungskonstanten verdeckt werden.
Durch Verwendung des entsprechenden Schlüsselwortes kann in solchen Situationen trotzdem auf den Klassennamen zugegriffen werden.

class Product p;

Besser ist es allerdings, die Namenskollision von vornherein zu vermeiden.

Dankeschön für den Hinweis. Ich habe die Enum-Werte nun aber besser mit einem Präfix versehen.

Ich denke die Sache ist hiermit geklärt.

VG

Dankeschön für den Hinweis. Ich habe die Enum-Werte nun aber besser mit einem Präfix versehen.

Ich finde Namenspaces schöner

out schrieb:

firefly schrieb:

Weil in c++ ein enum AFAIK kein Typ darstellt. In C++0x/C++11 gibt es "enum class" dann hast du einen konkreten tyy.

Wieso sollte ein enum keinen Typen definieren? Wenn es kein Typ wäre, könntest du doch auch kein Objekt davon erzeugen.

Es geht nicht um den Enum an sich, sondern um einen Wert innerhalb des Enums! Das finde ich nicht so klar.

Der einzige Unterschied zwischen normalen Enumerationen und scoped enumerations ist, dass bei letzterem

• die Enumeratoren nicht implizit in einen integralen Skalar konvertieren werden können
• die Enumeratoren nicht einfach angesprochen werden dürfen, sondern wie bei Namensräumen durch den Namen der Enumeration.

Es sind aber beides Typen.