DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23024>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23024 DOMCasts magic: failure building Xerces-C 2.3.0 with C++ Builder 5 ------- Additional Comments From [EMAIL PROTECTED] 2003-09-10 15:03 ------- None of the files added by Vitaly were there in version 2.3.0 but the defines may have made a difference.. dunno. Anyways, I now get an exception 0xC0000027 when running DOMMemTest. Interestingly, though, when compiling with a freshly download BCC551 with the makefiles in the BCC* directory (slightly patched to add the MemoryManagerArrayImpl.obj file) from a CVS tarball from 2003-09-09 (latest I could find) I don't have any problem. The same thing won't compile with stock BCB5 (but I can use the lib & dll from BCB5). So, I now have a .lib & dll I can use, but I'm still not very happy with the casting magic. FWIW, I'm running on a Win2KSP4. I also use Xerces-C on Cygwin, MSVC, Linux and FreeBSD, all w/o problems. --- Neil Graham wrote on 2003-09-10 13:52: > Given the huge variety of platforms that this seems to work on--a list that's > considerably longer than the binaries we provide would indicate--I really > don't think we'd want to take the memory hit of the additional pointers for > this one compiler. It's possible my perspective could change when we hear > from Jason and when the inconsistency between Vitaly and Ronald's observations > is resolved, but that's my $0.02 for now. I'm afraid what we see remains inconsistent - but even what *I* see is inconsistent: AFAIK, BCC551 is the compiler that should be used by BCB5, so I don't see why the two should give different results.. As for the extra memory overhead for the additional pointers: if memory were a real concern, the user wouldn't use DOM. DOM is an easy-to-use model, but is by no means efficient and AFAICT isn't intended to be. If the user wants efficiency, he'll use SAX. With that in mind, I don't see any reason to forego clean programming for the sake of a couple of bytes more memory to spend. It's 4 to 16B per class - which might amount to a couple of K per XML file. IMHO, if you advertise portability, you can't rely on the ABI not changing (or on the order of attributes in a class, for that matter). It may work for the time being, but I am not surprised that it won't work every time (even if different versions of the same compiler spit out different versions of the same DLL from the same code..) rlc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
