Klotzkopp

http://www.codeproject.com/KB/shell/dotnetbandobjects.aspx?df=100&forumid=3788&exp=0&select=862248

Ich würde das nicht pauschal abwerten. Ich halte es eher für überflüssig, die nachfolgenden Bedingungen alle noch zu prüfen, wenn eine wahr ergeben hat. Genau das passiert aber, wenn man das ohne else macht.

Wenn du int durch int teilst, kommt dabei wieder int raus. Das Ergebnis dann einem double zuzuweisen, rettet die Rechnung auch nicht mehr. Mindestens einer der Operanden muss ein Fließkommatyp sein. Ein Cast reicht hier aus.

Das ist mehr oder weniger ein Schönheitsfehler. Aber lies doch bitte auch den Rest von flashpixx' Beitrag. Ich vermute übrigens, dass der Sinn dieser Aufgabe ist, dass du das Ergebnis wieder als Bruch ausgibst. Ansonsten wäre das wirklich zu einfach.

Zum eigentlichen Problem hat flashpixx schon alles gesagt. Ich hätte noch zwei Anmerkungen: fflush(stdin) erzeugt undefiniertes Verhalten, der Code ist dadurch nicht mehr portabel. Und bitte denk dir für deine Threads aussagekräftige Titel aus. Ich hab den hier mal für dich angepasst.

Welches Betriebssystem?

Du solltest srand nur einmal aufrufen. So initialisierst du jedesmal den Zufallsgenerator mit der Zeit in Sekunden, erhältst also während dieser Sekunde immer wieder denselben Wert von rand.

Fällt dir was auf? Das ist für C. Da geht's leider oftmals nicht anders. Die Lösung dafür ist dieselbe: Lass das mit den globalen Variablen, und mach dir ernsthafte Gedanken über eine saubere Modellierung der Beziehungen, Besitzverhältnisse und Lebensdauer deiner Objekte.

Visual C# selbst sollte das auch können, öffne die ausführbare Datei als Ressource. Und ich hoffe, dir ist klar, dass es da auch lizenzrechtliche Aspekte gibt.

Aber die sind doch sicher nicht vom Himmel gefallen, oder? Wie gesagt, üblicherweise ist die Nutzung einer Software an einen Lizenzvertrag gekoppelt. Da steht drin, was du mit der Software tun darfst und was nicht. Was möglich ist, ist da ziemlich egal.

Der Drucker und die Software wurden von Menschen gemacht, insofern ist davon auszugehen, dass es jemanden gibt, der das versteht. Ob es für dich verständlich ist, kann man kaum vorhersagen. Kann sein, dass der auszugebende Text im Klartext drinsteht, kann aber auch sein, dass Treiber und Drucker über eine proprietäre Seitenbeschreibungssprache kommunizieren und das ganze auch noch verschlüsselt wird. Im Prinzip handelt es sich um Reverse Engineering der Treibersoftware für XP. Du solltest prüfen, ob der Lizenzvertrag das überhaupt erlaubt.

Was willst du denn da abhören? Die Kommunikation des Treibers mit dem Drucker unter XP?

Wie äußert sich denn der Absturz? Ist das Programm einfach weg, oder erscheint eine Fehlermeldung?

Du kannst deine Beiträge bis zu 15 Minuten nach dem Erstellen bearbeiten. Zum Problem: Gibt es denn auf dem anderen Rechner ein Laufwerk D, und hat der Benutzer dort Schreibrechte?

Das kann viele Ursachen haben, meistens ist es schlampige Programmierung. Du kannst übrigens auch die Release-Version mit F5 debuggen, wenn auch mit gewissen Einschränkungen. Aber vielleicht reicht das ja, um nachzuvollziehen, an welcher Stelle das Programm aussteigt.

Und mit einem aussagekräftigen Threadtitel geht's gleich nochmal so gut. Bitte beim nächsten Thread selbst dran denken

Verbessert hat sich nur der Threadtitel. Die Problembeschreibung ist so schlecht wie zuvor. Mit "komme einfach nicht weiter" kann niemand etwas anfangen. Aber mal ein Tipp: Lerne den Unterschied zwischen der Variablen a und dem Zeichenliteral 'a', und dann frag dich nochmal, was du womit vergleichen möchtest. Und bitte schick nicht dieselbe Problemstellung per PN durch die Gegend.

Ich fürchte, dass $safeprojectname$ nur für Project Templates funktioniert.

Die Frage ist nicht, wann man es macht, sondern woraus. Man erstellt Testfälle nicht aus der fertigen Funktion, sondern aus der Spezifikation.

Für deine IDE solltest du in der Dokumentation nachsehen. In der Konsole kannst du das mit dem Kommando chcp herausfinden. Indem du entweder die Codierung der Konsole ermittelst (GetConsoleOutputCP) und entsprechend andere Strings ausgibst, oder indem du der Konsole ein bestimmte Codierung aufzwingst (SetConsoleOutputCP). Letzteres funktioniert aber nur, wenn die Konsole keine Rasterschriftart benutzt. Das ist natürlich Windows-spezifisch, eine portable Lösung gibt's nicht. Under Linux hast du dieses Problem in aller Regel nicht, weil da praktisch überall UTF-8 benutzt wird. Das hat allerdings wiederum andere Nachteile, wie z.B. dass die Länge eines Strings in Bytes von der Anzahl der Zeichen abweichen kann.

\xFC ist nicht generell die Escapesequenz für ü. Dein Problem hat mit Escapesequenzen eigentlich auch gar nichts nichts zu tun. Deine Konsole benutzt offenbar eine andere Zeichencodierung als du erwartest, das ist alles. Dass du im Code Escapesequenzen für Sonderzeichen benutzen musst, liegt auch nur daran, dass dein Editor eine andere Codierung als deine Konsole benutzt. 0xFC ist der Code für ü in ISO 8859-1. Dein Editor verwendet wahrscheinlich genau diese Codierung, also ist es völlig egal, ob du im Code \xFC oder gleich ü schreibst. Entscheidend ist die Codierung deiner Konsole, und die ist vermutlich Codepage 850. Da siehst du die hochgestellte 3 bei FC. Der richtige Code fürs ü wäre in diesem Fall also \x81.

Die Umstellung auf Zeiger war ein Schritt in die falsche Richtung. Jetzt hast du einen Operator, der PERSON mit einem Zeiger auf LIT vergleichen kann. Du vergleichst aber zwei Zeiger, dafür hast du keinen Operator überladen, du kannst es auch gar nicht. Ein weiteres Problem ist der Cast von other auf PERSON* in deinem Vergleichsoperator. Wenn der Parameter gar kein PERSON* ist (z.B. nur ein Zeiger auf ein LIT oder eine andere von LIT abgeleitete Klasse), dann hast du da undefiniertes Verhalten.

Dir ist aber klar, dass dein Programm momentan maxM nicht für die Anzahl der Schächte benutzt, sondern für die Größe? Letzlich musst du deine anz-Variablen durch ein einziges, dynamisches int-Array ersetzen. Weitere Arrays für die Münzwerte und -namen wäre wohl auch nicht schlecht. Und du solltest dringend von Fließkommatypen weg. 0.5 mag ja noch ohne Rundungsfehler in einen double passen, aber 0.2 oder 0.1 tut es nicht mehr. Fließkommatypen sollte man übrigens grundsätzlich nicht auf Gleichheit prüfen. Rechne besser komplett in Cent, dann kannst du ganzzahlige Variablen benutzen.

Es gibt bei diesem Programm aber keine sinnvolle Anwendung für dynamische Speicherverwaltung. Du brauchst doch nicht mehr Variablen, wenn du größere Schächte brauchst. Oder meinst du mehr Schächte?

Wie kommst du darauf, dass du dafür dynamische Speicherverwaltung brauchst? Du musst doch nur maxM mit dem Konstruktorparameter initialisieren.