 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Niklas Norrthon
Guest
|
 Posted: Wed Oct 26, 2005 7:50 am Post subject: malloc family in C++ |
 |
|
In comp.lang.c in a discussion drifting off topic there I wrote:
| Quote: | No rule without exceptions...
Last week I used malloc in C++ for the first time in the 15 years I've
been playing with the language... I had a buffer which I needed to
shrink every once in a while, so I saved lots of CPU cycles switching
from new[] and delete[] to malloc, realloc and free.
|
Someone replied, suggesting using vector<>::resize(). But resize just
calls erase which causes destructors of contained objects to be called,
but it does not release any memory held by the vector. My contained
objects were unsigned chars, so destructors or not was not an issue.
Then the suggestion came to use the vector<>::swap() trick, to
return any memory not used. At this point the people over next
door had had enough (and who can blame them?).
So now I move over here...
My problem was:
A large array (a megabyte or two) of unsigned char gets populated by
a library function. Then the data in the array gets processed, and
after a chunk is used it is not needed anymore, so there is no need
to hold on to that memory any longer if the chunk not needed is at the
end of the array (which happens about 25% of the time).
My first attemt was to use a vector, and the swap trick to return
unused memory. There were two problems with this approach: While
swapping twice the memory is allocated, and the entire vector had
to be copied every time.
The solution was of course to switch to malloc and realloc instead.
Now it is functioning and fast. The calls to the C memory management
functions take place deep inside a class, so no other program logic
was affected at all. Only difference is a much smaller memory foot
print, and a faster program.
/Niklas Norrthon
|
|
| Back to top |
|
 |
Pete Becker
Guest
|
| Posted: Wed Oct 26, 2005 2:08 pm Post subject: Re: malloc family in C++ |
|
|
Niklas Norrthon wrote:
| Quote: |
The solution was of course to switch to malloc and realloc instead.
|
Of course it was. <g> Don't let language bigots dictate how you write
code. Sometimes C does things better than C++.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
|
|
| Back to top |
|
|
E. Mark Ping
Guest
|
| Posted: Wed Oct 26, 2005 6:15 pm Post subject: Re: malloc family in C++ |
|
|
In article <0p1x2867kn.fsf (AT) niklas (DOT) ua.dynas.se>,
Niklas Norrthon <do-not-use (AT) invalid (DOT) net> wrote:
| Quote: | The solution was of course to switch to malloc and realloc instead.
|
In our company we had a need for something similar, but wanted the
benefits of vector, so we wrote pod_vector<>, which uses
malloc/realloc, has a "shrink_to_fit" member function and doesn't call
constructors or destructors.
--
Mark Ping
[email]emarkp (AT) soda (DOT) CSUA.Berkeley.EDU[/email]
|
|
| Back to top |
|
|
Roland Pibinger
Guest
|
| Posted: Wed Oct 26, 2005 6:46 pm Post subject: Re: malloc family in C++ |
|
|
On Wed, 26 Oct 2005 18:15:04 +0000 (UTC),
[email]emarkp (AT) soda (DOT) csua.berkeley.edu[/email] (E. Mark Ping) wrote:
| Quote: | In our company we had a need for something similar, but wanted the
benefits of vector, so we wrote pod_vector<>, which uses
malloc/realloc, has a "shrink_to_fit" member function and doesn't call
constructors or destructors.
|
Unfortunately, not even Boost knows a portable way to determine if a
type is a POD or not:
http://www.boost.org/doc/html/boost_typetraits/reference.html#boost_typetraits.is_pod
Best wishes,
Roland Pibinger
|
|
| Back to top |
|
|
Howard Hinnant
Guest
|
| Posted: Thu Oct 27, 2005 1:34 pm Post subject: Re: malloc family in C++ |
|
|
In article <0p1x2867kn.fsf (AT) niklas (DOT) ua.dynas.se>,
Niklas Norrthon <do-not-use (AT) invalid (DOT) net> wrote:
| Quote: | The solution was of course to switch to malloc and realloc instead.
Now it is functioning and fast. The calls to the C memory management
functions take place deep inside a class, so no other program logic
was affected at all. Only difference is a much smaller memory foot
print, and a faster program.
|
I'm glad it worked for you.
Question: realloc doesn't really guarantee anything. It can silently
refuse to release the extra memory. It can also internally copy to a
smaller block, just like you had with vector. If you had a better
standard C tool that would either do it, or tell you it couldn't, would
you use it? I.e. would you want to know of an impending failure to
shrink the block in place, and therefore have the opportunity to do
something else?
I'm asking because I'm proposing such a tool. And your use case might
be good evidence to support such a tool. Here is the proposal:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1085.htm
This proposal adds a few more functions to the malloc/realloc family,
one of which is specifically charged with reducing (or expanding) the
size of a block *in-place* if it can:
int resize_alloc(void* ptr, size_t size_requested,
size_t* size_received);
-Howard
|
|
| Back to top |
|
|
E. Mark Ping
Guest
|
| Posted: Thu Oct 27, 2005 8:59 pm Post subject: Re: malloc family in C++ |
|
|
In article <435fce3f.3425150 (AT) news (DOT) utanet.at>,
Roland Pibinger <rpbg123 (AT) yahoo (DOT) com> wrote:
| Quote: | On Wed, 26 Oct 2005 18:15:04 +0000 (UTC),
[email]emarkp (AT) soda (DOT) csua.berkeley.edu[/email] (E. Mark Ping) wrote:
In our company we had a need for something similar, but wanted the
benefits of vector, so we wrote pod_vector<>, which uses
malloc/realloc, has a "shrink_to_fit" member function and doesn't call
constructors or destructors.
Unfortunately, not even Boost knows a portable way to determine if a
type is a POD or not
|
Our portable way is to have developers choose the container after
profiling, understanding that the objects held will be treated as POD.
That works pretty well.
--
Mark Ping
[email]emarkp (AT) soda (DOT) CSUA.Berkeley.EDU[/email]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
