Wo ist der Stack
-
Können globale Variablen im Daten- und im Codebereich liegen?
Tut mir leid das ich euch Löcher in den Bauch frage!
-
Lies dir Optimizer's Beitrag nochmal durch, dann ist eine Hälfte schon beantwortet. Globale Variablen können afaik auch im Codesegment liegen. Funktionen sind ja auch sowas wie globale Variablen mit festem Inhalt.
Allerdings sind solche Sachen wohl plattformabhängig.
-
HumeSikkins schrieb:
Gleichzeitig sagt der Standard, dass:
a) malloc, calloc, realloc, free nicht über new/delete implementiert werden dürfen,
b) zwischen new/delete und *alloc/free keinerlei Beziehung bestehen muss.sehr vernümpftig.
damit hat er faktisch erlaubt, daß man new über malloc implemetieren kann.für die leutchen, die sich um performance gedanken machen, gipt's noch einen untersched. der heap (malloc/free) ist für typische c-anwenungen optimiert und der freispeicher (new/delete) ist für typische c++-anwendungen optimiert. und das heißt konkret, daß malloc objekte beliebiger größen einigermaßen gut besorgt und daß new mehrkosten für große objekte zahlt, um kleinere objekte schnell zu besorgen. immerhinque ist while(file>>age>>sex>>location) bunnies.push_back(new Person(age,sex,location)); völlig normaler stil in c++. da muß new für viele kleine objekte rulen.
-
Gut, ich fasse zusammen:
Stack: lokale Variablen
Heap: allokierte Variablen
Datenbereich: static und globale Variablen
Codesegment: glabale Variablen
-
volkard schrieb:
der freispeicher (new/delete) ist für typische c++-anwendungen optimiert. und das heißt konkret, daß malloc objekte beliebiger größen einigermaßen gut besorgt und daß new mehrkosten für große objekte zahlt, um kleinere objekte schnell zu besorgen. immerhinque ist while(file>>age>>sex>>location) bunnies.push_back(new Person(age,sex,location)); völlig normaler stil in c++. da muß new für viele kleine objekte rulen.
Hmm, Alexandrescu schreibt das genaue Gegenteil (Modern C++ Design) und stellt deshalb ja seinen SmallObjAllocator vor. Ist das mittlerweile anders? Meine Ausgabe ist von 2003...
-
Cocaine schrieb:
volkard schrieb:
der freispeicher (new/delete) ist für typische c++-anwendungen optimiert. und das heißt konkret, daß malloc objekte beliebiger größen einigermaßen gut besorgt und daß new mehrkosten für große objekte zahlt, um kleinere objekte schnell zu besorgen. immerhinque ist while(file>>age>>sex>>location) bunnies.push_back(new Person(age,sex,location)); völlig normaler stil in c++. da muß new für viele kleine objekte rulen.
Hmm, Alexandrescu schreibt das genaue Gegenteil (Modern C++ Design) und stellt deshalb ja seinen SmallObjAllocator vor. Ist das mittlerweile anders? Meine Ausgabe ist von 2003...
Ich weiß nicht gegen was Alexandrescu seinen Allokator getestet hat, aber gegen die Standard-New-Implementation des VC 6.0 hatte das Ding nie auch nur den Hauch einer Chance. Das Kapitel in Modern C++ Design bespricht ein paar wichtige Dinge und die Theorie ist sicher richtig, die Implementation des Allokators kann man aber ohne weiteres in die Kategorie "nur zum Lernen geeignet" einsortieren. Eine praktische Relevanz hat das Ding nicht.
-
HumeSikkins schrieb:
Ich weiß nicht gegen was Alexandrescu seinen Allokator getestet hat, aber gegen die Standard-New-Implementation des VC 6.0 hatte das Ding nie auch nur den Hauch einer Chance.
Ja, ich war davon auch sehr enttäuscht. IMHO ist es auch nicht so gut möglich nur mit C++ Boardmitteln einen verdammt schnellen Allokator zu schreiben.
Volkards SmallAlloc ist dagegen ein verdammt geiles und schnelles Ding.
-
Mr.Schottky schrieb:
Codesegment: glabale Variablen
Lass das weg. Wie der Name schon sagt, befindet sich hier der ausführbare Code. Ich kenne auch keinen C++ Compiler, der hier vom User erstellte Variablen ablegt. Willst du sowas machen, musst du dich wohl in die Tiefen der Assembler Programmierung stürzen.
-
Shade Of Mine schrieb:
Volkards SmallAlloc ist dagegen ein verdammt geiles und schnelles Ding.
Kann man sich den irgendwo mal anschaun?
-
Cocaine schrieb:
volkard schrieb:
der freispeicher (new/delete) ist für typische c++-anwendungen optimiert. und das heißt konkret, daß malloc objekte beliebiger größen einigermaßen gut besorgt und daß new mehrkosten für große objekte zahlt, um kleinere objekte schnell zu besorgen. immerhinque ist while(file>>age>>sex>>location) bunnies.push_back(new Person(age,sex,location)); völlig normaler stil in c++. da muß new für viele kleine objekte rulen.
Hmm, Alexandrescu schreibt das genaue Gegenteil (Modern C++ Design) und stellt deshalb ja seinen SmallObjAllocator vor. Ist das mittlerweile anders? Meine Ausgabe ist von 2003...
alexandrescu schreibt, warum new praktisch nen small object allocator eingebaut haben sollte und warum malloc das nicht so braucht. außerdem sagt er, wie man sich einen selber machen kann, wenn man keinen im new drin hat. ich postuliere, daß nun endlich einer drin ist, weil die compilerbauer auch sein buch gelesen haben. oder sonstwie halt dafür sogen, daß new für c++ gut ist und malloc für c gut ist.