4. partieller Code (include *.c file) schlechter Stil?

partieller Code (include *.c file) schlechter Stil?


  • @SoIntMan

    Mal eine dumme Frage. Was spricht gegen:

    typedef struct stDef 
{
  int someinfo;
} stDef ;


// Je nach Kontext Foo.h
static const stDef FooDef = { 42 };    

// Je nach Kontext Bar.h
static const stDef BarDef = { 123 };

// Je nach Kontext BarFoo.h
static const stDef definitions[2] = { FooDef, BarDef };

    Edit: Habe gelöschten Beitrag wiederhergestellt.

    0
    S
     1 Antwort
  • F

    @SoIntMan sagte in partieller Code (include *.c file) schlechter Stil?:

    dadurch dass nur die die pool.c bar/foo kennt/verwendet .. dachte ich mir ich kann mirfoo.h/bar.h sparen da ich ja direct c includieren kann..

    Wenn static nur zum "ruhigstellen" war und die Sichtbarkeit hier nicht wichtig ist, dann kannst du dir in dem Fall die Header auch sparen, indem du deren Inhalt (die Deklarationen von part_Foo und part_Bar) direkt in die pool.c schreibst:

    // pool.h
typedef struct stDef 
{
  int someinfo;
} stDef ;

stDef getDef(const int id);

    //pool.c
#include <pool.h>

stDef part_Foo();
stDef part_Bar();

stDef getDef(const int id)
{
    static stDef definitions[2] = {0};
    definitions[0] = part_Foo();
    definitions[1] = part_Bar();
    return definitions[id];
}

    // def.c oder alternativ eine foo.c und eine bar.c.
#include <pool.h>

stDef part_Foo()
{
    stDef def = { 42 };
    return def;
}

stDef part_Bar()
{
    stDef def = { 123 };
    return def;
}

    Das ist Äquivalent zur Lösung mit den 2 Headern, nur eben ohne die 2 extra Dateien. Das würde ich für so etwas simples auch in der Form bevorzugen. Zu viele Dateien können ein Projekt auch unübersichtlich machen.

    Oder alternativ auch ohne Funktionen und direkt mit globalen Variablen:

    //pool.c
#include <pool.h>

extern stDef myproject_foo_def;
extern stDef myproject_bar_def;

stDef getDef(const int id)
{
    static stDef definitions[2] = {0};
    definitions[0] = myproject_foo_def;
    definitions[1] = myproject_bar_def;
    return definitions[id];
}

    // def.c oder alternativ eine foo.c und eine bar.c.
#include <pool.h>

const stDef myproject_foo_def = { 42 };
const stDef myproject_bar_def = { 123 };

    Die sind dann in der Form zumindest nicht für jeden sichtbar, der pool.h einbindet.
    Probleme mit Initialisierungsreihenfolge natürlich erstmal außen vor. Mit den Variablen sollte man getDef natürlich erst aufrufen, wenn die globalen Konstruktoren durch sind (im Zweifel frühestens ab der main()). Ansonsten machen die Funktionen mehr Sinn.

    0
    S
     1 Antwort
  • Mod

    @Quiche-Lorraine : Ich weiß nicht, wieso du es gelöscht hast, aber ich erinnere mich noch was da stand (und ich kann meine Moderatorenfähigkeiten einsetzen, um die Geschichte zu sehen 😉 ), aber ich kann dir als Feedback geben, dass das eigentlich ein solider Vorschlag war.

    0 1 Antwort
  • S

    @Finnegan sagte in partieller Code (include *.c file) schlechter Stil?:

    Oder alternativ auch ohne Funktionen und direkt mit globalen Variablen:

    hmm.. das ist auch noch ne gute idee. das stimmt..

    @SeppJ sagte in partieller Code (include *.c file) schlechter Stil?:

    Wenn das natürlich nur vereinfachter Beispielcode ist, und da irgendwelche Pointer eine Rolle spielen, dann ist das const natürlich wichtig. Dann aber um so mehr Vorsicht mit den statics, ob die Objekte, auf die du zeigst, auch wirklich existieren.

    ja statisch objekte in c files sind ja dann nur in der c bekannt.. ich kann dann in diversen c files den selben namen der variablen nehmen oder nicht.. und was meinst du mit ob die objekte auch wirklich existieren? vll. habe ich dich auch falsch verstanden..

    @SeppJ sagte in partieller Code (include *.c file) schlechter Stil?:

    machen, egal ob da nun int x() oder const int x() stünde.

    du meinst weil es in c keine referencen gibt.. dass da const egal is? guter hinweiß...

    @SeppJ sagte in partieller Code (include *.c file) schlechter Stil?:

    @Quiche-Lorraine : Ich weiß nicht, wieso du es gelöscht hast, aber ich erinnere mich noch was da stand (und ich kann meine Moderatorenfähigkeiten einsetzen, um die Geschichte zu sehen ), aber ich kann dir als Feedback geben, dass das eigentlich ein solider Vorschlag war.

    ja bin offen für vorschläge, nur raus damit

    0 1 Antwort

  • @SeppJ
    Ich war gerade ein wenig verwirrt, da ich es nur mit C++ Mitteln getestet habe.

    Aber danke für deinen Hinweis, ich habe ihn wiederhergestellt.

    0
  • S

    @Quiche-Lorraine sagte in partieller Code (include *.c file) schlechter Stil?:

    Mal eine dumme Frage. Was spricht gegen:
    typedef struct stDef
    {
    int someinfo;
    } stDef ;

    // Je nach Kontext Foo.h
    static const stDef FooDef = { 42 };

    // Je nach Kontext Bar.h
    static const stDef BarDef = { 123 };

    // Je nach Kontext BarFoo.h
    static const stDef definitions[2] = { FooDef, BarDef };

    servus, das ist ein genialer ansatz, den hatte ich anfangs auch im kopf 🙂 ABER. die zeile

    static const stDef definitions[2] = { FooDef, BarDef };

    schmeist in VSC 14 eien compilerfehler.. dass bei FooDef ,BarDef ein konstanter austruck erwartet wird, was er auch laut code ist.. aber vsc streikt ..gcc geht.. 😉

    0 1 Antwort

  • @SoIntMan

    #pragma once

typedef struct stDef
{
	int someinfo;
} stDef;

// Je nach Kontext Foo.h
//static const stDef FooDef = { 42 };

#define FooDef() { 42 }

// Je nach Kontext Bar.h
//static const stDef BarDef = { 123 };

#define BarDef() { 123 }

// Je nach Kontext BarFoo.h
static const stDef definitions[2] = { FooDef(), BarDef() };

    So funktioniert es. Nicht schön aber selten.

    Und irgentwie vermisse ich hier schon C++ wg. constexpr,...

    Du siehst ja aich direkt das Problem. Die Defines sind nicht typsicher.

    0

  • Das hatte ich für @SoIntMan schon vor 1,5 Monaten in statische komplexe objekte initialisieren Frage/Problem herausgefunden.

    0
    S
     1 Antwort
  • S

    @Th69 sagte in partieller Code (include *.c file) schlechter Stil?:

    Das hatte ich für @SoIntMan schon vor 1,5 Monaten in statische komplexe objekte initialisieren Frage/Problem herausgefunden.

    ja richtig, war aber nicht direkt das Thema...

    @Quiche-Lorraine sagte in partieller Code (include *.c file) schlechter Stil?:

    @SoIntMan
    #pragma once

    typedef struct stDef
    {
    int someinfo;
    } stDef;

    // Je nach Kontext Foo.h
    //static const stDef FooDef = { 42 };

    #define FooDef() { 42 }

    // Je nach Kontext Bar.h
    //static const stDef BarDef = { 123 };

    #define BarDef() { 123 }

    // Je nach Kontext BarFoo.h
    static const stDef definitions[2] = { FooDef(), BarDef() };

    So funktioniert es. Nicht schön aber selten.
    Und irgentwie vermisse ich hier schon C++ wg. constexpr,...
    Du siehst ja aich direkt das Problem. Die Defines sind nicht typsicher.

    netter workaround, aber gefällt mir nicht so.. muss ich mal sacken lassen

    0 1 Antwort
  • Mod

    @SoIntMan sagte in partieller Code (include *.c file) schlechter Stil?:

    ja statisch objekte in c files sind ja dann nur in der c bekannt.. ich kann dann in diversen c files den selben namen der variablen nehmen oder nicht.. und was meinst du mit ob die objekte auch wirklich existieren? vll. habe ich dich auch falsch verstanden..

    Ich dachte da dran, dass die Objekte durch zu viele statics an den falschen Stellen ggf. häufiger existieren als nur einmal. Falls das nur dumme Konstanten sind, ist das kein Problem. Wenn das aber Singleton-artige Objekte sind, die einen veränderlichen Zustand tragen, dann würdest du Probleme bekommen.

    0
    S
     1 Antwort
  • S

    @SeppJ sagte in partieller Code (include *.c file) schlechter Stil?:

    Ich dachte da dran, dass die Objekte durch zu viele statics an den falschen Stellen ggf. häufiger existieren als nur einmal. Falls das nur dumme Konstanten sind, ist das kein Problem. Wenn das aber Singleton-artige Objekte sind, die einen veränderlichen Zustand tragen, dann würdest du Probleme bekommen.

    ne das sind wirklich nur readonly daten. ich bin kein fan von static absolut nicht.. vewendet hier nur static damit die daten nur in c-file sichtbar sind und "einmal" um die Def Array zu initalisieren

    0

  • @SoIntMan sagte in partieller Code (include *.c file) schlechter Stil?:

    @Th69 sagte in partieller Code (include *.c file) schlechter Stil?:

    Das hatte ich für @SoIntMan schon vor 1,5 Monaten in statische komplexe objekte initialisieren Frage/Problem herausgefunden.

    ja richtig, war aber nicht direkt das Thema...

    @Quiche-Lorraine sagte in partieller Code (include *.c file) schlechter Stil?:

    @SoIntMan
    #pragma once

    typedef struct stDef
    {
    int someinfo;
    } stDef;

    // Je nach Kontext Foo.h
    //static const stDef FooDef = { 42 };

    #define FooDef() { 42 }

    // Je nach Kontext Bar.h
    //static const stDef BarDef = { 123 };

    #define BarDef() { 123 }

    // Je nach Kontext BarFoo.h
    static const stDef definitions[2] = { FooDef(), BarDef() };

    So funktioniert es. Nicht schön aber selten.
    Und irgentwie vermisse ich hier schon C++ wg. constexpr,...
    Du siehst ja aich direkt das Problem. Die Defines sind nicht typsicher.

    netter workaround, aber gefällt mir nicht so.. muss ich mal sacken lassen

    Das ist doch genau das, was ich auch mit den Makros gemacht habe (nur hier als Funktionsmakros - warum eigentlich?).

    Und das Problem bei deinem Code

    stDef getDef(const int id)
{
    static stDef definitions[2] = {0};
    definitions[0] = myproject_foo_def;
    definitions[1] = myproject_bar_def;
    return definitions[id];
}

    ist, daß zwar definitions statisch ist, bei jedem Aufruf aber die einzelnen Zuweisungen jeweils ausgeführt werden (d.h. die Daten kopiert werden) -> das kann doch nicht wirklich dein Ziel sein...

    0
    S
     1 Antwort
  • S

    @Th69 sagte in partieller Code (include *.c file) schlechter Stil?:

    Das ist doch genau das, was ich auch mit den Makros gemacht habe (nur hier als Funktionsmakros - warum eigentlich?).

    absolut, da stimmt.

    @Th69 sagte in partieller Code (include *.c file) schlechter Stil?:

    ist, daß zwar definitions statisch ist, bei jedem Aufruf aber die einzelnen Zuweisungen jeweils ausgeführt werden (d.h. die Daten kopiert werden) -> das kann doch nicht wirklich dein Ziel sein...

    ja da hast du auch recht, aus der sichtweiße dann doch mit makros. die aufrufw finden nur selten statt, aber ich geb dir recht;)

    0
Anmelden zum Antworten