ich habe grade eine Log klasse für mein Projekt geschrieben.
Vorher hatte ich mich nicht wirklich viel mit Templates beschäftigt, jetzt brauch ich halt welche. also tutorial angeguckt. da stehts aber wie immer nur als ganz normaler code. ich übernehm das in meine struktur.

GLog.h

#ifndef GLOG
#define GLOG

#include <fstream>
using namespace std;

class GLog
{
	private:
		fstream Log;
	public:
		GLog();
		~GLog();
		template<class T>
		void WriteLog(T);
		bool Open(char*);
		bool Close();
};

#endif

GLog.cpp

#include "GLog.h"

GLog::GLog()
{

}

GLog::~GLog()
{

}

bool GLog::Open(char* path)
{
    Log.open(path, ios::out);
	return true;
}

bool GLog::Close()
{
    Log.close();
	return true;
}
void GLog::WriteLog(T mes)
{
	Log << mes << endl;
}

so, jetzt kommen ziemlich viele compiler errors:

1>h:\alex\proggen\godrings2\godrings2\glog.cpp(24) : error C2065: 'T': nichtdeklarierter Bezeichner
1>h:\alex\proggen\godrings2\godrings2\glog.cpp(24) : error C2146: Syntaxfehler: Fehlendes ')' vor Bezeichner 'mes'
1>h:\alex\proggen\godrings2\godrings2\glog.cpp(24) : error C2761: 'void GLog::WriteLog(T)': Die erneute Deklaration der Memberfunktion ist unzulässig
1>h:\alex\proggen\godrings2\godrings2\glog.cpp(24) : error C2059: Syntaxfehler: ')'
1>h:\alex\proggen\godrings2\godrings2\glog.cpp(25) : error C2143: Syntaxfehler: Es fehlt ';' vor '{'
1>h:\alex\proggen\godrings2\godrings2\glog.cpp(25) : error C2447: '{': Funktionskopf fehlt - Parameterliste im alten Stil?

was muss ich ändern?

Und das ganze in den Header.

kann man templates nur IM header implementieren? weil ich arbeite eig so, die funktionen im header zu definieren und in einer cpp datei zu implementieren. geht das net auch iwie so?

Nein, geht bei den meisten Compilern nicht. Es sei denn es wird export für Templates unterstützt, was egtl nicht der Fall ist. Du kannst die Definition in eine extra Datei packen und in den Header inkludieren.

#ifndef GLOG
#define GLOG

#include <fstream>
using namespace std; // NICHT IM HEADER!

class GLog
{
    private:
        fstream Log;
    public:
        GLog();
        ~GLog();
        template<class T>
        void WriteLog(T);
        bool Open(char*); // const? std::string?
        bool Close(); // was soll den beim schließen fehlschlagen? void!
};

#endif

=>

#if !defined (G_LOG_H__INCLUDED)
#define G_LOG_H__INCLUDED

#if (_MSC_VER > 1000)
#pragma once
#endif // (_MSC_VER > 1000)

#include <fstream>
#include <string>

namespace g // hmm lass dir nen anständigen Namen einfallen ... ;) aber hieß ja bei dir glog ...
{
    class log
    {
    private:
        log();
        ~log();
        log& operator=(const log&);

    public:
        static log& instance() { static log inst; return inst; }

    public:
        bool open(const std::string& filename) { m_file.open(filename.c_str()); return (!m_file ? false : true); }
        void close() { m_file.close(); }

    public:
        template <typename T>
        bool write_data(const T& data) { if (!m_file) return false; m_file << "<p>" << data << "</p>" << std::endl; return true;}

    private:
        std::ofstream m_file;
    };
};

#endif // G_LOG_H__INCLUDED

#include "glog.h"

int main()
{
    g::log& log = g::log::instance(); // damit du nicht immer g::log::instance() schreiben musst ... einfach log.foo ...
    log.open("test.html");
    log.write_data("das ist eine tolle Zeile!");
}

...

das G ist ja auch nur der anfangsbuchtstabe von meinem projektnamen

ich hab noch ein paar fragen dazu:

1. kann man konstruktoren und destruktoren überhaupt private machen?

2. was hat das hier zubedeuten? ist das eine versionsverwaltung?

#if (_MSC_VER > 1000)
#pragma once
#endif // (_MSC_VER > 1000)

3. warum nimmst du nicht einfach einen private teil und einen public teil?

4. hast du die klasse grade zum singleton gemacht? so ähnlichen code hab ich schonmal bei singletons gesehn. die klasse war aber mit absicht kein singleton

das soll jetzt keine kritik sein, einfach nur ein paar verständis fragen.

Eldarion

return (!m_file ? false : true);

=>

return m_file.good();

Eldarion schrieb:

das G ist ja auch nur der anfangsbuchtstabe von meinem projektnamen

Ja, wunderbar. Benutz es als Namensbereich, so wie (D)Evil es zeigte, *nie* als Klassenpräfix.

1. kann man konstruktoren und destruktoren überhaupt private machen?

Sicher kann man. Dann kann die Klasse von außerhalb eben nicht mehr instanziert werden.

2. was hat das hier zubedeuten? ist das eine versionsverwaltung?

#if (_MSC_VER > 1000)
#pragma once
#endif // (_MSC_VER > 1000)

Ne, '#pragma once' sorgt dafür, dass der Compiler die Datei nur einmal einbindet, macht also genau das, wofür auch Include Guards da sind. Ob es sinnvoll ist, beides zu verwenden, weiß ich nicht (ist es das?). Das '#if…' sorgt dafür, dass das Pragma nur verwendet wird, wenn der Compiler es auch versteht (mit anderen Worten: Im MS-VC++-Compiler mit Version > 1000). AFAIK verstehen aber auch jede Menge andere Compiler die '#pragma once'-Direktive.

3. warum nimmst du nicht einfach einen private teil und einen public teil?

Hatter doch.

4. hast du die klasse grade zum singleton gemacht? so ähnlichen code hab ich schonmal bei singletons gesehn. die klasse war aber mit absicht kein singleton

Joar, hat er. Absichtlich.

#pragma once macht nicht zu 100% das was Includeguards tun sollten (es sei denn sie werden optimiert, was auch vorkommen mag). Der Compiler merkt sich in welcher #pragma once residiert und öffnet die mein wiederinkludieren garnicht erst, d.h. man spart sich das hoch zeitaufwendige öffnen der Datei und kann so den Compilierspeed vergrößern.

aber dazu hab ich jetzt mal ne frage, ist es also schlechter stil definition und implemantation zu trennen?

das wollte ich noch wissen. schonmal danke für die antworten.

aber zu drittens: ich sehe da aber 2 private und 3 public teile.

private:
        log();
        ~log();
        log& operator=(const log&);
   
    public:
        static log& instance() { static log inst; return inst; }
   
    public:
        bool open(const std::string& filename) { m_file.open(filename.c_str()); return (!m_file ? false : true); }
        void close() { m_file.close(); }

    public:
        template <typename T>
        bool write_data(const T& data) { if (!m_file) return false; m_file << "<p>" << data << "</p>" << std::endl; return true;}

    private:
        std::ofstream m_file;

aber dazu hab ich jetzt mal ne frage, ist es also schlechter stil definition und implemantation zu trennen?

das wollte ich noch wissen. schonmal danke für die antworten.

Na ja, generell ist es natürlich schon guter Stil. Man sollte aber aufpassen, dass man dadurch letztendlich nicht noch mehr Arbeit hat. Außerdem sind viele Bibliotheken Header-only. Das ist immer dann der Fall, wenn man (wie hier) mit Templates arbeitet. Und wenn eh alles in einer Datei ist, kann man auch gut Implementierung und Definition zusammentun, da spricht nichts gegen, wenn man es sauber schreibt.

aber zu drittens: ich sehe da aber 2 private und 3 public teile.

Ach so. hatte nicht bemerkt, dass die Betonung in Deiner Frage auf "einen" lag.

(D)Evil trennt hier eben verschiedene logische Bereiche der Datei, nicht privat und öffentlich sondern eben verschiedene Teile der Schnittstelle, die für sich genommen gewissermaßen Einheiten darstellen und daher beliebig angeordnet werden können. Ist gut (IMHO), weil es erlaubt, die Teile nachträglich zu verschieben, ohne dass man darauf achten muss, dass der Sichtbarkeitsbereich erhalten bleibt.

...ist es also schlechter stil definition und implemantation zu trennen?...

Nein - oft im Gegenteil.
Bei templates ist es aber schlicht und einfach technisch nicht anders möglich (mal die "export-Exoten" mal außen vor gelassen).

Gruß,

Simon2.

Mit einigen Compilern von "kurz nachm Krieg" geht es zwar nicht in jedem Fall (z.B. VC6), weil die bestimmte Konstrukte nur direkt inline verdauen. I.a. sollte es aber nix geben was man direkt in die Klasse reinimplementieren muss, auch bei templates.

1. kann man Konstruktoren und Destruktoren überhaupt private machen?

... wie Konrad Rudolph schon richtig sagte, verhindert man somit das von außen neue Instanzen der Klasse erstellt werden können. Gehört zum Singleton dazu ...

. hast du die klasse grade zum Singleton gemacht? so ähnlichen Code hab ich schon einmal bei Singleton's gesehen. die klasse war aber mit Absicht kein Singleton

Hmm ja habe ich. Ist bei einem Log zu 99% sinnvoll Aber wenn du einen Grund dagegen hast ... dann nimm es raus und setzt den Konstruktor public. Den copy-Operator kannst du dann raus nehmen.

hmm der Rest wurde ja schon von den anderen erklärt ...

ich hab jetzt um alle meine klassen so ein Namespace-Konstrukt gemacht.

Hmm ... nicht unbedingt sinnvoll. Kommt drauf an. Wenn du bsw. eine Bibliothek geschrieben hast, bietet sich es an diese in einen Namespace zu packen. Oder auch um einzelne Teile einer Bibliothek zu trennen. Ganze Engines kannst du auch in einen Namespace schieben.