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 1 of 2  [1] 2  Next page →

#13339 — How to free this memory?

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


        

[toc] | [next] | [standalone]

#13340

On 13.01.2012 18:05, Bint 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"

When you allocate with `new[]`, you should/must delete with `delete[]`.

But you should not do use raw arrays and raw new.

Use standard library containers such as `std::vector`.


<code>
#include <iostream>
#include <vector>

int main()
{
     using namespace std;

     struct TriVertex { double x, y, z; };
     typedef vector<TriVertex>       VertexVector;
     typedef vector<VertexVector>    VertexVectorVector;

     VertexVectorVector  vertices( 2 );
     vertices[0].resize( 100 );
     vertices[1].resize( 50 );
}
</code>


Cheers & hth.,

- Alf

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

#13346

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote in message 
news:jepq5f$bvj$1@dont-email.me...
> On 13.01.2012 18:05, Bint 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"
>
> When you allocate with `new[]`, you should/must delete with `delete[]`.
>
> But you should not do use raw arrays and raw new.
>
> Use standard library containers such as `std::vector`.
>
>
> <code>
> #include <iostream>
> #include <vector>
>
> int main()
> {
>     using namespace std;
>
>     struct TriVertex { double x, y, z; };
>     typedef vector<TriVertex>       VertexVector;
>     typedef vector<VertexVector>    VertexVectorVector;
>
>     VertexVectorVector  vertices( 2 );
>     vertices[0].resize( 100 );
>     vertices[1].resize( 50 );
> }
> </code>
>
>

Hi Alf
Thanks for the extra tips.
As an additional discussion point , how would you pass, for example, a 
pointer to a vertex as a function argument when using the vector method?
For example:
void example_function(trivertex* arg){};

example_function( vertices[0] ); /*No this won't convert to a pointer*/


I always feel I am entering dangerous territory when I start thinking about 
pointers to vector elements.
I am thinking of an iterator or something but I wonder if any iterator type 
will convert to a pointer, or perhaps using addressof operator &. How would 
you extract a pointer from the vector?









--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13351

On 13.01.2012 19:07, Paul <pchrist wrote:
>
> How would you extract a pointer from the vector?

You can just take the address of an element, like

   &v[0]

or

   &front()

for a non-empty vector v.

The vector buffer has been guaranteed contiguous since C++03.

With C++11 there is also a data() member function that has both const 
and non-const version, and that gives you &front() directly.


Cheers & hth.,

- Alf

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

#13358

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote in message 
news:jeptmu$2v8$1@dont-email.me...
> On 13.01.2012 19:07, Paul <pchrist wrote:
>>
>> How would you extract a pointer from the vector?
>
> You can just take the address of an element, like
>
>   &v[0]
>
> or
>
>   &front()
>
> for a non-empty vector v.
>
> The vector buffer has been guaranteed contiguous since C++03.
>
> With C++11 there is also a data() member function that has both const and 
> non-const version, and that gives you &front() directly.
>
>
> Cheers & hth.,
>
> - Alf

Also i reply to Kevins post... I see the vector <bool> inconsistency and try 
to avoid vector<bool>. But I still feel uncomfortable taking the address of 
a vector element. There seems to be some dark looming uncomfortable danger 
attached to this, I just can't put my finger on it.
I can see no harm on a single thread application however I wonder if there 
may be implications on MT apps. For example if one thread has a pointer and 
a different thread has modified the vector, in such a way that the pointer 
is invalidated. What I am getting at is, even with STL containers, 
programmers still need to tread carefully.

In some appications, or programs,  the STL container is the perfect 
solution. but I don't think this is always the case. I believe there is 
still a large userbase who require the raw memory managment features of C++.
STL allocators are a very usefull, not to mention productive, feature of C++ 
but they are an abstract feature. The basic laguage does not restrict its 
useage to this abstract feature and for this we should be thankfull. C++ is 
a powerfull programming language because it has so many different features, 
we can use C++ as a Java like language(high level), or as a C like 
language(low level) it has many different features and I think this is an 
important aspect of its success.

I think the STL part of the C++ language is just one aspect of its many uses 
and should not be emphasised to be any more important that the other 
aspects. It woud be great if in the future we had one common programming 
language , based on binary. But lets wait and see what happens with quantumn 
computers, maybe binary is a bit retarded and we need to start thiking in 
3's, who knows. Actually quantum is all about two's( the atom is either in 
the box or not in the box) so maybe our knowledge of binary and quantumn fit 
together well.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13368

On Jan 13, 8:35 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> "Alf P. Steinbach" <alf.p.steinbach+use...@gmail.com> wrote in messagenews:jeptmu$2v8$1@dont-email.me...
> > On 13.01.2012 19:07, Paul <pchrist wrote:


> >> How would you extract a pointer from the vector?
>
> > You can just take the address of an element, like
>
> >   &v[0]
>
> > or
>
> >   &front()
>
> > for a non-empty vector v.
>
> > The vector buffer has been guaranteed contiguous since C++03.
>
> > With C++11 there is also a data() member function that has both const and
> > non-const version, and that gives you &front() directly.
>
> Also i reply to Kevins post... I see the vector <bool> inconsistency and try
> to avoid vector<bool>. But I still feel uncomfortable taking the address of
> a vector element. There seems to be some dark looming uncomfortable danger
> attached to this, I just can't put my finger on it.

it really is safe!


> I can see no harm on a single thread application however I wonder if there
> may be implications on MT apps. For example if one thread has a pointer and
> a different thread has modified the vector, in such a way that the pointer
> is invalidated. What I am getting at is, even with STL containers,
> programmers still need to tread carefully.
>
> In some appications, or programs,  the STL container is the perfect
> solution. but I don't think this is always the case. I believe there is
> still a large userbase who require the raw memory managment features of C++.
> STL allocators are a very usefull, not to mention productive, feature of C++
> but they are an abstract feature.

whatever that means...

> The basic laguage does not restrict its
> useage to this abstract feature and for this we should be thankfull. C++ is
> a powerfull programming language because it has so many different features,
> we can use C++ as a Java like language(high level), or as a C like
> language(low level) it has many different features and I think this is an
> important aspect of its success.

C++ has exceptions. Therefore you should write exception safe code. It
is difficult to do this if you employ raw memory allocations.

> I think the STL part of the C++ language is just one aspect of its many uses
> and should not be emphasised to be any more important that the other
> aspects. It woud be great if in the future we had one common programming
> language , based on binary. But lets wait and see what happens with quantumn
> computers, maybe binary is a bit retarded and we need to start thiking in
> 3's, who knows.

I'mnot sure why quantum compyer necessarily inolves trinary.

> Actually quantum is all about two's( the atom is either in
> the box or not in the box)

not really! We only have a probability that the atom is in the box.

> so maybe our knowledge of binary and quantumn fit together well.

maybe not

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

#13413

On Jan 13, 12:35 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:

> Also i reply to Kevins post... I see the vector <bool> inconsistency and try
> to avoid vector<bool>. But I still feel uncomfortable taking the address of
> a vector element. There seems to be some dark looming uncomfortable danger
> attached to this, I just can't put my finger on it.
> I can see no harm on a single thread application however I wonder if there
> may be implications on MT apps. For example if one thread has a pointer and
> a different thread has modified the vector, in such a way that the pointer
> is invalidated. What I am getting at is, even with STL containers,
> programmers still need to tread carefully.

As always!

Assuming the default vector allocator is used, the ways I can think of
offhand that a pointer to an existing vector element may become
invalid are

a) the vector is resized to a smaller size, such that the pointer now
points past the new end of the vector
b) the vector is resized to a size larger than the original capacity,
necessitating a memory re-allocation
c) the vector is swapped with a temporary vector (the pointer now
points into the temporary) which is then immediately destroyed
d) the vector itself is destroyed (c is a special case of this)

These can, of course, happen even in a single-threaded application if
the programmer does not take care to avoid it.  And if you run
std::sort (etc.) on the vector, the object at the pointed-at location
may become different than you expect...

- Kevin B. McCarty

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

#13353

On Jan 13, 10:07 am, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> "Alf P. Steinbach" <alf.p.steinbach+use...@gmail.com> wrote in messagenews:jepq5f$bvj$1@dont-email.me...

> > int main()
> > {
> >     using namespace std;
>
> >     struct TriVertex { double x, y, z; };
> >     typedef vector<TriVertex>       VertexVector;
> >     typedef vector<VertexVector>    VertexVectorVector;
>
> >     VertexVectorVector  vertices( 2 );
> >     vertices[0].resize( 100 );
> >     vertices[1].resize( 50 );
> > }
> > </code>
>
> Hi Alf
> Thanks for the extra tips.
> As an additional discussion point , how would you pass, for example, a
> pointer to a vertex as a function argument when using the vector method?
> For example:
> void example_function(trivertex* arg){};
>
> example_function( vertices[0] ); /*No this won't convert to a pointer*/

If example_function needs a pointer, give it one.  Any of these will
work, with a few caveats below.

example_function( & vertices[0][0] );
example_function( & vertices[0].front() );
example_function(   vertices[0].data() ); // C++11 only

Caution: if vertices is empty, all of these give undefined behavior.
Else, if vertices[0] is empty, the first two of the above give
undefined behavior, and the third will probably give a pointer that
example_function will try to do something bad with, since it has no
'count' argument that could be specified as zero.  And, if the
trivertex class overloads unary operator& [but who does?] the first
two of the above may possibly cause trouble.  So be sure to check
those conditions first.

This is also assuming that example_function doesn't try to do anything
silly with the pointer it's given like realloc(), free(), etc.

(Note too that vector<bool> has a completely different implementation
from any other vector<T>, such that you cannot get a useful bool* from
it.)


> I always feel I am entering dangerous territory when I start thinking about
> pointers to vector elements.

Not much to worry about: if you have a vector<T> where T is neither
bool nor has its own unary operator&, a pointer to a single vector
element can easily be acquired with & vec[index], and a pointer to the
first element obtained as above is guaranteed to give you a bunch of
objects that are contiguous in memory, just as if they were allocated
with operator new[].  (But beware of polymorphic objects... don't put
those in vectors.)


> I am thinking of an iterator or something but I wonder if any iterator type
> will convert to a pointer, or perhaps using addressof operator &. How would
> you extract a pointer from the vector?

Generally vector<T>::iterator is a typedef for T* (except in the
special case vector<bool>), but this is not guaranteed (e.g. when
compilers have debugging turned on).

If you have only a vector<T>::iterator, AND you are sure it points to
a valid object (is not a one-past-the-end or singular iterator), AND
(yet again) T does not overload unary & and is not bool, you can get a
pointer from it via

    vector<T>::iterator it = ...;
    T * ptr = & * it;

- Kevin B. McCarty

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

#13369

On Jan 13, 6:48 pm, Kevin McCarty <kmcca...@gmail.com> wrote:

> Not much to worry about: if you have a vector<T> where T is neither
> bool nor has its own unary operator&, a pointer to a single vector
> element can easily be acquired with & vec[index], and a pointer to the
> first element obtained as above is guaranteed to give you a bunch of
> objects that are contiguous in memory, just as if they were allocated
> with operator new[].  (But beware of polymorphic objects... don't put
> those in vectors.)

oops! Why not? It seems an obvious thing to want to do! Or rather
pointers to POs. Is that ok?

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

#13414

On Jan 14, 2:19 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Jan 13, 6:48 pm, Kevin McCarty <kmcca...@gmail.com> wrote:
>
> > Not much to worry about: if you have a vector<T> where T is neither
> > bool nor has its own unary operator&, a pointer to a single vector
> > element can easily be acquired with & vec[index], and a pointer to the
> > first element obtained as above is guaranteed to give you a bunch of
> > objects that are contiguous in memory, just as if they were allocated
> > with operator new[].  (But beware of polymorphic objects... don't put
> > those in vectors.)
>
> oops! Why not? It seems an obvious thing to want to do! Or rather
> pointers to POs. Is that ok?

STL containers of pointers of polymorphic objects, absolutely, that is
fine.  (Containers of unique_ptrs or shared_ptrs, even better, if
you'd like the containers to have ownership of the objects.)  If, as
well as container ownership, you also want syntactic sugar to avoid
having to use [unary] * or -> operators, consider boost::ptr_array,
ptr_vector, etc.

Putting polymorphic objects themselves directly into a container (or
even a C-array or a block of new[]'ed up memory) is not a particularly
good idea.  A vector of base-class objects is unlikely to be very
useful, and even if instantiable (if the base class is not abstract),
is likely to encourage coding errors caused by slicing.

A vector of derived-class objects could perhaps be useful if you need
a bunch of copies of some objects known to have a specific fixed
derived type.  But code that creates a vector of derived objects can
lead to the following mistake:

vector<Derived> vder(2);
Base * b = & vder[0];  // ok, get a pointer to the Base
                       // portion of vder[0]
b->doSomething();      // ok
(++b)->doSomething();  // KABOOM

Either is allowed by the language (if the base class is not abstract),
and a very careful programmer could use such containers safely, but
why make life complicated.

- Kevin B. McCarty

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

#13350

On 13/01/2012 17:37, Alf P. Steinbach wrote:
> On 13.01.2012 18:05, Bint 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"
>
> When you allocate with `new[]`, you should/must delete with `delete[]`.
>
> But you should not do use raw arrays and raw new.
>
> Use standard library containers such as `std::vector`.
>
>
> <code>
> #include <iostream>
> #include <vector>
>
> int main()
> {
> using namespace std;
>
> struct TriVertex { double x, y, z; };
> typedef vector<TriVertex> VertexVector;
> typedef vector<VertexVector> VertexVectorVector;
>
> VertexVectorVector vertices( 2 );
> vertices[0].resize( 100 );
> vertices[1].resize( 50 );
> }
> </code>

I see Alf has quietly stopped putting 'using namespace std;' at 
namespace scope and is instead now doing it at function scope; that is 
progress even if still unnecessary/wrong (IMO).

/Leigh

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

#13341

"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;


HTH.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13343

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

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

#13345

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

Thanks
B

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

#13347

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

/Leigh

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

#13354

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

If your program is structured in such a way that it uses C++ EH to encompass 
RAII then by all means use only RAII safe objects. But the structure of a 
programs' error checking/ EH is flexible as is the C++ programming language. 
The language does not force a programmer to structure a program( regarding 
its error checking and exceptiopn handling) in any particular way, it 
provides a tool or a set of tools for which the programmer can create 
his/her own program structuure. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13355

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

/Leigh

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

#13356

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



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13357

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.

/Leigh

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

#13359

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

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?



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web