4. Problem mit Include-Reihenfolge

Problem mit Include-Reihenfolge

  • _

    Hallo miteinander,

    Ich hab da mal wieder ein nerviges Problem:

    ich benutze in einem Programm die JVCL Komponenten von Jedi, die PNG Imagelist von LMD und Rave Reports.

    Ärgerlicherweise musste ich nun feststellen, dass sich die Header davon gegenseitig ganz schön in die Quere kommen ("Deklaration nicht ordnungsgemäß abgeschlossen" usw. wegen den div. Bezeichnern).

    Ich habe schon rausgefunden, dass sie in folgender Reihen inkludiert werden müssen:

    - LMDImagelist
    - RaveReports
    - Jedi

    dann funktioniert es. Allerdings handelt es sich nicht nur um ein Formular/Unit sondern um mehrere, die von allem Komponenten enthalten...

    Ich bekomme es nicht, die Includes so anzuordnen, dass es keine Fehler mehr gibt.
    Eigentlich habe ich mir gedacht, dass ich alle Includes von RaveReports (durch das das Chaos angefangen hat) bereits in der Headerfile der MainForm inkludiere, damit sie später nicht mehr in den anderen Formularen inkludiert werden, wo vorher bereits die JVCLs inkludiert wurden. 🙄

    Naja, es klappt auf jeden Fall nicht. Obwohl eigentlich die Header von RaveReports überall vor denen von Jedi sind, kommt es in der RpBase.hpp zu einem Konflikt der durch die Jvconsts.hpp ausgelöst wird...

    Meine Fragen:
    a. Weiß jemand, wie genau und in welcher Reihenfolge (besonders bzgl. Rekursion) Header im BCB inkludiert werden bzw. wo ich etwas dazu finden kann?
    b. Was kann man sonst noch machen (am liebsten natürlich ohne die Fremdpakete verändern zu müssen)?

    Vielen Dank schonmal und schönen Tag noch!

    0
  • A

    __yoshi schrieb:

    a. Weiß jemand, wie genau und in welcher Reihenfolge (besonders bzgl. Rekursion) Header im BCB inkludiert werden bzw. wo ich etwas dazu finden kann?

    Genau so, wie du sie einbindest. Es sei natürlich denn, du hast für dein Projekt einen Master-PCH erstellt; dann sind die darin enthaltenen Header in jedem Unit als erste eingebunden.

    __yoshi schrieb:

    b. Was kann man sonst noch machen (am liebsten natürlich ohne die Fremdpakete verändern zu müssen)?

    Das hängt sehr davon ab, wie die Mehrdeutigkeiten aussehen. Könntest du da nicht etwas konkreter werden?

    0
  • _

    Hi,

    __yoshi schrieb:

    b. Was kann man sonst noch machen (am liebsten natürlich ohne die Fremdpakete verändern zu müssen)?

    Das hängt sehr davon ab, wie die Mehrdeutigkeiten aussehen. Könntest du da nicht etwas konkreter werden?[/quote]

    Ein aktueller Fehler ist:
    [BCC32 Fehler] RpBase.hpp(462): E2040 Deklaration nicht ordnungsgemäß abgeschlossen

    RpBase.hpp:
    void __fastcall CrLf(void);

    JvConsts.hpp
    #define CrLf "\r\n"

    Gefolgt von dutzenden anderen "mehrfach deklariert" etc.

    Bzgl. Einbindungsreihenfolge:

    Main.h:
#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>

#include "LMDPNGImage.hpp"

#include "RpBase.hpp"
#include "RpDefine.hpp"
#include "RpRave.hpp"
#include "RpSystem.hpp"
#include "RpCon.hpp"
#include "RpConDS.hpp"

#include "FormXY.h"

#include "LMDControl.hpp"
#include "LMDCustomBevelPanel.hpp"
#include "LMDCustomControl.hpp"
#include "LMDCustomPanel.hpp"
#include "LMDSimplePanel.hpp"
...

FormXY.h:
#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include "LMDPNGImage.hpp"

#include "RpCon.hpp"
#include "RpConDS.hpp"
#include "RpDefine.hpp"

#include "JvDBGrid.hpp"
#include "JvExDBGrids.hpp"

#include <DB.hpp>
#include <DBGrids.hpp>
#include <ExtCtrls.hpp>
#include <Grids.hpp>
...

    Warum schmeißt er den Fehler hier bei Rave? Die "RpBase.hpp" ist doch vor irgendetwas anderem von Jedi inkludiert...?!

    Gruß

    0
  • A

    Da bleibt dir, gerade in Fällen wie denen, wo der Delphi-Compiler Konstanten in Delphi als Makros in C++ ausdrückt (das tut er, um nicht in Konflikt mit dem PCH-Mechanismus, der statische Initialisierungen nicht erlaubt, zu kommen), nichts übrig, als die Header- oder Unit-Datei zu bearbeiten. In diesem Fall könntest du z.B. einfach das #define entfernen.

    0
  • _

    Oh shit, Frau Schmidt.
    Ich habe gehofft das vermeiden zu können...

    Naja gut, dann werde ich mich mal daran begeben. Vielen Dank!

    0

  • Manchmal hilft es auch, wirklich alle Includes in nur einer Header-Datei zu lagern. Und dann in jedem Source-File nur diese eine Header-Datei zu includen. Habe mit der Taktik eigentlich immer alles hinbekommen.

    0
  • A

    Mit einem Master-Header kann man die Kompilierungszeiten beschleunigen und PCH-Probleme vermeiden (und C++Builder 2009 wird voraussichtlich einen Wizard mitbringen, der diesen Schritt automatisiert), aber wenn eine Headerdatei so etwas wie

    #define CrLf "\r\n"

    macht, ändert das nichts daran, daß das Symbol im weiteren Kontext unbenutzbar ist.
    Ein Workaround, der ohne Modifikation der Original-Header und -Units auskommt, wäre, all diese #defines zu lokalisieren und unmittelbar nach dem Einbinden der Headerdatei mittels #undef wieder zu entfernen. Um das nicht mehrfach tun zu müssen, wäre ein Master-Header natürlich hilfreich.

    0
  • _

    Hi,

    It0101 schrieb:

    Manchmal hilft es auch, wirklich alle Includes in nur einer Header-Datei zu lagern. Und dann in jedem Source-File nur diese eine Header-Datei zu includen. Habe mit der Taktik eigentlich immer alles hinbekommen.

    Ja, so etwas habe ich grundlegend versucht, indem ich versucht habe alle kritischen Header bereits in der richtigen Reihenfolge in der Main-Header-File zu inkludieren und danach können sie ja auftauchen wie sie wollen, weil es eh keinen Inklude mehr gibt.

    Wie audacia aber schon sagte, hilft das in diesem Fall leider nicht.

    Naja, nachdem ich mir nun alle Konflikte mal genauer angeschaut habe, konnte ich sie durch Modifikationen in den Originalheadern (nicht schön, aber was will man machen) beheben und das Baby rennt wieder 🙂

    Vielen Dank und schönen Gruß

    0
Anmelden zum Antworten