Vad ska jag använda för programmeringsmetodik vid många funktioner - C

Kan du expandera? Vad menar du är problemet med många funktioner, och vilken lösning har e.g. Java som du kan relatera till?

Om ditt problem är att det är mycket att komma ihåg om man ska memorera en hel .c fil, så låter det som att du nog inte utnyttjar .h filer till fullo. .h filer kan bland annat användas för att bara göra en delmängd av alla funktioner i .c filen synliga utåt, i.e. som ett slags system för att specifiera vilka funktioner som är privata och vilka som är publika, lite som enkapsulering. Är du duktig och begränsar API ytan kan du då se varje .c fil lite som en klass i OOP, där de flesta funktionerna är interna för klassen och inte behöver förstås av användaren, medan .h filen specifierar det mer begränsade, publika interfacet för "klassen".

Ok, fortfarande inte helt säker på vad du är ute efter, men kan iallafall kommentera lite på vad du skrivit här.

1. Koden i ditt andra exempel använder inte polymorfism, utan komposition. Komposition är när man har en klass/strukt som har en annan klass/strukt som fält. Detta används som ett alternativ till arv för att bygga upp komplexa typer. Som du märkt funkar det utmärkt att använda komposition i ett imperativt språk som C.

Polymorfism är något helt ortogonalt. Polymorfism, också kallat "generics" av vissa, är ett sätt att skriva en generell implementation av en funktion/metod/klass, och återanvända den för mer specialiserade instanser av typen. Ett exempel är Java klassen "ArrayList" som är polymorfisk över elementtypen. Man skriver klassen en gång, generell för vilken elementtyp som helst, sen kan användare av klassen ha vilka instanser som helst, e.g. "ArrayList<Integer>" eller "ArrayList<ArrayList<A>>". Liknande, funktionen "id" i Haskell som har typen "forall a. a -> a". C har mycket beklagligen ingen polymorfism, varför man istället behöver casta värden så ofta, e.g. efter en malloc.

2. Att använda .h filer främst för att deklarera funktioner, och att inte använda globala variabler tycker jag du gör helt rätt i! "Publika" strukter och konstanter passar också bäst att ha här.

3. Att ha "metoder" i C, i.e. en strukt med fält av funktionstyp, är inte särskiljt praktiskt för det mesta. Det må se väldigt OOP och fint ut, men det går väldigt mycket mothårs i C. Det kan vara bra att ha ibland, men jag tror att du oftast kommer finna att en "dummare" lösning blir smidigare i det stora hela. Om du vill fortsätta på detta spår kan jag iallafall påpeka att ett makro hade kunnat minska repetition en del!

Jag hade nog rekommenderat att du kikar en gång till på C++ dock. Ingen som tvingar dig att lära dig hela språket (förutom nördar på internet)! Att bara använda det som ett "C med klasser" kan räcka långt. Jag hade iallafall saknat polymorfism väldigt i C till skillnad mot C++ (även om C++s typsystem fortfarande lämnar mycket att begära).

Inte mer avancerad - annorlunda.

Man brukar dela upp programmeringsspråk i två huvudgrupper som var och en består av två undergrupper.
Först har vi de imperativa språken som delas upp i procdurella språk (Fortran, C, Pascal, m.fl.) och objektorienterade språk (Java, Smalltalk, m.fl).
Sen så har vi de deklarativa språken som i sin tur delas upp i funktionella (Scheme, Haskell, SML, m.fl) och logik-orienterade (Prolog)

Varje av dessa grupper innebär olika sätt att programmera och tänka. Ingen av dem är mer avancerad än de andra, bara annorlunda.
Inget av de olika angreppssätten är heller "bättre" i någon slags absolut mening, även om de passar olika bra för olika problem.

Det har sagts att det går att skriva Fortran i vilket språk som helst, och på samma sätt så går det att skriva objektorienterat i vilket språk som helst.

Att försöka skriva objektorienterat i ett språk som inte har stöd för det är dock oftast en dålig idé och gör att man komplicerar saker mer än nödvändigt.

Försök inte skriva Java eller C++ i C. Skriv C i C.

C++ är inte bättre. Större och mer komplext, ja, men inte bättre.
C har ändrats rätt mycket sedan det skapades och står inte stilla det heller, även om inte alla nymodigheter accepteras så snabbt bland användare.

Det finns flera olika sorters polymorfism inom programmering. När man pratar om polymorfism i objekt-orienterade sammanhang så är det oftast subtypning man menar, snarare än parametrisk polymorfism (som t.ex. generics i Java). Det innebär förenklat att om du har en klass B som ärver från A så kan du använda en instans av B på ställen där en instans av A förväntas. T.ex. i C++:

class A
{
  public:
    virtual void someMethod() { std::cout << "A"; };
};

class B : public A
{
  public:
    void someMethod() { std::cout << "B"; };
};

void f(A &a)
{
  a.someMethod();
}

int main()
{
  B b;
  f(b); // Skriver ut B, även fast f tar en instans av A.
}

Det går att göra sånt även i C, men koden kommer bara se ut som att den är skriven av en militant C++-programmerare som tvingats att skriva C.

struct point
{
    int x;
    int y;
    void (*print)(const struct point*);
};

Det här är ett jättedåligt sätt att göra polymorfism i C, av flera anledningar.

Vi börjar med effektivitet. Det är relevant eftersom du skriver att du vill använda C för att skapa kompakt kod med små systemkrav.

Under kategorin effektivitet börjar vi med minne. Att behöva använda RAM-minne för att lagra instruktionspekare, och då dessutom i varenda objekt skalar inte särskilt väl. I ditt exempel har du bara en funktion, men i något som vore mer än ett leksaksexempel så hade du haft fler funktioner.

Om du har många instanser av denna datastruktur så blir detta rätt mycket minne över tid. Du kör kanske inte slut på ditt RAM-minne, däremot kanske du får använda ett långsammare cache i din CPU, eller inget cache alls, vilket gör att din (begränsade) CPU inte kan jobba lika snabbt.

Sen får vi inte glömma alla möjligheter att göra fel på. Varje gång du skapar ett objekt måste du komma ihåg att uppdatera denna tabell med pekare. Vilket också gör det dyrare CPU-mässigt att skapa nya objekt. Helt i onödan ofta.

Detta kan man mitigera delvis genom att skapa ett "klassobjekt" som man pekar till som innehåller en tabell med funktioner. Det är också ungefär så som t.ex. C++ implementerar "virtuella metoder" i verkligheten.

Med det sagt så är det inte polymorfism som du egentligen verkar vara ute efter, utan mer ett sätt att organisera sig.

För att svara på det som egentligen verkar vara kärnan till ditt problem, hur organiserar man sin kod på ett bra sätt i C? Ett bra sätt att tänka på är att läsa på om modulär programmering. Det går ut på att man delar upp sitt program i små beståndsdelar, med väl definierade gränssnittsytor mellan modulerna.

Finns det verkligen fortfarande embedded utvecklingsmiljöer som inte stödjer C++?

Ett tips är att göra alla variabler du definierar i det yttersta scopet static, annars kommer dom att vara tillgängliga från vilken annan .c-fil som helst (om det inte är din mening att dom ska vara globala.)