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

#88786

"R.Wieser" <address@not.available> writes:
> "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 word "object" is not about object-oriented programming.  The C
standard defines an "object" as a "region of data storage in the
execution environment, the contents of which can represent values"; it
doesn't use the term "variable". The C++ standard uses the word "object" in the
same way, though it doesn't have quite the same formal definition.

An "object" is just a variable, except that a variable typically has a
name.

>> 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.  :-\

Yes, people are often informal, or even sloppy, about the distinction.

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

For example, `int*` and `char*` are pointer types.

A pointer value is the result of evaluating an expression of pointer
type, including an expression that simply yields the value stored in an
object/variable.  That value can be the address of an object (or of a
function, but let's set that aside), or it can be a null pointer (there
are other possibilities).

A pointer expression is a chunk of text in a C or C++ program,
interpreted as an expression that, when evaluated, will yield a result
of pointer type.

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

"<OT>" means off-topic.  I marked the last part of my article that way
because it discusses C, while the topic of this newsgroup is C++, a
distinct language.

You raised the issue of the ambiguity between a "pointer" as a value and
a "pointer" as an object in the context of a "pointer to a string",
which is a C-specific context.  I'm trying to steer the discussion in a
direction that applies to both languages.  (I might suggest posting to
comp.lang.c, but I'm not sure it would be useful.)

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

Sure, "string pointer" means the same thing as "pointer to a string".
It's slightly informal, but not likely to be ambiguous.

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

Suggestion: Any time you read something specific that you find
confusing, ask about it.  That's likely to be a lot easier than trying
to solve the general problem.

People with a lot of experience are likely to write in an informal
shorthand that assumes a similar level of experience in readers.  It can
be ambiguous, but the ambiguity can be resolved *if* you have that
experience.  If something is genuinely confusing, feel free to keep us
on our toes by asking about it.

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

#88957

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> "R.Wieser" <address@not.available> writes:
>
>> "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 word "object" is not about object-oriented programming.  The C
> standard defines an "object" as a "region of data storage in the
> execution environment, the contents of which can represent values";
> it doesn't use the term "variable".  The C++ standard uses the word
> "object" in the same way, though it doesn't have quite the same
> formal definition.
>
> An "object" is just a variable, except that a variable typically has
> a name.

Just a quibble:  C does have some objects that are not variables
in the usual sense of the word.  Generally it is true that all
"variables" correspond to objects (sometimes instantiated more
than once), but not all objects correspond to variables (again
in the usual sense of how the term "variable" is used).

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

#88962

On Thursday, February 2, 2023 at 9:44:06 AM UTC-5, Tim Rentsch wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes: 
...
> > The word "object" is not about object-oriented programming. The C 
> > standard defines an "object" as a "region of data storage in the 
> > execution environment, the contents of which can represent values"; 
> > it doesn't use the term "variable". The C++ standard uses the word 
> > "object" in the same way, though it doesn't have quite the same 
> > formal definition. 
> > 
> > An "object" is just a variable, except that a variable typically has 
> > a name.
> Just a quibble: C does have some objects that are not variables 
> in the usual sense of the word. ...

True, and his comment implies that fact, by using the word "except"  - when that exception does not apply, you still have an object, but not a variable.

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

#88963

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Thursday, February 2, 2023 at 9:44:06 AM UTC-5, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>
> ...
>
>>> The word "object" is not about object-oriented programming.  The C
>>> standard defines an "object" as a "region of data storage in the
>>> execution environment, the contents of which can represent values";
>>> it doesn't use the term "variable".  The C++ standard uses the word
>>> "object" in the same way, though it doesn't have quite the same
>>> formal definition.
>>>
>>> An "object" is just a variable, except that a variable typically has
>>> a name.
>>
>> Just a quibble:  C does have some objects that are not variables
>> in the usual sense of the word. ...
>
> True, and his comment implies that fact, by using the word "except"
> - when that exception does not apply, you still have an object, but
> not a variable.

I suppose that is one way of reading it.  But certainly it
is not the only way of reading it.

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

#88719

"R.Wieser" <address@not.available> writes:
> "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. :-\

Note that we're talking about C; C++, the topic of this newsgroup, is a
related but distinct language.

What C calls a "string" is very close to (probably identical to) what
C++ calls a "null-terminated byte string", or NTBS.  The informal term
"C-style string" is common, to distinguish it from C++'s std::string.

In C, there is no string type (unless you define one yourself).  The
language-defined term "string" is used to refer to a data format, not a
data type.  An object of type "array of char" may or may not contain a
string (or multiple strings).

The C term "pointer to a string" is not analogous to, for example,
"pointer to an int".  It is a language-defined phrase because the term
"pointer to a string" either would not make sense or would have a
different meaning in the absence of that definition.  A pointer to a
string points to the initial (0th) element of the string, and can be
used via array arithmetic, indexing, and calls to library functions to
manipulate the string.

An object containing a *pointer to a string* is normally of type char*
or const char*.

Everything that can be done in C using C-style strings and C-style
string pointers can be done the same way in C++, but it's almost
always easier and safer to use std::string.

To answer your original question, given a char* value (say, a function
parameter), neither C nor C++ gives you a way to determine how the
memory it points to was allocated, and therefore how and whether it
should be deallocated.  If you want to pass pointers around and let the
called function decide whether and how to deallocate it, you'll have to
pass that information somehow, probably as another argument or by
wrapping the pointer in a structure or class.  Note also that memory
allocated by malloc() should be deallocated by calling free(), and
memory allocated by new should be deallocated by delete; mixing the two,
IIRC, has undefined behavior.

But again, std::string takes care of all of this for you.

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

#88723

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message 
news:875ycyiehv.fsf@nosuchdomain.example.com...
> "R.Wieser" <address@not.available> writes:

> To answer your original question, given a char* value (say, a
> function parameter), neither C nor C++ gives you a way to determine
> how the memory it points to was allocated, and therefore how and
> whether it should be deallocated.

I already assumed as much, but as I'm a novice in regard to the language I 
had to make sure.

Who knows, maybe what we all have been referring to as "a pointer to a 
string" is actually an object carrying a number of attributes and a 
deconstructor too. :-)

Regards,
Rudy Wieser

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

#88726

On 1/22/23 06:27, R.Wieser wrote:
> "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. :-\

C doesn't have a string type, just a data storage format for strings
that is recognized by many standard library functions. Since there is no
string type, there's no specific pointer type that is used for storing
such pointers. Any pointer type might point at the first character of a
string, but the most useful types for such pointers are those that can
be passed to or or used to store the value returned from those library
functions without requiring an explicit conversion. Those functions
generally take arguments and/or return values of char* or const char*
types. I don't remember if there are any that use unsigned char rather
than char, but it would be possible. Other useful types would be [const]
void*, which in C (unlike C++) allows implicit conversions to and from
[const] char*.

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

#88731

"James Kuyper" <jameskuyper@alumni.caltech.edu> wrote in message 
news:tqk7dn$386s5$1@dont-email.me...
> On 1/22/23 06:27, R.Wieser wrote:

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

> C doesn't have a string type, just a data storage format for strings
> that is recognized by many standard library functions.

The famous "C string", non terminated but instead with its length stored 
before the first character.

> Since there is no string type, there's no specific pointer type that is
> used for storing such pointers.

Thats not what I'm trying to get at.

You have an address and a variable you store that address in.  Which names 
do you use for both ?

I most allways see them referred to with the same phrase : "a string 
pointer".  Which is ofcourse ambigue. That doesn't matter much in most 
circumstances (which one of the two it actually is can be gleaned from the 
context), but does some others.

Regards,
Rudy Wieser

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

#88735

On 1/23/23 02:04, R.Wieser wrote:
> "James Kuyper" <jameskuyper@alumni.caltech.edu> wrote in message 
> news:tqk7dn$386s5$1@dont-email.me...
...
>> C doesn't have a string type, just a data storage format for strings
>> that is recognized by many standard library functions.
> 
> The famous "C string", non terminated but instead with its length stored 
> before the first character.

That sentence no verb. I point that out because that fact that is has no
verb is part of the reason why I'm not sure what you meant by it. The
term "string", as defined by the C standard, is by definition
null-terminated, and does not have a stored length.

>> Since there is no string type, there's no specific pointer type that is
>> used for storing such pointers.
> 
> Thats not what I'm trying to get at.
> 
> You have an address and a variable you store that address in.  Which names 
> do you use for both ?
> 
> I most allways see them referred to with the same phrase : "a string 
> pointer".  Which is ofcourse ambigue. That doesn't matter much in most 
> circumstances (which one of the two it actually is can be gleaned from the 
> context), but does some others.

Any given use might seem ambiguous to a newbie like yourself, but the
reason why it is commonplace to use "string pointer" without following
it with "value", "object", "type", or "expression" is precisely because
it's usually clear from context (at least to those with more experience
with the language) which of those is being referred to. When it would
otherwise be ambiguous, people usually (but unfortunately, not always)
do add the additional word that's needed to make it clear.

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

#88739

On 23/01/2023 08:04, R.Wieser wrote:
> "James Kuyper" <jameskuyper@alumni.caltech.edu> wrote in message
> news:tqk7dn$386s5$1@dont-email.me...
>> On 1/22/23 06:27, R.Wieser wrote:
> 
>>> 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 ?
> 
>> C doesn't have a string type, just a data storage format for strings
>> that is recognized by many standard library functions.
> 
> The famous "C string", non terminated but instead with its length stored
> before the first character.
> 

C strings are, by definition, always terminated - if they are not 
terminated, they are not strings.  And any length indicator is not part 
of the string.

What you are describing here sounds more like what is known as a 
"Pascal-style string", because it is the common format for variable 
length short strings in Pascal.  (Typical Pascal implementations can 
support other string formats too, including fixed length formats, "long" 
strings with 32-bit length indicators at the start, C-style strings, and 
maybe others.)

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

#88691

On 21/01/2023 14:28, 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.
> :-)
> 
> Regards,
> Rudy Wieser
> 

As others have said - in C++ we have a string class, which would be the much preferred approach. 
Also with resources generally which need to be managed (freed at some point to avoid resource leaks) 
the common approach is for those resources to be represented by classes that free the resources when 
they go out of scope (or earlier by calling some kind of dispose method).

But this doesn't really answer your question...  If you had asked the question in comp.lang.c it 
would be more relevant as there is no string class, and the question deserves a literal answer.

The answer is that the documentation for using the function in question needs to clearly specify 
whether or not the caller is responsible for freeing particular resources returned by the function.

So perhaps the function documentation might say "Caller is responsible for freeing the returned 
string, using free() function".  Of course, if you're writing the called function, and want to 
return some literal string, you would need to strdup() that literal string yourself, so that it can 
be correctly freed by the caller.  (The topic is more general than just freeing memory - calls to 
the OS often return other resources like handles representing kernal objects, or GUI objects, and 
sometimes those resources must be freed by the caller, and sometimes they represent pre-existing 
objects owned elsewhere in the system that the caller mustn't free.  The whole question of resource 
ownership can be troublesome for callers, so the only answer is good documentation.  Maybe function 
naming conventions like create_xx() vs get_xx() etc. can help, but documentation is the key.

Regards,
Mike.

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

#88693

"Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message 
news:tPqdnZTbnINss1H-nZ2dnZfqnPadnZ2d@brightview.co.uk...

> the question deserves a literal answer.

Thats what I thought too.

> The answer is that the documentation for using the function in question 
> needs to clearly specify whether or not the caller is responsible for 
> freeing particular resources returned by the function.

My post was more in the direction that /either of/ those string types could 
be returned, and I would like to create a "safe release" routine for such a 
pointer.

> Of course, if you're writing the called function, and want to return some 
> literal string, you would need to strdup() that literal string yourself, 
> so that it can be correctly freed by the caller.

Thats good for a simple situation.  I was also thinking of a string pointer 
which could be initialized by the user but changed by a routine.

Ofcourse, the "you may only provide type 'X' there" documentation rule could 
also be applied there.  I was just hoping that I could create a bit more 
flexibility.

Thanks for the well-aimed reply.

Regards,
Rudy Wieser

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

#88695

On 1/21/23 2:09 PM, R.Wieser wrote:
> "Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message
> news:tPqdnZTbnINss1H-nZ2dnZfqnPadnZ2d@brightview.co.uk...
> 
>> the question deserves a literal answer.
> 
> Thats what I thought too.
> 
>> The answer is that the documentation for using the function in question
>> needs to clearly specify whether or not the caller is responsible for
>> freeing particular resources returned by the function.
> 
> My post was more in the direction that /either of/ those string types could
> be returned, and I would like to create a "safe release" routine for such a
> pointer.
> 
>> Of course, if you're writing the called function, and want to return some
>> literal string, you would need to strdup() that literal string yourself,
>> so that it can be correctly freed by the caller.
> 
> Thats good for a simple situation.  I was also thinking of a string pointer
> which could be initialized by the user but changed by a routine.
> 
> Ofcourse, the "you may only provide type 'X' there" documentation rule could
> also be applied there.  I was just hoping that I could create a bit more
> flexibility.
> 
> Thanks for the well-aimed reply.
> 
> Regards,
> Rudy Wieser
> 
> 

So the "string pointer" type you are thinking of needs to be told, and 
remember the answer to the question, "Does this memory need to be freed?"

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

#88703

"Richard Damon" <Richard@Damon-Family.org> wrote in message 
news:bSYyL.44734$%os8.15496@fx03.iad...
> On 1/21/23 2:09 PM, R.Wieser wrote:

> So the "string pointer" type you are thinking of needs to be told, and 
> remember the answer to the question, "Does this memory need to be freed?"

Its unclear to me which "string pointer" you are referring to there : the 
result of the strdup() function, or the "char* message" variable it is 
stored in.

But yes, that is pretty much what I was asking about - with the "being told" 
part done by the programming language.  With me just checking what it was 
told.

Regards,
Rudy Wieser

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

#88697

On 21/01/2023 19:09, R.Wieser wrote:
> "Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message
> news:tPqdnZTbnINss1H-nZ2dnZfqnPadnZ2d@brightview.co.uk...
> 
>> the question deserves a literal answer.
> 
> Thats what I thought too.
> 
>> The answer is that the documentation for using the function in question
>> needs to clearly specify whether or not the caller is responsible for
>> freeing particular resources returned by the function.
> 
> My post was more in the direction that /either of/ those string types could
> be returned, and I would like to create a "safe release" routine for such a
> pointer.

A noble aim, but... the C++ and C language raw pointers are basically just "pointers to type xxx" 
They don't encapsulate how to free referenced resource(s) - pointers to an object on the stack, or 
in static program storage, or on the C/C++ heap or even in the OS process heap will all typically 
look similar, i.e. just 32- or 64-bit (or whatever) address space pointer values.  You could analyse 
the pointer value and try to work out what region of memory it belongs to, but that will be 
non-portable and too much to reasonably ask, I'd say.

C++ functions could return some kind of embellished pointer - a class object including the pointer 
and also the capability within the class of freeing the referenced resources in various ways 
depending on how the resource was created.  The embellishment would increase the memory required for 
a 'pointer', so this might not be a good idea e.g. if your app might have large arrays of such 
pointers.  Basically, if there were a /simple/ answer to your original question, there would be no 
interesting debate, but there's not - so you need to carefully balance costs/benefits.  Simple is 
good, unless simple doesn't work! :)

>> Of course, if you're writing the called function, and want to return some
>> literal string, you would need to strdup() that literal string yourself,
>> so that it can be correctly freed by the caller.
> 
> Thats good for a simple situation.  I was also thinking of a string pointer
> which could be initialized by the user but changed by a routine.

There are two aspects here, and it's good to keep them separate.

Looking at the std::string class, that addresses the "initialized by the user but changed by a 
routine" bit of the problem, which I'll suggest is 99% of the benefit you're after.  [Pass strings 
as std::string& ]

The remaining "I really want to return pointers to memory allocated (and so to be later freed) in 
several different ways decided at run-time ALL FROM THE SAME FUNCTION" is a separate problem.  It 
could be addresed with the approach of embellished pointers.  The standard library supports custom 
allocators which can serve as template arguments for containers like std::string, so you could have 
a std::string with an embellished pointer - but, so much added complexity for what??

If you're more interested in C APIs, using raw pointers etc., then the whole topic of 
responsibilities for managing memory between callers and called functions IN GENERAL is quite 
subtle.  DCE's Remote Procedure Call (RPC) framework has to solve this issue because the calling and 
called routines typically are in different address spaces with no shared memory, and it's far from 
trivial!  The problem is that C/C++ language in itself does not sufficiently describe pointer use to 
make this possible.  E.g. a pointer could be a REF pointer to a single struct, or to an array, and 
structs can chain to other structs, possibly involving loops of pointers, or at least having 
multiple pointers to a single struct.  Also pointers need to be understood as IN/OUT/INOUT in terms 
of which way data is being passed to/from a function, which affects the rules for managing the 
memory.  If you're interested in the GENERAL solution for this kind of problem the DCE RPC 
documentation (or Microsofts DCOM which uses RPC) relating to memory management would at least give 
you a good idea of the issues.

But if you just want to provide one C-style API for one function with a modifiable IN/OUT parameter, 
just do something like:

int AmendString (/*INOUT*/ char** ppString);

and clearly document callers responsibity, including how the string memory must initially be 
allocated by the caller, and how it must eventually be freed upon return.

Mike.

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

#88704

"Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message 
news:OtycnbSNHJxJ_1H-nZ2dnZfqnPudnZ2d@brightview.co.uk...

> A noble aim, but... the C++ and C language raw pointers are basically just 
> "pointers to type xxx" They don't encapsulate how to free referenced 
> resource(s).

:-) That was what I tried to get clear : if perhaps the current iteration of 
the language perhaps had such a ... something. An "I'm static" bitflag would 
have been enough for my purposes.

> You could analyse the pointer value and try to work out what region of 
> memory it belongs to, but that will be non-portable and too much to 
> reasonably ask, I'd say.

Athough I currently am way to much of a novice in the language that might 
actually be something I would try - even if just to show myself that it 
isn't a good idea.

> Simple is good, unless simple doesn't work! :)

Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It 
Simple, Stupid") and I quite agree with.

> Looking at the std::string class, that addresses the "initialized by the 
> user but changed by a routine" bit of the problem, which I'll suggest is 
> 99% of the benefit you're after.  [Pass strings as std::string& ]

Using the "document the function!" method you mentioned earlier I could also 
tell the user that only dynamic strings are permitted as input.

> It could be addresed with the approach of embellished pointers.

I'm sorry, but currently I have absolutily /no idea/ what those are.

> If you're more interested in C APIs, using raw pointers etc., then the 
> whole topic of responsibilities for managing memory between callers and 
> called functions IN GENERAL is quite subtle.  DCE's Remote Procedure Call 
> (RPC) framework has to solve this issue because the calling and called 
> routines typically are in different address spaces with no shared memory, 
> and it's far from trivial!

You mean marshalling ?   I had to do that in Windows (using my preferred 
language, Assembly) when I tried to retrieve some data from a control on a 
dialog that was part of another process - which included having to "remote 
allocate" some memory to copy to/from.

> The problem is that C/C++ language in itself does not sufficiently 
> describe pointer use to make this possible.

As above, thart was what I needed to make sure of - before I started to try 
to create all kinds of complex-y solutions that would not be needed.

> E.g. a pointer could be a REF pointer to a single struct, or to an array, 
> and structs can chain to other structs, possibly involving loops of 
> pointers, or at least having multiple pointers to a single struct.

Hey !   I was trying to keep it simple !   :-)

But yes, I was thinking in the same direction.  In my case I wanted to 
provide and/or return the string as part of a structure.   The structure 
could be dynamic too, meaning that before the structure would be destroyed 
all of the strings in it need to be destroyed first.

> But if you just want to provide one C-style API for one function with a 
> modifiable IN/OUT parameter, just do something like:
>
> int AmendString (/*INOUT*/ char** ppString);

Ehhrrmm...  I didn't even realize that I needed that notation.  I skipped it 
that specific notation by having the string pointer "hidden" in a structure.

> and clearly document callers responsibity, including how the string memory 
> must initially be allocated by the caller, and how it must eventually be 
> freed upon return.

Agreed.

The only problem is that my user is rather stupid. I'm not sure if I'm, at 
some time in the future, will be able to use the function I wrote myself 
without fouling up and wondering whatever I was thinking of when I wrote it. 
:-)

Thanks for the explanation.

Regards,
Rudy Wieser

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

#88709

22.01.2023 12:56 R.Wieser kirjutas:
> "Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message
> news:OtycnbSNHJxJ_1H-nZ2dnZfqnPudnZ2d@brightview.co.uk...

>> You could analyse the pointer value and try to work out what region of
>> memory it belongs to, but that will be non-portable and too much to
>> reasonably ask, I'd say.
> 
> Athough I currently am way to much of a novice in the language that might
> actually be something I would try - even if just to show myself that it
> isn't a good idea

This is basically impossible. Yes, maybe you can tell on some platform 
if a string pointer points to some address in the heap, stack or a 
global static area. Alas, even if it points to heap, you still won't 
know if you may or must call free() on the pointer. The string might be 
allocated globally and meant to be in shared use for longer, or the 
string might be a part of another data structure which your code doesn't 
even know how to deallocate.

So it's not just a bad idea, but impossible, unless you want to severely 
cripple the ways how strings may be used in your program.

> 
>> Simple is good, unless simple doesn't work! :)
> 
> Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
> Simple, Stupid") and I quite agree with.

If you want to keep it simple, then just use C++ std::string, you can't 
get simpler than that, unless switching over to Python(*) or something.

(*) Some might claim Python strings are actually more complicated than 
in C++ because of codepage/unicode nuances, Python 2 / Python 3 
differences, and hidden performance gotchas, e.g. the computational 
complexity of Python string += operation is worse in Python than in C++.

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

#88714

"Paavo Helde" <eesnimi@osa.pri.ee> wrote in message 
news:tqjaaa$33tcp$1@dont-email.me...
> 22.01.2023 12:56 R.Wieser kirjutas:
>> "Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in 
>> message
>> news:OtycnbSNHJxJ_1H-nZ2dnZfqnPudnZ2d@brightview.co.uk...

>>> Simple is good, unless simple doesn't work! :)
>>
>> Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
>> Simple, Stupid") and I quite agree with.
>
> If you want to keep it simple, then just use C++ std::string, you can't 
> get simpler than that, unless switching over to Python(*) or something.

I'll keep that in mind.  Heck, I might even go and take a look at it some 
time. :-)

Regards,
Rudy Wieser

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

#88730

Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> C++ functions could return some kind of embellished pointer - a class object including the pointer 
> and also the capability within the class of freeing the referenced resources in various ways 
> depending on how the resource was created.  The embellishment would increase the memory required for 
> a 'pointer', so this might not be a good idea e.g. if your app might have large arrays of such 
> pointers.  Basically, if there were a /simple/ answer to your original question, there would be no 
> interesting debate, but there's not - so you need to carefully balance costs/benefits.  Simple is 
> good, unless simple doesn't work! :)

Instead of putting the meta information about the string in the pointer type,
it could be put in the string itself.

Make the first char of the string contain any information you need about the
string (up to 8 bits of it available), and have the actual string contents
start after that, and make the "pointer" point to that second byte. When
destroying the string, make it check the actual first byte to see if it
has to free it or not.

This way the pointer itself can be the size of a pointer, and the metadata
only takes 1 byte.

[toc] | [prev] | [standalone]

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

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

csiph-web