4. E2178: VIRDEF-Namenskonflikt bei 'funktion' (C++)

E2178: VIRDEF-Namenskonflikt bei 'funktion' (C++)

  • ?

    Diese Fehlermeldung bekomme ich bei einigen Dateien meines Projektes beim Compilieren.
    Das Merkwürdige ist, dass ich den Compiler (Borland C++ Builder 4, ich weiß, alt und nimmt man eigentlich nicht mehr) genau so wie immer installiert habe und einen 100%ig funktionalen Source von einer CD genommen habe.

    D.h. der Compiler ist der gleiche, der Source ist der gleiche, aber ich kriege etliche VIRDEF-Namenskonflikte. Auch nicht immer an der gleichen Stelle, sondern immer so in 4-5 verschiedenen Dateien.

    Könnt ihr mir da weiterhelfen woran es liegen könnte? Am Source liegt es nicht, der ist unverändert und ich habe den schon vorher mehrfach erfolgreich compiliert.

    Einzige Änderung ist, dass ich den Rechner gewechselt habe (WinXP statt Win2k).
    Der Builder hat den Patch 1 bekommen.

    Die Online-Hilfe sagt, dass ich zu lange ergänzte Namen verwenden würde, was aber Quatsch ist, da die Namen seit Jahren so sind wie sie dort sind und diverse Versionen der Software damit erstellt wurden.

    Falls ich noch nicht genug Informationen gegeben habe, um Vermutungen loszutreten, so schreibt mir das bitte. Bin für jede Hilfe dankbar.

    greetz
    para

    0
  • A

    para123 schrieb:

    Diese Fehlermeldung bekomme ich bei einigen Dateien meines Projektes beim Compilieren.

    Vermutlich beim Linken.

    para123 schrieb:

    (Borland C++ Builder 4, ich weiß, alt und nimmt man eigentlich nicht mehr)

    Sic.

    Du könntest mal ein paar konkrete Fehlermeldungen posten. Und ansonsten versuchsweise den Linker von C++Builder 4 (ilink32.exe) durch den des kostenlosen Turbo C++ 2006 ersetzen.

    0
  • ?

    Habe jetzt den Linker mal durch den aus dem kostenlosen Compiler (Version 5.5) ersetzt (iLink32.exe). Ergibt keinerlei Änderung.

    Konkrete Fehlermeldungen (aus dem letzten Compiliervorgang):

    [C++Fehler] GlobalObjects.cpp(8): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::GlobalObjects()'.
    [C++Fehler] GlobalObjects.cpp(8): E2178VIRDEF-Namenskonflikt bei '_fastcall AnsiString::AnsiString()'.
    [C++Fehler] GlobalObjects.cpp(44): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::~GlobalObjects()'.
    [C++Fehler] GlobalObjects.cpp(51): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::load()'.
    [C++Fehler] GlobalObjects.cpp(54): E2178VIRDEF-Namenskonflikt bei '_fastcall AnsiString::c_str() const'.
    [C++Fehler] GlobalObjects.cpp(115): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::save()'.
    [C++Fehler] GlobalObjects.cpp(153): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::getProgramPath()'.
    [C++Fehler] GlobalObjects.cpp(159): E2178VIRDEF-Namenskonflikt bei 'GlobalObjects::getNextProjectSendID()'.

    Danach bricht der Compiler ab. Die Meldungen unterscheiden sich bei jedem Vorgang im Grunde nur durch die Datei, die bemängelt wird. Wechselt immer so zwischen 4 verschiedenen Dateien hin und her. Bei jedem Vorgang eine Liste mit VIRDEF-Fehlern, die so aussehen wie oben.

    greetz
    para

    0

  • Evtl. brauchst du auch noch UPDATE PACK 2 für den C++Builder 4, s. http://info.borland.com/devsupport/bcppbuilder/patches/bcpp4/english/UPD2RDME.TXT

    Edit: hier noch der Link auf die Update-Seite: http://info.borland.com/devsupport/bcppbuilder/patches/#cbuilder4

    0
  • ?

    Äußerst unwahrscheinlich, dass das ein Problem sein sollte, da das Programm komplett mit dem Patch 1 entwickelt wurde, ohne Patch 2.

    Ich probier es trotzdem mal aus.

    greetz
    para

    0

  • Hast du denn mal einen kompletten Rebuild gemacht, d.h. auch die Precompiled-Header-Dateien gelöscht etc. ?

    0
  • ?

    Im Projektordner befinden sich nur die CPP-Dateien und die zugehörigen Header. Hinzu kommen teilweise DFM-Files, für die Windows-Oberfläche (hatte auch mit nem Texteditor Dateien modifiziert und dann gemerkt, dass die DFM-Dateien Probleme machen, wenn man diese Dateien nicht im Builder editiert).

    Beim Compilieren steht im Log aber tatsächlich etwas von wegen "vorcompilierte Header geladen".

    Haben die eine spezielle Endung beim Builder-4? Könnten die auch in einem anderen Ordner gespeichert sein?

    Ansonsten hab ich da nichts finden können.

    Im Hauptordner des Projektes befindet sich auch eine DSK-Datei und eine RES-Datei. Ich kenne mich mit den Bedeutungen da nicht so genau aus, aber das eine wird wohl für Ressource stehen o.ä.

    Könnten diese Dateien der Problemherd sein? Werde das mal testen.

    0
  • ?

    Die Object-Files hab ich natürlich alle gelöscht vorm Compilieren.

    0
  • ?

    Soeben ist der Compiler an einer anderen Stelle hängen geblieben (ist er vorher auch schon 1mal, das war aber nach Löschen der obj-Files nicht mehr vorgekommen):

    Und zwar gibt er bei dieser Zeile einer der Header-Dateien

    bool fillListViewItem(TListItem *ListItem, char aDateMode=0, char aTimeMode=0);

    folgende Fehlermeldung aus:

    E2293 ) erwartet.

    Hier wurde natürlich auch nichts verändert, was mich wieder sehr stutzig werden lässt.. 😕

    greetz
    para

    0

  • Ja, die vorkomp. Dateien sind im BCB-Ordner 'Lib' untergebracht.
    Lösch dort mal alle Dateien mit der Endung '.csm' sowie die 'vcl40.#XX'-Dateien (am besten einfach mal den Ordner nach Datum im Explorer sortieren und dann alle besagten Dateien in den Papierkorb schieben).

    Ich habe zwar hier nur den CBuilder 5 (bei mir heißen die Dateien 'vcl50.#XX')
    , aber sollte beim 4er auch nicht anders gewesen sein (außer der Name)...

    Und dann noch mal dein Projekt neu bauen.

    0
  • ?

    Ja, die Dateien hab ich nun alle gefunden und in den Papierkorb verschoben.

    Hatte in den Projekteinstellungen auch schon vorcompilierte Header deaktiviert, seitdem macht der Compiler keine dementsprechenden Meldungen mehr.

    Auch die VIRDEF-Fehler hab ich seitdem nicht mehr zu Gesicht bekommen, scheint daran gelegen zu haben.

    Leider bleibt der

    [C++Fehler]ArListItemDeviceState.h(62): E2293 ) erwartet.

    Zeile 62:

    bool fillListViewItem(TListItem *ListItem, char aDateMode=0, char aTimeMode=0);

    Vielen Dank für den guten Support bislang. Hat mir sehr geholfen. Wäre toll, wenn wir das (hoffentlich) letzte Problem auch noch geklärt kriegen.

    Inzwischen habe ich

    - C++ Builder 4 mit Patch 1 & 2 versehen (inkl. Builder Reinstall)
    - vorcompilierte Header deaktiviert / gelöscht
    - den Linker iLink32.exe mit dem des Builder 5.5 ersetzt
    - den Sourcecode immer noch nicht verändert seit dem letzten erfolgreichen Compilieren

    Patch 2 sowie Linker tauschen hatten auf das Projekt keine Wirkung.
    Das VIRDEF-Problem kam wie es aussieht von den vorcompilierten Headern.

    - Kann geänderte Hardware/Betriebssystem überhaupt Compiler-Fehler verursachen?
    - Können solche Fehler entstehen, wenn ich auf dem alten Rechner SubVersion laufen hatte und dieses nun hier nicht installiert ist?
    - Woher kann ein E2293 kommen, wenn nicht aus fehlerhaftem Code? Denn sonst hätte dieser Code ja niemals funktionieren dürfen.

    Verbessert mich, wenn ich mich irre. 🙂

    0

  • Wahrscheinlich kennt er jetzt den Typ 'TListItem' nicht. Durch die vork. Header könnte es vorher funktioniert haben (da die gesamte <VCL.h> dort abgelegt ist).

    Also einfach noch ein

    #include <comctrls.hpp>
// bzw.
class TListItem;

    vorher einfügen.

    Ansonsten einfach mal die Header-Datei posten...

    0
  • ?

    Sieht gut aus. Sieht sehr gut aus. ^^

    Nach der #include-Zeile hat er mir nun ohne Mucken eine EXE ausgespuckt.

    Teste die gleich mal. 🙂

    Vielen Dank für die Hilfe! Und ein frohes Weihnachtsfest wünsche ich. 🙂

    0

  • Danke, wünsche ebenfalls ein Frohes Fest :xmas1:

    Vllt. spendiert dir der Weihnachtsmann ja eine neuere Version vom C++ Builder 😉

    0
Anmelden zum Antworten