Klotzkopp

Das malloc/free-Paar im else-Block der einfuegen-Funktion ist falsch. Krawatte *lastTie = (Krawatte *) malloc(sizeof(Krawatte)); Hier holst du nochmal Speicher für eine Krawatte. Warum überhaupt? lastTie = *k; Hier verbiegst du den Zeiger lastTie auf den Listenanfang. Damit hast du keinen Zeiger mehr, der auf den gerade reservierten Speicher zeigt -> Speicherleck. free(lastTie); Da lastTie auf deinen alten Listenanfang zeigt, löschst du hier eine Krawatte aus deiner Liste. Der Vorgänger verweist allerdings noch darauf, darum fliegt es dir um die Ohren, wenn du das nächste Mal die Liste durchgehst.

Niemand. Aber meiner Meinung nach ist es kontraproduktiv, wenn das Ziel ist, dass man C++ lernt. C ist keine Vorbedingung für C++. Wenn ein Anfänger ein ungeeignetes Werkzeug verwenden möchte, das es ihm nur unnötig schwer macht, sollte man ihn schon auf bessere Alternativen hinweisen. Was genau? Das char-Arrays eine Krücke sind? C hat keinen eigenen Datentyp für Strings. Darum muss man sich mit Arrays behelfen, die die unangenehme Eigenschaft haben, dass ihre Größe feststeht. Wenn man da also flexibel sein will, landet man sofort bei dynamischer Speicherverwaltung. Auch ein Thema mit großem Fehlerpotenzial für Anfänger. Dann kommt hinzu, dass Arrays keine Wertsemantik haben (Zuweisen? Vergleichen? Pech!) und keine Funktionsparameter sein können, sondern dabei zu Zeigern werden. Was dann dazu führt, dass man nur noch einen Zeiger auf den Stringanfang hat, und somit entweder eine Längeninformation oder eine Endmarkierung mitschleppen muss. Bei den meisten anderen Arrays tut man ersteres, bei char-Arrays in der Regel letzteres. Damit hat man dann auch gleich die merkwürdige Konvention, dass char-Zeiger anders als alle anderen Zeiger behandelt werden. Was auch zur Folge hat, dass man an die Nullterminierung denken muss, und alles, was da dran hängt. Man muss ständig im Hinterkopf haben, was mit der Nullterminierung passiert, ob der Speicher groß genug ist und ob und wann der Speicher wieder freigegeben werden muss. Das geht in C leider nicht anders. In C++ geht das auch, aber da ist es dann nur noch eine Krücke. std::string ist ein Typ mit Wertsemantik, der einem das alles erspart. Meine Erfahrung ist, dass Leute, die zuerst C und dann C++ gelernt haben, oft eine Art "Tunnelblick" entwickeln und auch in C++ noch so programmieren, als ob es C wäre. Aus dem Denkschema kommt man nicht so einfach wieder raus. Typisches Beispiel: Ausnahmesicherheit.

Falls du damit meinst, dass man keine eigene Variable für die Archivgröße braucht, weil man denselben Wert auch mit GG + GT+ GS ermitteln kann, hast du Recht, das ist eigentlich überflüssig. Aber darum geht's ja bei der Aufgabe nicht.

Er soll sie gar nicht kennenlernen. Er soll einfach die Finger von char-Arrays lassen. Die braucht man in C++ erst einmal nicht. Wieso soll ein Anfänger Gefahren kennenlernen, die er prima komplett vermeiden kann, bis er etwas sattelfester geworden ist? Erklärst du einem C++-Anfänger auch die Stolperfallen bei Exception Specifications? Eben, früher oder später. Man kann sehr lange auf char-Arrays verzichten. char-Arrays sind Bestandteil von C++, kein "C-Code". Der Unterscheid zu C ist nur, dass man diese Krücke nicht mehr braucht, weil es bessere Lösungen für Strings gibt. Nein, ist es nicht. C++ ist eine eigenständige Sprache, die in weiten Teilen kompatibel zu C ist. Aber C++ ist keine Erweiterung von C, und C ist keine Teilmenge von C++. Und beide Sprachen entwickeln sich immer weiter voneinander weg.

Der Unterschied ist: G ist immer in Bytes, DS.groesse nicht. Der Wert von DS.groesse ist ohne DS.einheit nicht aussagekräftig. Und jetzt schau dir an, was wie aufsummiert wird, und ob das so sinnvoll ist.

Das ist kein guter Grund. Du machst es dir mit char-Arrays nur unnötig schwer. Du musst auf viel mehr achten und kannst viel mehr falsch machen als mit std::string und std::vector. Zeig doch mal deinen 2D-Array-Code, dann können wir überlegen, wie wir den umstellen.

Was ist der Unterschied zwischen G und DS.groesse?

Du bist der Meinung, dass der Supportmitarbeiter deine Kompetenz nur auf Basis deiner eigenen Zusicherung derselben anerkennen soll. Ich meine, dass er das nicht darf. Der Supportmitarbeiter hat vermutlich täglich mit Leuten zu tun, die nur meinen, Ahnung zu haben und das natürlich auch behaupten. Ich finde, ein guter Supportmitarbeiter darf sich auf so etwas nicht verlassen, um Schäden zu vermeiden. Und wer weiß, vielleicht hat er konkrete Vorgaben zum Ablauf und darf davon gar nicht abweichen. Es ist schön, dass du die Verantwortung auf dich nimmst, aber weißt du, ob der Supportmitarbeiter sie überhaupt abgeben darf? Sehe ich das richtig, dass du schon vorher einen Report über eine ungesicherte Verbindung geschickt hast? Und dich erst beim zweiten darüber aufregst? Weißt du genau, was diese Software nach der Installation tut, auch wenn du nicht den "live Schutz" aktivierst? Üblicherweise wird alles, was für so eine Funktionalität gebraucht wird (Treiber, Hooks, Dienste) bei der Installation angelegt und "ruht" nur, solange es nicht gebraucht wird. Ansonsten würde es schwierig werden, ohne Neustart und Adminrechte diese Funktion ein- oder auszuschalten. Daraus, dass der "live Schutz" nicht aktiv ist, kannst du nicht folgern, dass kein Teil der Software läuft. Oder hast du das wirklich geprüft? Hast du dir alle laufenden Dienste angesehen? Alle aktiven Treiber? Alle DLL-Hooks? Nur sehr wenige Personen, die den Support in Anspruch nehmen, sind in der Lage, das festzustellen. Und genau wie die Software selbst kann auch die Deinstallation fehlschlagen. Zweifelsfrei (für den Supportmitarbeiter) klären kann das nur der Report.

Deine Schilderung fängt offensichtlich mittendrin an. Hätte doch sein können, dass da vorher ein Anlass war. Der Supportmitarbeiter sollte zunächst davon ausgehen, dass du nicht qualifiziert bist, das zweifelsfrei festzustellen. Deine Argumentation, auf die sich mein Zitat bezog, war, dass es kein Problem gibt, weil es vorher immer gutgegangen ist. Das ist ein logischer Fehlschluss. Was du jetzt vorbringst, ist etwas Anderes. Nö. Siehe oben. In derselben Mail, in der du beklagst, dass dir die Datenübertragung nicht sicher genug ist, verkündest du auch, dass du selbst über eine gesicherte Verbindung nichts mehr schicken wirst. Was soll der Supportmitarbeiter da noch anbieten? Für mich stellt sich das so dar, dass du aufgegeben hast.

Das wundert mich nicht. Supportmitarbeiter haben es ständig mit Kunden zu tun, die sich für kompetenter halten als sie sind. Der Supportmitarbeiter unterstellt dir damit keine Lüge, er geht einfach von Inkompetenz aus. Und das ist meiner Meinung nach angebracht. Es ist nicht Aufgabe des Supports, dich weiterzubilden. Die meisten User wollen das auch gar nicht. Und viele, die es wollen, verstehen es dann doch nicht. Es gibt auch die Art "nicht so schlau wie er glaubt". Das ist schlicht falsch. Du hast dich geweigert, eine Anweisung des Supports zu befolgen. Darauf hat der Supportmitarbeiter gesagt, dass er dir nicht weiterhelfen kann. Dass er nicht will, ist eine Behauptung von dir. Schreien kommt immer gut an. Wie gesagt, ein Supportmitarbeiter sollte nicht "glauben". Er muss sich vergewissern. Natürlich kann es. Mit solchen Behauptungen ist es nicht verwunderlich, wenn der Support dich in die Kategorie "Glaubt, Ahnung zu haben" steckt. Was soll das sein? Beweis durch Beispiel? Es geht immer so lange gut, bis es knallt. Hast du nach einem anderen Weg, die Daten zu übermitteln, gefragt? Ich als Anbieter würde versuchen, so einen Kunden schnellstens loszuwerden.

Du greifst offenbar auf bereits freigegebenen Speicher zu. Bist du sicher, dass der Fehler in einer dieser Funktionen steckt? Was sagt der Debugger?

Benutz keine char-Arrays, wenn du keinen guten Grund dafür hast. #include <vector> #include <string> #include <fstream> int main() { using namespace std; ifstream file("bla.txt"); vector<string> v; string line; while(getline(file, line, ';')) { v.push_back(line); } }[/code]

Mit std::getline kannst du aus einem beliebigen Eingabestrom in einen String einlesen und ein Trennzeichen angeben. Deklariert wird diese Funktion in <string>. while(getline(streamvar, stringvar, ';')) { // stringvar verarbeiten }[/code]

Wenn das beispielsweise E-Mails waren, ja. Ich würde dir raten, es zu lassen. Die beabsichtigte Wirkung, den Kaspersky-Support als schlecht darzustellen, wird dein Text nicht haben. Ich vermute vielmehr, dass es für dich peinlich wird, wenn dir die User hier fachliche Fehler nachweisen.

Ist der Kundensupport von Kaspersky Internet Security damit einverstanden, dass du das veröffentlichst?

Aber du stimmst zu, dass das im allgemeinen Fall nicht so sein muss?

Schau dir die Bemerkung bei 6.1.1 an.

Das ist für Datenflusspläne und hat in PAPs nichts zu suchen. Benutz 4.2.

Wofür gibt's kein Symbol mehr?

Zahlen wären schon angebracht. Wer sind denn die "Besucher"? Mitarbeiter? Kunden? Sparen die Besucher Zeit durch die Änderungen? Spart jemand Geld durch geringere Traffic-Kosten? Gab es konkrete Beschwerden wegen der Benutzerfreundlichkeit? Werden möglicherweise Kunden durch eine nicht mehr zeitgemäße Webpräsenz abgeschreckt?

Hast du einfach drauf los gearbeitet, ohne dir vorher zu überlegen, was es bringt? Nein. Der Nutzen des Projekts ist doch nicht, dass es weniger gekostet hat, als wenn es jemand anderes durchgeführt hätte. Der Nutzen ergibt sich aus dem Projektziel: Welchen Nutzen bringt diese Aktualisierung? Da du bisher nichts darüber gesagt hast, wozu diese Webseite gut ist, kann man da nur spekulieren. Welche Auswirkung hatte es denn, dass diese Seite nicht auf dem neuesten Stand war? Kam es dadurch zu Verzögerungen oder Störungen in Geschäftsprozessen? Wenn die durch deine Änderungen nicht mehr auftreten, ist genau das dein Nutzen.

Wenn du nichts geändert hast, ist das nicht weiter verwunderlich. Wenn doch, solltest du schon sagen, was Geh es doch einfach mal von Hand durch: schachbrett_ enthält überall 0, zeile_ und spalte_ sind auch 0 while ((spalte_>=0)&&(spalte_<=groesse_)) ---> true, äußere Schleife betreten while ((zeile_<groesse_) && conflictFeld(zeile_,spalte_)) ---> false (weil conflictFeld auf einem leeren Schachbrett 0 zurückgibt), innere Schleife nicht betreten Ende der äußeren Schleife, zurück zu 2 Mehr passiert nicht.

Wäre dir lieber, wir ließen dich ins offene Messer rennen? Ich kenne die Lizenz des Originalspiels nicht, aber in aller Regel darfst du nicht ohne Einverständnis des Urheberrechtsinhabers die Grafiken übernehmen. Das scheint mir hier aber passiert zu sein. Ich nehme den Link vorerst raus. Wenn du meinst, dass das urheberrechtlich in Ordnung ist, schick mir eine PN, dann stelle ich ihn wieder rein.

Die Blauäugigkeit, mit der hier offenbar unbekannte ausführbare Dateien runtergeladen und gestartet werden, erschreckt mich ein wenig :eek Jeronimonino, Ich hoffe, du machst das in einer Sandbox. Murphy9904, wenn jemand etwas zu deinem Programm sagen soll, dann stell bitte den Quellcode zur Verfügung.

Du meinst wahrscheinlich fußgesteuert.