ich bin heute morgen über ein "interessantes" Verhalten gestolpert, das Ihr mir hoffentlich erklären könnt:

Ich habe eine kleine library, die mir die Kommunikation mit einem Server ermöglicht und Funktionen am Server aufruft. Damit ich gegebenenfalls neue Funktionen implementieren kann, compiliere ich alles selber (ist überschaubar wenig). Anscheinend unterstütz die
library verschiedene Funktionsmodi, die ich mit #defines einstellen kann:

#ifdef NON_MATLAB_PARSING /* when compiling, make sure NON_MATLAB_PARSING is always defined! */
        ....
#else 
	....
#endif /* else NON_MATLAB_PARSING */

Also habe ich kurzerhand NON_MATLAB_PARSING in meiner main.cpp zum Testen definiert:

#define NON_MATLAB_PARSING
#include "HeaderDerLib.h"
...

..und bekam eine ganze Menge Syntaxfehler.

Wenn ich nun folgendes im Header mache:

#define NON_MATLAB_PARSING
#ifdef NON_MATLAB_PARSING /* when compiling, make sure NON_MATLAB_PARSING is always defined! */
        ....
#else 
	....
#endif /* else NON_MATLAB_PARSING */

geht alles ohne Probleme!

Haben #defines einen bestimmten Geltungsbereich oder so? Ich habe schon das Projekt durchsucht und NON_MATLAB_PARSING wird weder undefiniert, noch irgendetwas damit gemacht. Es wird auch nur in dieser einen Header-Datei benutzt. Die Reihenfolge sollte ja stimmen oder kann es sein, dass die #include Direktive VOR der #define Direktive abgearbeitet wird ?

Gruß

Pille456

P.S: Habs mit VS 2010 getestet.

Und das beisst sich.

Ist aber ins blaue hinein geraten.

Spontan würde ich sagen: du inkludierst die Datei einmal mit definiertem NON_MATLAB_PARSING und einmal ohne.

Und das beisst sich.

Ist aber ins blaue hinein geraten.

Dann würde die Reihenfolge in irgendeiner Art und Weise eine Rolle spielen, denn ich rufe #define NON_MATLAB_PARSING als aller erster in der main.cpp auf (noch vor irgendetwas anderem).

manni66 schrieb:

Solche defines übergibt man dem Compiler direkt. In Visual Studio wird das in den Projekteigenschaften C/C++->Preprocessor und dann in Preprocessor Definitions gemacht.

Wusste ich nicht, funkt aber aufjedenfall.

Falls jemand eine klare Antwort für dieses Problem hat, immer her damit. Ansonsten verbuche ich das mal unter "MS VS 2010 Eigenart".

Danke für den Tipp!

Falls jemand eine klare Antwort für dieses Problem hat, immer her damit.

Die Antwort wird sein, dass du irgendwo irgendetwas vergessen hast. Der Code den du hier zeigst, wird wohl nicht 1:1 das beobachtete Verhalten erzeugen. Zeig mal ein vollständiges Beispiel, bei dem du auch getestet hat, dass es sich tatsächlich unerwartet verhält.

Ansonsten verbuche ich das mal unter "MS VS 2010 Eigenart".

Nein. Glaubst du wirklich, DU hättest einen nicht-dokumentierten Fehler in einem häufig genutzten Teil eines weit verbreiteten Programms gefunden, wenn die Möglichkeit, dass der Fehler bei dir liegen könnte, nicht ausgeschlossen ist?

Dann würde die Reihenfolge in irgendeiner Art und Weise eine Rolle spielen, denn ich rufe #define NON_MATLAB_PARSING als aller erster in der main.cpp auf (noch vor irgendetwas anderem).

Definiere "als aller erstes"

Einzelne .cpp Files werden z.B. unabhängig voneinander kompiliert, von einer "Reihenfolge" zu reden macht in dem Zusammenhang gar keinen Sinn...

ich sage nicht, dass es unbedingt an MS VS 2010 liegen muss. Vielleicht liegt es auch an der library die ich nutze, aber den Fehler konnte ich auf die Schnelle nicht finden, zumal es ja anscheinend mit 2 anderen Methoden funktioniert. Wahrscheinlich liegt der Fehler sogar bei mir, sonst würde ich ja hier nicht fragen
Ich will ja wissen, wo das Problem liegt oder ob es tatsächlich einfach eine Eigenart ist. Der gcc Verhält sich ja auch manchmal anders, als VS. Kann ja sein, dass das Verhalten gar nicht genau definiert ist. Muss ja nicht immer gleich ein Bug sein.
Folgendes Beispiel geht nicht:

// Reihenfolge scheint hier aber egal zu sein
#define NON_MATLAB_PARSING
#include "extApi.h"
#include <iostream>
#include <conio.h>

int main(int argc, char* argv[]) {
	std :: cout << "Hallo Welt" << std :: endl;
	_getch();
}

Die Solution wurde mit cmake erstellt:

cmake_minimum_required(VERSION 2.6)
project(TestAPI)

set(SOURCES
    src/main.cpp
	src/extApi.c
	src/extApiCustom.c
	src/extApiPlatform.c
)

set(HEADERS
    include/extApi.h
	include/extApiCustom.h
	include/extApiInternal.h
	include/extApiPlatform.h
	include/extApiCustomConst.h
	include/v_repConst.h
	include/v_repLib.h
)

include_directories("include/")
#add_definitions( -DNON_MATLAB_PARSING ) # hiermit gehts

add_executable(
    TestAPI
    ${SOURCES}
    ${HEADERS}
)

Aufbau des Projekts sieht so aus:

root
 + vs
 + qtcreator
 + src
 + include
 - CMakeList.txt

In src und include sind die header und cpp Dateien aufgeteilt. Die lib ist Teil von V-REP (http://www.v-rep.eu/), einem Programm zur Simulation von Robotern (ähnlich Player/Stage oder MS robotics studio). Auch wenn V-REP closed source ist, sind die Remote API Funktionen als cpp/h Dateien verfügbar, damit diese bei Bedarf erweitert werden können.
Ich will jetzt hier nicht Datei posten, konkret gehts aber um die extApi.h:

#ifndef _EXTAPI__
#define _EXTAPI__

#ifdef NON_MATLAB_PARSING /* when compiling, make sure NON_MATLAB_PARSING is always defined! */
	#include "extApiPlatform.h"
	#include "v_repConst.h"
#else 
	typedef char simxChar;
	typedef short simxShort;
	typedef unsigned short simxUShort;	
	typedef int simxInt;
	typedef unsigned int simxUInt;
	typedef float simxFloat;
	typedef void simxVoid;
#endif /* else NON_MATLAB_PARSING */

#ifdef _WIN32
	#define EXTAPI_DLLEXPORT extern __declspec(dllexport)
#endif
#if defined (__linux) || defined (__APPLE__)
	#define EXTAPI_DLLEXPORT extern
#endif

/* Use following to test endianness detection on little endian machines (endianness of the client is handled on the server side)
#define ENDIAN_TEST
*/

#ifdef NON_MATLAB_PARSING

// einige Funktionsdeklarationen, nach Kommentar: /* Various other functions, not to be called directly */

#endif /* NON_MATLAB_PARSING */

//ganz viele Funktionsdeklarationen, HIER treten später die Syntaxfehler (unerkennbar mittendrin) auf
//Soweit ich das sehe werden hier keine Funktionen redefiniert o.Ä. Nach Kommentar: /* The remote API functions */

Die inkludierten extApiPlatorform.h und v_repConst.h enthalten diverse enums/const/define Deklarationen. Dort kommt jedoch niergens NON_MATLAB_PARSING vor.

dot schrieb:

Definiere "als aller erstes"

Einzelne .cpp Files werden z.B. unabhängig voneinander kompiliert, von einer "Reihenfolge" zu reden macht in dem Zusammenhang gar keinen Sinn...

In diese Richtung zielte meine Frage, ob es dort eine Reihenfolge gibt oder eben nicht. Da die main.cpp meine main() enthält gehe ich davon aus, dass der compiler diese zuerst parst. Und dort wird er (siehe oben) als erstes ein #define finden.

Gruß
Pille456

In diese Richtung zielte meine Frage, ob es dort eine Reihenfolge gibt oder eben nicht. Da die main.cpp meine main() enthält gehe ich davon aus, dass der compiler diese zuerst parst. Und dort wird er (siehe oben) als erstes ein #define finden.

Die Reihenfolge ist egal. Auf Mehrkernsystemen können durchaus alle deine Dateien gleichzeitig compiliert werden. Der Präprozessor übernimmt keine Definitionen von einer Quellcodedatei zur anderen.

danke für Euren 3 Antworten in so kurzer Zeit
Mir war nicht bewusst, dass das total unabhängig voneinander kompiliert werden kann, dachte der compiler beginnt zumindest bei der main() function, bevor er sich den Rest vornimmt. Wieder was gelernt. Danke!