lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Raw strings


From: Vadim Zeitlin
Subject: Re: [lmi] Raw strings
Date: Tue, 9 Mar 2021 14:56:35 +0100

On Tue, 9 Mar 2021 12:40:42 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 3/9/21 2:05 AM, Greg Chicares wrote:
GC> > On 3/9/21 12:25 AM, Vadim Zeitlin wrote:
GC> [...]
GC> >> std::string const simple_table_header =
GC> >> 1 + R"""(
GC> [...contents...]
GC> >> )""";
GC> >> 
GC> >> ? This seems quite readable to me and it's short and memorable enough to
GC> >> use it without having to look it up every time.
GC> > 
GC> > Either way is fine with me, as long as we standardize on exactly one.
GC> 
GC> Having slept on it, I do prefer '--cut-here--' because it's
GC> self-documenting, whereas '"""' is not.

 One last feeble attempt: it's true that "--cut-here--" is self-documenting
even for people not familiar with any other languages. But anybody who has
seen Python (or Java, in a few years, when this new syntax becomes more
widespread), shouldn't have any trouble understanding R"""(...)""" neither.
And the latter is just significantly easier to both type (I'm confident of
being able to do it without looking up the existing uses of raw strings)
and, IMHO, read.

 Also, more generally, I, of course, attach more importance than you to
using more standard approaches, as I work on many different projects and
it just makes life easier for me if there are more commonalities between
them and fewer surprising project-specific idiosyncrasies. But even if you,
perfectly logically, attach less importance to this, I still think there is
some value in not always doing very peculiar lmi-specific thing. And using
"--cut-here--" is definitely special and unique: without looking it up, I'm
willing to bet that no other project does it, while there are probably at
least a few projects using R"""(...)""".

 So if you agree to switch to a less surprising delimiter, I'd be glad to
do it (and update the coding style check, of course). But if you don't say
anything more, I promise to drop this subject, I'm already glad we've found
a way to keep using raw strings in lmi at all.

 Regards,
VZ

Attachment: pgp5DmMCDFXd3.pgp
Description: PGP signature


reply via email to

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