heap oder data segment?

[scales of justice]

man kann Arrays ja an verschiedenen Orten im Speicher anlegen:

Stack:

int main()
{
 int array[10];
 ...
}

Heap:

int main()
{
 int *array;
 array = malloc(40);
 ...
}

Data Segment:

int array[10];

int main()
{
 ...
}

das man Arrays nicht auf dem Stack ablegen sollte weiß ich, aber wie siehts mit Heap und Data Segment aus?
Sollte man wenn man keinen dynamischen Array braucht lieber den Heap oder das Data Segment benutzen?
oder ist das völlig egal?

[c.rackwitz]

globale variablen sind zu vermeiden. gruende findest du bitte selbst.

[vista]

hi,
das data segment (bss) hat gewisse vorteile:
- nicht initialisierte variablen werden mit 0 vorbelegt.
- keine speicheranforderung zur laufzeit nötig, der speicher ist garantiert verfügbar, wenn nicht, geht's schon das linken schief.
- der code ist auch auf systemen ohne heapverwaltung compilierbar.
- informationsaustausch über globale variablen kann sehr effizient sein, weil keine funktionsargumente und rückgabewerte benötigt werden.
- gute ausnutzung des RAMs auf systemen, die wenig davon haben.

c.rackwitz schrieb:

globale variablen sind zu vermeiden

was natürlich völliger unsinn ist.
man kann die 'globalität' z.b. einschränken, indem man die variablen static macht.

[AJ]

vista schrieb:

hi,
das data segment (bss) hat gewisse vorteile:
- nicht initialisierte variablen werden mit 0 vorbelegt.
- keine speicheranforderung zur laufzeit nötig, der speicher ist garantiert verfügbar, wenn nicht, geht's schon das linken schief.
- der code ist auch auf systemen ohne heapverwaltung compilierbar.
- informationsaustausch über globale variablen kann sehr effizient sein, weil keine funktionsargumente und rückgabewerte benötigt werden.
- gute ausnutzung des RAMs auf systemen, die wenig davon haben.

c.rackwitz schrieb:

globale variablen sind zu vermeiden

was natürlich völliger unsinn ist.
man kann die 'globalität' z.b. einschränken, indem man die variablen static macht.

Ich frag mich echt, warum Funktionen überhaupt noch Parameter haben, wenn globale Variablen so toll sind.

Nur gut, dass nicht jeder Softwarehersteller so denkt. Ich stell mir grad vor wieviel Arbeitsspeicher ich bräuchte, wenn ich Windows Vista mit allen Office-Programmen laufen lassen würde...

[vista]

AJ schrieb:

Ich stell mir grad vor wieviel Arbeitsspeicher ich bräuchte, wenn ich Windows Vista mit allen Office-Programmen laufen lassen würde...

was hat das mit globalen variablen zu tun?

[volkard]

das man Arrays nicht auf dem Stack ablegen sollte weiß ich, aber wie siehts mit Heap und Data Segment aus?

natürlich legt man arrays auf den stack. nur keine großen.

speed: global ist immer da. stack ist sauschnell angelegt (ein takt oder zwei) und kostenlos gelöscht. heap ist dagegen lahm, anlegen und löschen im bereich mehrere hundert takte. die hunderte von takten sind irrelevant, wenn es um arrays mit tausenden von einträgen geht.

speicher: stack braucht nur einmal pro aktuell gebarauchter instanz. sagen wir mal, wir haben zehn funktionen, die jeweils so ein array ihr eigen nennen, und die sich nicht gegenseitig aufrufen. dann wird im ram nur einmal der platz benötigt. heap braucht nur einmal pro gebrauchter instanz. vorsicht beim rausgehen aus funktionen, im gegensatz zum stack löschen sich heap-arrays nicht von alleine. globale brauchen pro jemals gebrauchter instanz speicher, sind deswegen eher indiskutabel.

grenzen: der stack auf normalen pc-compilern nicht größer als 1M werden. die globalen dürfen saugroß werden. die auf dem heap dürfen riesig werden.

meine empfehlung: alle variablen gehören immer auf den stack, solange es keine gewichtigen gründe dagegen gibt. die gewichtigen gründe sind:
große arrays gehören auf den heap.
1M gar nicht so viel speicher ist und schnell verbraucht ist.
soll die lebensdauer erhöht werden, legt man die variable entsprechend weiter oben im aufrufbaum an.
will man erst bei der ersten verwendung anlegen und dann leben lassen, nimmt man static (quasi global). aber das ganze array static oder nur nen zeiger static und das array auf dem heap? hängt wieder nur von der größe ab.
will man am anfang anlegen und leben lassen, nimmt man global, aber auch hier bestimmt die größe des arrays, ob man den heap nimmt.

vista schrieb:

hi,
das data segment (bss) hat gewisse vorteile:
- nicht initialisierte variablen werden mit 0 vorbelegt.

naja, dann initialisiert man eben.

- keine speicheranforderung zur laufzeit nötig, der speicher ist garantiert verfügbar, wenn nicht, geht's schon das linken schief.

oder das laden.

- der code ist auch auf systemen ohne heapverwaltung compilierbar.

exotisches argument. da muß ich dagegenhalten, daß man code mit globalen variablen schlecht auf systeme crosscompilieren kann, die einen brainfuck-prozessor haben.

- informationsaustausch über globale variablen kann sehr effizient sein, weil keine funktionsargumente und rückgabewerte benötigt werden.

jo. kann. aber das mit den parametern und rückgabewerten ist auch schon recht fix.

- gute ausnutzung des RAMs auf systemen, die wenig davon haben.

versteh ich nicht. globale variablen nicht im ram? wo denn sonst?

c.rackwitz schrieb:

globale variablen sind zu vermeiden

ich finde auch, daß man sie meiden sollte.

[Paddy82]

da muß ich dagegenhalten, daß man code mit globalen variablen schlecht auf systeme crosscompilieren kann, die einen brainfuck-prozessor haben

Volkard, danke viel besser kann ein Arbeitstag nicht anfangen

[vista]

volkard schrieb:

- informationsaustausch über globale variablen kann sehr effizient sein, weil keine funktionsargumente und rückgabewerte benötigt werden.

jo. kann. aber das mit den parametern und rückgabewerten ist auch schon recht fix.

...aber eben nicht so fix wie der direkte zugriff

volkard schrieb:

- gute ausnutzung des RAMs auf systemen, die wenig davon haben.

versteh ich nicht. globale variablen nicht im ram? wo denn sonst?

es gibt etliche systeme, die 8K, 4K oder weniger RAM haben. eine heapverwaltung für so wenig RAM zu verwenden ist pure speicherverschwendung.
...und stackmemory ist im normalfall sehr begrenzt.

volkard schrieb:

c.rackwitz schrieb:

globale variablen sind zu vermeiden

ich finde auch, daß man sie meiden sollte.

und warum?

[Paddy82]

vista schrieb:

volkard schrieb:

c.rackwitz schrieb:

globale variablen sind zu vermeiden

ich finde auch, daß man sie meiden sollte.

und warum?

Das kann ich dir genau sagen:

!! SEITENEFFEKTE !!

In einem grossem Projekt sind viele globale Variablen der letzte mist....

Ich spreche da aus Erfahrung

Wenn mir in unserem System Fehler auffallen, kann ich mindestens einen halben Tag warten, weil meine Kollegen durch zig Quellen schauen und sich immer nur wundern, warum "Variable XY den Wert Z" hat. Nach einigen Stunden stellt sich dann herraus, dass Variable XY ja noch an diversen anderen Stellen benutzt und dort auch verändert wurde.

Man kann natürlich sagen, schlecht programmiert, aber ich finde, dass man, wenn man mit so wenig globalen Variablen wie möglich arbeitet, sicherer fährt.
Es ist für Programmierer, die nicht so sauber programmieren können, einfach nicht so schnell möglich Fehler zu produzieren. Und solche Programmierer findet man in jedem größeren Projekt...

Alle meinen man sollte goto vermeiden, aber im nächsten Atemzug schreiben sie 100 Module in denen sie globale Variablen verändern, ohne es ausreichend zu Dokumentieren, oder ohne beim Benutzen der Variablen die Doku zu lesen.

[scales of justice]

was ist dann überhaupt wenn man in einer Funktion einen statischen Array anlegt?
wird der direkt beim linken im data segment angelegt, oder wird der bei erster Benutzung im Heap angelegt?
auf den Stack geht ja eigentlich nicht

[LordJaxom]

vista schrieb:

AJ schrieb:

Ich stell mir grad vor wieviel Arbeitsspeicher ich bräuchte, wenn ich Windows Vista mit allen Office-Programmen laufen lassen würde...

was hat das mit globalen variablen zu tun?

Globale Variablen sind global. Omnipräsent sozusagen. Stack wird nach Durchlauf einer Funktion abgeräumt, Heap wird vom Programmierer aufgeräumt. Globale Variablen nicht.

Das merkt man sehr deutlich bei z.B. COBOL, wo es nur globale Variablen gibt. Da wird dann z.B. in die Trickkiste gegriffen um größere Bereiche mehrfach zu belegen a la unions (übel, übel, übel)...

[CStoll]

scales of justice schrieb:

was ist dann überhaupt wenn man in einer Funktion einen statischen Array anlegt?
wird der direkt beim linken im data segment angelegt, oder wird der bei erster Benutzung im Heap angelegt?
auf den Stack geht ja eigentlich nicht

Statische Variablen landen im Data-Segment. Der einzige Vorteil gegenüber globalen Variablen ist, daß sie nicht direkt von außen erreichbar sind (indirekt kommst du immer dran - und damit sind sie fast genauso schlecht wie globale Variablen).

[vista]

Paddy82 schrieb:

vista schrieb:

volkard schrieb:

c.rackwitz schrieb:

globale variablen sind zu vermeiden

ich finde auch, daß man sie meiden sollte.

und warum?

Das kann ich dir genau sagen:

!! SEITENEFFEKTE !!

In einem grossem Projekt sind viele globale Variablen der letzte mist....

was glaubst du wohl, wieviele globale variablen im kernel des erfolgreichsten OS der welt stecken? dutzende!
mit globalen variablen ist es wie mit 'goto', man muss genau wissen was man tut.

btw: programmieranfängern wird ja immer von globalen variablen und gotos abgeraten. zu recht übrigens, wie sollen sie lernen strukturiert zu coden wenn sie alles global machen, weil's besonders einfach ist?
...aber wenn im wirklichen leben der einsatz von globalen variablen einen echten vorteil bringt (sie müssen dazu natürlich gut dokumentiert sein und selbsterklärende namen haben), sollte man sie auch benutzen.

LordJaxom schrieb:

vista schrieb:

AJ schrieb:

Ich stell mir grad vor wieviel Arbeitsspeicher ich bräuchte, wenn ich Windows Vista mit allen Office-Programmen laufen lassen würde...

was hat das mit globalen variablen zu tun?

Globale Variablen sind global. Omnipräsent sozusagen. Stack wird nach Durchlauf einer Funktion abgeräumt, Heap wird vom Programmierer aufgeräumt. Globale Variablen nicht.

ja, das sollte jedem klar sein, der globale variablen benutzt.
aber ich kann immer noch nicht verstehen, was globale variablen mit vista und office zu tun haben. wieso sollte man mehr speicher benötigen?

[RIESEN_PFUIIII]

[quote="Paddy82]
Man kann natürlich sagen, schlecht programmiert, aber ich finde, dass man, wenn man mit so wenig globalen Variablen wie möglich arbeitet, sicherer fährt.
Es ist für Programmierer, die nicht so sauber programmieren können, einfach nicht so schnell möglich Fehler zu produzieren. Und solche Programmierer findet man in jedem größeren Projekt...
[/quote]

Du bekommst von mir ein "RIESEN PFUI!!!!!!!!" für die Aussage auf die Stirn tätowiert. Geben wir doch lieber die Schuld denen die den Zeitaufwand nicht bezahlen wollen der richtig guter Code wert ist!!!

PS.: ...brainfuck-Prozessor kriegt auch ein Pfui

[AJ]

vista schrieb:

Paddy82 schrieb:

vista schrieb:

volkard schrieb:

c.rackwitz schrieb:

globale variablen sind zu vermeiden

ich finde auch, daß man sie meiden sollte.

und warum?

Das kann ich dir genau sagen:

!! SEITENEFFEKTE !!

In einem grossem Projekt sind viele globale Variablen der letzte mist....

was glaubst du wohl, wieviele globale variablen im kernel des erfolgreichsten OS der welt stecken? dutzende!

Wahrscheinlich ein wenig mehr wie gotos :p
btw: erfolgreichstes OS = ???

vista schrieb:

mit globalen variablen ist es wie mit 'goto', man muss genau wissen was man tut.

Richtig und darum versucht man auch sie zu vermeiden. Nur weil ich mit goto umgehen kann, würde ich trotzdem nicht auf die Idee kommen auf Schleifen zu verzichten.

vista schrieb:

...aber wenn im wirklichen leben der einsatz von globalen variablen einen echten vorteil bringt (sie müssen dazu natürlich gut dokumentiert sein und selbsterklärende namen haben), sollte man sie auch benutzen.

Dafür sind sie schlussendlich auch da.

vista schrieb:

LordJaxom schrieb:

vista schrieb:

AJ schrieb:

Ich stell mir grad vor wieviel Arbeitsspeicher ich bräuchte, wenn ich Windows Vista mit allen Office-Programmen laufen lassen würde...

was hat das mit globalen variablen zu tun?

Globale Variablen sind global. Omnipräsent sozusagen. Stack wird nach Durchlauf einer Funktion abgeräumt, Heap wird vom Programmierer aufgeräumt. Globale Variablen nicht.

ja, das sollte jedem klar sein, der globale variablen benutzt.
aber ich kann immer noch nicht verstehen, was globale variablen mit vista und office zu tun haben. wieso sollte man mehr speicher benötigen?

Nehmen wir mal an, dass die Programme (inklusive Betriebssystem) zu 25% aus globalen Variablen bestehen und nehmen wir weiter an, dass das Betriebssystem und 5 laufende große Programme (mal von sämtlichen Hintergrundprozessen und Pipapo abgesehen) 1GB Arbeitsspeicher belegen (mehr oder minder im Leerlauf).
Wieviel Arbeitsspeicher brauchst du dann, wenn alle Programme (inkl. BS) zu 50% aus globalen Variablen bestehen? (=> retorische Frage ;))

[volkard]

vista schrieb:

was glaubst du wohl, wieviele globale variablen im kernel des erfolgreichsten OS der welt stecken? dutzende!

ich bitte darum, daß du diese behauptung zurücknimmst oder einen nachweis erbringst.

[vista]

AJ schrieb:

Nehmen wir mal an, dass die Programme (inklusive Betriebssystem) zu 25% aus globalen Variablen bestehen und nehmen wir weiter an, dass das Betriebssystem und 5 laufende große Programme (mal von sämtlichen Hintergrundprozessen und Pipapo abgesehen) 1GB Arbeitsspeicher belegen (mehr oder minder im Leerlauf).
Wieviel Arbeitsspeicher brauchst du dann, wenn alle Programme (inkl. BS) zu 50% aus globalen Variablen bestehen? (=> retorische Frage ;))

ach, so meinst du das.
naja, du darfst nicht vergessen, dass win virtual memory und paging hat. alle segmente eines prozesses, heap, stack, BSS, code, etc. kommen aus demselben 'paged pool', und werden dynamisch alloziert, freigegeben oder auf die festplatte ausgelagert. aus sicht eines usermode-programms ist das völlig transparent d.h. es sollte keinen grossen unterschied machen, ob man sich 200MB mit malloc besorgt, oder dieselbe speichermenge als statisches array anlegt.
erst wenn aktuell ein speicherzugriff erfolgt, sorgt windows dafür, dass physikalisch auch speicher verfügbar ist (in 4K blöcken, sollte in dem augenblick kein speicher an diese adresse gemappt sein, lädt win die seite aus dem paging file oder alloziert einen neue).
es gibt unter win noch den 'nonpaged pool' (speicherseiten, die nicht ausgelagert werden, für DMA usw.). wenn man den zu ausgiebig beansprucht (geht aber nur im kernel mode), ist das natürlich nicht mehr so toll...

volkard schrieb:

vista schrieb:

was glaubst du wohl, wieviele globale variablen im kernel des erfolgreichsten OS der welt stecken? dutzende!

ich bitte darum, daß du diese behauptung zurücknimmst oder einen nachweis erbringst.

zum einen sind da die dokumentierten 'GlobalFlags'
--> http://www.osronline.com/ddkx/ddtools/gflags_7u5v.htm
viele weitere findest du, wenn du dir die geleakten win2k sources anschaust...

[volkard]

vista schrieb:

zum einen sind da die dokumentierten 'GlobalFlags'
--> http://www.osronline.com/ddkx/ddtools/gflags_7u5v.htm

was ist daran global?

und ein verweis auf geleakte kernels bringt deiner these nix.

[vista]

volkard schrieb:

vista schrieb:

zum einen sind da die dokumentierten 'GlobalFlags'
--> http://www.osronline.com/ddkx/ddtools/gflags_7u5v.htm

was ist daran global?

die sind insofern global, dass man diese sogar aus dem user mode verändern und damit das verhalten des ganzen systems steuern kann.
die anderen globalen variablen, die ich meinte, sind dem user-mode nicht zugänglich (einige davon schon, aber nur read-only). sie sind aber im kernel global und man kann sie auch böswillig verändern (machen z.b. rootkits so um usermode-prozesse zu verstecken etc.)
win ist übrigens trotzdem modular und objektorientiert aufgebaut und, meineer meinung nach, beisst sich das nicht mit der verwendung globaler variablen.

volkard schrieb:

und ein verweis auf geleakte kernels bringt deiner these nix.

ich muss dir nichts beweisen. wenn du der meinung bist, dass ich nur blödsinn schreibe, dann glaub das...

[supertux]

In Linux gibt es sowohl gotos als auch globale Variablen. Wer schon Kernel Module geschrieben hat, weiß das

Auszug aus Linux Device Drivers, Third Edition

Error recovery is sometimes best handled with the goto statement. We normally hate to use goto, but in our opinion, this is one situation where it is useful. Careful use of goto in error situations can eliminate a great deal of complicated, highly-indented, “structured” logic. Thus, in the kernel, goto is often used as shown here to deal with errors.

Und gerade im Kernel hat man manchmal keine andere Wahl als globale Variablen zu nehmen, und diese gibt es auch; da bin ich vistas Meinung.