Re: Strange compile error

[Berin Lautenbach <be...@ozemail.com.au>]

Vincent,

Will look into defining _MEM_DEBUG.  I think including windows.h for all 
includes is also overkill - I only need it in some places, so I will 
look at trying to cut the whole thing down a bit.

On the other one, I can see a couple of solutions :

1.  Don't inject into global namespace within include files - so have 
all references to Xerces/Xalan elements be fully qualified until I hit 
the actual cpp files.  This ties everything more tightly with 
Xerces/Xalan, but that's about the only "negative" I can see.

2.  Define a xsec namespace and then inject into there.  Seems like 
overkill, and means people have to worry about Xerces/Xalan and Xsec 
namespaces.

3.  typedef everything to a new type.  It's probably the best way to do 
it architecturally (place an interface between the DOM library and the 
XSEC library), but we'd then need wrappers around things to get correct 
types returned, and it could quickly get nasty.

So I think I'm leaning with number 1 (for now), but interested in 
thoughts.  Any other options gratefully received :>.

Cheers,
	Berin

Vincent Finn wrote:
> That sounds fine, undefing _DEBUG before the headers is a bit less hacky
> than doing _WINDOWS_
> 
> 
> 
>>-----Original Message-----
>>From: Berin Lautenbach [mailto:berin@ozemail.com.au]
>>Sent: 30 August 2003 03:40
>>To: Vincent Finn
>>Cc: 'security-dev@xml.apache.org'
>>Subject: Re: Strange compile error
>>
>>
>>Vincent,
>>
>>Firstly - apologies for not replying sooner. Was away all week and 
>>no-where near e-mail.
>>
>>The reason for afx.h in the debug build is to allow us to use the 
>>Windows memory debugging routines.  But it means you need an 
>>MFC build. 
>>  Pain in the neck, but it's helped me track some really 
>>nasty memory leaks.
>>
>>You could undefine the _DEBUG flag in the debug build - but 
>>that's messy 
>>as well.
>>
>>How about I create a new define _MEM_DEBUG that can be turned off in 
>>XSECW32Config.h to go back to normal includes?
>>
>>On the second question - Ouch.  Yes I can see the problem.  
>>Let me have 
>>a think.
>>
>>Cheers,
>>	Berin
>>
>>
>>Vincent Finn wrote:
>>
>>>Hi,
>>>
>>>I tracked my problems down and it leaves me with a few questions
>>>
>>>The first is about the debug error
>>>
>>>This comes from the fact that in XSECDefs.hpp there is code 
>>
>>that includes
>>
>>>"afx.h" for debug builds
>>>and "windows.h" for release ones
>>>afx.h eventually includes afxv_w32.h which will stop windows.h being
>>>included twice
>>>this will stop any ATL projects from building since they 
>>
>>automatically
>>
>>>include windows.h
>>>
>>>why is there a different include for debug (except for the 
>>
>>crtdbg bit
>>
>>>obviously)?
>>>
>>>I can get around this by undefing _WINDOWS_ for the xsec 
>>
>>headers but that
>>
>>>seems to be very hacky
>>>the alternative would seem to be to remove the header but 
>>
>>this won't compile
>>
>>>is there a better solution?
>>>
>>>---
>>>
>>>The second question is why are the Xerces classes being 
>>
>>injected into the
>>
>>>global namespace?
>>>e.g. XSEC_DECLARE_XERCES_CLASS(DOMDocument);
>>>this seems a bit extreme to me and causes my other problem
>>>
>>>The compile bug happens because the VC ATL wizard 
>>
>>automatically includes
>>
>>>msxml in ATL dll projects 
>>>(it a hidden dependency somehow, so I can't get rid of it)
>>>and they inject DOMDocument into the global namespace
>>>
>>>so know you get 2 DOMDocuments in the global namespace
>>>
>>>I am currently running with a modified library
>>>with XSEC_DECLARE_XERCES_CLASS(DOMDocument) which requires 
>>
>>a lot of other
>>
>>>minor changes
>>>
>>>Is there a better solution for this problem too?
>>>
>>>
>>>I would prefer a solution that could be done in the library 
>>
>>(or my calling
>>
>>>code) 
>>>I don't really want to be using a hacked version of the 
>>
>>xsec since it makes
>>
>>>upgrading a mess!
>>>
>>>Any suggestions appreciated
>>>
>>>	Vin
>>>
>>>
>>>-------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Vincent Finn 
>>>>Sent: 27 August 2003 12:39
>>>>To: 'security-dev@xml.apache.org'
>>>>Subject: Strange compile error
>>>>
>>>>
>>>>Hi,
>>>>
>>>>I have a strange problem compiling a project using xsec
>>>>
>>>>I am on WinXP, VC6 SP5, xerces 2.2, openssl 0.9.7b, xsec 1.0
>>>>I have a COM dll which currently uses xerces to create an XML file
>>>>I am adding xsec in to sign the file
>>>>
>>>>when I add the line
>>>>#include <xsec/framework/XSECProvider.hpp>
>>>>I get errors (the same is true for other xsec includes)
>>>>
>>>>The strange part is that I have code in a test (console) 
>>
>>project which
>>
>>>>parses an XML file and signs it and this works, but not in my 
>>>>real project
>>>>also I get very different errors in debug and release
>>>>
>>>>the only other point I can think of worth mentioning is that 
>>>>I do have a global using statement
>>>>using namespace XERCES_CPP_NAMESPACE;
>>>>
>>>>Has anyone seen this or have any idea what it might be?
>>>>
>>>>	Thanks, Vin
>>>>
>>>>
>>>>The errors are as follows
>>>>in DEBUG
>>>>c:\program files\microsoft visual 
>>>>studio\vc98\mfc\include\afxv_w32.h(14): fatal error C1189: 
>>>>#error :  WINDOWS.H already included.  MFC apps must not 
>>>>#include <windows.h>
>>>>
>>>>in RELEASE
>>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/utils/XSECSafeBuffer
>>>>Formatter.hpp(108): warning C4100: 'formatter': unreferenced 
>>>>formal parameter
>>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGTransform.h
>>>>pp(79): error C2874: using-declaration causes a multiple 
>>>>declaration of 'DOMDocument'
>>>>   
>>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102)
>>>>: see declaration of 'DOMDocument'
>>>>C:\LIBS\XML-SECURITY-C-1.0.0\INCLUDE\xsec/dsig/DSIGSignedInfo.
>>>>hpp(82): error C2874: using-declaration causes a multiple 
>>>>declaration of 'DOMDocument'
>>>>   
>>>>C:\LIBS\XERCES-C-SRC2_2_0\SRC\xercesc/dom/DOMDocument.hpp(102)
>>>>: see declaration of 'DOMDocument'
>>>>
>>>>--------------------------------------------------------------
>>>>---------
>>>>vincent.finn@automsoft.com
>>>>--------------------------------------------------------------
>>>>---------
>>>>INTEL INSIDE: The worlds most widely used warning label.
>>>>------------------------------------------------------------
>>
>>----------
>>
>>>
>