Alternative zu initialization

[Konfusius]

namespace invader schrieb:

Das gibt es in C zum Glück nicht, denn es ist unnütz und würde nur Probleme verursachen.

Unnütz ist es sicher nicht. Man kann damit so etwas wie Klassenkonstruktoren realisieren. Die Gefahr von Rekursion besteht bei der initialisierung von Hand (mindestens) genauso.

[Tachyon]

+fricky schrieb:

Tachyon schrieb:

Und nein, in C geht es nicht. Die Konstruktion oben ist zwar kein Thema, aber man kann nicht, wie in C++, den Nutzen daraus ziehen.

welchen nutzen meinst du? in c kannste doch auch eine funktion schreiben, die in abhängigkeit von einem statischen flag eine struct initialisiert und dieselbe immer zurückgibt.

Sagte ich ja auch. Aber Trigger dafür kann in C erst nach dem Eintritt in main() kommen...

[namespace invader]

Konfusius schrieb:

Die Gefahr von Rekursion besteht bei der initialisierung von Hand (mindestens) genauso.

Wenn man bei der Initialisierung von Hand eine Endlosrekursion baut, merkt man das aber, sobald man es ausprobiert. Im Gegensatz zu dem Glücksspiel von Konstruktoraufrufen bei globalen C++-Objekten.

[namespace invader]

Tachyon schrieb:

Sagte ich ja auch. Aber Trigger dafür kann in C erst nach dem Eintritt in main() kommen...

Für so einen Trigger vor main() muss man in C++ aber wieder globale Objekte deklarieren, die in ihrem Konstruktor irgendwas machen, mit dem dazugehörigen Problem der unvorhersehbaren Ausführungsreihenfolge. Dann hättest du auch gleich deine Instanz selbst als globales Objekt deklarieren und dir die getCrazyTypeInstance-Funktion sparen können.

[Tachyon]

namespace invader schrieb:

[...]

Such mal nach dem "Construct on first use"-Idiom. Ich denke nicht, dass das in C geht.

[dumm]

Möglicherweise reicht mein Programmierwissen noch nicht so weit, aber für was sollte etwas ausgeführt werden noch bevor das Programm ausgeführt wird? Nach meinem Verständniss rufe ich eine Funktion die zuerst ausgeführt werden soll einfach zuerst auf und dann erst den Rest. Kann mir das jemand erklären? Da sich hier ja Leute rege and der Diskussion beteiligen, habe ich da anscheind ein Wissensleak.

[+fricky]

Tachyon schrieb:

+fricky schrieb:

Tachyon schrieb:

Und nein, in C geht es nicht. Die Konstruktion oben ist zwar kein Thema, aber man kann nicht, wie in C++, den Nutzen daraus ziehen.

welchen nutzen meinst du? in c kannste doch auch eine funktion schreiben, die in abhängigkeit von einem statischen flag eine struct initialisiert und dieselbe immer zurückgibt.

Sagte ich ja auch. Aber Trigger dafür kann in C erst nach dem Eintritt in main() kommen...

was doch egal bzw. kein nachteil ist. hauptsache es passiert vor der erstmaligen benutzung und später nicht mehr.

struct Object *getStaticObject(void)
{
   static int initialized = 0;
   static struct Object o;
   if (!initialized)
   {
     o.blah = ...;
     o.blub = ....;
     ...
     initialized = 1;
   }
   return &o;
}

^^wird auch nur beim ersten aufruf initialisiert.

[namespace invader]

Tachyon schrieb:

Such mal nach dem "Construct on first use"-Idiom. Ich denke nicht, dass das in C geht.

Wieso nicht?

SomeCrazyType *getCrazyTypeInstance()
{
    static SomeCrazyType *instance = NULL;
    if (!instance)
        instance = SomeCrazyType_create();

    return instance;
}

[Tachyon]

+fricky schrieb:

...

Wie ich bereits sagte, sagte ich bereits, dass das Konstrukt an sich in C kein Problem ist.

[+fricky]

Tachyon schrieb:

+fricky schrieb:

...

Wie ich bereits sagte, sagte ich bereits, dass das Konstrukt an sich in C kein Problem ist.

auf was wolltest du denn hinaus? irgendwelche workarounds für c++'s eigentümliche probleme sind doch in C nicht relevant.

[volkard]

ich vermute, das geht noch direkter.

struct Object *createStaticObject()
{
  static struct Object o;//oder mit malloc anlegen
  o.foo=5;
  return &o;
}

struct Object *getStaticObject(void)
{
   static struct Object *po=createStaticObject();
   return po;
}

[Tachyon]

+fricky schrieb:

irgendwelche workarounds für c++'s eigentümliche probleme sind doch in C nicht relevant.

Und wieso versuchst Du dann mir krampfhaft zu zeigen, dass man solche Workarounds in C programmieren kann?

[namespace invader]

dumm schrieb:

Möglicherweise reicht mein Programmierwissen noch nicht so weit, aber für was sollte etwas ausgeführt werden noch bevor das Programm ausgeführt wird?

Na z.B. um globale Objekte zu initialisieren, von denen man später (im eigentlichen Programm) davon ausgehen können möchte, dass sie initialisiert wurden.

Aber IMHO ist es sinnvoller, einfach eine init-Funktion zu schreiben, die das erledigt, und die ganz normal am Anfang des Programms aufzurufen ist, anstatt irgendwelche verwirrenden und potenziell problematischen Sprachfeatures haben zu wollen, die bewirken, dass vor main() irgendwas automatisch gemacht wird.

[volkard]

[+fricky]

volkard schrieb:

ich vermute, das geht noch direkter.

struct Object *createStaticObject()
{
  static struct Object o;//oder mit malloc anlegen
  o.foo=5;
  return &o;
}

struct Object *getStaticObject(void)
{
   static struct Object *po=createStaticObject();
   return po;
}

klar, aber dabei könnte einer versehentlich createStaticObject() aufrufen, aber getStaticObject meinen, was nicht gut wäre.

Tachyon schrieb:

+fricky schrieb:

irgendwelche workarounds für c++'s eigentümliche probleme sind doch in C nicht relevant.

Und wieso versuchst Du dann mir krampfhaft zu zeigen, dass man solche Workarounds in C programmieren kann?

wieso? du hast doch zuerst gesagt, dass das in C nicht geht oder keine vorteile hätte.

namespace invader schrieb:

Aber IMHO ist es sinnvoller, einfach eine init-Funktion zu schreiben, die das erledigt, und die ganz normal am Anfang des Programms aufzurufen ist, anstatt irgendwelche verwirrenden und potenziell problematischen Sprachfeatures haben zu wollen, die bewirken, dass vor main() irgendwas automatisch gemacht wird.

das sehe ich genau so. zum wohldefinierten verhalten eines programms gehört ein fester einsprungpunkt (z.b. sowas wie main) und nicht irgendwelche codefragmente die beim start in unvorhersehbarer reihenfolge dran kommen.

[volkard]

+fricky schrieb:

klar, aber dabei könnte einer versehentlich createStaticObject() aufrufen, aber getStaticObject meinen, was nicht gut wäre.

dir steht es frei, die sachen anders zu nennen. aber die funktionale zerlegung nur deshalb nicht zu betreiben, weil man bei vielen funktionen deren namen verwechseln könnte, das kann auch nur dir einfallen.

[+fricky]

volkard schrieb:

dir steht es frei, die sachen anders zu nennen. aber die funktionale zerlegung nur deshalb nicht zu betreiben, weil man bei vielen funktionen deren namen verwechseln könnte...

gegen kleine funktionen hab ich nichts, aber warum sollte man 'ne kleine funktion in noch kleinere zerlegen, wenn's nix bringt und wenn diese funktion sowieso nur von einer anderen aufgerufen werden darf?

volkard schrieb:

...das kann auch nur dir einfallen.

hältste mich für so pingelig?