Variablen in eigenem Projekt private machen?
-
randa schrieb:
Wenn deine Get/Set Meothoden wikrlich sehr oft aufgerufen werden, wäre es auf Preformancesicht besser, du würdest die Public machen und auf Mehtoden verzichten.
Wozu gibt es inline?
-
randa schrieb:
Ich würde mal einen anderen Punkt auch reinbringen: Wenn deine Get/Set Meothoden wikrlich sehr oft aufgerufen werden, wäre es auf Preformancesicht besser, du würdest die Public machen und auf Mehtoden verzichten.
Da es generell eine kluge Idee ist, solch kleine Funktionen inline zu machen, bekommst du auch keine Performance Penalty.
-
Ich kenne inline, doch es ist nicht das gleiche wie der direkte Zurgiff. Abgesehen davon kann man größere Funktionen nicht inline machen.
Edit: Damit da klar ist: Ich rede nur von extremfällen in der Grafikprogrammierung, z.B. in der inneren Schleife der Rasterisierung o.ä. Ich sagte bereits, das natürlich eine Kapselung normalerweise vorzuziehen wäre.
-
Extreme Fälle erfordern manchmal extreme Lösungen. Bringen diese Vorteile, sollte man sie nutzen. Das hat aber nichts mit allgemeinen Design-Prinzipien zu schaffen.
-
randa schrieb:
Ich kenne inline, doch es ist nicht das gleiche wie der direkte Zurgiff. Abgesehen davon kann man größere Funktionen nicht inline machen.
Zu 1: Wenn da nur ein return var; drin steht wird es auch später im Programm nicht mehr sein, als ein klasse.var bzw. einfach die Adresse der Variablen.
Zu 2: Mein Compiler kann es z.B. mit __forceinline statt dem normalen inline, andere Compiler bieten es sicher auch an
-
Erhard Henkes schrieb:
Extreme Fälle erfordern immer extreme Lösungen. Bringen diese Vorteile, sollte man sie nutzen. Das hat aber nichts mit allgemeinen Design-Prinzipien zu schaffen.
Das habe ich ja auch nicht behauptet. Ich sagte: In einigen Fällen, in denen es Performance bringt, sollte man in Betracht ziehen, einen Direkten Zugriff zu ermöglichen.
-
randa schrieb:
Ich kenne inline, doch es ist nicht das gleiche wie der direkte Zurgiff. Abgesehen davon kann man größere Funktionen nicht inline machen.
Edit: Damit da klar ist: Ich rede nur von extremfällen in der Grafikprogrammierung, z.B. in der inneren Schleife der Rasterisierung o.ä. Ich sagte bereits, das natürlich eine Kapselung normalerweise vorzuziehen wäre.
Wenn mit deinem Compiler zwischen type.var und type.get_var() (wenn get_var inline ist), in der release version, auch nur ein Processordurchlauf Unterschied gibt dann schmeiß ihn sofort in die digitale Mülltonne.
-
randa: Es geht nicht darum, dass inline annähernd so schnell wie ein direkter Zugriff ist, sondern *genau so* schnell. Da ist es egal, ob das Objekt für Benutzereingaben oder in einer 3D-Engine verwendet wird; gleich schnell ist gleich schnell.
randa schrieb:
Abgesehen davon kann man größere Funktionen nicht inline machen.
Äh, stimmt? Wenn du getX() mit einem direkten Zugriff vergleichen willst, ist getX() ja per Definition nicht groß. Und wenn es groß sein sollte, fällt der direkte Zugriff eh raus.
Natürlich ist getX() nicht ganz so flexibel wie ein direkter Zugriff - man kann das zu Grunde liegende Feld nicht per Referenz an andere Funktionen übergeben usw. - aber davon war hier IMHO nicht die Rede.
-
Wenn du die Klasse nicht benutzt kanst du die Variabel ruhgen Gewissens public machen. Das Konzept ist für den normalsterblichen Hobbyprogrammierer sowieso etwas überdiemensioniert. Ich würde mal sagen wenn du weniger als 200 Zeilen Code (ohne die Klasse!) hast kannst du dir das Konzept schenken in dem Fall spielts wirklich keine Geige. Der ganze Code liegt später sowieso nur kompeliert vor (kann nicht mehr eingesehen werden). Wenn die Klasse also wirklich nur für dich ist ist es völlig egal, mach das was dir besser gefällt.
Lass dich von keinem hier von der Aussage beeindrucken "Das ist schlechter Stil" oder "das macht man nicht". Wie so oft führen viele Wege nach Rom. Solange es keinen Performancetechnischen Unterschied macht kanst du auch noch ganz andere Sachen machen.
Ein Freund von mir benutzt in seinen Klassen Konstanten die im Hauptquelltext definiert werden müssen. (<- da sage selbst ich "das geht eigentlich so nicht"), aber ihm ist das völlig egal und die Klasse die er so gemacht ist wirklich gut!
-
flammenvogel schrieb:
Lass dich von keinem hier von der Aussage beeindrucken "Das ist schlechter Stil" oder "das macht man nicht". Wie so oft führen viele Wege nach Rom. Solange es keinen Performancetechnischen Unterschied macht kanst du auch noch ganz andere Sachen machen.
schlechter stil wird durchaus zum problem sobald im team gearbeitet wird
aber zum thema möcht ich noch zwei punkte beisteuern
1. wenn es vollkommen egal ist welchen wert die mausposition hat könntest dus natürlich auch public machen
in einer set funktion hast du aber noch die möglichkeit die position zu kontolliern und abzuändern2. falls irgendwann ungültige werte gesetzt werden, kannst du in ner set funktion leichter per bedingtem breakpoint prüfen von wem der wert gesetzt wird.
falls die variable public is müsstest du halt einen breakpoint auf die speicheradresse setzen
-
"Das ist schlechter Stil" oder "das macht man nicht".
Hier wurde nicht in diesem Sinne argumentiert, sondern vielfach klare und nachvollziehbare Argumente vorgebracht. Hat man bessere Argumente, kann man diese ja nennen. Bisher habe ich jedoch noch kein stichhaltiges Argument gelesen, um eine Member-Variable public zu gestalten. Auch das Performance-Argument sticht nicht.
-
Erhard Henkes schrieb:
"Das ist schlechter Stil" oder "das macht man nicht".
Hier wurde nicht in diesem Sinne argumentiert, sondern vielfach klare und nachvollziehbare Argumente vorgebracht. Hat man bessere Argumente, kann man diese ja nennen. Bisher habe ich jedoch noch kein stichhaltiges Argument gelesen, um eine Member-Variable public zu gestalten. Auch das Performance-Argument sticht nicht.
Hey, ich sagte ja schon, ihr habt recht
Ehrlich gesagt hab ich mich hier auf einige Bereiche der Grafikprogrammierung bezogen, da ich vor ein paar Wochen genau dieses Problem hatte, und mich entschieden hab, es public zu machen. Aus dem Einfachen Grund weil ich in einer Inneren Schleife Zugriff auf mehrere Variablen einer Klasse brauchte.
-
Hey, ich sagte ja schon, ihr habt recht.
o.k.
Teste doch mal genau dieses Beispiel mit get-Funktionen (inline), damit du siehst, dass es wirklich kein Nachteil ist.
Aber den Schwerpunkt sollte man im "information hiding" sehen.
-
Ui hier hat sich ja einiges getan.
Es ist nun wirklich so das die variablen oft benutzt und verändert werden. Ich würde sagen das Projekt ist sogar relativ groß, ich bin noch fast ganz am Anfang, habe aber schon ~2400 Hardcodezeilen (code counter sei dank).
Wie sieht das nun mit der Performance aus?cd9000 schrieb:
randa schrieb:
Wenn deine Get/Set Meothoden wikrlich sehr oft aufgerufen werden, wäre es auf Preformancesicht besser, du würdest die Public machen und auf Mehtoden verzichten.
Nein.
operator void schrieb:
randa schrieb:
Wenn deine Get/Set Meothoden wikrlich sehr oft aufgerufen werden, wäre es auf Preformancesicht besser, du würdest die Public machen und auf Mehtoden verzichten.
Wozu gibt es inline?
groovemaster2002 schrieb:
randa schrieb:
Ich würde mal einen anderen Punkt auch reinbringen: Wenn deine Get/Set Meothoden wikrlich sehr oft aufgerufen werden, wäre es auf Preformancesicht besser, du würdest die Public machen und auf Mehtoden verzichten.
Da es generell eine kluge Idee ist, solch kleine Funktionen inline zu machen, bekommst du auch keine Performance Penalty.
Bin ich denn jetzt mit inline aus dem schneider?
-
Bin ich denn jetzt mit inline aus dem schneider?
... ansonsten sollst du deinen Compiler wegwerfen.
Miss es doch einfach selbst nach.
-
Immer dieses "miss es doch nach".
Ich will aber nicht empirisch herausfinden ob es so ist, sondern ich will wissen ob es so ist
-
ratlos439857 schrieb:
Ich will aber nicht empirisch herausfinden ob es so ist, sondern ich will wissen ob es so ist
Das wurde jetzt in mindestens 5 Postings zum Ausdruck gebracht. Der Vorschlag es zu messen sollte nur dich dazu bringen, es auch zu glauben. Wenn du es nicht glaubst kannst du dir ja den Assemblercode anschauen.
-
Das Stichwort inline bedeutet IMHO das überall wo die Funktion auftaucht, der Kompiler die Stelle vorm kompilen durch den Code der Funktion erstetzt.
Möglichkeit A:
Du läst die Funktion so wie sie ist (ohne inline).
In diesem Fall muss später das Programm immer, bei aufruf der Funktion, zur Definition der Funkton springen. Das ist dann meistens damit Funktion das sich das Programm einen vermerkt macht wo es stehen geblieben ist, vor aufruf der Funktion. Das kostet etwas Zeit.Möglichkeit B:
Du machst die kurzen oft benötigten Funktionen inline.
Dann erstetzt der Kompiler die Funktionsaufrufe im Quelltext durch den Code der Funktion. (so wie das bei #define ist). Bei kleinen Funktionen die oft aufgerufen werden spart man sich den Vermerk, das erhöht die Performance. Bei längern oft aufgerufen Funktionen, bläht sich der Quelltext dadurch aber sehr auf. Da IMHO (ich bin nicht ganz sicher!) das komplette Programm vor ausführung in den Hauptspeicher eingelese werden muss, kann es in diesem Fall auch Performance Verlust geben.Da ich jetzt den einzel Fall nicht kenne kann ich dir nicht sagen ob das schneller ist oder nicht.
PS: Korriegrt mich wenn es B Fehler gibt!
-
flammenvogel schrieb:
Du machst die kurzen oft benötigten Funktionen inline.
Dann erstetzt der Kompiler die Funktionsaufrufe im Quelltext durch den Code der Funktion. (so wie das bei #define ist). Bei kleinen Funktionen die oft aufgerufen werden spart man sich den Vermerk, das erhöht die Performance. Bei längern oft aufgerufen Funktionen, bläht sich der Quelltext dadurch aber sehr auf. Da IMHO (ich bin nicht ganz sicher!) das komplette Programm vor ausführung in den Hauptspeicher eingelese werden muss, kann es in diesem Fall auch Performance Verlust geben.IMHO ist das eher nicht der Fall, dass die komplette exe in den RAM geladen wird. Gegenbeispiel: 3dmark03.exe. Der Installer ist eine einzige, riesige exe-Datei. Trotzdem startet der Installer sofort, ohne komplett im Speicher zu landen. Einige Spiele arbeiten ähnlich.
inline-Funktionen machen allerhöchstens ein paar kb aus (und das ist schon viel). Eine Funktion, die ein paar Berechnungen durchführt, hat vielleicht 30-50 Bytes. Selbst wenn die 20 Mal inline aufgerufen wird, macht das noch kein Kilobyte aus.
Um den Speicherverbrauch sollte man sich bei inline heutzutage wirklich am wenigsten Gedanken machen.edit: Falls man einen On-Access-Viren-Scanner aktiv hat (
) merkt man manchmal, was es heißt, wenn die komplette exe in den Speicher geladen wird.
-
Damit wäre dann wohl geklärt, dass Member-Variablen nicht public sein sollen. public data bringen keinen Performance-Vorteil, keinen bedeutenden Speicher-Vorteil, dafür aber eine Verletzung des wichtigsten Prinzips der OOP.