Doppelte includes trotz Include Guards



  • Na ja, Xerces includiert die iostream.h so:

    #if defined(XERCES_NEW_IOSTREAMS)
    #include <iostream>
    #else
    #include <iostream.h>
    #endif
    

    Warum XERCES_NEW_IOSTREAMS jetzt hier nicht definiert ist weiß ich nicht.
    Die Version ist nicht die aktuellste, das lässt sich aus bestimmten Gründen auch nicht ändern. Ich verwende die 2.3.0

    Meine Includes sehen so aus:

    Anwendung:

    main.cpp

    #include "stdafx.h"
    
    #include <iostream>
    
    #include "Exporter.h"
    

    Exporter.cpp

    #include "StdAfx.h"
    
    #include <iostream>
    #include <math.h>
    
    #include "Exporter.h"
    

    Exporter.h

    #ifndef EXPORTER_H
    #define EXPORTER_H
    
    #include <algorithm>
    
    //Jede Menge includes aus der DLL
    #include "Generator.h"
    [...]
    

    DLL:

    Generator.h

    #ifndef __GENERATOR_H__
    #define __GENERATOR_H__
    #include "StdAfx.h"
    
    #include <fstream>
    
    #include "Measurements.h"
    

    StdAfx.h

    #if !defined(AFX_STDAFX_H__INCLUDED_)
    #define AFX_STDAFX_H__INCLUDED_
    
    #if _MSC_VER > 1000
    #pragma once
    #endif
    
    #include <windows.h>
    
    // TODO: reference additional headers your program requires here
    
    // ---- Xerces Stuff ----
    #include <iostream>
    
    #include <xercesc/util/PlatformUtils.hpp>
    #include <xercesc/util/XMLString.hpp>
    #include <xercesc/dom/DOM.hpp>
    
    #include <xercesc/framework/LocalFileFormatTarget.hpp>
    
    #if defined(XERCES_NEW_IOSTREAMS)
    #include <iostream>
    #else
    #include <iostream.h>
    #endif
    
    XERCES_CPP_NAMESPACE_USE
    // ---- ^ Xerces Stuff ^ ----
    
    #include <sstream>
    #include "XercesString.h"
    

    Wenn ich jetzt den include der Exporter.h (und den entsprechenden Code) in der main.cpp auskommentiere, dann kompiliert es. Prüfe ich in der main.cpp und der exporter.cpp, ob die defines der Include Guards existieren, dann ist dem in beiden Fällen nicht so.



  • Upps, das #include <iostream> in der StdAfx.h der DLL stammt noch aus meinen Tests, das muss da natürlich weg.



  • Also ich würde spontan mal XERCES_NEW_IOSTREAMS in deinem Projekt definieren.
    Simon



  • Thunderb0lt schrieb:

    Na ja, Xerces includiert die iostream.h so:

    #if defined(XERCES_NEW_IOSTREAMS)
    #include <iostream>
    #else
    #include <iostream.h>
    #endif
    

    Warum XERCES_NEW_IOSTREAMS jetzt hier nicht definiert ist weiß ich nicht.

    Weil du es nicht definiert hast. Das ist ganz offensichtlich ein Schlater, der vom Benutzer der Lib zu setzen ist. Du als Benutzer kannst damit angeben welche IOStreams Xerces benutzen soll (am Besten eben die, die Du auch benutzt). Da es sich vermutlich nicht um den einzigen Flag handeln wird und da es projekteinheitlich sein sollte, mach dir einen eigenen Forwarding-Header für xerces:

    //myXerces.h
    #define XERCES_NEW_IOSTREAMS
    // weitere #defines nach Bedarf
    #include "xerces.h"
    


  • Dann macht VC6 Probleme.

    main.cpp(46): fatal error C1001: INTERNAL COMPILER ERROR
            (compiler file 'msc1.cpp', line 1794) 
             Please choose the Technical Support command on the Visual C++ 
             Help menu, or open the Technical Support help file for more information
    

    Zeile 46 ist die letzte der Definition dieses globalen Enums.

    [cpp]enum Export_Type {
    XML = 1,
    HTML = 2,
    PLAIN = 4
    };[cpp]



  • Thunderb0lt schrieb:

    Dann macht VC6 Probleme.

    Dann nimm einen aktuellen Compiler. VC6 ist veraltet, hat zig Macken und unterstützt Teile des Standards nicht. Soweit ich das beurteilen kann ist der Code an der Stelle korrekt.



  • Thunderb0lt schrieb:

    Dann macht VC6 Probleme.

    main.cpp(46): fatal error C1001: INTERNAL COMPILER ERROR
            (compiler file 'msc1.cpp', line 1794) 
             Please choose the Technical Support command on the Visual C++ 
             Help menu, or open the Technical Support help file for more information
    

    Zeile 46 ist die letzte der Definition dieses globalen Enums.

    [cpp]enum Export_Type {
    XML = 1,
    HTML = 2,
    PLAIN = 4
    };[cpp]

    Lol! Dann nimm halt einen Compiler der nicht gerade 11Jahre alt wurde!!!



  • Wenn das eine Option wäre, würde ich ja nicht VC6 verwenden 😉
    Der Code an der Stelle kann ja eigentlich auch nicht der Grund sein. Denn wie gesagt, wenn ich das Include in der main.cpp auskommentiere funktioniert es ja und laufen tat es ja auch schonmal.



  • Tja, ohne den Code ders verursacht und ohne die nötige Glaskugel können wir hier nur raten worans gelegen hat. Und wenn der VC6 ne Vorgabe vom Chef ist dann geh zu ihm und sag er soll dir helfen weil alle anderen dich mit dem veralteten Stück Schrott nur auslachen 😉



  • Na ja, durch den komplette Code hätte sich ja auch keiner durchwühlen wollen, oder? 😉

    Aber über Umwege, habe ich den Fehler nun gefunden. Ein Element des Enums hatte den gleichen Namen, wie ein namespace, den ich mir über eine Reihe an verschachtelten Headern includiert habe. VC6 hat das dann nach ein paar Modifikationen an anderer Stelle im Code letztlich auch so ausgespuckt...

    Danke für eure Hilfe 🙂



  • deshalb gibts auch folgenden workaround:

    namespace enumname
    {
      enum T
      {
        /*..*/
      };
    }
    

    da passiert so was nicht und außerdem kann man über enumname::wert auf die enum-werte zugreifen...

    bb


Anmelden zum Antworten