great, thanks. committed

https://github.com/moses-smt/mosesdecoder/commit/70e8eb54ce75feb0a7d4ed00d275e56652c0a914
I ran the regression tests before I commit, it's more extensive

Hieu Hoang
Research Associate (until March 2015)
** searching for interesting commercial MT position **
University of Edinburgh
http://www.hoang.co.uk/hieu


On 5 February 2015 at 15:49, Jeroen Vermeulen <
[email protected]> wrote:

> Here's a minor patch in case it's of use - but feel free to tell me to
> shut up if it isn't.
>
> Looking at some of the file-handling code I noticed that a lot of places
> check a string for a particular prefix or suffix with this kind of pattern:
>
>   if (
>     (text.size() >= suffix.size()) &&
>     (text.substr(text.size()-suffix.size()) == suffix)) {
>
> It's a bit hard to read, and could lead to strange crashes if you forget
> the length check.  For example, checking for...
>
>   filename.substr(filename.size()-3) == ".gz"
>
> ...would crash if filename was less than 3 characters long.
>
> If anyone's interested, I'm attaching a patch that replaces all
> prefix/suffix checks that I could find with BOOST's starts_with() and
> ends_with().  It's a little safer and easier to follow, and doesn't make
> you count the characters in a fixed-length suffix:
>
>   if (ends_with(text, suffix)) {
>   if (ends_with(filename, ".gz")) {
>   if (starts_with(item, "[") && ends_with(item, "]")) {
>
> None of these cases looked particularly performance-sensitive, but I
> checked just in case.  If anything, the BOOST code looks more
> optimizer-friendly.  It compares characters in-place (so no need to copy
> a substring) and seems to optimize for the known length of string
> constants (so it knows at compile time that ".gz" is 3 characters long).
>
> I haven't done any manual testing, but the unit tests pass.  Is that
> considered a reasonable guarantee?
>
>
> Jeroen
>
> _______________________________________________
> Moses-support mailing list
> [email protected]
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to