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

#88756 — Re: A string pointer to a static or dynamic string : how to free the

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>> On Sat, 21 Jan 2023 19:30:48 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>
>>>> Unless you want to parse the string which may involve chopping it about. Then
>>>
>>>> its simpler to use a C string and pointers rather than mess about with
>>>> inefficient substr() etc.
>>>
>>> What's wrong with sth. like this ?
>>>
>>> string substr()
>>> {
>>> 	string hw( "hello world!" );
>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>> 	hw.resize( 5 );
>>> 	return hw;
>>> }
>> 
>> char *hw = "hello world!";
>> :
>> return hw + 5;
>
>You're returning a newly created string object, thereby inducing
>the issue a second allocation

No, he's simply returning the final characters of the C-style
sequence of 'char' entities.  About as efficient as possible for
the stated example.

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

#88758 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 15:46 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> Unless you want to parse the string which may involve chopping it about. Then
>>>>
>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>> inefficient substr() etc.
>>>>
>>>> What's wrong with sth. like this ?
>>>>
>>>> string substr()
>>>> {
>>>> 	string hw( "hello world!" );
>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>> 	hw.resize( 5 );
>>>> 	return hw;
>>>> }
>>>
>>> char *hw = "hello world!";
>>> :
>>> return hw + 5;
>>
>> You're returning a newly created string object, thereby inducing
>> the issue a second allocation

> No, he's simply returning the final characters of the C-style
> sequence of 'char' entities.  About as efficient as possible for
> the stated example.

Maybe, but maybe he suggested that
as the body of my function-definition.

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

#88760 — Re: A string pointer to a static or dynamic string : how to free the

On Mon, 23 Jan 2023 16:48:13 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.01.2023 um 15:46 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>
>>>>>> Unless you want to parse the string which may involve chopping it about.
>Then
>>>>>
>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>> inefficient substr() etc.
>>>>>
>>>>> What's wrong with sth. like this ?
>>>>>
>>>>> string substr()
>>>>> {
>>>>> 	string hw( "hello world!" );
>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>> 	hw.resize( 5 );
>>>>> 	return hw;
>>>>> }
>>>>
>>>> char *hw = "hello world!";
>>>> :
>>>> return hw + 5;
>>>
>>> You're returning a newly created string object, thereby inducing
>>> the issue a second allocation
>
>> No, he's simply returning the final characters of the C-style
>> sequence of 'char' entities.  About as efficient as possible for
>> the stated example.
>
>Maybe, but maybe he suggested that
>as the body of my function-definition.

I was simply pointing out that for simple operations such as that char* is 
usually more efficient than std::string.

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

#88762 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 17:09 schrieb Muttley@dastardlyhq.com:
> On Mon, 23 Jan 2023 16:48:13 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.01.2023 um 15:46 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>>
>>>>>>> Unless you want to parse the string which may involve chopping it about.
>> Then
>>>>>>
>>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>>> inefficient substr() etc.
>>>>>>
>>>>>> What's wrong with sth. like this ?
>>>>>>
>>>>>> string substr()
>>>>>> {
>>>>>> 	string hw( "hello world!" );
>>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>>> 	hw.resize( 5 );
>>>>>> 	return hw;
>>>>>> }
>>>>>
>>>>> char *hw = "hello world!";
>>>>> :
>>>>> return hw + 5;
>>>>
>>>> You're returning a newly created string object, thereby inducing
>>>> the issue a second allocation
>>
>>> No, he's simply returning the final characters of the C-style
>>> sequence of 'char' entities.  About as efficient as possible for
>>> the stated example.
>>
>> Maybe, but maybe he suggested that
>> as the body of my function-definition.
> 
> I was simply pointing out that for simple operations such as that char* is
> usually more efficient than std::string.

You put that in a context where we discussed further allocations
if you extract a substring, and I took that into that context.
With your further explanations your code fits even less.

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

#88763 — Re: A string pointer to a static or dynamic string : how to free the

On Mon, 23 Jan 2023 13:53:55 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>> On Sat, 21 Jan 2023 19:30:48 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>
>>>> Unless you want to parse the string which may involve chopping it about.
>Then
>>>
>>>> its simpler to use a C string and pointers rather than mess about with
>>>> inefficient substr() etc.
>>>
>>> What's wrong with sth. like this ?
>>>
>>> string substr()
>>> {
>>> 	string hw( "hello world!" );
>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>> 	hw.resize( 5 );
>>> 	return hw;
>>> }
>> 
>> char *hw = "hello world!";
>> :
>> return hw + 5;
>
>You're returning a newly created string object, thereby inducing

This is C, not C++. There are no objects. Its returning a memory address
which in this case will probably be pointing to part of the program text area.

>blem. And you're returning the exclamation mark I also stripped.

hw[10] = '\0';

Sorted.

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

#88765 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
> On Mon, 23 Jan 2023 13:53:55 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> Unless you want to parse the string which may involve chopping it about.
>> Then
>>>>
>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>> inefficient substr() etc.
>>>>
>>>> What's wrong with sth. like this ?
>>>>
>>>> string substr()
>>>> {
>>>> 	string hw( "hello world!" );
>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>> 	hw.resize( 5 );
>>>> 	return hw;
>>>> }
>>>
>>> char *hw = "hello world!";
>>> :
>>> return hw + 5;
>>
>> You're returning a newly created string object, thereby inducing
> 
> This is C, not C++. ...

In a C++-newsgroup and we discussed the topic of copy-allocations ...

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

#88766 — Re: A string pointer to a static or dynamic string : how to free the

On Mon, 23 Jan 2023 17:25:49 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>> On Mon, 23 Jan 2023 13:53:55 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>
>>>>>> Unless you want to parse the string which may involve chopping it about.
>>> Then
>>>>>
>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>> inefficient substr() etc.
>>>>>
>>>>> What's wrong with sth. like this ?
>>>>>
>>>>> string substr()
>>>>> {
>>>>> 	string hw( "hello world!" );
>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>> 	hw.resize( 5 );
>>>>> 	return hw;
>>>>> }
>>>>
>>>> char *hw = "hello world!";
>>>> :
>>>> return hw + 5;
>>>
>>> You're returning a newly created string object, thereby inducing
>> 
>> This is C, not C++. ...
>
>In a C++-newsgroup and we discussed the topic of copy-allocations ...
>

When comparing C vs C++ a discussion of C is entirely appropriate.

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

#88767 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 17:37 schrieb Muttley@dastardlyhq.com:
> On Mon, 23 Jan 2023 17:25:49 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>> On Mon, 23 Jan 2023 13:53:55 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>>
>>>>>>> Unless you want to parse the string which may involve chopping it about.
>>>> Then
>>>>>>
>>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>>> inefficient substr() etc.
>>>>>>
>>>>>> What's wrong with sth. like this ?
>>>>>>
>>>>>> string substr()
>>>>>> {
>>>>>> 	string hw( "hello world!" );
>>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>>> 	hw.resize( 5 );
>>>>>> 	return hw;
>>>>>> }
>>>>>
>>>>> char *hw = "hello world!";
>>>>> :
>>>>> return hw + 5;
>>>>
>>>> You're returning a newly created string object, thereby inducing
>>>
>>> This is C, not C++. ...
>>
>> In a C++-newsgroup and we discussed the topic of copy-allocations ...
>>
> 
> When comparing C vs C++ a discussion of C is entirely appropriate.

Yes, somewhere else in this thread.

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

#88770 — Re: A string pointer to a static or dynamic string : how to free the

On Mon, 23 Jan 2023 17:40:30 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.01.2023 um 17:37 schrieb Muttley@dastardlyhq.com:
>> On Mon, 23 Jan 2023 17:25:49 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>> On Mon, 23 Jan 2023 13:53:55 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>>>
>>>>>>>> Unless you want to parse the string which may involve chopping it
>about.
>>>>> Then
>>>>>>>
>>>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>>>> inefficient substr() etc.
>>>>>>>
>>>>>>> What's wrong with sth. like this ?
>>>>>>>
>>>>>>> string substr()
>>>>>>> {
>>>>>>> 	string hw( "hello world!" );
>>>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>>>> 	hw.resize( 5 );
>>>>>>> 	return hw;
>>>>>>> }
>>>>>>
>>>>>> char *hw = "hello world!";
>>>>>> :
>>>>>> return hw + 5;
>>>>>
>>>>> You're returning a newly created string object, thereby inducing
>>>>
>>>> This is C, not C++. ...
>>>
>>> In a C++-newsgroup and we discussed the topic of copy-allocations ...
>>>
>> 
>> When comparing C vs C++ a discussion of C is entirely appropriate.
>
>Yes, somewhere else in this thread.

Oh ok, now you're subdividing threads are you? You're the one who suggested
that using erase() and substr() was somehow just as efficient as returning
a pointer.

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

#88781 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 18:00 schrieb Muttley@dastardlyhq.com:

> Oh ok, now you're subdividing threads are you? You're the one who suggested
> that using erase() and substr() was somehow just as efficient as returning
> a pointer.

My suggestion was related to the point that changing the string might
result in a new string allocation and I've shown that this change might
occur in-place.

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

#88775 — Re: A string pointer to a static or dynamic string : how to free the

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>> On Mon, 23 Jan 2023 13:53:55 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>
>>>>>> Unless you want to parse the string which may involve chopping it about.
>>> Then
>>>>>
>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>> inefficient substr() etc.
>>>>>
>>>>> What's wrong with sth. like this ?
>>>>>
>>>>> string substr()
>>>>> {
>>>>> 	string hw( "hello world!" );
>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>> 	hw.resize( 5 );
>>>>> 	return hw;
>>>>> }
>>>>
>>>> char *hw = "hello world!";
>>>> :
>>>> return hw + 5;
>>>
>>> You're returning a newly created string object, thereby inducing
>> 
>> This is C, not C++. ...
>
>In a C++-newsgroup and we discussed the topic of copy-allocations ...

What Muttley posted is perfectly legal C++ code.

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

#88778 — Re: A string pointer to a static or dynamic string : how to free the

Am 23.01.2023 um 18:30 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 23.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>> On Mon, 23 Jan 2023 13:53:55 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 23.01.2023 um 10:30 schrieb Muttley@dastardlyhq.com:
>>>>> On Sat, 21 Jan 2023 19:30:48 +0100
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Am 21.01.2023 um 17:20 schrieb Muttley@dastardlyhq.com:
>>>>>>
>>>>>>> Unless you want to parse the string which may involve chopping it about.
>>>> Then
>>>>>>
>>>>>>> its simpler to use a C string and pointers rather than mess about with
>>>>>>> inefficient substr() etc.
>>>>>>
>>>>>> What's wrong with sth. like this ?
>>>>>>
>>>>>> string substr()
>>>>>> {
>>>>>> 	string hw( "hello world!" );
>>>>>> 	hw.erase( hw.begin(), hw.begin() + 6 );
>>>>>> 	hw.resize( 5 );
>>>>>> 	return hw;
>>>>>> }
>>>>>
>>>>> char *hw = "hello world!";
>>>>> :
>>>>> return hw + 5;
>>>>
>>>> You're returning a newly created string object, thereby inducing
>>>
>>> This is C, not C++. ...
>>
>> In a C++-newsgroup and we discussed the topic of copy-allocations ...
> 
> What Muttley posted is perfectly legal C++ code.

Yes, but not in that context.

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

#88768 — Re: A string pointer to a static or dynamic string : how to free the

On Monday, January 23, 2023 at 11:20:25 AM UTC-5, Mut...@dastardlyhq.com wrote:
> On Mon, 23 Jan 2023 13:53:55 +0100
> Bonita Montero <Bonita....@gmail.com> wrote: 
> >Am 23.01.2023 um 10:30 schrieb Mut...@dastardlyhq.com: 
> >> On Sat, 21 Jan 2023 19:30:48 +0100 
> >> Bonita Montero <Bonita....@gmail.com> wrote: 
> >>> Am 21.01.2023 um 17:20 schrieb Mut...@dastardlyhq.com: 
> >>> 
> >>>> Unless you want to parse the string which may involve chopping it about. 
> >Then 
> >>> 
> >>>> its simpler to use a C string and pointers rather than mess about with 
> >>>> inefficient substr() etc. 
> >>> 
> >>> What's wrong with sth. like this ? 
> >>> 
> >>> string substr() 
> >>> { 
> >>> string hw( "hello world!" ); 
> >>> hw.erase( hw.begin(), hw.begin() + 6 ); 
> >>> hw.resize( 5 ); 
> >>> return hw; 
> >>> } 
> >> 
> >> char *hw = "hello world!"; 
> >> : 
> >> return hw + 5; 
> > 
> >You're returning a newly created string object, thereby inducing
> This is C, not C++. ...

Actually, this IS C++. While this  discussion has been about C, it's actually taking place on comp.lang.c++.

> ... There are no objects. ...

As C defines the term "object",  both hw and the array that  "hello world!" points at are objects. However, you are correct in saying that hw+5 would not be an object in C.

> >blem. And you're returning the exclamation mark I also stripped.
> hw[10] = '\0'; 

hw points at the array that was created because of the existence of the string literal "hello world!". 

"If the program attempts to modify such an array, the behavior is undefined." (C standard, 6.4.5p7)

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

#88772 — Re: A string pointer to a static or dynamic string : how to free the

On Mon, 23 Jan 2023 08:40:36 -0800 (PST)
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote:
>On Monday, January 23, 2023 at 11:20:25 AM UTC-5, Mut...@dastardlyhq.com wrote:
>
>> On Mon, 23 Jan 2023 13:53:55 +0100
>> Bonita Montero <Bonita....@gmail.com> wrote: 
>> >Am 23.01.2023 um 10:30 schrieb Mut...@dastardlyhq.com: 
>> >> On Sat, 21 Jan 2023 19:30:48 +0100 
>> >> Bonita Montero <Bonita....@gmail.com> wrote: 
>> >>> Am 21.01.2023 um 17:20 schrieb Mut...@dastardlyhq.com: 
>> >>> 
>> >>>> Unless you want to parse the string which may involve chopping it
>about. 
>> >Then 
>> >>> 
>> >>>> its simpler to use a C string and pointers rather than mess about with 
>> >>>> inefficient substr() etc. 
>> >>> 
>> >>> What's wrong with sth. like this ? 
>> >>> 
>> >>> string substr() 
>> >>> { 
>> >>> string hw( "hello world!" ); 
>> >>> hw.erase( hw.begin(), hw.begin() + 6 ); 
>> >>> hw.resize( 5 ); 
>> >>> return hw; 
>> >>> } 
>> >> 
>> >> char *hw = "hello world!"; 
>> >> : 
>> >> return hw + 5; 
>> > 
>> >You're returning a newly created string object, thereby inducing
>> This is C, not C++. ...
>
>Actually, this IS C++. While this  discussion has been about C, it's actually
>taking place on comp.lang.c++.
>
>> ... There are no objects. ...
>
>As C defines the term "object",  both hw and the array that  "hello world!"
>points at are objects. However, you are correct in saying that hw+5 would not
>be an object in C.
>
>> >blem. And you're returning the exclamation mark I also stripped.
>> hw[10] = '\0'; 
>
>hw points at the array that was created because of the existence of the string
>literal "hello world!". 
>
>"If the program attempts to modify such an array, the behavior is undefined."
>(C standard, 6.4.5p7)

That's true, my mistake. So we change the char* to

char hw[] = "hello world!";

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

#88729

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> This is C++, so just return a std::string from your function, and forget 
> everything about C-style strings, malloc, free and strdup. Good riddance!

When it comes to "C-style strings", not really. After all, they are
essentially just syntactic sugar over arrays of char, and thus have
all the advantages of such arrays.

C++ doesn't really add a "better" equivalent to C-style strings which
would have all the efficiency benefits of them. std::string_view gets
close, and in some cases it's actually the better choice, but it's not
exactly the same thing (for starters, it's larger than the size of a
pointer which, while in many cases that's inconsequential, sometimes
it can be a deal breaker).

And rather obviously std::string cannot completely replace C-style
strings. While safetywise and featurewise it's mostly superior (save
for a few exceptional cases), its problem is that it's always
dynamically allocated and doesn't support statically allocated
strings (which is the very reason why std::string_view was created,
to support that very thing).

In most cases avoiding the dynamic allocation may be completely
unnecessary and without any benefit. However, in the situations
where avoiding it does introduce a significant benefit it's good
to have the alternative. Especially if all you need to handle the
data is a pointer (and thus std::string_view would be overkill).

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

#88743

23.01.2023 08:34 Juha Nieminen kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> This is C++, so just return a std::string from your function, and forget
>> everything about C-style strings, malloc, free and strdup. Good riddance!
> 
> When it comes to "C-style strings", not really. After all, they are
> essentially just syntactic sugar over arrays of char, and thus have
> all the advantages of such arrays.
> 
> C++ doesn't really add a "better" equivalent to C-style strings which
> would have all the efficiency benefits of them. std::string_view gets
> close, and in some cases it's actually the better choice, but it's not
> exactly the same thing (for starters, it's larger than the size of a
> pointer which, while in many cases that's inconsequential, sometimes
> it can be a deal breaker).
> 
> And rather obviously std::string cannot completely replace C-style
> strings. While safetywise and featurewise it's mostly superior (save
> for a few exceptional cases), its problem is that it's always
> dynamically allocated and doesn't support statically allocated
> strings (which is the very reason why std::string_view was created,
> to support that very thing).

Maybe you meant "dynamically initialized", not "dynamically allocated"? 
AFAIK there is no guarantee a std::string would always involve dynamic 
allocation, and with short strings it often does not.

Dynamic initialization might indeed be a problem because in C++ the 
order of global statics initialization is not very well determined, and 
there is a danger to access the object before its creation or after its 
destruction. But strictly speaking, this is a problem with dynamic 
initialization, not dynamic allocation (although it might be the 
allocation step which is failing).

> 
> In most cases avoiding the dynamic allocation may be completely
> unnecessary and without any benefit. However, in the situations
> where avoiding it does introduce a significant benefit it's good
> to have the alternative. Especially if all you need to handle the
> data is a pointer (and thus std::string_view would be overkill).

It's true that when striving for max performance, using C-style strings 
might sometimes have benefits. I myself have coded large global C-style 
arrays containing C-style string constants, sorted by hand for faster 
lookup at run time. However, the OP claims he is novice in C++, aiming 
for a simple solution, so he should not deal with such nuances before he 
has got some years of experience under his belt.

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

#88744

Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> And rather obviously std::string cannot completely replace C-style
>> strings. While safetywise and featurewise it's mostly superior (save
>> for a few exceptional cases), its problem is that it's always
>> dynamically allocated and doesn't support statically allocated
>> strings (which is the very reason why std::string_view was created,
>> to support that very thing).
> 
> Maybe you meant "dynamically initialized", not "dynamically allocated"? 
> AFAIK there is no guarantee a std::string would always involve dynamic 
> allocation, and with short strings it often does not.

Short string optimization is not guaranteed by the standard and, thus,
you cannot rely on it. Additionally, even when it is implemented, you
have no way of controlling how large the "short" string is (which would
actually be a nice feature; I believe Boost has "short" data optimizing
containers where you can actually determine the size of that "short data".
But alas, that's not standard.)

Even more additionally, if short string optimization is implemented,
you pay the price of having an additional conditional on each single
access and operation you do to the string, whether you want it or not
(there's no way to turn it off if you wanted to). Sure, in most
situations this additional conditional is inconsequential, but in
those situations where you need to squeeze the last clock cycle out
of your code you will be paying the price.

I would even go as far as saying that it would be better if
implementations *don't* use short string optimization, because
then you get a consistent guaranteed behavior without surprising
side effects (in terms of performance). A "short (whatever)
optimizing" data container should be its own thing (like in Boost).

> Dynamic initialization might indeed be a problem because in C++ the 
> order of global statics initialization is not very well determined, and 
> there is a danger to access the object before its creation or after its 
> destruction. But strictly speaking, this is a problem with dynamic 
> initialization, not dynamic allocation (although it might be the 
> allocation step which is failing).

Dynamic memory allocation is slow (relatively speaking) and causes other
optimization problems such as memory fragmentation. In most situations
this is inconsequential but, as mentioned, when you need to squeeze
the last clock cycles out of the code...

> It's true that when striving for max performance, using C-style strings 
> might sometimes have benefits. I myself have coded large global C-style 
> arrays containing C-style string constants, sorted by hand for faster 
> lookup at run time. However, the OP claims he is novice in C++, aiming 
> for a simple solution, so he should not deal with such nuances before he 
> has got some years of experience under his belt.

Novice or not, I think it's not good advise to just say "forget about
C style strings, they are completely obsolete and not to be used".

Perhaps something more along the lines of: "It's better to just use
std::string in this case. It's much easier and much safer, and offers
a lot more features."

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

#88745

On Monday, 23 January 2023 at 11:52:01 UTC, Juha Nieminen wrote:
> 
> Novice or not, I think it's not good advise to just say "forget about 
> C style strings, they are completely obsolete and not to be used". 
> 
> Perhaps something more along the lines of: "It's better to just use 
> std::string in this case. It's much easier and much safer, and offers 
> a lot more features."
>
It's often easier to construct a string in a C style buffer, and easier to parse.

But std::strings can be copied and assigned. So it's much easier to pass
the strings around. Most strings in most programs are quite short, and
execution time and memory use isn't very relevant.

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

#88749

On Monday, January 23, 2023 at 7:52:01 PM UTC+8, Juha Nieminen wrote:
> Paavo Helde <ees...@osa.pri.ee> wrote: 
> >> And rather obviously std::string cannot completely replace C-style 
> >> strings. While safetywise and featurewise it's mostly superior (save 
> >> for a few exceptional cases), its problem is that it's always 
> >> dynamically allocated and doesn't support statically allocated 
> >> strings (which is the very reason why std::string_view was created, 
> >> to support that very thing). 
> > 
> > Maybe you meant "dynamically initialized", not "dynamically allocated"? 
> > AFAIK there is no guarantee a std::string would always involve dynamic 
> > allocation, and with short strings it often does not.
> Short string optimization is not guaranteed by the standard and, thus, 
> you cannot rely on it. Additionally, even when it is implemented, you 
> have no way of controlling how large the "short" string is (which would 
> actually be a nice feature; I believe Boost has "short" data optimizing 
> containers where you can actually determine the size of that "short data". 
> But alas, that's not standard.) 
> 
> Even more additionally, if short string optimization is implemented, 
> you pay the price of having an additional conditional on each single 
> access and operation you do to the string, whether you want it or not 
> (there's no way to turn it off if you wanted to). Sure, in most 
> situations this additional conditional is inconsequential, but in 
> those situations where you need to squeeze the last clock cycle out 
> of your code you will be paying the price. 
> 
> I would even go as far as saying that it would be better if 
> implementations *don't* use short string optimization, because 
> then you get a consistent guaranteed behavior without surprising 
> side effects (in terms of performance). A "short (whatever) 
> optimizing" data container should be its own thing (like in Boost).
> > Dynamic initialization might indeed be a problem because in C++ the 
> > order of global statics initialization is not very well determined, and 
> > there is a danger to access the object before its creation or after its 
> > destruction. But strictly speaking, this is a problem with dynamic 
> > initialization, not dynamic allocation (although it might be the 
> > allocation step which is failing).
> Dynamic memory allocation is slow (relatively speaking) and causes other 
> optimization problems such as memory fragmentation. In most situations 
> this is inconsequential but, as mentioned, when you need to squeeze 
> the last clock cycles out of the code...
> > It's true that when striving for max performance, using C-style strings 
> > might sometimes have benefits. I myself have coded large global C-style 
> > arrays containing C-style string constants, sorted by hand for faster 
> > lookup at run time. However, the OP claims he is novice in C++, aiming 
> > for a simple solution, so he should not deal with such nuances before he 
> > has got some years of experience under his belt.
> Novice or not, I think it's not good advise to just say "forget about 
> C style strings, they are completely obsolete and not to be used". 
> 
> Perhaps something more along the lines of: "It's better to just use 
> std::string in this case. It's much easier and much safer, and offers 
> a lot more features."

c-string or std::string are library (implementing) stuff, not really The language.
C/C++ just says any character sequence ending with 0 is a string.

struct AA {
 char aa[33];
 AA() { aa[32]=0; };
} aa;

AA* ptr=&aa;   // (char*)ptr points to a string?
'string' is human question, not the CPU's problem.

For commercial programs, I would select QString (and QCString).
I also have my String, no string class is generally better.
So, in the end, it is still c-string. OS demands c-string.

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

#88679

On 1/21/23 9:28 AM, 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
> 
> 

There is no portable way of telling. As others have mentioned, 
std:string lets you get around this problem. In a standard 
implementation this will copy the static string into the heap, so 
std:string knows to always delete its version.

In embedded applications where space may be tight, I use a replacement 
version for std::string that looks where the pointer for the string is 
coming from, and if it is in system flash, I know it can't change, so I 
don't copy it, and inside the string class keep track of that fact.

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

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

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

csiph-web