String literal

Most modern programming languages use bracket delimiters (also balanced delimiters) to specify string literals. Double quotations are the most common quoting delimiters used:

 "Hi There!"

An empty string is literally written by a pair of quotes with no character at all in between:

 ""

Some languages either allow or mandate the use of single quotations instead of double quotations (the string must begin and end with the same kind of quotation mark and the type of quotation mark may or may not give slightly different semantics):

 'Hi There!'

These quotation marks are unpaired (the same character is used as an opener and a closer), which is a hangover from the typewriter technology which was the precursor of the earliest computer input and output devices.

In terms of regular expressions, a basic quoted string literal is given as:

"[^"]*"

This means that a string literal is written as: a quote, followed by zero, one, or more non-quote characters, followed by a quote. In practice this is often complicated by escaping, other delimiters, and excluding newlines.

A number of languages provide for paired delimiters, where the opening and closing delimiters are different. These also often allow nested strings, so delimiters can be embedded, so long as they are paired, but still result in delimiter collision for embedding an unpaired closing delimiter. Examples include PostScript, which uses parentheses, as in (The quick (brown fox)) and m4, which uses the backtick (`) as the starting delimiter, and the apostrophe (') as the ending delimiter. Tcl allows both quotes (for interpolated strings) and braces (for raw strings), as in "The quick brown fox" or {The quick {brown fox}}; this derives from the single quotations in Unix shells and the use of braces in C for compound statements, since blocks of code is in Tcl syntactically the same thing as string literals – that the delimiters are paired is essential for making this feasible.

The Unicode character set includes paired (separate opening and closing) versions of both single and double quotations:

 “Hi There!”
 ‘Hi There!’
 „Hi There!“
 «Hi There!»

These, however, are rarely used, as many programming languages will not register them (one exception is the paired double quotations which can be used in Visual Basic .NET). Unpaired marks are preferred for compatibility, as they are easier to type on a wide range of keyboards, and so even in languages where they are permitted, many projects forbid their use for source code.

String literals might be ended by newlines.

One example is MediaWiki template parameters.

 {{Navbox
 |name=Nulls
 |title=[[wikt:Null|Nulls]] in [[computing]]
 }}

There might be special syntax for multi-line strings.

In YAML, string literals may be specified by the relative positioning of whitespace and indentation.

    - title: An example multi-line string in YAML
      body : |
        This is a multi-line string.
        "special" metacharacters may
        appear here. The extent of this string is
        represented by indentation.

Some programming languages, such as Perl and PHP, allow string literals without any delimiters in some contexts. In the following Perl program, for example, red, green, and blue are string literals, but are unquoted:

%map = (red => 0x00f, blue => 0x0f0, green => 0xf00);

Perl treats non-reserved sequences of alphanumeric characters as string literals in most contexts. For example, the following two lines of Perl are equivalent:

$y = "x";
$y = x;

In the original FORTRAN programming language (for example), string literals were written in so-called Hollerith notation, where a decimal count of the number of characters was followed by the letter H, and then the characters of the string:

35HAn example Hollerith string literal

This declarative notation style is contrasted with bracketed delimiter quoting, because it does not require the use of balanced "bracketed" characters on either side of the string.

Advantages:

• eliminates text searching (for the delimiter character) and therefore requires significantly less overhead
• avoids the problem of delimiter collision
• enables the inclusion of metacharacters that might otherwise be mistaken as commands
• can be used for quite effective data compression of plain text strings

Drawbacks:

• this type of notation is error-prone if used as manual entry by programmers
• special care is needed in case of multi byte encodings

This is however not a drawback when the prefix is generated by an algorithm as is most likely the case.

C++ has two styles of string, one inherited from C (delimited by "), and the safer std::string in the C++ Standard Library. The std::string class is frequently used in the same way a string literal would be used in other languages, and is often preferred to C-style strings for its greater flexibility and safety. But it comes with a performance penalty for string literals, as std::string usually allocates memory dynamically, and must copy the C-style string literal to it at run time.

Before C++11, there was no literal for C++ strings (C++11 allows "this is a C++ string"s with the s at the end of the literal), so the normal constructor syntax was used, for example:

• std::string str = "initializer syntax";
• std::string str("converting constructor syntax");
• std::string str = string("explicit constructor syntax");

all of which have the same interpretation. Since C++11, there is also new constructor syntax:

• std::string str{"uniform initializer syntax"};
• auto str = "constexpr literal syntax"s;

A number of languages, including Pascal, BASIC, DCL, Smalltalk, SQL, J, and Fortran, avoid delimiter collision by doubling up on the quotation marks that are intended to be part of the string literal itself:

  'This Pascal string''contains two apostrophes'''

  "I said, ""Can you hear me?"""

Some languages, such as Fortran, Modula-2, JavaScript, Python, and PHP allow more than one quoting delimiter; in the case of two possible delimiters, this is known as dual quoting. Typically, this consists of allowing the programmer to use either single quotations or double quotations interchangeably – each literal must use one or the other.

  "This is John's apple."
  'I said, "Can you hear me?"'

This does not allow having a single literal with both delimiters in it, however. This can be worked around by using several literals and using string concatenation:

  'I said, "This is ' + "John's" + ' apple."'

Python has string literal concatenation, so consecutive string literals are concatenated even without an operator, so this can be reduced to:

  'I said, "This is '"John's"' apple."'

C++11 introduced so-called raw string literals. They consist, essentially of

R" end-of-string-id ( content ) end-of-string-id ",

that is, after R" the programmer can enter up to 16 characters except whitespace characters, parentheses, or backslash, which form the end-of-string-id (its purpose is to be repeated to signal the end of the string, eos id for short), then an opening parenthesis (to denote the end of the eos id) is required. Then follows the actual content of the literal: Any sequence characters may be used (except that it may not contain a closing parenthesis followed by the eos id followed a quote), and finally – to terminate the string – a closing parenthesis, the eos id, and a quote is required.
The simplest case of such a literal is with empty content and empty eos id: R"()".
The eos id may itself contain quotes: R""(I asked, "Can you hear me?")"" is a valid literal (the eos id is " here.)
Escape sequences don't work in raw string literals.

D supports a few quoting delimiters, with such strings starting with q" plus an opening delimiter and ending with the respective closing delimiter and ". Available delimiter pairs are (), <>, {}, and []; an unpaired non-identifier delimiter is its own closing delimiter. The paired delimiters nest, so that q"(A pair "()" of parens in quotes)" is a valid literal; an example with the non-nesting / character is q"/I asked, "Can you hear me?"/".
Similar to C++11, D allows here-document-style literals with end-of-string ids:

q" end-of-string-id newline content newline end-of-string-id "

In D, the end-of-string-id must be an identifier (alphanumeric characters).

In some programming languages, such as sh and Perl, there are different delimiters that are treated differently, such as doing string interpolation or not, and thus care must be taken when choosing which delimiter to use; see different kinds of strings, below.

A further extension is the use of multiple quoting, which allows the author to choose which characters should specify the bounds of a string literal.

For example, in Perl:

qq^I said, "Can you hear me?"^
qq@I said, "Can you hear me?"@
qq§I said, "Can you hear me?"§

all produce the desired result. Although this notation is more flexible, few languages support it; other than Perl, Ruby (influenced by Perl) and C++11 also support these. A variant of multiple quoting is the use of here document-style strings.

Lua (as of 5.1) provides a limited form of multiple quoting, particularly to allow nesting of long comments or embedded strings. Normally one uses [[ and ]] to delimit literal strings (initial newline stripped, otherwise raw), but the opening brackets can include any number of equal signs, and only closing brackets with the same number of signs close the string. For example:

local ls = [=[
This notation can be used for Windows paths: 
local path = [[C:\Windows\Fonts]]
]=]

Multiple quoting is particularly useful with regular expressions that contain usual delimiters such as quotes, as this avoids needing to escape them. An early example is sed, where in the substitution command s/regex/replacement/ the default slash / delimiters can be replaced by another character, as in s,regex,replacement, .

Another option, which is rarely used in modern languages, is to use a function to construct a string, rather than representing it via a literal. This is generally not used in modern languages because the computation is done at run time, rather than at parse time.

For example, early forms of BASIC did not include escape sequences or any other workarounds listed here, and thus one instead was required to use the CHR$ function, which returns a string containing the character corresponding to its argument. In ASCII the quotation mark has the value 34, so to represent a string with quotes on an ASCII system one would write

"I said, " + CHR$(34) + "Can you hear me?" + CHR$(34)

In C, a similar facility is available via sprintf and the %c "character" format specifier, though in the presence of other workarounds this is generally not used:

char buffer[32];
snprintf(buffer, sizeof buffer, "This is %cin quotes.%c", 34, 34);

These constructor functions can also be used to represent nonprinting characters, though escape sequences are generally used instead. A similar technique can be used in C++ with the std::string stringification operator.

When code in one programming language is embedded inside another, embedded strings may require multiple levels of escaping. This is particularly common in regular expressions and SQL query within other languages, or other languages inside shell scripts. This double-escaping is often difficult to read and author.

Incorrect quoting of nested strings can present a security vulnerability. Use of untrusted data, as in data fields of an SQL query, should use prepared statements to prevent a code injection attack. In PHP 2 through 5.3, there was a feature called magic quotes which automatically escaped strings (for convenience and security), but due to problems was removed from version 5.4 onward.

A few languages provide a method of specifying that a literal is to be processed without any language-specific interpretation. This avoids the need for escaping, and yields more legible strings.

Raw strings are particularly useful when a common character needs to be escaped, notably in regular expressions (nested as string literals), where backslash \ is widely used, and in DOS/Windows paths, where backslash is used as a path separator. The profusion of backslashes is known as leaning toothpick syndrome, and can be reduced by using raw strings. Compare escaped and raw pathnames in C#:

 "The Windows path is C:\\Foo\\Bar\\Baz\\"
 @"The Windows path is C:\Foo\Bar\Baz\"

Extreme examples occur when these are combined – Uniform Naming Convention paths begin with \\, and thus an escaped regular expression matching a UNC name begins with 8 backslashes, "\\\\\\\\", due to needing to escape the string and the regular expression. Using raw strings reduces this to 4 (escaping in the regular expression), as in C# @"\\\\".

In XML documents, CDATA sections allows use of characters such as & and < without an XML parser attempting to interpret them as part of the structure of the document itself. This can be useful when including literal text and scripting code, to keep the document well formed.

<![CDATA[  if (path!=null && depth<2) { add(path); }  ]]>

In C, where the concept and term originate, string literal concatenation was introduced for two reasons:[17]

• To allow long strings to span multiple lines with proper indentation in contrast to line continuation, which destroys the indentation scheme; and
• To allow the construction of string literals by macros (via stringizing).[18]

In practical terms, this allows string concatenation in early phases of compilation ("translation", specifically as part of lexical analysis), without requiring phrase analysis or constant folding. For example, the following are valid C/C++:

char *s = "hello, " "world";
printf("hello, " "world");

However, the following are invalid:

char *s = "hello, " + "world";
printf("hello, " + "world");

This is because string literals have array type, char [n] (C) or const char [n] (C++), which cannot be added; this is not a restriction in most other languages.

This is particularly important when used in combination with the C preprocessor, to allow strings to be computed following preprocessing, particularly in macros.[14] As a simple example:

char *file_and_message = __FILE__ ": message";

will (if the file is called a.c) expand to:

char *file_and_message = "a.c" ": message";

which is then concatenated, being equivalent to:

char *file_and_message = "a.c: message";

A common use case is in constructing printf or scanf format strings, where format specifiers are given by macros.[19][20]

A more complex example uses stringification of integers (by the preprocessor) to define a macro that expands to a sequence of string literals, which are then concatenated to a single string literal with the file name and line number:[21]

#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
#define AT __FILE__ ":" TOSTRING(__LINE__)

Beyond syntactic requirements of C/C++, implicit concatenation is a form of syntactic sugar, making it simpler to split string literals across several lines, avoiding the need for line continuation (via backslashes) and allowing one to add comments to parts of strings. For example, in Python, one can comment a regular expression in this way:[22]

re.compile("[A-Za-z_]"       # letter or underscore
           "[A-Za-z0-9_]*"   # letter, digit or underscore
          )

Implicit string concatenation is not required by modern compilers, which implement constant folding, and causes hard-to-spot errors due to unintentional concatenation from omitting a comma, particularly in vertical lists of strings, as in:

l = ['foo',
     'bar'
     'zork']

Accordingly, it is not used in most languages, and it has been proposed for deprecation from D[23] and Python.[14] However, removing the feature breaks backwards compatibility, and replacing it with a concatenation operator introduces issues of precedence – string literal concatenation occurs during lexing, prior to operator evaluation, but concatenation via an explicit operator occurs at the same time as other operators, hence precedence is an issue, potentially requiring parentheses to ensure desired evaluation order.

A subtler issue is that in C and C++,[24] there are different types of string literals, and concatenation of these has implementation-defined behavior, which poses a potential security risk.[25]