template als template übergeben?

SeppJ

Scarabol schrieb:

Hi,

also verstehen tu ich den Text nicht, das ist mir zu theoretisch.

Aber es hat mich auf die Idee gebracht ein paar 'typename' zu streuen und alle Fehler im Header sind weg. Nur in der Implementierung gehts jetzt weiter, dass er auch für die Konstruktoren auf einmal templates haben will...

Und gerade deswegen ist es ja auch so wichtig zu verstehen, was man tut, anstatt so lange rumzuprobieren, bis man etwas compilierendes hat.

Ernsthaft: Das musst du verstehen! Passt dir das Englisch nicht? Soll ich versuchen, das Problem auf Deutsch zu erklären?

Scarabol

Danke für das nette Angebot aber die Mühe brauchst du dir wirklich nicht machen ich hab den Artikel jetzt in meinen Favoriten und ich les ihn einfach nochma wenn ich ein bischen fitter bin. Wenns nicht klappt frag ich dann einfach nochma nach...

MfG
Scarabol

Scarabol schrieb:

kann ich ein template als template übergeben?
Wenn ja wie?

Ja, aber ich bin mir nicht sicher, ob es das ist, was Du wirklich meinst. Ich habe den Eindruck, dass Du das Wort "template" falsch benutzt.

Scarabol schrieb:

template <class ITEM> class table
{
// bla bla
protected:
list<ITEM> liste; // liste erwartet ein template, dass wiederum durch
// das klassentemplate ITEM ersetzt werden soll
}

Hier fehlt die Information, wie das Klassentemplate list deklariert wurde. Es gibt auch einen Widerspruch zwischen Code und Kommentar. Mit "class ITEM" wird ITEM ein Typ-Parameter. Du sprichst aber die ganze Zeit von Klassentemplates. Klassentemplates sind keine Typen sondern Typfamilien.

Scarabol schrieb:

Ich bekomme aber den Fehler:
"warning C4346: 'irr::core::list<T>::Iterator': Abhängiger Name ist kein Typ"
"Präfix mit 'typename' zum Angeben eines Typs"
"error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'type'"
Was mach ich da falsch?

Das sieht danach aus, als ob Du ein typename vergessen hättest. Und das kann man auch nur der Compiler-Fehlermeldung entnehmen. Aus deinen geposteten Code-Fetzen geht das nicht hervor (!).

Was mich an Deiner Anfrage stört:
- Du verwendest das Wort "template" falsch.
- Du hast kein vollständiges kleines Code-Beispiel gepostet.
Einzeln betrachtet ist das jeweils nicht schlimm. Aber beides zusammen führt zu einer Anfrage, mit der Hilfsbereite nicht viel anfangen können. Wenn Du Dich weder korrekt ausdrücken kannst und auch Dein Programm nicht verrätst, was soll dabei rauskommen?

Scarabol

Hi,

startable.h

#ifndef inc_startable_h
#define inc_startable_h

#include "irrlicht.h"
#include "declarations.h"

using namespace irr::gui;
using namespace irr::core;

namespace star
{

	template <typename ITEM>
	class table
	{
	protected:
		class _line
		{
			typename list<ITEM>::Iterator type;
			list<stringw> _vars;
		};

	public:
		table(gameengine *gm, IGUIElement *parent, list<stringw> columns);
		~table();

		void addline(typename list<ITEM>::Iterator type, list<stringw> _vars);
		void refresh(void);
		typename list<ITEM>::Iterator getactive(void);

	private:
		gameengine *_gm;
		IGUIElement *_parent;
		IGUIScrollBar *_scrollbar;
		IGUITab *_headline;
		IGUITab *_content;
		list<_line> _rows;
		typename list<_line>::Iterator _active;

	};

}

#endif

startable.cpp

#include "gameengine.h"
#include "startable.h"

using namespace star;

template <class ITEM>
table<ITEM>::table(gameengine *gm, IGUIElement *parent, list<stringw> columns)
{
	_gm = gm;
	_parent = parent;
}

template <class ITEM>
table<ITEM>::~table()
{
}

MfG
Scarabol

SeppJ

Bevor du irgendwann mal unnötige Probleme bekommst, eine Warnung:

Bezeichner die mit _ anfangen oder zwei _ nacheinander enthalten, sind für die Compilerimplementierung reserviert. Wenn man selber solche Namen benutzt, kann es passieren, dass es zu Namenskonflikten kommt.

theta

SeppJ schrieb:

Bevor du irgendwann mal unnötige Probleme bekommst, eine Warnung:

Bezeichner die mit _ anfangen oder zwei _ nacheinander enthalten, sind für die Compilerimplementierung reserviert. Wenn man selber solche Namen benutzt, kann es passieren, dass es zu Namenskonflikten kommt.

Gilt aber nicht für Member variablen...

Shade Of Mine

theta schrieb:

SeppJ schrieb:

Bevor du irgendwann mal unnötige Probleme bekommst, eine Warnung:

Bezeichner die mit _ anfangen oder zwei _ nacheinander enthalten, sind für die Compilerimplementierung reserviert. Wenn man selber solche Namen benutzt, kann es passieren, dass es zu Namenskonflikten kommt.

Gilt aber nicht für Member variablen...

Doch.

SeppJ

Shade Of Mine schrieb:

theta schrieb:

SeppJ schrieb:

Bevor du irgendwann mal unnötige Probleme bekommst, eine Warnung:

Bezeichner die mit _ anfangen oder zwei _ nacheinander enthalten, sind für die Compilerimplementierung reserviert. Wenn man selber solche Namen benutzt, kann es passieren, dass es zu Namenskonflikten kommt.

Gilt aber nicht für Member variablen...

Doch.

Ich habe mal nachgeschlagen: Der Sachverhalt ist komplizierter:

Überall (auch für Member) sind reserviert:

Namen die einen doppelten Unterstrich enthalten
UND
Namen die mit einem Unterstrich gefolgt von einem Großbuchstaben beginnen

Nur im globalen Namensbereich reserviert sind:

Namen die mit einem Unterstrich beginnen

theta

In 17.4.3.1 ff steht aber nichts davon.
Da sind nur Macro names, Global names und Names with external linkage erwähnt.

Simon

LordJaxom

theta schrieb:

In 17.4.3.1 ff steht aber nichts davon.
Da sind nur Macro names, Global names und Names with external linkage erwähnt.

Da steht aber für die von SeppJ bei "überall" erwähnten Konditionen "for any use".

Daraus folgt doch, dass es keine gute Idee ist, einen solchen Namen für irgendwas eigenes zu verwenden. Denn spätestens, wenn die Bibliotheksimplementierung ein Makro dieses Namens definiert, ist völlig Wurst, ob es sich bei Deiner Verwendung um eine Membervariable handelt.

theta

Da steht aber für die von SeppJ bei "überall" erwähnten Konditionen "for any use".

Da hätte ich gerne die Ref. in den Standard.

Simon

pumuckl

SeppJ schrieb:

Nur im globalen Namensbereich reserviert sind:

Namen die mit einem Unterstrich beginnen

(und im namespace std)

theta schrieb:

In 17.4.3.1 ff steht aber nichts davon.
Da sind nur Macro names, Global names und Names with external linkage erwähnt.

Die Überschrift "Global names" in 17.4.3.1.2 ist da etwas missverständlich. Das bezieht sich nicht auf Bezeichner im globalen namespace sondern allgemein auf namen, die *irgendwo* benutzt werden. Andernfalls würde im zweiten Unterpunkt (Namen die mit Unterstrichen beginnen, [auch ohne folgenden Großbuchstaben]) der Zusatz "for use as a name in the global namespace" keinen Sinn machen.

Siehe auch ausführliche Diskussion hier: http://www.velocityreviews.com/forums/t486491-reserved-identifiers.html

LordJaxom

theta schrieb:

Da hätte ich gerne die Ref. in den Standard.

17.4.3.1.2 erster Spiegelstrich

theta

Danke.
Simon

SeppJ

pumuckl schrieb:

SeppJ schrieb:

Nur im globalen Namensbereich reserviert sind:

Namen die mit einem Unterstrich beginnen

(und im namespace std)

Interessanterweise steht das im Standard nicht so, dort wird ausdrücklich der globale Namensbereich genannt. Das bedeutet wohl, dass in std nur die Namen mit doppeltem Unterstrich und die Namen mit Unterstrich und Großbuchstaben reserviert sind.

camper

SeppJ schrieb:

pumuckl schrieb:

SeppJ schrieb:

Nur im globalen Namensbereich reserviert sind:

Namen die mit einem Unterstrich beginnen

(und im namespace std)

Interessanterweise steht das im Standard nicht so, dort wird ausdrücklich der globale Namensbereich genannt. Das bedeutet wohl, dass in std nur die Namen mit doppeltem Unterstrich und die Namen mit Unterstrich und Großbuchstaben reserviert sind.

17.4.3.1 Abs. 1 S. 1

pumuckl

camper schrieb:

SeppJ schrieb:

pumuckl schrieb:

[...](und im namespace std)

Interessanterweise steht das im Standard nicht so, dort wird ausdrücklich der globale Namensbereich genannt. Das bedeutet wohl, dass in std nur die Namen mit doppeltem Unterstrich und die Namen mit Unterstrich und Großbuchstaben reserviert sind.

17.4.3.1 Abs. 1 S. 1

In der Version die mir vorliegt ist am 17.4.3.1.2, zweiter Spiegelstrich eine Fußnote 165, die besagt dass das auch für den NS std gilt, mit Verweis auf 17.4.3.1

§17.4.3.1, Abs.3 besagt "if the program deklares [...] a name in a context where it is reserved, [...] the behavior is undefined."

Die Frage ist jetzt, ob ein Programm dann ggf. von der Implementierung bereitgestellte Namen im Namensraum std überhaupt benutzen darf oder ob das auch schon undefined behavior ist.

bsp:

#include <somestdheader> //definiert void std::_somestdfunc()

void std::_somestdfunc(); //Kein Verstoss gegen 17.4.3.1, abs 1., da keine Deklaration HUNZUGEFUEGT wird. Aber vllt. gegen die Fussnote 165?

int main()
{
#ifdef _MY_COMPILER_THAT_DEFINES_SOMESTD_FUNC_IN_SOMESDT_HEADER_
  std::_somestdfunc(); // undefined behavior??
#endif
}

camper

pumuckl schrieb:

Die Frage ist jetzt, ob ein Programm dann ggf. von der Implementierung bereitgestellte Namen im Namensraum std überhaupt benutzen darf oder ob das auch schon undefined behavior ist.

Das ist aus sich heraus klar. Da der betreffende Bezeichner überhaupt erst durch die Implementation eingeführt wird, kann der Standard schlecht eine Aussage über das Verhalten machen. Ergo ist das Verhalten undefiniert.

unskilled

camper schrieb:

pumuckl schrieb:

Die Frage ist jetzt, ob ein Programm dann ggf. von der Implementierung bereitgestellte Namen im Namensraum std überhaupt benutzen darf oder ob das auch schon undefined behavior ist.

Das ist aus sich heraus klar. Da der betreffende Bezeichner überhaupt erst durch die Implementation eingeführt wird, kann der Standard schlecht eine Aussage über das Verhalten machen. Ergo ist das Verhalten undefiniert.

nicht impl. defined?

camper

unskilled schrieb:

nicht impl. defined?

Muss die Implementation ihre eigenen Innereien dokumentieren? Ich glaube nicht.

Impl. defined ist etwas, dessen Existenz der Standard voraussetzt, und für das die Implementation ein bestimmtes dokumentiertes Verhalten haben muss. Beide Voraussetzungen sind für etwaige reservierte Bezeichner nicht erfüllt.