Hallo
Ich arbeite seit einer Weiler mit gnuarm und habe schon einige
Programme in C hinbekommen. Nun will ich meinen Uart Code für
einen ADUC7000 zusammenfassen. Ich dachte dabei an eine "Klasse".
Nun gibt es in standard-C keine Klassen, nur Strukturen. Mit Strukturen
scheint das ganze aber etwas umstädlich zu sein, da in der Struktur
keine
Funktion deklariert werden kann, zumindest scheint es bei mir so.
struct test {
int function1(int i);
};
Hier bleibt der Compiler hängen. Fehlermeldung: Es wurde eine Funktion
definiert.
Als nächstes habe ich mir überlegt, in der Struktur Pointer zu
definieren,
die auf die entsprechenden Funktionen zeigen. Das scheint aber sehr
umständlich zu sein.
Daher war meine Idee, auf C++ umzuschwenken, da dort Klassen definiert
sind.
Da C++ eine Obermenge von C ist, sollte der restliche C-Code laufen.
Mein Problem ist, dass ich keine ahnung habe, wo ich meine Makefile
anpassen
muss, damit der Code als C++ Code und nciht als C-Code interpretiert
wird.
Kann mir einer von euch dabei helfen?
anbei meine Makefile.
Vielen Dank,
Tilo
Du benutzt einfach einen der automatisch erkannten Dateinamenssuffixe
für C++:
file.cc
file.cp
file.cxx
file.cpp
file.CPP
file.c++
file.C
C++ source code which must be preprocessed. Note that in
.cxx, the last two letters must both be literally x.
Likewise, .C refers to a literal capital C.
Die Aussage:
> Da C++ eine Obermenge von C ist, ...
ist zwar nicht wirklich korrekt, aber kann eine brauchbare Näherung
sein.
> Nun gibt es in standard-C keine Klassen, nur Strukturen. Mit Strukturen> scheint das ganze aber etwas umstädlich zu sein, da in der Struktur> keine Funktion deklariert werden kann, zumindest scheint es bei mir so.
Kann man schon, aber halt nicht in C.
> Als nächstes habe ich mir überlegt, in der Struktur Pointer zu> definieren, die auf die entsprechenden Funktionen zeigen. Das scheint> aber sehr umständlich zu sein.
Es kostet natürlich auch Platz, da jedes Objekt pro Funktion einen
Zeiger enthält. Außerdem müssen diese initialisiert werden.
> Da C++ eine Obermenge von C ist, sollte der restliche C-Code laufen.
Das stimmt nicht so ganz. Es gibt durchaus Unterschiede, aber eine
Anpassung sollte je nach Code mit relativ wenig Aufwand möglich sein.
> Mein Problem ist, dass ich keine ahnung habe, wo ich meine Makefile> anpassen muss, damit der Code als C++ Code und nciht als C-Code> interpretiert wird.
So wie du CC und CFLAGS definiert hast, mußt du jetzt auch CXX und
CXXFLAGS definieren. CXX ist dann arm-elf-g++. Die .c-Dateien benennst
du um nach *.cpp oder eine andere übliche C++-Endung. Dann mußt du eine
Regel zur Übersetzung der Dateien definieren. Statt wie in deinem Fall
für jede Datei eine eigene Regel zu definieren, wäre es sowieso noch
sinnvoll, eine generische Regel zu verfassen, etwa so:
Vielen Dank für eure Tips. Ihr habt mir sehr weitergeholfen.
Ich habe meine main.c in main.cpp umbenannt und in der Makefile
die entsprechenden Änderungen gemacht.
Die Umstellung auf C++ scheint funktioniert zu haben.
Leider funktioniert dafür jetzt etwas anderes nicht mehr.
Ich habe meinen uart-Code in eine Header File gepackt:
uart.h und uart.c. Der Code ist in C geschrieben. Ich habe mich dabei
an http://de.wikibooks.org/wiki/C-Programmierung:_Eigene_Header
orientiert. Ich habe die uart.o als Object angegeben und sie wurde
in reinem C als uart.o erzeugt und genutzt.
Die Datei uart.o wird immer noch erzeugt. Leider kann die Funktion nicht
mehr genutzt werden:
#include uart.h
int main (void) {
IRQ = IRQ_Function; // Weise IRQ Funkion zu
InitUart(115200); // Starte Uart
}
#####
/Users/tilolutz/Documents/workspace/Uart_Demo/main.cpp:20: undefined
reference to `InitUart(int)'
Kann es sein, dass C und C++ Code nicht gemischt werden kann?
@Ralf: Das mit der Makefileänderung und g++ schau ich mir noch genauer
an.
arm-elf-gcc scheint den C++ Code jedenfalls zu erkennen:
arm-elf-gcc -I./ -c -fno-common -mcpu=arm7tdmi -O0 -g -std=gnu99
main.cpp
cc1plus: warning: command line option "-std=gnu99" is valid for C/ObjC
but not for C++
Bis dann, Tilo
Ich kenne den gcc nicht gut genug, um eine spezifische Aussage zu diesem
Compiler zu treffen. Im Allgemeinen erzeugen aber C++ Programme einen
größeren Overhead als vergleichbare C Programme. Das kann auf einem
kleinen Mikroconroller hinsichtlich des vorhandenen Programmspeichers
entscheidend sein.
Wenn Du bei C bleibst könntest Du ja wie folgt Deinen Code
strukturieren. Willst Du z.B. eine Klasse UART schreiben, schreibe keine
C++ Klasse UART, sondern erstelle die Datei UART.c die dann für die
Klasse steht, und erstelle in dieser Datei ganz normale C-Funktionen,
deren Namen für die Methoden dieser "Klasse" stehen. "Klassen interne"
Variablen werden in UART.c als globale Variblen und mit dem
Schlüsselwort "static" vereinbart, beschränkt das Zugriffsrecht auf Code
in dieser Datei.
So erhälst du einen sinnvoll strukturierten C-Code ohne größeren
Overhead. Als normales C-Programm stehen natürlich die
Zugriffbeschränkungen(public, private o. protected) nicht zur Verfügung.
Ableiten von Klassen ist natürlich auch nicht möglich, es ist dann eben
ein ganz normales C-Programm, dessen Quellcode lediglich nach dem
Vorbild von C++ strukturiert ist.
Tschau Sven!
Sven Woehlbier wrote:
> Ich kenne den gcc nicht gut genug, um eine spezifische Aussage zu diesem> Compiler zu treffen. Im Allgemeinen erzeugen aber C++ Programme einen> größeren Overhead als vergleichbare C Programme.
Im Allgemeinen sind allgemeine Aussagen Quatsch.
Man kann natürlich mit C++ mehr Overhead verursachen, aber man muss es
nicht. Es sollte klar sein, dass "late binding" Overhead kostet, aber
das würde es auch dann, wenn man ein vergleichbares Modell in C
zusammenbauen möchte. Es ist dort eben nur offensichtlicher.
>> Im Allgemeinen erzeugen aber C++ Programme einen>> größeren Overhead als vergleichbare C Programme.>> Im Allgemeinen sind allgemeine Aussagen Quatsch.
Full Ack.
> Man kann natürlich mit C++ mehr Overhead verursachen, aber man muss es> nicht.
Ich habe für den AVR durchaus auch schon C++-Code geschrieben, der
effizienter war als entsprechender C-Code. Wenn man weiß, was der
Compiler daraus macht, kann man durchaus C++-Features nutzen, ohne daß
es mehr kostet als reiner C-Code. Manche Features bringen zwar einen
Overhead, aber den müßte man bei entsprechender Umsetzung in C auch
zahlen. Nur muß man es in C eben umständlicher schreiben.
