Topic: autoptr ptr(new T[N])
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/10/14 Raw View
In article <7ttbll$95i$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
writes
>> Thus, as long as 'delete x' and 'delete[] x' would have the
>> same effect, we would only need one of them.
>
>This would work if *EVERY* allocation had the extra
>4-byte pointer, even simple allocations such as
> char *x = new char;
>On our 4-byte alignment system, this 1-byte allocation
>actually consumes 12 bytes of RAM (4 for the allocation size,
>4 for the number of objects, 1 for the actual data, and 3
>for byte alignment). Currently this takes 8 bytes, which is
>bad enough. I think that many C++ programmers would object.
I do not understand where allocation size comes into this. That
information is an OS level detail, nothing to do with the compiler. If
I wrote my own allocator I would not need to track the amount of storage
because the compiler could work it out from sizeof(type) if it needed it
because my custom allocator was doing its own 'heap' management.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg) (postmaster@nospam.gov)
Date: 1999/10/14 Raw View
In article <7tpehi$k6g$1@nnrp1.deja.com>, rado42 <rado42@my-deja.com> wrote:
> >
> > Don't stray outside this. Specifically:
> >
> > T* p = new T;
> > delete [] p;
> >
> > and
> >
> > T* p = new T [n];
> > delete p;
> >
>
> The nesessity of delete[] has always been bothering me.
> I understand the need for it, but I think that at the cost
> of little overhead (probably 4 bytes) it could be arranged
> so that the compiler would ALWAYS write the size of the
> allocated array (even if single object is allocated).
Yes, that's correct. And you can do this anyway.
Foo* foo = new Foo [1];
// always use delete []
delete [] foo;
But this adds the overhead to every allocation. For some allocations, this
can be a factor of 4 or more in allocation size! (imagine allocating
millions of char objects separately)
> Moreover, most allocators keep such information in order
> to work,
most != all
> so in could be sone that there isn't any overhead at all.
You're proposing adding the overhead again - I call that twice the overhead.
char* c = new char;
would use ::operator new, which may add its own overhead, and would add
more overhead that you propose.
> Thus, as long as 'delete x' and 'delete[] x' would have the
> same effect, we would only need one of them.
No, but you are suggesting that we merge them together.
> Take this as a proposal for language change
Pretty weak proposal.
> It will not ruin any existing code,
Wrong.
struct X {
void* operator new ( std::size_t );
void operator delete ( void* );
};
fixed_pool<sizeof (X)> pool;
void* X::operator new ( std::size_t s ) {
assert( s == sizeof (X) );
return pool.alloc();
}
void X::operator delete ( void* p ) {
pool.free( p );
}
I could come up with more, but I think this is sufficient.
> but will prevent problems like
> stated in this thread (including autoptr).
C++ isn't about distributed fat. What you propose is just that -
distribute fat of array allocations to all allocations to reduce the
vocabulary of freestore operations.
If you want a single allocation concept in vocabulary, you are more than
free to make this so. Don't create C-style arrays with a new expression
and you never have to worry about operator delete []. Use std::vector if
you want an array of objects. Many people follow this in general.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: rado42 <rado42@my-deja.com>
Date: 1999/10/10 Raw View
>
> Don't stray outside this. Specifically:
>
> T* p = new T;
> delete [] p;
>
> and
>
> T* p = new T [n];
> delete p;
>
The nesessity of delete[] has always been bothering me.
I understand the need for it, but I think that at the cost
of little overhead (probably 4 bytes) it could be arranged
so that the compiler would ALWAYS write the size of the
allocated array (even if single object is allocated).
Moreover, most allocators keep such information in order
to work, so in could be sone that there isn't any overhead at all.
Thus, as long as 'delete x' and 'delete[] x' would have the
same effect, we would only need one of them.
Take this as a proposal for language change. It will not
ruin any existing code, but will prevent problems like
stated in this thread (including autoptr).
--
rado
http://members.tripod.com/~radosoft
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/10/10 Raw View
rado42 wrote:
> The nesessity of delete[] has always been bothering me.
So don't use old-style arrays. Use vector.
Old-style arrays have always bothered me.
> I understand the need for it, but I think that at the cost
> of little overhead (probably 4 bytes)
That's _not_ a little overhead. That's a big overhead for
small objects.
> it could be arranged
> so that the compiler would ALWAYS write the size of the
> allocated array (even if single object is allocated).
> Moreover, most allocators
most != all
> keep such information in order
> to work, so in could be sone that there isn't any overhead at all.
No
> Thus, as long as 'delete x' and 'delete[] x' would have the
> same effect, we would only need one of them.
It's an immense overhead for new int. And it's useless, as
you don't use scalars and arrays the same way.
--
Valentin Bonnard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/10/10 Raw View
In article <7tpehi$k6g$1@nnrp1.deja.com>, rado42 <rado42@my-deja.com>
writes
>>
>> Don't stray outside this. Specifically:
>>
>> T* p = new T;
>> delete [] p;
>>
>> and
>>
>> T* p = new T [n];
>> delete p;
>>
>
>The nesessity of delete[] has always been bothering me.
>I understand the need for it, but I think that at the cost
>of little overhead (probably 4 bytes) it could be arranged
>so that the compiler would ALWAYS write the size of the
>allocated array (even if single object is allocated).
>Moreover, most allocators keep such information in order
>to work, so in could be sone that there isn't any overhead at all.
>
>Thus, as long as 'delete x' and 'delete[] x' would have the
>same effect, we would only need one of them.
>
>Take this as a proposal for language change. It will not
>ruin any existing code, but will prevent problems like
>stated in this thread (including autoptr).
>
Over the years C++ has struggled with various ways to handle this
problem. The final outcome has been a compromise between the needs of
different groups. Remember that all the variations of new and delete
can be over-ridden as well as overloaded the overhead of even four bytes
would be unacceptable for a class based allocator for a small type using
a reserved block of storage.
If you are willing to force compatibility just declare all your dynamic
objects as arrays (of one if necessary). This follows the C++ principle
of not paying for what you do not use.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@anti-spam_metrowerks.com (Howard Hinnant)
Date: 1999/10/10 Raw View
In article <7tpehi$k6g$1@nnrp1.deja.com>, rado42 <rado42@my-deja.com> wrote:
> The nesessity of delete[] has always been bothering me.
> I understand the need for it, but I think that at the cost
> of little overhead (probably 4 bytes) it could be arranged
> so that the compiler would ALWAYS write the size of the
> allocated array (even if single object is allocated).
> Moreover, most allocators keep such information in order
> to work, so in could be sone that there isn't any overhead at all.
>
> Thus, as long as 'delete x' and 'delete[] x' would have the
> same effect, we would only need one of them.
Think of a block of memory returned by new[] as a vector. It typically
has associated with it both a capacity and a size. The memory allocator
will return a block of memory greater than or equal to the amount
requested. That amount is what I would refer to as the capacity.
Additionally, one must record the number of objects in the array so that
the right number of constructions/destructions are done (the size).
The non-array version is specialized such that size == 1 (and so size does
not need to be stored). But capacity is not necessarily == 1.
Note that what I describe here is but one possible implementation. But it
is an allowed implementation.
-Howard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW <allan_w@my-deja.com>
Date: 1999/10/11 Raw View
First, "St phane Bailliez" <bailliez@cybercable.fr> wrote:
> If you do this
> MyObject *pArray = new MyObject[56];
> delete pArray;
> It will call only the destructor of the first object.
> That's why you need to use the array form of delete.
Later, ichehab wrote:
> If the use of delete[] only differ from delete by
> ensuring that all destructors get called rather than
> just the first in the array, is it perfectly safe and
> valid to do:
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
> // using vector is too much effort
> // valarray look more like the way to go.
> }
This provoked blargg to reply:
> If your indended behavior is undefined.
I can't be sure, but it seems to me that ichehab was making
that exact point, by arguing with St phane Bailliez's logic.
I agree with ichehab. *IF* the only reason that new[]/delete
was illegal was stated to be the number of destructor calls
made, *THEN* the code that ichehab posted would have been
legal because we could be 100% certain that the "char"
datatype has no destructor.
However, since no such reason was stated explicitly, we cannot
make this assumption. The only thing we really can say about
new[]/delete in a standards group is that it is undefined.
--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW <allan_w@my-deja.com>
Date: 1999/10/11 Raw View
rado42 <rado42@my-deja.com> wrote:
[Replying to comments that new/delete[] and new[]/delete
are undefined]
> The nesessity of delete[] has always been bothering me.
> I understand the need for it, but I think that at the cost
> of little overhead (probably 4 bytes) it could be arranged
> so that the compiler would ALWAYS write the size of the
> allocated array (even if single object is allocated).
Many C++ rules are designed so that it is possible for C++
compilers to optimize to a large degree. The idea of 4 extra
bytes per non-array object on the free store is abhorrent,
and the time consumed writing and maintaining it is also
objectionable.
Besides, realistically, even if we had this rule, C++
programs would still have to somehow know the difference
between a pointer to an object and a pointer to an array.
For instance, pointer arithmetic on pointer-to-object isn't
reliable because the pointer might actually point to a
derived type. If the program already has this information,
there's little sense in forcing the run-time system to
figure it out again.
> Moreover, most allocators keep such information in order
> to work, so in could be sone that there isn't any overhead at all.
An easy mistake to make; it took me months to convince myself
that this isn't true.
You're trying to use one number to
(a) Determine the number of MyClass objects in the block,
so that delete[] can call all of the destructors, and
(b) Determine the size of the allocated block, so that
delete[] can return it to the free store properly.
But this won't work. Part (a) is always controlled by the
compiler, but part (b) must work with user-defined
::operator new[] and ::operator delete[]. Furthermore, you
might not even know at compile-time that these functions
are being replaced, but only at link time. If the user
does override ::operator new[] and ::operator delete[],
then the delete[] code can't possibly know the size of the
block unless the size is stored somewhere in the block.
Let's assume we're allocating an array of 10 MyClass objects.
Each object is 19 bytes long, int's are 4 bytes long, and our
machine requires 4-byte alignment. So this:
MyClass *x = new MyClass[10];
becomes this:
char *__x = ::operator new[](204);
((int*)__x) = 10;
__x += 4;
for (x=(MyClass*)__x; x<20+(MyClass*)__x; ++x)
// Call allocator for *x
x = (MyClass*)__x;
But note that ::operator new[] must also save the block size
(204) somewhere, so that ::operator delete[] has access to this
information.
> Thus, as long as 'delete x' and 'delete[] x' would have the
> same effect, we would only need one of them.
This would work if *EVERY* allocation had the extra
4-byte pointer, even simple allocations such as
char *x = new char;
On our 4-byte alignment system, this 1-byte allocation
actually consumes 12 bytes of RAM (4 for the allocation size,
4 for the number of objects, 1 for the actual data, and 3
for byte alignment). Currently this takes 8 bytes, which is
bad enough. I think that many C++ programmers would object.
--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg) (postmaster@nospam.gov)
Date: 1999/10/11 Raw View
In article <7tt9gd$7kc$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com> wrote:
> First, "St phane Bailliez" <bailliez@cybercable.fr> wrote:
> > If you do this
> > MyObject *pArray = new MyObject[56];
> > delete pArray;
> > It will call only the destructor of the first object.
> > That's why you need to use the array form of delete.
>
> Later, ichehab wrote:
> > If the use of delete[] only differ from delete by
> > ensuring that all destructors get called rather than
> > just the first in the array, is it perfectly safe and
> > valid to do:
> > {
> > auto_ptr ar(new char[strlen(src)]);
> > ....
> > // No char destructor, so I therfore
> > // don't really care about delete[].
> > // using vector is too much effort
> > // valarray look more like the way to go.
> > }
>
> This provoked blargg to reply:
> > If your indended behavior is undefined.
>
> I can't be sure, but it seems to me that ichehab was making
> that exact point, by arguing with St phane Bailliez's logic.
I read the above from ichehab as suggesting that delete new T [n], where T
has no destructor, is OK if delete [] just adds the behavior of calling
destructors. That is not correct. It also assumes the new expression
doesn't add any extra information at the beginning of the allocation.
> I agree with ichehab. *IF* the only reason that new[]/delete
> was illegal was stated to be the number of destructor calls
> made,
*and* the standard required compilers to optimize new for cases where the
type has no destructor,
> *THEN* the code that ichehab posted would have been
> legal because we could be 100% certain that the "char"
> datatype has no destructor.
Not legal, but would have had more of a reason to work.
> However, since no such reason was stated explicitly, we cannot
> make this assumption. The only thing we really can say about
> new[]/delete in a standards group is that it is undefined.
And in practice. A compiler that always stored the number of objects for a
new expression would be useful for debugger support (so the debugger could
display the array properly).
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ichehab@my-deja.com
Date: 1999/10/05 Raw View
Can an autoptr be used to manage `auto delete' an array?
The destructor uses delete, where as the book say for new[] you must
use delete [].
Or is it matter of writting a different wrapper for arrays?
Cheers,
- I.
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Marco Dalla Gasperina" <marcodg@pacifier.com>
Date: 1999/10/05 Raw View
<ichehab@my-deja.com> wrote in message news:7tb303$jgd$1@nnrp1.deja.com...
> Can an autoptr be used to manage `auto delete' an array?
No.
> The destructor uses delete, where as the book say for new[]
> you must use delete [].
Correct.
> Or is it matter of writting a different wrapper for arrays?
> Cheers,
There already is one. std::vector is handy for this very
purpose.
marco
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/10/05 Raw View
ichehab@my-deja.com wrote:
>
> Can an autoptr be used to manage `auto delete' an array?
> The destructor uses delete, where as the book say for new[] you must
> use delete [].
> Or is it matter of writting a different wrapper for arrays?
> Cheers,
>
> - I.
autoptr won't correctly handle arrays. However, you can use vallarray<>
as a substitute; it's guaranteed to have consecutive storage, so the
address of the first element is also the address of the entire array.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Colin Rafferty <craffert@ms.com>
Date: 1999/10/05 Raw View
ichehab@my-deja.com writes:
> Can an autoptr be used to manage `auto delete' an array?
No.
> The destructor uses delete, where as the book say for new[] you must
> use delete [].
Which is why it won't work.
> Or is it matter of writting a different wrapper for arrays?
Yes. Although, you will probably be happy with vector<T>.
--
Colin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "St phane Bailliez" <bailliez@cybercable.fr>
Date: 1999/10/05 Raw View
Write an auto_ptr_array wrapper.
If you do this
MyObject *pArray = new MyObject[56];
delete pArray;
It will call only the destructor of the first object. That's why you need to
use the array form of delete.
--
St phane Bailliez, Paris - France
mailto:bailliez@cybercable.fr
<ichehab@my-deja.com> wrote in message news:7tb303$jgd$1@nnrp1.deja.com...
> Can an autoptr be used to manage `auto delete' an array?
> The destructor uses delete, where as the book say for new[] you must
> use delete [].
> Or is it matter of writting a different wrapper for arrays?
> Cheers,
>
> - I.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/10/07 Raw View
ichehab@my-deja.com wrote:
>
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
> // using vector is too much effort
> // valarray look more like the way to go.
> }
No. delete foo; calls operator delete(void*) to deallocate,
while delete[] foo; calls operator delete[](void*).
Both are different functions, which may be implemented
differently (and can be overridden independantly).
For example, new/delete might use a strategy opimized for
small to medium sized allocations, while new[]/delete[]
are optimized for large memory blocks. Then operator delete()
will not understand the allocation data of operator new[]
and vice versa.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: smeyers@aristeia.com (Scott Meyers)
Date: 1999/10/07 Raw View
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
> // using vector is too much effort
> // valarray look more like the way to go.
> }
No. Results are undefined, and this will do unpleasant things at runtime
on some real systems.
Why would vector be too much effort?
Scott
--
Scott Meyers, Ph.D. smeyers@aristeia.com
Software Development Consultant http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 1999/10/07 Raw View
ichehab@my-deja.com wrote:
>
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
This is not the case, you must call delete[] if you new[] regardless
of the data type or absence of destructors.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel M. Pfeffer" <pfefferd@nospam.internet-zahav.net>
Date: 1999/10/07 Raw View
The implementation of operator new[] may reserve room for extra data
relating to the memory allocated. For example, it might allocate extra
memory to store the size of each object in the array, so it can calculate
the number of objects.
'operator new' may reserve 4 extra bytes, and store sizeof(object) in them.
'operator new[]' may reserve 8 extra bytes, storing sizeof(object) in the
first 4 bytes and the number of class instances in the second 4 bytes.
Calling 'operator delete' might not work even for a 'char' array in this
implementation.
--
Daniel Pfeffer
--------------
Remove 'nospam' from my address in order to contact me directly
<ichehab@my-deja.com> wrote in message news:7teuur$bei$1@nnrp1.deja.com...
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
> // using vector is too much effort
> // valarray look more like the way to go.
> }
>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/10/08 Raw View
In article <37FB7CF7.F1C3BBE2@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>For example, new/delete might use a strategy opimized for
>small to medium sized allocations, while new[]/delete[]
>are optimized for large memory blocks. Then operator delete()
>will not understand the allocation data of operator new[]
>and vice versa.
and delete[] has to have some mechanism for determining the number of
elements in the array, so it may need to modify the address passed
before 'freeing' it. If such a modification was applied to an address
that had not been generated by a use of new[] you would end up trying to
release a block of memory from an invalid address.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/10/06 Raw View
In article <7tb303$jgd$1@nnrp1.deja.com>, ichehab@my-deja.com writes
>Can an autoptr be used to manage `auto delete' an array?
No
>The destructor uses delete, where as the book say for new[] you must
>use delete [].
Exactly.
>Or is it matter of writting a different wrapper for arrays?
Well why not use a vector?
>Cheers,
>
>- I.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ichehab@my-deja.com
Date: 1999/10/06 Raw View
If the use of delete[] only differ from delete by ensuring that all
destructors get called rather than just the first in the array, is it
perfectly safe and valid to do:
{
auto_ptr ar(new char[strlen(src)]);
....
// No char destructor, so I therfore
// don't really care about delete[].
// using vector is too much effort
// valarray look more like the way to go.
}
Thanks,
- I.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg) (postmaster@nospam.gov)
Date: 1999/10/06 Raw View
In article <7teuur$bei$1@nnrp1.deja.com>, ichehab@my-deja.com wrote:
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
If your indended behavior is undefined.
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
Or about the freestore system getting the correct pointer to delete,
causing all sorts of problems (one possible outcome).
> // using vector is too much effort
Sounds like writing correct code is just too much effort, then.
> // valarray look more like the way to go.
> }
People always trip up on this. They like to poke around in abstractions'
internals. I can only assume they do the same kind of thing with other
abstractions too. This is not good software engineering.
Single object on freestore:
T* p = new T;
// use p
delete p;
// cannot use p
Multiple objects on freestore:
T* p = new T [n];
// use p
delete [] p;
// cannot use p
Don't stray outside this. Specifically:
T* p = new T;
delete [] p;
and
T* p = new T [n];
delete p;
invoke undefined behavior. Absolutely anything can (and does) happen. If
you're lucky, it will crash immediately. If you're unlucky (which may be
often), it will appear to do what you want.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Colin Rafferty <craffert@ms.com>
Date: 1999/10/06 Raw View
ichehab@my-deja.com writes:
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
Unfortunately for you, this is not the case.
Calling delete on a pointer that was allocated with new[] is undefined
behavior, and anything can happen.
This means that your favorite compiler may do what you like, but the
next one you use will generate the HCF instruction (Halt and Catch Fire).
--
Colin
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "John Hickin" <hickin@nortelnetworks.com>
Date: 1999/10/07 Raw View
ichehab@my-deja.com wrote:
>
> If the use of delete[] only differ from delete by ensuring that all
> destructors get called rather than just the first in the array, is it
> perfectly safe and valid to do:
> {
> auto_ptr ar(new char[strlen(src)]);
> ....
> // No char destructor, so I therfore
> // don't really care about delete[].
> // using vector is too much effort
> // valarray look more like the way to go.
> }
>
This isn't true.
The standard gives me sufficient freedom to implement the global
operators new, new[], delete, and delete[] in such a way that the code
you have above breaks.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]