@Lars: Nimm mal an, du schreibst an einem Großprojekt(~200000 Codezeilen)in einem Team.
Nimm weiter an, Du willst eine Klasse überschreiben, oder du mußt einen Fehler finden oder, oder, oder...
Nimm weiter an, dein Kollege hat des Stück vor einem jahr geschrieben (wenn Du Glück hast, weißt du wers war, aber da hörts oft auch schon auf.)...
Nimm weiter an(sorry für die Wiederholungen, aber mir fällt nix anderes ein), Dein Chef sitzt Dir im Nacken, weil der Kunde das Ergebnis noch gestern haben will...
Auf jeden fall: Du mußt gelegentlich Code lesen, der alt oder nicht von Dir oder beides ist und du mußt diesen Code auf einen Blick verstehen. Und dann hast du einfach keine Zeit auf Tooltips zu warten oder mit [Strg+Click] die Definition anzusehen.
@Lossey: Also ich weiß in 99% der Fälle eher den Typ der momentan benötigten Variable, als den Namen (Thema Zuweisungen).

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Eben, daher macht es keinen Sinn den noch vor jede Variable zu schreiben. Ausser es gibt dir zusaetzliche Infos wie bei einer Web Anwendung, da koennte man einem String noch hinzufuegen ob der save (also von html tags gefiltered etc) ist oder nicht. Solche Dinge machen schon Sinn imho.

PS: 200'000 Zeilen sind noch kein Gross Projekt. Das Projekt dass ich zur Zeit in Delphi offen habe hat 324872 Zeilen code. Und ich arbeite alleine daran

Ich denke mal, wenn du objekt orientiert programmierst, dann sagt ein o vor dem Namen für Objektypen recht wenig aus.
Für die internen Variablen ist bei Delphi f als Prefix vorgesehen.
Wie es bei C# gemacht werden soll, weiß ich nicht genau. Da nehme ich immer das gleiche Wort kleingeschrieben.

Objekte haben ja schon auch einen Typ von daher koennte man ja schon mehr als nur ein o schreiben, zb TFormForm1 oder so.
Ganz lustige Variabeln Namen wuerde es dann noch in C# geben wenn man generics verwendet.

@Sidorion
Also in diesem Fall würde ich dem Chef dringend anraten, die Deadline rauszuschieben oder sich selbst damit herumzuärgern - wenn es bei einem komplexen Projekt, an dem mehrere Leute arbeiten, keine gute Dokumentation (und klare Programmierrichtlinen) gibt, wird das ohnehin nur mit Glück etwas, wenn man später einsteigen möchte. Carad geht übrigens auch schon munter auf die 400000 Zeilen zu (bzw. liegt darüber, wenn einige Zusatzbibliotheken aktiviert sind) .
Im Übrigen denke ich dass es oftmals eher bremst, wenn mehrere Leute an einem Projekt arbeiten und ihre Aufgabengebiete nicht strikt getrennt sind - ich denke diese Erfahrung werden schon viele Leute hier gemacht haben, dass es oft effizienter ist, alleine an einem Projekt zu werkeln (gerade bei Gruppenarbeiten gibt es immer irgendwelche Wappler, die man allerhöchstens dazu brauchen kann, eine regelmäßige Versorgung mit Nahrungsmitteln und Getränken sicherzustellen)

Was die Nomenklatur anbelangt, liegt es an jedem selbst, das zu wählen, was am Besten gefällt, oder sich halt an die Richtlinien des jeweiligen Projektes zu halten. Hier sollten Programmierer ohnehin flexibel sein.
Ich selbst finde es z.B. äußerst praktisch, bei exzessiver Polymorphie bei Klasseneigenschaften den Klassentyp, in dem sie erstmalig auftreten als Kürzel mit anzugeben - damit tue ich mich dann leichter, bei Ableitungen die geeignete Basisklasse zu wählen, außerdem sehe ich dann sofort, wo eine Variable herkommt, bzw. ob es eine Objekteigenschaft oder eine lokale bzw. globale Variable ist. Andere tun das nicht und sind auch glücklich

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

genau das wollte ich auch sagen: Programmierrichtlinien sind ab einer bestimmten Größe des Projektes unbedingt erforderlich und dazu gehört eben auch eine Namenskonvention. Weil nur so kann man code von einem anderen im Team lesen, als hätte mans selber geschrieben.
Bei uns gibt es z.B. auch Vorschriften, wie die Einrückungen zu machen sind, und wo ein Then nach einem If zu stehen hat und so.

Ich denke bei diesem Thema geht es eigentlich um Lesbarkeit<>Schreibfaulheit. Ich für mein Teil kanns lieber lesen
was macht z.B. in C++ die Anweisung a=b*c; ? In Delphi und C wärs klar aber C++ nicht.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

In diesem Thema ging es eigentlich um was anderes

Habe noch eine Frage bzg. Optimierung:

Ich habe eine Klasse TCombobox, die wie eine normale Combobox geöffnet sein kann.
Hierbei darf maximal eine Combobox geöffnet sein.

Aktuell habe ich es so gelöst, dass ich eine globale Variable (in AppWindow) habe, die auf die offene Combobox zeigt.
Ich hätte es aber gerne ohne diese Varialbe. Ist ja kein Problem, durchläuft man halt alle Comboboxen und sie schliessen sich, wenn man nicht in sie geklickt hat.
Dadurch kann ich aber nach einem "Treffer", d.h. wenn der User auf eine Komponente geklickt hat, kann ich nicht abbrechen, sondern muss alle durchlaufen, da das nichttreffen jetzt auch wichtig ist.
Dadurch durchläuft mein Programm bei jedem Klick wesentlich mehr Schleifen als sonst notwendig (jedes Fenster muss durchlaufen werden, und jede Komponente von diesen auch).
Wie würdet ihr das Problem lösen?

Also ich habe in meiner Komponentensammlung auch schon einmal reichlich über dieses Problem nachgedacht. 100%tig genau weiß ich es bisher immer noch nicht. Meine ist komplett anders aufgebaut und vom Komplexibilitätsgrad wesentlich höher als die window(s).pas von Jan Horn. (auf die du ja aufbaust). Bei mir können mehrere Fenster existieren und gleichzeitig auf dem Rendercontext dargestellt werden. Es soll dann auch noch modale Fenster etc. geben. Und deine Aufklappung ist vom Prinzip her nichts anderes als ein modales Fenster. Welches aber nur wiederum ein Bestandteil der Comboboxklasse ist. Hier jetzt nicht Delphiklasse und "Fenster" vermischen.

Du könntest alle modalen Fenster bei der Hauptklasse registrieren und diese dann zeichnen wenn alle anderen Elemente bereits gezeichnet wurden. Das ist dann keine alleinstehende Variable mehr sondern gleich eine komplette Liste. Diese Lösung ist ziemlich viel Programmieraufwand und lohnt auch nur dann wenn man sehr komplexe hirarchien damit aufbauen möchte.

Die Quick & Dirty Lösung wäre, dass du dir an der CheckBox eine Klappstatus merkst und beim Zweiten mal nur noch einmal durch die Struktur durchgehst und alle ausgeklappten CheckBoxen zeichnest. Wenn alles richtig ist dürfte das nur eine sein. Alles andere sollte nicht sonderlich stören. Ich denke mal für die Komplexibilität sollte das auch vollkommen ausreichen.

Oder eben mit der einen Variable die es auch verhindert, dass du mehrere öffnen kannst und das durchsuchen geht auch schneller. Abgesehen davon werden so Mausevents auch gleich mit richtig verteilt. Ist zwar sehr hartcodiert aber ehrlich gesagt ist das dafür vollkommen ausreichend.

Du kannst auch glEnable(GL_POLYGON_OFFSET_LINE); und glEnable(GL_POLYGON_OFFSET_FILL); machen.
Die sorgen dafür daß wenn du die Linie/Polygon zeichnest beim Prüfen für den z-Puffer geschummelt wird, d.h. bevor du dein aufklappfenster malst dann setzt du mit glPolygonOffset und glLineOffset einen höheren Wert und danach wieder einen niedrigeren. Das führt dazu, daß das Aufklappfenster 'näher' an den Betrachter rückt und immer vor alle anderen komponenten gezeichnet wird.
Jetzt kannst du dein Aufklappfenster gleich beim Zeichnen der Combobox mitzeichnen, falls sie aufgeklappt ist.
Ist quasi so ne art z-Order Geschichte bei gleichen z-Werten. Löst nebenbei auch Z-fighting. Der einzigen Nachteil hiervon ist, wenn du das Fenster 'von hinten' siehst, ist die Aufklappbox trotzdem ganz sichtbar.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Das wäre auch noch eine Maßnahme aber dann könnte man doch auch gleich echte 3D Koordinaten übergeben. Dann spart man sich das getrickse mit dem ZBuffer. Spätestens beim Blending kommt es dann wieder auf die Reihenfolge des Gezeichneten an. Ich hatte die Möglichkeit schon glatt vergessen, da ich bei meinen Sachen auch ne Schnittstelle für gdi habe und des hat leider kein ZBuffer.

Ähem, ihr habt mich etwas falsch verstanden.
Mir geht es nicht darum wie ich das zeichne. Dies ist kein Problem. Die Comboboxen werden halt immer eine Ebene höhergeschoben und als letztes gezeichnet. Überschneidungen filtere ich dann beim erstellen dieser Komponenten raus.

Mir geht es um die Behandlung des MouseEvents.
Aktuell geht er jedes Fenster und jede Komponente einzeln durch und hört auf, sobald eine davon "getroffen" wird, d.h. in die Komponente geklickt wurde (wie im Original halt). Nach dem das gemacht wird, wird noch geschaut ob eine Combobox geöffnet wurde, wenn nicht schliesst er die bisher Geöffnete. Die (globale) Variable zeigt mir an ob eine Combobox geöffnet wurde und welche geöffnet ist.
Hat den Vorteil, dass nicht alle Komponenten durchlaufen werden, da maximal eins angeklickt werden kann.

Die Alternative wäre, dass ich die globale Variable weglasse und einfach alle Komponenten durchlaufe.
So kann sich die Combobox selbst schliessen.
So mache ich mich unabhängig von der globalen Variablen, muss aber immer alle Komponenten durchlaufen, auch wenn die angeklickte Komponente schon gefunden ist.

Es geht also um Laufzeit vs. globale Variablen.

Also eine globale Variable ist zwar aus Objekt orientierter Sicht nicht so sonderlich schön aber manchmal durchaus schon äußerst praktisch und leider teilweise absolut notwendig.

Um mal ein kleines absolut nicht passendes Beispiel in den Raum zu werfen. In meinem TexturenLoader habe ich eine hardcodierte Methode die ein Bild Vertikal flippt. Er nimmt sich das erste Pixel einer Zeile und kopiert es in ein anderes Bild ans Ende der Zeile. Das ganze ist halbwegs gut optimiert. Jetzt habe ich aber auch eine Funktionsschnittstelle. Bei der wird eine Procedur für jedes Pixel des Bildes aufgerufen und die bekommt eine ganze Reihe an Pointern übergeben. Rot Grün Blau getrennt. In der Methode muss ich mir dann ausrechnen welches Pixel ich haben will und muss mir die Daten davon holen. Das ist dann wiederrum ein Aufruf einer Methode die mir Pointer füllt. Und dann muss ich das Pixel Byte für Byte kopieren wo ich vorher das ganze Pixel kopieren konnte. Warum erzähle ich das jetzt? Ich wäre normal davon ausgegangen, dass die Funktionsschnittstelle so das 3-4 Fache der Zeit braucht wie die andere Methode. Das habe ich mal getestet. Habe ein 512x512 Bild 200 mal flippen lassen. Ein mal so und ein mal so. Hardcodiert waren es 5000 Millisekunden. Mit der Funktionsschnittstelle lediglich 200 ms mehr.

Fazit. Unterschätze nicht die Leistung eines Code der vermeindlich langsamer aussieht.

Ich denke also mal, dass der Code zum Durchsuchen nur minimal langsamer sein wird als das mit der globalen Variable. Außerdem darfst du nicht vergessen. Wie viele Elemente hast du den maximal. Lass es 30 Stück sein, dann sind es aber viele. Und viel wichtiger wie oft wird das denn aufgerufen. Auch nur, wenn der User klickt. Und dann spielt es keine Rolle mehr ob es 0.4 oder 1 ms dauert. Also denke ich mal, dass die Ausführzeit sehr vernachlässigbar ist.

Zu gut deutsch. Mach et so wie du es gerne machen möchtest und wie es für dich einfacher und besser aussieht. Ändern kannst du es später alle mal wieder, wenn es dir nicht zusagt.

PS: Die ganze Fensterverwaltung wäre nur dann richtig Effektiv, wenn du einen komplexen Fenstermanager einbauen würdest und massig Events an die Fenster sendest. So wie es im Windows der Fall ist. Aber das ist richtig kompliziert, komplex und ein riesen Aufwand.

Erst muß man sehen, dass der Code schön wird. Gute Optimierungsmöglichkeiten ergeben sich dann meist von selber.

Ich würde eine Variable nehmen, aber keine globale. Jedes Element hat n Unterelemente und die wiederum usw.. Ganz oben ist das root Element, in der Mitte sind die Knoten und ganz unten die Blätter.
z.B.:

Wenn du dir jetzt in jedem Knoten merkst, welches Unterelement gerade den Focus hat (kann Nil sein wenn keins) dann ist ganz einfach rauszukriegen, welches Element den Focus verlieren muss (und im Falle einer ComboBox z.B. zuklappen). Welches Element nach dem Click den Eingabefokus erhalten muß, kriegst du ja über Objektselektion raus.
Der Algorithmus ist einfach: Es gibt in der Elementklasse (Vorfahr von allen, damits alle können) die Methode SetFocus mit Übergabe ID.
Jetzt prüft jeder Knoten, in welchem seiner Kindknoten die ID bekannt ist(ID ist bekannt, falls ichs selber bin oder einem meiner Kindknoten die ID bekannt). der wird erstmal gemerkt. Jetzt teilt der Knoten dem kindknoten, in dem vorher die focus ID war mit, dass er den Focus verloren hat (mit SetFocus(Nil)) und der tut dann das selbe mit SEINEM Kindknoten, der vorher den Focus hatte. Dann teilt der Knoten noch dem Kindknoten, der die ID des neuen eingabeelements beinhaltet mit , dass er diese prozedur mit seinen Kindern wiederholen muss.
Das Ganze ist sowas in der Art wie eine Rekursion, nur daß in jeder Aufrufebene die Instanz wechselt.
Ich hoffe, das war verständlich

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Danke für eure Antworten.
Werde es wohl nun mit der globalen Variablen machen.

@Sideron:
Wenn ich mir das Unterelement merke, kann ich eigentlich auch direkten einen Zeiger (bzw. durch eine Klasseninstanz) nehmen.
Dann spar ich mir den Durchlauf eines Astes.