Funktionen konvertieren

[Aabeku K. (aabeku)]

Hi,

angenommen man hat eine Funktion vom Type:

static int eeprom_get(char adr, char* ptr);

Ich möchte aber nicht jedes mal meinen Pointer und die EEPROM-Adresse 
mitgeben. Wenn man einer Funktion feste Parameter übergibt, sodass kann 
man dann die Funktionen so "umcasten"?

int (*eeprom_get_parameter)(void) = eeprom_get(parameter_adr, 
&parameter);


 - "Parameter_adr" ist die konstante EEPROM-Adresse wo die Daten 
hinterlegt sind.
 - "&Parameter" ist konstante Pointer zur Addresse im RAM, wo der Wert 
von "parameter" hinterlegt wird.

Gruß

P.S.: Ich rede hier von der Programmiersprache C und dem Compiler XC8 
und IDE MPLAB. Letztere beide sind von Microchip.

[Niklas G. (erlkoenig)]

Das nennt sich Currying und wird so nur von funktionalen Sprachen 
unterstützt (z.B. Scala). In C++ gibt es dafür std::bind oder etwas 
schöner Lambdas (mit Cloure).

In C geht das nicht wirklich. Sofern die Parameter-Ausdrücke immer 
vorhanden sind, kannst du einfach ein Makro definieren. Oder beide Werte 
in ein struct packen, welches du an eine Hilfs-Funktion übergibst, die 
dann die beiden Werte an eeprom_get übergibt; das ist dann ein 
semi-OOP-Ansatz.

[Jörg W. (dl8dtl) (Moderator)]

Niklas G. schrieb:
> Sofern die Parameter-Ausdrücke immer vorhanden sind, kannst du einfach
> ein Makro definieren.

So klingt mir seine Beschreibung, und in der Tat könnte man das mit 
einem Makro machen.

char eeprom_data;

#define EEPROM_ADDRESS 42
#define EEPROM_GET() eeprom_get(EEPROM_ADDRESS, &eeprom_data)

// ...

  EEPROM_GET();
  // ...
  EEPROM_GET();

Schön ist natürlich was anderes. ;-)

[Aabeku K. (aabeku)]

Ja das ist genau was ich meinte.

Schön ist es wirklich nicht. Auch ein Workaround sind Wrapper.

int eeprom_get_parameter(void){
   return eeprom_get(PARAMTER_ADR, &parameter);
}

Ist aber genau so wenig schön wie Macros.

Schade das es nicht geht :/ Hätte einiges schöner gemacht.

Danke für die Antworten :)

[Jörg W. (dl8dtl) (Moderator)]

Aabeku K. schrieb:
> Ist aber genau so wenig schön wie Macros.

Mach es "static inline". Schöner als ein Makro allemal, und du hast ein 
paar Prüfungen mehr durch den Compiler.

[Frank K. (fchk)]

Aabeku K. schrieb:

> static int eeprom_get(char adr, char* ptr);

Mach doch ein:

static void eeprom_set_addr(char adr, char* ptr);

und ein dazugehöriges

static int eeprom_get_inc(void);

das dann den Wert aus adr nach *ptr schreibt und beides anschließend 
inkrementiert. Ebenso wäre bei Bedarf ein static int 
eeprom_get_dec(void); denkbar.

fchk

[Wilhelm M. (wimalopaan)]

Aabeku K. schrieb:
> Ja das ist genau was ich meinte.
>
> Schön ist es wirklich nicht. Auch ein Workaround sind Wrapper.
>
>

> int eeprom_get_parameter(void){
>    return eeprom_get(PARAMTER_ADR, &parameter);
> }
> 
>

Das ist doch genau das, was Du wolltest! Kannst Du `inline` deklarieren 
und ab in die entsprechende Header-Datei.

Was findest Du daran unschön?

Vielleicht möchtest Du es aber eher so benutzen können?

void f() {
    int v = eeprom_get(Parameter_A);
}

[Wilhelm M. (wimalopaan)]

Niklas G. schrieb:
> Das nennt sich Currying und wird so nur von funktionalen Sprachen
> unterstützt (z.B. Scala). In C++ gibt es dafür std::bind oder etwas
> schöner Lambdas (mit Cloure).

Aus seiner Beschreibung sehe ich nicht, dass er eine N-stellige Funktion 
auf N Aufrufe einstelliger Funktionen abbilden will.

> In C geht das nicht wirklich.

In GCC kann man lokale Funktionen definieren als Erweiterung. Vielleicht 
geht das bei dem XC8 auch?Damit könnte man dann tatsächlich 
"schönfinkeln" aka currying.

[Peter D. (peda)]

Ich mag das nicht, überall durcheinander im Code vom EEPROM lesen oder 
schreiben.
Ich lege mir daher ein Struct an, das alle Variablen enthält, die im 
EEPROM gesichert werden sollen. Und dann wird nur einmalig die Struct 
aus dem EEPROM gelesen, bzw. dahin gesichert.
Damit muß man keine Extrawurst für alle EEPROM-Variablen braten. Es sind 
ganz normal zugreifbare Variablen, die nach dem Reset aus dem EEPROM 
initialisiert werden.

Und das Sichern der Struct in den EEPROM erfolgt als Hintergrundtask 
(per Polling in der Mainloop), damit für die Schreibdauer die 
Applikation nicht angehalten werden muß.

[W.S. (Gast)]

Aabeku K. schrieb:
> angenommen man hat eine Funktion vom Type:
>
> static int eeprom_get(char adr, char* ptr);
>
> Ich möchte aber nicht...

Wenn du so eine Funktion hast und sie dir nicht gefällt, dann schreib 
dir einfach eine bessere Funktion.

Gerade EEPROMs werden recht häufig seriell betrieben, weswegen da ein 
char* Zeiger nicht wirklich hinpaßt.

Selbst bei auf dem Chip eingebautem EEPROM ist es oft so, daß es feste 
HW-Register gibt, wo man Adresse und Sollinhalt hineinschreibt und dann 
ein Schreiben auslöst oder nur Adresse und Lesen auslösen und dann den 
Istinhalt aus einem HW-Register holen.

Irgendwelche Präprozessor-Akrobatik halte ich für übel, denn sie macht 
das Ganze nur undurchsichtiger und die vorhandene Funktion nicht besser.

W.S.

[A. S. (Gast)]

Aabeku K. schrieb:
> int (*eeprom_get_parameter)(void) = eeprom_get(parameter_adr,
> &parameter);

int eeprom_get_parameter(void) { 
  return eeprom_get(parameter_adr, &parameter);
}

[Noch ein Kommentar (Gast)]

> Schön ist es wirklich nicht. Auch ein Workaround sind Wrapper.

Tja, unter den 10.000 C++23 Features findest du mindestens ein dutzend 
Features, mit denen du dein "umcasten" bauen kannst.

Musst dich halt entscheiden. Entweder eine Sprache, in der du dich auf 
struct[] und Wrapper beschränken musst. Oder eine Sprache, bei der du 
erst mal einen Kubikmeter Lehrbücher und Spezifikationen durcharbeiten 
musst.

[Wilhelm M. (wimalopaan)]

Noch ein Kommentar schrieb:
>> Schön ist es wirklich nicht. Auch ein Workaround sind Wrapper.
>
> Tja, unter den 10.000 C++23 Features findest du mindestens ein dutzend
> Features, mit denen du dein "umcasten" bauen kannst.
>
> Musst dich halt entscheiden. Entweder eine Sprache, in der du dich auf
> struct[] und Wrapper beschränken musst. Oder eine Sprache, bei der du
> erst mal einen Kubikmeter Lehrbücher und Spezifikationen durcharbeiten
> musst.

Und Du hast den Beitrag nicht gelesen.