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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#88718

On 1/22/23 7:23 AM, jak wrote:
> 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.
> 

Excpet that it DOES have strings, as defined in &.1.1p1

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

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

#88720

jak <nospam@please.ty> writes:
> 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.

That is both off-topic and incorrect.

C does not have a string type.  C certainly does have strings.  The
definition is quoted above.

The C standard makes extensive use of the term "string", particularly in
the library section.  The meaning is clear and unambiguous.  Removing
the definition from the language would require a great deal of work to
update the standard, and would have no benefit.

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

#88725

On 1/22/23 07:23, jak wrote:
> 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.

C has strings, because the C standard provides a definition of what a C
string is. It's not a data type as you might expect from using other
languages. In C, it's only a data storage format recognized by many C
standard library functions, and as such defining it is the very first
sentence in the section defining the C standard library:

"A string is a contiguous sequence of characters terminated by and
including the first null character." (7.1.1p1)

The previously referenced definition of a "pointer to a string" occurs
shortly thereafter.

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

#88724

On 1/22/23 06:17, jak wrote:
> Il 22/01/2023 11:20, James Kuyper ha scritto:
...
>> 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.

ISO is the International Standards Organization. They are responsible
for defining the C language. Terms defined in that standard are
specialized jargon whose meaning, in the context of C, might differ from
what you'd expect if you made the mistake of parsing them as ordinary
English words - that is the purpose of defining such jargon, to provide
more precise and slightly different definitions than ordinary English
might provide. In the context of the C standard, those definitions are
authoritative.

In that context, how do you think that definition fails to be
sufficiently precise? Can you give an example of a case where you might
imagine that it's ambiguous whether or not the definition applies?

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

#88705

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message 
news:87a62bie22.fsf@nosuchdomain.example.com...

> A *pointer to a string* is by definition "a pointer to its initial
> (lowest addressed) character".

To disambiguate :

Assuming that a "pointer to a string" is something a function like strdup() 
returns, what do you call the (type of) variable that such a result is 
stored in ?

... it often confuses the h*ll outof me when the word "stringpointer" is 
used for both. :-\


Regards,
Rudy Wieser

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

#88707

On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:
> "Keith Thompson" <Keith.S.T...@gmail.com> wrote in message 
> news:87a62bi...@nosuchdomain.example.com...
> > A *pointer to a string* is by definition "a pointer to its initial 
> > (lowest addressed) character".
> To disambiguate : 
> 
> Assuming that a "pointer to a string" is something a function like strdup() 
> returns, what do you call the (type of) variable that such a result is 
> stored in ? 
> 
> ... it often confuses the h*ll outof me when the word "stringpointer" is 
> used for both. :-\ 

A pointer to a string is (constrained in described way) pointer to a
character. So variable has to be of type pointer to a character.

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

#88712

On 22/01/2023 12:42, Öö Tiib wrote:
> On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:
>> "Keith Thompson" <Keith.S.T...@gmail.com> wrote in message
>> news:87a62bi...@nosuchdomain.example.com...
>>> A *pointer to a string* is by definition "a pointer to its initial
>>> (lowest addressed) character".
>> To disambiguate :
>>
>> Assuming that a "pointer to a string" is something a function like strdup()
>> returns, what do you call the (type of) variable that such a result is
>> stored in ?
>>
>> ... it often confuses the h*ll outof me when the word "stringpointer" is
>> used for both. :-\
> 
> A pointer to a string is (constrained in described way) pointer to a
> character. So variable has to be of type pointer to a character.

Exactly.

A "string" is "a contiguous sequence of characters terminated by and 
including the first null character", as defined by the C standards and 
therefore by C (for those that don't understand how the language is 
defined).

So a "pointer to a string" is also a "pointer to character", though 
pointers to characters do not necessarily point to strings.  And since 
there is no specific type for a "string" in C, you use "pointer to 
character" types to hold "pointer to string" values.

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

#88713

"Öö Tiib" <ootiib@hot.ee> wrote in message 
news:604d1f9c-51b9-4e7d-9c69-25b235a0eb5en@googlegroups.com...
> On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:

>> ... it often confuses the h*ll outof me when the word "stringpointer" is
>> used for both. :-\
>
> A pointer to a string is (constrained in described way) pointer to a
> character. So variable has to be of type pointer to a character.

Thats not what I ment.  If an address which is pointing to a sequence of 
characters is called a "pointer to a string" - normally referred to as "a 
string pointer" - , what should the variable which stores that addres be 
called ?

Regards,
Rudy Wieser

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

#88717

On 1/22/23 9:40 AM, R.Wieser wrote:
> "Öö Tiib" <ootiib@hot.ee> wrote in message
> news:604d1f9c-51b9-4e7d-9c69-25b235a0eb5en@googlegroups.com...
>> On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:
> 
>>> ... it often confuses the h*ll outof me when the word "stringpointer" is
>>> used for both. :-\
>>
>> A pointer to a string is (constrained in described way) pointer to a
>> character. So variable has to be of type pointer to a character.
> 
> Thats not what I ment.  If an address which is pointing to a sequence of
> characters is called a "pointer to a string" - normally referred to as "a
> string pointer" - , what should the variable which stores that addres be
> called ?
> 
> Regards,
> Rudy Wieser
> 
> 

A pointer to string (with type pointer to char).

Just like an int value (like 5) is the value of a given bit combination, 
a variable that holds such a value is also called an int.

If you need to distinguish them, one is a value, and the other is a 
variable (or object)

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

#88721

On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:
> On 1/22/23 9:40 AM, R.Wieser wrote: 
> > "Öö Tiib" <oot...@hot.ee> wrote in message
> > news:604d1f9c-51b9-4e7d...@googlegroups.com... 
> >> On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote: 
> > 
> >>> ... it often confuses the h*ll outof me when the word "stringpointer" is 
> >>> used for both. :-\ 
> >> 
> >> A pointer to a string is (constrained in described way) pointer to a 
> >> character. So variable has to be of type pointer to a character. 
> > 
> > Thats not what I ment. If an address which is pointing to a sequence of 
> > characters is called a "pointer to a string" - normally referred to as "a 
> > string pointer" - , what should the variable which stores that addres be 
> > called ? 
> > 
> > Regards, 
> > Rudy Wieser 
> > 
> >
> A pointer to string (with type pointer to char). 
> 
> Just like an int value (like 5) is the value of a given bit combination, 
> a variable that holds such a value is also called an int. 
> 
> If you need to distinguish them, one is a value, and the other is a 
> variable (or object)
>
The snag is that C has no way of resolving the problem that a string has
an unknown number of bytes. 
So 
char *stringpointer;
*stringpointer = "foo";

Won't work. Unlike a pointer to a numerical type.

In C++, the std::string manages memory internally, so you can have this convenience.
The cost is that you lose control of the run time operations used to manage the 
memory.

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

#88736

On 22/01/2023 20:46, Malcolm McLean wrote:
> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:
>> On 1/22/23 9:40 AM, R.Wieser wrote:
>>> "Öö Tiib" <oot...@hot.ee> wrote in message
>>> news:604d1f9c-51b9-4e7d...@googlegroups.com...
>>>> On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:
>>>
>>>>> ... it often confuses the h*ll outof me when the word "stringpointer" is
>>>>> used for both. :-\
>>>>
>>>> A pointer to a string is (constrained in described way) pointer to a
>>>> character. So variable has to be of type pointer to a character.
>>>
>>> Thats not what I ment. If an address which is pointing to a sequence of
>>> characters is called a "pointer to a string" - normally referred to as "a
>>> string pointer" - , what should the variable which stores that addres be
>>> called ?
>>>
>>> Regards,
>>> Rudy Wieser
>>>
>>>
>> A pointer to string (with type pointer to char).
>>
>> Just like an int value (like 5) is the value of a given bit combination,
>> a variable that holds such a value is also called an int.
>>
>> If you need to distinguish them, one is a value, and the other is a
>> variable (or object)
>>
> The snag is that C has no way of resolving the problem that a string has
> an unknown number of bytes.

That is a very clumsy way of expressing yourself.  A string in C is a 
/value/ - it is formed by a particular set of characters of a particular 
length.  What you are trying to say, I think, is that a /pointer/ to a 
string does not encode the length of the string.  And that is true - but 
it is not a "snag" or a "problem".  It is an unavoidable artefact of the 
simple way C strings are implemented.  And it is easily solved by 
calling "strlen".

> So
> char *stringpointer;
> *stringpointer = "foo";
> 
> Won't work. Unlike a pointer to a numerical type.

Pointers to numerical types don't let you make type mistakes either. 
"foo" is not a C string - it is a string literal.  Neither a string 
literal not a C string is a specific type in C.

> 
> In C++, the std::string manages memory internally, so you can have this convenience.

C++ has a real standard string type, rather than just a defined concept 
as in C.  And it has a lot of useful features - it is a higher level 
concept that C strings.

> The cost is that you lose control of the run time operations used to manage the
> memory.
> 

In C++, std::string is a convenience shortcut for a specific 
instantiation of the std::basic_string template.  If you want to have a 
string type with specific control of memory management, you can 
instantiate the template with your own choice of allocator function.

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

#88755

David Brown <david.brown@hesbynett.no> writes:
>On 22/01/2023 20:46, Malcolm McLean wrote:
>> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:

>> The snag is that C has no way of resolving the problem that a string has
>> an unknown number of bytes.
>
>That is a very clumsy way of expressing yourself.  A string in C is a 
>/value/ - it is formed by a particular set of characters of a particular 
>length.  What you are trying to say, I think, is that a /pointer/ to a 
>string does not encode the length of the string.  And that is true - but 
>it is not a "snag" or a "problem".  It is an unavoidable artefact of the 
>simple way C strings are implemented.  And it is easily solved by 
>calling "strlen".

Easily solved, but performance for large strings is poor.

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

#88757

On Monday, 23 January 2023 at 14:45:05 UTC, Scott Lurndal wrote:
> David Brown <david...@hesbynett.no> writes: 
> >On 22/01/2023 20:46, Malcolm McLean wrote: 
> >> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote: 
> 
> >> The snag is that C has no way of resolving the problem that a string has 
> >> an unknown number of bytes. 
> > 
> >That is a very clumsy way of expressing yourself. A string in C is a 
> >/value/ - it is formed by a particular set of characters of a particular 
> >length. What you are trying to say, I think, is that a /pointer/ to a 
> >string does not encode the length of the string. And that is true - but 
> >it is not a "snag" or a "problem". It is an unavoidable artefact of the 
> >simple way C strings are implemented. And it is easily solved by 
> >calling "strlen".
> Easily solved, but performance for large strings is poor.
>
Yes. Normally when you assign a string, you don't need to keep the old 
copy hanging about. So using std::strings and move assignment will 
allow the assignment to be implemented in a few machine instructions.
(You can probably do this in C by reusing the buffer, but the code has to 
be written vary carefully to ensure that the pointers are pointing to the right
type of memory).

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

#88773

On 23/01/2023 15:44, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 22/01/2023 20:46, Malcolm McLean wrote:
>>> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:
> 
>>> The snag is that C has no way of resolving the problem that a string has
>>> an unknown number of bytes.
>>
>> That is a very clumsy way of expressing yourself.  A string in C is a
>> /value/ - it is formed by a particular set of characters of a particular
>> length.  What you are trying to say, I think, is that a /pointer/ to a
>> string does not encode the length of the string.  And that is true - but
>> it is not a "snag" or a "problem".  It is an unavoidable artefact of the
>> simple way C strings are implemented.  And it is easily solved by
>> calling "strlen".
> 
> Easily solved, but performance for large strings is poor.
> 

Sure.

There is no "perfect" way to implement a way of holding (general) 
strings in a language.  There are lots of ways to do it, but they all 
have their disadvantages as well as advantages.  If you want to work 
efficiently with large strings, standard C strings is a poor choice of 
format.

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

#88776

On Monday, 23 January 2023 at 17:05:27 UTC, David Brown wrote:
> On 23/01/2023 15:44, Scott Lurndal wrote: 
> > David Brown <david...@hesbynett.no> writes: 
> >> On 22/01/2023 20:46, Malcolm McLean wrote: 
> >>> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote: 
> > 
> >>> The snag is that C has no way of resolving the problem that a string has 
> >>> an unknown number of bytes. 
> >> 
> >> That is a very clumsy way of expressing yourself. A string in C is a 
> >> /value/ - it is formed by a particular set of characters of a particular 
> >> length. What you are trying to say, I think, is that a /pointer/ to a 
> >> string does not encode the length of the string. And that is true - but 
> >> it is not a "snag" or a "problem". It is an unavoidable artefact of the 
> >> simple way C strings are implemented. And it is easily solved by 
> >> calling "strlen". 
> > 
> > Easily solved, but performance for large strings is poor. 
> >
> Sure. 
> 
> There is no "perfect" way to implement a way of holding (general) 
> strings in a language. There are lots of ways to do it, but they all 
> have their disadvantages as well as advantages. If you want to work 
> efficiently with large strings, standard C strings is a poor choice of 
> format.
>
It depends how large.
If strings are very large then flat memory buffers are often the best way to go.
That prevents inadvertent copies.
If string are short, then it usually doesn't matter from a performance perspective,
so it's whether C strings or another format is easier to integrate with the exisiting
code.
If strings are medium length them then yes, C format is probably a poor choice,
because the strings are not so long that copying is prohibitively expensive,
but not so short than inefficient copying hardly matters. A format that allows
for efficient assignment, but is also easy to use, is likely better.

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

#88777

David Brown <david.brown@hesbynett.no> writes:
>On 23/01/2023 15:44, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 22/01/2023 20:46, Malcolm McLean wrote:
>>>> On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:
>> 
>>>> The snag is that C has no way of resolving the problem that a string has
>>>> an unknown number of bytes.
>>>
>>> That is a very clumsy way of expressing yourself.  A string in C is a
>>> /value/ - it is formed by a particular set of characters of a particular
>>> length.  What you are trying to say, I think, is that a /pointer/ to a
>>> string does not encode the length of the string.  And that is true - but
>>> it is not a "snag" or a "problem".  It is an unavoidable artefact of the
>>> simple way C strings are implemented.  And it is easily solved by
>>> calling "strlen".
>> 
>> Easily solved, but performance for large strings is poor.
>> 
>
>Sure.
>
>There is no "perfect" way to implement a way of holding (general) 
>strings in a language.  There are lots of ways to do it, but they all 
>have their disadvantages as well as advantages.  If you want to work 
>efficiently with large strings, standard C strings is a poor choice of 
>format.
>

Yes.  It's really application dependent.

For example, when parsing a sequence of bytes, one may not actually
care about the length and rather just start parsing at the first byte
and stop when the nul-byte (or a parse error) is encountered.

One pass through the string, instead of a pass every time strlen() is called.

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

#88722

"Richard Damon" <Richard@Damon-Family.org> wrote in message 
news:sbfzL.383809$iU59.50359@fx14.iad...
> On 1/22/23 9:40 AM, R.Wieser wrote:

>> If an address which is pointing to a sequence of characters is called a 
>> "pointer to a string" - normally referred to as "a string pointer" - , 
>> what should the variable which stores that addres be called ?
>
> A pointer to string (with type pointer to char).

Yep. Both referred to with the exact same name.  And that confuses the h*ll 
outof someone who has to listen to someone talking about two different 
things, but uses the same word for both. :-(

Why do you think I asked ?

> If you need to distinguish them, one is a value, and the other is a 
> variable

You know that, I know that.  But listening to people talking about both 
using the same "string pointer" name I have to wonder if they do ...

Regards,
Rudy Wieser

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

#88727

"R.Wieser" <address@not.available> writes:
> "Richard Damon" <Richard@Damon-Family.org> wrote in message 
> news:sbfzL.383809$iU59.50359@fx14.iad...
>> On 1/22/23 9:40 AM, R.Wieser wrote:
>>> If an address which is pointing to a sequence of characters is called a 
>>> "pointer to a string" - normally referred to as "a string pointer" - , 
>>> what should the variable which stores that addres be called ?
>>
>> A pointer to string (with type pointer to char).
>
> Yep. Both referred to with the exact same name.  And that confuses the h*ll 
> outof someone who has to listen to someone talking about two different 
> things, but uses the same word for both. :-(
>
> Why do you think I asked ?
>
>> If you need to distinguish them, one is a value, and the other is a 
>> variable
>
> You know that, I know that.  But listening to people talking about both 
> using the same "string pointer" name I have to wonder if they do ...

If I understand you correctly, the two things you're referring to are
the pointer *value* and an *object* of pointer type that holds that
value.

There's nothing special about pointers to strings here.  The same
confusion occurs with, for example, a pointer to an int (which is
convenient, because we can discuss this without dragging C into the
discussion).

    int n = 42;
    int* ptr = &n;

The result of evaluating the expression `&n`, or the expression
`ptr`, is a value of type `int*`.  We commonly refer to this value as
"a pointer" (or "an address").

The object named `ptr` is an object (variable) of type `int*`.
We also commonly refer to this object as "a pointer" (though not as
"an address").

Similarly we can refer either to `42` or to the object `n` as
"an integer" or "an int".

Usually this isn't a problem.  In most contexts, the distinction
between a value of some type and an object/variable that holds a
value of some type either isn't important or is sufficiently clear
from the context.

For cases where the ambiguity is important, I find it useful
to think of the word "pointer" (as well as "array", "integer",
etc.) as an adjective rather than a noun.  Thus we can refer to a
*pointer value*, or a *pointer object", or a *pointer type*, or a
*pointer expression*, all of which are clearly distinct concepts.
I'll note that the C and C++ standards often do not use this level
of precision (and in most cases they probably don't need to).

<OT>
For C's definition of a "pointer to a string", I'd say it refers
to a *value* of pointer type.  An object of type char* might have a
current value that is a pointer to a string, but then after a value
is assigned to it it might not.  The state of being a "pointer to
a string" applies to the value, not to the object that currently
happens to hold such a value.

I don't recall seeing a use of the term "pointer to a string" that
was confusing because it could refer to either a value or an object.
</OT>

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

#88732

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message 
news:87wn5egtw8.fsf@nosuchdomain.example.com...

> If I understand you correctly, the two things you're referring to are
> the pointer *value* and an *object* of pointer type that holds that
> value.

I do not call it an object, to me its just a variable.  Anything beyond that 
(an object wich might contain other properties as well as methods) is (way) 
outside of my scope.

> There's nothing special about pointers to strings here.
> The same confusion occurs with, for example, a pointer to an int

Indeed.  But if there is one thing I've learned from Usenet it is that you 
need to keep the context to a question simple.  Referring to all the other 
adresses and what they point to would just be "muddying the water".

> Usually this isn't a problem.  In most contexts, the distinction
> between a value of some type and an object/variable that holds a
> value of some type either *isn't important or is sufficiently clear
> from the context*.

Agreed.

But thats the crux : somethimes I get the distinct feeling that someone is 
talking about the address (pointing to a string or otherwise), but than 
suddenly seems to talk about the variable holding it.  :-\

> For cases where the ambiguity is important, I find it useful
> to think of the word "pointer" (as well as "array", "integer",
> etc.) as an adjective rather than a noun.  Thus we can refer to a
> *pointer value*, or a *pointer object", or a *pointer type*, or a
> *pointer expression*, all of which are clearly distinct concepts.

I think I can translate "pointer value" as to be meaning an address.  For 
the others ? I do not have the foggiest I'm afraid.

> <OT>

Whoooo....  Is that *on*, of *off* topic ?  Not that it matters much which 
one though. :-)

> For C's definition of a "pointer to a string", I'd say it refers
> to a *value* of pointer type.

AFAIK most people do not use that phrase but use the (shorthand) "string 
pointer" (with or without the space) instead.  But yes, I would also.

Though thats the whole problem to me : most people seem to use that "string 
pointer" phrase for the addres (the "value of pointer type") *as well as* 
the variable (or worse : an object) its stored in.


But I think I am going to stop asking.  It looks like the destinction 
between the address and what its stored in isn't of much, if any, importance 
to the people here.

Oh well, you can't get /everything/ answered. :-)

Regards,
Rudy Wieser

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

#88734

On 1/23/23 02:33, R.Wieser wrote:
> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
> news:87wn5egtw8.fsf@nosuchdomain.example.com...
>
>> If I understand you correctly, the two things you're referring to are
>> the pointer *value* and an *object* of pointer type that holds that
>> value.
>
> I do not call it an object, to me its just a variable. Anything beyond
> that (an object wich might contain other properties as well as
> methods) is (way) outside of my scope.

The term "object" has a well-defined meaning in C, but since it is not
an object-oriented language, that definition carries a lot less baggage
than you're thinking of:

"region of data storage in the execution environment, the contents of
which can represent values" (3.15p2).

The C standard does not define the noun "variable", a fact that is
difficult to confirm because it makes extensive use of the adjective
"variable". Also, it makes extensive use of the ISO convention of
defining some terms by italicizing those terms inside of a sentence
whose contents constitute the official definition of those terms, so in
principle you have to search every use of the word "variable" in the
entire standard. In practice, however, the index usually notes the
location where a term is defined, if it is defined.

C++ does have a definition of the noun "variable". If you strip that
definition of everything specific to C++, it boils down to "named
object". As far as I've been able to tell, that definition fits every
use of the noun "variable" in the C standard. Therefore, I assume that's
what the term means in the C standard, and I recommend that you do the same.

For example, if you declare "struct tm *start_times;" and assign it to
point at a dynamically allocated array of at least six elements, then
start_times, the array that it points at, start_times[5], and
start_times[5].tm_year are all considered to be objects, but only
start_times and tm_year are variables, because they are the only objects
in that list that have names. The array that start_times points at is an
unnamed object, and the last two are sub-objects of that object.

Therefore, every variable is also an object.

>> For cases where the ambiguity is important, I find it useful
>> to think of the word "pointer" (as well as "array", "integer",
>> etc.) as an adjective rather than a noun. Thus we can refer to a
>> *pointer value*, or a *pointer object", or a *pointer type*, or a
>> *pointer expression*, all of which are clearly distinct concepts.
>
> I think I can translate "pointer value" as to be meaning an address.
> For the others ? I do not have the foggiest I'm afraid.

A pointer object is a a region of memory used to store a pointer value.

A pointer type is the type of a pointer value, including in particular
the pointer value that might be stored in a pointer object.

"An expression is a sequence of operators and operands that specifies
computation of a value, 92) or that designates an object or a function,
or that generates side effects, or that performs a combination thereof."
(C standard, 6.5p1).

Since operators and operands are parts of the text of a C program,
expressions are things that exist only in the source code, not in the
compiled program. Translation of source code into an executable results
in the generation of code that does what the expression specifies should
be done. A pointer expression is an expression that specifies
computation of a pointer value, or designates a pointer object.

This whole issue is especially difficult for a newbie because it's often
perfectly clear, to an experienced user of C, whether "a pointer" refers
to a pointer value, a pointer object, a pointer type, or a pointer
expression. As a result, all of those terms are frequently shortened to
"pointer", unless the context is ambiguous. This is true even within the
standard itself. I'm sorry, but that's the way it is. I can't do
anything about it even if I didn't find it convenient to do the same.
All I can do is assure you that it will become clearer as you get more
familiar with the language.

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

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

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

csiph-web