Hallo zusammen,
ich habe einen Haufen Header-Dateien, die Lookuptables enthalten, und
deren Name identisch mit der darin definierten Variable ist. Ich will
nur eine davon einbinden und auch einer Variablen zuweisen.
Sprich sie werden so genutzt:
1
//#include "abcdefg123.h"
2
//char *bitmap = &abcdefg123;
3
#include"abdefg123.h"
4
char*bitmap=&abdefg123;
5
//#include "abcdef123.h"
6
//char *bitmap = &abcdef123;
7
//#include "abcdefg124.h"
8
//char *bitmap = &abcdefg124;
9
...
Lieber wäre es, wenn ich mit Präprozessormagie nur eine Konstante
anpassen müßte. Ungefähr so:
1
#define BITMAPFILE(NAME) "NAME ## .h"
2
#define BITMAP abdefg123
3
4
#include BITMAPFILE(BITMAP)
5
char*bitmap=&BITMAP;
Anscheinend scheint der Präprozessor das Include nur vor der
Zeichenkettenoperation auszuführen.
Gibt es einen Trick, wie ich Variable + Header-Datei dennoch nur an
einer Stelle einstellen kann?
Viele Grüße
W.T.
Walter T. schrieb:> Gibt es einen Trick, wie ich Variable + Header-Datei dennoch nur an> einer Stelle einstellen kann?
Das macht man normalerweise über #ifdefs, und Du kannst beim
Compiler-Aufruf mit -DMY_STUFF oder -DMY_SWITCH=0/1/2/usw. das Richtige
einblenden.
Nop schrieb:> Das macht man normalerweise über #ifdefs
Naja, #ifdefs würden dazu führen, dass ich neue neue Header-Datei
anstelle an zwei Stellen nur noch an drei Stellen einpflegen müsste...
Eine #include-Direktive mit variablem Argument ist m.W. nicht möglich.
Du kannst das Include-File aber statt mit #include mit der Compiler-
Option -include einbinden und im Makefile, der Shell oder von wo immer
der Compiler aufgerufen wird, den Dateinamen variabel machen.
Edit:
Doch, #include ist natürlich auch mit einem Macro als Argument möglich.
Ich habe da etwas durcheinander geschmissen.
Walter T. schrieb:> Naja, #ifdefs würden dazu führen, dass ich neue neue Header-Datei> anstelle an zwei Stellen nur noch an drei Stellen einpflegen müsste...
Nicht, wenn Du eine zentrale variable Headerdatei machst, in der per
ifdef die Einblendungen gemacht werden, und Du diese zentrale
Headerdatei dann ansonsten ohne ifdef inkludierst.
Die Datei heißt immer gleich befindet sich aber in unterschiedlichen
Verzeichnissen. Über den compiler inklude Pfad („-I..“wird dann die
richtige geladen.
Meiner Ansicht nach wäre es am saubersten diese Lookup Tabelle innerhalb
deines Build Prozesses zu generieren. Sie kommt dann in das Verzeichnis
wo auch die generierten obj Dateien landen. Und zwar nur genau die eine,
die für dein aktuelles Build die richtige ist.
Walter T. schrieb:> #define BITMAPFILE(NAME) "NAME ## .h"
hab jetzt keinen Compiler hier, aber funktioniert das nur in " " nicht
(in < > dagegen schon? Wäre es so richtigt?
Johann L. schrieb:> Beispiel:
Danke! Das war genau das, was ich gesucht habe.
Wilhelm M. schrieb:> Warum solche Klimmzüge: mit constexpr-Funktionen kannst Du doch die> Lookup-Tabellen elegant im C++-Code selbst berechnen.
Momentan erzeuge ich die Bitmap-Tabellen immer extern in Matlab. Im
Build-Prozeß wäre natürlich super - allerdings kann ich mir das gerade
nicht vorstellen, ohne dass der Build-Prozess auf externe Werkzeuge wie
z.B. ImageMagick zugreift. Kannst Du das mal als Beispiel zeigen? Ich
habe mal ein Roh-Bitmap angehängt.
Walter T. schrieb:> Wilhelm M. schrieb:>> Warum solche Klimmzüge: mit constexpr-Funktionen kannst Du doch die>> Lookup-Tabellen elegant im C++-Code selbst berechnen.>> Momentan erzeuge ich die Bitmap-Tabellen immer extern in Matlab. Im> Build-Prozeß wäre natürlich super - allerdings kann ich mir das gerade> nicht vorstellen, ohne dass der Build-Prozess auf externe Werkzeuge wie> z.B. ImageMagick zugreift. Kannst Du das mal als Beispiel zeigen? Ich> habe mal ein Roh-Bitmap angehängt.
Ich hatte oben nur etwas von Lookup-Tabelle gelesen und damit nicht das
Zeichen von Bildern assoziiert.
Geht aber um das Umwandeln (nicht das Erzeugen) von BitMap-Daten, so
kann man es schon so machen.
Bei den Bildern oder sagen wir besser Icons habe ich es so gelöst, dass
ich die selbstverständlich mit einem Grafikprogramm erzeuge und dann als
XBM (Header) speichere. Die XBM-Datei wird dann so inkludiert, wie sie
ist. Das XBM-Format (es repräsentiert ja die Daten in einem
char-C-Array) ist oft nicht das, was man als BitMap gebrauchen kann, und
das kann man dann per constexpr-Funktion in das Zielformat umwandlen.
Natürlich kann man Grafiken auch algorithmisch erzeugen, aber ich
bezweifle, dass es irgendeine Grafik-Bibliothek gibt, die aus
constexpr-Funktionen besteht bzw. dass es das ist, was Du machen
möchtest.
Walter T. schrieb:> Johann L. schrieb:>> Beispiel:>> Danke! Das war genau das, was ich gesucht habe.>
Das ist zwar "bewundernswert smarte Präprozessor-Magie", aber doch ein
Krampf, wenn man's pflegen und sich immer wieder neu eindenken muss.
Für die constexpr-Logik gilt nach meinem Geschmack Ähnliches.
M.E. gehört solcherlei Preprocessing ins Makefile und sonst nirgendwo
hin. Dort würde zumindest ich danach suchen.
ich mache das mit texten so ...
in dem textfile ist dann nur formatiert der inhalt des arrays
1
{
2
"text"
3
}
im code dann
1
constchar*sprache[]={
2
#include"textfile.txt"
3
}
das klappt auch mit anderen sachen. nur muss die zu includierende datei
entsprechend formatiert sein.
oder du machst ein binary draus und verknüpfst das über den linker
Eine eigene Frage?
Dieser Thread ist über 8 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
