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> 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.

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
>
>

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.
>
>

"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.

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.
>
>

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
> >
> >
>
>

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
> > >
> > >
> >
> >
>
>

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
> > > >
> > > >
> > >
> > >
> >
> >
>
>