Boost logo

Boost :

From: deansturtevant_at_[hidden]
Date: 2001-03-13 06:10:30


--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> The header could go like:
>
> //==================================================================
=======
> // Standard Boost header blurb goes here
>
> // Beman could put a revision history here, which would really be
> // the release date of each Boost version. He has to remember to
> // update this file before each official release. Maybe a tool
> // could be written to do it?
>
>
> // Past Boost versions, single-part
> // (previous versions don't have constants)
> #define BOOST_VERSION_1_21_1 0x0178
> //...
> #define BOOST_VERSION_2_1_0 0x0201
>
> // Current Boost version, single-part
> // (compare this with the ones above, if needed)
> #define BOOST_VERSION_CURRENT BOOST_VERSION_2_1_0
>
> // Current Boost version, multiple-parts
> // (for display only; not for comparisons)
> #define BOOST_VERSION_MAJOR 2
> #define BOOST_VERSION_MINOR 1
> #define BOOST_VERSION_FIX 0
> //==================================================================
=======
>
> I guess it could be used like (excuse any line-wrapping my e-mailer
does):
>
> //==================================================================
=======
> #include <boost/release_version.hpp>
>
> #if defined(BOOST_VERSION_1_23_0) && (BOOST_VERSION_CURRENT >
> BOOST_VERSION_1_23_0)
> #include <boost/crc.hpp> // Boost 1.23.0's version had a bug
> #else
> #include <custom/crc_code.hpp>
> #endif
>
> //...
>
> int main()
> {
> //...
>
> cout << "Using Boost " << BOOST_VERSION_MAJOR << '.'
> << BOOST_VERSION_MINOR << '.' << BOOST_VERSION_FIX << ".\n";
>
> //...
> }
> //==================================================================
=======
I think this suggestion is a tad too complicated. Not only that, but
I maintain that the mere existence of these constants is dangerous.
How about having one version number and one version string? The
string could be instantiated in a library.
- Dean


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk