Größe eines externen Arrays in C

Du musst die Größe halt auf irgend eine Art mit übergeben. Eleganter 
geht es in C nicht.

Oliver

header.h:

1

#ifndef _HEADER_H_

2

#define _HEADER_H_

3

4

5

#include <stddef.h>

6

7

typedef struct

8

{

9

  const int a;

10

  const int b;

11

} element_t;

12

13

extern size_t    nElemente;

14

15

#endif /* ifndef _HEADER_H_ */

source.c:

1

#include "header.h"

2

3

const element_t element[] = { {1,2}, {3,4}, {5,6} };

4

5

size_t    nElemente = sizeof(element)/sizeof(element[0]);

main.c:

1

#include <stdlib.h>

2

#include <stddef.h>

3

#include <stdio.h>

4

5

#include "header.h"

6

7

8

int main( int nargs, char **args )

9

{

10

  printf( "Das Feld hat %lu Elemente\n", (unsigned long)nElemente );

11

12

  return 0;

13

}

Ausgabe:

1

klaus@lap7:~$ gcc -Wall main.c source.c

2

klaus@lap7:~$ ./a.out

3

Das Feld hat 3 Elemente

Es ist insofern nicht gleich, als es kompiliert und läuft.

Natürlich kannst du nach demselben Strickmuster auch statt einer size_t 
eine struct mit mehreren machen.

PS: in meinem Vorschlag fehlt bei nElemente noch jeweils ein const in 
der .h und der .c.

Deinen Vorschlag mit der struct finde ich für C durchaus angemessen.

Wesentlich eleganter geht es dann wohl erst in C++...

Aus dem typedef für element_t würde ich die const von a und b wegnehmen; 
du machst ja nachher eh das ganze Feld nochmal const. Noch conster geht 
nicht.

Sonst würde ich da nicht mehr viel verpfuschen.
Tricksen kann man noch viel, das macht es aber nicht unbedingt besser 
oder gar verständlicher.

In C zerfallen die Array-Bezeichner (fast) immer (wie in diesem Fall) zu 
einem Zeiger (decay of array designator). Das geht nur in der 
Übersetzungseinheit, in dem der Compiler die vollständige Deklaration 
des Array-Bezeichners gesehen hat. Demzufolge geht es eben nicht 
zwischen Übersetzungseinheiten bzw. bei Parameterlisten.

Da hier schon C++ angesprochen wurde: daher kommt auch die Äußerung von 
Bjarne: C-Arrays sind so dummm, sie kennen noch nicht einmal ihre Länge.

Ist sofern ist die Lösung mit dem eigenen Datentyp (struct) schon ok. 
Und bei Parameterlisten auch die Lösung mit einem zusätzlichen Parameter 
für die Länge. Beides allerdings bei statischen Arrays Krücken. Aber so 
ist C nun mal ...
Die Variante mit einem CPP-Macro ist natürlich wie immer die 
schlechteste Variante.

Aktuell exponiert deine source.c (bzw. dessen header) nur ein Symbol, 
nämlich extern const element_t element[];

Das reicht wie du festgestellt hast nicht, du musst also ein zweites 
Symbol exponieren, nämlich die Länge von element[].

Jetzt hast du zwei Möglichkeiten:
- per Makro
- per Variable und forward declaration

Die Makro-Lösung hat den Nachteil dass du die Länge hartcodiert angeben 
musst, also
#define len 3
Spielereien mit sizeof() im Makro werden nicht funktionieren da in 
main.c die Arrays ja bereits zerfallen sind.
Also musst du das Makro händisch aktuell halten.

Deswegen würde ich hier eine Variable "element_len" exponieren. Wenn die 
Variable innerhalb von source.c angelegt wird kannst du da auch mit 
sizeof() arbeiten. Im HEader hast du dann nur noch eine forward 
declaration

Ob du eine losgelöste Variable exponierst oder die Infos in einem struct 
sammelst ist dann syntaktischer Zucker, kommt auf deinen Gusto an.

Le X. schrieb:

> Die Makro-Lösung hat den Nachteil dass du die Länge hartcodiert angeben
> musst, also
> #define len 3
> Spielereien mit sizeof() im Makro werden nicht funktionieren da in
> main.c die Arrays ja bereits zerfallen sind.
> Also musst du das Makro händisch aktuell halten.

Naja, das ist ja nicht der Nachteil der Macro-Lösung: Du kannst das 
Macro ja auch in der Definition des Arrays verwenden, damit hast Du 
keine Duplikation.

Der Nachteil der CPP-Macros ist, dass sie nicht ge-scoped sind und 
einfach nur Textersatz, können also an beliebigen Stellen "zuschlagen".

> Ob du eine losgelöste Variable exponierst oder die Infos in einem struct
> sammelst ist dann syntaktischer Zucker, kommt auf deinen Gusto an.

Nein, das ist kein syntaktischer Zucker, sondern - im Gegenteil - ein 
ganz wichtiger Vorteil: denn mit einem struct verknüpfst Du 
zusammengehörige Informationen zu einer Entität. Leider ist es in C 
nicht ganz, nur fast ein Datentyp, da man freie Funktionen nicht 
überladen kann und es keine Elementfunktionen gibt.

Klaus W. schrieb:
> Aus dem typedef für element_t würde ich die const von a und b wegnehmen;
> du machst ja nachher eh das ganze Feld nochmal const. Noch conster geht
> nicht.

Das eigentliche Problem daran ist, dass die Elemente damit nicht mehr 
zuweisbar sind.

Ich würde es in der Tat so machen:

1

typedef struct {

2

  int a;

3

  int b;

4

} element_t;

5

6

typedef struct {

7

  element_t* const element;

8

  const size_t anzahl;

9

} config_t;

Damit

- bleiben Objekte vom Type element_t zuweisbar (das wird wohl in Deinem 
Fall sinnvoll sein),
- der Zieltyp (pointee) bleibt änderbar in config_t,
- der Zeiger selbst (pointer) wie auch die zugehörige Länge sind 
immutable,
- was dazu führt, dass die Invariante nicht nachträglich verletzt werden 
kann,
- der Datentyp für Anzahl ist korrekt (nicht-negativ und nicht zu 
klein).

A. S. schrieb:
> Die wichtigere Frage: wofür brauchst Du die Anzahl?

Meistens möchte man drüber iterieren.

> Und warum ist sie vorher nicht bekannt?

Doch, das ist sie ja.

> Am Ende ist es recht selten, wo man "nur" die Anzahl braucht. Oft
> braucht man noch weitere Infos im struct oder eine terminierte Liste ist
> ausreichend.

Natürlich kann er auch ein Sentinel verwenden, dazu müsste der TO 
verraten, ob es bei den Elementen des struct einen ungültigen Wert gibt, 
den man als Sentinel verwenden kann.

Udo K. schrieb:
> So geht es auch:
> Btw. Was sollen die "const" in element_t bewirken?
>
>

1

> // Im Header

2

> typedef struct {

3

>     int a;

4

>     int b;

5

> } element_t;

6

> 

7

> extern const element_t element[100];

8

> 

9

> // Test

10

> int main()

11

> {

12

>     printf("%d\n", sizeof(element)/sizeof(element_t));

13

> }

14

>

Nicht Dein Ernst jetzt, oder?
Lies doch erstmal hier den Thread, bevor Du die Diskussion noch vor den 
Anfang zurück spulst!

A. S. schrieb:
> Wilhelm M. schrieb:
>> Das eigentliche Problem daran ist, dass die Elemente damit nicht mehr
>> zuweisbar sind
>
> Bei der Definition sind sie bekannt. Das reicht, da können sie
> zugewiesen werden.

Das ist keine Zuweisung, sondern eine Initialisierung.
const-Objekte sind read-only und können nicht zugewiesen werden.

In c steht hinter dem Namen immer eine Adresse (Zeiger). Die maximale 
Größe hängt vom adressierbaren Speicherraum des Prozessors ab und 
dadurch letzten Endes vom Compiler.

Gerald K. schrieb:
> In c steht hinter dem Namen immer eine Adresse (Zeiger). Die maximale
> Größe hängt vom adressierbaren Speicherraum des Prozessors ab und
> dadurch letzten Endes vom Compiler.

Das ist falsch, wie ich oben schon geschrieben habe: array-Bezeichner 
sind (abstrakte) array-Bezeichner, Zeiger sind Zeiger, und beides 
erstmal unterschiedliche Konzepte. In vielen Kontexten zerfallen 
allerdings array-Bezeichner zu einem Zeiger auf das erste Element.

Ich programmiere C/++ seit 30 Jahren... und ich mag die Sprache da man 
sehr nah an der Hardware ist. Die (redundanten!) Header haben mich 
allerdings im Laufe der Zeit immer mehr gestört. Und schlimmer, wie hier 
im Thread (initializer lists), manchmal geben sie nicht mal die 
Möglichkeit her, die Definition mit der Deklaration vernünftig zu 
verheiraten.

Der mit C++20 eingeführte export ist mehr als überfällig.

Zurück zum Thema, hier noch eine (eher akademische) Alternative:

1

$ cat foo.h

2

typedef struct {

3

  int a;

4

  int b;

5

} element_t;

6

7

enum {

8

  nelements = 3 // macros are evil

9

};

10

11

extern element_t const (*elements) [nelements];

12

// pointer so the compiler can implicitly type check

13

14

$ cat foo.c

15

#include "foo.h"

16

17

static element_t const array[] = { {1,2}, {3,4}, {5,6} };

18

19

element_t const (*elements)[nelements] = &array;

20

21

$ cat main.c

22

#include "foo.h"

23

#include <stdio.h>

24

25

int main()

26

{

27

  for (int i=0; i<sizeof(*elements)/sizeof(**elements); ++i)

28

    printf("%d %d %d\n", i, (*elements)[i].a, (*elements)[i].b);

29

  return 0;

30

}

31

32

$ gcc -Wall -o main foo.c main.c

33

$ ./main

34

0 1 2

35

1 3 4

36

2 5 6

kein Problem und bereits gelöst schrieb:
> Dann musst du auch die dazugehörigen Funktionen anlegen, die dir neue
> Elemente von diesem Datentyp anlegen UND gleichzeitig den Counter
> (automatisch) inkrementieren. Dann ist man gleich bei Getter und Setter

Da es um statische Arrays geht, ist das Inkrementieren der Anzahl 
sinnlos (und deswegen hier nicht möglich).

kein Problem und bereits gelöst schrieb:
> C kennt die Arraygröße. Dort, wo Array angelegt wird, dort soll man auch
> seine Größe ermitteln.

Das tut er ja auch oben. Alles gut.

> Und dort, wo Array bekannt gemacht wird (per
> extern), dort wird auch seine Größe (Größenvariable) (per extern)
> bekannt gemacht. Fertig.

Nix fertig.
Es geht doch um Kontexte, wo die Definition nicht mehr sichtbar ist und 
der Bezeichner zu einem Zeiger zerfallen ist (Standardbeispiel: 
Parameterlisten).

fiju schrieb:
> Die Anzahl der Elemente in die Struc mit aufnehmen
>
>  typedef struct {
>     int Anzahl
>     int a;
>     int b;
>  } element_t;

So nach dem Motto, n-fach gemoppelt hält besser ;-)
Schwachsinn! Wie der Name schon sagt, ist element_t der DT eines 
Elementes(!), nicht des Containers!

Wullum Iri schrieb im Beitrag #7154305:
> Gehiern

... würde ich mal einschalten

Udo K. schrieb:
> So geht es auch:

Das ist der straight-forward Ansatz. Die Elemente in der initializer 
list abzählen und das Array entsprechend deklarieren.

Die implizite (böse) Redundanz ist aber ein Problem: Was wenn man sich 
verzählt hat oder wenn nachträglich die initializer list geändert wird?

Ist die initializer list größer, dann gibt der Compiler bescheid.
Ist die initializer list kleiner, werden implizt Null Elemente 
angehangen. Letzteres möchte man nicht unbedingt.

Beim meinem Ansatz erkennt der Compiler beide Probleme. (Eher 
akademisch, denn wer möchte schont mit einem Pointer auf ein Array 
arbeiten.)

Mikro 7. schrieb:
> Die implizite (böse) Redundanz ist aber ein Problem: Was wenn man sich
> verzählt hat oder wenn nachträglich die initializer list geändert wird?

Alleine die Tatsache, dass man überhaupt von Hand abzählen muss, stört 
schon. Wozu hat man den Computer?

Rolf M. schrieb:
> Alleine die Tatsache, dass man überhaupt von Hand abzählen muss, stört
> schon. Wozu hat man den Computer?

Eine der Schwächen von C/++. "export" in C++20 verspricht zumindest 
etwas Besserung.

Mikro 7. schrieb:
> Rolf M. schrieb:
>> Alleine die Tatsache, dass man überhaupt von Hand abzählen muss, stört
>> schon. Wozu hat man den Computer?
> Eine der Schwächen von C/++. "export" in C++20 verspricht zumindest
> etwas Besserung.
Soll es in C auch Module wie in C++ geben? Du meinst Module, wenn du 
"export" schreibst?

Für C++ macht das kaum einen Unterschied, da man jederzeit ein 
std::array benutzen könnte.

Mombert H. schrieb:
> Für C++ macht das kaum einen Unterschied, da man jederzeit ein
> std::array benutzen könnte.

Wie soll das mit std::array hier funktionieren?

Mikro 7. schrieb:
> Mombert H. schrieb:
>> Für C++ macht das kaum einen Unterschied, da man jederzeit ein
>> std::array benutzen könnte.
>
> Wie soll das mit std::array hier funktionieren?

Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im 
Header immer noch die Größe von Hand angeben.

Rolf M. schrieb:
> Mikro 7. schrieb:
>> Mombert H. schrieb:
>>> Für C++ macht das kaum einen Unterschied, da man jederzeit ein
>>> std::array benutzen könnte.
>>
>> Wie soll das mit std::array hier funktionieren?
>
> Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im
> Header immer noch die Größe von Hand angeben.

Nein. Die Größe ist Bestandteil des Typs in diesem Fall.

Wilhelm M. schrieb:
>> Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im
>> Header immer noch die Größe von Hand angeben.
>
> Nein.

Dann zeig mal, wie du ein std::array deklarierst, ohne die Größe 
anzugeben.

> Die Größe ist Bestandteil des Typs in diesem Fall.

Das ist sie bei einem C-Array auch. Bei beiden muss ich sie bei einer 
Deklaration explizit angeben, damit der Compiler weiß, wie groß es ist, 
und zwar gerade weil die Größe Teil des Typs ist.
Konkret: Ob ich schreibe

1

extern const element_t element[3];

oder

1

extern const std::array<element_t, 3> element;

macht in der Hinsicht keinen Unterschied. Bei beiden steht die 3 
explizit da. Also hilft mir std::array dabei nicht.

Rolf M. schrieb:
> Also hilft mir std::array dabei nicht.

Dann nimm std::vector. Der kann für dich zählen.

Oliver

Oliver S. schrieb:
> Rolf M. schrieb:
>> Also hilft mir std::array dabei nicht.
>
> Dann nimm std::vector. Der kann für dich zählen.

Dann aber natürlich komplett zur Laufzeit, mit dynamischer Allokation 
und allem, was da so dazu gehört.

Rolf M. schrieb:
> Wilhelm M. schrieb:
>>> Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im
>>> Header immer noch die Größe von Hand angeben.
>>
>> Nein.
>
> Dann zeig mal, wie du ein std::array deklarierst, ohne die Größe
> anzugeben.
>
>> Die Größe ist Bestandteil des Typs in diesem Fall.

> Also hilft mir std::array dabei nicht.

Mit CTAD kann die Größe und Elementtyp aus dem Initialisierer bestimmt 
werden. Und ein std::array zerfällt nicht.

Einer der schönen Eigenschaften von C/++ sind die ausführlichen 
Prüfungen zur compile time. Wo viele Sprachen auf einen runtime error 
laufen, bietet C++ Möglichkeiten, einige davon bereits im Voraus 
auszuschließen.

In diesem Sinn ist die Frage des TO interessant, weil C/++ hier 
(initializer lists) durch seine fehlende "export" Möglichkeit und den 
dadurch notwendigen verkappten Header declarations an seine Grenzen 
stößt. Die Größe des Arrays ist zwar bekannt, man kann sie aber nicht 
(zur compile time) exportieren.

Natürlich gibt es eine Menge Möglichkeiten damit in der Praxis 
umzugehen. Die Größe händisch abzulegen ist wohl die praktikabelste (so 
wie der TO es macht).

Rolf M. schrieb:
> Mikro 7. schrieb:
>> Mombert H. schrieb:
>>> Für C++ macht das kaum einen Unterschied, da man jederzeit ein
>>> std::array benutzen könnte.
>> Wie soll das mit std::array hier funktionieren?
> Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im
> Header immer noch die Größe von Hand angeben.

1

#include <array>

2

struct element_t {

3

  int a;

4

  int b;

5

};

6

std::array element{element_t{1,2}, element_t{3,4}, element_t{5,6}};

Wilhelm M. schrieb:
> Mit CTAD kann die Größe und Elementtyp aus dem Initialisierer bestimmt
> werden.

Auch das geht mit einem klassischen C-Array, wenn auch ganz ohne fancy 
Akronym. Allerdings sollte dir eigentlich auch aufgefallen sein, dass es 
hier um die extern-Deklaration im Header geht, die vom Initializer 
nichts weiß.

Mikro 7. schrieb:
> C/++
Was genau meinst du damit und warum schreibst du es so? Ich würde es 
ohne den umgebenden Text als "C ohne ++" lesen.

Mombert H. schrieb:
>> Das frage ich mich auch. Das Problem bleibt ja bestehen: Man muss im
>> Header immer noch die Größe von Hand angeben.
> #include <array>
> struct element_t {
>   int a;
>   int b;
> };
> std::array element{element_t{1,2}, element_t{3,4}, element_t{5,6}};

Und wo ist jetzt die dazugehörige extern-Deklaration im Header, die ja 
eigentlich das Thema der Diskussion ist?
Hier nochmal das Problem des TO:

Tim T. schrieb:
> header.h:

1

typedef struct {

2

 const int a;

3

 const int b;

4

} element_t;

5

extern const element_t element[]; // <- Es geht um diese Zeile

> source.c:

1

#include "header.h";

2

const element_t element[] = { {1,2}, {3,4}, {5,6} };

Rolf M. schrieb:
> Und wo ist jetzt die dazugehörige extern-Deklaration im Header, die ja
> eigentlich das Thema der Diskussion ist?
Dann schreib ein simples "constexpr inline" davor und pack die 
Definition in den Header.

Mombert H. schrieb:
> Rolf M. schrieb:
>> Und wo ist jetzt die dazugehörige extern-Deklaration im Header, die ja
>> eigentlich das Thema der Diskussion ist?
> Dann schreib ein simples "constexpr inline" davor und pack die
> Definition in den Header.

Und dann wird das Ding in 342 Quelldateien inkludiert und landet dann 
342 mal im finalen Binary? Ob das im Sinne des TO ist wage ich zu 
bezweifeln sonst hätte er das mit static const auch in C lösen können.

Μαtthias W. schrieb:
> Mombert H. schrieb:
>> Rolf M. schrieb:
>>> Und wo ist jetzt die dazugehörige extern-Deklaration im Header, die ja
>>> eigentlich das Thema der Diskussion ist?
>> Dann schreib ein simples "constexpr inline" davor und pack die
>> Definition in den Header.
> Und dann wird das Ding in 342 Quelldateien inkludiert und landet dann
> 342 mal im finalen Binary? Ob das im Sinne des TO ist wage ich zu
> bezweifeln sonst hätte er das mit static const auch in C lösen können.
Nein, es landet eben nicht 342 mal im Binary. Das hat damit zu tun, dass 
"constexpr inline" etwas anderes ist als "static const" ...

Rolf M. schrieb:
> Und wo ist jetzt die dazugehörige extern-Deklaration im Header, die ja
> eigentlich das Thema der Diskussion ist?

Die brauchen wir nicht mehr, wenn wir die kleinen Goodies von C++ 
verwenden.
Folgende Header-Datei:

1

#pragma once

2

3

#include <array>

4

5

struct Config {

6

    struct element_t {

7

  int a;

8

  int b;

9

    };

10

    inline static constexpr std::array elements = {element_t{1, 2}, element_t{3, 4}};    

11

};

Und dann in den Implementierungsdateien:

1

#include "bm12.h"

2

3

4

int foo() {    

5

    for(const auto& e : Config::elements) {        

6

    }

7

}

inline ist ein oft missverstandenes Schlüsselwort: es bedeutet, dass 
eine Verletzung der ODR durch den Linker "repariert" wird (einfach 
gesprochen).

DPA schrieb:
> Wilhelm M. schrieb:
>> Und ein std::array zerfällt nicht.
>
> Wann will man das denn effektiv? Einfaches Szenario, ich will das
> std::array an eine Funktion übergeben. Entweder die müssen immer gleich
> gross sein, und ich muss die Grösse wissen, oder ich muss ein Template
> nutzen, und habe dann vermutlich unnötigen Code. Oder ich übergebe halt
> doch was anderes, als ein std::array, irgend ein Iterator oder so...

Immer will man das. Es sei denn, der DT der Elemente ermöglichen ein 
Sentinel.
Ansonsten wäre man ja wieder bei dem C Scheiß.

Einige Anwendungsfälle erfordern ein Array einer vorgegebenen Größe (und 
ggf. Elementtyp), dann ist es auch ein Vorteil, weil es bei einem 
Mismatch zw. Argument- und Parametertyp nicht compiliert (im Gegensatz 
zu C).

Siehe auch Algorithmen: die Algorithmen sind üblicherweise templates und 
haben eine Schnittstelle mit

- Container,
- Iteratorpaar oder mehr,
- Range(s)

Und der angenommene Code-Bloat ist ein viel genanntes Pseudo-Argument, 
was durch die bessere Optimierung oft (mehr als) wett gemacht wird.

Wilhelm M. schrieb:
> Immer will man das. Es sei denn, der DT der Elemente ermöglichen ein
> Sentinel. Ansonsten wäre man ja wieder bei dem C Scheiß.

Wenn die Funktion std::arrays mit unterschiedlichen Größen verarbeiten 
können soll, bleibt mir wie DPA schon schreibt neben einem Template nur 
die Möglichkeit, sowas wie einen Iterator zu nehmen. Wenn ich das tue, 
bin ich aber tatsächlich da angelangt, wo C ist, denn das ist dann im 
Prinzip das gleiche wie der Zeiger auf den Anfang des Arrays. An die 
Größe komme ich wieder nicht heran, sofern sie nicht separat übergeben 
wird.

> Und der angenommene Code-Bloat ist ein viel genanntes Pseudo-Argument,
> was durch die bessere Optimierung oft (mehr als) wett gemacht wird.

Wo ich da eher Bloat sehe, ist beim Compilieren. Das dauert bei sehr 
template-lastigem Code gerne mal ewig, was die Entwicklung verlangsamt, 
weil ich ständig auf den Compiler warten muss. Dazu kommen die extrem 
gesprächigen und sehr viel schwieriger zu lesenden 
Compiler-Fehlermeldungen.
Templates sind ein cooles Feature, aber ich will nicht mein ganzes 
Programm als großes Template schreiben.

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Immer will man das. Es sei denn, der DT der Elemente ermöglichen ein
>> Sentinel. Ansonsten wäre man ja wieder bei dem C Scheiß.
>
> Wenn die Funktion std::arrays mit unterschiedlichen Größen verarbeiten
> können soll, bleibt mir wie DPA schon schreibt neben einem Template nur
> die Möglichkeit, sowas wie einen Iterator zu nehmen.

Auch dann wird die Funktion i.A. ein Template über den Elementtyp sein.

> Wenn ich das tue,
> bin ich aber tatsächlich da angelangt, wo C ist, denn das ist dann im
> Prinzip das gleiche wie der Zeiger auf den Anfang des Arrays.

Nein. Ein Zeiger ist zwar ein Iterator, aber nicht jeder Iterator ist 
ein Zeiger.

Der Aufrufer hat oft die Aufgabe, das halb-offene Intervall anzupassen.

Ansonsten unterstützen Iteratoren (nicht alle, je nach Typ) den op-(), 
und damit kann man die Elementanzahl ermitteln. Dies ist aber in den 
meisten Fällen nicht wichtig, wenn man Iteratoren nimmt, da die ja das 
Nutzintervall bestimmen.

Andernfalls nimmt man std::span<> o.ä. (std::stringview).

> An die
> Größe komme ich wieder nicht heran, sofern sie nicht separat übergeben
> wird.

Quatsch, s.o.

>> Und der angenommene Code-Bloat ist ein viel genanntes Pseudo-Argument,
>> was durch die bessere Optimierung oft (mehr als) wett gemacht wird.
>
> Wo ich da eher Bloat sehe, ist beim Compilieren. Das dauert bei sehr
> template-lastigem Code gerne mal ewig, was die Entwicklung verlangsamt,
> weil ich ständig auf den Compiler warten muss. Dazu kommen die extrem
> gesprächigen und sehr viel schwieriger zu lesenden
> Compiler-Fehlermeldungen.

Da hat sich (z.B. auch bei clang) extrem viel getan. Es ist seit einigen 
Jahren längst nicht mehr so wie anno-dazumals.

Und lieber Fehlermeldungen des Compilers lesen als langes 
Laufzeit-Debugging.

> Templates sind ein cooles Feature, aber ich will nicht mein ganzes
> Programm als großes Template schreiben.

Warum nicht?
Für die meisten µC Sachen mache ich das und es funktioniert absolut 
hervorragend.

Endlich ist die -1 Bewertung da, ich dachte schon, Du schläfst ;-)

Wilhelm M. schrieb:
> inline ist ein oft missverstandenes Schlüsselwort: es bedeutet, dass
> eine Verletzung der ODR durch den Linker "repariert" wird (einfach
> gesprochen).

Nette Idee static constexpr im class scope für ODR zu "missbrauchen". 
:-)

Das funktioniert aber auch ohne inline und ohne CTAD.

Statt

1

inline static constexpr std::array elements = {element_t{1, 2}, element_t{3, 4}};

funktioniert das folgende an gleicher Stelle genauso:

1

static constexpr element_t elements[] = { {1,2}, {3,4} };

Mikro 7. schrieb:
> Nette Idee static constexpr im class scope für ODR zu "missbrauchen".
> :-)

static constexpr ist implizit inline: sorry, Fehler von mir ;-)

Ich meinte C++11: Durch den "struct Config" scope wird ODR sicher 
gestellt und man kann quasi im Header initialisieren (im Source 
braucht es dann nur noch eine Dummy Definition).

In C++17 (inline) brauchst du den "struct Config" scope doch gar nicht, 
oder wofür soll der dort gut sein?