static const und extern "C"
-
Hallo,
ich habe das Problem, dass ich in einem C++-Projekt einen extern "C" Header habe, der Prototypen von Funktionen hat und Arrays, die von extern "C"-Funktionen aufgerufen werden:
Map.h
#ifndef _MAP_H_ #define _MAP_H_ #ifdef __cplusplus extern "C" { #endif #define MELD_IN_NUM 18 #define MELD_OUT_NUM 144 #define PICT_IN_NUM 6 #define PICT_OUT_NUM 48 extern uint8 meld[MELD_IN_NUM]; [...] void mapxyz(); #ifdef __cplusplus } #endif #endif // _MAP_H_Die Funktion mapxyz() wird von einer "extern "C""-Funktion aufgerufen, das ganze kompiliert aber mit einem C++-Compiler. Kann ich dann trotzdem statt #define MELD_IN_NUM 18 ein static const MELD_IN_NUM = 18 schreiben, wohlwissend dass das unter C keine echte Konstante ist und deswegen nicht für Array-Größen verwendet werden kann, oder wird alles im C++-Kontext kompiliert und nur das Name-Mangling für die Funktion(en) verhindert?
Danke f. alle Hinweise
-
Warum willst du denn einen C++-kompatiblen C-Header so abändern, dass er von C-Compilern nicht mehr verstanden wird?
extern "C" bezieht sich nur auf die Bindung und dem, was dazugehört. Es veranlasst keinen C++ Compiler, sich wie ein C Compiler zu verhalten.
-
Weil ich die Konstanten bzw. Array-Größen auch noch in anderen (C++-)Modulen brauche und da lieber static consts hätte statt #define's?
Es gibt eben Inkonsistenzen, wenn ich an einer Stelle #define's habe und an anderer Stelle (im C++-Kontext noch dazu in einem Namespace) static const Konstanten...
-
const funktioniert doch auch in C!?
-
dot schrieb:
const funktioniert doch auch in C!?
Aber nicht als konstanter Ausdruck für die Arraydimension.
-
Stimmt, da war doch was (ich verwend einfach viel zu selten C). In dem Fall könntest du ein #ifdef __cplusplus machen, um die Dinger jeweils als const oder als #define zu definieren, oder den enum Hack verwenden...
-
Tachyon schrieb:
Aber nicht als konstanter Ausdruck für die Arraydimension.
Muss die Arraydimension in C überhaupt konstant sein? Ich dachte dort gibt es VLA.
-
VLA ist ein C99 Feature und funktioniert nur für lokale Arrays in Funktionen. Und wieso ein VLA machen, wenn die Größe doch konstant ist?
-
Reduzieren wir das Problem auf das Minimum.
AlGaN schrieb:
extern uint8 meld[MELD_IN_NUM];Was spricht gegen?
extern uint8* meld;
-
nurf schrieb:
Reduzieren wir das Problem auf das Minimum.
AlGaN schrieb:
extern uint8 meld[MELD_IN_NUM];Was spricht gegen?
extern uint8* meld;Was spricht gegen
extern uint8 meld[];
-
nurf schrieb:
Was spricht gegen?
extern uint8* meld;Dass es etwas völlig anderes ist und wohl kaum das Problem löst?
-
AlGaN schrieb:
Kann ich dann trotzdem statt #define MELD_IN_NUM 18 ein static const MELD_IN_NUM = 18 schreiben, wohlwissend dass das unter C keine echte Konstante ist und deswegen nicht für Array-Größen verwendet werden kann, oder wird alles im C++-Kontext kompiliert und nur das Name-Mangling für die Funktion(en) verhindert?
Na ich denke schon dass du das kannst. Probiers halt aus.
Ich denke aber auch dass du die #defines auch einfach #defines bleiben lassen kannst, das Hinzufügen eines geeigneten Prefix zum Namen sollte vollkommen ausreichend sein - bzw. vielleicht noch die Namen etwas verständlicher machen, würde auch nicht schaden.
Ich persönlich verwende einfach immer den Projektnamen als Prefix. Bzw. den Namespacenamen (was bei mir das selbe ist).Also statt
namespace Foosel { static const short Blah = 123; }einfach
#define FOOSEL_BLAH ((short) 123)
-
AlGaN schrieb:
Es gibt eben Inkonsistenzen, wenn ich an einer Stelle #define's habe und an anderer Stelle (im C++-Kontext noch dazu in einem Namespace) static const Konstanten...
Das eine ist halt C, das andere C++. Wie ich schon hab durchscheinen lassen, finde ich deine Idee nicht so toll wie du selbt. Ich würd's einfach so lassen.
