The code I write needs to compile under several older versions of Boost, as I'm sure is very common. I have been tripped up by using const_pointer_cast, which apparently doesn't exist very far into the past. As far as I can see, implementing this functionality is not trivial, because it's easy to make a mess of the reference counts in shared pointers. I'd like to know when this functionality was introduced, but with the older documentation offline at the moment I'm a bit scuppered. I thought of downloading old versions from source forge, but find there's a gap between 1.33.1 and 1.38 Any ideas how I can find out? Thx - Rob.
On 9 August 2010 13:29, Robert Jones
The code I write needs to compile under several older versions of Boost, as I'm sure is very common.
I have been tripped up by using const_pointer_cast, which apparently doesn't exist very far into the past.
The header 'ponter_cast.hpp' was added in boost 1.34, if that helps. Daniel
On Mon, Aug 9, 2010 at 1:43 PM, Daniel James
On 9 August 2010 13:29, Robert Jones
wrote: The code I write needs to compile under several older versions of Boost, as I'm sure is very common.
I have been tripped up by using const_pointer_cast, which apparently doesn't exist very far into the past.
The header 'ponter_cast.hpp' was added in boost 1.34, if that helps.
It does, on this specific query, which makes my life somewhat easier today, thanks! In general I was hoping for a more general excavation strategy for older versions, as this kinda thing comes up quite often. - Rob.
Zitat von Robert Jones
On Mon, Aug 9, 2010 at 1:43 PM, Daniel James
wrote: On 9 August 2010 13:29, Robert Jones
wrote: The code I write needs to compile under several older versions of Boost, as I'm sure is very common.
I have been tripped up by using const_pointer_cast, which apparently doesn't exist very far into the past.
The header 'ponter_cast.hpp' was added in boost 1.34, if that helps.
It does, on this specific query, which makes my life somewhat easier today, thanks!
In general I was hoping for a more general excavation strategy for older versions, as this kinda thing comes up quite often.
why don't you write code for the oldest version you need to support? the documentation for some old versions is still online. just change the version number in the URL. even older versions should still be available for download. boost library authors usually keep the breaking changes for new versions to a minimum and document them. this is probably easier than backporting.
On Mon, Aug 9, 2010 at 3:07 PM, Stefan Strasser
why don't you write code for the oldest version you need to support? the documentation for some old versions is still online. just change the version number in the URL. even older versions should still be available for download.
boost library authors usually keep the breaking changes for new versions to a minimum and document them. this is probably easier than backporting.
Yes, a perfectly sensible strategy, but one not available to me right at this moment, since the backporting requirement emerged AFTER the code had been written! On broader front the correct answer to my dilemma is obviously to standardise on a dev environment including compilers, third party libs etc. I say 'obviously', but in practise there seem to be innumerable political hurdles to overcome. Such is the life of a production software engineer I guess, but really the hidden cost of all this phaphing about must be immense! - Rob.
Robert Jones wrote:
On Mon, Aug 9, 2010 at 1:43 PM, Daniel James
wrote: On 9 August 2010 13:29, Robert Jones
wrote: The code I write needs to compile under several older versions of Boost, as I'm sure is very common.
I have been tripped up by using const_pointer_cast, which apparently doesn't exist very far into the past.
The header 'ponter_cast.hpp' was added in boost 1.34, if that helps.
It does, on this specific query, which makes my life somewhat easier today, thanks!
In general I was hoping for a more general excavation strategy for older versions, as this kinda thing comes up quite often.
I guess running svn log on the interesting file is the most straigh-forward approach. Once you identify revision where some functionality is added, you can examine the next release after that to see if the change was merged, or not. - Volodya
participants (4)
-
Daniel James
-
Robert Jones
-
Stefan Strasser
-
Vladimir Prus