globale Variablen mit 0 initialisieren?
hans eder
vorinitialisiert.
a) static long a[1024];
und
b) static long b[1024]={0};
ergeben also beide ein mit 0-en initialsiertes Array.
Nun wird in einem C-Lehrbuch (was ich gerade lese) behauptet, daß die
Variante b) die bessere sei
und man sich aus Gründen eines 'guten Programmierstils' dieses 'manuelle'
Initialisiseren von
globalen und static Variablen angewöhnen sollte.
Ich habe mich bislang immer auf die automatische, regelkonforme
Initialsierung dieser Variablen verlassen.
Zudem wird bei meinem Compiler das Programm durch die Initialsierung vom Typ
b) unötig vergrößert, da der Initialsierungsdatenblock (..= {0}) zum Code
gehängt wird.
gibt es wirklich gute Gründe für 'manuelle', doppelt-gemoppelte
Initialisierung?
--
hans eder
Helmut Schellong
>
> globale oder static Variablen werden vom Compiler immer mit 0
> vorinitialisiert.
>
> a) static long a[1024];
> und
> b) static long b[1024]={0};
>
> ergeben also beide ein mit 0-en initialsiertes Array.
>
> Nun wird in einem C-Lehrbuch (was ich gerade lese) behauptet, daß die
> Variante b) die bessere sei
> und man sich aus Gründen eines 'guten Programmierstils' dieses 'manuelle'
> Initialisiseren von
> globalen und static Variablen angewöhnen sollte.
Das ist kompletter Quatsch.
Wirf das Buch weg.
Mir gehen diese falschen Dinge aus schlechten C-Büchern
langsam auf die Nerven.
> Ich habe mich bislang immer auf die automatische, regelkonforme
> Initialsierung dieser Variablen verlassen.
> Zudem wird bei meinem Compiler das Programm durch die Initialsierung vom Typ
> b) unötig vergrößert, da der Initialsierungsdatenblock (..= {0}) zum Code
> gehängt wird.
Ganz genau!
Explizit initialisierte Objekte sind 'im Bauch' der Exe.
(Auch wenn es Default-0 ist.)
> gibt es wirklich gute Gründe für 'manuelle', doppelt-gemoppelte
> Initialisierung?
Nein, das ist sogar ein wenig irre!
Warum?:
static long b[1024]={0};
static long b[1024]={1}; //[1]
In beiden Fällen werden die letzten 1023 Elemente mit
Default-0 gefüllt!
Du gibst ja nur das erste Element *explizit* an!
static long b[1024];
Hier werden *alle* 1024 Elemente mit Default-0 gefüllt.
Aber erst beim Programmstart, bevor main() aufgerufen wird.
Das ist eindeutig besser.
Das würde ich sogar bei [1] machen!
Dann:
int main(void)
{
//...
b[0]=1;
//....
Im Zusammenhang mit dem ELF-Format und Paging-Mechanismen
sollte man vorinitialisierte Daten sogar möglichst vermeiden!
Eine InitVars()-Funktion ist ja durchaus eine oft gebrauchte
Maßnahme, um kleine Exe zu bewahren.
Außerdem kann man dann den Grundzustand wieder herstellen.
Desweiteren kann man vor nichtinitialisierte Variablen
'extern' schreiben, was das Projekt-Management erleichtert.
(var.c / var.h / #define EXTERN)
FAZIT:
Der Autor Deines C-Buches ist ein kleiner Spinner,
der viele 'verdirbt'.
Ich habe nämlich den Ausdruck '{0}' schon öfter hier
gesehen...
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
http://www.schellong.de http://www.schellong.com
http://home.t-online.de/home/schellong sche...@t-online.de
hans eder
3A8EF2F7...@t-online.de...
> > und man sich aus Gründen eines 'guten Programmierstils' dieses
'manuelle'
> > Initialisiseren von globalen und static Variablen angewöhnen sollte.
>
> Das ist kompletter Quatsch.
> Wirf das Buch weg.
> Mir gehen diese falschen Dinge aus schlechten C-Büchern
> langsam auf die Nerven.
Ok, das ist deutlich, meine Variablen werden weiterhin automatisch
initialisiert.
Neben der ungewöhnlichen Empfehlungen zum 'manuellen Initialisieren' finde
ich das Buch allerdings nicht schlecht, es geht sonst sehr genau und
ausführlich auf die Sprachkonzepte von C ein.
Das Buch heißt 'C als erste Programmiersprache, ISO Standard', 2. Auflage
> FAZIT:
> Der Autor Deines C-Buches ist ein kleiner Spinner,
> der viele 'verdirbt'.
> Ich habe nämlich den Ausdruck '{0}' schon öfter hier
> gesehen...
>
kleine Spinner, hmmm..
Bei den Autoren dieses Buches handelt es sich um Prof. Dr Joachim Goll,
Prof. Herbert Wiese und Uwe Günther. Hochkarätige Dozenten an der
Fachhochschule Esslingen, Fachbereich Informationstechnik, Lehrbeauftragte
für Software Engineering.
Folgende Ansichten werden die Autoren sicher auch in Ihren Vorlesungen
vertreten (Zitat aus dem Buch S.335):
"Statische lokale Variablen werden wie globale Variablen mit 0
initialisiert, wenn sie nicht manuell initialisiert werden.
Gewöhnen Sie sich aus Sicherheitsgründen eine manuelle Initialsierung
an!"
und zwei Seiten noch beim selben Thema:
"Generell sollte man es sich jedoch angewöhnen, alle Variablen selbst
manuell zu initialisieren."
Angesichts solcher Experten von der Hochschule bin ich dann doch unsicher
geworden und hab lieber hier nochmal gefragt - schönen Dank für prompte
Antwort.
--
hans eder
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> schrieb in im Newsbeitrag:
> 3A8EF2F7...@t-online.de...
>
> > > und man sich aus Gründen eines 'guten Programmierstils' dieses
> 'manuelle'
> > > Initialisiseren von globalen und static Variablen angewöhnen sollte.
> >
> > Das ist kompletter Quatsch.
> > Wirf das Buch weg.
> > Mir gehen diese falschen Dinge aus schlechten C-Büchern
> > langsam auf die Nerven.
>
> Ok, das ist deutlich, meine Variablen werden weiterhin automatisch
> initialisiert.
> Neben der ungewöhnlichen Empfehlungen zum 'manuellen Initialisieren' finde
> ich das Buch allerdings nicht schlecht, es geht sonst sehr genau und
> ausführlich auf die Sprachkonzepte von C ein.
> Das Buch heißt 'C als erste Programmiersprache, ISO Standard', 2. Auflage
Möglicherweise ist es insgesamt kein Schrott.
Aber ich fürchte, diverse Stammschreiber hier würden darin hunderte
von Stellen finden, die nicht okay sind, so sie denn dieses Buch
inhaltlich kennten - ich kenne es nicht.
>
> > FAZIT:
> > Der Autor Deines C-Buches ist ein kleiner Spinner,
> > der viele 'verdirbt'.
> > Ich habe nämlich den Ausdruck '{0}' schon öfter hier
> > gesehen...
> >
>
> kleine Spinner, hmmm..
Du hast meine Begründungen ja gesehen...
IMO sind die stichhaltig.
> Bei den Autoren dieses Buches handelt es sich um Prof. Dr Joachim Goll,
> Prof. Herbert Wiese und Uwe Günther. Hochkarätige Dozenten an der
> Fachhochschule Esslingen, Fachbereich Informationstechnik, Lehrbeauftragte
> für Software Engineering.
Möglicherweise (weitgehend) Theoretiker.
> Folgende Ansichten werden die Autoren sicher auch in Ihren Vorlesungen
> vertreten (Zitat aus dem Buch S.335):
> "Statische lokale Variablen werden wie globale Variablen mit 0
> initialisiert, wenn sie nicht manuell initialisiert werden.
> Gewöhnen Sie sich aus Sicherheitsgründen eine manuelle Initialsierung
> an!"
Haben die was gegen die 0 ?
> und zwei Seiten noch beim selben Thema:
> "Generell sollte man es sich jedoch angewöhnen, alle Variablen selbst
> manuell zu initialisieren."
Warum?
Die Entwickler von C haben doch sicher gute Gründe für die Default-0.
> Angesichts solcher Experten von der Hochschule bin ich dann doch unsicher
> geworden und hab lieber hier nochmal gefragt - schönen Dank für prompte
> Antwort.
Der C-Standard *garantiert* eine typgerechte 0-Initialisierung
aller statischen Objekte, die nicht explizit initialisiert wurden.
Dieses Konzept finde ich gut und praxisgerecht.
Jan Echternach
"hans eder" <ed...@online.de> writes:
> Nun wird in einem C-Lehrbuch (was ich gerade lese) behauptet, daß die
> Variante b) die bessere sei
> und man sich aus Gründen eines 'guten Programmierstils' dieses 'manuelle'
> Initialisiseren von
> globalen und static Variablen angewöhnen sollte.
>
> Ich habe mich bislang immer auf die automatische, regelkonforme
> Initialsierung dieser Variablen verlassen.
Nur wenn man sehr paranoid ist oder es mit einer etwas abartigen
C-Implementierung zu tun hat, braucht man die explizite
Initialisierung, um eine Initialisierung sicher zu stellen.
Das Hauptargument ist der Programmierstil: Fuer den Programmierer
macht es schon einen Unterschied, ob eine globale Variable
initialisiert werden muss oder nicht (und sieh nur eher "zufaellig" mit
0 initialisiert wird). Die explizite Initialisierung bei allen
absichtlich initialisierten Variablen (auch bei denen, die mit 0
initialisiert werden) erlaubt es dem Programmierer, diesen Unterschied
im Code auszudruecken.
> Zudem wird bei meinem Compiler das Programm durch die Initialsierung vom Typ
> b) unötig vergrößert, da der Initialsierungsdatenblock (..= {0}) zum Code
> gehängt wird.
Compiler-Entwickler treten - bzw. selber machen. ;-> Genau dieses
Thema wurde vor paar Monaten auf linux-kernel diskutiert. Das Ergebnis
war IIRC, dass nichts wirklich dagegen spricht, dass der Compiler eine
explizite Initialisierung mit 0 erkennt und sie genau wie eine
implizite Initialisierung mit 0 behandelt, ausser dass es vielleicht
erstmal jemand im Compiler implementieren muesste.
--
Jan
Helmut Schellong
>
> In article <96mpli$bo9$1...@news.online.de>,
> "hans eder" <ed...@online.de> writes:
> Nur wenn man sehr paranoid ist oder es mit einer etwas abartigen
> C-Implementierung zu tun hat, braucht man die explizite
> Initialisierung, um eine Initialisierung sicher zu stellen.
>
> Das Hauptargument ist der Programmierstil: Fuer den Programmierer
> macht es schon einen Unterschied, ob eine globale Variable
> initialisiert werden muss oder nicht (und sieh nur eher "zufaellig" mit
> 0 initialisiert wird). Die explizite Initialisierung bei allen
> absichtlich initialisierten Variablen (auch bei denen, die mit 0
> initialisiert werden) erlaubt es dem Programmierer, diesen Unterschied
> im Code auszudruecken.
Dann ist das aber nur logisch, wenn man *alle* Elemente explizit angibt.
Nur das erste auf 0 zu setzen, setzt ja voraus, dass man weiss, dass
der Compiler eben mit 0 weitermacht.
>
> > Zudem wird bei meinem Compiler das Programm durch die Initialsierung vom Typ
> > b) unötig vergrößert, da der Initialsierungsdatenblock (..= {0}) zum Code
> > gehängt wird.
>
> Compiler-Entwickler treten - bzw. selber machen. ;-> Genau dieses
> Thema wurde vor paar Monaten auf linux-kernel diskutiert. Das Ergebnis
> war IIRC, dass nichts wirklich dagegen spricht, dass der Compiler eine
> explizite Initialisierung mit 0 erkennt und sie genau wie eine
> implizite Initialisierung mit 0 behandelt, ausser dass es vielleicht
> erstmal jemand im Compiler implementieren muesste.
Das waere trotz allem zu begruessen,
eben weil nix dagegen spricht.
Wer seine Exe aus Abgeberei aufblasen will, der init. eben mit !=0
und ueberschreibt dann dies mit 0...
Rudolf Meyer
> Warum?
> Die Entwickler von C haben doch sicher gute Gründe für die Default-0.
Frage: Ist es nicht auch so, dass explizit initialisierte statische Variable
bei manchen Compilern diese zu const-Variable werden?
MfG
Rudolf Meyer
Helmut Schellong
Nein, ohne das Keyword 'const' darf das nicht geschehen.
Man könnte dann ja nicht hineinschreiben...
Ausnahme: "abcdefg" (Zeichenkettenkonstante)
Wolfgang Zogalla
>
> globale oder static Variablen werden vom Compiler immer mit 0
> vorinitialisiert.
>
globalen und statischen Variablen stehen, komplett mit 0 ueberschrieben.
Ist das wirklich immer gleich einer Initialisierung mit 0? Bei jedem
Typ? Anders ausgedrueckt:
Ist z.B.
double z= 0;
immer gleichbedeutend zu
double z; memset(&z, 0, sizeof(double)); ?
Bei den gaengigen Fliesskomma-Zahlenformaten ist das der Fall, aber wird
das garantiert?
Wolfgang
Helmut Schellong
Lies den Thread!
Dort steht genau das drin.
Eine *typgerechte* 'Nullung' wird garantiert.
Hans-Bernhard Broeker
> Frage: Ist es nicht auch so, dass explizit initialisierte statische Variable
> bei manchen Compilern diese zu const-Variable werden?
Nein. Du wirfst das glaube ich mit String-Konstanten durcheinander.
Die sind in der Tat automatisch effektiv 'const', obwohl es nicht dran
steht.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Stefan Reuther
Jan Echternach <ech...@informatik.uni-rostock.de> wrote:
> In article <96mpli$bo9$1...@news.online.de>,
> "hans eder" <ed...@online.de> writes:
>> Nun wird in einem C-Lehrbuch (was ich gerade lese) behauptet, daß die
>> Variante b) die bessere sei
>> und man sich aus Gründen eines 'guten Programmierstils' dieses 'manuelle'
>> Initialisiseren von
>> globalen und static Variablen angewöhnen sollte.
[snip]
> Das Hauptargument ist der Programmierstil: Fuer den Programmierer
> macht es schon einen Unterschied, ob eine globale Variable
> initialisiert werden muss oder nicht (und sieh nur eher "zufaellig" mit
> 0 initialisiert wird). Die explizite Initialisierung bei allen
> absichtlich initialisierten Variablen (auch bei denen, die mit 0
> initialisiert werden) erlaubt es dem Programmierer, diesen Unterschied
> im Code auszudruecken.
Ein anderer (stilistischer) Grund ist vielleicht, daß automatische
(lokale) Variablen eben nicht initialisiert werden. Wenn man eine
globale Variable per cut&paste in eine Funktion befördert, wird
sie auf einmal nicht mehr initialisiert.
Noch ein Grund: in C ist es erlaubt, eine Variable in zwei
compilation units zu definieren, wenn man sie maximal einmal
initialisiert.
$ cat foo.c
int x;
$ cat bar.c
int x = 1;
int main() { return 0; }
$ gcc foo.c bar.c
Wenn man sich angewöhnt, alle Variablen zu initialisieren, wird dieser
Fehler beim Linken erkannt.
Stefan, der seine Variablen nicht immer initialisiert
Helmut Schellong
>
> Hallo,
>
> Jan Echternach <ech...@informatik.uni-rostock.de> wrote:
>
> Ein anderer (stilistischer) Grund ist vielleicht, daß automatische
> (lokale) Variablen eben nicht initialisiert werden. Wenn man eine
> globale Variable per cut&paste in eine Funktion befördert, wird
> sie auf einmal nicht mehr initialisiert.
Manche Compiler weigern sich, auto-Objekte mit ={0};
zu initialisieren.
Und wenn der Compiler das erlaubt, wird ein doppeltes statisches
(internes) Objekt angelegt, das bei jedem Ueberlaufen des init.
auto-Objektes
in das auto-Objekt kopiert wird.
Das sollte man zumindest wissen.
> Noch ein Grund: in C ist es erlaubt, eine Variable in zwei
> compilation units zu definieren, wenn man sie maximal einmal
> initialisiert.
> $ cat foo.c
> int x;
> $ cat bar.c
> int x = 1;
> int main() { return 0; }
> $ gcc foo.c bar.c
> Wenn man sich angewöhnt, alle Variablen zu initialisieren, wird dieser
> Fehler beim Linken erkannt.
Durch 'extern' wird der Fehler auch erkannt.
extern-Objekte dürfen nicht init. werden.
Hans-Bernhard Broeker
[...]
> Noch ein Grund: in C ist es erlaubt, eine Variable in zwei
> compilation units zu definieren, wenn man sie maximal einmal
> initialisiert.
Das stimmt so nicht wirklich. Im Standard findet man das, wenn man
nach 'tentative definition' sucht (K&R2-deutsch: vorlaeufige
Definition'). Und es gilt per Standard nur fuer mehrere nicht
initialisierte Definitionen innerhalb *einer* Uebersetzungseinheit.
Dass es auch quer ueber mehrere Uebersetzungseinheiten oft
funktioniert, ist urspruenglich eine Eigenart des Unix-Linkers, die
dort zwecks Link-Kompatibilitaet zu Fortran noetig ist.
> $ gcc foo.c bar.c
> Wenn man sich angewöhnt, alle Variablen zu initialisieren, wird dieser
> Fehler beim Linken erkannt.
Das ist dazu nicht noetig. Es reicht, dem Compiler auf die Fuesse zu treten:
~> gcc -fno-common -g foo.c bar.c -o foo
/usr/tmp/cca103682.o: In function `main':
/cldsk/axp61/he/broeker/bar.c:2: multiple definition of `x'
/usr/tmp/cca103681.o(.data+0x0): first defined here
Horst Kraemer
<sche...@t-online.de> wrote:
> Stefan Reuther wrote:
> >
> > Hallo,
> >
> > Jan Echternach <ech...@informatik.uni-rostock.de> wrote:
> >
> > Ein anderer (stilistischer) Grund ist vielleicht, daß automatische
> > (lokale) Variablen eben nicht initialisiert werden. Wenn man eine
> > globale Variable per cut&paste in eine Funktion befördert, wird
> > sie auf einmal nicht mehr initialisiert.
>
> Manche Compiler weigern sich, auto-Objekte mit ={0};
> zu initialisieren.
Ja. Nicht-standardkonforme Compiler.
Bei denen koennen noch tausend andere merkwuerdige Sachen passieren.
unsigned char wird per Standardpromotion auf unsigned int promoviert
und nicht auf int, obwohl der Wertebereich von int den Wertebereich
von unsigned char umfasst, etc. pp..
MfG
Horst
Heiko Wolf
ich haette auch noch eine Frage zu diesem thread.
Gilt die default Initialisierung auch fuer lokale Varaiblen?
Kann ich also auch int i; anstele von int i = 0; schreiben?
MfG Heiko
Rudolf Meyer
Newsbeitrag: 96rdqj$138$1...@nets3.rz.RWTH-Aachen.DE...
> Rudolf Meyer <meyer....@t-online.de> wrote:
>
> > Frage: Ist es nicht auch so, dass explizit initialisierte statische
Variable
> > bei manchen Compilern diese zu const-Variable werden?
>
> Nein. Du wirfst das glaube ich mit String-Konstanten durcheinander.
> Die sind in der Tat automatisch effektiv 'const', obwohl es nicht dran
> steht.
--
Gruss
Rudi
Rudolf Meyer
Helmut Schellong <sche...@t-online.de> schrieb in im Newsbeitrag: > >
> > Frage: Ist es nicht auch so, dass explizit initialisierte statische
Variable
> > bei manchen Compilern diese zu const-Variable werden?
>
> Nein, ohne das Keyword 'const' darf das nicht geschehen.
> Man könnte dann ja nicht hineinschreiben...
>
> Ausnahme: "abcdefg" (Zeichenkettenkonstante)
Danke das wollte ich wissen, ich habe das wohl verwechselt.
Gruss
Rudi
Franz Iberl
[...]
> "Statische lokale Variablen werden wie globale Variablen mit 0
> initialisiert, wenn sie nicht manuell initialisiert werden.
> Gewöhnen Sie sich aus Sicherheitsgründen eine manuelle Initialsierung
> an!"
> und zwei Seiten noch beim selben Thema:
> "Generell sollte man es sich jedoch angewöhnen, alle Variablen selbst
> manuell zu initialisieren."
Der Punkt ist m.E. "global" und "statisch" vs. "lokal":
man ist als Coder selbst dafür zuständig, auf den Unterschied "zu achten".
Deshalb kommen glaub ich manche in Versuchung solche Empfehlungen
zu geben ("aus Sicherheitsgründen"), die bei "Vergessen" des Unterschieds
wirksam werden.
Ich finde es besser, /keine/ redundanten Statements zu benutzen,
was Du ja jetzt auch tust.
Servus
Franz
Franz Iberl
[...]
> Manche Compiler weigern sich, auto-Objekte mit ={0};
> zu initialisieren.
dürfen die das denn (d.h. dann sind sie doch nicht mehr konform)?
Servus
Franz
Stefan Reuther
Helmut Schellong <sche...@t-online.de> wrote:
>> Ein anderer (stilistischer) Grund ist vielleicht, daß automatische
>> (lokale) Variablen eben nicht initialisiert werden. Wenn man eine
>> globale Variable per cut&paste in eine Funktion befördert, wird
>> sie auf einmal nicht mehr initialisiert.
> Manche Compiler weigern sich, auto-Objekte mit ={0};
> zu initialisieren.
> Und wenn der Compiler das erlaubt, wird ein doppeltes statisches
> (internes) Objekt angelegt, das bei jedem Ueberlaufen des init.
> auto-Objektes in das auto-Objekt kopiert wird.
Das ist ja wohl ein `quality of implementation issue'.
Für einfache Datentypen wird sicherlich kein static-Objekt
angelegt. Und wenn der Compiler eine große struct per memcpy
initialisiert, ist das definitiv schneller als wenn ich das
händisch tue.
>> Noch ein Grund: in C ist es erlaubt, eine Variable in zwei
>> compilation units zu definieren, wenn man sie maximal einmal
>> initialisiert.
>> $ cat foo.c
>> int x;
>> $ cat bar.c
>> int x = 1;
>> int main() { return 0; }
>> $ gcc foo.c bar.c
>> Wenn man sich angewöhnt, alle Variablen zu initialisieren, wird dieser
>> Fehler beim Linken erkannt.
> Durch 'extern' wird der Fehler auch erkannt.
> extern-Objekte dürfen nicht init. werden.
Der Fehler ist, daß zwei Variablen definiert werden sollten,
nämlich eine in `foo.c' und eine in `bar.c'; aber nur eine
definiert wurde.
Stefan
Helmut Schellong
Sie sind dann nicht ganz konform.
Helmut Schellong
>
> Hallo,
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >> Ein anderer (stilistischer) Grund ist vielleicht, daß automatische
>
> > zu initialisieren.
> > Und wenn der Compiler das erlaubt, wird ein doppeltes statisches
> > (internes) Objekt angelegt, das bei jedem Ueberlaufen des init.
> > auto-Objektes in das auto-Objekt kopiert wird.
>
> Das ist ja wohl ein `quality of implementation issue'.
> Für einfache Datentypen wird sicherlich kein static-Objekt
> angelegt.
Natürlich nicht.
Deshalb zeigte ich auch ={ }.
> Und wenn der Compiler eine große struct per memcpy
> initialisiert, ist das definitiv schneller als wenn ich das
> händisch tue.
Ja, aber da liegt dann ohne Wissen ein initialisiertes Objekt
im Bauch der Exe, obwohl nur ein auto-Objekt sichtbar ist!
Das mach ich manchmal:
struct xx StructA;
struct xx Struct0;
StructA.y= ....
//.......
StructA= Struct0; // Löschen, maximal schnell, rep movsd