What is the best alternative for realloc in C++

[Kumar]

Hi,
Can somebody advise me on what is the best alternative for realloc in C++?
Is it safe to "realloc"ate memory allocated using new operator ?

[Rolf Magnus]

Kumar wrote:

Hi,
Can somebody advise me on what is the best alternative for realloc in
C++?
What would you need it for?
Is it safe to "realloc"ate memory allocated using new operator ?

No. You can only use realloc on memory that you got from malloc or
realloc. Also, realloc won't work properly with non-pod objects, since
it doesn't care about constructors and destructors.

[Rolf Magnus]

Kumar wrote:

Hi,
Can somebody advise me on what is the best alternative for realloc in
C++?
What would you need it for?
Is it safe to "realloc"ate memory allocated using new operator ?

No. You can only use realloc on memory that you got from malloc or
realloc. Also, realloc won't work properly with non-pod objects, since
it doesn't care about constructors and destructors.

[David Harmon]

On 6 Apr 2004 02:12:33 -0700 in comp.lang.c++, rs******@acmet.com
(Kumar) wrote,

Hi,
Can somebody advise me on what is the best alternative for realloc in C++?
std::vector<>::resize()
Is it safe to "realloc"ate memory allocated using new operator ?

Don't use 'new'.

[David Harmon]

On 6 Apr 2004 02:12:33 -0700 in comp.lang.c++, rs******@acmet.com
(Kumar) wrote,

Hi,
Can somebody advise me on what is the best alternative for realloc in C++?
std::vector<>::resize()
Is it safe to "realloc"ate memory allocated using new operator ?

Don't use 'new'.

[Kevin Goodsell]

Rolf Magnus wrote:

Kumar wrote:

Is it safe to "realloc"ate memory allocated using new operator ?

No. You can only use realloc on memory that you got from malloc or
realloc.

....or calloc().
Also, realloc won't work properly with non-pod objects, since
it doesn't care about constructors and destructors.

Likewise with malloc(), calloc(), and free(), which is why these should
only be used when absolutely necessary, and only by people who really
know what they are doing.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Rolf Magnus wrote:

Kumar wrote:

Is it safe to "realloc"ate memory allocated using new operator ?

No. You can only use realloc on memory that you got from malloc or
realloc.

....or calloc().
Also, realloc won't work properly with non-pod objects, since
it doesn't care about constructors and destructors.

Likewise with malloc(), calloc(), and free(), which is why these should
only be used when absolutely necessary, and only by people who really
know what they are doing.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

David Harmon wrote:

Don't use 'new'.

Reasonable advice, but just to be perfectly clear:

1) Don't use malloc() (and friends) when 'new' can do the job.

2) Don't use malloc() or 'new' when containers or automatic variables
can do the job.

3) When explicit memory management is necessary, try to use smart
pointers to make it easier and safer.

4) If you do have to use any form of explicit memory management, use
caution.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

David Harmon wrote:

Don't use 'new'.

Reasonable advice, but just to be perfectly clear:

1) Don't use malloc() (and friends) when 'new' can do the job.

2) Don't use malloc() or 'new' when containers or automatic variables
can do the job.

3) When explicit memory management is necessary, try to use smart
pointers to make it easier and safer.

4) If you do have to use any form of explicit memory management, use
caution.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Evan Carew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar wrote:

Hi,
Can somebody advise me on what is the best alternative for realloc in C++?
Is it safe to "realloc"ate memory allocated using new operator ?

Kumar,

The simple answer is that realloc is nothing more than a fancy version
of malloc, ie new. So if you are working with STL compliant objects &
containers, then simply setting one equal to another will suffice, then
either let the old object go out of scope (if automatic), or delete it.

Evan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAc0OVoo/Prlj9GScRApXyAJ0UKj7WWWX5v98AdCdCyrm1fwO4PQCdFJ61
M1vu6exq008FY2XrmEXkrkk=
=4O+j
-----END PGP SIGNATURE-----

[Evan Carew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar wrote:

Hi,
Can somebody advise me on what is the best alternative for realloc in C++?
Is it safe to "realloc"ate memory allocated using new operator ?

Kumar,

The simple answer is that realloc is nothing more than a fancy version
of malloc, ie new. So if you are working with STL compliant objects &
containers, then simply setting one equal to another will suffice, then
either let the old object go out of scope (if automatic), or delete it.

Evan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAc0OVoo/Prlj9GScRApXyAJ0UKj7WWWX5v98AdCdCyrm1fwO4PQCdFJ61
M1vu6exq008FY2XrmEXkrkk=
=4O+j
-----END PGP SIGNATURE-----

[Kevin Goodsell]

Evan Carew wrote:

malloc, ie new.

The implication that malloc() and 'new' are equivalent is very wrong.
There are significant differences, for example: malloc() returns NULL on
failure while 'new' throws an exception, malloc() allocates raw memory
while 'new' constructs objects in the allocated space, malloc() is a
single function while 'new' comes in several variants and can be
overloaded or overridden by the programmer.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Evan Carew wrote:

malloc, ie new.

The implication that malloc() and 'new' are equivalent is very wrong.
There are significant differences, for example: malloc() returns NULL on
failure while 'new' throws an exception, malloc() allocates raw memory
while 'new' constructs objects in the allocated space, malloc() is a
single function while 'new' comes in several variants and can be
overloaded or overridden by the programmer.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Evan Carew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar,

I'm sure Kevin means well, but I think you would do well to put his
posts in your filter list. The problem with his post is that most
compiler vendors do indeed use malloc under the hood as the default new
operator's machenery. While many vendors do add additional functionality
to new beside what malloc provides, ultimately, you are interfacing with
the OS's memory machenery, and thus must use its entry points. In the
UNIX world, this happens to be malloc (I can't imagine it would be any
different with MS products).

Evan Carew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAdCPmoo/Prlj9GScRAnl5AJ49sHLYuak9OAOLvXGdExJKqn2PrACffZQ2
Pv1ZYvqReZFHmBY1cbdHnQo=
=bC5J
-----END PGP SIGNATURE-----

[Evan Carew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar,

I'm sure Kevin means well, but I think you would do well to put his
posts in your filter list. The problem with his post is that most
compiler vendors do indeed use malloc under the hood as the default new
operator's machenery. While many vendors do add additional functionality
to new beside what malloc provides, ultimately, you are interfacing with
the OS's memory machenery, and thus must use its entry points. In the
UNIX world, this happens to be malloc (I can't imagine it would be any
different with MS products).

Evan Carew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAdCPmoo/Prlj9GScRAnl5AJ49sHLYuak9OAOLvXGdExJKqn2PrACffZQ2
Pv1ZYvqReZFHmBY1cbdHnQo=
=bC5J
-----END PGP SIGNATURE-----

[Claudio Puviani]

"Evan Carew" <te*******@pobox.com> wrote

I'm sure Kevin means well, but I think you would do
well to put his posts in your filter list.
That's harsh coming from someone who's posting incorrect advice. 'malloc'
and 'new' are not interchangeable. Period.
The problem with his post is that most compiler vendors
do indeed use malloc under the hood as the default new
operator's machenery.
Which is irrelevant to the fact that the two should NEVER be intermixed.
While many vendors do add additional functionality to
new beside what malloc provides, ultimately, you are
interfacing with the OS's memory machenery, and thus
must use its entry points.
That's incorrect. Memory management is shared by the C++ library (for
fine-grained allocations) and the operating system (for the library's
internal use only). A call to 'new' or 'malloc' very rarely results in a
call to an OS system function, and when it does, it's an indirect
consequence.
In the UNIX world, this happens to be malloc
Wrong again. You're really racking up the misses. In UNIX, the fundamental
memory management system call is 'sbrk'. UNIX knows nothing about 'malloc'.
(I can't imagine it would be any different with MS products).

You need more imagination, then. Windows system calls for memory management
are even more convoluted and offer an entire suite of operations on
system-managed heaps, only a small subset of which is used as the
underpinnings of 'malloc' and 'new'.

Next time you arrogantly attack someone like Kevin for posting correct
information, you might want to look things up to avoid making a complete
fool of yourself.

Claudio Puviani

[Claudio Puviani]

"Evan Carew" <te*******@pobox.com> wrote

I'm sure Kevin means well, but I think you would do
well to put his posts in your filter list.
That's harsh coming from someone who's posting incorrect advice. 'malloc'
and 'new' are not interchangeable. Period.
The problem with his post is that most compiler vendors
do indeed use malloc under the hood as the default new
operator's machenery.
Which is irrelevant to the fact that the two should NEVER be intermixed.
While many vendors do add additional functionality to
new beside what malloc provides, ultimately, you are
interfacing with the OS's memory machenery, and thus
must use its entry points.
That's incorrect. Memory management is shared by the C++ library (for
fine-grained allocations) and the operating system (for the library's
internal use only). A call to 'new' or 'malloc' very rarely results in a
call to an OS system function, and when it does, it's an indirect
consequence.
In the UNIX world, this happens to be malloc
Wrong again. You're really racking up the misses. In UNIX, the fundamental
memory management system call is 'sbrk'. UNIX knows nothing about 'malloc'.
(I can't imagine it would be any different with MS products).

You need more imagination, then. Windows system calls for memory management
are even more convoluted and offer an entire suite of operations on
system-managed heaps, only a small subset of which is used as the
underpinnings of 'malloc' and 'new'.

Next time you arrogantly attack someone like Kevin for posting correct
information, you might want to look things up to avoid making a complete
fool of yourself.

Claudio Puviani

[Kevin Goodsell]

Evan Carew wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar,

I'm sure Kevin means well, but I think you would do well to put his
posts in your filter list. The problem with his post is that most
compiler vendors do indeed use malloc under the hood as the default new
operator's machenery. While many vendors do add additional functionality
to new beside what malloc provides, ultimately, you are interfacing with
the OS's memory machenery, and thus must use its entry points. In the
UNIX world, this happens to be malloc (I can't imagine it would be any
different with MS products).

Kumar,

I'm sure Evan means well, but I think you would do well to put his posts
in your filter list. The problem is that he can't grasp simple concepts
like how to post properly (i.e., not top-posting), or the (very
important) differences between malloc() and 'new'. This suggests that
any advice he gives may be dubious at best, and downright dangerous at
worst. I would suggest deferring to the more knowledgeable members of
the group (I'm not including myself in that set). It's not to hard to
figure out who they are -- they are the ones who correct people's
errors, including each others, and don't make ridiculous claims without
backing them up.

Incidentally, the following FAQ entries are relevant to the question at
hand:

http://www.parashift.com/c++-faq-lit....html#faq-16.2
http://www.parashift.com/c++-faq-lit....html#faq-16.3
http://www.parashift.com/c++-faq-lit....html#faq-16.5

Any good C++ book or reference can verify everything I said in my
previous post, or I can expand on any or all of them that need
clarification.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Evan Carew wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kumar,

I'm sure Kevin means well, but I think you would do well to put his
posts in your filter list. The problem with his post is that most
compiler vendors do indeed use malloc under the hood as the default new
operator's machenery. While many vendors do add additional functionality
to new beside what malloc provides, ultimately, you are interfacing with
the OS's memory machenery, and thus must use its entry points. In the
UNIX world, this happens to be malloc (I can't imagine it would be any
different with MS products).

Kumar,

I'm sure Evan means well, but I think you would do well to put his posts
in your filter list. The problem is that he can't grasp simple concepts
like how to post properly (i.e., not top-posting), or the (very
important) differences between malloc() and 'new'. This suggests that
any advice he gives may be dubious at best, and downright dangerous at
worst. I would suggest deferring to the more knowledgeable members of
the group (I'm not including myself in that set). It's not to hard to
figure out who they are -- they are the ones who correct people's
errors, including each others, and don't make ridiculous claims without
backing them up.

Incidentally, the following FAQ entries are relevant to the question at
hand:

http://www.parashift.com/c++-faq-lit....html#faq-16.2
http://www.parashift.com/c++-faq-lit....html#faq-16.3
http://www.parashift.com/c++-faq-lit....html#faq-16.5

Any good C++ book or reference can verify everything I said in my
previous post, or I can expand on any or all of them that need
clarification.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.