Hab ein VC++ 6.0 hier.
Hab dein Beispiel aufgesetzt und compiliert.
Keine Fehlermeldung.
Kannst du bitte ein vollständiges, kompilierbares Beispiel
zusammenstellen und vor dem Posten testen ob es die von dir
beobachtete Fehlermeldung hervorbringt.
#include <header.h>
<> solltest du ausschliesslich für System-header Files
reservieren. Für eigene Headerfiles wird " benutzt.
#include "header.h"
Der Unterschied zwischen <> und "" sind rein die Aufsuchpfade
mit denen der Compiler das Header File sucht. Vielleicht liegt
es ja daran, dass du ein Header File einbindest, dass zufällig
genauso heist wie dein eigenes.
Hallo Karl, ich habe der Umgebung den Pfad in den Optionen gesetzt. Der
Header heißt selbstverständlich nicht header.h, er hat einen sehr
eindeutigen Namen.
Ich habe es genauso wie beschrieben auch mit dem Keil gemacht, keine
Fehlermeldung wie bei dir. Aber VS6 eiert rum. MSDN kann man vergessen,
kein zutreffender Eintrag.
Im Anhang mal das was bei mir nicht läuft neu zusammengestellt.
Danke für die Mühe.
RAR ist ganz schlecht.
Kann ich auf der Maschine auf der ich bin nicht öffnen.
Kann auch nichts nachinstallieren, da ich keine Admin Rechte habe.
Einen Entzipper hab ich allerdings.
Da sind sie, die beiden Sourcefiles als ZIP-Archiv.
Das Problem liegt darin, daß die Art der Strukturinitialisierung in C++
unzulässig ist. Benennt man das *.cpp-Sourcefile (das übrigens kein
einziges C++-Element enthält) um in *.c, dann lässt sich die Chose
anstandslos übersetzen.
Sowas dachte ich mir. Das Problem: In meiner Headerdatei sind Elemente
aus C++ (Bibliotheksdefinitionen). Bevor ich jetzt alles auseinander
stricke: Gibt es eine Möglichkeit das zu umgehen? Was genau ist
unzulässig? Ich bin nicht (mehr) besonders bewandert in C++.
Wobei das interessante darin besteht, dass dieser Fehler
erst dann auftritt, wenn der 3-te Pointer in die Struktur
hineinkommt. Bei nur 2 Pointern in der Struktur ist das
kein Problem.
Ich denke mal, dass ist ein Compilerfehler. Auf Anhieb wuesste
ich nicht, warum das laut C++ Standard illegal sein sollte.
> Gibt es eine Möglichkeit das zu umgehen?
Grade im VC++ ausprobiert.
Du kannst der Struktur einen Konstruktor verpassen und dort
eine Initializer List angeben.
1
typedefstructlcd_font_
2
{
3
constunsignedintglyph_width;/* glyph width in pixels */
4
/* 0 for variable width fonts */
5
constunsignedintglyph_height;/* glyph height for storage */
6
constunsignedchar*glyph_table;/* font table start address in memory */
7
constunsignedchar*mapping_table;/* used to find the index of a glyph */
constunsignedint*offset_table;/* ks the offsets of the first byte */
11
/* of each glyph */
12
lcd_font_(unsignedinta,unsignedintb,
13
constunsignedchar*c,constunsignedchar*d,
14
constunsignedchar*e,constunsignedint*f)
15
:glyph_width(a),
16
glyph_height(b),
17
glyph_table(c),
18
mapping_table(d),
19
width_table(e),
20
offset_table(f)
21
{
22
}
23
24
}LCD_FONT;
Die Initialisierung in main verändert sich dann ein bischen:
1
LCD_FONTCourier_New__8(
2
3
0,// glyph_width
4
13,// glyph_height
5
Courier_New__8_char_table,// ptr to glyph_table
6
Courier_New__8_mapping_table,// ptr to mapping_table
7
Courier_New__8_width_table,
8
Courier_New__8_offset_table
9
);
Wenn der Konstruktor kein Problem darstellt (keine Kompatibilität
zu C) dann wäre das eine Lösung. Schlimmstenfalls müsste man den
Konstruktor noch mit einem Makro kapseln, so dass er nur bei C++
aktiv wird.
Jetzt wüsste ich nur noch zu gerne, warum dein Code im
Eröffnungsposting ohne Probleme compilierte :-)
Karl heinz Buchegger wrote:
> Wobei das interessante darin besteht, dass dieser Fehler> erst dann auftritt, wenn der 3-te Pointer in die Struktur> hineinkommt. Bei nur 2 Pointern in der Struktur ist das> kein Problem.
Das nehme ich zurück.
Obwohl. Ich hatte mit einer Teststruktur den Fall, dass es sich
genauso verhalten hat.
Jetzt hab ich mal probehalber folgendes gemacht:
1
typedefstructvec_
2
{
3
unsignedinta;
4
unsignedintb;
5
}vec;
6
7
structvec_xy={0,5};
compiliert.
Umgeändert auf (const eingefügt )
1
typedefstructvec_
2
{
3
constunsignedinta;
4
constunsignedintb;
5
}vec;
6
7
structvec_xy={0,5};
compiliert nicht.
Geändert auf
1
typedefstructvec_
2
{
3
unsignedinta;
4
unsignedintb;
5
constunsignedchar*glyph_table;
6
}vec;
7
8
structvec_xy={0,5,Courier_New__8_char_table};
compiliert
Dürfte also was mit dem const bei den unsigned int zu tun haben.
Ein Test:
1
typedefstruct
2
{
3
unsignedintglyph_width;/* glyph width in pixels */
4
/* 0 for variable width fonts */
5
unsignedintglyph_height;/* glyph height for storage */
6
constunsignedchar*glyph_table;/* font table start address in memory */
7
constunsignedchar*mapping_table;/* used to find the index of a glyph */
Dass die Anfrage im GCC-Forum gepostet wurde, nahm ich zum Anlass, den
Inhalt von fehler.zip dem GCC zum Fraß vorzuwerfen:
g++ -pedantic -Wall -Wextra -c courier_new__8_R0_L0_T0_B1.cpp
Bis auf die Warnung vor dem fehlenden Newline am Dateiende meckert der
Compiler nichts, trotz der auf Maximum eingestellten Penibilität. Also
hat einer der beiden Compiler eine Macke. Ich tippe mal auf den VC ;-)
yalu wrote:
> Dass die Anfrage im GCC-Forum gepostet wurde, nahm ich zum Anlass, den> Inhalt von fehler.zip dem GCC zum Fraß vorzuwerfen:>> g++ -pedantic -Wall -Wextra -c courier_new__8_R0_L0_T0_B1.cpp>> Bis auf die Warnung vor dem fehlenden Newline am Dateiende meckert der> Compiler nichts, trotz der auf Maximum eingestellten Penibilität. Also> hat einer der beiden Compiler eine Macke. Ich tippe mal auf den VC ;-)
:-)
Oh. Das ist nichts neues. VC 6.0 hat so einige Macken.
Hat allerdings auch schon einige Jährchen auf dem Buckel.
Der wurde 1998 auf die Menschheit losgelassen.
Im Gegensatz zu "const unsigned int" bezieht sich das "const" bei "const
unsigned char*" auf das, worauf der Zeiger zeigt. Die Variable
glyph_table kann also veraendert werden, nur *glyph_table nicht. Bei
"unsigned int a;" kann aber tatsaechlich die Variable a nicht veraendert
werden.
Deswegen schaetze ich, dass einige C-Tricksereien nicht mehr
funktionieren, weil das eben kein gewoehnlicher C-POD-Typ mehr ist
(sieht man zum Beispiel daran, dass Zuweisung nicht mehr funktioniert).
Ich wuerde wahrscheinlich einfach ganz zu C++ wechseln und nicht
versuchen C/C++ gemischt zu schreiben. Also auch nicht "typedef struct {
/* ... */ } vec;" nehmen sondern eben direkt "struct vec { ... };". Fuer
das typedef gibt es in C++ keinen Grund meh. Oder vielleicht noch
besser, da das Objekt ja offenbar doch ein paar Methoden braucht, gleich
"class vec { ... };" schreiben.
Erstmal vielen Dank, eure Hilfestellungen sind super!
Aber zu früh gefreut, im Anhang mal das Ganze erweitert um den
scheinbaren Verursacher der Probleme. Ich habe ein wenig rumgespielt und
komme nicht um folgende Fehler herum:
1
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
2
error C2501: 'USBDevice' : Fehlende Speicherklasse oder Typbezeichner
Ich habe keine Ahnung in welche Richtung das läuft...
Die Variante mit dem Konstruktor habe ich versucht, leider ohne Erfolg.
Ich möchte das Ganze nicht umstellen auf C++ weil meine Kenntnisse
mittlerweile schlecht sind und das auch zu viel Arbeit nach sich ziehen
würde weil GLCD die Fonts als struct ausspuckt - es soll leicht
handhabbar bleiben.
yalu wrote:
> Da fehlt wohl einfach nur die Deklaration von CCyUSBDevice ;-)
?
Der Wald, die Bäume, ich.
> Vielleicht erst CyAPI.h und dann zUSB_API.h includen. Dann müssten> zumindest die angegeben Fehler weg sein.
Tatsächlich. Nur kommen dann weitere 102 Fehler die sich allesamt auf
die CyAPI.h beziehen.
T. H. wrote:
> Tatsächlich. Nur kommen dann weitere 102 Fehler die sich allesamt auf> die CyAPI.h beziehen.
Lass dich von der Menge nicht verunsichern. Die hat meist
wenig zu sagen. Die meisten werden wohl Folgefehler sein.
Bearbeite den ersten und finde raus, was da schief läuft.
Wenn du ihn behoben hast, fallen dann auch gleich wieder
30 oder 40 Fehler weg.
Also: Immer eins nach dem anderen und nicht verzweifeln.
> Also auch nicht "typedef struct {> /* ... */ } vec;" nehmen sondern eben direkt "struct vec { ... };".> Fuer das typedef gibt es in C++ keinen Grund meh.
Full ack.
> Oder vielleicht noch besser, da das Objekt ja offenbar> doch ein paar Methoden braucht, gleich "class vec { ... };" schreiben.
Das wissen viele nicht, daher mische ich mich hier mal ein.
Der einzige Unterschied zwischen einer struct und einer class in C++
ist es, dass bei einer struct alle Member per default public sind
und bei einer class sind sie private. Selbiges für Ableitungen.
Struct wird per default public abgeleitet, class wird private.
Ansonsten sind struct und class völlig gleichwertig. Auch eine
struct kann Memberfunktionen beinhalten. Auch eine struct kann
Konstruktor/Destruktor haben. Auch eine struct kann virtuelle
Funktionen haben, etc.
Moin!
> Lass dich von der Menge nicht verunsichern.
Keine Sorge Karl, das bestimmt nicht. Ich hatte gestern Abend aber
einfach kein Bock mehr. Ursache: Ich habe versäumt einen Header
einzubinden. Jetzt läuft es (ohne const). Nun fehlt bloß noch ein Guru
der erklärt, warum es mit const nicht ging. Zudem man das hier mal
probieren sollte:
1
typedefconststruct
2
{
3
unsignedintinge;
4
unsignedintwalburg;
5
constunsignedint*ingeborg;
6
}STRUKTUR;
Das funktioniert anstandslos. Ist es VC6 (Bug) oder ist es C++ allgemein
(Inkonsistenz)? Oder DAU?
>> Das funktioniert anstandslos. Ist es VC6 (Bug) oder ist es C++ allgemein> (Inkonsistenz)? Oder DAU?
Im Moment tendiere ich zu einem Bug.
Ich hab den C++ Standard nicht hier, kann da erst am Wochenende
reinschauen. Wenn ich Zeit habe, mach ich mich mal über Aggregate
schlau. In meiner Erinnerung ist das etwas schwammig. Auf
Anhieb komme ich aber nicht drauf, wie ein const die Definition
eines Aggregates verändern könnte. Und das mit der Initialisierung
ist ja wohl ein Witz. Gerade weil da const im Spiel ist, muss
initialisiert werden.
T. H. wrote:
> Wäre interessant! Worauf ich eigentlich hinaus wollte:>>>
1
typedefconststruct
2
>{
3
>constunsignedintinge;
4
>constunsignedintwalburg;
5
>constunsignedint*ingeborg;
6
>}STRUKTUR;
>> Funktioniert nämlich nicht.
Das macht aber auch nicht wirklich viel Sinn.
Ob die ganze Struktur const sein soll oder nicht
legt man sinnigerweise erst bei der Definition der
Variablen fest.
Aber in diesem Fall dürfte er nicht stottern. Die Struktur ist konstant,
also auch die Elemente. Dennoch stört er sich am const der Integer. Über
Sinn oder Unsinn dieser Konstruktion sei nur soviel gesagt: In meinem
Fall macht typdef const struct durchaus Sinn, ich weiss es von Anfang
an, dass es eine konstante (unabänderbare) Struktur sein sollte und
nur eine Hilfskonstruktion ist.