4. Datenstruktur für Matrizen

Datenstruktur für Matrizen

  • R
    Mod

    Pyr0kar schrieb:

    Darf man mal fragen ob ihr auch Color<N> oder sogar Color<T, N> habt ? 😉

    wieso nicht vector<T> dafuer nehmen?

    0
  • T

    Ja, ich habe für Farben ebenfalls das Vektor-Template genommen. Das war mitunter auch der Grund, warum ich das Template überhaupt erstellt habe - 2D-Vektoren für Texturkoordinaten, 3D für 3D halt 😉 und 4D u.a. für RGBA.

    0
  • P

    rapso schrieb:

    Pyr0kar schrieb:

    Darf man mal fragen ob ihr auch Color<N> oder sogar Color<T, N> habt ? 😉

    wieso nicht vector<T> dafuer nehmen?

    Ganz einfach, weil man bei einer eigenen Klasse so schöne dinge machen kann wie:

    static const Color3 White = Color3(255, 255, 255);
static const Color3 Red= Color3(255, 0, 0);

    Bei XNA haben sie das auch, schreibt sich eigentlich dann ganz nett.
    Außerdem weiß man damit deutlicher dass es ein Farbwert ist.
    Niemand wird außerversehen eine Position als Farbwert behandeln u. andersrum 😉

    Oder eben 1, 1, 1 und 1, 0, 0 für die Werte - je nach Speicherung.
    Nebenbei: sollte man lieber chars zur speicherung benutzten um dann weiß als 255,255,255 darzustellen oder lieber floats die von 0 bis 1 reichen was ja opengl etc. dann annnimmt?

    0
  • R
    Mod

    Pyr0kar schrieb:

    rapso schrieb:

    Pyr0kar schrieb:

    Darf man mal fragen ob ihr auch Color<N> oder sogar Color<T, N> habt ? 😉

    wieso nicht vector<T> dafuer nehmen?

    Ganz einfach, weil man bei einer eigenen Klasse so schöne dinge machen kann wie:

    static const Color3 White = Color3(255, 255, 255);
static const Color3 Red= Color3(255, 0, 0);

    was sollen diese zwei zeilen beweisen?

    Bei XNA haben sie das auch, schreibt sich eigentlich dann ganz nett.
    Außerdem weiß man damit deutlicher dass es ein Farbwert ist.

    hoe? was soll das aussagen? wo ist der unterschied zu

    typedef Vector<float,3> tyColor3;
static const tdColor3 White(255, 255, 255);
static const tdColor3 Red(255, 0, 0);

    ?

    Niemand wird außerversehen eine Position als Farbwert behandeln u. andersrum 😉

    der zusammenhang entgeht mir.

    Oder eben 1, 1, 1 und 1, 0, 0 für die Werte - je nach Speicherung.
    Nebenbei: sollte man lieber chars zur speicherung benutzten um dann weiß als 255,255,255 darzustellen oder lieber floats die von 0 bis 1 reichen was ja opengl etc. dann annnimmt?

    je nachdem ob du HDR unterstuetzung brauchst oder nicht.
    gibt ja viele wege nach rom, z.b.

    typedef Vector<Sat<float,0.f,1.f>,3> tyColor3;

    btw. opengl limitiert nicht auf 0 bis 1

    0
  • P

    rapso schrieb:

    Pyr0kar schrieb:

    rapso schrieb:

    Pyr0kar schrieb:

    Darf man mal fragen ob ihr auch Color<N> oder sogar Color<T, N> habt ? 😉

    wieso nicht vector<T> dafuer nehmen?

    Ganz einfach, weil man bei einer eigenen Klasse so schöne dinge machen kann wie:

    static const Color3 White = Color3(255, 255, 255);
static const Color3 Red= Color3(255, 0, 0);

    was sollen diese zwei zeilen beweisen?

    Mir fällt leider jetzt erst auf dass die zwei Codezeilen wirklich nicht zeigen was ich meinte 😉 ^^
    Ich wollte eigentlich ausdrücken dass man das ganze der Klasse als Membervariable einbauen kann.
    So dass dann möglich ist:

    Color c = Color::White // eben noch mit templates etc.
driver->clear(Color::White);

    Ansonsten (bei benutzung der vectoren für farben) muss man entweder sowas wie einen CommonColors-Namespace machen oder sonst was unschönes.

    rapso schrieb:

    Niemand wird außerversehen eine Position als Farbwert behandeln u. andersrum 😉

    der zusammenhang entgeht mir.

    Na der zusammenhang ist, dass bei z.b.

    Driver::clear(Color& color)

    Auch nur ein Color-Wert angegeben werden kann, wenn jemand da ein Vector reinhaut gibts ein netten compile-time-error. In Scott Meyers Effective C++ gibts einen Tipp der empfielt für sowas immer eigene Klassen zu schreiben damit der compiler schon zu compile-time weiß ob die Typen stimmen.
    Typedefs sind in C++ einfach nicht sicher.

    rapso schrieb:

    Oder eben 1, 1, 1 und 1, 0, 0 für die Werte - je nach Speicherung.
    Nebenbei: sollte man lieber chars zur speicherung benutzten um dann weiß als 255,255,255 darzustellen oder lieber floats die von 0 bis 1 reichen was ja opengl etc. dann annnimmt?

    je nachdem ob du HDR unterstuetzung brauchst oder nicht.
    gibt ja viele wege nach rom, z.b.

    typedef Vector<Sat<float,0.f,1.f>,3> tyColor3;

    btw. opengl limitiert nicht auf 0 bis 1

    danke, wusste ich nicht.

    Danke für deine antwort 🙂

    0
  • P

    Falls jemand langweilig ist, gleich noch ein paar Fragen:

    1. Macht eurer Meinung nach ein operator[] für Vector-Typen Sin? Bei irrlicht wurden die soweit ich weiß seit 1.3 rausgenommen - jemand eine idee?

    2. falls man sowas gefährliches wie operator[] mit Vector& (d.h. Referenz) rückgabe benutzt, sollte man dann im falle von einem falschen index eine exception werfen?
    Oder sollten vector-klassen frei von exceptions sein?

    Vector<T,N>& operator[](unsigned int n)
{
switch(n)
{
case 0: return X;
case 1: return Y;
default: //exception???
}
}

    3. Sollte die const-variante die keine Referenz, sondern einen Wert zurückgibt eine exception werfen oder lieber 0 rückgeben?

    Vector<T,N> operator[](unsigned int n) const
{
switch(n)
{
case 0: return X;
case 1: return Y;
default: //return 0    oder exception???
}
}

    4. Oder sollte man, wenn man wie ich std::tr1::array benutzt um die daten als union abzulegen:

    union
			{
				struct
				{
					T X;
					T Y;
				};
				struct
				{
					std::tr1::array<T, 2> Elements;
				};
			};

    Dann lieber einfach so was nehmen ?

    T operator[](unsigned int n) const
{
return Elements[n];			
}

    Fragen über Fragen, 😉 Antwortet wenn euch danach beliebt :p

    0
  • T

    Die letzte Variante, aber mit einem normalen Array (keine Ahnung, was std::tr1::array ist). Alles andere ist zu langsam. Höchstens im Debug-Build den Index checken (z.B. mit assert).

    0
  • R
    Mod

    Pyr0kar schrieb:

    rapso schrieb:

    Pyr0kar schrieb:

    rapso schrieb:

    Pyr0kar schrieb:

    Darf man mal fragen ob ihr auch Color<N> oder sogar Color<T, N> habt ? 😉

    wieso nicht vector<T> dafuer nehmen?

    Ganz einfach, weil man bei einer eigenen Klasse so schöne dinge machen kann wie:

    static const Color3 White = Color3(255, 255, 255);
static const Color3 Red= Color3(255, 0, 0);

    was sollen diese zwei zeilen beweisen?

    Mir fällt leider jetzt erst auf dass die zwei Codezeilen wirklich nicht zeigen was ich meinte 😉 ^^
    Ich wollte eigentlich ausdrücken dass man das ganze der Klasse als Membervariable einbauen kann.
    So dass dann möglich ist:

    Color c = Color::White // eben noch mit templates etc.
driver->clear(Color::White);

    bei c++ versucht man mit kapselung die member nicht direkt zugreifbar zu machen, das zu brechen mit static const ist zum einen nicht schoen, zum anderen musst du die definition noch ausserhalb schreiben... doppelt unschoen.

    auch aus diesem grund gibt es namespaces, so musst du grundlegende oop dinge nicht brechen und darfst sogar trotzdem ein packet schoen abkapseln... kanns ein dass es nur meine ansicht ist 🙂

    rapso schrieb:

    Niemand wird außerversehen eine Position als Farbwert behandeln u. andersrum 😉

    der zusammenhang entgeht mir.

    Na der zusammenhang ist, dass bei z.b.

    Driver::clear(Color& color)

    Auch nur ein Color-Wert angegeben werden kann, wenn jemand da ein Vector reinhaut gibts ein netten compile-time-error. In Scott Meyers Effective C++ gibts einen Tipp der empfielt für sowas immer eigene Klassen zu schreiben damit der compiler schon zu compile-time weiß ob die Typen stimmen.
    Typedefs sind in C++ einfach nicht sicher.

    dann scheint dir ziemlich viel in letzten paar jahren entgangen zu sein, sprachen wie cg/hlsl nutzen vectoren/colors als nur einen datentypen und beim normalen rechnen tag fuer tag macht man auch keinen unterschied, du kannst farben oder normalen in buffer stopfen und sie dann wieder auf der graphikkarten interpretieren wie du moechtest.

    ich hab zuhause meinen color4 von vector4 abgeleitet, sharen das meiste aber manches wie z.b. operator* ist dann anders.
    aber grundsaetzlich spricht aus meiner sicht nicht dagegen das meiste zu sharen.

    0
  • L

    Pyr0kar schrieb:

    union
			{
				struct
				{
					T X;
					T Y;
				};
				struct
				{
					std::tr1::array<T, 2> Elements;
				};
			};

    Du kannst nur PODs in unions benutzen ⚠

    btw. ist das kein ISO-C++ aber die meisten Compiler unterstützen anonyme structs und unions.

    0

  • lolz schrieb:

    btw. ist das kein ISO-C++ aber die meisten Compiler unterstützen anonyme structs und unions.

    weis eigentlich wer warum das so is!? mir fällt auf die schnelle eigentlich nix ein was gegen anonyme structs sprechen würd...

    0
  • R
    Mod

    ich dachte annonyme structs kaemen in den neuen c++ standard.

    0

  • rapso schrieb:

    ich dachte annonyme structs kaemen in den neuen c++ standard.

    🙂 wunderbar

    0
  • R
    Mod

    das war keine feststellung, sonder wirklich was ich glaube mal gelesen zu haben (irgendwo in nem artikel der non-standard unterschiede in VC++ und g++ auf listete). waere schoen wenn das wirklich in den standard kaeme.

    0
  • R

    anonyme structs ala

    struct {
  // ...
} instanz;

    sind doch erlaubt.

    Aber die union geht auch wenn anonyme Typen erlaubt sind nicht, da die zweite Struktur definitiv und je nach dem was T ist auch die erste Struktur kein POD mehr sind 🙂

    0
  • P

    Hab mich von std::tr1::array getrennt.

    template<class T>
		class Vector<T, 2>
		{
		public:
			enum { Dimension = 2 };
			typedef T ValueType;
			typedef T ArrayType[2];

		public:
			union
			{
				struct
				{
					T X;
					T Y;
				};
				struct
				{
					ArrayType Elements;
				};
			};
			...

    Kann mir jemand jetzt konkret einen Compiler nennen der das nicht frisst?

    0
  • R
    Mod

    ich glaube VC5, irgend ein codewarrior und symantec wollten das nicht... ist aber ewig her dass ich die benutzt habe.

    0
Anmelden zum Antworten