Enum zu char array mappen mit verschiedenen Datentypen

[Peter (Gast)]

Hallo

Ich stehe mal wieder auf dem Schlauch und bräuchte mal einen Tipp.

Und zwar möchte ich gerne zu den Variablen sensor1 bis 3 die 
dazugehörigen Strings auswählen. Das folgende Beispiel klappt auch 
soweit. Sobald aber z.B. sensor1 einen anderen Datentyp als die 
restlichen Einträge hat, geht das natürlich nicht mehr, weil das 
array_Data ja als uint32_t definiert wurde.

Gibt es einen ähnlich eleganteren Weg, der mit unterschiedlichen 
Datentypen programmiert werden kann? Für mich ist der Vorteil hier, dass 
man über eine Zählvariable direkt die passenden Paare (Wert und Text) 
bekommt.

Bestimmt gibt es eine Möglichkeit mit Strukturen zu arbeiten. Aber da 
müsste man ja die einzelnen Members wieder explizit hinschreiben 
(struc.memberXYZ). Sonst fällt mir echt nichts ein...

const char* array_string[] = {"Sensor 1", "Sensor 2", "Sensor 3"};
uint32_t* array_Data[] = {&sensor1, &sensor2, &sensor3};

enum dataSequence{
  sensor1,
  sensor2,
  sensor3,
};


void foo(void)
{
    enum dataSequence s[3];

    s[0] = sensor1;
    s[1] = sensor2;
    s[2] = sensor3;

    int i;
    for(i = 0; i < 3; i++)
    {

        print_char_string(array_string[s[i]]);
        print_number(array_Data[s[i]]);

    }
}

void print_char_string(* pointer){}
void print_number(* pointer){}

https://www.cs.utah.edu/~germain/PPS/Topics/C_Language/enumerated_types.html

[Johann L. (gjlayde)]

Das lässt sich nicht compilieren:

#include <stdint.h>

const char* array_string[] = {"Sensor 1", "Sensor 2", "Sensor 3"};
uint32_t* array_Data[] = {&sensor1, &sensor2, &sensor3};

foo.c:4:28: error: 'sensor1' undeclared here (not in a function)
 uint32_t* array_Data[] = {&sensor1, &sensor2, &sensor3};
                            ^~~~~~~
...

Zudem wird später sensor1 als enum deklariert, und davon kann keine 
Adresse genommen wwerden:

#include <stdint.h>

uint32_t sensor1, sensor2, sensor3;

const char* array_string[] = { "Sensor 1", "Sensor 2", "Sensor 3" };
uint32_t* array_Data[] = { &sensor1, &sensor2, &sensor3 };

enum dataSequence
{
  sensor1,
  sensor2,
  sensor3,
};

foo.c:9:3: error: 'sensor1' redeclared as different kind of symbol
   sensor1,
   ^~~~~~~
foo.c:3:10: note: previous declaration of 'sensor1' was here
 uint32_t sensor1, sensor2, sensor3;
          ^~~~~~~
...

[A. S. (Gast)]

Ich fürchte auch, Du denkst in zuviel Abstraktionen.

Schreibe mal den Code direkt.

Es wird nicht klar, was genau Du denn in array_Data haben möchtest.

Und auch nichtz der Unterschied zwischen der Sensor-Instanz (sensor1..3) 
und dessen Index (auch sensor1..3).

[R. M. (Gast)]

Enum ist eigentlich nur eine Konstantendefinition, in deinem Beispiel, 
das Gleiche, wie

#define sensor1 0
#define sensor2 1
#define sensor3 1

Nicht als Array zu verstehen, könnte aber den Index für ein Array 
liefern.
Für den Typ, bräuchte dann aber jedes Arrayelement ein weiteres Feld.

struct sensors[Anzahl]{
 int value;
 char type;
 };

[Rolf M. (rmagnus)]

Peter schrieb:
> Hallo
>
> Ich stehe mal wieder auf dem Schlauch und bräuchte mal einen Tipp.
>
> Und zwar möchte ich gerne zu den Variablen sensor1 bis 3 die
> dazugehörigen Strings auswählen.

sensor1 bis 3 sind keine Variablen, sondern Enumeratoren. Sie belegen 
keinen Speicher und existieren nur im Quellcode. Daher ergibt es auch 
keinen Sinn, ihre Adresse zu nehmen.

> Das folgende Beispiel klappt auch soweit.

Das glaube ich dir nicht. Dein Code enthält mehrere Fehler.

> Sobald aber z.B. sensor1 einen anderen Datentyp als die
> restlichen Einträge hat, geht das natürlich nicht mehr, weil das
> array_Data ja als uint32_t definiert wurde.

sensor1 bis 3 sind alle vom Typ enum dataSequence.

[Johann L. (gjlayde)]

Kann man natürlich alles machen; unten als Fingerübung in C.

Ansonsten kann ich nur bekräftign, was Achim geschrieben hat: Das sieht 
schwer aus nach Über-Abstaktion.

In C++ ließe sich das alles kompakter formulieren, aber das Problem der 
Über-Abstraktion löst auch C++ nicht (statt der switch/case hätte man 
dann vtables).

#include <stdint.h>
#include <inttypes.h>
#include <stdlib.h>
#include <stdio.h>

typedef enum
{
  TYP_A,
  TYP_B,
  TYP_C,
  N_TYPES
} sensor_typ_t;

// 3 verschiedene Sensor-Typen, wobei die 1. Komponente bei allen Typen
// gleich ist, um damit spaeter Union sensor_t unterscheiden zu koennen.

typedef struct
{
    const sensor_typ_t typ;
    const char *name;
    uint32_t data;
} sensorA_t;

typedef struct
{
    const sensor_typ_t typ;
    const char *name;
    int data[2];
} sensorB_t;

typedef struct
{
    const sensor_typ_t typ;
    uint8_t data[4];
    const char *name;
} sensorC_t;

// Union fuer alle 3 Sensor-Typen: Typ des Sensors laesst sich
// am ersten Feld .typ bzw. .senorA.typ erkennen.

typedef union
{
    const sensor_typ_t typ;
    sensorA_t sensorA;
    sensorB_t sensorB;
    sensorC_t sensorC;
} sensor_t;

// Erschaffe 4 Sensoren vom Typ A, B, C, C.

sensor_t sensors[] =
{
    {
        .sensorA = { .typ = TYP_A, .name = "Sensor 1", .data = 1234 }
    },
    {
        .sensorB = { .typ = TYP_B, .name = "Sennsorr 2", .data = { 12, 34 } }
    },
    {
        .sensorC = { .typ = TYP_C, .name = "Sen 3", .data = { 1, 2, 3, UINT8_MAX } }
    },
    {
        .sensorC = { .typ = TYP_C, .name = "Sen 4", .data = { 5, 6, 7, INT8_MAX } }
    },
};


__attribute__((__noreturn__))
static void bug (const sensor_t *s)
{
    printf ("BUG %p\n", s);
    exit (EXIT_FAILURE);
}

// Ausgabe

static void print_typ (const sensor_t *s)
{
    if (s->typ >= N_TYPES)
        bug (s);

    printf (".typ = %d = '%c'\n", s->typ, 'A' + s->typ);
}

static void print_name (const sensor_t *s)
{
    printf (".name = \"");
    switch (s->typ)
    {
        default: bug (s); break;
        case TYP_A: printf ("%s", s->sensorA.name); break;
        case TYP_B: printf ("%s", s->sensorB.name); break;
        case TYP_C: printf ("%s", s->sensorC.name); break;
    }
    printf ("\"\n");
}

static void print_data (const sensor_t *s)
{
    printf (".data = ");

    switch (s->typ)
    {
        default: bug(s); break;

        case TYP_A:
            printf ("%" PRIu32, s->sensorA.data);
            break;

        case TYP_B:
            printf ("[ %d, %d ]", s->sensorB.data[0], s->sensorB.data[1]);
            break;

        case TYP_C:
            printf ("[ %" PRIu8 ", %" PRIu8 ", %" PRIu8 ", 0x%02" PRIx8 " ]",
                    s->sensorC.data[0], s->sensorC.data[1],
                    s->sensorC.data[2], s->sensorC.data[3]);
            break;
    }
    printf ("\n");
}

void print_sensor (const sensor_t *s)
{
    printf ("address = %p\n", s);
    print_typ (s);
    print_name (s);
    print_data (s);
    printf ("\n");
}

void print_sensors (const sensor_t *s, size_t n_sensors)
{
    printf ("\n#######\n# Sensors = %d\n\n", n_sensors);
    for (size_t i = 0; i < n_sensors; i++)
    {
        printf ("# %d:\n", i + 1);
        print_sensor (s++);
    }
}

#define ARRAY_SIZE(X) (sizeof (X) / sizeof (*X))

int main (void)
{
    print_sensors (sensors, ARRAY_SIZE (sensors));

    sensor_t *s = &sensors[3];
    s->sensorC.name = "Sensor C.2";
    s->sensorC.data[2] = 42;
    print_sensors (s, 1);

    // s->sensorC.typ = TYP_A;  //// error: assignment of read-only member 'typ'
}

Ausgabe:

#######
# Sensors = 4

# 1:
address = 0x20e
.typ = 0 = 'A'
.name = "Sensor 1"
.data = 1234

# 2:
address = 0x216
.typ = 1 = 'B'
.name = "Sennsorr 2"
.data = [ 12, 34 ]

# 3:
address = 0x21e
.typ = 2 = 'C'
.name = "Sen 3"
.data = [ 1, 2, 3, 0xff ]

# 4:
address = 0x226
.typ = 2 = 'C'
.name = "Sen 4"
.data = [ 5, 6, 7, 0x7f ]


#######
# Sensors = 1

# 1:
address = 0x226
.typ = 2 = 'C'
.name = "Sensor C.2"
.data = [ 5, 6, 42, 0x7f ]

[STK500-Besitzer (Gast)]

Text und Sensor-Datentyp gehören zusammen?!
Also eine struct "Sensor_struct"

Der Sensor-Typ kann unterschiedlich sein?
Also eine Union "Sensor_union".

Die Sensor_struct besteht also aus einem Char-Array und einer 
Sensor_union".

Daraus dann ein Array "Sensor_array" erstellen.

union Sensor_union{
  // die verschiedenen Ergebnistypen
};


typdef struct {
  char Name[9];
  union Sensor_union Sensor_data;
}Sensor_struct;


Sensor_struct Sensor_array[3];

Oder?

[Peter (Gast)]

Guten Morgen.

Vielen Dank für die teils ausführlichen Antworten.


Ich hatte mich beim Vereinfachen des Codes verschrieben.
Sollte so aussehen:

const char* array_string[] = {"Sensor 1", "Sensor 2", "Sensor 3"};
uint32_t* array_Data[] = {&var_sensor1, &var_sensor2, &var_sensor3};

enum dataSequence{
  sensor1,
  sensor2,
  sensor3,
};

So lässt es sich aber bei mir compilieren und richtig ausführen.

Da komme ich wohl nicht drumherum mir verschiedene Strukturen zu 
schreiben.

[Rufus Τ. F. (rufus)]

Peter schrieb:
> Sollte so aussehen:

Schön. Aber was soll das? Welches Problem willst Du damit eigentlich 
lösen?

[A. S. (Gast)]

Peter schrieb:
> So lässt es sich aber bei mir compilieren und richtig ausführen

Dann lass "s[3]" einfach weg und arbeite direkt mit den enums oder dem 
Index ....

Peter schrieb:

void foo(void)
{
    for(int i = 0; i < 3; i++)
    {
        print_char_string(array_string[i]);
        print_number(array_Data[i]);

    }
    /* oder nur einer ... */
    print_char_string(array_string[sensor2]);
}

[Wilhelm M. (wimalopaan)]

Johann L. schrieb:

> In C++ ließe sich das alles kompakter formulieren, aber das Problem der
> Über-Abstraktion löst auch C++ nicht (statt der switch/case hätte man
> dann vtables).

Nein, denn man muss nicht notwendigerweise Laufzeitpolymorphie (s.o. 
vtables) verwenden.

Er möchte ja einfach "nur" generischen Code haben. Und das würde man in 
C++ ganz einfach mit statischer Polymorphie lösen.

Es steht zwar in der Fragestellung nicht explizit drin, doch ich vermute 
mal stark, dass es eine reine C-Frage ist. Und da C nun mal eine 
nicht-generische Sprache ist, kann man das Problem nur mit 
poor-mans-polymorphism lösen.

[René H. (Gast)]

Wilhelm M. schrieb:
> Johann L. schrieb:
>
>> In C++ ließe sich das alles kompakter formulieren, aber das Problem der
>> Über-Abstraktion löst auch C++ nicht (statt der switch/case hätte man
>> dann vtables).
>
> Nein, denn man muss nicht notwendigerweise Laufzeitpolymorphie (s.o.
> vtables) verwenden.
>
> Er möchte ja einfach "nur" generischen Code haben. Und das würde man in
> C++ ganz einfach mit statischer Polymorphie lösen.
>
> Es steht zwar in der Fragestellung nicht explizit drin, doch ich vermute
> mal stark, dass es eine reine C-Frage ist. Und da C nun mal eine
> nicht-generische Sprache ist, kann man das Problem nur mit
> poor-mans-polymorphism lösen.

Hat man Dir in der Schule oft das Pausenbrot geklaut?

Sry, der Wissensstand vom TO kommt klar raus.

Grüsse,
René

[DPA (Gast)]

Wilhelm M. schrieb:
> Es steht zwar in der Fragestellung nicht explizit drin, doch ich vermute
> mal stark, dass es eine reine C-Frage ist. Und da C nun mal eine
> nicht-generische Sprache ist, kann man das Problem nur mit
> poor-mans-polymorphism lösen.

Bei C-Structs gibt es keine Vererbung, aber das ist ein Vorteil, kein 
Nachteil, denn man kann stattdessen Aggregation nutzen:

Ungetestet:

enum sensor_type {
  SENSOR_TYPE_A,
  SENSOR_TYPE_B
};

struct sensor {
  enum sensor_type type;
  const char* name;
};

struct light_sensor {
  struct sensor sensor;
  int wavelength;
};

struct audio_sensor {
  struct sensor sensor;
  float min_freq, max_freq, db_factor;
};

struct light_sensor light_sensor_1 = {
  .sensor = {
    .name = "light 1"
  },
  .wavelength = 123
};

struct audio_sensor audio_sensor_1 = {
  .sensor = {
    .name = "audio 1"
  },
  .min_freq = 100,
  .max_freq = 100000,
  .db_factor = 12.3
};

struct sensor* sensor_list[] = {
  &light_sensor_1.super,
  &audio_sensor_1.super
};
size_t sensor_count = sizeof(sensor_list)/sizeof(*sensor_list);

int main(){
  for(size_t i=0; i<sensor_count; i++)
    printf("sensor: ", sensor_list[i]);
}

In go ist das noch etwas schöner. Um von der Liste wieder auf den 
derived typ zugreifen zu können braucht man einen upcast, aber das ist 
auch bei c++ nicht anders.

[DPA (Gast)]

DPA schrieb:
> printf("sensor: ", sensor_list[i]);

Edit, sollte 'printf("sensor: %s\n", sensor_list[i]->name);' sein.

[Wilhelm M. (wimalopaan)]

DPA schrieb:
> Wilhelm M. schrieb:
>> Es steht zwar in der Fragestellung nicht explizit drin, doch ich vermute
>> mal stark, dass es eine reine C-Frage ist. Und da C nun mal eine
>> nicht-generische Sprache ist, kann man das Problem nur mit
>> poor-mans-polymorphism lösen.
>
> Bei C-Structs gibt es keine Vererbung, aber das ist ein Vorteil, kein
> Nachteil, denn man kann stattdessen Aggregation nutzen:

Von Vererbung hatte ich gar nicht gesprochen.

> In go ist das noch etwas schöner. Um von der Liste wieder auf den
> derived typ zugreifen zu können braucht man einen upcast,

Du meinst hier einen "down-cast" oder besser eine "cross-cast", da es ja 
keine Vererbung und damit kein Liskov gibt, wie Du oben selbst sagst.

Willst Du nun Deine Liste verwenden, muss Du nun (wie Johann es oben mal 
exemplarisch gemacht hat) zu Fuß anhand eines Diskriminators (etwa per 
switch) entscheiden, um ein type-dispatching durchzuführen. Dann sind 
wir bei dem oben von mir genannten poor-mans-polymorphism.

[DPA (Gast)]

Wilhelm M. schrieb:
> Willst Du nun Deine Liste verwenden, muss Du nun (wie Johann es oben mal
> exemplarisch gemacht hat) zu Fuß anhand eines Diskriminators (etwa per
> switch) entscheiden, um ein type-dispatching durchzuführen. Dann sind
> wir bei dem oben von mir genannten poor-mans-polymorphism.

Der springende Punkt ist doch aber gerade, dass das bei C++ ebenso ist, 
solange die abgeleiteten Typen unterschiedliche Funktionens sets haben. 
Bei Funktionen, die nur die Basisklasse benötigen, muss man ebenfalls in 
beiden fällen nicht casten. Nur wenn man mal eine Funktion überladen 
muss, dann hat man einen Cast mehr. Dafür spart man sich die ganzen 
Probleme, die Vererbung mit sich bringen würde. Keine sich 
überschneidenden Namensräume zu haben finde ich vereinfacht vieles.

[Wilhelm M. (wimalopaan)]

DPA schrieb:
> Wilhelm M. schrieb:
>> Willst Du nun Deine Liste verwenden, muss Du nun (wie Johann es oben mal
>> exemplarisch gemacht hat) zu Fuß anhand eines Diskriminators (etwa per
>> switch) entscheiden, um ein type-dispatching durchzuführen. Dann sind
>> wir bei dem oben von mir genannten poor-mans-polymorphism.
>
> Der springende Punkt ist doch aber gerade, dass das bei C++ ebenso ist,
> solange die abgeleiteten Typen unterschiedliche Funktionens sets haben.

Nein, wenn sie überschrieben sind, macht es der Compiler per vtable.

> Bei Funktionen, die nur die Basisklasse benötigen, muss man ebenfalls in
> beiden fällen nicht casten.

Da ich dann nur den statischen Typ verwende, benutze ich auch keine 
Laufzeitpolymorphie. Dann brauch ich das ganze Konstrukt nicht.

> Nur wenn man mal eine Funktion überladen
> muss, dann hat man einen Cast mehr.

Genau, sagte ich ja oben. Bei C++ braucht man (wegen vtable) keinen 
down-cast.

> Dafür spart man sich die ganzen
> Probleme, die Vererbung mit sich bringen würde.

Die wären?

> Keine sich
> überschneidenden Namensräume zu haben finde ich vereinfacht vieles.

Wo kommt das in dem Beispiel vor?

Wie ich oben schon sagte, kann man es auch (oft besser) mit stat. 
Polymorphie lösen.

[Zweig (Gast)]

Wilhelm M. schrieb:
> Wie ich oben schon sagte, kann man es auch (oft besser) mit stat.
> Polymorphie lösen.

wie würde das denn aussehen?

[DPA (Gast)]

Wilhelm M. schrieb:
>> Der springende Punkt ist doch aber gerade, dass das bei C++ ebenso ist,
>> solange die abgeleiteten Typen unterschiedliche Funktionens sets haben.
>
> Nein, wenn sie überschrieben sind, macht es der Compiler per vtable.

Nein, unterschiedliche Funktions sets, nicht identische. Du bringst 
genau den fall, den ich spezifisch ausgeschlossen hatte.

>> Bei Funktionen, die nur die Basisklasse benötigen, muss man ebenfalls in
>> beiden fällen nicht casten.
>
> Da ich dann nur den statischen Typ verwende, benutze ich auch keine
> Laufzeitpolymorphie. Dann brauch ich das ganze Konstrukt nicht.

Genau, hier verstehen wir uns wieder. Ich würde noch behaupten, dass die 
fälle, wo man direckt schon die Funktion nutzen kann, weil man die 
richtigen Typen schon hat, etwa 80% aller Fälle ausmacht.

>> Nur wenn man mal eine Funktion überladen muss, dann hat man einen Cast
>> mehr.
>
> Genau, sagte ich ja oben. Bei C++ braucht man (wegen vtable) keinen
> down-cast.

Aber nur in diesem Spezialfall, wenn man im übergeordneten Typ eine 
Funktion hat, die man auch überladen kann. Sonst muss man entweder eine 
für den Typ unsinnige einführen, oder doch wieder je nach Typ einen 
anderen downcast machen. In dem nicht unüblichen fall hat man logisch 
dann häufig eine Funktion die die Objekte verarbeiten, und nicht eine 
Funktion die eine logische eigenschaft des Objekts wäre, womit die 
lösung mit überladung zu bestenfalls unschönen Architekturen führt.

>> Dafür spart man sich die ganzen Probleme, die Vererbung mit sich bringen
>> würde.
>
> Die wären?

Siehe nächsten Satz. Ausserdem hat man damit eine unnötige Variation 
etwas zu tun, das auch ohne genausogut geht. Und man kann schnell 
unnötige oder problematische Vererbungen machen, wenn man später merkt 
dass z.B. ein Kreis doch keine spezielle Ellipse ist und umgekehrt. Ohne 
Vererbung würde man garnicht erst auf die Idee kommen, das eine könne 
teil des anderen sein.

>> Keine sich überschneidenden Namensräume zu haben finde ich vereinfacht
>> vieles.
>
> Wo kommt das in dem Beispiel vor?

Wozu muss es?

> Wie ich oben schon sagte, kann man es auch (oft besser) mit stat.
> Polymorphie lösen.

Finde ich nicht. Ist übrigens auch nicht im Beispiel.

[Wilhelm M. (wimalopaan)]

DPA schrieb:
> Aber nur in diesem Spezialfall, wenn man im übergeordneten Typ eine
> Funktion hat, die man auch überladen kann.

Ich denke, Du meinst: überschreiben.

> Sonst muss man entweder eine
> für den Typ unsinnige einführen, oder doch wieder je nach Typ einen
> anderen downcast machen.

Wenn Du das machen "musst", deutet das fast immer auf eine falsche 
Modellierung hin. Denn Du benutzt dann eben nicht das Interface. Kann 
man aber per NVI lösen.

>>> Dafür spart man sich die ganzen Probleme, die Vererbung mit sich bringen
>>> würde.
>>
>> Die wären?
>
> Siehe nächsten Satz. Ausserdem hat man damit eine unnötige Variation
> etwas zu tun, das auch ohne genausogut geht.

Verstehe nicht, was Du meinst.

> Und man kann schnell
> unnötige oder problematische Vererbungen machen, wenn man später merkt
> dass z.B. ein Kreis doch keine spezielle Ellipse ist und umgekehrt. Ohne
> Vererbung würde man garnicht erst auf die Idee kommen, das eine könne
> teil des anderen sein.

Konformanz-Verletzungen gibt auch anderswo.

>>> Keine sich überschneidenden Namensräume zu haben finde ich vereinfacht
>>> vieles.
>>
>> Wo kommt das in dem Beispiel vor?
>
> Wozu muss es?

Wenn Du es erwähnst.

[Wilhelm M. (wimalopaan)]

Zweig schrieb:
> Wilhelm M. schrieb:
>> Wie ich oben schon sagte, kann man es auch (oft besser) mit stat.
>> Polymorphie lösen.
>
> wie würde das denn aussehen?

Mal ein einfaches Beispiel:

#include <cstdint>
#include <array>
#include <tuple>
#include <iostream>

struct DevA;
struct DevB;
struct DevC;

template<typename Device, typename ValueType, auto Size>
struct Sensor {
    template<typename Stream>
    Stream& out(Stream& stream) {
        return stream << Size << '\n'; // zu erweitern ...
    }
private:
    std::array<ValueType, Size> mData;
};

std::tuple sensors{
    Sensor<DevA, uint8_t, 10>{}, 
    Sensor<DevB, uint32_t, 100>{},
    Sensor<DevC, double, 5>{}
};

int main() {
    std::apply([](auto&... s){
        (s.out(std::cout), ...);        
    }, sensors);
}

[DPA (Gast)]

Wilhelm M. schrieb:
> Verstehe nicht, was Du meinst.

Ich bezihe mich auf die 2 Sätze des Zitats, die du auseinander genommen 
hast. Der zweite ist eine folge des anderen.

[Zweig (Gast)]

Wilhelm M. schrieb:
> Mal ein einfaches Beispiel:

Und wo ist da das enum und wie spreche ich einen von den drei Sensoren 
an.
?

[Wilhelm M. (wimalopaan)]

Zweig schrieb:
> Wilhelm M. schrieb:
>> Mal ein einfaches Beispiel:
>
> Und wo ist da das enum und wie spreche ich einen von den drei Sensoren
> an.
> ?

Im OP stand ja auch nichts von Sensorfunktionen (außer den Namen 
auszugeben und einen Wert). Also, was möchtest Du denn machen?

[jzjjf (Gast)]

Peter schrieb:
> const char* array_string[] = {"Sensor 1", "Sensor 2", "Sensor 3"};
> uint32_t* array_Data[] = {&sensor1, &sensor2, &sensor3};
>
> enum dataSequence{
>   sensor1,
>   sensor2,
>   sensor3,
> };
>
> void foo(void)
> {
>     enum dataSequence s[3];
>
>     s[0] = sensor1;
>     s[1] = sensor2;
>     s[2] = sensor3;
>
>     int i;
>     for(i = 0; i < 3; i++)
>     {
>
>         print_char_string(array_string[s[i]]);
>         print_number(array_Data[s[i]]);
>
>     }
> }
>
> void print_char_string(* pointer){}
> void print_number(* pointer){}



ist nicht das genau das gleiche?

const char* array_string[] = {"Sensor 1", "Sensor 2", "Sensor 3"};
uint32_t*   array_Data[] = {&sensor1, &sensor2, &sensor3};

enum{
  sensor1 = 0,
  sensor2,
  sensor3,
  sensormax
};

void foo(void)
{
    int i;
    for(i = 0; i < sensormax ; i++)
    {
        print_char_string(array_string[i]);
        print_number(array_Data[i]);

    }
}

[Zweig (Gast)]

Wilhelm M. schrieb:
> Im OP stand ja auch nichts von Sensorfunktionen (außer den Namen
> auszugeben und einen Wert). Also, was möchtest Du denn machen?

Ich hätte gerne mal ein Beispiel bei dem es z.B 3 unterschiedliche
SenorTypen gibt.
Klar gleiche Interface aber unterschiedliche Implementierung.
Da fehlt mir ein Ansatz wie ich z.B über einen enum einer dieser 
Sensoren Typen auswähle, eine Instanz bilde und fortan nur noch mit 
diesem interagiere.

Ist sowas auch ohne vtable möglich?

[Wilhelm M. (wimalopaan)]

Zweig schrieb:
> Wilhelm M. schrieb:
>> Im OP stand ja auch nichts von Sensorfunktionen (außer den Namen
>> auszugeben und einen Wert). Also, was möchtest Du denn machen?
>
> Ich hätte gerne mal ein Beispiel bei dem es z.B 3 unterschiedliche
> SenorTypen gibt.
> Klar gleiche Interface aber unterschiedliche Implementierung.
> Da fehlt mir ein Ansatz wie ich z.B über einen enum einer dieser
> Sensoren Typen auswähle, eine Instanz bilde und fortan nur noch mit
> diesem interagiere.

Genau das steht doch oben: Du hast da drei unterschiedliche Sensortypen, 
sie werden instanziiert, und dann wird über sie iteriert.