Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-05-13 14:52:21


Russell Hind wrote:
> Edward Diener wrote:
>> It is really difficult to know where the changes need to be done.
>> There are a number of tests in the Boost header files and source
>> files for Borland version numbers 0x560, 0x561, and 0x562 but none
>> of these are extended to cover 0x564. I would think that the library
>> developers where these tests are being made would attempt to see
>> whether or not these tests also need to be applied to 0x564 or not.
>> But I don't think most Boost library developers even care about this
>> anymore, unfortunately. I hope I am wrong about this.
>>
>
> I think part of the problem comes from Borland not releasing the
> comamnd-line compiler 5.6 for free, as they did with 5.5.
>
> Also, Update 4 was only released a week or 2 before 1.30.0 was
> released,
> so there was minimum amount of time to make changes for this.

I do understand this and remember the timing issue well. I also do
understand why the 1.30 release was not changed at the last moment to
accomodate Update 4, as it would have delayed 1.30 well beyond the date in
which it was planned to be released.

> We
> pushed
> for a change in format to take into account 0x564 which did get in for
> the release but many didn't because people were un-willing
> (understandably) to make changes so close to a release.

I agree with those people.

>
> What may be helpful would be a list of current work-arounds for each
> compiler and where they are used so when a new patch comes out, we
> have
> a shorter list of items that need looking at to see if the work-around
> is still needed, or if it has been fixed in the latest patch.

Yes, that would be valuable from library implementors. I have also pushed in
the past for library implementors to be more responsive to documenting
changes from Boost release to release of their libraries, but this idea has
been ignored as a whole although a few library developers actually do this.

My main concern is that code which tests specifically for some BCB6
__BORLANDC__ number, such as 0x561, and assumes only this means BCB6, has
not been updated to also test for 0x562 and 0x564 when appropriate. But I
don't know if this is the case anywhere, which was the reason for my
original post.


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