Initialisierung von Variablen in C mit GCC?

[Lin728]

Grabe derzeit ein wenig in den gtk-interna herum um performance-engpässe aufzuspüren und was mir aufgefallen ist, dass davon ausgegengen wird dass Zeiger mit NULL und variablen mit 0 vorinitialisiert werden (zumindest wenn diese teil eines structs sind).

Ist dies eine gcc-besonderheit und inwieweit ist dies standardisiert?

[peschmae]

Also das kann ich so jetzt nicht nachvollziehen. Bei mir ist eigentlich immer alles (egal ob aufm Heap oder aufm Stack) nicht vorinitialisiert. Auch structs.

Ausnahme sind natürlich statische Variablen.

MfG Peschmä

[RapidMax]

Auf dem Stack und im Heap werden die Daten nicht mit Null (0) initialisiert. Im Datenbereich (Globale Variablen) hingegen AFAIK schon. Es kann bei glib aber auch sein, dass der dort verwendete malloc wrapper aehnlich wie calloc() den allozierten Bereich auf Null setzt (ich vermute aber eher nicht).

Gruss, Andy

[jeebee]

GLib-Doku: g_malloc0(gulong n_bytes)
falls diese Methode zum Speicher allozieren genutzt wird, ja. Ansonsten nein.

[Lin728]

Also soweit ich das verstanden habe wird die Struktur über "g_object_new" über erzeugt und so wie ich das verstehe auch initialisiert.

lg

[peschmae]

Also das Argument das ich immer gehört habe war vor allem dass halt auf Unix-Systemen mehr Programmierer C beherrschen. Und dass es einfacher sei für C-Bibliotheken Bindings zu erstellen.
Gefolgt vom (nicht ganz unberechtigten) Hinweis, C++ könne auch nicht der Weisheit letzer Schluss sein

Aber eigentlich finde ich OOP mit C auch einfach nur mühsam. Kein Wunder - die Sprache ist ja auch 20 Jahre älter als OOP

Aber hey, dich fragt keiner und ein Kompletrewrite dürfte schwierig durchzupauken sein

MfG Peschmä

[Lin728]

Ich sehs als notlösung an, aber mehr nicht :-/

[Joghurt]

Nur als Erinnerung: in C++ läuft es intern genauso ab, nur dass du es syntaktisch besser schreiben kannst.

class Foo { void bar() {...}; int a; int b;};
Foo a;
a.bar();

ist intern nichts anderes als

struct Foo {int a; int b;};
void Foo_bar(Foo* this) { ... }
Foo a;
Foo_bar(&a);

[anda_skoa]

Also soweit ich das verstanden habe wird die Struktur über "g_object_new" über erzeugt und so wie ich das verstehe auch initialisiert.

Davon würde ich auch ausgehen, das ist praktisch das Äquivalent zu einem Konstruktor.

Wahnsinn das ganze glib-gebilde ist kaputt, das mag eventuell anno 1995/1996 sinn gehabt haben, ich empfinde es als Plage.

Ohne glib würde ich kein C Projekt mehr machen, alleine die Container selber fehlerfrei zu implementieren ist den Aufwand nicht wert.
Edit: man darf nicht vergessen, daß glib mehr oder weniger zwei Bibliotheken in einer ist.
Da gibt es die Hilfmittel für bequemes C und das GObject System. Ws wurde schon öfter angeregt das zu trennen, damit man glib leichter als Abhängigkeit verantworten kann, um zB glib Container in der API einer eigenen Lib verwenden zu können.

Ich zweifle stark daran dass all diesen pseudo-OO gebilde schneller sein sollen als echtes C++ (meinetwegen ohne exception handling), für den programmierer ists eine zumutung, besonders wenns ans erstellen eigener "Klassen" geht.

Schneller ist es auf keinen Fall, aber manchmal sind die Projektvorgaben auf C fixiert, oder der Entwickler traut sich nicht über eine andere Sprache drüber, oder C wird aus "religiösen" Gründen bevorzugt.

Wie man sich als Java Programmierer dazu motivieren kann, in die Tiefen von C abzusteigen, ist mir allerdings ein Rätsel
Als ich von Java ausgehen C++ angefangen habe, hätte ich ohne die durch Qt bereitgestellte Brücke wieder aufgehört.

Ciao,
_