C: Kann man mittels #define einen Wert zurück geben?

Warum deklariert Du CreateMyArray nicht als Funktion?

Pete K. schrieb:
> Warum deklariert Du CreateMyArray nicht als Funktion?

Weil das erzeugte statische Array nur so lange existiert, bis die 
Funktion zurückkehrt, aber offenbar auch danach noch benötigt wird.

Rolf M. schrieb:
> Weil das erzeugte statische Array nur so lange existiert, bis die
> Funktion zurückkehrt, aber offenbar auch danach noch benötigt wird.

Nein!

Der Witz an statischen Variablen ist doch, daß sie ab Programmstart 
durchgehend existieren.

Weil das Feld in diesem Fall lokal definiert ist (wenn auch statisch), 
ist es über den Variablennamen nur innerhalb der Funktion erreichbar.
Aber über Zeiger oder sonstwie auch außerhalb der Funktion.

Nur automatische Variablen liegen auf dem Stack und werden beim 
Verlassen eines Blocks bzw. der Funktion aufgelöst.

W.S. schrieb:
> In C hat man keine solchen Dinge
> wie z.B. den 'const' Abschnitt in Pascal, wo man Konstanten definieren
> kann.

Aha. Bring' dich mal auf Stand. Seit 21 Jahren kann man Konstanten 
definieren.

Rolf M. schrieb:
> Weil das erzeugte statische Array nur so lange existiert, bis die
> Funktion zurückkehrt, aber offenbar auch danach noch benötigt wird.

Wenn man denn unbedingt will, kann man auch das. Arrays können zwar kein 
Funktionsergebnis sein, structs können das aber durchaus. Und arrays 
können auch Bestandteil von structs sein.

Ob das allerdings empfehlenswert ist, steht auf einem anderen Blatt.

Erst mal Danke für den Input. Das mit dem Array ist ja nur ein Beispiel. 
Was ich eigentlich will, das ein Struct mit einem variablen Datenfeld 
erstellt werden kann, aber eben ohne malloc() und ein Teil der Daten, 
wie z.B. der Name, im ROM liegt. Der Name wird im Makro automatisch aus 
den Parametern generiert. Und genau das geht eben mit einer Funktion 
nicht, oder doch?

Alle Structs und dessen Größe stehen schon bei Programmerstellung fest, 
sollen aber trotzdem variabel bleiben. Das hat für mich den Vorteil, das 
eben schon der Compiler meckert wenn der Speicher verbraucht ist. Das 
funktioniert ja soweit auch hervorragend, bis auf das Zurückgeben des 
Zeigers. Bis jetzt mache ich das über einen Funktionsparameter, aber das 
ist eben nicht ganz so elegant. Wenn ich den Zeiger nicht unbedingt 
benötige, kann ich ihn nicht einfach weglassen.

Wie man an dem obigen Beispiel mit dem ATOMIC_READ sieht, scheint es ja 
auch irgendwie mit Makros zu gehen.

Ste N. schrieb:
> Wie man an dem obigen Beispiel mit dem ATOMIC_READ sieht, scheint es ja
> auch irgendwie mit Makros zu gehen.

Die benutzen auch den Komma-Operator.

Bei Variablendefinitionen hat das Komma aber eine andere Bedeutung.

Ste N. schrieb:
> Gibt es eigentlich eine Möglichkeit von einer Makrodefinition einen Wert
> zurück zu geben? Hier mal ein Beispiel, was ich meine.

Beim GCC sind solche Dinge mit Statement Expressions möglich. Das ist
aber eine GCC-spezifische Spracherweiterung:

  https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Ich persönlich bin kein Freund solcher Spracherweiterungen. Ordentlicher
C-Code sollte IMHO mit

1

gcc -std=c18 -pedantic-errors

fehlerfrei kompiliert werden.

> Ich habe so etwas schon mal gesehen, wo es funktioniert. Das ist aber
> nur ein sehr einfaches Makro.
>
> #define OS_ATOMIC_READ(expr)  (__builtin_disable_interrupts(), _OS_Temp
> = (expr), __builtin_enable_interrupts(), _OS_Temp)

In diesem Fall besteht der Makrorumpf nur aus einem einzelnen Ausdruck,
der natürlich – wie jeder Ausdruck, der nicht vom Typ void ist – ein
Ergebnis hat, das von einem aufrufenden Programmteil bspw. einer
Variable zugewiesen werden kann.

In deinem Beispiel enthält der Makrorumpf aber zusätzlich noch eine
Deklaration, weswegen dein Vorhaben nur mit der o.g. Spracherweiterung
realisierbar ist.

Markus F. schrieb:
> W.S. schrieb:
>> In C hat man keine solchen Dinge
>> wie z.B. den 'const' Abschnitt in Pascal, wo man Konstanten definieren
>> kann.
>
> Aha. Bring' dich mal auf Stand. Seit 21 Jahren kann man Konstanten
> definieren.

Benamste Kompilezeitkonstanten sind in C – anders als in C++ –
nur mit #define möglich. Mit dem Schlüsselwort const werden
Read-Only-Variablen deklariert, was aber nicht dasselbe ist.

Klaus W. schrieb:
> Rolf M. schrieb:
>> Weil das erzeugte statische Array nur so lange existiert, bis die
>> Funktion zurückkehrt, aber offenbar auch danach noch benötigt wird.
>
> Nein!
>
> Der Witz an statischen Variablen ist doch, daß sie ab Programmstart
> durchgehend existieren.

Da hast du natürlich recht. Das gilt selbstverständlich nur für 
nicht-statische lokale Variablen. Mea culpa.

Ste N. schrieb:
> Alle Structs und dessen Größe stehen schon bei Programmerstellung fest,
> sollen aber trotzdem variabel bleiben.

Das verstehe ich nicht ganz. Nicht nur die Größe, sondern alle Elemente 
mit deren jeweiligen Typ und Position innerhalb der Struct sind zur 
Compilezeit bekannt. Man spricht sie über den bei der Definition des 
Typs bereits vergebenen Namen an. Was willst du da variabel machen?

> Das hat für mich den Vorteil, das eben schon der Compiler meckert wenn
> der Speicher verbraucht ist. Das funktioniert ja soweit auch
> hervorragend, bis auf das Zurückgeben des Zeigers. Bis jetzt mache ich
> das über einen Funktionsparameter, aber das ist eben nicht ganz so
> elegant. Wenn ich den Zeiger nicht unbedingt benötige, kann ich ihn nicht > 
einfach weglassen.

Aber ohne den Zeiger kannst du doch gar nicht drauf zugreifen.

Yalu X. schrieb:
> Beim GCC sind solche Dinge mit Statement Expressions möglich. Das ist
> aber eine GCC-spezifische Spracherweiterung:
>
>   https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Ist schon Krass! 4 Klammern an der richtigen Position haben das 
"Problem" gelöst.

1

#define CreateMyArray (name, size)       \

2

  ({static unsigned name [size];         \

3

    myFoo (name, size);})

So funktioniert es und wird Fehlerfrei und ohne Warnungen übersetzt!

Selbst mit der Option strict-ansi wird es erfolgreich übersetzt, 
allerdings mit reichlich Warnungen, darunter auch Kommentare mit //. 
Aber damit kann ich gut leben, strict-ansi nutze ich nicht und es ist ja 
nur für mich.

Also Danke für den Input Yalu, wieder was gelernt!

PittyJ schrieb:
> Anfänger sollten keine #define verwenden dürfen.

Bisschen krass ausgedrückt. Aber ich kann durchaus empfehlen, 
funktionsartige Makros durch Inline-Funktionen zu ersetzen, sofern das 
möglich ist.

EAF schrieb:
> Ste N. schrieb:
>> Was ich eigentlich will, das ein Struct mit einem variablen Datenfeld
>> erstellt werden kann,
> Das nennt man "dynamische Speicherverwaltung" oder Heap, was du da
> nutzen möchtest.

ich glaube du hast mein Anliegen nicht verstanden...

> Ste N. schrieb:
>> aber eben ohne malloc()
> Ach...
> Wie möchte es der Herr denn: Statisch oder dynamisch?

statisch

> Ste N. schrieb:
>> Und genau das geht eben mit einer Funktion
>> nicht, oder doch?
> Funktionen legen ihre lokalen Variablen auf dem Stack an.
> Aber dann darfst du die Adresse nicht per Return weiterreichen.

deswegen ja static

> Ste N. schrieb:
>> Alle Structs und dessen Größe stehen schon bei Programmerstellung fest,
>> sollen aber trotzdem variabel bleiben.
> Also eine konstante Größe, welche variabel ist?
> Ich sehe da einen Widerspruch!
> Du nicht?

Nö! Variabel sollen sie ja zur Compilezeit sein, nicht zur Laufzeit.

Am Ende sieht mein Makro so aus.

1

#define MERGE_(a,b)   a##b

2

#define STRINGIFY_(a) #a

3

4

#define CreateMyStruct(mystruct,size)                            \

5

  ({const char MERGE_(mystruct, _name)[] = STRINGIFY_(mystruct); \

6

    static myStruct_t MERGE_(mystruct, _struct);                 \

7

    static unsigned MERGE_(mystruct, _array)[size];              \

8

    _CreateStruct ( &MERGE_(mystruct, _struct),                  \

9

                    MERGE_(mystruct, _name),                     \

10

                    MERGE_(mystruct, _array),                    \

11

                    size);})

Also ich finde es genial einfach!

Dazu muß ich noch sagen, das in _CreateStruct() noch viel mehr passiert. 
Unter anderem wird aus den Structs eine verkette Liste erstellt, welche 
eben Arrays unterschiedlicher Länge beinhalten kann.
Wenn ich jetzt jeden Eintrag von Hand erstellen sollte, fände ich das 
ziemlich umständlich.

Ste N. schrieb:
>> Ste N. schrieb:
>>> Alle Structs und dessen Größe stehen schon bei Programmerstellung fest,
>>> sollen aber trotzdem variabel bleiben.
>> Also eine konstante Größe, welche variabel ist?
>> Ich sehe da einen Widerspruch!
>> Du nicht?
>
> Nö! Variabel sollen sie ja zur Compilezeit sein, nicht zur Laufzeit.

Das sind sie doch einfach durch Änderung des struct-Typs. Ich sehe aber 
nicht, wie dir das Makro dabei hilft.

A. S. schrieb:
>

1

> #define CreateMyStruct(name,size)    \

2

>   ({static myStruct_t s;             \

3

>     static unsigned   a[size];       \

4

>     _CreateStruct(&s, #name, a, size})

5

> 

6

>

>
> Das sollte identisch sein.
>
> O.T.: mit einem dritten Parameter und Zuweisung in der letzten Zeile
> wäre es auch ohne Erweiterung nutzbar.

Kannst Du das bitte noch mal näher erläutern?

Das mit dem String ist wirklich ne sehr gute Idee, manchmal sieht man 
den Wald vor lauten Bäumen nicht... aber der Rest geht so leider nicht. 
Das Makro kann ja dann nur 1x aufrufen werden und dafür bräuchte ich die 
ganzen Klimmzüge tatsächlich nicht. Beim nächsten Aufruf gibt es s und a 
schon und der Compiler meckert, und zwar zu recht.

So kann ich in meiner main() einfach nur

p_myA = CreateMyStruct (a, 256);
p_myB = CreateMyStruct (b, 128);
p_myC = CreateMyStruct (c, 64);
p_myD = CreateMyStruct (d, 256);

aufrufen und alles weitere wird automatisch abgeleitet.

A. S. schrieb:
> Kannst du die vielen erzeugten Namen nutzen? Im Editor oder Debugger?
> Fall nicht, lass sie weg. Nach außen ist ja nur der string-inhalt
> sichtbar.

Den Namen benötige ich wirklich nur zum debuggen. Könnte man mit einem 
weiteren #define bei Bedarf auch ausblenden ;) Aber dann wirds am Ende 
wirklich unübersichtlich...

Nop schrieb:
> Für persönlichen Gebrauch sicherlich cool. In einem professionellen
> Code-Review? Keine Chance für den ganzen Ansatz.

Da gebe ich dir natürlich vollkommen recht! Wie gesagt es ist eine 
private Spielerei. Das Makro wird wirklich nur im Initialisierungsteil 
der main() aufgerufen. Das ich das nicht in eine Schleife oder if/then 
Abfrage setzen kann, ist klar.

Rolf M. schrieb:
>> Nö! Variabel sollen sie ja zur Compilezeit sein, nicht zur Laufzeit.
>
> Das sind sie doch einfach durch Änderung des struct-Typs. Ich sehe aber
> nicht, wie dir das Makro dabei hilft.

Das hilft mir insofern, das es die Deklaration extrem unkompliziert 
macht. Zumindest für mich, siehe oben.

A. S. schrieb:
> Ste N. schrieb:
>> Beim nächsten Aufruf gibt es s und a schon und der Compiler meckert, und
>> zwar zu recht.
>
> Aber doch nur statc in einem Block in { }.
>
> Da kannst Du beliebig viele Blöcke von haben.

Funktioniert tatsächlich! Das wird ja immer besser und macht die Sache 
extrem übersichtlich. Das die Klammern einen Block abschotten, hätte ich 
jetzt nicht etwartet und deswegen auch nie probiert.

Danke!

Ich ahne langsam, was du vorhast.
Ich glaube dir auch, daß es in C mit dem Praeprozessor machbar ist, und 
sicher eine nette Spielerei.

Aber nüchtern betrachtet, geht sowas in C++ mit templates sicher 
wesentlich eleganter und möglicherweise besser.
Nachdem der gcc ja auch C++ kann, wäre es zumindest eine Überlegung 
wert?

Das wäre mal wieder eine Anwendung für den sogenannten X-macro-trick der 
nicht so bekannt ist.

1

// Liste

2

#define MY_STRUCTURES \

3

 MY_STRUCT(s1, 42 )  \

4

 MY_STRUCT(s2, 174 )  \

5

 MY_STRUCT(s3, 22 )  \

6

7

// Expansion 

8

#define MY_STRUCT(name, size)  \

9

typedef struct {  \

10

int var[size]; \

11

} name; 

12

MY_STRUCTURES 

13

#undef MY_STRUCT 

14

15

Daraus macht der Preprozessor dann ::

16

17

18

typedef struct { int var[42]; } s1;

19

typedef struct { int var[174]; } s2;

20

typedef struct { int var[22]; } s3;

BLE schrieb:
> he he he, ...
> Hat sich einer mal mit Zephyr angeschaut?
>
> Da werden OS Strukturen  PIN Configuration  ... genau mit solchen
> macros angelegt und teilweise wird dan im macro wider auf andere macros
> zugegriffen,
>
> Auch im Linuz kernel sind mir solche macros schon begegnet, war glaube
> ich der part power rails / Frequanzy scalling

Das war schon zu Zeit der pdp11 bekannt ;-)

@ Ste N.
Du kannst auch damit den Datentyp deiner variable ändern ...

1

// Liste

2

#define MY_STRUCTURES \

3

 MY_STRUCT(s1, 42 , int)  \

4

 MY_STRUCT(s2, 174, char )  \

5

 MY_STRUCT(s3, 22, float )  \

6

7

// Expansion 

8

#define MY_STRUCT(name, size, vtype)  \

9

typedef struct {  \

10

vtype var[size]; \

11

} name; 

12

MY_STRUCTURES 

13

#undef MY_STRUCT

ergibt:

typedef struct { int var[42]; } s1;
typedef struct { char var[174]; } s2;
typedef struct { float var[22]; } s3;

Klaus W. schrieb:
> Ich ahne langsam, was du vorhast.
> Ich glaube dir auch, daß es in C mit dem Praeprozessor machbar ist, und
> sicher eine nette Spielerei.
>
> Aber nüchtern betrachtet, geht sowas in C++ mit templates sicher
> wesentlich eleganter und möglicherweise besser.
> Nachdem der gcc ja auch C++ kann, wäre es zumindest eine Überlegung
> wert?

In C++ gibt es dafür std::array

BLE schrieb:
> Es ist halt z.B. abzuwägen was besser ist, ein complexes Macro oder jede
> menge copy past code.

Bei W.S. ist die Antwort klar, er mag Kopierpastencode.
Auf Cortex-M mit mehreren uarts hat er für jeden Uart ne eigene Funktion 
mit verdoppeltem Code:
uart1_CharOut()
uart2_CharOut()
uart3_CharOut()
etc.

Bei Programmierfragen darf man nicht W.S. fragen.
Er kann ja nichtmal C.