Boost logo

Boost :

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-05 03:59:28

AlisdairM wrote:

> It has been agreed that several platforms will be deprecated in this
> version of Boost. To support that I have added a warning to the
> Borland config to alert anyone using old versions of this platform that
> it is being deprecated and this is the last compatible release.
> What I notice is the warning gets annoying pretty quickly.
> I propose to wrap the warning in the following test:
> #if __BORLANDC__ <= 0x581 && !defined(BOOST_ACKNOWLEDGE_DEPRECATED_1_34)
> # pragma message "...";
> #endif
> This will allow users to disable the warning by defining the macro in
> their environment.
> I would like to extend this to a general policy, to make deprecation
> more visible were it occurs. Using the BOOST_ACKNOWLDGE_DEPRECATED
> test we could deprecate libraries or functions, as well as platforms.
> The test is a simple 'does this macro exist' rather than testing for a
> value, so should be compatible with toolchains that allow defining
> macros, but not giving them values.
> The macro is tied to the specific version that is deprecated, so in
> later releases we should grep for BOOST_DEPRECATED and either update
> the version, or do something stronger such as use #error (platform) or
> remove the code entirely (library)

I'm not sure I like all aspects of your proposal, but I do agree that a
general deprecation policy would be useful, especially if supported by
tools similar to those you envision.

One thing I do feel strongly about: no matter how broken a library is
with a specific compiler, deprecation advertising should entail a
warning and not an error.

This would make it more easy to un-deprecate a platform when it starts
supporting the required constructs and enables library authors to accept
platform specific patches on a discretionary basis. Moreover even if
such patches were not submitted/accepted developers would be free to try
and use those portions of a library that do work on their platform.

It would also make it possible to accept platform specific patches
against previous releases of Boost and maybe even allow more bugfix
releases, should anybody volunteer to perform the necessary tasks.

A concrete example: I'm using Borland's BCB6 at work and we're stuck
with Boost 1.31 because we're using uBlas, which doesn't support my
compiler in more recent releases. Now I happen to know that 1.32
"almost" works and that someone has the necessary patches. Accepting
these to be committed against the 1.32 branch would enable all those in
my situation to at least move forward one release (I happen to know that
there are at least two of us - right, Russell? :-).

To issue a bugfix release based on 1.32 now probably does not make much
sense, but a 1.33.2 release incorporating support for compiler versions
issued in the last six months might be appreciated by those wishing to
upgrade their compiler separately from their Boost version.

Nicola Musatti

Boost list run by bdawes at, gregod at, cpdaniel at, john at