minor compile-time issue with boost::regex (1.32)
this will cause compile warnings in VC7.1 with the "detect 64bit issues" flag set: boost::match_results<string::const_iterator> what; for(boost::match_results<string::const_iterator>::size_type i=0; i<what.size(); i++) results.push_back(string(what[i].first, what[i].second)); warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data it seems the operator takes an int for index instead of size_type. -- Cory Nelson http://www.int64.org
this will cause compile warnings in VC7.1 with the "detect 64bit issues" flag set:
boost::match_results<string::const_iterator> what; for(boost::match_results<string::const_iterator>::size_type i=0; i<what.size(); i++) results.push_back(string(what[i].first, what[i].second));
warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
it seems the operator takes an int for index instead of size_type.
For historical reasons a negative index is permitted - so for now I'm not going to change this to a size_type argument - although if there's any other way to suppress the warning I'll happily use it. John.
Please don't take offense when I say this, but "for historical reasons" set off my alarm for sloppy code. I don't claim to know C++ or Boost better than others here so if there is a better valid reason please enlighten me. If there is no way to have a negative index (this is not an array, after all..), why give the option? Doing things the wrong way just because thats how they were done before isn't good. I almost didn't reply for fear of setting off an arrogant developer. Not saying you are one of them, but there are an unfortunate amount in the OSS community and I have stepped on enough toes to learn. On Tue, 2 Nov 2004 10:57:14 -0000, John Maddock <john@johnmaddock.co.uk> wrote:
this will cause compile warnings in VC7.1 with the "detect 64bit issues" flag set:
boost::match_results<string::const_iterator> what; for(boost::match_results<string::const_iterator>::size_type i=0; i<what.size(); i++) results.push_back(string(what[i].first, what[i].second));
warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
it seems the operator takes an int for index instead of size_type.
For historical reasons a negative index is permitted - so for now I'm not going to change this to a size_type argument - although if there's any other way to suppress the warning I'll happily use it.
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Please don't take offense when I say this, but "for historical reasons" set off my alarm for sloppy code.
I don't claim to know C++ or Boost better than others here so if there is a better valid reason please enlighten me. If there is no way to have a negative index (this is not an array, after all..), why give the option? Doing things the wrong way just because thats how they were done before isn't good.
The design changed: it was previously documented as taking a signed value, with an index of -1 returning the equivalent of $` and -2 returning \'. Access this way is now deprecated; with the introduction of members prefix() and suffix() now providing that functionality. Access the old way is still supported so that existing code will still work (at least for now, eventually I'll make a breaking change and make the offset unsigned).
I almost didn't reply for fear of setting off an arrogant developer. Not saying you are one of them, but there are an unfortunate amount in the OSS community and I have stepped on enough toes to learn.
We try to succumb to reasoned argument around here, but we're all human all the same, John.
participants (2)
-
Cory Nelson -
John Maddock