|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
c++ - More pre-defined macros ...
↑ ↓ ← → "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__
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
32?
Major and minor versions are MSB and LSB of the __DMC__ macro
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
it is 48, of course). Unless someone knows of a natty pre-processing
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__
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
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
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__
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
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
C++ there are only a few numbers to conjure with and so the versions can
derived explicitly as in the following extract from the Synesis compiler
discriminating root header. (I am pretty happy with the current state as
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,
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 >=
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
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
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
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
to a version of a compiler, and I certainly don't want to provide
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
revisions. The only thing you can tell from the version number is that
higher numbers are better than lower ones <g>. Additionally, since
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__
in addition to the very useful __DMC_VERSION_STRING__, where each
evaluate to a (decimal?) number representing the major and minor build
numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__ defined
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
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
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
otherwise an excellent and singular characteristic of your great
causes this requirement. With other super-supported compilers such as
C++ there are only a few numbers to conjure with and so the versions can
derived explicitly as in the following extract from the Synesis compiler
discriminating root header. (I am pretty happy with the current state as
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,
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
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 >=
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
required and not on the details of in what symbol (or symbols) the
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
dormant for months!).
So with DMC, if one wants to support the (many) separate versions,
either an overall decimal symbol, or separate decimal major/minor
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
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
to a version of a compiler, and I certainly don't want to provide
that may fail to work (without at least there being a "#error This code
not compatible with your version of XYZ C++ compiler"), as that makes
libraries look bad.
Nevertheless, I am aware of your many tasks, and don't want to add to
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
revisions. The only thing you can tell from the version number is that
higher numbers are better than lower ones <g>. Additionally, since
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__
in addition to the very useful __DMC_VERSION_STRING__, where each
evaluate to a (decimal?) number representing the major and minor
numbers, e.g. __DMC_MAJOR__ defined to be 8 and __DMC_MINOR__
to
be
32?
Matthew
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next