Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85644 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2022-07-26 07:57 +0000 |
| Last post | 2022-07-27 15:38 -0700 |
| Articles | 4 on this page of 24 — 8 participants |
Back to article view | Back to comp.lang.c++
Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 07:57 +0000
Re: Is a char array initializer a "string literal"? Muttley@dastardlyhq.com - 2022-07-26 08:03 +0000
Re: Is a char array initializer a "string literal"? Öö Tiib <ootiib@hot.ee> - 2022-07-26 01:51 -0700
Re: Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 10:07 +0000
Re: Is a char array initializer a "string literal"? Öö Tiib <ootiib@hot.ee> - 2022-07-26 05:10 -0700
Re: Is a char array initializer a "string literal"? Öö Tiib <ootiib@hot.ee> - 2022-07-26 06:18 -0700
Re: Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 16:03 +0000
Re: Is a char array initializer a "string literal"? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-07-26 18:18 +0200
Re: Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-27 07:40 +0000
Re: Is a char array initializer a "string literal"? Öö Tiib <ootiib@hot.ee> - 2022-07-27 01:17 -0700
Re: Is a char array initializer a "string literal"? Bo Persson <bo@bo-persson.se> - 2022-07-26 11:11 +0200
Re: Is a char array initializer a "string literal"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-26 02:30 -0700
Re: Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 10:19 +0000
Re: Is a char array initializer a "string literal"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 12:03 -0700
Re: Is a char array initializer a "string literal"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-27 01:56 -0700
Re: Is a char array initializer a "string literal"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-27 11:02 -0700
Re: Is a char array initializer a "string literal"? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-07-26 11:36 +0200
Re: Is a char array initializer a "string literal"? Juha Nieminen <nospam@thanks.invalid> - 2022-07-26 10:22 +0000
Re: Is a char array initializer a "string literal"? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-07-26 16:50 +0200
Re: Is a char array initializer a "string literal"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 12:13 -0700
Re: Is a char array initializer a "string literal"? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-07-26 17:56 -0700
Re: Is a char array initializer a "string literal"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 19:24 -0700
Re: Is a char array initializer a "string literal"? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-07-27 13:05 -0700
Re: Is a char array initializer a "string literal"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-27 15:38 -0700
Page 2 of 2 — ← Prev page 1 [2]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-07-26 17:56 -0700 |
| Message-ID | <tbq2gk$2a4ok$1@dont-email.me> |
| In reply to | #85644 |
On 7/26/2022 12:57 AM, Juha Nieminen wrote: > In another forum I was discussing string literals and char arrays. > During the conversation this question occurred to me: > In an array initialization like this: > > char str[] = "hello"; > > can that "hello" even be considered a "string literal", or should it > be classified as something else? Yes, it is a string literal. I.e. formally it is an independent object with static storage duration, independent and separate from `str` in your example. > The question arose because an (actual) string literal has a type of > array-of-const-char (of a size needed to store the contents of the > string literal). So for example the type of "hello" is const char[6]. > > However, you can't initialize an array with another array. But you _can_ initialize a char array with a string literal. A special exception is deliberately made for this specific case in C and C++ standards. They explicitly state that you _can_ initialize a char array with a string literal and explicitly specify the semantics of such initialization. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-26 19:24 -0700 |
| Message-ID | <87k07zxpgg.fsf@nosuchdomain.example.com> |
| In reply to | #85672 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 7/26/2022 12:57 AM, Juha Nieminen wrote:
>> In another forum I was discussing string literals and char arrays.
>> During the conversation this question occurred to me:
>> In an array initialization like this:
>> char str[] = "hello";
>> can that "hello" even be considered a "string literal", or should it
>> be classified as something else?
>
> Yes, it is a string literal. I.e. formally it is an independent object
> with static storage duration, independent and separate from `str` in
> your example.
It is a string literal, i.e., it is a source code token starting and
ending with a '"' character. The corresponding object with static
storage duration is not a string literal. It doesn't exist until
execution time.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-07-27 13:05 -0700 |
| Message-ID | <tbs5qm$2k527$1@dont-email.me> |
| In reply to | #85673 |
On 7/26/2022 7:24 PM, Keith Thompson wrote: > Andrey Tarasevich <andreytarasevich@hotmail.com> writes: >> On 7/26/2022 12:57 AM, Juha Nieminen wrote: >>> In another forum I was discussing string literals and char arrays. >>> During the conversation this question occurred to me: >>> In an array initialization like this: >>> char str[] = "hello"; >>> can that "hello" even be considered a "string literal", or should it >>> be classified as something else? >> >> Yes, it is a string literal. I.e. formally it is an independent object >> with static storage duration, independent and separate from `str` in >> your example. > > It is a string literal, i.e., it is a source code token starting and > ending with a '"' character. The corresponding object with static > storage duration is not a string literal. It doesn't exist until > execution time. No. The distinctions is there, but it is different. While it is true that the standard text differentiates between lexical/grammatical `string-literal` (hyphenated) and "string literal object", the former is generally treated as an expression, not as a mere token in source code. For example, in 7.5.1: "[...] A string-literal is an lvalue. [...]". A "string literal" is an expression that evaluates to a "string literal object". Also, Note 7 on 5.13.5 (admittedly non-normative) goes as far as stating "The effect of attempting to modify a string-literal is undefined." I hope you understand that this not not an attempt to dissuade us from modifying the source code of our programs. These nothing wrong with taking the same terminological liberties in a Usenet discussion. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-27 15:38 -0700 |
| Message-ID | <87zgguw59u.fsf@nosuchdomain.example.com> |
| In reply to | #85704 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 7/26/2022 7:24 PM, Keith Thompson wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>> On 7/26/2022 12:57 AM, Juha Nieminen wrote:
>>>> In another forum I was discussing string literals and char arrays.
>>>> During the conversation this question occurred to me:
>>>> In an array initialization like this:
>>>> char str[] = "hello";
>>>> can that "hello" even be considered a "string literal", or should it
>>>> be classified as something else?
>>>
>>> Yes, it is a string literal. I.e. formally it is an independent object
>>> with static storage duration, independent and separate from `str` in
>>> your example.
>> It is a string literal, i.e., it is a source code token starting and
>> ending with a '"' character. The corresponding object with static
>> storage duration is not a string literal. It doesn't exist until
>> execution time.
>
> No. The distinctions is there, but it is different.
I don't think it's different.
> While it is true that the standard text differentiates between
> lexical/grammatical `string-literal` (hyphenated) and "string literal
> object", the former is generally treated as an expression, not as a
> mere token in source code. For example, in 7.5.1: "[...] A
> string-literal is an lvalue. [...]".
It's a token and it's an expression. "A *literal* is a primary
expression" [expr.prim.literal].
> A "string literal" is an expression that evaluates to a "string
> literal object".
Yes. How does that disagree with what I wrote? (A string literal
object is not a string literal.)
> Also, Note 7 on 5.13.5 (admittedly non-normative) goes as far as
> stating "The effect of attempting to modify a string-literal is
> undefined." I hope you understand that this not not an attempt to
> dissuade us from modifying the source code of our programs.
Yes. It would have been more precise to say that "The effect of
attempting to modify a string literal object is undefined." The current
wording is informal, and I don't have a huge problem with it.
> These nothing wrong with taking the same terminological liberties in a
> Usenet discussion.
Unless the point of confusion in the original post is precisely the
distinction I pointed out.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.c++
csiph-web