[VC++] include van de klasse Blowfish mislukt

[Verwijderd]

Hey,

We hebben een zeer mysterieus probleem met de Microsoft Visual C++ compiler. Wanneer we de klasse BlowFish.cpp en BlowFish.h toevoegen aan ons project ("add files to project") krijgen we 72 foutmeldingen. Dit terwijl we bij het toevoegen van andere klassen dit probleem niet hebben. Nochtans volgen we exact dezelfde werkwijze. Merken we nog op dat wanneer we de klasse BlowFish op zich gebruiken er geen problemen ontstaan. De code vormt dus geen probleem denken we.

De desbetreffende bestanden:
http://users.skynet.be/pe/BlowFish.cpp
http://users.skynet.be/pe/Blowfish.h

Ligt het aan onze methode van toevoegen, zijn het de bestanden, zien we iets kleins over het hoofd? Het is een zeer raar probleem dat we ook na het raadplegen van de search en het internet niet hebben kunnen oplossen. Mocht iemand ons kunnen helpen zouden we die ZEER dankbaar zijn.

mvg,
twee gefrustreerde C++ gebruikers

[.oisyn]

Zou wel fijn zijn als je er bij zei welke foutmeldingen (en dan bedoel ik niet alle 72 )
Maar het compileert wel als je ze aan een leeg project toevoegd?

[Verwijderd]

Bij een niet grafisch VC++ project compileert het zonder fouten. Bij een grafisch daarentegen krijgen we 72 foutmeldingen die er niet zouden mogen zijn ("no class or namespace name"). Dit terwijl de klasse WEL herkend wordt want hij stelt bij aanmaak van een object de juiste functies voor.

[.oisyn]

Geef dan eens een aantal error meldingen met de bijbehorende regels code, we kunnen natuurlijk niet raden wat er mis is

[Verwijderd]

http://users.skynet.be/pe/errors.txt
http://users.skynet.be/pe/BlowFish.cpp

Wat zou het zijn denk je?

[henkleerssen]

zitten in die header file/ cpp file wat reserved names die je met grafische VC++ project ook hebt misschien? Misschien is het gewoon handiger om er gewoon anders een aparte dll van te compilen (niet grafisch project dus).. en deze te referencen.. misschien?

[henkleerssen]

btw je encryptie is niet meer zo waterdicht he.. als je de blowfish code post..

[Verwijderd]

Hehe, we zien niet direct gereserveerde namen. Een aparte .dll file compileren lijkt ons wat verregaand (we zijn noobjes). En ten slotte moet dit toch werken? Het lukt ons wel met registry.h en registry.cpp ...

[.oisyn]

Is de macro __BLOWFISH_H__ soms al gedefinieerd voor je blowfish.h include?

Tip: dat kun je controleren door net boven de #include dit te zetten:

C++:

#ifdef __BLOWFISH_H__
#error __BLOWFISH_H__ al gedefinieerd
#endif

[Verwijderd]

Of __BLOWFISH_H__ al ergens anders is gedefineerd, kun je volgens mij beter testen door iets als:

C++:

#ifdef __BLOWFISH_H__
 #ifndef __BLOWFISH_H__DEFINED_HERE__
  #error __BLOWFISH_H__ already defined somewhere else!!!
 #endif
#else
 #define __BLOWFISH_H__DEFINED_HERE__
#endif

Als je de file meerdere keren wordt geinclude, kan deze error anders ook verschijnen terwijl d'r niets aan de hand is.

Maar zdy, voeg je misschien per ongeluk "-D__BLOWFISH_H__" toe als commandline-argument voor de compiler?

offtopic:
En <cstring> gebruik je niet BTW, dus kun je die gewoon weglaten...

[ Voor 4% gewijzigd door Verwijderd op 15-04-2003 12:51 ]

[.oisyn]

Verwijderd schreef op 15 April 2003 @ 12:46:
Of __BLOWFISH_H__ al ergens anders is gedefineerd, kun je volgens mij beter testen door iets als:

C++:

#ifdef __BLOWFISH_H__
 #ifndef __BLOWFISH_H__DEFINED_HERE__
  #error __BLOWFISH_H__ already defined somewhere else!!!
 #endif
#else
 #define __BLOWFISH_H__DEFINED_HERE__
#endif

ik had het simpelweg als test voor de source file waarin je de header include, dus niet als test in de header file

Puur om te weten of __BLOWFISH_H__ al gedefinieerd is, een debug-check dus

[Verwijderd]

Sorry, was mij niet geheel duidelijk, maar idd, maar dan wel meteen voor de '#include "Blowfish.h"' anders zou die nog gedefineerd kunnen worden in de andere voorafgaande includefiles... En je zou ook nog "#pragma once" in de headerfile kunnen zetten als workaround, maar ik vond dit zo mooier

[.oisyn]

Nou ja #pragma once zorgt ervoor dat het maar 1 keer geinclude wordt (is bovendien niet portable ), maar dat is het probleem hier niet: op een een of andere manier wordt de inhoud van blowfish.h niet geparsed. En de enige mogelijkheid waardoor dat komt is dus volgens mij omdat __BLOWFISH_H__ gedefinieerd is al voordat de header voor het eerst geinclude wordt.

[Verwijderd]

Ik ga d'r ook vanuit dat deze __BLOWFISH_H__ all ergens gedefineerd is en als ik zo kijk naar de include-lijst lijkt het me onwaarschijnlijk dat deze gedefineerd wordt in <cstring> dan wel <exception>, en dus ga ik d'r vanuit dat het van de commandline vandaan moet komen...

offtopic:
.oisyn: Een "workaround" is nooit volledig porteerbaar, anders is het een bugfix Of "#pragma"'s wel of niet portable zijn, daar de menigen sterk over verdeelt. Ik vind ze idd niet porteerbaar, ondanks dat pragma's bedacht zijn om compilerspecifieke features te kunnen gebruiken in porteerbare code...

offtopic:
Zdy: Die "C" als prepend voor een class naam is trouwens niet echt nodig. Deze is - Voor zover ik weet - door microsoft ingevoerd voor MFC, om niet te conflicteren met bestaande classes en libraries, zodat CList bijvoorbeeld niet conflicteerde met een "List" e.d. Om die reden kon/kan het vaak meer kwaad dan goed om een "C" prepend te gebruiken voor eigen classes als je met MFC werkt.

[Verwijderd]

De fouten blijven bestaan . 't Moet toch gaan? We geraken wel in paniek, 't is voor het eindwerk en als we bij zulke zaken lang moeten blijven stilstaan halen we onze deadline niet . Verdomme toch, wat kan dat nu zijn allez .

[Verwijderd]

Maar zdy, voeg je misschien per ongeluk "-D__BLOWFISH_H__" toe als commandline-argument voor de compiler?

offtopic:
En <cstring> gebruik je niet BTW, dus kun je die gewoon weglaten...

Neen, we voegen dit niet toe. Toch bedankt.

[.oisyn]

Verwijderd schreef op 15 April 2003 @ 14:44:
.oisyn: Een "workaround" is nooit volledig porteerbaar, anders is het een bugfix

het is in dit geval geen workaround, het meerdere keren includen van een file is het probleem namelijk niet

Of "#pragma"'s wel of niet portable zijn, daar de menigen sterk over verdeelt. Ik vind ze idd niet porteerbaar, ondanks dat pragma's bedacht zijn om compilerspecifieke features te kunnen gebruiken in porteerbare code...

Een compiler geeft geen error bij #pragma directives die hij niet ondersteund. Als de werking van je programma echter afhangt van de werking van bepaalde #pragma directives is het dus gelijk niet portable, aangezien andere compilers ze doodleuk negeren

Zdy: Die "C" als prepend voor een class naam is trouwens niet echt nodig. Deze is - Voor zover ik weet - door microsoft ingevoerd voor MFC, om niet te conflicteren met bestaande classes en libraries, zodat CList bijvoorbeeld niet conflicteerde met een "List" e.d. Om die reden kon/kan het vaak meer kwaad dan goed om een "C" prepend te gebruiken voor eigen classes als je met MFC werkt.

De reden dat MS een C gebruikt is niet voor conflicten, maar gewoon hun manier van naamgeving. Net als dat ze parameters prefixen met een afkorting van het type (zoals dwRasterOp, bRepaint, etc.), en m_ als prefix gebruiken voor class member variabelen. Die C staat voor class, ze gebruiken ook de I voor interfaces.

Om diezelfde reden kan je dus prima een C als prefix gebruiken, als je je goed voelt bij die naamgeving. Als je echt name-clashes wilt vermijden moet je namespaces gebruiken, en niet andere namen verzinnen

Zdy: Kreeg je met mijn aanpassing nou de extra error "__BLOWFISH_H__ al gedefinieerd", of niet?

[ Voor 4% gewijzigd door .oisyn op 15-04-2003 14:58 ]

[Verwijderd]

Neen, het blijven die 72 errors ... mischien best in machinetaal beginnen

[ Voor 189% gewijzigd door Verwijderd op 15-04-2003 15:00 ]

[Verwijderd]

Uit de eerste foutmelding:

[plain]C:\_kaho\fghdfgh\BlowFish.cpp(19) : error C2653: 'CBlowFish' : is not a class or namespace name[/]

moet je concluderen dat de CBlowfish class declaratie in "Blowfish.h" niet is meegenomen. Omdat de compiler niet begint met een error dat ie de include-file niet kan vinden, moet dit dus een andere oorzaak hebben en de enige die ik kan verzinnen is dat __BLOWFISH_H__ al vantevoren is gedefineerd en dat de inhoud van de includefile daardoor wordt overgeslagen...

Maar je weet zeker dat er geen error bij is gekomen met de check van .oisyn dan wel die van mij?

[Verwijderd]

Er is zoals gezegd geen error bijgekomen, en is het niet raar dat hij de functies in de headerfile wel kent (want hij vult ze automatisch aan bij aanmaak object). Ik kan er totaal naast zitten ook natuurlijk.

[Verwijderd]

WTF? 'k heb niets veranderd en nu doet hij het precies wel, 'k houd jullie op de hoogte.

[.oisyn]

de intellisense doet de IDE zelf, en heeft niets te maken met de daadwerkelijke compilestap (MS' intellisense houdt bijvoorbeeld geen rekening met macro's, waardoor alle info geparsed wordt, ook al heb je een stuk code gedisabled door er een #if 0 ... #endif omheen te zetten)

[Verwijderd]

.oisyn schreef op 15 April 2003 @ 14:56:
het is in dit geval geen workaround, het meerdere keren includen van een file is het probleem namelijk niet

jij je zin, je hebt gelijk, etc, etc...

De reden dat MS een C gebruikt is niet voor conflicten, maar gewoon hun manier van naamgeving. Net als dat ze parameters prefixen met een afkorting van het type (zoals dwRasterOp, bRepaint, etc.), en m_ als prefix gebruiken voor class member variabelen. Die C staat voor class, ze gebruiken ook de I voor interfaces.

Ik meen anders toch echt ooit gelezen te hebben dat ze dit expliciet hadden gedaan naar aanleiding van een volledige overstap van library-classes...

Uiteraard kan je gewoon C prepends gebruiken, maar je code wordt er niet meer/minder proffessioneler op... Als je dat soort lettertjes in je naam wilt kunnen zien, kun je de C++ code ook naar C compileren Maar in principe is het totaal niet van belang of iets geimplementeerd is als een class, dan wel een struct, enum of een dword... Als het maar het gewenste gedrag defineert.

[Verwijderd]

Alle problemen zijn dus van de baan. Enigste wijziging die ik heb aangebracht is deze:

#ifdef __BLOWFISH_H__
#ifndef __BLOWFISH_H__DEFINED_HERE__
#error __BLOWFISH_H__ already defined somewhere else!!!
#endif
#else
#define __BLOWFISH_H__DEFINED_HERE__
#endif

Bedankt beiden voor jullie tijd en hulp, doe zo verder (met discussiëren ).

[ Voor 4% gewijzigd door Verwijderd op 15-04-2003 15:14 ]

[Verwijderd]

Verwijderd schreef op 15 April 2003 @ 15:13:
Alle problemen zijn dus van de baan. Enigste wijziging die ik heb aangebracht is deze:

#ifdef __BLOWFISH_H__
#ifndef __BLOWFISH_H__DEFINED_HERE__
#error __BLOWFISH_H__ already defined somewhere else!!!
#endif
#else
#define __BLOWFISH_H__DEFINED_HERE__
#endif

Bedankt beiden voor jullie tijd en hulp, doe zo verder (met discussiëren ).

Dit voegde niks toe aan de werking van de code zelf, misschien dat de IDE nu door had dat je headerfile opnieuw onder de loep moest worden genomen... Gebruik je misschien precompiled headers?

[Verwijderd]

Inderdaad, 'k vond het ook raar dat dit het oploste, maar een error die ik ervoor kreeg was in de trend van "looking for pre-compiled header directive".

[Verwijderd]

Als ik die wijzigingen nu ongedaan maak blijft het werken, zeer raar fenomeen toch wel.

[Verwijderd]

#include "stdafx.h" was de boosdoener , indien we die vanboven zetten geen probleem, zetten we die onder andere includes 72 errors, de logica ontgaat me hier ... maar soit bedankt.

[.oisyn]

Precompiled headers moet je ook niet gebruiken als je er niet mee om weet te gaan (dit bedoel ik niet vervelend, het is meer een kwestie van ervaring ), moet je dus effe uitzetten in de project options

[.oisyn]

Verwijderd schreef op 15 april 2003 @ 15:10:
Uiteraard kan je gewoon C prepends gebruiken, maar je code wordt er niet meer/minder proffessioneler op... Als je dat soort lettertjes in je naam wilt kunnen zien, kun je de C++ code ook naar C compileren Maar in principe is het totaal niet van belang of iets geimplementeerd is als een class, dan wel een struct, enum of een dword... Als het maar het gewenste gedrag defineert.

Ik neem aan dat je weleens gehoord hebt van hungarian notation? Er zijn veel mensen die het gebruiken. Ikzelf vind het ook erg lelijk, maar het is gewoon een kwestie van voorkeur. De C voor je klassenaam past ook in dat verhaal. Het kan zeker wel handig zijn om het verschil te zien tussen een klasse (een type beginnend met een C) en een interface (beginnend met een I). Een type met een I kun je namelijk niet instantieren, om maar even een voorbeeld te noemen

Dat van compileren naar C-code snap ik niet helemaal.

[Olaf van der Spek]

henkleerssen schreef op 15 April 2003 @ 11:36:
btw je encryptie is niet meer zo waterdicht he.. als je de blowfish code post..

Tuurlijk wel. De encryptie is waarschijnlijk zelfs sterker als de code public is, omdat het algorithme door meer mensen bekeken en gecontroleerd is.

"Obscurity is no security"

.oisyn schreef op 15 April 2003 @ 16:30:
Dat van compileren naar C-code snap ik niet helemaal.

Misschien dat hij het over mangled C++ names heeft?

[ Voor 23% gewijzigd door Olaf van der Spek op 15-04-2003 16:55 ]

[MSalters]

Overigens zijn namen met __ erin (twee underscores naast elkaar) gereserveerd voor de compiler, en je hebt dat 2 keer in je header guard.
Ook _[A-Z] is gereserveerd, en _[a-z] in sommige contexten. HEADER_H_INCLUDED is een perfecte macro voor dit soort dingen; "iedereen" weet dat dat een header guard macronaam is.