#include im Header-File "verstecken"

Hallo.

Ich möchte ein #include "framework.h" im Header-File(test.h) "verstecken" bzw. wenn test.h in einem anderem File includiert wird, möchte ich, dass framework.h nicht somit auch automatisch includiert.

Mittels einem kleinen Beispiel möchte ich das kurz schildern:

//test.h
class test
{
   public:
      test();
      void work();
};

//test.cpp

#include "test.h"
#include "framework.h"
test::test()
{
}
void test::work()
{
   framework::work();
}

//main.cpp
#include "test.h"

main()
{
   test t1;
   t1.work();
}

In main.cpp kann ich auf das Framework nicht zugreifen und das ist auch gut so, jedoch wenn ich alles in test.h ausprogrammiere und auf test.cpp verzichte, dann schon...

//test.h

#include "framework.h"
class test
{
   public:
      test() {}
      void work() {framework::work();}
};

//main.cpp
#include "test.h"

main()
{
   test t1;
   t1.work();
}

Nun kann ich im main.cpp auf alles aus framework.h auch zugreifen und das möchte ich verhindern, jedoch sollte die headerfile only Variante auch bestehen bleiben.

Gibt es eine Lösung, dass ich das include "framework.h" in test.h irgendwie auf private setzen kann oder so?

Ich hoffe, ich konnte mein Problem so schildern, dass es verständlich ist
DANKE.

daddy_felix

Das hört sich sehr seltsam an. Kannst du etwas genauer erkären, was du erreichen möchtest?

Wo ist das Problem, "Framework.h" nur in der "test.cpp" einzubinden? Wenn es nur die inline-Definitionen sind, dann verzichte darauf. Wenn du der Meinung bist, die Methoden müssten aus Performancegründen unbedingt inline sein, dann verwende das entsprechende Schlüsselwort bei der Deklaration. Aber vorher besser mal profilen, ob es wirklich inline sein muss. In der Regel sind die Bottlenecks ganz woanders.

DocShoe

Du kannst den Präprozessor benutzen, um eine bedingte Kompilierung durchzuführen:

test.h

#ifdef ENABLE_UNIT_TEST
#include "framework.h"
#endif

class test
{
   ...
   void test();
};

test.cpp

void test::work()
{
#ifdef ENABLE_UNIT_TEST
   framework::work();
#endif
}

Wenn du jetzt build-spezifische Definitionen benutzt (im Debug Modus ist ENABLE_UNIT_TEST definiert, im Release nicht) kannst du den Test ein- und ausschalten.

Es ist so, dass einige Klassen rein im Headerfile ausprogrammiert wurden (war sehr vorteilhaft für uns, weil die manuelle Verwaltung des Makefiles teilweise vereinfacht wurde, usw.)

Nun habe ich eben das Problem, dass ich durch einiger include's in verschachtelten reinen Headerfiles mich nun gegenseitig includiere
Das ganze würde nicht auftreten, wenn es ein cpp gäbe. Würde ich das alles umstellen, dann treten bei bestehenden Sachen etliche Probleme auf und das möchte ich natürlich auch wieder vermeiden.

Lange Rede kurzer Sinn: Ich möchte quasi im Headerfile ein include machen, dass sich quasi genau so auswirkt als würde ich es im cpp machen.

asc

mavilla schrieb:

Es ist so, dass einige Klassen rein im Headerfile ausprogrammiert wurden (war sehr vorteilhaft für uns...

Scheinbar schießen sich manche Leute lieber in den Fuß als etwas richtig zu machen. Vorteilhaft war es maximal beim Makefile - jetzt lebt mit den Konsequenzen.

Soetwas gibt es nicht. Du wirst deinen Code ändern müssen.

daddy_felix

mavilla schrieb:

Nun habe ich eben das Problem, dass ich durch einiger include's in verschachtelten reinen Headerfiles mich nun gegenseitig includiere

klingt nicht so, als hättet ihr jemals was von "Header guards" gehört?

Dass "#include" lediglich eine Textersetzung macht, ist euch vermutlich auch nicht bekannt?

Swordfish

...

@asc, @daddy_felix
Das Problem ist die schon angesprochene Unwissenheit mancher Kollegen, aber es hilft mir nun auch nichts, wenn ich mich hinausrede auf diese Kollegen. Ich habe nun das Problem mit diesem "historischen" Code und muss Lösungen finden bei div. Erweiterungen und wenn es nun gar keine Lösung mehr gibt, dann habe ich ein sehr sehr großes Problem

@Swordfish
Blick noch nicht ganz durch wie ich das Anwenden könnte?

daddy_felix

mavilla schrieb:

Ich habe nun das Problem mit diesem "historischen" Code und muss Lösungen finden bei div. Erweiterungen und wenn es nun gar keine Lösung mehr gibt, dann habe ich ein sehr sehr großes Problem

Bau als erstes "include guards" ein, dann hast du zumindest schonmal keine Probleme mit zyklischen Einbindungen.

Aso, nein die sind sowieso drinnen, da habe ich mich vorhin bzgl. dem gegenseitigen inkludieren falsch ausgedrückt, aber trotzdem habe ich durch das gegenseitige includieren von Headeronly-Klassen eben Auflösungsprobleme.

#include im Header-File &quot;verstecken&quot;

#include im Header-File "verstecken"