Klotzkopp

Mach dir klar, was /22 bedeutet: Die letzten beiden Bits der dritten Zahl gehören zum Host-Teil deines Netzes, also die 1er und die 2er. Dein Ausgangsnetz geht also von 193.168.172.0 bis 193.168.175.255.

Nein, es ist genau andersherum. Mit der Ausgangslage 193.168.172.0 /22 stehen genau diese 22 Bit nicht zur Verfügung, aus diesem Netz darf man nicht raus, es kann also nur der Host-Teil dieses Netzes weiter unterteilt werden. /25 ist schon richtig.

Ist aber nicht schön. Addiere ist bei dir nicht static, d.h. du musst diese Methode über ein Bruch-Objekt aufrufen, was du ja auch tust: Du schreibst: bruch1.Addiere. Dieses Objekt benutzt du aber gar nicht in der Methode. Statt dessen übergibst du dasselbe Objekt nochmals als Parameter. Entweder machst du die Methode static, oder du wirfst einen Parameter raus. So ist das Unsinn.

Wenn die Tabelle statisch ist, würde ich sie als Array von Strukturen anlegen: struct HGT { int H; int G; int T; } tabelle[] = { { 8, 11, 3 }, { 7, 55, 6 }, { 4, 43, 8 }, { 6, 41, 7 }, { 3, 30, 11 } }; [/code] Was die Umsetzung angeht: Wo genau klemmt es denn?

Au weia. Nur zur Information: Microsoft hat diesen Präfix vor etwa 20 Jahren für die MFC-Klassen benutzt, weil der C++-Compiler damals noch keine Namespaces beherrschte und man so Namenskonflikte vermeiden wollte. Mit "sauber" hat das nichts zu tun. Mach's so, wie es der Dozent will, aber merk dir, dass das eine sehr alte Notlösung für ein inzwischen nicht mehr vorhandenes Problem ist. getNenner und getZaehler hast du ins Spiel gebracht, wenn ich das richtig sehe. Deine Addiere-Funktion gibt einen Bruch zurück. Parameter sind die Dinger, die rein gehen. Richtig. Ich glaube, du hast überhaupt noch nicht verstanden, was Funktionen tun. Die Variablen in main und CBruch::Addiere haben nichts miteinander zu tun. Was du in main beim Aufruf von Addiere benutzt, landet in den Parametern bruch1 und bruch2 von Addiere. Dass die dieselben Namen wie Variablen in main haben, bedeutet gar nichts. Die könnten auch ganz anders heißen. Und es wäre für's Verständnis vermutlich auch besser, wenn sie nicht dieselben Namen hätten, damit das deutlich wird. Und wie die Variable heißt, die du als Rückgabewert benutzt, ist auch völlig egal. Du hast zwei Möglichkeiten: Bruch b = CBruch::Addiere(bruch1, bruch2); Bruch b = bruch1.Addiere(bruch2); Das kannst du dir aussuchen. Je nachdem sieht Addiere ein wenig anders aus. Die Version von Der_Lampe entspricht eher der ersten Variante, aber du musst darauf achten, die Methode in der Klassendefinition als static zu deklarieren.

In den meisten Fällen, die ich gesehen habe, sind Setter Mutatoren für genau eine Membervariable. Das kommt dabei raus, wenn man zu jeder Membervariablen reflexartig Getter und Setter anlegt. Und das sehe ich leider sehr häufig. Mit dem Verzicht auf Getter und Setter meine ich natürlich nicht, dass man statt dessen die dazugehörigen Member public macht. Das wäre noch schlimmer.

Um das mal zu konkretisieren: Wenn man die Klasse Bruch (was soll der Präfix C da?) ordentlich entwirft, kann main so aussehen: int main() { Bruch b1(4, 8); Bruch b2(2, 4); Bruch b = b1 + b2; cout << b; }[/code]Hier tauchen die Begriffe Zähler und Nenner nur als Bedeutung der Konstruktorparameter auf. So wäre das sauber. Und so ist das auch möglich. Ohne Getter und Setter.

Das Sortieren kann man sich sparen, es ist ein reines Problem des Findens des optimalen Weges. Da die Kästen und die Objekte schön durchnummeriert sind, steht ja von Anfang an fest, welches Objekt in welchen Kasten gehört.

Die Ausgabe hat nichts mit der Berechnung zu tun. Die Denkweise, die dich zu dieser (übrigens falschen) Annahme geführt hat, ist der Grund, warum ich überhaupt nichts von Gettern und Settern halte. Wenn man damit die interne Struktur einer Klasse eins zu eins auf die öffentliche Schnittstelle kopiert, lernt man nicht, dazwischen zu unterscheiden. Du solltest außerhalb der Klasse Bruch überhaupt nicht an Zähler und Nenner denken. Weder solltest du für die Ausgabe eines Bruchs getZaehler und getNenner aufrufen müssen (dafür braucht die Klasse eine Ausgabe-Methode), noch solltest du die Werte über Setter setzen (dafür gibt's Konstruktoren). Deine Addiere-Methode gibt einen Bruch zurück, und das ist auch genau richtig. Ein Bruch kapselt Zähler und Nenner. Wenn du außerhalb der Klasse überall mit Zähler und Nenner hantierst, machst du die Kapselung kaputt.

Nein, das wäre mathematisch falsch. Ersetze in Addiere (und nur dort) getNenner() durch Nenner und getZaehler() durch Zaehler. Das ist alles. Kürzen solltest du den Bruch danach übrigens auch noch. Da geschieht jedenfalls nichts mit der Addiere-Methode, weil du sie nicht aufrufst. Zeig mal, wie du die aufrufen möchtest. Wie soll Addiere in deinem Code benutzt werden? Dann kann man auch mehr darüber sagen, wie sie aussehen muss.

In der Headerdatei sollte nur die Funktionsdeklaration stehen, also nur der Kopf, nicht der Rumpf. Sonst gibt es ganz schnell Linkerfehler. #ifndef NAMEDERHEADERDATEI_H #define NAMEDERHEADERDATEI_H void foo(); #endif[/code]

Beschreib das beobachtete Verhalten (Fehlermeldung usw.), nicht das, was du für die Ursache hältst.

Habt ihr dafür eventuell Beispiele? Es ist für die Fehlersuche hilfreich, wenn wir das einfach reproduzieren können und nicht lange suchen müssen.

Ich weiß nicht, wie ich es anders beschreiben soll: Du brauchst an dieser Stelle keine get-Methoden. Du kannst direkt auf die private-Member zugreifen. Zeig doch bitte mal, wie du dir die Verwendung deiner Addier-Methode vorstellst.

Nein, die benötigst du nicht. Du kannst in der Addiere-Methode auch direkt auf Zaehler und Nenner zugreifen. Ich sehe das Problem nicht. Ist dir klar, dass du in deinem Programm mehrere Objekte deiner Bruch-Klasse erzeugst, und das jedes dieser Objekte seinen eigenen Zähler und Nenner hat? Auch deine Addiere-Methode erzeugt ein neues Bruch-Objekt. Damit kannst du doch machen, was du willst.

Welche Werte geben die Funktionen zurück?

Domänenbenutzer oder lokaler Benutzer?

Da hast du doch den berechenbaren Nutzen: Der Schaden, der durch das jetzt behobene Sicherheitsproblem hätte entstehen können, multipliziert mir der Wahrscheinlichkeit des Eintretens. Klassische Risikoanalyse. Möglicherweise schlecht abschätzbar, aber sicherlich möglich. Dass die Kosten auch angefallen wären, wenn du etwas anderes gemacht hättest, heißt nicht, dass dein Projekt nichts gekostet hat. Das ist eine Milchmädchenrechnung.

Dir ist aber klar, dass du nicht nur den Code, sondern möglicherweise auch die Datenbankstruktur ändern musst? Sobald jemand einen zweiten seriellen Drucker anschließt, passt dein Datenmodell nicht mehr. Und die Lösung ist nicht, dass du in Axis ein weiteres Fremdschlüsselfeld einbaust. Nimm die Fremschlüssel aus Axis raus, und füge in Axisprinter eine AxisID hinzu, sowie Felder, die Anschlussart und -nummer aufnehmen können. Aber was für ein reales Objekt repräsentiert ein Main-Datensatz? Hostname legt nahe, dass es sich um einen Rechner handelt. TypeID lässt eher auf einen Drucker schließen.

Ohne Beschreibung, worauf sich die jeweiligen Fremschlüssel beziehen, ist das schwer zu beurteilen. Bei einigen kann man es ja am Namen sehen, aber nicht bei allen. Wie sehen die Beziehungen aus? Was repräsentieren die einzelnen Tabellen (Main? Axis?) Ich sehe da jedenfalls ein Problem, wenn ein Printserver mehr als 2 LPT-Ports oder mehr als einen USB-Drucker hat. Warum legst du dich da derart fest?

Ob man in der Methode direkt auf die Member zugreift oder die Getter benutzt, darüber kann man sich sicher streiten. Aber ich habe ja beide Varianten erwähnt

Auch dafür muss ich die Nenner multiplizieren. Oder zumindest das KGV ermitteln.

Was hindert dich daran, Nenner * obj.Nenner zu rechnen? Oder getNenner() * obj.getNenner()?

Ist es denn jetzt keine Vorgabe mehr? Du hast doch vorher sowieso die Anforderungen des Auftraggebers erfasst. Da gehört das mit dazu: "Anforderung für die Entwicklung ist die XYZ Systemarchitektur."

Eine Projektdokumentation ist aber keine Erzählung, die die Arbeitsschritte auflistet. Das wäre ein Protokoll. Um bei deinem Beispiel zu bleiben: Dass der Test als Black-Box-Test durchgeführt wird, ist Ergebnis der Testplanung. Und sollte damit vor der Durchführung feststehen.