#if innerhalb eins #defines

Ist ja mega umständlich! Deklariere alle Fonts einzeln als 
globale/statische Variablen. Dann machst du ein globales Array welches 
Pointer auf die gewünschten Fonts enthält. Das kann man auch simpel per 
Makros machen:

1

static const Font font1 { ... }, font2 { ... }, font3 { ... }, font4 { ... };

2

3

#define ENABLED_FONTS font1,font2,font3

4

const Font* fonts [] = { ENABLED_FONTS, NULL };

Dieses Array kannst du dann nach belieben iterieren.
Nicht verwendete Fonts werden vom Compiler schlicht wegoptimiert. 
Ansonsten schließe ich mich Sven an.

ein weiterer Ansatz ist die Auswahl an Parameter und Codeabschnitte 
(=Quelldateien) ausserhalb zu regeln.
Im Makefile kann vor dem Kompilieren in einem (Temporären) Verzeichnis 
das zusammenkopiert werden was für eine gewünschte Buildvariante 
benötigt ist.
Vor dem Kopilieren kann auch ein Stück Quellcode variantenspezifisch 
generiert werden, z.b. eine explizite #include-Liste.

Bei so organisierten Projekte tut man allerdings gut daran, buildlogs 
(oder extrakt davon) aufzubewahren, damit danach jederzeit die Binaries 
zugeordnet werden können (z.B. per SHA1/MD5 Prüfsumme oder eine andere 
"Signatur", welche natürlich beim builden mitgeloggt werden muss)

Malte _. schrieb:
> Also je nach dem welcher Font, und vor allem ob mehr als einer,
> verwendet wird, wird der Quellcode unterschiedlich zusammen gebaut.

Baue einfach nicht hinein, was du nicht brauchst oder nimm einen Chip 
mit genügend Platz im Flash.

Solche Definier-Orgien sind mir ein Graus und sie sind ein netter 
Ansatz, um sich selbst Probleme zu machen. Wer hindert dich eigentlich 
daran, dein Gdi projektspezifisch zu machen und dort nur das einzubauen, 
was du tatsächlich benötigst?

W.S.

Das ist nicht nur: "Aua!" sondern schon "Au weia!".

Sozusagen das programmatische Äquivalent zu Kurt Bindl und dem Stefan 
Hackebusch.

Kein Mensch, der noch alle Tüten in der Schüssel hat programmiert so. 
Und im professionellen Umfeld kriegst Du Berufsverbot.

OK. Schluss mit lustig.


Es mag mühsam sein, aber vielleicht schreibst Du hier mal Deine 
Anforderungen detailliert auf und wir überlegen zusammen, wie man das 
vernünftig machen kann.

Malte _. schrieb:
> [...]
>
> Hostenmatz schriebt:
>> Es mag mühsam sein, aber vielleicht schreibst Du hier mal Deine
>> Anforderungen detailliert
>
> Es geht um mein Projekt:
> Beitrag "Menu Designer für Grafik LCDs inklusive grafischem Editor"
> In dem möchte ich die derzeit separaten Dateien mit verschiedenen Fonts
> (und entsprechend doppelt zu watenden Code) vereinheitlichen (und habe
> UTF-8 Support eingebaut).
Das mag so sein. Aber ich lese mir jetzt nicht den Thread durch, um das 
heraus zu suchen, was Dir Probleme beim Design macht. Ich sehe zwar ein 
kleines How-To für Anfänger, aber keine "Entwicklungsdokumentation" in 
der die Funktionsweise im Gesamtzusammenhang und im Detail erklärt wird.

Fonts sind in der Regel einfach konstante Arrays. Und eines oder mehrere 
davon, wählt man per define aus. Alle anderen ignoriert der Compiler und 
das kostet minimal Zeit. Es mag ja sein, dass Dein System ein wenig mehr 
Möglichkeiten bietet und deswegen flexibler bei der Fontauswahl sein 
muss, evtl. auch zur Laufzeit, je nach Font, unterschiedlich arbeiten 
muss; aber das solltest Du mal wirklich ausführlich, mit Grafiken 
(Daten- und Kontrollfluss) beschreiben und klarlegen, was Du erreichen 
willst, so das ein "Entwickler" das nachvollziehen kann ohne sich erst 
durch den Code zu wühlen und das reverse-engineeren muss.

Malte _. schrieb:
> Die Idee mit dem Weak gefällt mir. Danke :)

Das ist ja furchtbar... Braucht man wirklich eine 
Compiler/Linker-spezifische unportable Anweisung, um ein derart simples 
Problem zu lösen? Da sind die ersten Vorschläge doch wesentlich 
sauberer.