• Matthew Wilson (6/6) Dec 20 2002 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__ mac...
• Gisle Vanem (5/10) Dec 21 2002 Major and minor versions are MSB and LSB of the __DMC__ macro respective...
• Matthew Wilson (9/19) Dec 21 2002 Alas, this is wrong, as you anticipate (given you use of %X :))
• Gisle Vanem (4/8) Dec 21 2002 I've installed 8.31 here and works as I defined it. Borland's __BORLANDC...
• Matthew Wilson (10/19) Dec 21 2002 Sure. Of course the code you wrote would work, but that's a runtime
• Walter (9/15) Dec 20 2002 I'd rather not, since DMC doesn't follow the usual model of major and mi...
• Matthew Wilson (130/148) Dec 21 2002 I understand your reticence, as solution of the macro namespace is not a
• Walter (23/175) Dec 21 2002 I don't understand. There's nothing in common between compiler version
• Matthew Wilson (52/245) Dec 21 2002 I wasn't suggesting that compiler numbers were related between vendors, ...

"Matthew Wilson" <dmd synesis.com.au> writes:

Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__ macros
in addition to the very useful __DMC_VERSION_STRING__, where each would
evaluate to a (decimal?) number representing the major and minor build
numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined to be
32?

Matthew

"Gisle Vanem" <giva bgnett.no> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote:

 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__ macros
 in addition to the very useful __DMC_VERSION_STRING__, where each would
 evaluate to a (decimal?) number representing the major and minor build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined to be
 32?

Major and minor versions are MSB and LSB of the __DMC__ macro respectively.
E.g.
  printf ("Digital Mars C %X.%X", __DMC__ >> 8, __DMC__ & 0xFF);

Gisle V.

"Matthew Wilson" <dmd synesis.com.au> writes:

Alas, this is wrong, as you anticipate (given you use of %X :))

__DMC__ & 0xFF for the current beta 8.23 evaluates to 0x32, not 32 (in fact
it is 48, of course). Unless someone knows of a natty pre-processing time
technique to convert hex to decimal, this is not much use.


"Gisle Vanem" <giva bgnett.no> wrote in message
news:au1k0p$2c7k$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote:

 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__


macros
 in addition to the very useful __DMC_VERSION_STRING__, where each would
 evaluate to a (decimal?) number representing the major and minor build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined to


be
 32?

 Major and minor versions are MSB and LSB of the __DMC__ macro

respectively.
 E.g.
   printf ("Digital Mars C %X.%X", __DMC__ >> 8, __DMC__ & 0xFF);

 Gisle V.

"Gisle Vanem" <giva bgnett.no> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote:

 Alas, this is wrong, as you anticipate (given you use of %X :))

 __DMC__ & 0xFF for the current beta 8.23 evaluates to 0x32, not 32 (in fact
 it is 48, of course). Unless someone knows of a natty pre-processing time
 technique to convert hex to decimal, this is not much use.

I've installed 8.31 here and works as I defined it. Borland's __BORLANDC__
is defined the same way, btw.

Gisle V.

"Matthew Wilson" <dmd synesis.com.au> writes:

Sure. Of course the code you wrote would work, but that's a runtime
conversion to string using printf() and %X. As I mention, this does not help
with the compile-time requirement.

Thanks for your input anyway.

:)

Matthew

"Gisle Vanem" <giva bgnett.no> wrote in message
news:au2j4l$318v$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote:

 Alas, this is wrong, as you anticipate (given you use of %X :))

 __DMC__ & 0xFF for the current beta 8.23 evaluates to 0x32, not 32 (in


fact
 it is 48, of course). Unless someone knows of a natty pre-processing


time
 technique to convert hex to decimal, this is not much use.

 I've installed 8.31 here and works as I defined it. Borland's __BORLANDC__
 is defined the same way, btw.

 Gisle V.

"Walter" <walter digitalmars.com> writes:

I'd rather not, since DMC doesn't follow the usual model of major and minor
revisions. The only thing you can tell from the version number is that
higher numbers are better than lower ones <g>. Additionally, since updates
to the latest version are free on the web site, there is no reason for
anyone to be accommodating to older versions.


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:au0ui7$1km9$1 digitaldaemon.com...
 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__

macros
 in addition to the very useful __DMC_VERSION_STRING__, where each would
 evaluate to a (decimal?) number representing the major and minor build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined to

be
 32?

 Matthew

"Matthew Wilson" <dmd synesis.com.au> writes:

I understand your reticence, as solution of the macro namespace is not a
good thing.

My problem is that the very fact that you have frequent updates (which is
otherwise an excellent and singular characteristic of your great support)
causes this requirement. With other super-supported compilers such as Visual
C++ there are only a few numbers to conjure with and so the versions can be
derived explicitly as in the following extract from the Synesis compiler
discriminating root header. (I am pretty happy with the current state as far
as the STLSoft libraries goes, but am now trying to get full support for
DMC++ into my company's, much larger, code-base.)

#elif defined(_MSC_VER)
#undef __SYNSOFT_DVS_COMPILER_VER_MSVC
 #define __SYNSOFT_DVS_COMPILER
__SYNSOFT_VAL_COMPILER_MSVC
#if _MSC_VER == 800
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(1, 51)
#elif _MSC_VER == 900
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(2, 0)
#elif _MSC_VER == 1000
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(4, 0)
#elif _MSC_VER == 1020
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(4, 2)
#elif _MSC_VER == 1100
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(5, 0)
#elif _MSC_VER == 1200
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(6, 0)
#elif _MSC_VER == 1300
 #define __SYNSOFT_DVS_COMPILER_VER_MSVC
__SYNSOFT_GEN_COMPILER_VERSION(7, 0)
#else
 #error Could not recognise the Microsoft compiler version. (Not 1.51, 2.0,
4.0, 4.2, 5.0, 6.0, or 7.0).
#endif /* _MSC_VER */
#define __SYNSOFT_DVS_COMPILER_VER
__SYNSOFT_DVS_COMPILER_VER_MSVC

Having the symbol __SYNSOFT_GEN_COMPILER_VERSION(j, n) allows one to write
compiler-symbol independent code, such as

#if defined(__cplusplus) && \
    (   (__SYNSOFT_DVS_COMPILER_VER_BORLAND >=
__SYNSOFT_GEN_COMPILER_VERSION(4, 2)) || \
        (__SYNSOFT_DVS_COMPILER_VER_DECCXX >=
__SYNSOFT_GEN_COMPILER_VERSION(6, 1)) || \
        (__SYNSOFT_DVS_COMPILER_VER_DMC >= __SYNSOFT_GEN_COMPILER_VERSION(8,
26)) || \
        (__SYNSOFT_DVS_COMPILER_VER_GNUC >=
__SYNSOFT_GEN_COMPILER_VERSION(2, 91)) || \
        (__SYNSOFT_DVS_COMPILER_VER_MSVC >=
__SYNSOFT_GEN_COMPILER_VERSION(4, 0)) || \
        (__SYNSOFT_DVS_COMPILER_VER_WATCOM >=
__SYNSOFT_GEN_COMPILER_VERSION(11, 0)))
 #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
#endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

Of course one could write

#if defined(__cplusplus) && \
    (   (__BORLANDC__ >= 0x0452) || \
        (((__DECCXX_VER) / 100000) >= 601) || \
        (__DMC__ >= 0x0826) || \
        (   (__GNUC__ > 2 || \
            (    __GNUC == && \
                   __GNUC_MINOR__ >= 91))) || \
        (_MSC_VER >= 1000) || \
        (__WATCOMC__ == 1100))
 #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
#endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

but having a uniform mechanism allows one to focus on the compiler version
required and not on the details of in what symbol (or symbols) the compilers
store their version information, and in what form that information is
stored. Practical experience has shown many times that having the
generalised form leads to a great many fewer errors. As you can no doubt
appreciate, finding pre-processor bugs can take a long time (things can lie
dormant for months!).

So with DMC, if one wants to support the (many) separate versions, having
either an overall decimal symbol, or separate decimal major/minor symbols
would be a great boon. Otherwise it'll have to be something along the
current lines of.

#elif defined(__DMC__)
#undef __SYNSOFT_DVS_COMPILER_VER_DMC
#define __SYNSOFT_DVS_COMPILER
__SYNSOFT_VAL_COMPILER_DMC
#if __DMC__ == 0x0826
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 26)
#elif __DMC__ == 0x0827
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 27)
#elif __DMC__ == 0x0828
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 28)
#elif __DMC__ == 0x0829
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 29)
#elif __DMC__ == 0x0830
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 30)
#elif __DMC__ == 0x0831
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 31)
#elif __DMC__ == 0x0832
#define __SYNSOFT_DVS_COMPILER_VER_DMC
__SYNSOFT_GEN_COMPILER_VERSION(8, 32)
#else
#error Could not recognise the Digital Mars C++ compiler version. (Not
8.26 - 8.32).
#endif /* __DMC__ */
#define __SYNSOFT_DVS_COMPILER_VER
__SYNSOFT_DVS_COMPILER_VER_DMC
/* END: Digital Mars C/C++ compilers */

Your assertion that there is no need to support multiple versions due to the
updates being (pleasantly) freely available doesn't really persuade me,
however. I just can't see how it is ever reasonable to demand a user updates
to a version of a compiler, and I certainly don't want to provide libraries
that may fail to work (without at least there being a "#error This code is
not compatible with your version of XYZ C++ compiler"), as that makes the
libraries look bad.

Nevertheless, I am aware of your many tasks, and don't want to add to your
burden. I just imagined it would be a straightforward thing to do, and
therefore something that you could slip.

Matthew

P.S. I am taking your advice on the preparation of the remaining STLSoft
libraries, in that I am only going to support more recent DMC++ versions
(probably just 8.31 onwards)



"Walter" <walter digitalmars.com> wrote in message
news:au269i$2o8i$1 digitaldaemon.com...
 I'd rather not, since DMC doesn't follow the usual model of major and

minor
 revisions. The only thing you can tell from the version number is that
 higher numbers are better than lower ones <g>. Additionally, since updates
 to the latest version are free on the web site, there is no reason for
 anyone to be accommodating to older versions.


 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:au0ui7$1km9$1 digitaldaemon.com...
 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__

 macros
 in addition to the very useful __DMC_VERSION_STRING__, where each would
 evaluate to a (decimal?) number representing the major and minor build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined to

 be
 32?

 Matthew

"Walter" <walter digitalmars.com> writes:

I don't understand. There's nothing in common between compiler version
numbers from various vendors and support for various features. You're always
going to be stuck with a long #if-#elif#endif sequence. I suspect the
easiest thing to do is to create a seperate configuration header for each
vendor, and list the support features in those headers, in whatever
idiosyncratic means available from that vendor. Then, the rest of your code
is all clean and based on #if FEATURE_X type macros.

It's more or less what I do when I have to support multiple vendors.

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:au31g3$9p8$1 digitaldaemon.com...
 I understand your reticence, as solution of the macro namespace is not a
 good thing.

 My problem is that the very fact that you have frequent updates (which is
 otherwise an excellent and singular characteristic of your great support)
 causes this requirement. With other super-supported compilers such as

Visual
 C++ there are only a few numbers to conjure with and so the versions can

be
 derived explicitly as in the following extract from the Synesis compiler
 discriminating root header. (I am pretty happy with the current state as

far
 as the STLSoft libraries goes, but am now trying to get full support for
 DMC++ into my company's, much larger, code-base.)

 #elif defined(_MSC_VER)
 #undef __SYNSOFT_DVS_COMPILER_VER_MSVC
  #define __SYNSOFT_DVS_COMPILER
 __SYNSOFT_VAL_COMPILER_MSVC
 #if _MSC_VER == 800
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(1, 51)
 #elif _MSC_VER == 900
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(2, 0)
 #elif _MSC_VER == 1000
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(4, 0)
 #elif _MSC_VER == 1020
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(4, 2)
 #elif _MSC_VER == 1100
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(5, 0)
 #elif _MSC_VER == 1200
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(6, 0)
 #elif _MSC_VER == 1300
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(7, 0)
 #else
  #error Could not recognise the Microsoft compiler version. (Not 1.51,

2.0,
 4.0, 4.2, 5.0, 6.0, or 7.0).
 #endif /* _MSC_VER */
 #define __SYNSOFT_DVS_COMPILER_VER
 __SYNSOFT_DVS_COMPILER_VER_MSVC

 Having the symbol __SYNSOFT_GEN_COMPILER_VERSION(j, n) allows one to write
 compiler-symbol independent code, such as

 #if defined(__cplusplus) && \
     (   (__SYNSOFT_DVS_COMPILER_VER_BORLAND >=
 __SYNSOFT_GEN_COMPILER_VERSION(4, 2)) || \
         (__SYNSOFT_DVS_COMPILER_VER_DECCXX >=
 __SYNSOFT_GEN_COMPILER_VERSION(6, 1)) || \
         (__SYNSOFT_DVS_COMPILER_VER_DMC >=

__SYNSOFT_GEN_COMPILER_VERSION(8,
 26)) || \
         (__SYNSOFT_DVS_COMPILER_VER_GNUC >=
 __SYNSOFT_GEN_COMPILER_VERSION(2, 91)) || \
         (__SYNSOFT_DVS_COMPILER_VER_MSVC >=
 __SYNSOFT_GEN_COMPILER_VERSION(4, 0)) || \
         (__SYNSOFT_DVS_COMPILER_VER_WATCOM >=
 __SYNSOFT_GEN_COMPILER_VERSION(11, 0)))
  #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
 #endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

 Of course one could write

 #if defined(__cplusplus) && \
     (   (__BORLANDC__ >= 0x0452) || \
         (((__DECCXX_VER) / 100000) >= 601) || \
         (__DMC__ >= 0x0826) || \
         (   (__GNUC__ > 2 || \
             (    __GNUC == && \
                    __GNUC_MINOR__ >= 91))) || \
         (_MSC_VER >= 1000) || \
         (__WATCOMC__ == 1100))
  #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
 #endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

 but having a uniform mechanism allows one to focus on the compiler version
 required and not on the details of in what symbol (or symbols) the

compilers
 store their version information, and in what form that information is
 stored. Practical experience has shown many times that having the
 generalised form leads to a great many fewer errors. As you can no doubt
 appreciate, finding pre-processor bugs can take a long time (things can

lie
 dormant for months!).

 So with DMC, if one wants to support the (many) separate versions, having
 either an overall decimal symbol, or separate decimal major/minor symbols
 would be a great boon. Otherwise it'll have to be something along the
 current lines of.

 #elif defined(__DMC__)
 #undef __SYNSOFT_DVS_COMPILER_VER_DMC
 #define __SYNSOFT_DVS_COMPILER
 __SYNSOFT_VAL_COMPILER_DMC
 #if __DMC__ == 0x0826
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 26)
 #elif __DMC__ == 0x0827
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 27)
 #elif __DMC__ == 0x0828
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 28)
 #elif __DMC__ == 0x0829
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 29)
 #elif __DMC__ == 0x0830
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 30)
 #elif __DMC__ == 0x0831
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 31)
 #elif __DMC__ == 0x0832
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 32)
 #else
 #error Could not recognise the Digital Mars C++ compiler version. (Not
 8.26 - 8.32).
 #endif /* __DMC__ */
 #define __SYNSOFT_DVS_COMPILER_VER
 __SYNSOFT_DVS_COMPILER_VER_DMC
 /* END: Digital Mars C/C++ compilers */

 Your assertion that there is no need to support multiple versions due to

the
 updates being (pleasantly) freely available doesn't really persuade me,
 however. I just can't see how it is ever reasonable to demand a user

updates
 to a version of a compiler, and I certainly don't want to provide

libraries
 that may fail to work (without at least there being a "#error This code is
 not compatible with your version of XYZ C++ compiler"), as that makes the

 libraries look bad.

 Nevertheless, I am aware of your many tasks, and don't want to add to your
 burden. I just imagined it would be a straightforward thing to do, and
 therefore something that you could slip.

 Matthew

 P.S. I am taking your advice on the preparation of the remaining STLSoft
 libraries, in that I am only going to support more recent DMC++ versions
 (probably just 8.31 onwards)



 "Walter" <walter digitalmars.com> wrote in message
 news:au269i$2o8i$1 digitaldaemon.com...
 I'd rather not, since DMC doesn't follow the usual model of major and

 minor
 revisions. The only thing you can tell from the version number is that
 higher numbers are better than lower ones <g>. Additionally, since


updates
 to the latest version are free on the web site, there is no reason for
 anyone to be accommodating to older versions.


 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:au0ui7$1km9$1 digitaldaemon.com...
 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__

 macros
 in addition to the very useful __DMC_VERSION_STRING__, where each



would
 evaluate to a (decimal?) number representing the major and minor build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined



to
 be
 32?

 Matthew

"Matthew Wilson" <dmd synesis.com.au> writes:

I wasn't suggesting that compiler numbers were related between vendors, just
that practise has shown that it is easier to write something like

#if defined(__cplusplus) && \
  ( (__CC_VER_BORLAND >= __CC_VERSION(4, 2)) || \
    (__CC_VER_DECCXX >= __CC_VERSION(6, 1)) || \
    (__CC_VER_DMC >= > __CC_VERSION(8, 26)) || \
    (__CC_VER_GNUC >= __CC_VERSION(2, 91)) || \
    (__CC_VER_MSVC >= __CC_VERSION(4, 0)) || \
    (__CC_VER_WATCOM >= __CC_VERSION(11, 0)))
 #define ____CC_CAST_OPERATOR_SUPPORT
#endif /* __COMPILER && __cplusplus */

than

#if defined(__cplusplus) && \
  ( (__BORLANDC__ >= 0x0452) || \
    (((__DECCXX_VER) / 100000) >= 601) || \
    (__DMC__ >= 0x0826) || \
    ( (__GNUC__ > 2 || \
      (  __GNUC == && \
           __GNUC_MINOR__ >= 91))) || \
    (_MSC_VER >= 1000) || \
    (__WATCOMC__ == 1100))
 #define ____CC_CAST_OPERATOR_SUPPORT
#endif /* __COMPILER && __cplusplus */


in so far as one is less likely to make syntax errors (which slip past the
pre-processor), because everything other than the numbers is boilerplate and
so one can focus on the numbers.

The alternative technique is, as you say, to have a separate header for each
compiler where the features are discriminated which is then included by the
main header. I have used both techniques in the past (and both still exist
for various currently used code), and both have their respective benefits
and pains. The macro request would facilitate the former one being made more
simple wrt DMC++.

Anyway, as I said, I don't want to heap more work on you, and suspect that
the amount of your time I've spent on the issue is more than I wanted to use
in its implementation, so am content to drop it.

Be speaking soon.

Matthew

"Walter" <walter digitalmars.com> wrote in message
news:au353d$c87$1 digitaldaemon.com...
 I don't understand. There's nothing in common between compiler version
 numbers from various vendors and support for various features. You're

always
 going to be stuck with a long #if-#elif#endif sequence. I suspect the
 easiest thing to do is to create a seperate configuration header for each
 vendor, and list the support features in those headers, in whatever
 idiosyncratic means available from that vendor. Then, the rest of your

code
 is all clean and based on #if FEATURE_X type macros.

 It's more or less what I do when I have to support multiple vendors.

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:au31g3$9p8$1 digitaldaemon.com...
 I understand your reticence, as solution of the macro namespace is not a
 good thing.

 My problem is that the very fact that you have frequent updates (which


is
 otherwise an excellent and singular characteristic of your great


support)
 causes this requirement. With other super-supported compilers such as

 Visual
 C++ there are only a few numbers to conjure with and so the versions can

 be
 derived explicitly as in the following extract from the Synesis compiler
 discriminating root header. (I am pretty happy with the current state as

 far
 as the STLSoft libraries goes, but am now trying to get full support for
 DMC++ into my company's, much larger, code-base.)

 #elif defined(_MSC_VER)
 #undef __SYNSOFT_DVS_COMPILER_VER_MSVC
  #define __SYNSOFT_DVS_COMPILER
 __SYNSOFT_VAL_COMPILER_MSVC
 #if _MSC_VER == 800
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(1, 51)
 #elif _MSC_VER == 900
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(2, 0)
 #elif _MSC_VER == 1000
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(4, 0)
 #elif _MSC_VER == 1020
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(4, 2)
 #elif _MSC_VER == 1100
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(5, 0)
 #elif _MSC_VER == 1200
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(6, 0)
 #elif _MSC_VER == 1300
  #define __SYNSOFT_DVS_COMPILER_VER_MSVC
 __SYNSOFT_GEN_COMPILER_VERSION(7, 0)
 #else
  #error Could not recognise the Microsoft compiler version. (Not 1.51,

 2.0,
 4.0, 4.2, 5.0, 6.0, or 7.0).
 #endif /* _MSC_VER */
 #define __SYNSOFT_DVS_COMPILER_VER
 __SYNSOFT_DVS_COMPILER_VER_MSVC

 Having the symbol __SYNSOFT_GEN_COMPILER_VERSION(j, n) allows one to


write
 compiler-symbol independent code, such as

 #if defined(__cplusplus) && \
     (   (__SYNSOFT_DVS_COMPILER_VER_BORLAND >=
 __SYNSOFT_GEN_COMPILER_VERSION(4, 2)) || \
         (__SYNSOFT_DVS_COMPILER_VER_DECCXX >=
 __SYNSOFT_GEN_COMPILER_VERSION(6, 1)) || \
         (__SYNSOFT_DVS_COMPILER_VER_DMC >=

 __SYNSOFT_GEN_COMPILER_VERSION(8,
 26)) || \
         (__SYNSOFT_DVS_COMPILER_VER_GNUC >=
 __SYNSOFT_GEN_COMPILER_VERSION(2, 91)) || \
         (__SYNSOFT_DVS_COMPILER_VER_MSVC >=
 __SYNSOFT_GEN_COMPILER_VERSION(4, 0)) || \
         (__SYNSOFT_DVS_COMPILER_VER_WATCOM >=
 __SYNSOFT_GEN_COMPILER_VERSION(11, 0)))
  #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
 #endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

 Of course one could write

 #if defined(__cplusplus) && \
     (   (__BORLANDC__ >= 0x0452) || \
         (((__DECCXX_VER) / 100000) >= 601) || \
         (__DMC__ >= 0x0826) || \
         (   (__GNUC__ > 2 || \
             (    __GNUC == && \
                    __GNUC_MINOR__ >= 91))) || \
         (_MSC_VER >= 1000) || \
         (__WATCOMC__ == 1100))
  #define __SYNSOFT_DBS_CAST_OPERATOR_SUPPORT
 #endif /* __SYNSOFT_DVS_COMPILER && __cplusplus */

 but having a uniform mechanism allows one to focus on the compiler


version
 required and not on the details of in what symbol (or symbols) the

 compilers
 store their version information, and in what form that information is
 stored. Practical experience has shown many times that having the
 generalised form leads to a great many fewer errors. As you can no doubt
 appreciate, finding pre-processor bugs can take a long time (things can

 lie
 dormant for months!).

 So with DMC, if one wants to support the (many) separate versions,


having
 either an overall decimal symbol, or separate decimal major/minor


symbols
 would be a great boon. Otherwise it'll have to be something along the
 current lines of.

 #elif defined(__DMC__)
 #undef __SYNSOFT_DVS_COMPILER_VER_DMC
 #define __SYNSOFT_DVS_COMPILER
 __SYNSOFT_VAL_COMPILER_DMC
 #if __DMC__ == 0x0826
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 26)
 #elif __DMC__ == 0x0827
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 27)
 #elif __DMC__ == 0x0828
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 28)
 #elif __DMC__ == 0x0829
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 29)
 #elif __DMC__ == 0x0830
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 30)
 #elif __DMC__ == 0x0831
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 31)
 #elif __DMC__ == 0x0832
 #define __SYNSOFT_DVS_COMPILER_VER_DMC
 __SYNSOFT_GEN_COMPILER_VERSION(8, 32)
 #else
 #error Could not recognise the Digital Mars C++ compiler version. (Not
 8.26 - 8.32).
 #endif /* __DMC__ */
 #define __SYNSOFT_DVS_COMPILER_VER
 __SYNSOFT_DVS_COMPILER_VER_DMC
 /* END: Digital Mars C/C++ compilers */

 Your assertion that there is no need to support multiple versions due to

 the
 updates being (pleasantly) freely available doesn't really persuade me,
 however. I just can't see how it is ever reasonable to demand a user

 updates
 to a version of a compiler, and I certainly don't want to provide

 libraries
 that may fail to work (without at least there being a "#error This code


is
 not compatible with your version of XYZ C++ compiler"), as that makes


the
 libraries look bad.

 Nevertheless, I am aware of your many tasks, and don't want to add to


your
 burden. I just imagined it would be a straightforward thing to do, and
 therefore something that you could slip.

 Matthew

 P.S. I am taking your advice on the preparation of the remaining STLSoft
 libraries, in that I am only going to support more recent DMC++ versions
 (probably just 8.31 onwards)



 "Walter" <walter digitalmars.com> wrote in message
 news:au269i$2o8i$1 digitaldaemon.com...
 I'd rather not, since DMC doesn't follow the usual model of major and

 minor
 revisions. The only thing you can tell from the version number is that
 higher numbers are better than lower ones <g>. Additionally, since


 updates
 to the latest version are free on the web site, there is no reason for
 anyone to be accommodating to older versions.


 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:au0ui7$1km9$1 digitaldaemon.com...
 Walter, any chance you could provide __DMC_MAJOR__ and __DMC_MINOR__

 macros
 in addition to the very useful __DMC_VERSION_STRING__, where each



 would
 evaluate to a (decimal?) number representing the major and minor




build
 numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__




defined
 to
 be
 32?

 Matthew