C++ Keyword 'export'

Raptor

Der g++ kennt ja leider das C++ keyword

export

nicht. Daher ist bei generischen Klassen keine saubere Trennung von Klasse und Implementation moeglich.
Was kann ich dagegen machen?

Artchi

Nichts kann man da machen! Weil leider bisher kein Compiler dieses Schlüsselwort kann. Ist ganz einfach ein fast unlösbares Problem mit dem sich das C++ ISO Committee selbst ein Bein gestellt hat.

Implementier deine ganzen Templates direkt im Header-File. Geht nicht anders.

ZuK

Du kannst die nur einen Compiler kaufen der export versteht. Angeblich gibts aber noch nicht allzuviele.
Habe schon öfters gesehen das implementationen in files mit zb. der Endung .impl ausgelagert wurden dun diese dann mit include in die header eingebunden wurden.
Das ist nicht allzu schön kann aber relativ leicht umgestellt werden wenn export einmal unterstützt wird.
Kurt

Artchi schrieb:

Nichts kann man da machen!

Das stimmt nicht.
Er kann es ja selbst implementieren.

HumeSikkins

Hallo,
euch ist aber schon klar, dass export auch kein Wundermittel ist, oder? Das seperate Übersetzungsmodell was man von nicht-Templates kennt, erhält man auch durch export nicht.

http://www.gotw.ca/publications/mill23.htm
http://www.gotw.ca/publications/mill24.htm

Weil leider bisher kein Compiler dieses Schlüsselwort kann

Irrtum. EDG-basierte Compiler beherrschen export (wie z.B. der Comeau-Compiler)

Ist ganz einfach ein fast unlösbares Problem mit dem sich das C++ ISO Committee selbst ein Bein gestellt hat.

Inwiefern? export, als reine "Papierspezifikation", ist zwar wenig glücklich, aber das dürfte ja eigentlich keinen Compilerhersteller daran hindern eine bessere Strategie zu entwickeln.

Implementier deine ganzen Templates direkt im Header-File. Geht nicht anders.

Für *konkrete* Situationen gibt es durchaus andere Techniken. Stichwort: Explizite Instanziierung (oder Eric Nieblers Instantiator).

Wer vor hat dem comeau-compiler in nächster Zeit zu kaufen, sollte es jetzt tun, den gibt es zur Zeit zu nem super Angebot von 20USD

Raptor

*staubVomThreadAbklopfUndWiederAufwaerm* :xmas1:

Wenn ich meine Implementationen direkt mit der Klasse in das .hpp File packe, gibt es einige Probleme.
Ich brauche fuer die Implementation meiner Klasse A eine andere Klasse B, die wiederum auf die Klasse A angewiesen ist.(A includiert B und umgekehrt)
Normalerweise waere das kein Problem, koennte ich die Implementation in ein separates *.cpp file auslagern.
Da in der Praxis aber meine Klasse A ein Template ist, geht das eben aufgrund eines fehlenden export Keywords nicht.
Es entstehen also in den Headerfiles zyklische Abhaengigkeiten, wenn beide sich gegenseitig includieren.

//file: a.hpp
#ifndef A_HPP
#define A_HPP
#include <b.hpp>

class A
{
public:
    void foo()
    {
        B b;
        b.bar();
    }
};

#endif

//file: b.hpp
#ifndef B_HPP
#define B_HPP
#include <a.hpp>

class B
{
public:
    void bar()
    {
        A a;
        a.foo();
    }
};

#endif

UniX:~/test$ g++ b.hpp
/home/raptor/test/a.hpp: In member function 'void A::foo()':
/home/raptor/test/a.hpp: error: 'B' was not declared in this scope
/home/raptor/test/a.hpp: error: expected `;' before 'b'
/home/raptor/test/a.hpp: error: 'b' was not declared in this scope

Was kann ich dagegen tun? Die Implementation in ein separates File zu packen waere natuerlich am besten. Geht aber nicht(siehe Topic).

Raptor

Ein unloesbares Problem also?

camper

Raptor schrieb:

Ein unloesbares Problem also?

das ist - weitgehend - kein problem. solange du kein template instantiierst (oder eben eine explizite spezialisierung schreibst), bist du nicht auf die definition des jeweils anderen templates angewiesen, eine vorwärtsdeklaration genügt.

//file: a.hpp
#ifndef A_HPP
#define A_HPP
template<typename T> class B;

template<typename T> class A
{
public:
// ...
};
#include <b.hpp>

#endif

//file: b.hpp
#ifndef B_HPP
#define B_HPP
#include <a.hpp>

template<typename T> class B
{
public:
// ...
};

#endif

Artchi

Also, wenn man bedenkt, das das ISO-Kommittee bereits darüber nachgedacht hat, export im nächsten Standard wieder raus zu nehmen, dann scheint es ein unlösbares Problem zu sein.

Andererseits sagt EDG auch, das sich die User zuviel und vorallem falsches unter export vorstellen. Z.B. wird man die Implementierung von Templates durch export nicht verstecken können. Und wenn ich mich nicht ganz verlesen habe, wird durch export die Compilezeit noch verlängert.

Im großen und ganzen kann man auf export verzichten... aber export wird wohl doch nicht rausfliegen. Ich pers. fänd es besser, da dieses Feature wohl nie in die Compiler einfliessen wird (bis auf EDG).

rüdiger

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf <-- sehr interessant zu dem Thema

Raptor

camper schrieb:

Raptor schrieb:

Ein unloesbares Problem also?

das ist - weitgehend - kein problem. solange du kein template instantiierst (oder eben eine explizite spezialisierung schreibst), bist du nicht auf die definition des jeweils anderen templates angewiesen, eine vorwärtsdeklaration genügt.

Wie schon gesagt, muss ich die Implementation mit dem Header in ein File bekommen.
In der Implementation bin ich auf einige Funktionen meiner Klasse B angewiesen, naemlich, wie auch schon in dem SourceCode Beispiel gezeigt einige Funktionsaufrufe.
Eine Forward-Declaration reicht also leider nicht mehr aus:

error: invalid use of undefined type 'struct B'
error: forward declaration of 'struct B'

rüdiger

Warum musst du die Implementierung in den Header packen? Du benutzt ja offensichtlich keine Templates.

Raptor

Doch, ich benutze schon templates.
Ich habe das SourceCode Beispiel nur dazu gestrickt, um den Error zu demonstrieren. Fakt ist, das meine Implementation mit dem Header in ein File muss(sofern export nicht doch irgendwie funktioniert).