Klotzkopp

Das ist ja schon mal grundsätzlich falsch. sin 30° = 0,5. Ist dir klar, dass du das Ergebnis dieser Funktion mit Pi/180 umrechnen musst, nicht das Argument?

Theoretisch kannst du Insertion Sort immer anwenden. Alle Sortieralgorithmen erfüllen ihren Zweck. Wenn es um die Wahl eines bestimmten Algorithmus geht, ist eine Vorsortierung nur ein Kriterium von vielen. Wichtig ist unter Anderem auch, ob du einen stabilen Algorithmus brauchst, wie groß das zu sortierende Feld ist, wie teuer ein Vergleich in Relation zu einer Vertauschung ist usw.

Die erste Begründung ist Unsinn. Wenn du einen stabilen Sortieralgorithmus brauchst, musst du einen stabilen Sortieralgorithmus verwenden, das hat nichts damit zu tun, ob die Folge vorsortiert ist. Die zweite Begründung passt schon eher. Allerdings benutzt man in der Praxis Selection Sort und Insertion Sort nur für kleine Listen, weil sie O(n^2) haben. Bei größeren Listen benutzt man dann einen der Algorithmen mit O(n log n), wie Quicksort oder Mergesort.

Aber soweit ich weiß, nur mit Microsoft-Compilern. fflush auf Eingabeströme erzeugt undefiniertes Verhalten, dein Code ist damit nicht mehr portabel.

Diese Herangehensweise funktioniert bei C und C++ nicht. Laut Standard erzeugt der Code in Zeile 6 undefiniertes Verhalten. Das heißt nicht, dass das Programm an dieser Stelle abstürzen muss (das wäre ein definiertes Verhalten), sondern dass irgendetwas passieren kann. Man darf bei C und C++ daraus, dass ein Code funktioniert, nicht schlussfolgern, dass er richtig ist. str4 ist ein Nullzeiger. Nullzeiger dürfen nicht dereferenziert werden, sonst -> undefiniertes Verhalten. Konkret erzeugt das bei allen mir bekannten Compilern auf Betriebssystemen, die virtuellen Speicher anbieten, eine Schutzverletzung.

Das passiert von ganz allein. char ist ein numerischer Datentyp, der Wert ist der ASCII-Code. Ich vermute mal (mit "klappt einfach nicht" ist leider nicht mehr zu machen), dass hier die Zeilenvorschübe als Zeichen eingelesen werden. In diesem Fall ließe sich das wohl mit "\n%c" als Formatstring für scanf lösen.

Um mit einem einfachen Multimeter Strom zu messen, musst du das Messgerät in Reihe schalten. Es reicht also nicht, die Messspitzen irgendwo dranzuhalten.

Du meinst vermutlich, dass die Laufzeitkomplexität von Selection Sort davon unabhängig ist. Der Algorithmus profitiert nicht von einer Vorsortierung, weil er in jedem Schritt immer alle verbliebenen unsortierten Elemente durchsuchen muss, um das jeweils nächste kleinste zu finden. Es gibt da keine Möglichkeit, die Suche vorzeitig abzubrechen. Die Anzahl der Vergleiche, die bei Selection Sort stattfinden, ist immer gleich.

Richtig. Solche Grundkenntnisse werden nomalerweise im Unterricht vermittelt, wenn sie später geprüft werden sollen. Alternativ gibt es auch Bücher über's Angeln. So etwas kann ein Forum nicht wirklich ersetzen. Ein Forum kann aber bei konkreten Fragen zum Angeln helfen. Was nicht geht, ist sich hinzustellen und zu sagen: "Ich kann nicht angeln, gebt mir einen Fisch." Um jetzt mal von der Angelmetapher wegzukommen: Deine Ich-kann-gar-nichts-Einstellung macht es uns praktisch unmöglich, dir zu helfen. Niemand kann und will hier deinen kompletten verpassten Unterricht mit dir nacharbeiten.

Das geht leider nur, wenn im Header auch die Implementation liegt, d.h. wenn nur Inline-Funktionen oder Templates im Header stehen. Das soll übrigens keinesfalls eine Aufforderung sein, das zu tun Das wäre eine Möglichkeit. Nein, wie ich schon sagte, die Header wissen gar nichts. In deinem anderem Thread hattest du doch ein SDL-Projekt. Da reichte es auch nicht, die SDL-Header einzubinden. Du musstest dem Linker über "-lSDLMain -lSDL -lSDL_image" anweisen, die zugehörigen Bibliotheken zu linken. Genauso würdest du das dann mit einer eigenen Bibliothek machen.

Du brauchst eine Instanz dieser Klasse. Die solltest du natürlich nicht in deiner Render-Funktion erzeugen, denn dann hättest du ja bei jedem Durchlauf eine neue. Eine Instanz legst du durch Test use; oder, wenn eine Lebenszeit über den enthaltenen Block hinaus erforderlich ist, durch Test* use = new Test; an. Das ist das Schöne an undefiniertem Verhalten: Es kann alles passieren. Daraus, dass etwas funktioniert, darfst du nicht folgern, dass der Code richtig ist. Dein uninitialisierter Zeiger zeigt irgendwo in den Speicher. Wenn das Programm dann dort versucht, Werte abzulegen oder auszulesen, kann das zufällig gut gehen oder auch dein Programm abstürzen lassen.

Eine Note soll wiedergeben, was du kannst. Das Forum ist kein Hausaufgaben-Service. Die Einstellung "Ich brauche Hilfe, weil ich nichts kann" wird dich hier nicht weit bringen. Und einen Hausaufgabenbeitrag als "dringend" zu kennzeichnen, wirkt auch eher abschreckend. Hier bekommst du keinen Fisch - hier lernst du Angeln.

Gar nicht. Viele Entwicklungsumgebungen linken solche Standardbibliotheken einfach automatisch dazu. Darum hat es den Anschein, dass der Header allein ausreicht.

Das habe ich auch noch nicht erlebt, dass jemand ein Minimalbeispiel von 1,6 MByte abliefert :eek Zum Glück lässt sich das Problem auch leicht erkennen, ohne das Projekt kompilieren zu müssen: Test* use; use->draw(a,move); [/code] Das ist Blödsinn. use ist ein uninitialisierter Zeiger. Du erstellst nirgends ein Objekt der Klasse Test. Der Code verursacht undefiniertes Verhalten, da kann alles passieren.

Bitte kein Threadpushing, siehe Boardregeln. Ein aussagekräftiger Betreff wäre auch nett gewesen, bei "Fehler" weiß niemand, worum es geht. Des Rätsels Lösung ist übrigens %02X.

Edit > Advanced > View White Space oder Strg+R, Strg+W.

Bist du sicher, dass die Ausgabe erst beim 12. Durchlauf anfängt, oder kann es sein, dass einfach der Puffer deiner Konsole nicht groß genug ist, um die gesamte Ausgabe aufzunehmen? Leite doch die Ausgabe mal in eine Datei um.

Ohne Code lässt sich da nicht viel machen. Versuch bitte mal, ein kompilierbares Minimalbeispiel zu erstellen, das den Fehler reproduziert.

Schau dir noch mal an, was nicht erlaubt ist. Steht auf der ersten Seite dieses Threads .

Die beiden Strings sind Literale. Literale sind während der gesamten Laufzeit des Programms gültig, daher ist diese Zeile absolut korrekt. Man muss eben nur wissen, dass man auf Stringliterale nicht schreibend zugreifen darf. Das ist schon syntaktisch falsch. Du deklarierst hier ein zweidimensionales Array von char-Zeigern, der Initialisierer hat aber nur eine Dimension.

Kann es sein, dass du einfach nur rätst, damit ich dir sage, ob es richtig oder falsch ist?

Erinnerst du dich noch daran, was alles nicht erlaubt ist? Schreibzugriffe auf Stringliterale gehören dazu. str3[0] verweist auf ein Stringliteral, da darf man nicht reinschreiben.

Ist das ein dauerhafter Zustand? Zum vierten Mal: strcpy ändert nichts an den Zeigern. str3 kommt in dieser Zeile auch nicht vor. Selbst wenn es das täte, würde strcpy nichts daran ändern, wohin es zeigt, oder wie groß der Speicherbereich ist, auf den es zeigt. Soweit richtig. Es sind vier einfache und ganz klare Bedingungen, die du bei strcpy prüfen musst. Es kann doch nicht sein, dass dich das derart überfordert. Zum Beispiel für Zeile 8: Zeigt "test3" auf Speicher, aus dem gelesen werden darf? Enthält dieser Speicher einen terminierten String? Zeigt str3[0] auf Speicher, in den geschrieben werden darf? Ist dieser Speicher groß genug für den String (mit Terminierung)? Wenn die Antwort nicht vier mal "ja" ist, ist der Zugriff ungültig.

Wie kommst du jetzt auf 5? Das Array str2 wurde in Zeile 2 mit einem Literal der Länge 3 initialisiert, und danach hat sich nie wieder etwas daran geändert.

Zum dritten Mal: strcpy ändert nichts an den Zeigern, es kopiert nur Inhalt durch die Gegend. Wenn str1 vorher auf einen Speicherbereich der Länge 5 gezeigt hat, tut es das auch hinterher.