mikrocontroller.net

Forum: PC-Programmierung Interfaces - fixed-width value types


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grüß euch

Mich würde interessieren wie ihr die Parameterübergabe an 
Funktionen/Klassen/etc. in Sprachen handhabt, die über verschiedene 
fixed-width Typen verfügen.

Also also Beispiel bei C/C++ in etwa uint8_t, int16_t, usw. usf.

Nehmen wir an es gibt eine Funktion die irgendeinen jener Typen annimmt 
und damit irgendwas anstellt.
void f(T v);

Wie wählt ihr den Übergabe-Parameter aus wenn
- die Funktion ein Byte irgendwohin aussendet
- die Funktion einen 16bit Timer setzt
- die Funktion irgendwas berechnet, der Übergabewert aber etwa nur bis 
16bit skalieren darf

Interessanterweise ertappe ich mich selbst dabei, dass ich vom ersten 
bis zum letzten Beispiel immer weniger strikt mit dem Typen bin. Sprich 
bei einer Funktion die ein Byte sendet würde ich ohne zögern ein 
einzelnes Byte übergeben während ich beim Timer wohl schon nicht mehr so 
sicher wäre...

Die Frage ist, mit welcher Argumentation? Wäre es nicht besser überall 
explizit zu sein und auch beim Timer lediglich 16bit Werte zuzulassen?

Wie handhabt ihr sowas?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde, exakte Größen sollten nur dort eingesetzt werden, wo auch 
zwingend eine benötigt wird, also z.B. bei Hardware-Registern oder einem 
binären Protokoll.
Nur um Wertebereiche einzuschränken, würde ich sie nicht nehmen, schon 
alleine, weil das gar nicht durchgängig klappt. Nehmen wir mal an, dein 
Timer wird im Code fix auf einen Overflow-Wert von 10000 gestellt, um 
mit 10 Mhz betrieben zu werden und immer exakt einmal pro Millisekunde 
überzulaufen. Es gibt aber in der Regel keinen Typ, der exakt bis 9999 
geht.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Ich finde, exakte Größen sollten nur dort eingesetzt werden, wo auch
> zwingend eine benötigt wird, also z.B. bei Hardware-Registern oder einem
> binären Protokoll.
> Nur um Wertebereiche einzuschränken, würde ich sie nicht nehmen, schon
> alleine, weil das gar nicht durchgängig klappt. Nehmen wir mal an, dein
> Timer wird im Code fix auf einen Overflow-Wert von 10000 gestellt, um
> mit 10 Mhz betrieben zu werden und immer exakt einmal pro Millisekunde
> überzulaufen. Es gibt aber in der Regel keinen Typ, der exakt bis 9999
> geht.

Ja des letzte Beispiel gefällt mir eigentlich auch nicht mehr und war 
unüberlegt. Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit 
Adressraum oder so.
eeprom_write(T adress, ...) 

Das wäre dann ähnlich zum Timer. Physikalisch wird exakt jenes EEPROM 
immer nur 16bit Adressen schicken, aber sollte sowas Teil der Signatur 
sein oder doch nur Teil der Doku?

Der Vorteil eines uint16_t als Übergabewert besteht daran, dass jeder 
unüberlegte Aufruf sofort ein -Wconversion Warning erzeugt.

Dummerweise besteht der Nachteil eines uint16_t als Übergabewert darin, 
dass jeder Aufruf sofort ein -Wconversion Warning erzeugt. ;)
uint8_t b;
uint16_t adr;
eeprom_write(adr, b);
eeprom_write(static_cast<uint16_t>(adr + 1u), b);

Exakte Größen sorgen recht schnell dafür dass der eigene Code mit 
static_casts gespickt ist...

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit
> Adressraum oder so.
> eeprom_write(T adress, ...)
>
> Das wäre dann ähnlich zum Timer. Physikalisch wird exakt jenes EEPROM
> immer nur 16bit Adressen schicken, aber sollte sowas Teil der Signatur
> sein oder doch nur Teil der Doku?

Da würde ich size_t nehmen. Fehler würde ich zur Runtime loggen und 
zurückgeben. Und dann eventuell noch eine get_eeprom_size Funktion, je 
nachdem, wofür man das braucht. Bzw. bei Addressen würde ich wohl sogar 
void Pointer nehmen.

So wie ich mich kenne würde ich das vermutlich noch weiter abstrahieren, 
und ein memory Interface mit read write size Funktionen anlegen und im 
eeprom Modul dieses implementieren. Also sowas: (ungetestet)

memory.h
struct ns_memory;
struct ns_memory_instance;

struct ns_memory {
  const char* type;
  ssize_t (*read)(struct ns_memory_instance* memory, void* offset, size_t size, uint8_t out[size]);
  ssize_t (*write)(struct ns_memory_instance* memory, void* offset, size_t size, uint8_t in[size]);
};

struct ns_memory_instance {
  const struct ns_memory* type;
  const char* name;
  size_t block_size;
};

internal_eeprom.h
struct ns_internal_eeprom_memory {
  struct ns_memory super;
};

struct ns_internal_eeprom_memory_instance {
  struct ns_memory_instance super;
};

extern const struct ns_internal_eeprom_memory_instance ns_internal_eeprom_1;

internal_eeprom.c
extern const struct ns_internal_eeprom_memory ns_internal_eeprom_memory;

static ssize_t read(struct ns_memory_instance* memory, void* offset, size_t size, uint8_t out[size]){
  if(!memory || memory->type != &ns_internal_eeprom_memory.super){
    errno = EINVAL;
    return -1;
  }
  const struct ns_internal_eeprom_memory_instance* instance = (const struct ns_internal_eeprom_memory_instance*)memory;
  ...
}

static ssize_t write(struct ns_memory_instance* memory, void* offset, size_t size, uint8_t in[size]){
  ...
}

const struct ns_internal_eeprom_memory ns_internal_eeprom_memory = {
  .super = {
    .type = "EEPROM",
    .read = read,
    .write = write
  }
};

const struct ns_internal_eeprom_memory_instance ns_internal_eeprom_1 = {
  .super = {
    .type = &ns_internal_eeprom_memory.super,
    .name = "internal1",
    .block_size = 1024
  }
};

Und dann später z.B. so verwenden:
const struct ns_memory_instance* bla_memory = &ns_internal_eeprom_1.super;
void* bla_location = 0x0001;

int save_bla(bla* bla){
  return bla_memory->type->write(bla_memory, bla_location, sizeof(*bla), bla);
}

Vermutlich würde ich mir dann noch eine memory registry/factory 
basierend auf allgemeinen registry/factory funktionen bauen und die 
statischen Memories sich darin selbst registrieren lassen und solches 
zeug. Und bla_memory und bla_location würde ich vermutlich auslagern und 
mit einem anderen Programm generieren lassen, usw. Das heist, falls ich 
nicht gleich ein ganzes Dateisystem mit ähnlicher Abstraktion einbaue... 
"fs_mount("fat", ns_memory_registry_get("EEPROM","internal1"));". Und 
eventuell würde ich dann noch einen memory manager bauen, der Daten auf 
die Memories verteilt abhängig von verfügbarem Platz, Schreibrate, 
Geschwindigkeit, verbleibende Zyklen, dann muss ich auch nichtmehr 
angeben welchen Memory... Ups, ich glaube schreibe schon wieder 
versehentlich ein OS...

(Falls sich jemand wundert, warum ich das in C und nicht in C++ mache: 
Wenn ich das in C schon so Overengineere, stellt euch mal vor, was ich 
in C++ anstellen würde...)

Vincent H. schrieb:
> dass der eigene Code mit static_casts gespickt ist

In C kommt man immerhin noch mit weniger lang auszuschreibenden und nur 
einer Art des Casts zurecht.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:

> Ja des letzte Beispiel gefällt mir eigentlich auch nicht mehr und war
> unüberlegt. Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit
> Adressraum oder so.
>
>
> eeprom_write(T adress, ...)
> 

Die Frage ist doch, ob Adressen vorzeichenlose, Ganzzahlen sind. Das 
sind sie m.E. nicht, denn bspw. eine Multiplikation oder Division oder 
Addition zweier Adressen ist nicht sinnvoll. Das Addieren einer Adresse 
mit einem Offset schon.

Daher schreibe ich für so etwas einen eigenen DT.

Genau aus diesem Grunde hat man ja (endlich) in der C++-stdlib auch den 
DT std::byte eingefügt. Denn ein Byte ist etwas anderes als ein uint8_t.

>
> uint8_t b;
> uint16_t adr;
> eeprom_write(adr, b);
> eeprom_write(static_cast<uint16_t>(adr + 1u), b);
> 
>
> Exakte Größen sorgen recht schnell dafür dass der eigene Code mit
> static_casts gespickt ist...

Nicht, wenn Du Dir domänenspezifische DT nach dem obigen Muster baust.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Ja des letzte Beispiel gefällt mir eigentlich auch nicht mehr und war
> unüberlegt. Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit
> Adressraum oder so.

Und übermorgen hast du ein EEPROM mit 18 Bit Adressraum.
Dann musst du wieder neue Funktionen schreiben.

Jede Einschränkung schränkt ein.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Vincent H. schrieb:
>
>> Ja des letzte Beispiel gefällt mir eigentlich auch nicht mehr und war
>> unüberlegt. Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit
>> Adressraum oder so.
>>
>>
>> eeprom_write(T adress, ...)
>> 
>
> Die Frage ist doch, ob Adressen vorzeichenlose, Ganzzahlen sind. Das
> sind sie m.E. nicht, denn bspw. eine Multiplikation oder Division oder
> Addition zweier Adressen ist nicht sinnvoll. Das Addieren einer Adresse
> mit einem Offset schon.
>
> Daher schreibe ich für so etwas einen eigenen DT.

Schreibst du dann für alles einen Wrapper?
Ich mach das aktuell eher an Stellen wo Funktionsargumente sonst 
unübersichtlich wären (int, int, int...)

Aber ja, mit einem
eeprom_write(Address{}, ...)
wär das Problem natürlich umgangen...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Wilhelm M. schrieb:
>> Vincent H. schrieb:
>>
>>> Ja des letzte Beispiel gefällt mir eigentlich auch nicht mehr und war
>>> unüberlegt. Aber nehmen wir ein anderes, vielleicht ein EEPROM mit 16bit
>>> Adressraum oder so.
>>>
>>>
>>> eeprom_write(T adress, ...)
>>> 
>>
>> Die Frage ist doch, ob Adressen vorzeichenlose, Ganzzahlen sind. Das
>> sind sie m.E. nicht, denn bspw. eine Multiplikation oder Division oder
>> Addition zweier Adressen ist nicht sinnvoll. Das Addieren einer Adresse
>> mit einem Offset schon.
>>
>> Daher schreibe ich für so etwas einen eigenen DT.
>
> Schreibst du dann für alles einen Wrapper?

Ja.
Man hat viele Vorteile zur Compilezeit und keine Nachteile zur Laufzeit.

> Ich mach das aktuell eher an Stellen wo Funktionsargumente sonst
> unübersichtlich wären (int, int, int...)

Na, da sowieso. Solche mehrstelligen Funktionen gehen gar nicht.
So etws nennt sich "String Data Types". Gerade das ist ja ein Vorteil 
von C++.

Scott Meyers sagte schon: eine Schnittstelle soll leicht richtig und 
schwer falsch zu benutzen sein.

Die primitiven DT sind ja nur die Grundbausteine einer Sprache. Ohne das 
geht es (fast) nicht. D.h. aber nicht, dass alles ein uint8_t ist ;-) Im 
Gegenteil!

> Aber ja, mit einem
>
> eeprom_write(Address{}, ...)
> 
> wär das Problem natürlich umgangen...

Ja genau.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.