Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
volta
Anmeldungsdatum: 04.05.2005 Beiträge: 1876 Wohnort: D59192
|
Verfasst am: 01.07.2009, 20:38 Titel: |
|
|
OneCypher hat Folgendes geschrieben: | @Volta: Hehe! Bei deinem satirischen Beispiel bist du genau in die Falle getappt.. | Nein, ich bestimmt nicht
OneCypher hat Folgendes geschrieben: | Wenn ich bei der Volksbank bin, kann ich auch geld am Automaten der Sparkasse bekommen | .. und das wird dann auch von einem Konto der Sparkasse (nicht von deinem Konto bei der Volksbank) abgebucht?
Wo wohnst du und welchen Geldautomaten benutzt du??  _________________ Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
Nach oben |
|
 |
The_Muh aka Mark Aroni

Anmeldungsdatum: 11.09.2006 Beiträge: 718
|
Verfasst am: 01.07.2009, 21:34 Titel: |
|
|
OneCypher hat Folgendes geschrieben: | Zurück zum eigentlichen Problem:
Teilweise hab ich noch viel häftigere Konstrukte als die ich hier schon erwähnte. Und nach jedem Element muss man entweder nachsehen oder raten obs ein . oder ein -> ist, was man dazwischenfügen soll. |
Raten? Nö, dazu muss man nur nachvollziehen können was der eigenen Code macht. Gibt ne funktion nen pounter zurück (auf nen udt) muss man eben -> nutzen, gibt die funktion gleich den UDT wieder, nimmt man den punkt. Ich hab in MuhBot teilweise recht üble verschachtelungen drin (eine davon ist im trash-thread zu bewundern) und die hab ich gebastelt ohne mich einmal mit den operatione verhaspelt zu haben.
OneCypher hat Folgendes geschrieben: | Und für meine Aufgaben reichts leider nicht aus UDTs per Value zurückzugeben. Ich möchte ja eigentlich immer ans original ran. Daher dann Pointer auf UDTs. Ist halt blöd, aber es geht bisher nicht anders... |
Blöd ist das nicht. Ich hab teilweise nen UDT per allocate direkt in nem any ptr, nur muss man sich fragen ob man solche probleme nicht anders lösen kann. Manchmal reicht es da schon wenn man die verarbeitenden Subs / Funktionen mit in das UDT packt, sollte das nicht gehen, musst du gucken ob ein shared nicht besser wäre (an die alten hasen: bitte nicht hauen).
mfg
The_Muh _________________ // nicht mehr aktiv // |
|
Nach oben |
|
 |
croco97

Anmeldungsdatum: 04.11.2005 Beiträge: 260
|
Verfasst am: 02.07.2009, 11:04 Titel: |
|
|
OneCypher hat Folgendes geschrieben: |
Teilweise hab ich noch viel häftigere Konstrukte als die ich hier schon erwähnte. Und nach jedem Element muss man entweder nachsehen oder raten obs ein . oder ein -> ist, was man dazwischenfügen soll.
|
Dann ist was schiefgegangen. Grundsätzlich gilt (best practice...)
Code: |
1. Alloziiere alles auf dem Heap - es sei denn, es ist temporär und klein.
2. Keine globalen Objekte auf dem Stack
|
Damit hast du in 1. Ordnung keine Ambiguität mehr: Alle globalen oder "globaleren" UDT's sind ->. Nur lokale kleine UDT's können mal statisch sein.
Ein bisschen anders sieht's in komplexen Projekten mit komplexen UDT's aus, bei denen die Member z.T. dynamische Verweise (wie bei einer Liste) sind und z.T. eigene Member mit eigenem Speicherplatz. Aber selbst da sollte die Irritation sich in Grenzen halten. Grosse und komplexe Klassen mit vielen Unterklassen und Verweisen wirst du auch oft benutzen und damit die Struktur auch bald auswendig kennen.
GTK+ übrigens verzichtet vollkommen auf irgendeine Form von statischer Allokation. Alles wird ausschliesslich über Zeiger angesprochen. Ist manchmal ein bisschen umständlich, wenn man für jede einzelne Farbvariable ein "allocate" starten muss, aber insgesamt ist es OK.
VG!
Croco |
|
Nach oben |
|
 |
OneCypher
Anmeldungsdatum: 23.09.2007 Beiträge: 802
|
Verfasst am: 20.07.2009, 16:33 Titel: |
|
|
"GTK+ übrigens verzichtet vollkommen auf irgendeine Form von statischer Allokation."
Aha.. hab mir mal den einen oder anderen GTK+ Text angeguckt.. da wird ja wirklich überall nur noch hingezeigt..
Kann es irgendwo, irgendwie zu Problemen führen, wenn nur noch die Zeiger aufm HEAP liegen und der ganze Rest aufm STACK?
Ich mein, irgendwas muss ja immer aufm Heap liegen.. mindestens die Zeiger.. aber man kann ja auch Zeiger auf Zeiger auf [...] auf Zeiger auf den Stack legen.. aber das wird wahrscheinlich in den seltensten fällen sinnvoll sein.. |
|
Nach oben |
|
 |
|