为什么多行字符串有如此奇怪的语法? (当他们这样做时)
可能是我缺少的非常简单的东西,但是将字符串放在多行中有什么问题吗?
例如,Ruby 是:
text = <<END
Some
text
END
Python 是:
text = """
Some
text
"""
C# 是:
string text = @"
Some
Text";
这更接近,但仍然需要 @ 字符。
使用这样的单行有什么问题:
text = "
Some
text
"
我认为在这种情况下,字符串文字可能会结束,其中 (") 单独出现,这样,如果在途中找到引号,它们将被忽略。
text = "
He said "This is cool"
But it wasn't , until "
" //<-- quote mark alone
什么原因在许多编程语言(即 Java、JavaScript、C#、C++、C、Ruby、Python)中,是否可以避免使用单引号多行字符串文字?
Probably is something really simple that I'm missing, but what's wrong with having a string going in multiple lines?
For instance, Ruby is:
text = <<END
Some
text
END
And Python is:
text = """
Some
text
"""
And C# is:
string text = @"
Some
Text";
Which come closer, but still needs the @ character.
What's wrong with using a single line like this:
text = "
Some
text
"
I think in this case, the string literal could end, where the (") appears alone, that way, if quotes are found in the way, they are ignored.
text = "
He said "This is cool"
But it wasn't , until "
" //<-- quote mark alone
What reason(s) are there to avoid having single quotes multi lines string literal in many programming languages, namely, Java, JavaScript, C#, C++, C, Ruby, Python?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
首先,解析起来很恐怖 - 取决于其余语法的简单程度,这个单一的“便利功能”可能会使前端变得更加复杂。详情请参阅 diere 的回答。
另一个原因是这样的语法可能很危险 - 忘记一个结束引号,你就会得到一个巨大的字符串和一个小得多的程序;)
第三,通常不需要多行字符串(尤其是在甚至跨多行连接相邻文字字符串的语言,例如 C 和 Python)。与上述缺点相比,它只是没有回报。
First, it's a horror to parse - depending how simple the rest of the grammar is, this single "convenience feature" may make the frontend orders of magnitude more complex. See dierre's answer for details.
Another reason is that such syntax could be dangerous - forget a closung quote and you've got one huge string and a much smaller program ;)
Third, multi-line strings are not needed that often (especially in languages that concatnate adjacent literal strings even across multiple lines, like C and Python). It just doesn't pay off compared to the above drawbacks.
我能想到所需的特定语法的唯一原因是因为这样您就不必担心转义字符。我不确定这就是原因,但这肯定是这种语法的优点。
当您必须定义语法时,最后一个示例有点问题,因为您使用单个标记
"
来执行多个操作,而这对于标准 LALR(1) 来说并不容易,您将需要更多输入中的标记来预测要使用的正确规则。有关LALR 解析器的更多信息。
The only reason I can think of a specific syntax needed is because then you don't have to worry about escaping characters. I'm not sure this is the reason but it's surely an advantage of this syntax.
The last example is a bit problematic when you have to define your syntax because you are using a single token
"
to do multiple stuff and that's not easy with a standard LALR(1), you'll need more token in input to predict the right rule to use.More information on LALR parser.
我怀疑其中一部分是试图允许适当的格式。
在 C 或 C++ 中,您始终可以将一个长字符串写为一个长字符串,但这会向右延伸,并且如果它绕回,则会很难看。允许将其拆分可以更轻松地保持程序格式的完整性。通常,C 和 C++ 程序不会大量使用多行字符串,因此更改语言以使其更方便是有用的。
在字符串中显式显示行尾等通常很有用,并允许它保留周围程序的格式。有时,能够按照您想要的方式编写文字字符串也很有用,Ruby、Python 和 C# 示例展示了按照您想要的方式编写文字多行字符串的方法。
您的建议侵入了格式,就像 Ruby 和 Python 示例一样,而且看起来确实不是更好的解决方案。这些字符串很容易与普通字符串混淆,而 Ruby 和 Perl HERE 文档以及 Python 三引号准确地显示了这些字符串是什么。
I suspect part of this is trying to allow decent formatting.
In C or C++, you can always write a long string as one long string, but this will extend way to the right, and if it wraps around it's going to be ugly. Allowing it to be split up makes it easier to keep the formatting of the program intact. Typically, C and C++ programs do not make such heavy use of multiline strings as to make it useful to change the language to make them more convenient.
It's often useful to explicitly show the end-of-lines and such in a string, and to allow it to keep the formatting of the surrounding program. It's also sometimes useful to be able to write a literal string just the way you want it, and the Ruby, Python, and C# examples show ways to write literal multi-line strings just the way you want them.
Your suggestion intrudes on the formatting, much like the Ruby and Python examples, and really doesn't look like a better solution. It would be too easy to confuse those strings with normal strings, while the Ruby and Perl HERE-documents and Python triple quotation show exactly what those strings are.