spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Meines Erachtens sind Setter bei Wertüberprüfungen sinnvoll, sonst könnte man sich die Arbeit sparen und auch globale Variablen benutzen. Heutzutage sehen jedoch viele Programmierer im Hinblick auf Globale Variablen das Böse, was ich ehrlich gesagt, nicht verstehen kann..

Zumindestens ein sehr praktischer Vorteil neben der möglichen Wertüberprüfung: Man kann nen Breakpoint auf die Zuweisung im Setter setzen. Dann kann man immerhin effektiv rauskriegen wenn der Wert von aussen fehlerhaft überschrieben wird. Zumindestens ist mir nicht bekannt, dass man den Debugger dazu bringen könnte, bei einer Zuweisung an eine bestimmte Speicheraddresse zu halten ...

Zitat von »Legend«

Zumindestens ist mir nicht bekannt, dass man den Debugger dazu bringen könnte, bei einer Zuweisung an eine bestimmte Speicheraddresse zu halten ...

Doch, das geht über Data Breakpoints.
Allerdings weiß ich nicht, wie die in einem Debugger genau umgesetzt werden. Könnte sein, dass das Programm dadurch bei der Ausführung unerträglich langsam wird, wenn der Debugger nach jeder Instruktion nachguckt, ob sich der Wert geändert hat.
Weiß jemand, wie Data Breakpoints umgesetzt werden? Vielleicht im Prozessor selbst?

Okay, interessant das es doch geht, aber klingt nach http://msdn.microsoft.com/en-us/library/350dyxd0.aspx nicht so komfortabel wie eine Setter in den man einen "normalen" Breakpoint reinsetzt.

Zitat

Addresses of variables change from one debugging session to the next. For this reason, data breakpoints are automatically disabled at the end of each debugging session.

Ich weiß nicht, wie performant diese sind, aber Breakpoints mit Bedingungen sind brachial langsam, also wirklich unerträglich langsam. Da schreibe ich dann meist lieber ein if mit dummy-Block und setze dadrin einen Breakpoint. Ich glaube nicht, dass sich Data-Breakpoints da besser verhalten.

ich weiß nicht, wie es in C++ ist, aber in C#, Java und Python ist es beispielsweise so, dass beim Werfen einer Exception der StackTrace in der Exception verfügbar ist, wodurch man auch zu der Stelle kommt, an der der Setter aufgerufen wurde
dazu muss man nur im Falle einer Fehlerhaften Zuweisung nicht einen geeigneten Wert zuweisen, sondern eine Exception auslösen

bezüglich Setter und Properties:
es gibt durchaus Fälle, in denen es nicht notwendig ist, das Ändern von Werten einzuschränken oder gesetzte Werte zu überprüfen (weil sie durch den Datentyp immer geeignete Werte sind)
wenn die verwendete Sprache dann auch noch Propertys unterstützt, macht es auch von der Handhabung keinen Unterschied und könnte ggf. später auch in eine Variante mit Gettern und Settern umgewandelt werden, ohne dass die Aufrufe angepasst werden müssen
allerdings halte ich nicht wirklich etwas davon, etwas an einer Stelle auf die eine Art (Getter und Setter/ Properties) und an einer anderen Stelle auf eine andere Art (frei zugreifbare Variable) umzusetzen

globale Variablen:
damit sind nicht öffentlich sichtbare Variablen gemeint, sondern global verfügbare Variablen (bzw. statische Variablen)
und diese werden nicht zu unrecht nicht gemocht

Meiner Erfahrung nach sind sowohl Data Breakpoints als auch Conditional Breakpoints durchaus performant und bisweilen unersetzlich. Kontext: Visual Studio 2010, C++. Data Breakpoints werden nach meinem Wissen hardwareseitig in der MMU umgesetzt. Conditional Breakpoints sind nach meinem Wissen nur normale Breakpoints, also auch hardware-seitig implementiert, aber der Debugger prüft nach jedem Break die Bedingung und setzt evtl. die Programmausführung ohne Meldung fort, wenn die Bedingung nicht erfüllt ist. Das kann ordentlich lahm werden, wenn der Breakpoint millionen Mal getroffen wird.

Vom gnu-Debugger weiß ich, dass er warnt, wenn die unterliegende Hardware keine Data Breakpoints unterstützt, und er versucht das dann softwareseitig zu emulieren... ich habe nach einigen Stunden abgebrochen, weil die Ausführung noch nicht mal in der main() angekommen war. Kontext hier: MIPS, glaube ich, irgendeine Embedded Gurke in einem Fernseher.

Und zum eigentlichen Thema: Getter und Setter empfinde ich bisweilen als nützlich, und zwar aus folgenden Gründen:

- öffentlicher Nur-Lese-Zugriff: also ein Getter, aber kein Setter
- Nebenwirkungen bei Zugriff: Pflicht-Getter, und Setter mit zusätzlicher Logik neben der reinen Zuweisung, z.B. Signale

wenn man dagegen für jede Membervar einen Getter und einen Setter schreibt, der nix weiter außer Zurückreichen bzw. Zuweisen macht, sollte man sich schon fragen, was da faul ist. Meistens empfiehlt sich dann eher eine dumme Struktur mit öffentlichen Variablen. Ich bin aber auch schuldig, bisweilen sowas geschrieben zu haben. Heutzutage schützt mich aber schon allein meine Faulheit Effizienzorientierung, weil man sich zumindest in C++ adlig tippt.

Jup, in C++ und selbst Java machen die Dinger keinen Spaß. In C# ist es fast kein zusätzlicher Aufwand eine Property zu erstellen. Da sind nur lesende oder welche mit zusätzlicher Logik schnell gemacht. Zumeist fragt man sich aber schon, ob die tolle Idee der Kapselung von Datenfeldern in Klassen nicht doch irgendwie in der Praxis in eine total dämliche Richtung gegangener Overhead ist.

PS:
Properties in Objective-C sind richtig schöner Overhead... ich sag nur synthesize...

PPS:
Ein wirklich guter Vorteil von Gettern und Settern ist aber eine Kapselung zwischen Interface und Implementierung. Getter/Setter kann man im Interface definieren und von der eigentlichen Implementierung kapseln, was bei Services und austauschbaren Plugins doch eine ganz nette Sache ist.

Wollte kurz was dazu sagen, dass Getter/Setter gegen das Prinzip der Kapselung verstoßen sollen. Die Kapselung bleibt vorhanden, wenn ich zum Beispiel einen Getter habe, welcher einen Integer liefert, weiß ich dennoch nicht was intern gespeichert ist. Möglicherweise ist dieser Wert so überhaupt nicht vorhanden und wird erst beim Aufruf berechnet, oder ist eigentlich ein float-Wert welcher beim Aufruf umgewandelt wird. Da gibt es ja mehrere Möglichkeiten, aber an sich weiß der Aufrufer auch so nicht was intern ist. Mir ist bewusst, dass viele da anderer Meinung sind, aber eigentlich ist die Kapselung noch vorhanden.

Das stimmt halt aber in der Praxis leider nur bei ca. 1% der Fälle. Bei allen anderen wird ja doch der Wert direkt übernommen oder zurückgegeben.