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

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

A string pointer to a static or dynamic string : how to free the dynamic one ?

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

Contents

  A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-21 15:28 +0100
    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-21 16:40 +0200
      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-21 15:57 +0100
      Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-21 16:20 +0000
        Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-21 20:15 +0200
          Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 09:25 +0000
            Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 12:11 +0200
              Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 10:14 +0000
                Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 14:14 +0200
                  Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 12:27 +0000
                    Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 17:56 +0200
                      Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 16:11 +0000
                        Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 18:58 +0200
                          Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 17:18 +0000
                            Re: A string pointer to a static or dynamic string : how to free the Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 19:49 +0200
            Re: A string pointer to a static or dynamic string : how to free the Cholo Lennon <chololennon@hotmail.com> - 2023-01-23 16:44 -0300
              Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-24 17:05 +0000
        Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-21 19:30 +0100
          Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 09:30 +0000
            Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 13:53 +0100
              Re: A string pointer to a static or dynamic string : how to free the scott@slp53.sl.home (Scott Lurndal) - 2023-01-23 14:46 +0000
                Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 16:48 +0100
                  Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 16:09 +0000
                    Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 17:13 +0100
              Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 16:20 +0000
                Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 17:25 +0100
                  Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 16:37 +0000
                    Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 17:40 +0100
                      Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 17:00 +0000
                        Re: A string pointer to a static or dynamic string : how to free the Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2023-01-23 20:07 +0100
                  Re: A string pointer to a static or dynamic string : how to free the scott@slp53.sl.home (Scott Lurndal) - 2023-01-23 17:30 +0000
                    Re: A string pointer to a static or dynamic string : how to free the Bonita Montero <Bonita.Montero@gmail.com> - 2023-01-23 18:39 +0100
                Re: A string pointer to a static or dynamic string : how to free the "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-01-23 08:40 -0800
                  Re: A string pointer to a static or dynamic string : how to free the Muttley@dastardlyhq.com - 2023-01-23 17:02 +0000
      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Juha Nieminen <nospam@thanks.invalid> - 2023-01-23 06:34 +0000
        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-23 12:49 +0200
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Juha Nieminen <nospam@thanks.invalid> - 2023-01-23 11:51 +0000
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-23 04:05 -0800
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? wij <wyniijj5@gmail.com> - 2023-01-23 04:45 -0800
    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Richard Damon <Richard@Damon-Family.org> - 2023-01-21 10:13 -0500
      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-21 17:53 +0100
    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-21 08:04 -0800
      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-21 16:54 -0800
        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-22 10:46 +0100
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 05:20 -0500
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-22 12:17 +0100
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Bo Persson <bo@bo-persson.se> - 2023-01-22 12:29 +0100
                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-22 13:23 +0100
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-22 14:53 +0200
                    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-22 19:04 +0100
                      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-22 19:16 +0100
                        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 09:46 +0100
                          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? jak <nospam@please.ty> - 2023-01-23 13:22 +0100
                            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 14:42 +0100
                              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-23 06:15 -0800
                                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-01-23 08:22 -0800
                                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 18:02 +0100
                                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-23 11:14 -0800
                                    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-01-23 11:38 -0800
                                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 13:26 -0800
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Richard Damon <Richard@Damon-Family.org> - 2023-01-22 13:24 -0500
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 11:00 -0800
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 15:39 -0500
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 15:28 -0500
        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 12:27 +0100
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Öö Tiib <ootiib@hot.ee> - 2023-01-22 03:42 -0800
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-22 15:31 +0100
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 15:40 +0100
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Richard Damon <Richard@Damon-Family.org> - 2023-01-22 13:24 -0500
                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-22 11:46 -0800
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 10:24 +0100
                    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? scott@slp53.sl.home (Scott Lurndal) - 2023-01-23 14:44 +0000
                      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-23 07:34 -0800
                      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 18:05 +0100
                        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-23 09:37 -0800
                        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? scott@slp53.sl.home (Scott Lurndal) - 2023-01-23 17:37 +0000
                Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 21:16 +0100
                  Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 13:07 -0800
                    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-23 08:33 +0100
                      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-23 04:00 -0500
                      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 12:34 -0800
                        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-02 06:43 -0800
                          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-02 16:36 -0800
                            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-02 17:38 -0800
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 10:57 -0800
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 21:23 +0100
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 15:47 -0500
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-23 08:04 +0100
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-23 04:13 -0500
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? David Brown <david.brown@hesbynett.no> - 2023-01-23 10:33 +0100
    Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2023-01-21 18:29 +0000
      Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-21 20:09 +0100
        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Richard Damon <Richard@Damon-Family.org> - 2023-01-21 16:32 -0500
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 10:52 +0100
        Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2023-01-21 22:10 +0000
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 11:56 +0100
            Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-01-22 14:31 +0200
              Re: A string pointer to a static or dynamic string : how to free the dynamic one ? "R.Wieser" <address@not.available> - 2023-01-22 15:57 +0100
          Re: A string pointer to a static or dynamic string : how to free the dynamic one ? Juha Nieminen <nospam@thanks.invalid> - 2023-01-23 06:40 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#88689

"Richard Damon" <Richard@Damon-Family.org> wrote in message 
news:KiTyL.760492$GNG9.106194@fx18.iad...
> On 1/21/23 9:28 AM, R.Wieser wrote:

>>    char* message = "hello world";
>>    char* message = strdup("hello world");
...
>> The problem is that the dynamic one needs to be "free"d but tyhe static 
>> one
>> not.   How do I look at that "message" pointer whats "in" it so I can 
>> take
>> the correct action.

> There is no portable way of telling.

I was already afraid of that.

Regards,
Rudy Wieser

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

#88682

On Saturday, 21 January 2023 at 14:28:24 UTC, R.Wieser wrote:
> Hello all, 
> 
> I'm a rather newbie to C++ programming who is trying figure out how to deal 
> with string pointers - or rather, with what they point at. 
> 
> Case in point : 
> 
> char* message = "hello world"; 
> char* message = strdup("hello world"); 
> 
> I can user either of those in a function and return the pointer, and the 
> caller will be none-the-wiser which form (the static or dymnamic string) it 
> gets. 
> 
> The problem is that the dynamic one needs to be "free"d but tyhe static one 
> not. How do I look at that "message" pointer whats "in" it so I can take 
> the correct action. 
> 
> By the way: the same thing goes for when I want to replace a string. I don't 
> think that C++ has a garbage-collector running, so I need to do it myself. 
> :-) 
> 
It's a mess, and a hangover from C. C tresats string as character pointers,
and doesn't give you an easy way to tell if they are allocated on the heap, on
the stack, or in read-only memory. So the C programmer has to be careful.

In C++ there is a std::string. Normally when you are using C++, you should make
sure that all strings are turned into std::strings at the earliest opportunity. 
Becasue of the magic of destructors, you then needn't worry about the memory the
string points to.
An std::string can be assigned like a variable. Which is frequently useful.
Assignment is relatively expensive because it tends to involve an allocation
and a copy, but it's rare for string assignment to be a time critical step.

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

#88699

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It's a mess, and a hangover from C. C tresats string as character pointers,

No, a C string is by definition "a contiguous sequence of characters
terminated by and including the first null character".  It is not a
pointer.

A *pointer to a string* is by definition "a pointer to its initial
(lowest addressed) character".  Most manipulation of strings in C is
done via string pointers.

> and doesn't give you an easy way to tell if they are allocated on the heap, on
> the stack, or in read-only memory. So the C programmer has to be careful.

Right.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#88700

Il 22/01/2023 01:54, Keith Thompson ha scritto:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>> It's a mess, and a hangover from C. C tresats string as character pointers,
> 
> No, a C string is by definition "a contiguous sequence of characters
> terminated by and including the first null character".  It is not a
> pointer.
> 
> A *pointer to a string* is by definition "a pointer to its initial
> (lowest addressed) character".  Most manipulation of strings in C is
> done via string pointers.
> 
>> and doesn't give you an easy way to tell if they are allocated on the heap, on
>> the stack, or in read-only memory. So the C programmer has to be careful.
> 
> Right.
> 

pointer to a string? by definition? string pointers? Maybe you are
confusing programming languages. The C language has no string pointers.

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

#88701

On 1/22/23 04:46, jak wrote:
> Il 22/01/2023 01:54, Keith Thompson ha scritto:
...
>> A *pointer to a string* is by definition "a pointer to its initial
>> (lowest addressed) character".  Most manipulation of strings in C is
>> done via string pointers.
...> pointer to a string? by definition? string pointers? Maybe you are
> confusing programming languages. The C language has no string pointers.

When he said "by definition", he meant it:

"A _pointer to a string_ is a pointer to its initial (lowest addressed)
character." (C standard (n2731) 7.1.1p1).

The phrase "pointer to a string" is in italics, an ISO convention
indicating that the sentence in which that phrase occurs constitutes the
official definition of the meaning of that term.

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

#88702

Il 22/01/2023 11:20, James Kuyper ha scritto:
> On 1/22/23 04:46, jak wrote:
>> Il 22/01/2023 01:54, Keith Thompson ha scritto:
> ...
>>> A *pointer to a string* is by definition "a pointer to its initial
>>> (lowest addressed) character".  Most manipulation of strings in C is
>>> done via string pointers.
> ...> pointer to a string? by definition? string pointers? Maybe you are
>> confusing programming languages. The C language has no string pointers.
> 
> When he said "by definition", he meant it:
> 
> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
> character." (C standard (n2731) 7.1.1p1).
>

"pointer to a string" could be a pointer at the first element of an 
array that contains a string, perhaps. You argue a lot about the 
definitions contained in the "ISO", perhaps the writers should be 
convinced to use greater precision.

 >
> The phrase "pointer to a string" is in italics, an ISO convention
> indicating that the sentence in which that phrase occurs constitutes the
> official definition of the meaning of that term.
> 

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

#88706

On 2023-01-22 at 12:17, jak wrote:
> Il 22/01/2023 11:20, James Kuyper ha scritto:
>> On 1/22/23 04:46, jak wrote:
>>> Il 22/01/2023 01:54, Keith Thompson ha scritto:
>> ...
>>>> A *pointer to a string* is by definition "a pointer to its initial
>>>> (lowest addressed) character".  Most manipulation of strings in C is
>>>> done via string pointers.
>> ...> pointer to a string? by definition? string pointers? Maybe you are
>>> confusing programming languages. The C language has no string pointers.
>>
>> When he said "by definition", he meant it:
>>
>> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
>> character." (C standard (n2731) 7.1.1p1).
>>
> 
> "pointer to a string" could be a pointer at the first element of an 
> array that contains a string, perhaps. 

No, not "perhaps", but definitely. The term "pointer to a string" IS a 
pointer to the first element of an array that contains a string. That's 
what it says.

There are other pointers that can point to a char that is not part of a 
string. Those are then not "pointer to a string".

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

#88708

Il 22/01/2023 12:29, Bo Persson ha scritto:
> On 2023-01-22 at 12:17, jak wrote:
>> Il 22/01/2023 11:20, James Kuyper ha scritto:
>>> On 1/22/23 04:46, jak wrote:
>>>> Il 22/01/2023 01:54, Keith Thompson ha scritto:
>>> ...
>>>>> A *pointer to a string* is by definition "a pointer to its initial
>>>>> (lowest addressed) character".  Most manipulation of strings in C is
>>>>> done via string pointers.
>>> ...> pointer to a string? by definition? string pointers? Maybe you are
>>>> confusing programming languages. The C language has no string pointers.
>>>
>>> When he said "by definition", he meant it:
>>>
>>> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
>>> character." (C standard (n2731) 7.1.1p1).
>>>
>>
>> "pointer to a string" could be a pointer at the first element of an 
>> array that contains a string, perhaps. 
> 
> No, not "perhaps", but definitely. The term "pointer to a string" IS a 
> pointer to the first element of an array that contains a string. That's 
> what it says.
> 
> There are other pointers that can point to a char that is not part of a 
> string. Those are then not "pointer to a string".
> 
> 

ISO standard can cancel that definition because the C does not have
strings but only an agreement that allows the functions to use array as
strings.

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

#88711

22.01.2023 14:23 jak kirjutas:
> Il 22/01/2023 12:29, Bo Persson ha scritto:
>> No, not "perhaps", but definitely. The term "pointer to a string" IS a 
>> pointer to the first element of an array that contains a string. 
>> That's what it says.
>>
>> There are other pointers that can point to a char that is not part of 
>> a string. Those are then not "pointer to a string".
>>
>>
> 
> ISO standard can cancel that definition because the C does not have
> strings but only an agreement that allows the functions to use array as
> strings.

ISO standard defines what C is or is not. It's not up to a random 
internet commenter.

Of course ISO standard committee can change the wording in the next 
version. If they do this and drop the definition of the term "pointer to 
a string" from the next C standard, then C will not have such thing any 
more. But until then it does.

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

#88715

Il 22/01/2023 13:53, Paavo Helde ha scritto:
> 22.01.2023 14:23 jak kirjutas:
>> Il 22/01/2023 12:29, Bo Persson ha scritto:
>>> No, not "perhaps", but definitely. The term "pointer to a string" IS 
>>> a pointer to the first element of an array that contains a string. 
>>> That's what it says.
>>>
>>> There are other pointers that can point to a char that is not part of 
>>> a string. Those are then not "pointer to a string".
>>>
>>>
>>
>> ISO standard can cancel that definition because the C does not have
>> strings but only an agreement that allows the functions to use array as
>> strings.
> 
> ISO standard defines what C is or is not. It's not up to a random 
> internet commenter.
> 
> Of course ISO standard committee can change the wording in the next 
> version. If they do this and drop the definition of the term "pointer to 
> a string" from the next C standard, then C will not have such thing any 
> more. But until then it does.
> 
> 
The comments are feedback. Feedback helps. Faith sometimes kills.

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

#88716

Il 22/01/2023 19:04, jak ha scritto:
> Il 22/01/2023 13:53, Paavo Helde ha scritto:
>> 22.01.2023 14:23 jak kirjutas:
>>> Il 22/01/2023 12:29, Bo Persson ha scritto:
>>>> No, not "perhaps", but definitely. The term "pointer to a string" IS 
>>>> a pointer to the first element of an array that contains a string. 
>>>> That's what it says.
>>>>
>>>> There are other pointers that can point to a char that is not part 
>>>> of a string. Those are then not "pointer to a string".
>>>>
>>>>
>>>
>>> ISO standard can cancel that definition because the C does not have
>>> strings but only an agreement that allows the functions to use array as
>>> strings.
>>
>> ISO standard defines what C is or is not. It's not up to a random 
>> internet commenter.
>>
>> Of course ISO standard committee can change the wording in the next 
>> version. If they do this and drop the definition of the term "pointer 
>> to a string" from the next C standard, then C will not have such thing 
>> any more. But until then it does.
>>
>>
> The comments are feedback. Feedback helps. Faith sometimes kills.
> 

... I thought about what happens in the Middle East. Faith is faith and
the laws are laws but what is written is not always right.

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

#88733

On 22/01/2023 19:16, jak wrote:
> Il 22/01/2023 19:04, jak ha scritto:
>> Il 22/01/2023 13:53, Paavo Helde ha scritto:
>>> 22.01.2023 14:23 jak kirjutas:
>>>> Il 22/01/2023 12:29, Bo Persson ha scritto:
>>>>> No, not "perhaps", but definitely. The term "pointer to a string" 
>>>>> IS a pointer to the first element of an array that contains a 
>>>>> string. That's what it says.
>>>>>
>>>>> There are other pointers that can point to a char that is not part 
>>>>> of a string. Those are then not "pointer to a string".
>>>>>
>>>>>
>>>>
>>>> ISO standard can cancel that definition because the C does not have
>>>> strings but only an agreement that allows the functions to use array as
>>>> strings.
>>>
>>> ISO standard defines what C is or is not. It's not up to a random 
>>> internet commenter.
>>>
>>> Of course ISO standard committee can change the wording in the next 
>>> version. If they do this and drop the definition of the term "pointer 
>>> to a string" from the next C standard, then C will not have such 
>>> thing any more. But until then it does.
>>>
>>>
>> The comments are feedback. Feedback helps. Faith sometimes kills.
>>

<snip>

(This is a technical language group - please don't bring any kind of 
political or religious issues into it, even if you think they are 
analogous or illustrative.  People get too worked up.)


You can comment all you like on the C and C++ standards, but those are 
what /define/ the languages.  Implementations follow those standards - 
often with extensions, variations and small non-conformities, but still 
basically following the standards.  Books, courses, and tutorials (at 
least those of any quality) primarily follow the terminology and 
definitions from the standards.

The standards are what give us our common language.  They let someone 
call themselves a "C programmer", and let him or her write code that 
will compile on a "C compiler".  They let people write a new C compiler 
for a new processor, and know people can use existing C code on it. 
They let people have technical language discussions in a group like this 
and know what each other is talking about.

So when someone talks about "C strings" or "strings in C", we all know 
what is meant - the standards tell us.  When someone says "this C 
function takes a string pointer", we know what it means.  It doesn't 
matter that a "C string" is different from a "C++ std::string" or a 
"BASIC string" or a "piece of string", as long as the context is clear.


(C++ standards are a bit more complicated than C standards, since there 
are bigger differences between the versions, but the same principles apply.)

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

#88747

Il 23/01/2023 09:46, David Brown ha scritto:
> On 22/01/2023 19:16, jak wrote:
>> Il 22/01/2023 19:04, jak ha scritto:
>>> Il 22/01/2023 13:53, Paavo Helde ha scritto:
>>>> 22.01.2023 14:23 jak kirjutas:
>>>>> Il 22/01/2023 12:29, Bo Persson ha scritto:
>>>>>> No, not "perhaps", but definitely. The term "pointer to a string" 
>>>>>> IS a pointer to the first element of an array that contains a 
>>>>>> string. That's what it says.
>>>>>>
>>>>>> There are other pointers that can point to a char that is not part 
>>>>>> of a string. Those are then not "pointer to a string".
>>>>>>
>>>>>>
>>>>>
>>>>> ISO standard can cancel that definition because the C does not have
>>>>> strings but only an agreement that allows the functions to use 
>>>>> array as
>>>>> strings.
>>>>
>>>> ISO standard defines what C is or is not. It's not up to a random 
>>>> internet commenter.
>>>>
>>>> Of course ISO standard committee can change the wording in the next 
>>>> version. If they do this and drop the definition of the term 
>>>> "pointer to a string" from the next C standard, then C will not have 
>>>> such thing any more. But until then it does.
>>>>
>>>>
>>> The comments are feedback. Feedback helps. Faith sometimes kills.
>>>
> 
> <snip>
> 
> (This is a technical language group - please don't bring any kind of 
> political or religious issues into it, even if you think they are 
> analogous or illustrative.  People get too worked up.)
> 
> 
> You can comment all you like on the C and C++ standards, but those are 
> what /define/ the languages.  Implementations follow those standards - 
> often with extensions, variations and small non-conformities, but still 
> basically following the standards.  Books, courses, and tutorials (at 
> least those of any quality) primarily follow the terminology and 
> definitions from the standards.
> 
> The standards are what give us our common language.  They let someone 
> call themselves a "C programmer", and let him or her write code that 
> will compile on a "C compiler".  They let people write a new C compiler 
> for a new processor, and know people can use existing C code on it. They 
> let people have technical language discussions in a group like this and 
> know what each other is talking about.
> 
> So when someone talks about "C strings" or "strings in C", we all know 
> what is meant - the standards tell us.  When someone says "this C 
> function takes a string pointer", we know what it means.  It doesn't 
> matter that a "C string" is different from a "C++ std::string" or a 
> "BASIC string" or a "piece of string", as long as the context is clear.
> 
> 
> (C++ standards are a bit more complicated than C standards, since there 
> are bigger differences between the versions, but the same principles 
> apply.)
> 
> 
> 
hi David,
I have read your comments on these groups for a few years and I have an
excellent opinion about you but this time I have the impression that you
have read this branch of the thread with poor attention. Please read
more carefully the statement I replied.

Always with respect, Jak.

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

#88752

On 23/01/2023 13:22, jak wrote:
> Il 23/01/2023 09:46, David Brown ha scritto:
>> On 22/01/2023 19:16, jak wrote:
>>> Il 22/01/2023 19:04, jak ha scritto:
>>>> Il 22/01/2023 13:53, Paavo Helde ha scritto:
>>>>> 22.01.2023 14:23 jak kirjutas:

<snip>

>>>>>>
>>>>>> ISO standard can cancel that definition because the C does not have
>>>>>> strings but only an agreement that allows the functions to use 
>>>>>> array as
>>>>>> strings.
>>>>>

<snip>

> hi David,
> I have read your comments on these groups for a few years and I have an
> excellent opinion about you but this time I have the impression that you
> have read this branch of the thread with poor attention. Please read
> more carefully the statement I replied.
> 
> Always with respect, Jak.
> 

Then let me be sure we are discussing the same thing, and there are no 
misunderstandings.

I've cut out all except the most relevant quotation from your posts in 
this branch.  You claimed that C does not have strings, and when given a 
direct reference to the definition of strings in the C standard, you 
claimed that the standards do not determine what the C language is, and 
the standards should be changed to remove the definition of strings, 
since in your opinion they do not exist in the language.

Is that correct?


I tried to explain that the C language standards /do/ define the 
language.  Do you still deny that?  If so, how do /you/ think the 
language is defined?

Have you now looked at the standards and read for yourself how "strings" 
are define in the standards?  Have you looked at the other uses of the 
word "string" in the standard, including "string literal", "pointer to a 
string", and the "<string.h>" header and functions?


C's concept of a string is different from (and more low-level and 
primitive than) that found in many other programming languages.  But 
that does not mean C does not have strings, defined in the standards and 
as part of the language and standard library.

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

#88753

On Monday, 23 January 2023 at 13:42:53 UTC, David Brown wrote:
> 
> C's concept of a string is different from (and more low-level and 
> primitive than) that found in many other programming languages. But 
> that does not mean C does not have strings, defined in the standards and 
> as part of the language and standard library.
>
The language states that a text literal in double quotes produces a nul-terminated
string. I think that's the only place the C language itself defines a string. Otherwise
it is purely a standard library concept.

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

#88764

On Monday, January 23, 2023 at 9:15:58 AM UTC-5, Malcolm McLean wrote:
> On Monday, 23 January 2023 at 13:42:53 UTC, David Brown wrote: 
> > 
> > C's concept of a string is different from (and more low-level and 
> > primitive than) that found in many other programming languages. But 
> > that does not mean C does not have strings, defined in the standards and 
> > as part of the language and standard library. 
> >
> The language states that a text literal in double quotes produces a nul-terminated 
> string. I think that's the only place the C language itself defines a string. Otherwise 
> it is purely a standard library concept.

The language doesn't state any such thing. The standard does, but there is no separate standard for the C language. The C standard describes both the C language and the C standard library. The part that describes the language defines the syntax for a string literal (NOT a text literal), and defines the corresponding semantics, which often (but not always) create a null-terminated string. The part that describes the C standard library starts, as it's very first sentence, with a definition of a C string: "A string is a contiguous sequence of characters terminated by and including the first null character." (7.1.1p1). In that sentence, the term "string" is italicized, an ISO convention indicating that the sentence in which that italicized term appears constitutes the official definition of that term.
This makes sense, because nothing in the language itself depends upon strings; they matter only because various functions in the C standard library take pointers to strings as arguments, or give such pointers as the return value of the function.

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

#88771

On 23/01/2023 15:15, Malcolm McLean wrote:
> On Monday, 23 January 2023 at 13:42:53 UTC, David Brown wrote:
>>
>> C's concept of a string is different from (and more low-level and
>> primitive than) that found in many other programming languages. But
>> that does not mean C does not have strings, defined in the standards and
>> as part of the language and standard library.
>>
> The language states that a text literal in double quotes produces a nul-terminated
> string. I think that's the only place the C language itself defines a string. Otherwise
> it is purely a standard library concept.

You are jumbling several things a bit.  I would recommend you open a 
copy of the C standards (I don't think anything here has changed since 
at least C99) and have a look.

You'll find there is /one/ C standard document (in different versions) - 
the standard library is considered an integral part of the language. 
Very occasionally it is useful to distinguish a "core C language" (that 
is not a term from the standard) from things defined in the standard 
library - this is not such an occasion.

A sequence of characters inside double quotation marks is a "string 
literal".  The section describing these lexical elements, 6.4.5, 
describes the array and character sequence generated.  The /definition/ 
of the term "string" is found in chapter 7, describing the library, not 
in the section defining the term "string literal".  The terms "string" 
and "pointer to string" are mentioned in a number of places throughout 
the document, not just in the library or in connection with string literals.

It's fair to say that there is little that you can do with a string in C 
that does not involve library calls - basically, you can take a pointer 
to a string and use it as a pointer to a character, and you have 
initialisation from string literals.  String handling is done using 
library functions.  But that does not in any way mean strings are not 
defined in the C language, or not part of the C language.

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

#88782

On Monday, 23 January 2023 at 17:02:44 UTC, David Brown wrote:
> 
> A sequence of characters inside double quotation marks is a "string 
> literal". 
>
The double quotation marks plus the text inside is the "string literal".
 
You need a different term to describe the text itself.

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

#88783

On Monday, January 23, 2023 at 2:14:33 PM UTC-5, Malcolm McLean wrote:
> On Monday, 23 January 2023 at 17:02:44 UTC, David Brown wrote: 
> > 
> > A sequence of characters inside double quotation marks is a "string 
> > literal". 
> >
> The double quotation marks plus the text inside is the "string literal". 
> 
> You need a different term to describe the text itself.

"string literal" is a named element of the C grammar. In any context in which "string literal" is the appropriate description the whole thing, the appropriate description for what's between the quote marks is the named grammar element used in the definition of "string literal": s-char-sequence (6.4.5p1).

In translation phase 7, the s-char-sequence is used to initialize an array. The details are described in the C standard, 6.4.5p6. That array is guaranteed to be terminated by a null character. As a result, every position within that array  is guaranteed to qualify as the start of a C string, which might be empty if that position contains a null character.

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

#88788

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 23 January 2023 at 13:42:53 UTC, David Brown wrote:
>> C's concept of a string is different from (and more low-level and 
>> primitive than) that found in many other programming languages. But 
>> that does not mean C does not have strings, defined in the standards and 
>> as part of the language and standard library.
>>
> The language states that a text literal in double quotes produces a nul-terminated
> string. I think that's the only place the C language itself defines a string. Otherwise
> it is purely a standard library concept.

No, it doesn't say that.  The standard's description of string
literals (N1570 6.4.5) does not refer to the standard's definition of
"string" (N1570 7.1.1).

Consider, for example, "abc\0def".

Sections 6 and 7 are both equally valid parts of the C standard.
(Most of section 7 is optional for freestanding implementations,
but 7.1.1 is not, though the concept of a "string" is less useful
in an implementation that doesn't provide library functions that
manipulate strings).

(A side note: As far as I can tell, N1570 6.4.5 describes the syntax and
semantics of a string literal, but never actually says what the value of
a string literal is.  It's obvious that it's the value of the described
array object, but I don't think it actually says so.  This is not
relevant to the current discussion.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web