Removed all the warnings. However, another issue has cropped up : I'm using the the following snippet of code to instantiate an object of XercesDOMSupport :
*/// dom_support_ - holds the XALAN XercesDOMSupport xalanc_1_11::XercesDOMSupport dom_support_;* However, getting the following error : *error C2512: 'xalanc_1_11::XercesDOMSupport' : no appropriate default constructor available T*his was working fine with xalanc_1_10 / VC7.1. How do I fix this ? On Wed, Dec 3, 2008 at 6:14 PM, Hans Smit <[EMAIL PROTECTED]> wrote: > The first warning is a common VC++7/8/9 warning. It is not major, but will > help you program in a more secure (non-buffer-overrun-like) manner. I > usually disable this warning, fixing it may lead to MS specific code. > > refer to: > http://msdn.microsoft.com/en-us/library/aa985974(VS.80).aspx<http://msdn.microsoft.com/en-us/library/aa985974%28VS.80%29.aspx> > and > http://msdn.microsoft.com/en-us/library/aa985965.aspx > > The 2nd warning (or is it an error) is unknown to me. It looks like you > forgot half the message. > > How did you resolve the references to xalanc_1_10 errors? These were specific to my project. I replaced all the xalan include files with the ones from the new source and changed references to xalanc_1_10 to xalanc_1_11 in a few files, followed by a clean build. That got rid of these errors. :) > > > Hans > > > > Hi, > > > > I'm pretty close to compiling my project with VC++8. However, I'm not > sure > > how best to remove the following warnings. Do I simply use the flag > > mentioned ? Or is there any other way to get rid of these warnings ? > > > > *thirdparty\xalanc/Include/XalanVector.hpp(274) : warning C4996: > > 'std::copy': Function call with parameters that may be unsafe - this call > > relies on the caller to check that the passed values are correct. To > > disable > > this war use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use > > Visual C++ 'Checked Iterators' > > > > thirdparty\xalanc/Include/XalanVector.hpp(266) : while compiling class > > template member function 'unsigned short > > *xalanc_1_11::XalanVector<Type>::erase(unsigned short *,unsigned short > *)' > > with > > [ > > Type=xalanc_1_11::XalanDOMChar > > ] > > thirdparty\xalanc/XalanDOM/XalanDOMString.hpp(59) : see reference > > to > > class template instantiation 'xalanc_1_11::XalanVector<Type>' being > > compiled > > with > > [ > > Type=xalanc_1_11::XalanDOMChar > > ]* > > > > On Wed, Dec 3, 2008 at 1:18 AM, Hans Smit <[EMAIL PROTECTED]> wrote: > > > >> It seems like Dyuti and I got into a one-on-one thread. I must remember > >> to > >> use "reply all". Here is the rest of the thread for those of you who are > >> interested: (it seems to be a recurring theme - the "building" theme...) > >> > >> > >> Tuesday, December 02, 2008 19:27 Hans Smit wrote: > >> > >> Once again, I vaguely remember having a similar problem (with > >> Xalanc_1_10 / > >> 1_11 mix up). I think I had to double check that my project linking with > >> the > >> xalanc include + the xalanc library directories were to the newly > >> compiled > >> XalanC. I also remember having some dll dependencies that had to be > >> recompiled (they were throwing dll inconsistent linkage errors). It all > >> came > >> down to carelessness on my part, so I didn't bother making any notes on > >> this. I'm not sure this is the problem your having though. > >> > >> I assume you did manage to compile the XalanMsgLib project? It is > >> important > >> that you take nothing from the previous xalanc version. > >> > >> I would suggest starting a project from scratch and just try to compile > >> a > >> short xalanc function call. If this doesn't work, you at least have > >> something to share with the rest (that we can try to debug). Have you > >> tried > >> compiling and running any of the XalanC examples? > >> > >> It's a shame every one has a different way of saying "char" in C++. > >> Would > >> you like a 'w_' with that, a 'XalanDomChar', or a 'XMLCh' with your > >> encoding > >> today sir? Or would you like it s8, u8, u16 or the super duper u32? :-) > >> I > >> guess that was my pathetic excuse of a joke... encodings and locale have > >> been the bane of my existance since I started working with XML related > >> technologies. > >> > >> Hans > >> ----- Original Message ----- From: Dyuti Barma > >> To: Hans Smit > >> Sent: Tuesday, December 02, 2008 18:54 > >> Subject: Re: Xalan with VC++8 > >> > >> > >> Comments inline - > >> > >> > >> On Tue, Dec 2, 2008 at 7:51 PM, Hans Smit wrote: > >> > >> I vaguely remember having similar problems, and if my memory serves me > >> correctly... > >> > >> Check out the following settings in MSVC++ Project Properties: > >> > >> General->Character Set = Not set > >> C++ -> Language -> Treat w_char as built in type = Yes > >> > >> Yep, these settings seem to be in order. Still getting the same errors. > >> What I can't understand is - Why are the errors referring to Xalanc_1_10 > >> when I've replaced it by the new Xalanc_1_11 . Any clue ? > >> > >> > >> > >> Make sure the settings in the XalanC / XercesC and your own project > >> match. > >> This is very important. > >> > >> I hope this helps. Let us know. > >> > >> Cheers, > >> > >> Hans > >> > >> > >> Hey, > >>> > >>> Finally built Xalan-c. Phew !! > >>> (by removing all the .rc files) > >>> And I can totally imagine how you felt when you saw the success message > >>> ...Thanks a ton :-) > >>> > >>> And if I'm not asking for too much, can you tell me why I'm getting the > >>> following errors while building my application with the latest Xalan ? > >>> Thing to be noted is that - the error messages still refer to > >>> xalanc_1_10 > >>> instead of xalanc_1_11. Do you know why thats happening ? > >>> > >>> xalanc/DOMSupport/DOMServices.hpp(571) : error C2664: 'void (const > >>> XMLCh *const ,const unsigned int)' : cannot convert parameter 1 from > >>> 'const xalanc_1_10::XalanDOMChar *' to 'const XMLCh *const ' > >>> > >>> > >>> > >>> Types pointed to are unrelated; conversion requires > >>> reinterpret_cast, C-style cast or function-style cast > >>> xalanc/XPath/XObject.hpp(339) : error C2664: 'void (const XMLCh > >>> *const,const unsigned int)' : cannot convert parameter 1 from 'const > >>> xalanc_1_10::XalanDOMChar *' to 'const XMLCh *const ' > >>> > >>> > >>> > >>> Types pointed to are unrelated; conversion requires > >>> reinterpret_cast, C-style cast or function-style cast > >>> xalanc/XPath/XObject.hpp(343) : error C2664: 'void (const XMLCh > >>> *const,const unsigned int)' : cannot convert parameter 1 from 'const > >>> xalanc_1_10::XalanDOMChar *' to 'const XMLCh *const ' > >>> > >>> > >>> > >>> On Tue, Dec 2, 2008 at 6:05 PM, Hans Smit wrote: > >>> > >>> You are most likely compiling with VC++8 Express Edition. The express > >>>> edition does not include the resource builder. To get it to build > >>>> properly, remove all the .rc files from the projects you are going to > >>>> compile. > >>>> > >>>> I'm not sure why XalanC developers included any .rc files. I'm not > >>>> sure > >>>> what purpose they serve in a non-gui application. > >>>> > >>>> Also, be sure you get the xalanmessages_1_11.lib to build, and make > >>>> sure > >>>> your project knows where to locate it. Without it, you are out of luck > >>>> building xalanc. Isn't building fun? ;-) And just think, it's much > >>>> easier > >>>> than it was a couple of years ago. Back then, I spent an entire night > >>>> trying to figure out how to build XalanC. I guess you can image how > >>>> pleased I was when I saw the build message stating 0 errors. > >>>> > >>>> Hans > >>>> > >>> > >> > >> > >> ----- Original Message ----- From: "David Bertoni" <[EMAIL PROTECTED] > > > >> To: <xalan-c-users@xml.apache.org> > >> Sent: Tuesday, December 02, 2008 20:30 > >> Subject: Re: Xalan with VC++8 > >> > >> > >> Dyuti Barma wrote: > >>> > >>>> fwiw, I was unable to build XAlanMsgLib due to following error : > >>>> cannot open include file 'winres.h' > >>>> > >>>> What can I do to resolve this ? > >>>> > >>> Make sure you've installed the minimal amount of the ATL/MFC frameworks > >>> as > >>> you can. Unfortunately, that file is only installed by those > >>> components. > >>> > >>> Dave > >>> > >>> > >> > > > > >
