mit ist bewußt, dass ich hier einmach die warning für den abschnitt deaktivieren koennte. ich koennte auch einen static_cast vor der zuweisung durchführen, welcher aber mehr als gefaehrlich ist, wenn zwei matrizen mit nicht zueinander kompatiblen klassen beinhalten.

wie ist denn hier das allgmeine vorgehen, oder läßt man die waring einfach stehen?
wie macht es std::copy (eine Zuweisung zweier std::vector mit unterschieldichen Typen istja nicht erlaubt):

template< typename T>
struct Matrix
{
  //  ...
  template< typename T2>
  Matrix operator=(const Matrix< T2 >& rhs) 
  {
     //... verwaltungskram ...
     for(int x1=0; x1<nx1; ++x1)
        for(int x2=0; x2<nx1; ++x2)
           this->operator()(x1,x2) = rhs.operator()(x1,x2);
     return *this;
  }
  //...
};

int main()
{
   Matrix<double> m1(10,10,1);
   Matrix<float>  m2;
   m2 = m1; //<- Waring "possible loss of data"

   vector<double> a(10);
   vector<float> b;
   copy(a.begin(), a.end(), back_inserter(b)); //<- hier kommt keine Warning
return 0;
}

Anm.: ja, die Matrix-Klasse hat alle notwendigen Methoden, Kontruktoren, etc. implementiert. Mir geht es hier rein um das Beseitigen der Warnungs für den "possible loss of data" bei Verwednung von build-in-types

Du könntest einfach den Datentypen konstruieren (bei den Basisdatentypen erfolgt dann vom Compiler der Cast):

this->operator()(x1,x2) = T(rhs.operator()(x1,x2));

ich koennte auch einen static_cast vor der zuweisung durchführen, welcher aber mehr als gefaehrlich ist, wenn zwei matrizen mit nicht zueinander kompatiblen klassen beinhalten.

Wenn die beiden Klassen, wie in Matrix<A> und Matrix<B> wirklich nicht zueinander kompatibel, das heißt nicht ineinander umwandelbar sind, dann kompiliert das auch trotz eines static_cast nicht. Ein static_cast ist ja gerade dazu da, dass er nur relativ "schwache" Umwandlungen zulässt. Solange du also kein reinterpret_cast da reinhaust, kompiliert das ganze bei abstrusen Umwandlungen nicht.

Felix

muffmolch schrieb:

ich koennte auch einen static_cast vor der zuweisung durchführen, welcher aber mehr als gefaehrlich ist, wenn zwei matrizen mit nicht zueinander kompatiblen klassen beinhalten.

Wenn die beiden Klassen, wie in Matrix<A> und Matrix<B> wirklich nicht zueinander kompatibel, das heißt nicht ineinander umwandelbar sind, dann kompiliert das auch trotz eines static_cast nicht. Ein static_cast ist ja gerade dazu da, dass er nur relativ "schwache" Umwandlungen zulässt. Solange du also kein reinterpret_cast da reinhaust, kompiliert das ganze bei abstrusen Umwandlungen nicht.

Felix

nein, einen reinterpret_cast werd eich dort sicher nicht anwenden. Habe es nun mit dem static_cast und ein paar Testklassen getestet. Ist genau das, was ich gebraucht habe. Danke!

Mal noch was zu deiner Matrix Klasse. Da kommt es ja auch sehr auf Performance an. Und dazu habe ich mal was gelesen, dass man Schleife immer aufrollen soll, wenn man grössere Performance haben will.

Das war Anno 1980 auch ein total wichtiger Ratschlag. Aber du wirst es nicht glauben, knapp 30 Jahre spaeter macht das der Compiler fuer dich

drakon schrieb:

Mal noch was zu deiner Matrix Klasse. Da kommt es ja auch sehr auf Performance an. Und dazu habe ich mal was gelesen, dass man Schleife immer aufrollen soll, wenn man grössere Performance haben will.

Das war Anno 1980 auch ein total wichtiger Ratschlag. Aber du wirst es nicht glauben, knapp 30 Jahre spaeter macht das der Compiler fuer dich

Ok, das hat was. Aber dort, wo ich das gelesen habe war es nicht soo alt. (Wenn ich mich recht erinnere nvidia..).

drakon schrieb:

Mal noch was zu deiner Matrix Klasse. Da kommt es ja auch sehr auf Performance an. Und dazu habe ich mal was gelesen, dass man Schleife immer aufrollen soll, wenn man grössere Performance haben will.

Das war Anno 1980 auch ein total wichtiger Ratschlag. Aber du wirst es nicht glauben, knapp 30 Jahre spaeter macht das der Compiler fuer dich

nein das stimmt nicht. wir haben hier an der uni oft seminare, bei denen vorträge über code-optimierungen gehalten werden. der compile rist kein wudnerkind und kann bei weitem nicht alles so optimieren, wie man es als hardcore freak per hand koennte. aber der code ist dann oftmals kaum mehr vernünftig zu lesen und selbst die vortargenden raten oftmals von optimierungen ab, die am ende "nur" zu 2% Leisungssteigerung bei erheblichen mehraufwand führen.

PS: da die matrixklasse ein weiteres template-argument besitzt (hier nicht aufgefürht), die letztlich bestimmt, wie die indizes auf EINEN vector abgebildet werden und der template operator=() auch matrix klassen mit anderen "indexern" konvertieren kann, muessen hier explizit die schleifendurchgänge erfolgen!

PS: da die matrixklasse ein weiteres template-argument besitzt (hier nicht aufgefürht), die letztlich bestimmt, wie die indizes auf EINEN vector abgebildet werden und der template operator=() auch matrix klassen mit anderen "indexern" konvertieren kann, muessen hier explizit die schleifendurchgänge erfolgen!

Das habe ich mir noch gedacht, dass du bestimmt einen Grund dazu gehabt hast. Darum war ja auch die Variabel da. Hätte ja sein können, dass es nur eine const Variabel gewesen wäre..