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

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

How to free this memory?

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

Contents

  How to free this memory? Bint <bint@ign.com> - 2012-01-13 11:05 -0600
    Re: How to free this memory? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-13 18:37 +0100
      Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 18:07 +0000
        Re: How to free this memory? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-13 19:38 +0100
          Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 20:35 +0000
            Re: How to free this memory? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-14 02:16 -0800
            Re: How to free this memory? Kevin McCarty <kmccarty@gmail.com> - 2012-01-16 09:08 -0800
        Re: How to free this memory? Kevin McCarty <kmccarty@gmail.com> - 2012-01-13 10:48 -0800
          Re: How to free this memory? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-14 02:19 -0800
            Re: How to free this memory? Kevin McCarty <kmccarty@gmail.com> - 2012-01-16 08:56 -0800
      Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 18:16 +0000
    Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 17:37 +0000
      Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 17:47 +0000
        Re: How to free this memory? Bint <bint@ign.com> - 2012-01-13 12:04 -0600
          Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 18:10 +0000
            Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 19:20 +0000
              Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 19:27 +0000
                Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 19:52 +0000
                  Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 20:33 +0000
                    Re: How to free this memory? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-13 20:52 +0000
                      Re: How to free this memory? David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-13 15:01 -0600
                      Re: How to free this memory? BCFD36 <bcfd36@cruzio.com> - 2012-01-14 02:01 -0800
                    Re: How to free this memory? "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-13 15:46 -0600
                      Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-13 21:59 +0000
                    Re: How to free this memory? Goran <goran.pusic@gmail.com> - 2012-01-13 22:12 -0800
                      Re: How to free this memory? Leigh Johnston <leigh@i42.co.uk> - 2012-01-14 11:58 +0000
              Re: How to free this memory? Goran <goran.pusic@gmail.com> - 2012-01-13 22:01 -0800
          Re: How to free this memory? Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-13 13:48 -0500
          Re: How to free this memory? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-14 20:46 +0000
      Re: How to free this memory? Bint <bint@ign.com> - 2012-01-13 11:54 -0600
    Re: How to free this memory? Travis Vitek <travis.vitek@gmail.com> - 2012-01-13 09:21 -0800
      Re: How to free this memory? jgk@panix.com (Joe keane) - 2012-01-14 01:03 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13360

"Paul" <pchrist<nospam>or@yahoo.co.uk> writes:

> "Leigh Johnston" <leigh@i42.co.uk> wrote in message 
> news:Q5adnfNSlPy5CI3SnZ2dnUVZ8uudnZ2d@giganews.com...
>> On 13/01/2012 19:52, Paul <pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>>> news:zaCdnbr0KNdYGI3SnZ2dnUVZ8tmdnZ2d@giganews.com...
>>>> On 13/01/2012 19:20, Paul<pchrist wrote:
>>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>>> news:bvWdnUQB5qwO7o3SnZ2dnUVZ8smdnZ2d@giganews.com...
>>>>>> On 13/01/2012 18:04, Bint wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 13/01/2012 17:37, Paul<pchrist wrote:
>>>>>>>>> "Bint"<bint@ign.com>     wrote in message
>>>>>>>>> news:CB35C06F.B997%bint@ign.com...
>>>>>>>>>> Hello, I am allocating some vertices to pass to a function, and 
>>>>>>>>>> then
>>>>>>>>>> I
>>>>>>>>>> want
>>>>>>>>>> to free the memory.  How do I do this?  The compiler is giving me
>>>>>>>>>> warnings
>>>>>>>>>> when I do it this way:
>>>>>>>>>>
>>>>>>>>>>            trivertex **vertices;
>>>>>>>>>>
>>>>>>>>>>            vertices = new trivertex*[2];
>>>>>>>>>>
>>>>>>>>>>            vertices[0] = new trivertex[100];
>>>>>>>>>>            vertices[1] = new trivertex[50];
>>>>>>>>>>
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>>            delete vertices[0];
>>>>>>>>>>            delete vertices[1];
>>>>>>>>>>            delete vertices;
>>>>>>>>>>
>>>>>>>>>> I get this warning:
>>>>>>>>>> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka
>>>>>>>>>> 'double
>>>>>>>>>> (*)[3]') treated as delete"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> B
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> You should use delete[] , to delete memory allocated with new [].
>>>>>>>>> So...
>>>>>>>>> delete[] veritces[0];
>>>>>>>>> delete[] vertices[1];
>>>>>>>>> delete[] vertices;
>>>>>>>>
>>>>>>>> Yes you do delete[] what you new[] however the poster should use
>>>>>>>> std::vector as Alf suggests; it is very rare that you need to use
>>>>>>>> dynamically allocated arrays these days.
>>>>>>>>
>>>>>>>> One use-case for dynamically allocated arrays is when you want a
>>>>>>>> dynamically sized *uninitialized* buffer.
>>>>>>>>
>>>>>>>> /Leigh
>>>>>>>
>>>>>>> I don't have any experience with namespaces or std:vector.  I will 
>>>>>>> try
>>>>>>> it
>>>>>>> and see if what Alf posted works in my code.
>>>>>>>
>>>>>>> But if delete[] works, then what is wrong with using it?
>>>>>>
>>>>>> One advantage of std::vector is that you don't have to worry about
>>>>>> calling
>>>>>> delete[] or memory leaks as std::vector takes care of this
>>>>>> automatically.
>>>>>> The standard containers offer many other advantages also such as
>>>>>> exception
>>>>>> safety and a rich interface for modifying the container's controlled
>>>>>> sequence (its elements).
>>>>>
>>>>> I think there is a large division , in this newsgroup, about what is
>>>>> exception safety. You are correct to say that exception safety is very
>>>>> important when it comes to a decision about dynamic allocation or
>>>>> allowing
>>>>> STL allocators to handle it.
>>>>> However I cannot correlate this to your view that all programs should
>>>>> simply
>>>>> terminate when an exception is thrown because with this view it doesn't
>>>>> make
>>>>> any difference. If a program terminates who cares what memory has been
>>>>> allocated/deallocated?
>>>>
>>>> Again with the misrepresentation.  I *never* said that *all* programs
>>>> should simply terminate; I said that termination is acceptable behaviour
>>>> for *some* programs; "some" does not equal "all".
>>>>
>>> Ok but I think you were on the side arguing that *most* programs should 
>>> just
>>> terminate on bad alloc.
>>> Maybe I am mistaken, please clarify.
>>
>> It is impossible to quantify exactly but yes I am of the opinion that 
>> *most* programs can't function (meet their requirements) if *any* 
>> allocation they make fails in which case termination is acceptable.
>>
>> An example of a program that *should* perhaps catch bad_alloc would be a 
>> program that can open/edit "documents" where opening or editing a document 
>> can fail due to insufficient memory.
>>
>> A program which can have human safety implications should probably 
>> allocate *all* the memory it needs to meet its requirements up front 
>> nullifying any chance of a bad_alloc being thrown once the program has 
>> successfully started.
>>
> Lets simplify it..... If you have a system where the amount of available 
> memory is known.  Say a sattellite , then what are the possible causes of a 
> bad_alloc?
> Is there still a case for error checking allocations? What other errors can 
> occur during a memory allocation, other than a low memory condition?

The structure keeping track of free memory could be corrupted.  And the
memory allocation code itself could be corrupted.  

> IMO its very similar to checking for a disc read/write error. By testing for 
> bad alloc , your program is confirming the integrity of the memory acccess 
> operation.
>
> Say a sattellite orbiting the earth hit a  moot point in the earths magnetic 
> feild and becomes unstable due to particles from the sun, is it possible 
> that a write to memory could fail? If so is it not the case that this 
> allocation has failed due to circumstances other than a low memory 
> condition?

There *is* that old rule "never test for an error condition you don't
know how to handle".
-- 
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

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

#13367

On 1/13/12 12:52 PM, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:Q5adnfNSlPy5CI3SnZ2dnUVZ8uudnZ2d@giganews.com...
>> On 13/01/2012 19:52, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:zaCdnbr0KNdYGI3SnZ2dnUVZ8tmdnZ2d@giganews.com...
>>>> On 13/01/2012 19:20, Paul<pchrist wrote:
>>>>> "Leigh Johnston"<leigh@i42.co.uk>    wrote in message
>>>>> news:bvWdnUQB5qwO7o3SnZ2dnUVZ8smdnZ2d@giganews.com...
>>>>>> On 13/01/2012 18:04, Bint wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 13/01/2012 17:37, Paul<pchrist wrote:
>>>>>>>>> "Bint"<bint@ign.com>      wrote in message
>>>>>>>>> news:CB35C06F.B997%bint@ign.com...
>>>>>>>>>> Hello, I am allocating some vertices to pass to a function, and
>>>>>>>>>> then
>>>>>>>>>> I
>>>>>>>>>> want
>>>>>>>>>> to free the memory.  How do I do this?  The compiler is giving me
>>>>>>>>>> warnings
>>>>>>>>>> when I do it this way:
>>>>>>>>>>
>>>>>>>>>>             trivertex **vertices;
>>>>>>>>>>
>>>>>>>>>>             vertices = new trivertex*[2];
>>>>>>>>>>
>>>>>>>>>>             vertices[0] = new trivertex[100];
>>>>>>>>>>             vertices[1] = new trivertex[50];
>>>>>>>>>>
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>>             delete vertices[0];
>>>>>>>>>>             delete vertices[1];
>>>>>>>>>>             delete vertices;
>>>>>>>>>>
>>>>>>>>>> I get this warning:
>>>>>>>>>> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka
>>>>>>>>>> 'double
>>>>>>>>>> (*)[3]') treated as delete"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> B
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> You should use delete[] , to delete memory allocated with new [].
>>>>>>>>> So...
>>>>>>>>> delete[] veritces[0];
>>>>>>>>> delete[] vertices[1];
>>>>>>>>> delete[] vertices;
>>>>>>>>
>>>>>>>> Yes you do delete[] what you new[] however the poster should use
>>>>>>>> std::vector as Alf suggests; it is very rare that you need to use
>>>>>>>> dynamically allocated arrays these days.
>>>>>>>>
>>>>>>>> One use-case for dynamically allocated arrays is when you want a
>>>>>>>> dynamically sized *uninitialized* buffer.
>>>>>>>>
>>>>>>>> /Leigh
>>>>>>>
>>>>>>> I don't have any experience with namespaces or std:vector.  I will
>>>>>>> try
>>>>>>> it
>>>>>>> and see if what Alf posted works in my code.
>>>>>>>
>>>>>>> But if delete[] works, then what is wrong with using it?
>>>>>>
>>>>>> One advantage of std::vector is that you don't have to worry about
>>>>>> calling
>>>>>> delete[] or memory leaks as std::vector takes care of this
>>>>>> automatically.
>>>>>> The standard containers offer many other advantages also such as
>>>>>> exception
>>>>>> safety and a rich interface for modifying the container's controlled
>>>>>> sequence (its elements).
>>>>>
>>>>> I think there is a large division , in this newsgroup, about what is
>>>>> exception safety. You are correct to say that exception safety is very
>>>>> important when it comes to a decision about dynamic allocation or
>>>>> allowing
>>>>> STL allocators to handle it.
>>>>> However I cannot correlate this to your view that all programs should
>>>>> simply
>>>>> terminate when an exception is thrown because with this view it doesn't
>>>>> make
>>>>> any difference. If a program terminates who cares what memory has been
>>>>> allocated/deallocated?
>>>>
>>>> Again with the misrepresentation.  I *never* said that *all* programs
>>>> should simply terminate; I said that termination is acceptable behaviour
>>>> for *some* programs; "some" does not equal "all".
>>>>
>>> Ok but I think you were on the side arguing that *most* programs should
>>> just
>>> terminate on bad alloc.
>>> Maybe I am mistaken, please clarify.
>>
>> It is impossible to quantify exactly but yes I am of the opinion that
>> *most* programs can't function (meet their requirements) if *any*
>> allocation they make fails in which case termination is acceptable.
>>
>> An example of a program that *should* perhaps catch bad_alloc would be a
>> program that can open/edit "documents" where opening or editing a document
>> can fail due to insufficient memory.
>>
>> A program which can have human safety implications should probably
>> allocate *all* the memory it needs to meet its requirements up front
>> nullifying any chance of a bad_alloc being thrown once the program has
>> successfully started.
>>
> Lets simplify it..... If you have a system where the amount of available
> memory is known.  Say a sattellite , then what are the possible causes of a
> bad_alloc?
> Is there still a case for error checking allocations? What other errors can
> occur during a memory allocation, other than a low memory condition?

Typically, you don't do run time allocates on satellites, at least the 
ones with which I am familiar. It doesn't go over well in code reviews. 
People will come by your cube and look at you, then scurry away and laugh.

>
> IMO its very similar to checking for a disc read/write error. By testing for
> bad alloc , your program is confirming the integrity of the memory acccess
> operation.
>
> Say a sattellite orbiting the earth hit a  moot point in the earths magnetic
> feild and becomes unstable due to particles from the sun, is it possible
> that a write to memory could fail?

Yes. It does happen. Sometimes it is a single bit. The code section of 
memory is checksummed on a regular basis.

> If so is it not the case that this
> allocation has failed due to circumstances other than a low memory
> condition?

On the nosey!




-- 
Dave Scruggs

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

#13361

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:Q5adnfNSlPy5CI3SnZ2dnUVZ8uudnZ2d@giganews.com...
> An example of a program that *should* perhaps catch bad_alloc would be a 
> program that can open/edit "documents" where opening or editing a document 
> can fail due to insufficient memory.

It might be more valid, or at least just as valid, for that type of program 
to use a different strategy, perhaps one that doesn't require keeping the 
entire document resident in heap memory.

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

#13362

On 13/01/2012 21:46, MikeWhy wrote:
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:Q5adnfNSlPy5CI3SnZ2dnUVZ8uudnZ2d@giganews.com...
>> An example of a program that *should* perhaps catch bad_alloc would be
>> a program that can open/edit "documents" where opening or editing a
>> document can fail due to insufficient memory.
>
> It might be more valid, or at least just as valid, for that type of
> program to use a different strategy, perhaps one that doesn't require
> keeping the entire document resident in heap memory.

I was thinking more along the lines of a program that can open multiple 
documents and allocating memory for document "n + 1" fails but yes what 
you say is valid too.

/Leigh

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

#13365

On Jan 13, 9:33 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 13/01/2012 19:52, Paul <pchrist wrote:
>
>
>
>
>
>
>
>
>
> > "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> >news:zaCdnbr0KNdYGI3SnZ2dnUVZ8tmdnZ2d@giganews.com...
> >> On 13/01/2012 19:20, Paul<pchrist wrote:
> >>> "Leigh Johnston"<le...@i42.co.uk>   wrote in message
> >>>news:bvWdnUQB5qwO7o3SnZ2dnUVZ8smdnZ2d@giganews.com...
> >>>> On 13/01/2012 18:04, Bint wrote:
>
> >>>>>> On 13/01/2012 17:37, Paul<pchrist wrote:
> >>>>>>> "Bint"<b...@ign.com>     wrote in message
> >>>>>>>news:CB35C06F.B997%bint@ign.com...
> >>>>>>>> Hello, I am allocating some vertices to pass to a function, and then
> >>>>>>>> I
> >>>>>>>> want
> >>>>>>>> to free the memory.  How do I do this?  The compiler is giving me
> >>>>>>>> warnings
> >>>>>>>> when I do it this way:
>
> >>>>>>>>            trivertex **vertices;
>
> >>>>>>>>            vertices = new trivertex*[2];
>
> >>>>>>>>            vertices[0] = new trivertex[100];
> >>>>>>>>            vertices[1] = new trivertex[50];
>
> >>>>>>>> .
> >>>>>>>> .
> >>>>>>>> .
> >>>>>>>>            delete vertices[0];
> >>>>>>>>            delete vertices[1];
> >>>>>>>>            delete vertices;
>
> >>>>>>>> I get this warning:
> >>>>>>>> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka
> >>>>>>>> 'double
> >>>>>>>> (*)[3]') treated as delete"
>
> >>>>>>>> Thanks!
> >>>>>>>> B
>
> >>>>>>> Hi
>
> >>>>>>> You should use delete[] , to delete memory allocated with new [].
> >>>>>>> So...
> >>>>>>> delete[] veritces[0];
> >>>>>>> delete[] vertices[1];
> >>>>>>> delete[] vertices;
>
> >>>>>> Yes you do delete[] what you new[] however the poster should use
> >>>>>> std::vector as Alf suggests; it is very rare that you need to use
> >>>>>> dynamically allocated arrays these days.
>
> >>>>>> One use-case for dynamically allocated arrays is when you want a
> >>>>>> dynamically sized *uninitialized* buffer.
>
> >>>>>> /Leigh
>
> >>>>> I don't have any experience with namespaces or std:vector.  I will try
> >>>>> it
> >>>>> and see if what Alf posted works in my code.
>
> >>>>> But if delete[] works, then what is wrong with using it?
>
> >>>> One advantage of std::vector is that you don't have to worry about
> >>>> calling
> >>>> delete[] or memory leaks as std::vector takes care of this
> >>>> automatically.
> >>>> The standard containers offer many other advantages also such as
> >>>> exception
> >>>> safety and a rich interface for modifying the container's controlled
> >>>> sequence (its elements).
>
> >>> I think there is a large division , in this newsgroup, about what is
> >>> exception safety. You are correct to say that exception safety is very
> >>> important when it comes to a decision about dynamic allocation or
> >>> allowing
> >>> STL allocators to handle it.
> >>> However I cannot correlate this to your view that all programs should
> >>> simply
> >>> terminate when an exception is thrown because with this view it doesn't
> >>> make
> >>> any difference. If a program terminates who cares what memory has been
> >>> allocated/deallocated?
>
> >> Again with the misrepresentation.  I *never* said that *all* programs
> >> should simply terminate; I said that termination is acceptable behaviour
> >> for *some* programs; "some" does not equal "all".
>
> > Ok but I think you were on the side arguing that *most* programs should just
> > terminate on bad alloc.
> > Maybe I am mistaken, please clarify.
>
> It is impossible to quantify exactly but yes I am of the opinion that
> *most* programs can't function (meet their requirements) if *any*
> allocation they make fails in which case termination is acceptable.

I, however, am of the opposite opinion. There is one class of programs
that can do that: one that is effectively one long function (e.g. a
console program that takes some arguments, does whatever it needs
done, then exits, without any loops involving external interaction). I
believe that such programs are rare these days.

There's one other thing: a lot of code ends up being used elsewhere
(through libraries, or copy-paste, or copy-paste-modify a bit). So it
can very well be written in "your" class of programs, but also end up
in "my" class of programs ("yours" and mine" not intended to sound
disparaging). It is very dangerous, therefore, to presume termination
upon allocation failure in any code (and e.g. drop exception safety,
or rig malloc/new to terminate on the spot, or not check result of
malloc / improbable new(nothrow)). I reckon you aren't arguing any of
that, but it's worth noting.

Goran.

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

#13370

On 14/01/2012 06:12, Goran wrote:
> On Jan 13, 9:33 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 13/01/2012 19:52, Paul<pchrist wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> "Leigh Johnston"<le...@i42.co.uk>    wrote in message
>>> news:zaCdnbr0KNdYGI3SnZ2dnUVZ8tmdnZ2d@giganews.com...
>>>> On 13/01/2012 19:20, Paul<pchrist wrote:
>>>>> "Leigh Johnston"<le...@i42.co.uk>     wrote in message
>>>>> news:bvWdnUQB5qwO7o3SnZ2dnUVZ8smdnZ2d@giganews.com...
>>>>>> On 13/01/2012 18:04, Bint wrote:
>>
>>>>>>>> On 13/01/2012 17:37, Paul<pchrist wrote:
>>>>>>>>> "Bint"<b...@ign.com>       wrote in message
>>>>>>>>> news:CB35C06F.B997%bint@ign.com...
>>>>>>>>>> Hello, I am allocating some vertices to pass to a function, and then
>>>>>>>>>> I
>>>>>>>>>> want
>>>>>>>>>> to free the memory.  How do I do this?  The compiler is giving me
>>>>>>>>>> warnings
>>>>>>>>>> when I do it this way:
>>
>>>>>>>>>>             trivertex **vertices;
>>
>>>>>>>>>>             vertices = new trivertex*[2];
>>
>>>>>>>>>>             vertices[0] = new trivertex[100];
>>>>>>>>>>             vertices[1] = new trivertex[50];
>>
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>> .
>>>>>>>>>>             delete vertices[0];
>>>>>>>>>>             delete vertices[1];
>>>>>>>>>>             delete vertices;
>>
>>>>>>>>>> I get this warning:
>>>>>>>>>> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka
>>>>>>>>>> 'double
>>>>>>>>>> (*)[3]') treated as delete"
>>
>>>>>>>>>> Thanks!
>>>>>>>>>> B
>>
>>>>>>>>> Hi
>>
>>>>>>>>> You should use delete[] , to delete memory allocated with new [].
>>>>>>>>> So...
>>>>>>>>> delete[] veritces[0];
>>>>>>>>> delete[] vertices[1];
>>>>>>>>> delete[] vertices;
>>
>>>>>>>> Yes you do delete[] what you new[] however the poster should use
>>>>>>>> std::vector as Alf suggests; it is very rare that you need to use
>>>>>>>> dynamically allocated arrays these days.
>>
>>>>>>>> One use-case for dynamically allocated arrays is when you want a
>>>>>>>> dynamically sized *uninitialized* buffer.
>>
>>>>>>>> /Leigh
>>
>>>>>>> I don't have any experience with namespaces or std:vector.  I will try
>>>>>>> it
>>>>>>> and see if what Alf posted works in my code.
>>
>>>>>>> But if delete[] works, then what is wrong with using it?
>>
>>>>>> One advantage of std::vector is that you don't have to worry about
>>>>>> calling
>>>>>> delete[] or memory leaks as std::vector takes care of this
>>>>>> automatically.
>>>>>> The standard containers offer many other advantages also such as
>>>>>> exception
>>>>>> safety and a rich interface for modifying the container's controlled
>>>>>> sequence (its elements).
>>
>>>>> I think there is a large division , in this newsgroup, about what is
>>>>> exception safety. You are correct to say that exception safety is very
>>>>> important when it comes to a decision about dynamic allocation or
>>>>> allowing
>>>>> STL allocators to handle it.
>>>>> However I cannot correlate this to your view that all programs should
>>>>> simply
>>>>> terminate when an exception is thrown because with this view it doesn't
>>>>> make
>>>>> any difference. If a program terminates who cares what memory has been
>>>>> allocated/deallocated?
>>
>>>> Again with the misrepresentation.  I *never* said that *all* programs
>>>> should simply terminate; I said that termination is acceptable behaviour
>>>> for *some* programs; "some" does not equal "all".
>>
>>> Ok but I think you were on the side arguing that *most* programs should just
>>> terminate on bad alloc.
>>> Maybe I am mistaken, please clarify.
>>
>> It is impossible to quantify exactly but yes I am of the opinion that
>> *most* programs can't function (meet their requirements) if *any*
>> allocation they make fails in which case termination is acceptable.
>
> I, however, am of the opposite opinion. There is one class of programs
> that can do that: one that is effectively one long function (e.g. a
> console program that takes some arguments, does whatever it needs
> done, then exits, without any loops involving external interaction). I
> believe that such programs are rare these days.
>
> There's one other thing: a lot of code ends up being used elsewhere
> (through libraries, or copy-paste, or copy-paste-modify a bit). So it
> can very well be written in "your" class of programs, but also end up
> in "my" class of programs ("yours" and mine" not intended to sound
> disparaging). It is very dangerous, therefore, to presume termination
> upon allocation failure in any code (and e.g. drop exception safety,
> or rig malloc/new to terminate on the spot, or not check result of
> malloc / improbable new(nothrow)). I reckon you aren't arguing any of
> that, but it's worth noting.

I never presume termination upon allocation failure; I write a lot of 
library code and it is up to the consumer of a library to decide on 
termination or not by either catching exceptions or not.

/Leigh

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

#13364

On Jan 13, 8:20 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
>
> news:bvWdnUQB5qwO7o3SnZ2dnUVZ8smdnZ2d@giganews.com...
>
>
>
>
>
>
>
>
>
> > On 13/01/2012 18:04, Bint wrote:
>
> >>> On 13/01/2012 17:37, Paul<pchrist wrote:
> >>>> "Bint"<b...@ign.com>   wrote in message
> >>>>news:CB35C06F.B997%bint@ign.com...
> >>>>> Hello, I am allocating some vertices to pass to a function, and then I
> >>>>> want
> >>>>> to free the memory.  How do I do this?  The compiler is giving me
> >>>>> warnings
> >>>>> when I do it this way:
>
> >>>>>          trivertex **vertices;
>
> >>>>>          vertices = new trivertex*[2];
>
> >>>>>          vertices[0] = new trivertex[100];
> >>>>>          vertices[1] = new trivertex[50];
>
> >>>>> .
> >>>>> .
> >>>>> .
> >>>>>          delete vertices[0];
> >>>>>          delete vertices[1];
> >>>>>          delete vertices;
>
> >>>>> I get this warning:
> >>>>> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka
> >>>>> 'double
> >>>>> (*)[3]') treated as delete"
>
> >>>>> Thanks!
> >>>>> B
>
> >>>> Hi
>
> >>>> You should use delete[] , to delete memory allocated with new [].
> >>>> So...
> >>>> delete[] veritces[0];
> >>>> delete[] vertices[1];
> >>>> delete[] vertices;
>
> >>> Yes you do delete[] what you new[] however the poster should use
> >>> std::vector as Alf suggests; it is very rare that you need to use
> >>> dynamically allocated arrays these days.
>
> >>> One use-case for dynamically allocated arrays is when you want a
> >>> dynamically sized *uninitialized* buffer.
>
> >>> /Leigh
>
> >> I don't have any experience with namespaces or std:vector.  I will try it
> >> and see if what Alf posted works in my code.
>
> >> But if delete[] works, then what is wrong with using it?
>
> > One advantage of std::vector is that you don't have to worry about calling
> > delete[] or memory leaks as std::vector takes care of this automatically.
> > The standard containers offer many other advantages also such as exception
> > safety and a rich interface for modifying the container's controlled
> > sequence (its elements).
>
> I think there is a large division , in this newsgroup, about what is
> exception safety.

You misunderstood the discussion or have poorly expressed yourself.

It's not disputed (in this newsgroup) what exception safety __is__
(see Wikipedia and boost's site). It __is__ disputed what exceptions
to handle and when, and it __is__ disputed when it is OK to drop
exception safety (e.g. by terminating on the spot; note that
terminating after catching the exception in "main" upholds exception
safety).

Goran.

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

#13352

On 1/13/2012 1:04 PM, Bint wrote:
>[..]
> I don't have any experience with namespaces or std:vector.  I will try it
> and see if what Alf posted works in my code.
>
> But if delete[] works, then what is wrong with using it?

Not much, only you have to remember to actually use it, and it's not 
exception-safe.  Although I suspect the latter doesn't really apply to you.

V
-- 
I do not respond to top-posted replies, please don't ask

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

#13371

On Fri, 2012-01-13, Bint wrote:
...
> I don't have any experience with namespaces or std:vector.  I will try it
> and see if what Alf posted works in my code.
>
> But if delete[] works, then what is wrong with using it?

One thing is that it prevents you from learning about std::vector,
which is one of the *really basic* and useful tools the language
offers.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#13344

> Hi
> 
> You should use delete[] , to delete memory allocated with new [].
> So...
> delete[] veritces[0];
> delete[] vertices[1];
> delete[] vertices;
> 
> 
> HTH.
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net
> ---


Thank You!
B

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

#13342

On Jan 13, 9:05 am, Bint <b...@ign.com> wrote:
> Hello, I am allocating some vertices to pass to a function, and then I want
> to free the memory.  How do I do this?  The compiler is giving me warnings
> when I do it this way:
>
>         trivertex **vertices;
>
>         vertices = new trivertex*[2];
>
>         vertices[0] = new trivertex[100];
>         vertices[1] = new trivertex[50];
>
> .
> .
> .
>         delete vertices[0];
>         delete vertices[1];
>         delete vertices;
>
> I get this warning:
> " 'delete' applied to a pointer-to-array type 'trivertex *' (aka 'double
> (*)[3]') treated as delete"
>
> Thanks!
> B

You need to use array delete. i.e.,

  delete [] vertices[1];
  delete [] vertices[0];
  delete [] vertices;

Travis

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

#13363

In article <efea738f-d88a-42c8-8e36-d76f13447b7f@a8g2000pbi.googlegroups.com>,
Travis Vitek  <travis.vitek@gmail.com> wrote:
>On Jan 13, 9:05 am, Bint <b...@ign.com> wrote:
>>         trivertex **vertices;
>>
>>         vertices = new trivertex*[2];
>>
>>         vertices[0] = new trivertex[100];
>>         vertices[1] = new trivertex[50];
>>
>> .
>> .
>> .
>>         delete vertices[0];
>>         delete vertices[1];
>>         delete vertices;
>
>You need to use array delete. i.e.,
>
>  delete [] vertices[1];
>  delete [] vertices[0];
>  delete [] vertices;

Is it worth pointing out that this can be done with auto allocation?

Putting 'vertices' on stack is a no-brainer [in fact it's not obvious
why it's an array at all].  I might decline the other two, on a general
policy of keeping stack space tight.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web