//elegante unterdrueckung von "possible loss of data"

[muffmolch]

Hallo
ich habe eine template matrix-klasse, die es erlaubt eine matrix<double> einer matrix<float> zuzuweisen. bei der Zuweisung kommt es u.U. zu genauigkeitsverlusten, was hier auch selbstredend ist.

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

[Th69]

Ich nehme an, dein "this->operator()(x1,x2)" gibt eine nicht-konstante Referenz zurück und dieser wird dann ein anderer Datentyp zugewiesen.

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));

[Phoemuex]

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

[muffmolch]

Phoemuex schrieb:

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!

[drakon]

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.

[pumuckl]

Aber erst wenn einem der Profiler sagt dass die Schleife wirklich das Bottleneck ist

[Blue-Tiger]

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

[drakon]

Blue-Tiger schrieb:

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..).

[pumuckl]

Soll ja Leute geben die Anno 1980 ihr letztes C++-Buch/Magazin/Artikel gelesen haben und seitdem auf dem Stand ihren Code verbreiten. So wie es auch immernoch Lehrbuchautoren geht an denen die Einführung von std::string, Headern ohne .h und anderen "Neuigkeiten" vorüber gegangen ist

[muffmolch]

Blue-Tiger schrieb:

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!

[drakon]

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..