What is the best alternative for realloc in C++

[Claudio Puviani]

Re: What is the best alternative for realloc in C++

"Evan Carew" <tempcarew@pobo x.com> wrote[color=blue]
> I'm sure Kevin means well, but I think you would do
> well to put his posts in your filter list.[/color]

That's harsh coming from someone who's posting incorrect advice. 'malloc'
and 'new' are not interchangeable . Period.
[color=blue]
> The problem with his post is that most compiler vendors
> do indeed use malloc under the hood as the default new
> operator's machenery.[/color]

Which is irrelevant to the fact that the two should NEVER be intermixed.
[color=blue]
> 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.[/color]

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.
[color=blue]
> In the UNIX world, this happens to be malloc[/color]

Wrong again. You're really racking up the misses. In UNIX, the fundamental
memory management system call is 'sbrk'. UNIX knows nothing about 'malloc'.
[color=blue]
> (I can't imagine it would be any different with MS products).[/color]

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]

Re: What is the best alternative for realloc in C++

"Evan Carew" <tempcarew@pobo x.com> wrote[color=blue]
> I'm sure Kevin means well, but I think you would do
> well to put his posts in your filter list.[/color]

That's harsh coming from someone who's posting incorrect advice. 'malloc'
and 'new' are not interchangeable . Period.
[color=blue]
> The problem with his post is that most compiler vendors
> do indeed use malloc under the hood as the default new
> operator's machenery.[/color]

Which is irrelevant to the fact that the two should NEVER be intermixed.
[color=blue]
> 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.[/color]

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.
[color=blue]
> In the UNIX world, this happens to be malloc[/color]

Wrong again. You're really racking up the misses. In UNIX, the fundamental
memory management system call is 'sbrk'. UNIX knows nothing about 'malloc'.
[color=blue]
> (I can't imagine it would be any different with MS products).[/color]

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]

Re: What is the best alternative for realloc in C++

Evan Carew wrote:
[color=blue]
> -----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).
>[/color]

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-lite/freestore-mgmt.html#faq-16.2

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.3

http://www.parashift.com/c++-faq-lite/freestore-mgmt.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]

Re: What is the best alternative for realloc in C++

Evan Carew wrote:
[color=blue]
> -----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).
>[/color]

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-lite/freestore-mgmt.html#faq-16.2

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.3

http://www.parashift.com/c++-faq-lite/freestore-mgmt.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.