Hi James,
Not that I am arguing against but the templates use the define
XERCES_TMPLSINC (ie. #if !defined(XERCES_TMPLSINC)) to determine whether
or not to include the .c files. Inside src/xercesc/Makefile.incl for HPUX
if the compiler is not aCC then this define is set. I am not sure what
compiler this would be for (perhaps an earlier version of aCC). I think
this is all that would break if this would change (I don't see any other
places where XERCES_TMPLSINC is set). For the HP compiler I think we
already require aCC A.03.52 to build (I recall that in 2.6.0 we pulled out
some checks for HPUX compilers in XMemory.hpp) so this may be a non issue
already, although it would be good if someone with more HPUX experience
could comment.... Anyone?
Regards,
David A. Cargill
James Berry
<[EMAIL PROTECTED]
g> To
xerces-c-dev@xml.apache.org
02/18/2005 07:06 cc
PM
Subject
Re: Xerces internal use of .c
Please respond to include files
xerces-c-dev
On Feb 18, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote:
>> - Convert these files into actual templates, perhaps. I haven't
>> looked enough into the implementations to know whether this is
>> possible, or to discover what else might prevent us from doing this. I
>> do know that we use templates elsewhere in Xerces, so this shouldn't
>> break any compiler compatibility...?
> This was done for a very old version of IBM's xlC compiler that had a
> very
> rudimentary implementation for template instantiation. Since that
> compiler is long gone, I would vote we just do away with those files,
> and
> include their contents in the corresponding .hpp files. Xalan-C++ has
> done this from the beginning, without any problems.
> On the other hand, there are compilers that supports a separation of
> template declaration from template definition, but explicit
> instantiation
> requires more work. What are the chances we would want to do that?
> Any
> opinions?
Unless there's a good reason to bear the pain of specially supporting
the really old compilers (by doing something close to what we do today)
or supporting explicit instantiation (which presumably would require
some additional work or checks), I'd suggest we simply opt for rolling
the .c code into the .hpp files.
Any arguments from anybody on why we shouldn't do that?
-jdb
>> - Change the extensions on the files to something else.
>> Suggestions
>> are welcome. .tcc comes to mind, though I know gcc uses this for some
>> of it's code and I don't want to confuse it. Does anybody know of any
>> standard usage?
> The Rogue Wave library on HP with aCC uses .cc, and the Dinkumware
> library
> shipped on AIX with xlC uses .t, so there doesn't seem to be much of a
> consensus out there.
> Dave
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
