Wo Umrechnungsfunktionen einfügen
-
;fricky schrieb:
DarkGuardian schrieb:
Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin.
schon mal an 'funktionsobjekte' gedacht? dabei sind funktionen auch objekte, die man wie andere objekte behandeln kann (z.b. als parameter an funktionen übergeben, usw).
Du entäuscht mich.
Da bastelt jemand ein Objektorientiertes System um eine simple Multiplikation und von _dir_ kommt kein Flame
-
DarkGuardian schrieb:
Es gibt also doch noch einen Ansatz, auf den ich bisher nicht gekommen bin. Mal sehen, ob ich das so nutzen werde. Der einzige Nachteil dabei ist ja, dass man pro Umrechnung eine Klasse anlegt. Aber das kann verschmerzbar sein. Hängt halt von der Gesamtsituation ab.
Vielen Dank für den Hinweis.
Ich denke DEvent wollte nur zeigen, dass man nicht alles in einen OOP-Ansatz stopfen sollte. Der Code ist ja so ziemlich nutzlos und überladen und der Einsatz von Objekten macht ja gar keinen Sinn. Im OOP-Sinne ist er sogar fehlerhaft. Das umwandeln ist ja eine Aktion. Auch bei der OOP nutzt man freie Funktionen. Die Java-Leute haben zwar keine expliziten freien Funktionen eingeführt, weil man in den 90ern n bisschen verwirrt war was OOP betrifft. Aber die nutzen ja über statische Methoden an jeder Ecke im Endeffekt auch freie Funktionen. Ein Code wie der von DEvent ist ja eher ein DailyWTF. Wenn du schon Objekte einsetzen willst, dann nutze das lieber um die Werte mit Einheiten zu versehen.
@marmor kuchen
Nein, keine Macros. Dafür nimmt man doch sowohl in C als auch in C++ inline-Funktionen.
-
Icematix schrieb:
;fricky schrieb:
DarkGuardian schrieb:
Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin.
schon mal an 'funktionsobjekte' gedacht? dabei sind funktionen auch objekte, die man wie andere objekte behandeln kann (z.b. als parameter an funktionen übergeben, usw).
Du entäuscht mich.
Da bastelt jemand ein Objektorientiertes System um eine simple Multiplikation und von _dir_ kommt kein Flameer will doch unbedingt was oo-mässiges haben, warum sollte ich's ihm ausreden? ich persönlich würde auch einfach zwei makros nehmen (inline-funktionen für nur eine operation sind ziemlich sinnlos. der compiler wird sie immer auflösen, ob er nun für speed oder geringe codegrösse optimieren soll).
-
Funktionen. Dann kann man ggf. Überladungen anbieten. Makros haben ja, wie fricky schon erwähnt hat, hier keine Vorteile.
-
Tim schrieb:
Funktionen. Dann kann man ggf. Überladungen anbieten. Makros haben ja, wie fricky schon erwähnt hat, hier keine Vorteile.
als alter überladung-freak kannste ja auch makros mit #undef 'überladen' (falls dir mal ein anderer umrechnungsfacktor für meilen-nach-kilometer einfällt, oder so).
-
Selbst Kernighan (der steht für das K in K&R C) sagt, dass man heute keine Macros und lieber inline-Funktionen nehmen soll.
-
was erlaubt ist, wird auch benutzt
-
rüdiger schrieb:
Selbst Kernighan (der steht für das K in K&R C) sagt, dass man heute keine Macros und lieber inline-Funktionen nehmen soll.
seine meinung sei ihm gegönnt. ich jedenfalls finde makros garnicht so schlecht. es gibt z.b. compiler, die können nicht inlinen, wenn sich die inline-funktionen in anderen übersetzungseinheiten befinden. da kann man zwar tricksen, indem die funktionen in eine .h-datei verfrachtet werden, aber ich finde ausführbaren code in header-dateien unschön. wenn du bestimmte optimierungen einschaltest, wird sowieso einiges 'ge-inlined', ob du nun 'inline' davor schreibst, oder nicht.
^^alles bezogen auf C, in C++ mag das anders sein.
-
Du findest ausführbaren Code in Header-Dateien "unschön", aber Macros sind doch auch nichts anderes?
MfG SideWinder
-
SideWinder schrieb:
Du findest ausführbaren Code in Header-Dateien "unschön", aber Macros sind doch auch nichts anderes?
hmmm ja, das stimmt schon. nur sind makros (bei mir jedenfalls, bis auf ganz wenige ausnahmen) sehr klein, weniger als 5 zeilen, meistens einzeiler. und durch die durchgängige grosschreibung erkennt man sie im code auch sofort als makro. für alles was grösser ist, oder verzweigungen und schleifen enthält, rückgabewerte hat, usw. nehme ich dann auch lieber funktionen. ist halt wie immer: man sollte etwas weder verteufeln noch damit übertreiben.