Hallo kann mir mal jemand den Unterschied zwischen einer expliziten und einer impliziten Typwandlung erklähren? Das Programm sieht so aus. Danke /*-------------------+----------------------------+--------------------+ | Ohm-Hochschule | | convers2.cpp | | Nuernberg | Programmieren in C++ |--------------------| | Peter Jesorsky | | 02.07.2007 | +--------------------+----------------------------+-------------------*/ /* Einsatz einer Typumwandlungs-Funktion */ #include <iostream> #include <cmath> using namespace std; class Complex { public: Complex(double r = 0, double i = 0); // Konstruktor operator double() const; // Umwandlungsfunktion private: double re, im; }; Complex::Complex(double r /* = 0 */, double i /* = 0 */) { re = r; im = i; cout << "Konstruktor: (" << re << " , " << im << ")\n"; } Complex::operator double() const // Umwandlungsfunktion { cout << "Umwandlung Complex = (" << re << " , " << im << ") -> double = " << sqrt(re * re + im * im) << endl; return sqrt(re * re + im * im); } int main(void) { Complex x(3, 4); // Konstruktor-Aufruf zur Erzeugung von x double dbl; dbl = x; // implizite Typumwandlung Complex -> double // mit Umwandlungsfunktion dbl = (double)x; // explizite Typumwandlung dbl = double(x); // das gleiche mit neuer Syntax! cout << dbl << '\n'; return 0; } /* Ausgabe: ------------------------------------------------------------------------ Konstruktor: (3 , 4) Umwandlung Complex = (3 , 4) -> double = 5 Umwandlung Complex = (3 , 4) -> double = 5 Umwandlung Complex = (3 , 4) -> double = 5 5 ----------------------------------------------------------------------*/
> kann mir mal jemand den Unterschied zwischen einer expliziten > und einer impliziten Typwandlung erklähren? Naja, in einem Fall gibt es eben Regeln, die festlegen wie und wann eine Typumwandlung implizit erfolgt. Im anderem Fall schreibst Du es eben extra hin. Letzteres ist in der Regel besser lesbar, da es offensichtlicher ist, was gerade passiert. Impliziete Typumwandlung ist in erster Sicht eine tolle Sache, in der Realität aber ein Albtraum, darum will man sie eigentlich niemals verwenden. Nur in ganz besonderen Fällen ist sie sinnvoll. Konstrukturen können übrigens "eplicit" markiert werden.
Übrigens, Dein Beispiel mit der Complex-Klasse ist so ein Negativ-Beispiel wie man es auf keinen Fall machen soll.
Ich nehme an er meint den Cast-Operator. Die Operatorüberladung war schon immer in Reizthema. Bei Templates und Mehrfachvererbung sieht das ähnlich aus. Ich finde das Beispiel nicht schlimm. Ist normales C++. Ein einfacheres Beispiel für die Umwandlung sieht z.B. so aus:
1 | int i, n; |
2 | double f = 3.141; |
3 | |
4 | i = f; // implizit, könnte eine Warnung geben wg. Verlust an Genauigkeit. |
5 | n = (double) f; // explizit |
Regeln für die Umwandlung muß es immer geben. Eine implizite Umwandlung ist aber nicht immer erlaubt:
1 | char* cptr = malloc(128); // hier knallt es |
2 | char* cptr = (char*) malloc(128); // so geht es |
wenn du schon am lernen bist, schaue dir auch die explicit Konstruktoren an. diese sind eine prima sache.
> das ist ein Beispiel aus der Vorlesung > was ist daran negativ Naja, der Betrag eine komplexen Zahl ist eben keine komplexe Zahl. Das Interface dieser Klasse ist einfach mistig. Besser wäre:
1 | {
|
2 | public:
|
3 | Complex(double r = 0, double i = 0); |
4 | |
5 | double magnitude() const; |
6 | ...
|
7 | |
8 | private:
|
9 | double re, im; |
10 | };
|
Es ist eben einfach eines dieser Beispiele, bei dem mit aller Gewalt ein Anwendungsfall für implizite Typumwandlung gesucht wird, wo es keinen Sinn macht. Beim Unwandeln einer komplexen Zahl in ihren Betrag geht Information verloren. Der Betrag ist eben keine andere Darstellungsform der komplexen Zahl. Sinnvoll ist z.b. eine Typ-Umwandlung von einem Char nach Double. Da geht keine Information verloren.
Hallo ich hab da noch ein Problem dabei geht es um Containerklassen der Standartb und um den sogenannten Iterator. Was ist die Hauptaufgabe von so einem Iterator? /*-------------------+----------------------------+--------------------+ | Ohm-Hochschule | | cont1.cpp | | Nuernberg | Programmieren in C++ |--------------------| | Peter Jesorsky | | 03.07.2007 | +--------------------+----------------------------+-------------------*/ /* Einsatz eines vector-, list- oder deque-Containers Die Klasse vector kann gegen list oder deque ausgetauscht werden. */ #include <iostream> #include <vector> using namespace std; template <class T> ostream & operator<<(ostream &os, const vector<T> &co) { // über alle Elemente iterieren // Wenn der Container-Inhalt nicht verändert werden darf, muss statt // des iterator- ein const_iterator-Objekt eingesetzt werden. vector<T>::const_iterator iter; for (iter = co.begin(); iter != co.end(); iter++) os << *iter << ' '; os << endl; return os; } int main(void) { vector<int> cont; vector<int>::iterator it; // Elemente hinzufügen cont.push_back(1); cont.push_back(2); cont.push_back(4); cont.push_back(5); cout << "1: " << cont; // 1 2 4 5 // auf das erste und letzte Element zugreifen cout << "2: " << cont.front() << ' ' << cont.back() << endl; // Element 3 an Pos. 2 einfügen it = cont.begin(); // Pos. 0 it++; // Pos. 1 it++; // Pos. 2 cont.insert(it, 3); cout << "3: " << cont; // 1 2 3 4 5 // letztes Element entfernen cont.pop_back(); cout << "4: " << cont; // 1 2 3 4 // Erstes Element mit dem Wert 3 suchen und entfernen for (it = cont.begin(); it != cont.end(); it++) { if (*it == 3) { cont.erase(it); break; } } cout << "5: " << cont; // 1 2 4 // Anzahl der Elemente cout << "6: " << cont.empty() << endl; cout << "7: " << cont.size() << endl; // Alle Elemente löschen cont.clear(); cout << "8: " << cont.size() << endl; return 0; }
Dieses Vorlesungs-Beispiel ist typisch für die "Qualität" unzähliger Informatik-Vorlesungen. Den Studenten wird schon bei den Grundlagen durch schlechte Beispiele schlechter Programmierstil beigebracht, der später nur Ärger verursacht. Das A und O beim Programmieren bzw. Entwurf ist es, absolut klare und eindeutige Schnittstellen zu verwenden, ohne Überraschungen. Aber genau dieses Komplex-Beispiel zieht sich wie ein roter Faden schon seit bald 20 Jahren durch verschiede Bücher und Vorlesungen. Und die Studeten schreiben später (am Anfang) wirklich solche blöden Typ-Umwandlungen bis sie durch harte Erfahrung in der Praxis eines Besseren belehrt werden. Die Resourcen die durch solchen Mist vergeudet werden, sind aber immens.
>Aber genau dieses Komplex-Beispiel zieht sich wie ein roter Faden schon >seit bald 20 Jahren durch verschiede Bücher und Vorlesungen. Und die >Studeten schreiben später (am Anfang) wirklich solche blöden >Typ-Umwandlungen bis sie durch harte Erfahrung in der Praxis eines >Besseren belehrt werden. Wenn es nur das wäre. Tatsächlich zieht sich genau dieses Beispiel seit hunderten_ von Jahren durch _sämtliche Bücher und Vorlesungen. Die folgen für die Student sind fast immer Pickel und frühzeitiges Ableben. >Die Resourcen die durch solchen Mist vergeudet werden, sind aber immens. Stimmt. Die aktuelle Wirtschaftskrise ist durch ungeeignete Operatoren überhaupt erst entstanden. Da wage noch einer zu behaupten Programmierung und Programmarchitektur hätten nichts miteinander zu tun.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.