@Finnegan sagte in Unions oder doch Bit-Shift und Bit-Operationen: @TGGC sagte in Unions oder doch Bit-Shift und Bit-Operationen: Dennoch: Ich denke, dass sich fehlerträchtige Berechnungen immer irgendwie zentralisieren lassen, so dass man nur eine problematische Stelle im Code hat, anstatt hunderte. Diese Stelle gibt es und die ist im Kompiler drin. Daher meine Meinung: nicht neu machen. Ausserdem ist ja schön wenn du alles zentralisierst, aber wenn hunderte Member eine Position und Länge innerhalb ihrer Parentstruct brauchen, dann musst du eben diese hundertem Werte eben angeben. Wie zentralisiert das ist, ändert nichts an der Menge der Daten und der Schwierigkeit Inkonsistenzen zu vermeiden. Und daher nehme ich da soviel Unterstützung und Error Checking vom Compiler mit, wie ich nur kann anstatt das alles neu zu designen.

@wob sagte in DELETE() - Wird das Objekt wirklich gelöscht?: Das habe ich weder gemeint noch gefordert. So weit muss man nicht gehen. Die Probleme fangen doch schon beim Copy-Constructor an. Rule of 3. (5 ist zu advanced). Im obigen Beispiel muss man zudem doppelt aufpassen. Einmal mit dem Namen des Autos, das man ja als char* behandelt. Und einmal im aufrufenden Code, der Autos erzeugt und zerstört. Durch das Ersetzen von char* -> std::string hätte man das Problem halbiert, könnte aber immer noch new/delete lehren. Das stammt von StudiengangPanik und ist wohl nicht Teil der Aufgabenstellung. Es ist wohl der Tatsache geschuldet, dass in der Vorlesung entsprechende Dinge nicht eingeführt wurden. Und natürlich wäre das alles sehr viel besser vermittelbar. Nur es wird eben nicht getan, und daran ändern hier ständige Beschwerden rein gar nichts. Das hilft den Studenten nicht weiter uns sorgt höchstens dafür, dass sie sich vom Forum abwenden. Oder man macht als Übung, einen vector neu zu implementieren. Es gibt genügend Möglichkeiten, new/delete zu lehren, ohne in die Probleme zu laufen. Beantworte mir doch mal, warum sich Auto um String-Behandlung kümmern sollte. Genau das sollte eben nicht gelehrt werden. Stattdessen sollte separation of concerns gelehrt werden. Und zwar nicht nur theoretisch, sondern gleich hier. Einer kümmert sich um die String-Verwaltung und einer um Autos. Und gut ists. Wie bereits beschrieben, das Problem ist, dass Du die falschen Personen ansprichst. Die Studenten können nichts für die Aufgabenstellung. Wird es das? Entschuldigung, da fehlte ein Wort.

@martin_zi Ein allocator ist ein allgemeines Dingsti das Speicher besorgt. Ein iterator is ein allgemeines Dinsti das auf Speicher zeigt. Zeiger sind super iteratoren.

@hustbaer sagte in Objeke referenzen gebrauch, wie object copy vermeiden?: Leute die Code geschrieben haben mit dem ich dann arbeiten durfte. steinigen.

@enterprise , vor allem das TODO Fehlt nur noch ein Dependency Injection Container.

Na, wenn du das weißt....

@muemmel Ne, so geht das nicht. Du fragst nach Beispielen, ich liefere Beispiele. Du behauptest, die zählen nicht, aber lieferst keine Belege für deine Behauptung. So wird da keine Diskussion raus.

@Lockna: Wie gibst du denn das Array aus? Ich denke, da hast du einen Fehler...

@SeppJ sagte in software renderer: Dann ist die Gegenfrage: Hast du noch weitere Fragen oder reichen dir meine und @Wade1234 s Antworten? Damit bekommst du beliebige Pixel in einem 2D-Schachbrett gesetzt und kannst mit den ersten (aber erstaunlich schwierigen) Fingerübungen anfangen, zum Beispiel eine sauber aussehende gerade Linie oder einen beliebig skalierbaren Kreis zu zeichnen. Ich werde jetzt etwas rumprobieren und schauen wie weit ich komme. Aber denke, dass ich dazu noch fragen haben werde. Aber bisher mal danke.

@luis sagte in Problem bei Tannenbaumprogramm: Output den ich haben will -----* ----*** ---***** --******* -********* -----# bindestrich = leerzeichen Ach, ich weiß doch auch nicht. #include <cstdlib> #include <iostream> #include <string> int main() { std::cout << "Height: "; int height; if (!(std::cin >> height) || !height) { std::cerr << "Input error.\nbye.\n\n"; return EXIT_FAILURE; } for (int line{}; line + 1 < height; ++line) std::cout << std::string(height - line - 1, ' ') << std::string(line * 2 + 1, '*') << '\n'; std::cout << std::string(height - 1, ' ') << "#\n"; } oder mit manipulators. Liest sich aber viel hässlicher: for (int line{}; line + 1 < height; ++line) std::cout << std::setw(height - line - 1) << std::setfill(' ') << ' ' << std::setw(line * 2 + 2) << std::setfill('*') << '\n'; std::cout << std::setw(height + 1) << std::setfill(' ') << "#\n"; oder mit schleifchen: for (int line{}; line + 1 < height; ++line) { for (int spaces{ 1 }; spaces < height - line; ++spaces) std::cout.put(' '); for (int stars{}; stars < line * 2 + 1; ++stars) std::cout.put('*'); std::cout.put('\n'); } for (int spaces{ 1 }; spaces < height; ++spaces) std::cout.put(' '); std::cout << "#\n"; aber man sollte es wahrscheinlich bleiben lassen. Es wird nur hässlicher.

@axels Im Prinzip garnicht. Egal wie es die konkrete Sprache nennt geht es auf Maschinenebene immer um einen Zahlenwert der als Speicheradresse interpretiert wird.

@Th69 Nein, absolut logisch was du schreibst. Kopf->Tischkante Sorry wg. der späten Antwort...

@Sarkast sagte in while schleife funktioniert nicht (s muss änderbarer Ivalue sein): @Swordfish Du hast völlig recht, die ganze Familie mag kein Overlapping. memmove verträgt es.

Danke für die Rückmeldungen. Also der Compiler hat nicht gemeckert wegen dem Keyword override, ich habe jetzt aber alle Destruktoren bis auf den virtual Destruktor der Basisklasse entfernt. Ich habe mich, da wir bislang weder Move-Konstruktoren, noch das Keyword auto benutzt haben und solche Übungsaufgaben leider immer recht schwammig formuliert werden, dafür entschieden es erstmal beim Arbeiten mit Kopien zu belassen und in den abgeleiteten Klassen nicht mit Pointern zu arbeiten.

Nun, du machst ja nichts selber, außer die fertigen Funktionen aufzurufen (was gut ist!) daher kann man kaum etwas zum Speichern und Sortieren sagen. Wobei man, wenn es nur um Speichern von sortierten Daten ginge, wohl eher ein (multi-)set nehmen würde. Das ist von Natur aus sortiert, wodurch das aufwändige Neusortieren bei jedem Einfügen entfällt. Eine typische C++-Leseschleife würde so aussehen: while(cin >> eingabe) { lDaten.push_back(eingabe); lDaten.sort(); ZeigeListe(lDaten); } Da hast du automatisch alles drin: Fehlerprüfung (fehlt bei dir bisher) und Abbruchbedingung (mit CTRL+D (bzw CTRL+Z in Windows) oder bei Fehler).

@Swordfish sagte in Objektnamen vergleichen geht das ?: @It0101 sagte in Objektnamen vergleichen geht das ?: @hustbaer sagte in Objektnamen vergleichen geht das ?: Jedenfalls ist es besser als komischen Geschwurbel-Code zu zeigen der nochdazu falsch ist (t1->type() == t2->type() || t1->type() == Tier::TierArt::taSpinne ist nicht die korrekte Bedingung wenn wir wissen wollen ob beides Spinnen sind). Vielleicht stehe ich ja gerade auf dem Schlauch, aber warum ist das nochmal falsch? Lass t1 eine Spinne sein und t2 was beliebig anderes. Und und oder und so. Achso das meint ihr. Naja ich dachte anhand der Benamung der Flags hätte man erkennen können, dass der Quellcode mal eben schnell hingerotzt wurde und nur halb ernst gemeint ist. Ja wenn man das machen wollte, hätte man ein && anstatt || verwenden sollen. Ich füge hinzu: der Quellcode wurde hingerotzt und entstammt keinem hochwertigen Softwareprodukt. Er diente nur der Veranschaulichung meiner Idee. Ich füge desweiteren hinzu, dass der Quellcode 't1->type() == t2->type() || t1->type() == Tier::TierArt::taSpinne' nicht dazu diente, zu prüfen ob beide Tiere Spinnen sind.

@Leon0402 sagte in Probleme mit struct: Meine Empfehlung wäre an dieser Stelle "Der C++ Programmier" vom Bergmann. Du meinst Ulrich Breymann, nicht Bergmann. Ansonsten gibts auch noch den C++ Primer von Lippman. Beide Bücher sind empfehlenswert.

@wob sagte in Problem mit der Implementierung einer Template Klasse: "Der Bruch 0/0 ist 0" Haha. Wer hat das erfunden? Die Schweitzer? gratistip

@hustbaer sagte in Frage zu Funktionsobjekten: @Swordfish Konstruktoren können auch Nebeneffekte haben. So wie auch selbst definierte globale operator new/delete Nebeneffekte haben könnten. Trotzdem dürfen die wohl wegoptimiert werden. (Konstruktoren sicher siehe (N)RVO & Co., und bei den globalen operator new/delete ist zumindest Clang der Meinung dass es schon OK wäre die Aufrufe wegzuoptimieren.) Und warum dann nicht auch std::allocator? Habe ich nicht gesagt Kopfschmerzen?? Ich denke darüber heute sicher nicht mehr nach. @hustbaer sagte in Frage zu Funktionsobjekten: bei den globalen operator new/delete ist zumindest Clang der Meinung dass es schon OK wäre die Aufrufe wegzuoptimieren. Definier' sie mal selbst, ist clang dann immer noch derselben Meinung?