Re: [boost] [range][1.34] Cannot compile date-time due to upstream range change?

From: Pavol Droba (droba_at_[hidden])
Date: 2006-06-08 12:06:14

On Thu, Jun 08, 2006 at 06:22:22AM -0700, Jeff Garland wrote:
> Pavol Droba wrote:
> > Hi,
> > 
> > Range interface has been changed, but only in the CVS_HEAD. 
> 
> Ok, noting that in my version I have not taken the updated range for at 
> least a couple months and there's a huge list of range files that need 
> updating.
> 
> >1_34 branch should be consistent. 
> 
> With what, 1.33.1?  It's clearly different.
> 
> >The regression test for string_algo library are passing
> > as well.
> 
> Sure -- I can't explain the success of the regression tests.
> 
> > I would check, you your code does not use mixed versions of boot..
> 
> I've tested with multiple versions of boost on my machine for years, but 
> I triple checked before I posted.
> 
>   > cd ~/devTools/boost_rc_1_34/libs/date_time/test
>   > bjam
> 
> --> fails
> 
>   > cd ~/devTools/boost_cvs/libs/date_time/test
>   > bjam
> --> succeeds
> 
>   > cd ~/devTools/boost_1_33_1/libs/date_time/test
>   > bjam
> --> succeeds
> 
> I don't think it's possible for bjam to be confused about what it is 
> pointing to (and note that there's no BOOST_ROOT set). To be sure I 
> compiled a small date-time test case using g++ -I to switch the include, 
> diffed the date-time, string algo, range directories, etc.
> 
> And then there's this in the output pointing squarely at my RC version.
> 
> /home/jeff/devTools/boost_rc_1_34/boost/range/const_iterator.hpp:37:
> error: ???const char*??? is not a class, struct, or union type
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> /home/jeff/devTools/boost_rc_1_34/boost/algorithm/string/replace.hpp: In
> function ???void boost::algorithm::replace_all(SequenceT&, const Range1T&,
> const Range2T&) [with SequenceT = std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, Range1T = const char*,
> Range2T = std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >]???:
> 

Ok, that was just a guess. I'll have a look. But it might help if Thorsten
would check it out as well.

Regards,
Pavol.