TListView in bcb4 und bcb6 unterschiedlich ??

akari

Hallo

Die Ursache dürfe sein das irgendwo in einem der Header die du (indirekt) includest ein using namespace Comctrls steht. Dadurch wird aber unter Umständen der Compiler bei der Verwendung des Symbols stNone verwirrt, da er nun ::stNone und Comctrls::stNone kennt. Erst durch die explizite Verwendung eines der beiden Varianten (d.h. die einfachen :: hätten auch helfen müßen) wird dem Compiler klar gemacht welches Symbol er benutzen soll.

Ein gutes Beispiel warum man in Headern kein using namespace verwenden sollte.

bis bald
akari

Mecki

Danke akari,

Deine Erklärung stimmt fast.
Es funktionieren die Versionen

ListView1->SortType = Listactns::stNone;

und

ListView1->SortType = Comctrls::stNone;

Müsste ich nicht irgendwo ( und sei es in der bcb-Hilfe) herausfinden können,
wo der Unterschied zwischen beiden Anweisungen liegt oder
ob es überhaupt einen gibt

akari

Hallo

In diesem Fall ist die Ursache doch etwas anders : im Namespace Listactns wurde ein typedef auf das Symbol stNone angelegt, was dazu führt das der Compiler zwei verschiedene Symbole sieht die aber genau diegleiche Wirkung haben. Deshalb kannst du beide an SortType zuweisen, aber must explizit eines von beiden angeben.

Das using namespace ist dann dafür verantwortlich das beide Symbole im globalen Namespace verfügbar sind. Ohne das using... und explizite Namespace-Angabe würde der Compiler nur sagen das er stNone gar nicht kennt. Dann müßtest du automatisch einen der beiden Namespaces angeben.

bis bald
akari

Mecki

Thnx-- Dann hoffen wir, dass in der nächsten Version alles besser wird.

Braunstein

akari schrieb:

... was dazu führt das der Compiler zwei verschiedene Symbole sieht die aber genau die gleiche Wirkung haben.

Ob sie die gleiche Wirkung haben ist nicht sicher. Es könnten theoretisch unterschiedliche Repräsentationen dahinter stehen.
Sie haben auf jedem Fall den gleichen Namen und das ist das eigentliche Problem.

Mecki

Und wer sagt mir nun, ob sie die gleiche Funktion haben oder nicht ??
Da ich diese Symbole nicht definiert habe, müsste ich doch wenigstens irgendwo Informationen dazu finden

akari

Hallo

Wenn aber zwei verschiedene Repräsentationen dahinterstehen sollte die Zweisung an SortType nicht so einfach vom Compiler angenommen werden. Selbst wenn beide stNone-Symbole jeweils in der selben Position in verschiedenen enums stehen, sollte der Compiler bei verwenden des jeweils verkehrten enum-Symbols eine Fehlermeldung bringen. Deshalb mein Gedanke das nur ein typedef dafür sorgen könnte das die Zuweisung mit beiden Namespaces kompiliert.

bis bald
akari

Braunstein

Ich meinte damit, dass unterschiedliche Zahlen dahinter stehen können.

akari

Hallo

Ob nun verschiedene Zahlen hinter den enum-Konstanten stehen ist dabei zweitranging, es geht nur darum ob der R-Wert der Zuweisung direkt zu dem enum des L-Wertes gehört oder nicht.
Kleines Beispiel :

namespace n1
{
enum e1 {c1, c2};
}
namespace n2
{
enum e2 {c2, c1};
}
...
n1::e1 test = n2::c1;

Da kommt zumindestens eine Warnung :

W8006 n1::e1 wird mit n2::e2 initialisiert.

Das bedeutet das nur eine Zuweisung aus ein und demselben enum fehler- und warnungsfrei kompiliert wird, nur typedefs können da zweite aber passende Symbole generieren.

bis bald
akari

audacia

Mecki schrieb:

Thnx-- Dann hoffen wir, dass in der nächsten Version alles besser wird.

Wird es. In C++Builder 2009 kannst du enum-Konstanten explizit über den Scope des enum-Typs angeben (C++0x-Erweiterung):

ListView1->SortType = TSortType::stNone;