You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Robert Buck <rb...@mathworks.com> on 2002/07/12 14:34:24 UTC

Please Reconsider: Re: Xerces versioning policies and version definition in XercesDefs.hpp

Wait a minute...

> >     #define Xerces_DLLVersionStr "2_74_109"
> >     const char* const    gXercesVersionStr = "2_74";
> >     const char* const    gXercesFullVersionStr = "2_74_109";
> >     const unsigned int   gXercesMajVersion = 2;
> >     const unsigned int   gXercesMinVersion = 74;
> >     const unsigned int   gXercesRevision   = 109;
> >     #define XERCES_VERSION_MAJOR 2
> >     #define XERCES_VERSION_MINOR 74
> >     #define XERCES_VERSION_REVISION 109
> >
> >     #define XERCES_VERSION 0x02074109

Please, no. Please look at that example you provided again. Hex value 0x74 
!= 74.
Hex value 0x74 = = 116 !!! Does that mean that this is the 116th or 74th 
minor version?

I am trying to point out some confusion that immediately comes to the 
forefront when you use this
style. The example you cite is confusing, is inconsistent with reality, and 
will lead to
endless issues later (for users). One could also say that the correct value 
for it is 42EBD, right?
And the base-10 numeric value for your example above is 34029833.

I find the hex idea far less desirable purely from a usability standpoint. 
When
a Xerces user sees something like "274109", they can immediately recognize
visually which version of Xerces this refers to - it refers to 2.74.109. 
But the hex
value is not as friendly as you end up with 42EBD, right? As a user I would 
have
to back calculate what the base-10 numeric value for that is, to determine what
the patch and minor version levels are.


>Agreed.
>
>I would also like to see all the other non-critical macros removed
>from version.hpp, like all the concat macros, and just maintain these
>numbers by hand - after all they don't change very often...

Please, no.

Please ***don't*** rip out what we just managed to put in - especially 
those macros!
What is there now _is_ good. Let me explain why.

Captured within the definition of those macros is the policy for the format
of version strings and numbers that we have been speaking about. Considering
all the recent email activity regarding version preprocessor macros, it
should be aparent to contributors to Xerces that this mechanism is fairly
important to users of Xerces than we were first aware. By capturing the
policy in "code" you prevent accidental inconsistencies with the policy from
creeping into the library, guarenteeing users a consistent working form. You
cannot provide this guarentee otherwise.

I have looked into the idea for formatting in hex last night at home, and I
have come to the conclusion that it does not have all the redeeming
qualities the other form has. The other idea that Urs had suggested really
seems the best. By adding his one suggestion we will have achieved creating
something that works and captures the policy for form within code, and
avoid troubles later on.

Please make this _one_ change to the version header file, and lets be done
with it:

Change:

#define _XERCES_VERSION ...

to:

// ---------------------------------------------------------------------------
// C A L C U L A T E   V E R S I O N   -   E X P A N D E D   F O R M

#define MULTIPLY(factor,value) factor * value
#define CALC_EXPANDED_FORM(a,b,c) ( MULTIPLY(10000,a) + MULTIPLY(100,b) + 
MULTIPLY(1,c) )

// ---------------------------------------------------------------------------
// P R O D U C T   V E R S I O N   I N F O R M A T I O N

// PREPROCESSOR MACROS

#define _XERCES_VERSION 
CALC_EXPANDED_FORM(XERCES_VERSION_MAJOR,XERCES_VERSION_MINOR,XERCES_VERSION_REVISION)

-Bob


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org