template <typename Tsizetype, Tsizetype line_count, Tsizetype row_count, typename Tvaluetype>
class TMatrix
{
public:
	typedef Tvaluetype				ValueType;
	typedef Tsizetype				SizeType;

	static const SizeType			m		= row_count;
	static const SizeType			n		= line_count;

	class Line
	{
	private:
		ValueType *values;
		Line& operator = (const Line& rhs);
		Line (const Line& rhs);
	public:
		Line()
			:	values(new ValueType[row_count])
		{}

		void swap(Line &lhs, Line &rhs)
		{
			std::swap (lhs.values, rhs.values);
		}

		~Line()
		{
			delete []values;
		}

		ValueType& operator[] (Tsizetype i)
		{
			assert (i < row_count);
			return (values[i]);
		}

		const ValueType& operator[] (Tsizetype i) const
		{
			assert (i < row_count);
			return (values[i]);
		}

	};

private:
	Line *lines;
	TMatrix (const TMatrix &);
	TMatrix& operator = (const TMatrix &);
public:
	Line& operator[] (Tsizetype i)
	{
		assert (i < line_count);
		return (lines[i]);
	}

	const Line& operator[] (Tsizetype i) const
	{
		assert (i < line_count);
		return (lines[i]);
	}

	TMatrix()
		:	lines(new Line[line_count])
	{}

	~TMatrix()
	{
		delete []lines;
	}
};

und eine Funktion die mein Compiler leider nicht ganz überblicken kann (er ignoriert die untere Grenze wie auch an der Fehlermeldung ganz unten erkennbar wird:

template <typename Treturnvaluetype, typename Tsizetype, Tsizetype dim, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace (const TMatrix <Tsizetype, dim, dim, Tvaluetype> &thismatrix)
{
	if (dim >= 3)
	{
		Treturnvaluetype sum = Treturnvaluetype();
		const Tsizetype nextdim (dim-1);

		typedef TMatrix <Tsizetype, dim, dim, Tvaluetype> TThisMatrix;
		typedef TMatrix <Tsizetype, nextdim, nextdim, Tvaluetype> TNextMatrix;

		TNextMatrix nextmatrix;

		for (Tsizetype m = Tsizetype(); m != nextdim; ++m)
		{
			for (Tsizetype n = Tsizetype(); n != nextdim; ++n)
			{
				TNextMatrix::Line &line_to = nextmatrix[n];
				const TThisMatrix::Line &line_from = thismatrix[n+1];

				for (Tsizetype i = Tsizetype(); i != n; ++i)
				{
					line_to[i] = line_from[i];
				}
				for (Tsizetype i (n); i != nextdim; ++i)
				{
					line_to[i] = line_from[i+1];
				}
			}
			sum += thismatrix[0][m] * Determinant_LaPlace <Treturnvaluetype> (nextmatrix);
		}
		return sum;
	}
	else if (dim == 2)
	{
		return Treturnvaluetype(thismatrix[0][0] * thismatrix[1][1] - thismatrix[0][1] * thismatrix[1][0]);
	}
	else
	{
		throw std::invalid_argument ("Dimension needs to be bigger then one");
	}
}

Die Fehlermeldung:

1>------ Build started: Project: test, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>f:\c\libs\math\matrix.hpp(85) : error C2148: total size of array must not exceed 0x7fffffff bytes
1>        f:\c\libs\math\matrix.hpp(85) : while compiling class template member function 'my::TMatrix<Tsizetype,line_count,row_count,Tvaluetype>::TMatrix(void)'
1>        with
1>        [
1>            Tsizetype=size_t,
1>            line_count=-1,
1>            row_count=-1,
1>            Tvaluetype=char
1>        ]
1>        f:\c\libs\math\matrix.hpp(330) : see reference to class template instantiation 'my::TMatrix<Tsizetype,line_count,row_count,Tvaluetype>' being compiled
1>        with
1>        [
1>            Tsizetype=size_t,
1>            line_count=-1,
1>            row_count=-1,
1>            Tvaluetype=char
1>        ]
1>        f:\c\libs\math\matrix.hpp(348) : see reference to function template instantiation 'Treturnvaluetype my::math::Determinant_LaPlace<Treturnvaluetype,Tsizetype,0,Tvaluetype>(const my::TMatrix<Tsizetype,line_count,row_count,Tvaluetype> &)' being compiled
1>        with
1>        [
1>            Treturnvaluetype=float,
1>            Tsizetype=size_t,
1>            Tvaluetype=char,
1>            line_count=0,
1>            row_count=0
1>        ]
1>        f:\c\libs\math\matrix.hpp(348) : see reference to function template instantiation 'Treturnvaluetype my::math::Determinant_LaPlace<Treturnvaluetype,Tsizetype,1,Tvaluetype>(const my::TMatrix<Tsizetype,line_count,row_count,Tvaluetype> &)' being compiled
1>        with
1>        [
1>            Treturnvaluetype=float,
1>            Tsizetype=size_t,
1>            Tvaluetype=char,
1>            line_count=1,
1>            row_count=1
1>        ]
1>        c:\users\tommy\documents\visual studio 2008\projects\test\test\main.cpp(13) : see reference to function template instantiation 'Treturnvaluetype my::math::Determinant_LaPlace<float,size_t,2,char>(const my::TMatrix<Tsizetype,line_count,row_count,Tvaluetype> &)' being compiled
1>        with
1>        [
1>            Treturnvaluetype=float,
1>            Tsizetype=size_t,
1>            line_count=2,
1>            row_count=2,
1>            Tvaluetype=char
1>        ]
1>f:\c\libs\math\matrix.hpp(85) : warning C4307: '*' : integral constant overflow
1>f:\c\libs\math\matrix.hpp(85) : warning C4307: '+' : integral constant overflow
1>f:\c\libs\math\matrix.hpp(85) : error C2148: total size of array must not exceed 0x7fffffff bytes
1>Build log was saved at "file://c:\Users\Tommy\Documents\Visual Studio 2008\Projects\test\test\Debug\BuildLog.htm"
1>test - 2 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Der Code der diesen Fehler erzeugt hat sieht so aus:

my::TMatrix <size_t, 2, 2, char> eins;
eins[0][0] = 2;
eins[0][1] = 0;
eins[1][1] = 1;

float det = my::math::Determinant_LaPlace <float> (eins);

Wie bekomm ich es hin, dass mein Compiler merkt, dass er das template nicht für eine negative anzahl an zeilen/spalten erzeugen soll?
Oder geht das nicht mal eben mit ner anderen Schreibweise?

Würder ihr die Dimensionen überhaupt über Templates lösen oder etwa erst zur Laufzeit ermitteln (was ja Probleme bei sämtlichen Operatoren mit sich bringen würde: Bsp.: Addition 2er Matrizen, Determinante, Vergleiche, ...)

Danke schon mal : >

PS: Bitte keine Vorschläge statt des Pointers einen STL-Container oder ein Array auf dem Stack zu nehmen (was ja das Problem auch nicht behebt) - da die Stack-Größe eines Prozesses sehr stark (zumindest im Vergleich zum Heap) begrentzt ist, möchte ich mir dadurch keine Obergrenze setzen - so weit ich weiß speichert auch std::tr1::array seinen Inhalt auf dem Stack, oder?

template <typename Treturnvaluetype, std::size_t dim, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace (const TMatrix <dim, dim, Tvaluetype> &thismatrix)
{
    Treturnvaluetype sum = Treturnvaluetype();
    const std::size_t nextdim (dim-1);

    typedef TMatrix <dim, dim, Tvaluetype> TThisMatrix;
    typedef TMatrix <nextdim, nextdim, Tvaluetype> TNextMatrix;

    TNextMatrix nextmatrix;

    for (Tsizetype m = Tsizetype(); m != nextdim; ++m)
    {
        for (Tsizetype n = Tsizetype(); n != nextdim; ++n)
        {
            TNextMatrix::Line &line_to = nextmatrix[n];
            const TThisMatrix::Line &line_from = thismatrix[n+1];

            for (Tsizetype i = Tsizetype(); i != n; ++i)
            {
                line_to[i] = line_from[i];
            }
            for (Tsizetype i (n); i != nextdim; ++i)
            {
                line_to[i] = line_from[i+1];
            }
        }
        sum += thismatrix[0][m] * Determinant_LaPlace <Treturnvaluetype> (nextmatrix);
    }

    return sum;
}

// Und jetzt Spezialisierungen:
template <typename Treturnvaluetype, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace<Treturnvaluetype, 2, Tvaluetype> (const TMatrix <2, 2, Tvaluetype> &thismatrix)
{
    return Treturnvaluetype(thismatrix[0][0] * thismatrix[1][1] - thismatrix[0][1] * thismatrix[1][0]);
}

template<typename Treturnvaluetype, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace<Treturnvaluetype, 1, Tvaluetype> (const TMatrix <1, 1, Tvaluetype> &thismatrix)
{
    throw std::invalid_argument ("Dimension needs to be bigger then one");
    // Könnte man natürlich auch ein static_assert(false) machen ;)
}

template<typename Treturnvaluetype, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace<Treturnvaluetype, 0, Tvaluetype> (const TMatrix <0, 0, Tvaluetype> &thismatrix)
{
    throw std::invalid_argument ("Dimension needs to be bigger then one");
    // Könnte man natürlich auch ein static_assert(false) machen ;)
}

Man, hast du eine hässliche schreibweise ...
Übrigens, was soll dieses Tsizetype ? Habe das gleich mal rausgenommen, ist doch völlig überflüssig. Nimm gleich einen std::size_t , man hat ja keinen Vorteil, wenn man das immer selber angeben muss.

Kurz vielleicht noch zusammengefasst, was ich getan habe und wieso:
Ich habe deine if-else if-else Anweisung auseinander genommen. Templates haben etwas blödes an sich, sie werden immer instanziert, auch wenn man sie vielleicht gar nicht braucht. Also obwohl dim < 3 gewesen ist, so wurde trotzdem die Matrix mit der Dimension dim - 1 instanziert. Bei dim == 0, bekommen wir ein dim - 1 = -1, was natürlich zu einem Fehler beim Array führt. Um sowas zu verhindern, muss man eben Spezialisierungen einführen. Diese Spezialisierungen halten den rekursiven Fortschritt der Templates auf. So lassen sich mit den Templates übrigens auch Schleifen erzeugen

Habe den Code selber nicht getestet und bin auch etwas müde, daher könnte sich gut ein Fehler eingeschlichen haben. Aber ich hoffe die Fehlerbegründung kam an und du hast es verstanden.

Grüssli

bye

char arr[xxxx];
sizeof(arr); // <- gibt einen std::size_t zurück,
             //    die Zahl xxxx muss also in einen std::size_t reinpassen.

Und wie du auch selbst sagst, eine Matrix der Grösse 2^32-1 dürfte ein wenig gross sein
Du machst mit dem zusätzlichen Templateparameter dem Nutzer einfach zusätzliche Arbeit.

Grüssli

edit: Der Vollständigkeit halber hier mal die richtige Version (die von oben war ein wenig sehr fehlerbehaftet, aber naja )

template <typename Treturnvaluetype, size_t dim, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace (const TMatrix <dim, dim, Tvaluetype> &thismatrix)
{
	Treturnvaluetype sum = Treturnvaluetype();
	typedef TMatrix <dim, dim, Tvaluetype>	TThisMatrix;
	typedef typename TThisMatrix::SizeType	SizeType;
	const SizeType nextdim (dim-1);
	typedef TMatrix <nextdim, nextdim, Tvaluetype> TNextMatrix;

	TNextMatrix nextmatrix;

	for (SizeType m = SizeType(); m != dim; ++m)
	{
		for (SizeType n = SizeType(); n != nextdim; ++n)
		{
			TNextMatrix::Line &line_to = nextmatrix[n];
			const TThisMatrix::Line &line_from = thismatrix[n+1];

			for (SizeType i = SizeType(); i != m; ++i)
			{
				line_to[i] = line_from[i];
			}
			for (SizeType i (m); i != nextdim; ++i)
			{
				line_to[i] = line_from[i+1];
			}
		}
		if (m%2)
			sum -= thismatrix[0][m] * Determinant_LaPlace <Treturnvaluetype> (nextmatrix);
		else
			sum += thismatrix[0][m] * Determinant_LaPlace <Treturnvaluetype> (nextmatrix);
	}
	return sum;
}

a) Es gibt die Determinante einer 1x1-Matrix, nämlich das einzelne Element selbst. Also nix invalid_argument.

Japp, hab ich (jz) auch so

geloescht schrieb:

Ich würde durchaus statische Arrays einsetzen, du kannst ja eine Instanz der Klasse auf dem Heap erstellen, dann ist der Stack garnicht bis kaum gewachsen. Mit smart pointern ist die Speicherverwaltung keine große Sache. Also auch keine Obergrenze dadurch. Aber ist nicht zwingend notwendig, ich bin mir sicher, dass es bezogen auf Speicher und Geschwindigkeit sowohl Vorteile als auch Nachteile gibt. Z.B. macht shared_ptr eingesparte dynamische Allokationen wieder zunichte. Für jede Zeile eine dynamische Allokation zu machen ist aber unnötig, du kannst alles am Block allozieren!

Ich alloziere alles im Block - und mach danach nen placement new auf den Eintrag um ihn mit 0 oder was auch immer zu initialisieren

geloescht schrieb:

Für riesige Matrizen ist diese Klasse sowieso nicht geeignet, das hätte gigantischen Speicherverbrauch zur Folge. Dafür gibt es spezielle Implementationen für große Matrizen mit vielen Nullen oder gleichen Elementen usw. Schau dir einfach mal boost::ublas an.

Diese Klasse soll aber nicht für schwach besetzte Matrizen sein - sonst hätte ich sie kaum TMatrix genannt sondern iwie vermerkt, dass sie besser mit schwach besetzten Matrizen umgehen kann als mit voll besetzten...

Noch mal dazu:

Mit smart pointern ist die Speicherverwaltung keine große Sache

mit new und delete ja auch nicht, weil ich einmal den Speicher alloziere und einmal lösche - dann ist es noch in der copy-Fkt ein bisschen mehr Arbeit, aber alles in allem sind es vll 10 Zeilen die ich mir dadurch sparen könnte - Vorteile sehe ich davon aber keine - Nachteile würden mir aber ein paar einfallen - angefangen damit, dass ich nicht so schön mit dem Inhalt spielen kann, wie ich es mit den rohen Arrays tun kann ^^

bb

Wieso verwendest du eigentlich kein std::tr1::array (oder bei fehlender TR1-Unterstützung boost::array )?

unskilled schrieb:

so weit ich weiß speichert auch std::tr1::array seinen Inhalt auf dem Stack, oder?

Da std::tr1::array meines Erachtens nach auf dem Stack operiert (was zwar schneller ist aber der ist eben auch sehr begrentzt...)
Außerdem glaube ich nicht, dass ich mit std::tr1::array so gut arbeiten kann, wie bis jetzt:

Line(ValueType fill_with = ValueType())
	:	values(new ValueType[row_count])
{
	for(SizeType i = SizeType(); i != row_count; ++i)
	{
		new (values + i) ValueType(fill_with);
	}
}

//bzw.

TMatrix(ValueType fill_with = ValueType())
	:	lines ((Line*) new char[sizeof(Line) * line_count])
{
	for(SizeType i = SizeType(); i != line_count; ++i)
	{
		new (lines + i) Line(fill_with);
	}
}

Und da es so auch geht und ich nicht weiß, ob (wenn ja, wie) es mit std::tr1::array geht, habe ich eben diese Lösung gewählt ^^ Oder ist gegen diese Variante irgendetwas zu sagen?

bb

unskilled schrieb:

Oder ist gegen diese Variante irgendetwas zu sagen?

Findest du das schön?

lines ((Line*) new char[sizeof(Line) * line_count])

Ja, std::tr1::array ist ein einfacher Wrapper für C-Arrays, der noch weitere Funktionalität bereitstellt

Gut - ich hatte daran gezweifelt, dass er auch bei großen Größen auf dem Stack bleibt (hätte ja sein können, dass es je nach Größe spezialisiert ist)...

Nexus schrieb:

Findest du das schön?

lines ((Line*) new char[sizeof(Line) * line_count])

Hältst du es für umgänglich? (extrem hübsch finde ich es zwar nicht aber ich hab keinen anderen Weg gefunden und außer den optischen Nachteil ist mir keiner aufgefallen - und wenn an mal 5 Sekunden Zeit investiert erkennt man auch als Außenstehender, was man dort macht)

bb

template <int size>
struct giant
{
  char bar[size];
};

int main()
{
  //Das da braucht gerademal nen Pointer auf dem Stack
  giant* A = new giant<1000>();
  //Das da braucht womöglich 1kB auf dem Stack
  giant B<1000>;
}

Über die Grenzen des Stacks brauchst du dir wohl erst Gedanken machen, wenn du auf sie stößt.
:xmas2:

Nexus schrieb:

Findest du das schön?

lines ((Line*) new char[sizeof(Line) * line_count])

Hältst du es für umgänglich? (extrem hübsch finde ich es zwar nicht aber ich hab keinen anderen Weg gefunden und außer den optischen Nachteil ist mir keiner aufgefallen - und wenn an mal 5 Sekunden Zeit investiert erkennt man auch als Außenstehender, was man dort macht)

Aber was war dann mit deiner vorherigen Lösung?

lines(new Line[line_count])

geloescht schrieb:

Du könntest eine Instanz von std::tr1::array immernoch auf dem Heap erstellen! Plus es ist leicht damit umzugehen plus es ist schnell plus es spart Speicherplatz ggü. einem std::vector plus es ist einfach kopierbar.

Die Schnelligkeit, die aufgrund der Stack-Allokation gewonnen wird, geht hier auch wieder verloren. Ein std::tr1::array auf dem Heap dürfte etwa gleich schnell sein wie ein std::vector . Und der verschwendete Speicherplatz sollte eigentlich auch nicht gross ins Gewicht fallen. Aber darüber sollte man sich sowieso erst Gedanken machen, wenn es erforderlich ist...

Im Gegenzug nimmt man mit einem dynamisch allokierten std::tr1::array manuelle Speicherverwaltung und die damit verbundenen Probleme in Kauf. Ich selbst würde std::tr1::array wirklich nur für statische Arrays verwenden.

unskilled schrieb:

Nexus schrieb:

Aber was war dann mit deiner vorherigen Lösung?

lines(new Line[line_count])

(boar - was ne Arbeit das alles fertig auszuzitieren ^^)
Hmm... Ist natürlich ne sehr gute Frage, wieso ich das gemacht habe - eigtl weil ich es für nötig hielt - allerdings kann ich dir weder sagen, warum ich das getan habe, noch hab ich jetzt beim Ändern auf die schönere Variante Fehlermeldungen erhalten.

Nur einwas ist sehr komisch:
main

{ //~0 KB
	my::TMatrix <1000, 1000, double> eins(23); //~n KB
} //~n/2 KB

(ich weiß, das OS nimmt nicht sofort wieder allen Speicher zurück etc - aber bei jeder Größe hat mein Programm nach dem Ende des Scopes immer noch die Hälfte des RAMs (priv. Arbeitssatz) wie im Scope...

counter

namespace my
{
	size_t v (0);
	size_t l (0);
	size_t v2 (0);
}

vor dem erstellen:
0
0
0

nach dem erstellen:
2000
1
1000

nach dem zerstören:
1000
0
0

//matrix -> matrix

TMatrix(ValueType fill_with = ValueType())
	:	lines (new Line[line_count])
{
	++::my::l;
	for(SizeType i = SizeType(); i != line_count; ++i)
	{
		new (lines + i) Line(fill_with);
	}
	::my::v2 += line_count;
}

~TMatrix()
{
	--::my::l;
	::my::v2 -= line_count;
	delete [] lines;
}

matrix -> line

Line(ValueType fill_with = ValueType())
	:	values(new ValueType[row_count])
{
	++::my::v;
	for(SizeType i = SizeType(); i != row_count; ++i)
	{
		new (values + i) ValueType(fill_with);
	}
}
~Line()
{
	--::my::v;
	delete []values;
}

Nun erscheint mir ein nach char* casten im ctor doch wieder sinnvoll - allerdings wird dann der dtor ja trotzdem nicht aufgerufen - geht ein placement new überhaupt auf eine struktur, die selbst im ctor werte initialisiert? Oder gibts zum placement new irgend nen Gegenstück, was ich kennen sollte?

Danke schon mal - bb

1. Ist die Variante mit dem new char... nicht nur unschön, sie müsste sogar wenn mans genau nimmt noch unschöner sein - aus C-Cast mach reinterpret_cast
2. ist die Variante dann nicht nur noch unschöner, sondern es müsste eigentlich, getriggert durch den reinterpret_cast auf ein Array, folgendes passieren: sämtliche Alamrglocken schrillen und es blinkt ein großes, grelles Schild mit der Aufschrift "alignment/padding?!"
3. Die neue Variante ist zwar schöner anzusehn, aber nicht exception-safe (falls das für dich von Bedeutung ist): Wenn irgendwo im Rest der init-Liste eine Exception hochkommt dann hat das Objekt selbst nie existiert, weil nie alle Member initialisiert wurden, und alles was bleibt nachdem die bereits initialisierten Objekte abgeräumt wurden ist ein Speicherleck. Also kein new in Init-Listen, wenn man Exception safe bleiben möchte (es sei denn man initialisiert damit einen Smartpointer, dessen entsprechender Konstruktor unter Garantie keine Exceptions wirft.)

1. Ist die Variante mit dem new char... nicht nur unschön, sie müsste sogar wenn mans genau nimmt noch unschöner sein - aus C-Cast mach reinterpret_cast

Jopp - das wärs schon noch geworden, aber wollte ja erst mal wissen, ob es von der theorie so richtig wäre

pumuckl schrieb:

2. ist die Variante dann nicht nur noch unschöner, sondern es müsste eigentlich, getriggert durch den reinterpret_cast auf ein Array, folgendes passieren: sämtliche Alamrglocken schrillen und es blinkt ein großes, grelles Schild mit der Aufschrift "alignment/padding?!"

Oh - daran hatte ich wirklich nicht gedacht - aber habs ja jz auch wieder mit nem "sauberen" new und placement new - aber das speicherleck bleibt bestehen - und ich weiß nicht, warum -.-

pumuckl schrieb:

3. Die neue Variante ist zwar schöner anzusehn, aber nicht exception-safe (falls das für dich von Bedeutung ist): Wenn irgendwo im Rest der init-Liste eine Exception hochkommt dann hat das Objekt selbst nie existiert, weil nie alle Member initialisiert wurden, und alles was bleibt nachdem die bereits initialisierten Objekte abgeräumt wurden ist ein Speicherleck. Also kein new in Init-Listen, wenn man Exception safe bleiben möchte (es sei denn man initialisiert damit einen Smartpointer, dessen entsprechender Konstruktor unter Garantie keine Exceptions wirft.)

Also pack ich nen try / catch um die schleife und fange bad_alloc auf - und falls es geworfen wurde, führe ich den dtor aus und werfe die exception einfach ganz normal weiter?!

bb

edit: Also vll weiß ichs auch einfach nicht, aber ich glaube das normale new darf gar kein new auf Line sein sondern _muss_ auf nen intergralen Typen sein?!
Meine Lösung sieht jetzt folgendermaßen aus
(ich weiß nicht, ob man den exception-safe ctor normalerweise ähnlich implementiert aber ich hab anscheind noch irgendwo nen fehler drin - jedenfalls gibt er bei nem bad_alloc anscheind nicht wieder alles frei ><

Minimal-Code (fertig für copy&paste ^^):

template <size_t line_count, size_t row_count, typename ValueType>
class TMatrix
{
public:
	typedef size_t					SizeType;

	class Line
	{
	private:
		ValueType *values;

		void destruct(SizeType i = row_count) throw()
		{
			if(!values)
				return;

			for(; i != 0; --i)
			{
				values[i-1].~ValueType();
			}
			delete [] values;
			values = nullptr;
		}
	public:
		Line(ValueType fill_with = ValueType())
			:	values(new ValueType[row_count])
		{
			SizeType i = SizeType();
			try
			{
				for(; i != row_count; ++i)
				{
					new (values + i) ValueType(fill_with);
				}
			}
			catch (...)
			{
				destruct(i);
				throw;
			}
		}

		~Line()
		{
			destruct();
		}
	};

private:
	Line *lines;

	void destruct(SizeType i = line_count) throw()
	{
		if(!lines)
			return;

		for(; i != 0; --i)
		{
			lines[i-1].~Line();
		}
		delete [] reinterpret_cast <char*> (lines);
		lines = nullptr;
	}

public:
	TMatrix(ValueType fill_with = ValueType())
		:	lines ( reinterpret_cast <Line*> (new char[sizeof(Line) * line_count]) )
	{
		SizeType i = SizeType();
		try
		{
			for(; i != line_count; ++i)
			{
				new (lines + i) Line(fill_with);
			}
		}
		catch(...)
		{
			destruct(i);
			throw;
		}
	}

	~TMatrix()
	{
		destruct();
	}
};

Nun könnte man aus destruct noch nen template machen und wahrscheinlich auch noch nen template für init oder so - aber im Grunde genommen sollte es doch so (oder ähnlich) gehen, oder?

Zu Alignment/Padding: Sicher, dass das hier eine Rolle spielt?

bb und danke schon mal fürs angucken?! : >

// Und jetzt Spezialisierungen:
template <typename Treturnvaluetype, typename Tvaluetype>
Treturnvaluetype Determinant_LaPlace<Treturnvaluetype, 2, Tvaluetype> (const TMatrix <2, 2, Tvaluetype> &thismatrix)
{
    return Treturnvaluetype(thismatrix[0][0] * thismatrix[1][1] - thismatrix[0][1] * thismatrix[1][0]);
}
// ...

Leider sind partielle Spezialisierungen von Funktionstemplates nicht erlaubt, oder kompiliert das dein Compiler ?

Leider sind partielle Spezialisierungen von Funktionstemplates nicht erlaubt, oder kompiliert das dein Compiler ?

Jap, tut er. Zwar habe ich jetzt nicht genau das gemacht, aber habe ein foo-Test gemacht:

#include "Test.hpp"

#include <iostream>

template<typename T>
void foo()
{
	std::cout << "T!" << std::endl;
}

template<>
void foo<void>()
{
	std::cout << "void" << std::endl;
}

int main()
{
	foo<int>();
	foo<void>();

	test::wait("Press ENTER to exit...");

	return 0;
}

Mir persönlich ist der genaue Standard dazu nicht bekannt. Verwende den MSVC 2005.

Aber was soll, dann nimmt man statt Templatespezialisierung Funktionsüberladung. Sollte genauso gehen.

Grüssli

Das entscheidende war, dass du dort eben partielle Spezialisierung benutzt hast. Komplette Spezialisierung ist erlaubt, partielle eben nicht..

Achso ... *Kopf -> Tisch*
Das kommt ja auch erst mit dem nächsten Standard

Naja, aber in diesem Fall sollten Funktionsüberladungen Abhilfe schaffen.

Grüssli

Das kommt ja auch erst mit dem nächsten Standard

Sind in C++0x partielle Spezialisierungen von Funktionen möglich? Was war der Grund, sie bisher nicht einzuführen?

Dravere schrieb:

*Kopf -> Tisch*

Hehe, als ich das zuerst gesehen habe, dachte ich, es handle sich um eine Dereferenzierung. Dann hat mich verwirrt, dass bei "Tisch" das * nach dem Bezeichner steht... Vielleicht sollte ich langsam ins Bett...

drakon schrieb:

Das entscheidende war, dass du dort eben partielle Spezialisierung benutzt hast. Komplette Spezialisierung ist erlaubt, partielle eben nicht..

Achso ... *Kopf -> Tisch*
Das kommt ja auch erst mit dem nächsten Standard

Naja, aber in diesem Fall sollten Funktionsüberladungen Abhilfe schaffen.

Grüssli

Hehe..

Wenn wir schon bei dabei sind..

Das dürfte für dich interessant sein (warst doch du,der Probleme hatte, oder?:))
http://developer.amd.com/documentation/videos/pages/IntroductiontoAMDCodeAnalystPerformanceAnalyzer.aspx

(Achtung lautes Video.. -.-)

Dravere schrieb:

Das kommt ja auch erst mit dem nächsten Standard

Sind in C++0x partielle Spezialisierungen von Funktionen möglich? Was war der Grund, sie bisher nicht einzuführen?

Ich dachte ich hätte mal sowas gehört. Aber kann es grad nicht finden im letzten Draft. Aber das Zeug finde ich teilweise sowieso etwas komplex beschrieben
Oder ich bin einfach zu müde und zu viel gelernt heute, vielleicht bring ich ein paar Dinge grad völlig durcheinander

Grüssli

Ich habe jz folgenden Code:
Aber anscheind wird im nicht-bad_alloc-Fall nicht der komplette Speicher freigegeben (ein vergleichsmäßig kleiner Teil wird "vergessen", glaube ich) und ohne den cast auf char* hab ichs gar nicht hinbekommen - womit die Probleme mit Padding bleiben - die ich aber zumindest mit den aktuell verwendeten Datentypen umgehe (Pointer bzw double sollten ja von der größe her beide gut geeignet sein)

Helfer für CTor (placement new) und DTor (expliziter DTor-Aufruf + delete)

template <typename T>
void destruct(T * &array_values, size_t count) throw()
{
	if(!array_values)
		return;

	for(SizeType i = SizeType(); i != count; ++i)
	{
		T *tmp = array_values + i;
		if (tmp)
			tmp->~T();
	}

	delete [] reinterpret_cast <char*> (array_values);
	array_values = nullptr;
}

template <typename T, SizeType, typename TCtorArg>
void init(T * &array_values, size_t count, const TCtorArg &ctor_argument = TCtorArg())
{
	try
	{
		array_values = reinterpret_cast <T*> ( new char[sizeof(T) * count] );
	}
	catch (...)
	{
		array_values = nullptr;
		throw;
	}

	for(SizeType i = SizeType(); i != count; ++i)
	{
		try
		{
			new (array_values + i) T(ctor_argument);
		}
		catch (...)
		{
			destruct(array_values, i);
			throw;
		}
	}
}

die ich wie folg verwendet habe:

Line(ValueType fill_with = ValueType())
{
	try
	{
		alloc::placement_new::init(values, row_count, fill_with);
	}
	catch (...)
	{
		alloc::placement_new::destruct(values, row_count);
		throw;
	}
}

~Line() throw()
{
	alloc::placement_new::destruct(values, row_count);
}

TMatrix(ValueType fill_with = ValueType())
{
	try
	{
		alloc::placement_new::init(lines, line_count, fill_with);
	}
	catch (...)
	{
		alloc::placement_new::destruct(lines, line_count);
		throw;
	}
}

~TMatrix() throw()
{
	alloc::placement_new::destruct(lines, line_count);
}

Ich wäre über eine Reaktion sehr erfreut ^^

bb

class B
{
  A* aptr;
  C  c;

public:
  B() : aptr(new A()), c() 
  {}
};

Wenn jetzt z.B. der Konstruktor von c eine Exception auslöst, dann geschieht folgendes:
- alle bis dahin initialisierten Member von B werden zerstört. Da aptr ein POD ist und keinen Dtor hat wirds einfach gelöscht. Speicherleck geschaffen
- Da der Ctor von B nicht vollständig ausgeführt worden ist, hat das B-Objekt nie exisitiert, also wird auch kein Dtor für B aufgerufen. Speicherleck lebt weiter.
- da das B-Objekt nie existiert hat, kann auch von außen niemand den für aptr allokierten Speicher freigeben. Das Speicherleck bleibt also und ist nicht mehr zu retten.

Meine Aussage war also lediglich, dass die Aufrufe von new() in der Init-Liste eines Ctors für einfache Pointer nicht exceptionsicher sind.
Folgende Möglichkeiten gibts:

class B1
{
  A* aptr;
  C  c;

public:
  B1() : aptr(0), c() 
  {
    try {
     aptr = new a(); 
    }
    catch(...)
    { /* delete alle pointer */ }
  }
};

class B2
{
  shared_ptr<A> aptr;
  C  c;

public:
  B2() : aptr(new A()), c() 
  {}
};

Bei Variante 1 kann man das try/catch weglassen, wenns nur einen Pointer in der Klasse gibt der so initialisiert wird. Bei einem fehlschlagenden new wid der allokierte Speicher immer freigegeben. Ab zwei Pointern muss aber try/catch eingebaut werden: wenn das zweite new eine exception wirft muss der erste seinen Speicher freigeben.
Variante 2 geht deshalb, weil der smart-pointer den allokierten speicher wieder freigibt, wenn im Laufe der Konstruktion von B2 eine exception fliegt.