lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] count_lines() [Was: Group premium quotes]


From: Vadim Zeitlin
Subject: Re: [lmi] count_lines() [Was: Group premium quotes]
Date: Wed, 19 Aug 2015 17:38:44 +0200

On Wed, 19 Aug 2015 14:59:43 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-08-16 17:07, Greg Chicares wrote:
GC> > First of all, don't read this before September, especially not if you're
GC> > on vacation.
GC> 
GC> I realize this may not matter much, but:
GC> 
GC> // Return the number of lines in a possibly multiline string.
GC> std::size_t count_lines(std::string const& s)
GC> {
GC>     return 1u + std::count(s.begin(), s.end(), '\n');
GC> }
GC> 
GC> It looks like these string arguments:
GC>   "__1__\n__2__"
GC>   "__1__\n__2__\n"
GC> would return different counts. Given the "1u +", I suppose we're assuming
GC> that there's no trailing '\n', in which case we should at least document
GC> that; but if it's worth documenting, it's worth asserting. Untested idea:
GC>   LMI_ASSERT(s.rend() && '\n' != *s.rend());

 I think the condition should be

        !s.empty() && '\n' != *s.rend()

but I'm not really sure if it's worth adding it. Currently, having a
trailing "\n" in the string behaves in the expected way: it just adds an
extra blank line to the corresponding header (count_lines() is only called
with the header text). I don't see why would anybody really need it, but
OTOH I don't see any real reason to forbid it neither.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]