Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85644 > unrolled thread

Is a char array initializer a "string literal"?

Back to article view | Back to comp.lang.c++

Contents

  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 1 of 2  [1] 2  Next page →

#85644 — Is a char array initializer a "string literal"?

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?

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. Given that
fact, that would mean that the "hello" in

    char str[] = "hello";

is not a const char[6] (because you can't initialize 'str' with one).
It's something else. In fact, the above is essentially just syntactic
sugar for:

    char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' };

Thus, should that "hello", in this context, be considered an initializer
list rather than a "string literal"?

(Yes, I wouldn't be surprised if the standard still calls it a "string
literal". But even standards are flawed and ambiguous sometimes. No
standard is absolutely perfect.)

[toc] | [next] | [standalone]

#85646

On Tue, 26 Jul 2022 07:57:32 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> 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?

Its a literal and its a string. 

On a side note its interesting how many people don't know the critical
difference between

char str[] = "hello";

and

char *str = "hello";

in C and C++.

[toc] | [prev] | [next] | [standalone]

#85648

On Tuesday, 26 July 2022 at 10:57:48 UTC+3, 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? 
> 
> 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. Given that 
> fact, that would mean that the "hello" in 
> 
> char str[] = "hello"; 
> 
> is not a const char[6] (because you can't initialize 'str' with one). 
> It's something else. In fact, the above is essentially just syntactic 
> sugar for: 
> 
> char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' }; 
> 
> Thus, should that "hello", in this context, be considered an initializer 
> list rather than a "string literal"?

No. One is string literal used in array initialization (special case for 
character and wide character arrays) other is array initialization from
brace enclosed list. Both are also aggregate initializations as 
characters are aggregates. 

The C++ has about dozen ways how to initialize something and lot
of those are made to have confusingly similar syntax (that is the
dreaded "uniform" initialization) so being sometimes confused is
unavoidable. Just design classes in a way that only narrow subset
is usable.  

> 
> (Yes, I wouldn't be surprised if the standard still calls it a "string 
> literal". But even standards are flawed and ambiguous sometimes. No 
> standard is absolutely perfect.)

The str there is not string literal in neither case and you have no ways
to interact with the "hello" before or after of that initialization so it is
hard to see how it can be different from string literal by as-if rule. I
have never had issue of it not behaving like string literal is promised
to behave in said context. 
   

[toc] | [prev] | [next] | [standalone]

#85653

Öö Tiib <ootiib@hot.ee> wrote:
> The str there is not string literal in neither case and you have no ways
> to interact with the "hello" before or after of that initialization so it is
> hard to see how it can be different from string literal by as-if rule.

By the fact that a string literal is of type array-of-const-char, and that
you can't initialize an array with another array (even if it's a temporary).

If you, for example, print the value of sizeof("hello"), you'll get 6 as
the answer because "hello" is of type const char[6]. But quite clearly
it is not in:

    char str[] = "hello";

because you can't initialize an array with an array.

OTOH, perhaps I'm approaching this completely incorrectly. Perhaps
"string literal" shouldn't be interpreted as "a literal that's an
array of const char".

Instead, perhaps it should be thought of as: "The character
sequence '"hello"' appearing in the source code (after preprocessing)
is a string literal. How that string literal is interpreted by
the compiler depends on the particular context in which it appears.
Depending on the context it can be an array of const char, or an
array initializer list."

[toc] | [prev] | [next] | [standalone]

#85656

On Tuesday, 26 July 2022 at 13:08:08 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote: 
> > The str there is not string literal in neither case and you have no ways 
> > to interact with the "hello" before or after of that initialization so it is 
> > hard to see how it can be different from string literal by as-if rule.
> By the fact that a string literal is of type array-of-const-char, and that 
> you can't initialize an array with another array (even if it's a temporary). 

I am allowed by standard to initialize character array with string literal
(and wide character array with wide string literal).
  
> If you, for example, print the value of sizeof("hello"), you'll get 6 as 
> the answer because "hello" is of type const char[6]. But quite clearly 
> it is not in: 
> 
> char str[] = "hello"; 
> 
> because you can't initialize an array with an array. 

Third time I say that we are promised to by standard to be able to.
(First time was in previous reply).  Easiest is to see it in cppreference,
as its text is easier to read than that of standard and it is easily available
over net.
<https://en.cppreference.com/w/c/language/array_initialization>

> OTOH, perhaps I'm approaching this completely incorrectly. Perhaps 
> "string literal" shouldn't be interpreted as "a literal that's an 
> array of const char". 

I suspect you are treating initialization as assignment. Some of (all the
ways of) initialization look slightly like assignment. We can't assign or
pass array as value unless it is member of class ... but that does not 
regulate usage of string literals for initialization.

> Instead, perhaps it should be thought of as: "The character 
> sequence '"hello"' appearing in the source code (after preprocessing) 
> is a string literal. How that string literal is interpreted by 
> the compiler depends on the particular context in which it appears. 
> Depending on the context it can be an array of const char, or an 
> array initializer list."

No it is not initializer list. C++ can't be simplified much. It just has its
whole pile of different things in it of what some look confusingly
similar but are not. String literal and initializer list look very different
and are very different. For example:

auto str =  { 'h', 'e', 'l', 'l', 'o', '\0' };

That is required to result with str being  std::initializer_list<char>.

auto str = "hello";

That is required to result with str being char const *.

[toc] | [prev] | [next] | [standalone]

#85659

On Tuesday, 26 July 2022 at 15:10:12 UTC+3, Öö Tiib wrote:
>
> <https://en.cppreference.com/w/c/language/array_initialization>

Oops gave wrong page about C. The C++ is that
<https://en.cppreference.com/w/cpp/language/aggregate_initialization>
Scroll down to Character arrays.

[toc] | [prev] | [next] | [standalone]

#85664

Öö Tiib <ootiib@hot.ee> wrote:
> No it is not initializer list. C++ can't be simplified much. It just has its
> whole pile of different things in it of what some look confusingly
> similar but are not. String literal and initializer list look very different
> and are very different. For example:

Just because two things "look different" doesn't mean they are. One can
perfectly well be just syntactic sugar that means the same as the other.

> auto str =  { 'h', 'e', 'l', 'l', 'o', '\0' };
> 
> That is required to result with str being  std::initializer_list<char>.
> 
> auto str = "hello";
> 
> That is required to result with str being char const *.

Actually I think 'auto' in the last case will expand to char[6],
not const char*. That's because the type of "hello" is char[6].

[toc] | [prev] | [next] | [standalone]

#85665

On 26 Jul 2022 18:03, Juha Nieminen wrote:
> Öö Tiib <ootiib@hot.ee> wrote:
>> No it is not initializer list. C++ can't be simplified much. It just has its
>> whole pile of different things in it of what some look confusingly
>> similar but are not. String literal and initializer list look very different
>> and are very different. For example:
> 
> Just because two things "look different" doesn't mean they are. One can
> perfectly well be just syntactic sugar that means the same as the other.
> 
>> auto str =  { 'h', 'e', 'l', 'l', 'o', '\0' };
>>
>> That is required to result with str being  std::initializer_list<char>.
>>
>> auto str = "hello";
>>
>> That is required to result with str being char const *.
> 
> Actually I think 'auto' in the last case will expand to char[6],
> not const char*. That's because the type of "hello" is char[6].

`auto` on its own is roughly like `std::decay` of the initializer type, 
<url: https://en.cppreference.com/w/cpp/types/decay>,

arrays decay to pointers, functions decay to pointers, and top level 
const/volatile qualification is removed.

But if you make a reference `auto&`, then there must be a more exact 
match with the initializer type.


- Alf

[toc] | [prev] | [next] | [standalone]

#85676

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> `auto` on its own is roughly like `std::decay` of the initializer type, 
> <url: https://en.cppreference.com/w/cpp/types/decay>,
> 
> But if you make a reference `auto&`, then there must be a more exact 
> match with the initializer type.

Is there a good reason that they added such confusing needless complexity
to the keyword? What's the purpose of such inconsistent behavior?

[toc] | [prev] | [next] | [standalone]

#85678

On Wednesday, 27 July 2022 at 10:41:17 UTC+3, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.s...@gmail.com> wrote:
> > `auto` on its own is roughly like `std::decay` of the initializer type, 
> > <url: https://en.cppreference.com/w/cpp/types/decay>, 
> >
> > But if you make a reference `auto&`, then there must be a more exact 
> > match with the initializer type.
> Is there a good reason that they added such confusing needless complexity 
> to the keyword? What's the purpose of such inconsistent behavior?

They reused the rules of template argument deduction. I am not 100% sure
why but most likely it is because of hoped ease to learn and to implement
both when both are same.

Template argument is deduced from function call arguments.  To function
we can pass an array as argument but it will decay into pointer. We can take
reference to array but then also in template we need to indicate that the
parameter takes reference with that &.

[toc] | [prev] | [next] | [standalone]

#85649

On 2022-07-26 at 09:57, 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?
> 
> 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. Given that
> fact, that would mean that the "hello" in
> 
>      char str[] = "hello";
> 
> is not a const char[6] (because you can't initialize 'str' with one).
> It's something else. In fact, the above is essentially just syntactic
> sugar for:
> 
>      char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' };
> 
> Thus, should that "hello", in this context, be considered an initializer
> list rather than a "string literal"?
> 
> (Yes, I wouldn't be surprised if the standard still calls it a "string
> literal". But even standards are flawed and ambiguous sometimes. No
> standard is absolutely perfect.)

In the grammar "hello" is a string-literal (with a dash).

http://eel.is/c++draft/lex.string


You also have basic_string literals, with an s at the end - "hello"s.

http://eel.is/c++draft/basic.string.literals


Perhaps they are the real string literals?  ;-)

Or should we say std::string literals?

[toc] | [prev] | [next] | [standalone]

#85650

On Tuesday, 26 July 2022 at 08:57:48 UTC+1, 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? 
> 
> 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. Given that 
> fact, that would mean that the "hello" in 
> 
> char str[] = "hello"; 
> 
> is not a const char[6] (because you can't initialize 'str' with one). 
> It's something else. In fact, the above is essentially just syntactic 
> sugar for: 
> 
> char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' }; 
> 
> Thus, should that "hello", in this context, be considered an initializer 
> list rather than a "string literal"? 
> 
> (Yes, I wouldn't be surprised if the standard still calls it a "string 
> literal". But even standards are flawed and ambiguous sometimes. No 
> standard is absolutely perfect.)
>
C doesn't really have strings. It just has char arrays. Whilst strings are pretty
much always implemented as char arrays in any language, in most languages
you have a "string type", and you can copy, assign, concatenate and so on
with inbuilt language features. C doesn't do this.
The exception is that string literals (double quoted text in source code) are
allowed as special syntax for creating a string.

[toc] | [prev] | [next] | [standalone]

#85654

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> C doesn't really have strings. It just has char arrays. Whilst strings are pretty
> much always implemented as char arrays in any language, in most languages
> you have a "string type", and you can copy, assign, concatenate and so on
> with inbuilt language features. C doesn't do this.
> The exception is that string literals (double quoted text in source code) are
> allowed as special syntax for creating a string.

That's not really relevant to what I was asking.

Besides, the C standard calls then "strings" throughout. For example,
it says that the 'argv' value that the main() function gets is an array
of pointers to strings. On a particular curious note, in another part it
says:

"A character string literal need not be a string (see 7.1.1), because
a null character may be embedded in it by a \0 escape sequence."

7.1.1 defines: "A string is a contiguous sequence of characters
terminated by and including the first null character."

[toc] | [prev] | [next] | [standalone]

#85668

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> C doesn't really have strings.

Yes it does.

The C standard defines a "string" as "a contiguous sequence of
characters terminated by and including the first null character".

C has no string *type*, but it certainly does have strings.

(C++ has the same thing, but with different terminology.  And of course
C++ also has the type std::string.)

-- 
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]

#85679

On Tuesday, 26 July 2022 at 20:03:23 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> [...]
> > C doesn't really have strings.
> Yes it does. 
> 
> The C standard defines a "string" as "a contiguous sequence of
> characters terminated by and including the first null character".
> C has no string *type*, but it certainly does have strings. 
> 
The C standard uses a lot of words in a special way. Like "function".
"string" is another of those words. 

[toc] | [prev] | [next] | [standalone]

#85697

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 26 July 2022 at 20:03:23 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
>> [...]
>> > C doesn't really have strings.
>> Yes it does. 
>> 
>> The C standard defines a "string" as "a contiguous sequence of
>> characters terminated by and including the first null character".
>> C has no string *type*, but it certainly does have strings. 
>> 
> The C standard uses a lot of words in a special way. Like "function".
> "string" is another of those words. 

Yes, and when you refuse to acknowledge that the standard has its own
meanings for those words, you cause confusion.

It would help if you'd at least acknowledge in the first place that you
have your own meanings for words.

(Since this is comp.lang.c++, let's drop this.)

-- 
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]

#85651

On 26 Jul 2022 09:57, 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?
> 
> 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. Given that
> fact, that would mean that the "hello" in
> 
>      char str[] = "hello";
> 
> is not a const char[6] (because you can't initialize 'str' with one).
> It's something else. In fact, the above is essentially just syntactic
> sugar for:
> 
>      char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' };
> 
> Thus, should that "hello", in this context, be considered an initializer
> list rather than a "string literal"?
> 
> (Yes, I wouldn't be surprised if the standard still calls it a "string
> literal". But even standards are flawed and ambiguous sometimes. No
> standard is absolutely perfect.)

It's a string literal with all the rules of string literals, but there's 
a special case exception allowing this usage of initializing a `char` or 
other character type array; in this context it doesn't decay to pointer.

C++ requires that the array that's initialized is of sufficient size for 
the whole string including the zero-terminator, while C, in my opinion 
more practically oriented, does not require that.

When one is primarily concerned with not throwing away the compile time 
string size information one can just declare a reference, like

     const auto& str = "hello";

... or perhaps a `string_view`, which has `constexpr` construction,

     const string_view str = "hello";

Sadly, students are still taught to declare pointers as a way of naming 
string literals.

- Alf

[toc] | [prev] | [next] | [standalone]

#85655

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> When one is primarily concerned with not throwing away the compile time 
> string size information one can just declare a reference, like
> 
>     const auto& str = "hello";

Well, there's a quiz question if I ever saw one. What does 'auto' expand
to there?

Honestly, I wouldn't be certain without a bit further research or
testing.

[toc] | [prev] | [next] | [standalone]

#85661

On 26 Jul 2022 12:22, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>> When one is primarily concerned with not throwing away the compile time
>> string size information one can just declare a reference, like
>>
>>      const auto& str = "hello";
> 
> Well, there's a quiz question if I ever saw one. What does 'auto' expand
> to there?
> 
> Honestly, I wouldn't be certain without a bit further research or
> testing.

It's a reference to the array.

- Alf

[toc] | [prev] | [next] | [standalone]

#85669

Juha Nieminen <nospam@thanks.invalid> writes:
> 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?

It's a string literal.

A string literal is a syntactic construct, a sequence of characters
in a source file.  "hello" unquestionably meets the definition of
*string-literal* given in the C++ grammar.

A char array is an object that can exist during program execution.

> 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].

Yes.

> However, you can't initialize an array with another array. Given that
> fact, that would mean that the "hello" in
>
>     char str[] = "hello";
>
> is not a const char[6] (because you can't initialize 'str' with one).

There's a specific rule that allows a char array to be initialized with
a string literal.  See [dcl.init.string] in the standard.

The string literal "hello" is always of type `const char[6]`.
In most contexts, it "decays" to a pointer expression of type `const
char*` which evaluates to the address of the initial character
of the array.  A string literal used as an initializer for a
character array object is one of the exceptions, where it does not
"decay".  The array value is used to initialize the array object.
(Another exception is the operand of `sizeof`.)

> It's something else. In fact, the above is essentially just syntactic
> sugar for:
>
>     char str[] = { 'h', 'e', 'l', 'l', 'o', '\0' };
>
> Thus, should that "hello", in this context, be considered an initializer
> list rather than a "string literal"?

No, it's a string literal.  The fact that it happens to be equivalent to
some other syntactic construct does not change that fact.

> (Yes, I wouldn't be surprised if the standard still calls it a "string
> literal". But even standards are flawed and ambiguous sometimes. No
> standard is absolutely perfect.)

Yes, standards are flawed and ambiguous, but this is not a flaw or an
ambiguity.

-- 
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]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web