Struktur in C

Gast #2720270
Lesenswert?
• ▲
▼
Ich möchte folgende Werte an das Array bildpunkte in der 
Strukturvariablen bilddaten übergeben!?

10, 20, 30, 40, 50 //???
1
struct BILDDATEN
2
{
3
 unsigned char hoehe;
4
 unsigned char breite;
5
 unsigned char bildpunkte[5]; //???
6
};
7

8
int main()
9
{
10
 struct BILDDATEN bilddaten;
11
 
12
 bilddaten.hoehe = 10;
13
 bilddaten.breite = 5;
14
 bilddaten.bildpunkte[0] = 10; //???
15
 
16
 system("pause");
17
 return 0;
18
}
#2720540
Lesenswert?
• ▲
▼
Also bei mir geht das ohne Probleme durch den Compiler. Ich wüßte auch 
nicht, was daran falsch sein soll oder was mit "a flexible array member" 
gemeint sein könnte.

Rufus Τ. Firefly schrieb:
> struct BILDDATEN bilddaten = { 10, 5, { 10, 20, 30, 40, 50 } };

Man kann es auch noch etwas schicker schreiben:
1
struct BILDDATEN bilddaten =
2
{
3
  .hoehe = 10,
4
  .breite = 5,
5
  .bildpunkte = { 10, 20, 30, 40, 50 }
6
};
So sieht man gleich, was die einzelnen Zahlen bedeuten, und wenn man mal 
die Elemente verschiebt oder neue dazwischen einfügt, wird nicht die 
ganze Initialisierung durcheinandergebracht. Allerdings gibt es einige 
Compiler, die sich noch immer an der Computer-Steinzeit orientieren und 
damit nicht klarkommen.
Persönliche Seite #2720587
Lesenswert?
• ▲
▼
Rolf Magnus schrieb:
> Allerdings gibt es einige
> Compiler, die sich noch immer an der Computer-Steinzeit orientieren und
> damit nicht klarkommen.

Andersherum formuliert, es gibt nach wie vor nur wenige Compiler, die 
C99 unterstützen. Als Computer-Steinzeit würde ich allerdings die Zeit 
vor C89 ansehen, wie sie der "Ur-K&R" beschreibt.

Das ist halt die Crux, zwischen Portabilität und Lesbarkeit abzuwägen. 
Portabilität hier nicht in dem Sinne, daß ein Programm unbedingt auch 
auf anderen Plattformen/Compilern nutzbar ist, sondern in dem Sinne, daß 
der vom Programmierer verwendete Programmierstil ihn nicht diesbezüglich 
einengt.
Gast #2720656
Lesenswert?
• ▲
▼
Rufus Τ. Firefly schrieb:
> Rolf Magnus schrieb:
>> Allerdings gibt es einige
>> Compiler, die sich noch immer an der Computer-Steinzeit orientieren und
>> damit nicht klarkommen.
>
> Andersherum formuliert, es gibt nach wie vor nur wenige Compiler, die
> C99 unterstützen. Als Computer-Steinzeit würde ich allerdings die Zeit
> vor C89 ansehen, wie sie der "Ur-K&R" beschreibt.

C89 ist jetzt 23 Jahre alt. Ok, vielleicht nicht Steinzeit, sondern eher 
so die Antike…
Man beachte auch, daß C89 durch Erscheinen von C99 offiziell für 
ungültig erklärt wurde.

> Das ist halt die Crux, zwischen Portabilität und Lesbarkeit abzuwägen.

Portabilität auf Compiler, die es selbst nach 13 Jahren C99 noch nicht 
geschafft haben, mit der Entwicklung von C aufzuschließen. Von C11 will 
ich lieber gar nicht erst anfangen. Soll ich da noch 30 Jahre warten, 
bevor ich das einigemaßen portabel einsetzen kann?
Dein Argument verstehe ich schon, ich find's halt nur traurig.
#2720686
Lesenswert?
• ▲
▼
Rolf Magnus schrieb:
> Portabilität auf Compiler, die es selbst nach 13 Jahren C99 noch nicht
> geschafft haben, mit der Entwicklung von C aufzuschließen. Von C11 will
> ich lieber gar nicht erst anfangen. Soll ich da noch 30 Jahre warten,
> bevor ich das einigemaßen portabel einsetzen kann?
> Dein Argument verstehe ich schon, ich find's halt nur traurig.

afaik ist auch der gcc nicht feature complete was c99 angeht.
gibt es denn überhaupt einen compiler, der dies ist?
Gast #2720857
Lesenswert?
• ▲
▼
Vlad Tepesch schrieb:
> afaik ist auch der gcc nicht feature complete was c99 angeht.

Wenigstens versuchen sie's. Viele andere kümmern sich da gar nicht erst 
drum und haben's auch nicht vor. Deshalb gibt's dort nichtmal die 
grundlegendsten C99-Features.

> gibt es denn überhaupt einen compiler, der dies ist?

Also wenn, dann am ehesten diesen hier: http://www.comeaucomputing.com/
Der gilt sowohl für C, als auch für C++ als die Referenz, wenn's um 
Konformität geht.
#2720920
Lesenswert?
• ▲
▼
Rolf Magnus schrieb:
> Warum?

Weil die Werte nur anhand ihrer Position in der Liste (ggf. durch {} 
untergliedert) den Elementen zugeordnet werden, was immanent 
fehlerträchtig ist.
Wenn dann Werte fehlen, kann es gut daran liegen, daß anders 
initialisiert wird als man es vielleicht wollte.

Der gcc liefert deshalb bei -Wextra in so einem Fall eine Warnung:
1
user@ubuntu:~$ nl t.c
2
     1  #include <stdlib.h>
3
     2  #include <stdio.h>
4
     3  
5
     4  
6
     5  int main()
7
     6  {
8
     7      struct 
9
     8      {
10
     9          int      i;
11
    10          unsigned u;
12
    11          char     c[2];
13
    12      } strusi = { 0 };
14
    13  
15
    14      return 0;
16
    15  }
17
user@ubuntu:~$ gcc -Wall -Wextra t.c
18
t.c: In function ‘main’:
19
t.c:12: warning: missing initializer
20
t.c:12: warning: (near initialization for ‘strusi.u’)
21
t.c:12: warning: unused variable ‘strusi’

Ich kompiliere in der Regel alles mit -Wextra ohne Warnungen, deshalb 
leiste ich mir keine unvollständigen Initialisierungslisten (wenn schon 
C; bei C++ sind ja eh Konstruktoren angesagt).
Gast #2720931
Lesenswert?
• ▲
▼
Klaus Wachtler schrieb:
> Rolf Magnus schrieb:
>> Warum?
>
> Weil die Werte nur anhand ihrer Position in der Liste (ggf. durch {}
> untergliedert) den Elementen zugeordnet werden, was immanent
> fehlerträchtig ist.

Deshalb finde ich auch die Initialisierung mit Namen wesentlich besser.
Aber es ging ja speziell um die Initialisierung von allem mit 0. Da sind 
Positionen recht egal.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren