For Schleife mit Hindernissen

[Siro]

Nabend Peter,
dank Dir nochmal für die Rückmeldung
die Bibliotheken sind gut dokumentiert und findet man überall im Netz, mit der Benutzung habe ich auch keine Probleme.
Wenn ich aber mal schauen will wie etwas implementiert wurde und dann auf folgende Konstukte in einer Datei stoße, bin ich echt überfordert
und das möchte ich nicht in meinem Code drin haben, weil ich es nicht verstehe, gebe ich gern zu.

Das muss ich ja auch nicht benutzen, ist mir klar, aber der Code steht ja dort nicht umsonst, also möchte ich ihn auch verstehen,
so wie ich auch mein Programm verstehe. (Meistens jedenfalls) Das muss mir jetzt auch keiner auseinanderpflücken, das ist nur ein Beispiel
aus einer Header Datei, die ich eben mal geöffnet habe.

Ich meine solche Strickmuster:

#if defined _GNU_SOURCE && defined __GNUC__
#define strdupa(__s) \
    (__extension__ ({const char *__in = (__s); \
             size_t __len = strlen (__in) + 1; \
             char * __out = (char *) __builtin_alloca (__len); \
             (char *) memcpy (__out, __in, __len);}))
#define strndupa(__s, __n) \
    (__extension__ ({const char *__in = (__s); \
             size_t __len = strnlen (__in, (__n)) + 1; \
             char *__out = (char *) __builtin_alloca (__len); \
             __out[__len-1] = '\0'; \
             (char *) memcpy (__out, __in, __len-1);}))
#endif /* _GNU_SOURCE && __GNUC__ */

wenn ein Header z.B. wie folgt aussieht, gibt er für mich auch wieder Sinn, da braucht man garnicht drüber diskutieren. Ist ein Auzug vom Keil Compiler C51

extern char *strcat (char *s1, char *s2);
extern char *strncat (char *s1, char *s2, int n);

extern char strcmp (char *s1, char *s2);
extern char strncmp (char *s1, char *s2, int n);

extern char *strcpy (char *s1, char *s2);
extern char *strncpy (char *s1, char *s2, int n);

extern int strlen (char *);

extern char *strchr (const char *s, char c);
extern int strpos (const char *s, char c);
extern char *strrchr (const char *s, char c);
extern int strrpos (const char *s, char c);

extern int strspn (char *s, char *set);
extern int strcspn (char *s, char *set);
extern char *strpbrk (char *s, char *set);
extern char *strrpbrk (char *s, char *set);

extern char memcmp (void *s1, void *s2, int n);
extern void *memcpy (void *s1, void *s2, int n);
extern void *memchr (void *s, char val, int n);
extern void *memccpy (void *s1, void *s2, char val, int n);
extern void *memmove (void *s1, void *s2, int n);
extern void *memset  (void *s, char val, int n);

Das Problem ist, wie Ihr schon sagt, die Vielfältigkeit und das macht es einem Bitschieber nicht grade einfach noch durchzublicken.

und 4 Unterstriche gibt es dann auch schon mal: Auszug stdarg.h vom GCC

#if !defined (_VA_LIST_) || defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__) || defined(WINNT)
/* The macro _VA_LIST_DEFINED is used in Windows NT 3.5  */

[Peter(TOO)]

Hallo Siro,

#if defined _GNU_SOURCE && defined __GNUC__
_GNU_SOURCE dürfte in einem Header definiert sein, wenn man bestimmte Projekte übersetzt.
__GNUC__ ist definiert wenn du mit dem GNU-Compiler übersetzt.
Der folgende Code wird nur verwendet wenn diese beiden Bedingungen erfüllt sind

#define strdupa(__s) \
    (__extension__ ({const char *__in = (__s); \
             size_t __len = strlen (__in) + 1; \
             char * __out = (char *) __builtin_alloca (__len); \
             (char *) memcpy (__out, __in, __len);}))
#define strndupa(__s, __n) \
    (__extension__ ({const char *__in = (__s); \
             size_t __len = strnlen (__in, (__n)) + 1; \
             char *__out = (char *) __builtin_alloca (__len); \
             __out[__len-1] = '\0'; \
             (char *) memcpy (__out, __in, __len-1);}))
#endif /* _GNU_SOURCE && __GNUC__ */
strdupa(); und strndupa(); werden als inline Code definiert, verwenden aber compilerinterne Mechanismen (__builtin_alloca (); )

Das Problem ist, wie Ihr schon sagt, die Vielfältigkeit und das macht es einem Bitschieber nicht grade einfach noch durchzublicken.
und 4 Unterstriche gibt es dann auch schon mal: Auszug stdarg.h vom GCC ]

#if !defined (_VA_LIST_) || defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__) || defined(WINNT)
/* The macro _VA_LIST_DEFINED is used in Windows NT 3.5  */
Ist ein Hinweis, dass bei obigen Bedingungen (Es wird z.B. für Windows NT 3.5 übersetzt, ein anderes Macro verwendet wird.

Gerade der GNU-Compiler ist für unzählige CPUs, Betriebssysteme und Versionen vorhanden. Und jede Variante hat halt ihre speziellen Eigenheiten.
Wenn man es beherrscht, kann man in C Code schreiben, welcher unter unterschiedlichen Betriebssystem und CPUs funktioniert, das spart dann eine Menge Arbeit bei 
der Pflege. Ich selbst habe z.B. Übertragungsprotokolle geschrieben, welche auf eine Micro-Controller (meist ein Hitachi H8) und unter Windows laufen. Dabei ist dann der
Sourcecode nur einmal auf der Festplatte abgelegt und wird in beiden Projekten eingebunden. Hat den Vorteil, dass beide Projekte immer automatisch auf dem selben
Stand sind, wenn man etwas ändert. 
Bei mir waren dann oft noch zwei unterschiedliche Compiler im Spiel, VC für Windows und IAR für den H8. Da muss man dann vieles selber machen, was einem der GNU schon abnimmt, z.B. haben die #pragma unterschiedliche Syntax bei den beiden Compilern.

MfG Peter(TOO)

[Siro]

Hallo Peter,
Du gibst Dir wirklich sehr viel Mühe mein Nichtwissen aufzubessern.
Würde am liebsten Unterricht bei Dir nehmen. Ganz im Ernst.

Wiederverwendbaren Code zu schreiben ist ja auch Ziel meiner Bemühungen seit Jahren.
Es scheiterte aber daran das ich immer in Assembler programmierte. Da ist eigentlich nichts mehr
wiederverwendbar wenn man den Prozessor wechselt. So habe ich das auch möglichst vermieden.
Einmal PIC immer PIC. Inzwischen sind es die NXP Prozessoren mit CORTEX M3 Kern.
Um die Möglichkeiten voll auszuschöpfen muss man schonmal gucken was der Compiler für einen Code daraus macht.
Denn es gibt bestimmte Dinge die entsprechenden Assemblercode voraussetzen sonst funktioniert es nicht.
Das kann man dann aber trotzdem meist auch in C umsetzen wenn man dann weis wie.
Da fehlt aber halt noch reichlich Erfahrung.
Wenn ich soviel Zeit in "C" investiert hätte wie in die verschiedenen Assembler der verschiedenen Prozessoren....

shedepe schrieb:
Dann hast du doch bestimmt auch deinen Compiler selber geschrieben, sonst kannst du ja nicht sicher gehen, dass der Compiler wirklich den Binärcode erzeugt den er soll.

Da liegst Du garnicht so verkehrt, das ist so ungefär mein Anliegen und im Prinzip hab ich das schon in kleinem Maßstab umgesetzt.
Mein Assemblermacros sind inzwischen ähnlich einer Hochsprache und wurden immer wieder optimiert.
Da weis ich wirklich aufs Bit genau was raus kommt und welche Laufzeit dafür benötigt wird.
Leider nur für einen Prozessor anwendbar.

Hier muste ich aber auch schon feststellen: je universeller man sein möchte umso kryptischer wird der Code.


Na wie dem auch sei:
Aus Fehlern lernt man und ich hoffe ich mache noch viele Fehler......