#ifndef __mat_h__
#define __mat_h__

template<class t>
class mat
{
	public:
		t _data;
		void change(t const &data);

};

#include "lgs.h"

#include "mat.cpp"

#endif

mat.cpp

#ifndef __mat_cpp__
#define __mat_cpp__

#include "mat.h"

template<class t>
void mat<t>::change(t const &data)
{
	lgs::change(*this, data);
}

#endif

lgs.h

#ifndef __lgs_h__
#define __lgs_h__

#include "mat.h"

class lgs
{
	public:
		template<class t>
		static void change(mat<t> &m, t const &data);

};

#include "lgs.cpp"

#endif

lgs.cpp

#ifndef __lgs_cpp__
#define __lgs_cpp__

#include "lgs.h"

template<class t>
void lgs::change(mat<t> &m, t const &data)
{
	m._data = data;
}

#endif

Der Aufbau der Klassen macht in diesem Beispiel nicht unbedingt viel Sinn, aber soll auch nur zur Problemkonstruktion dienen.
Ich benutze Code::Blocks 10.05 mit dem GNU GCC und dieser gibt mir folgende Fehlermeldung, die ich nicht ganz nachvollziehen kann:

mat.cpp: In member function 'void mat<t>::change(const t&)':
mat.cpp:10: error: 'lgs' has not been declared

Danke schonmal im Voraus!

mir ist das schon klar das ich zirkulär inklude, was allerdings durch IncludeGuards kein Problem sein sollte.

Genau da liegt dein Trugschluss. Es ist eben doch ein Problem...

Wie gesagt:

dot schrieb:

Include Guards sind kein Freibrief um einfach abschalten und alles überall inkludieren zu können...

template<class t>
class mat
{
    public:
        t _data;
        void change(t const &data);
};

class lgs
{
    public:
        template<class t>
        static void change(mat<t> &m, t const &data);
};

template<class t>
void lgs::change(mat<t> &m, t const &data)
{
    m._data = data;
}

template<class t>
void mat<t>::change(t const &data)
{
    lgs::change(*this, data);
}

Kann es sein, dass du in deine Code doch noch irgendwo etwas anders hast als bei dem, was du hier gepostet hast?

deklaration mat und lgs
definition mat und lgs

und wenn ich das durchspiele kommt das doch auch überall so hin, oder nicht?

Kann es sein, dass du in deine Code doch noch irgendwo etwas anders hast als bei dem, was du hier gepostet hast?

ich hab es genauso wie oben compiliert, mit GNU GCC, und da gibt er besagten fehler. mein eigentlicher code ist komplexer, aber konnte den gleichen fehler halt auch mit dieser vereinfachten variante konstruieren, also muss er auch hier zu finden sein.

// A.h

#ifndef A_INCLUDED
#define A_INCLUDED

#include "B.h"

class A
{
};

#endif

// B.h

#ifndef B_INCLUDED
#define B_INCLUDED

#include "A.h"

class B
{
  A a;
};

#endif

Du inkludierst irgendwo A.h. A_INCLUDED wird definiert und dann gleich drauf B.h inkludiert. B.h inkludiert nun wieder A.h. Da A_INCLUDED aber schon definiert ist kommt nix aus A.h mehr rein und der Typ A ist in B.h undefiniert. Die Moral von der Geschicht: Include Guards lösen nicht auf irgendeine magische Art und Weise zirkuläre Abhängigkeiten auf.

Aus

#include "A.h"

wird

class A;

.

Wenn A.h bereits inkludiert ist, dann findet man in B.h nur eine leere Datei (dank Inkludeguards). Somit kann es nicht funktionieren.

Abgesehen davon kann man das mit der Trennung von Deklaration und Implementierung schon so machen nur würde ich dazu raten die Dateien dann eben nicht .cpp zu nennen sondern irgendwas anderes.

Darf ich die Auflösung erfahren, warum der gepostete Code bei mir lief und bei dir nicht?

Vermutlich weil du mat.h inkludiert hast und nicht lgs.h

#ifndef __lgs_h__
#define __lgs_h__

template<class t>
class mat;

class lgs
{
	public:
		template<class t>
		static void change(mat<t> &m, t const &data);

};

#include "mat.h"

#include "lgs.cpp"

#endif

geändert und es funktioniert.

Dobi schrieb:

Darf ich die Auflösung erfahren, warum der gepostete Code bei mir lief und bei dir nicht?

Vermutlich weil du mat.h inkludiert hast und nicht lgs.h

Ich hatte nix geändert sondern nur den Code, der im Eingangspost stand, in Dateien kopiert, was man auch auf den Screenshots sieht. Naja, mir solls egal sein.

Allerdings hat es sich (schon allein der Übersichtlichkeit halber) durchgesetzt, dass man die Definitionen einfach mit in die .h schreibt, die cpp nicht includiert und da nur den Kram drin hat, der nicht sichtbar sein muss. Dann passt es auch wieder zum normalen .h-.cpp-Konzept. Das würde ich auch empfehlen.

Was daran übersichtlich sein soll, kann ich jetzt überhaupt nicht nachvollziehen. In ein headerfile sollen die Definitionen und nichts anderes.
Alle eigentlichen Codes ins cpp. Wenn da was keine Templates drin hat, hat man schnell zwei defines angebracht, so dass sich das cpp auch trotz des mit enthaltenen template codes problemlos kompilieren lässt.
So ist dann aber alles schön so zusammen wie es auch bei allen nicht-Template-Klassen ist.

Was daran übersichtlich sein soll, kann ich jetzt überhaupt nicht nachvollziehen. In ein headerfile sollen die Definitionen und nichts anderes.

Ein Template funktioniert aber nicht nach den "üblichen" Maßstäben, und es ist mit Sicherheit ungewöhnlicher ein include auf eine cpp zu machen, als eine Definition in die Header zu schreiben (und wenn schon, mit einer Endung die auf den Sonderfall hinweist. z.B. tmpl statt cpp).

Ein Template funktioniert aber nicht nach den "üblichen" Maßstäben,

Wohl war, aber es lässt sich so umsetzen, dass es genauso mit einbezogen werden kann wie eine ganz normale Klasse - Und dies macht in meinen Augen mehr Sinn, als etwas wie

asc schrieb:

(...mit einer Endung die auf den Sonderfall hinweist. z.B. tmpl statt cpp).

Denn ich sehe hier keinen Mehrnutzen. Oder was nützt es mir, wenn ich die Endung sehe und dann nachschauen muss: "scheisse, was ist denn das für n'ding?".
Und wenn ich dann noch Teile separat kompilieren muss, zB wegen einer Spezialisierung, dann soll das nochmals in ein separates File usw usw? Ne Danke, da ist doch der gute alte Aufbau einmal .hpp und einmal .cpp viel angenehmer.