C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

realloc in c++
Goto page 1, 2, 3 ... 21, 22, 23  Next
 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
quikquic@yahoo.com
Guest





PostPosted: Thu Oct 02, 2003 10:07 am    Post subject: realloc in c++ Reply with quote



For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have in C++?

Thank,

qk

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Francis Glassborow
Guest





PostPosted: Thu Oct 02, 2003 8:14 pm    Post subject: Re: realloc in c++ Reply with quote



In article <ead1f717.0310011615.61419b5f (AT) posting (DOT) google.com>,
"quikquic (AT) yahoo (DOT) com" <quikquic (AT) yahoo (DOT) com> writes
Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have in C++?

Well malloc and new do not implement the same concept. But in C++ you
also have realloc and if matter enough you can use that as long as you
also use malloc. However notice that realloc presupposes that you are
handling a dynamic array. In C++ you would use std::vector for such a
purpose. There is nothing to prevent an implementor from making memory
allocation as efficient as possible but that becomes a QoI issue.


--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Howard Hinnant
Guest





PostPosted: Thu Oct 02, 2003 10:59 pm    Post subject: Re: realloc in c++ Reply with quote



In article <ead1f717.0310011615.61419b5f (AT) posting (DOT) google.com>,
[email]quikquic (AT) yahoo (DOT) com[/email] (quikquic (AT) yahoo (DOT) com) wrote:

Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have in
C++?

vector<T>::resize(size_type, value_type);

-Howard

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Maciej Sobczak
Guest





PostPosted: Thu Oct 02, 2003 11:48 pm    Post subject: Re: realloc in c++ Reply with quote

Hi,

[email]quikquic (AT) yahoo (DOT) com[/email] wrote:
Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have in C++?

std::vector<char> buf(100);
buf.resize(200);

or:

boost::scoped_array buf(new char[100]);
buf.reset(new char[200]);

Or, better yet, please write us what problem do you want to solve.
It is often the case that when the group is challenged with higher-level
question, the collective solution is much different (and usually much
better) than what the original poster initially thought.

--
Maciej Sobczak


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Daniel Pfeffer
Guest





PostPosted: Thu Oct 02, 2003 11:49 pm    Post subject: Re: realloc in c++ Reply with quote

<quikquic (AT) yahoo (DOT) com> wrote

Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have
in C++?


In the general case, you don't. In order to implement a generic renew<T>,
you would have to ensure that every class is "copy constructible", or that
every class has an assignment operator. There are many cases in which the
existence of such operators is a bad idea.

If you require dynamic re-allocation of a vector of objects, I suggest that
you use the std::vector template.


HTH,
Daniel Pfeffer



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
WW
Guest





PostPosted: Fri Oct 03, 2003 11:19 am    Post subject: Re: realloc in c++ Reply with quote

[email]quikquic (AT) yahoo (DOT) com[/email] wrote:
Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we
have in C++?

new bigger
copy
delete old

OR

write a language proposal what Bjarne Stroustrup will like to get a "renew"
or a new_in_place or something.

--
WW aka Attila



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Aaron Bentley
Guest





PostPosted: Fri Oct 03, 2003 11:40 am    Post subject: Re: realloc in c++ Reply with quote

[email]quikquic (AT) yahoo (DOT) com[/email] wrote:
Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we have in C++?

Andrei Alexandrescu.
:-)

http://www.cuj.com/documents/s=7988/cujcexp1912alexandr/

One cute thing he points out is that realloc() is a complete replacement
for both malloc() and free()!

Aaron

--
Aaron Bentley
www.aaronbentley.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Bjarne Stroustrup
Guest





PostPosted: Sat Oct 04, 2003 8:40 am    Post subject: Re: realloc in c++ Reply with quote

"WW" <wolof (AT) freemail (DOT) hu> :news1.kolumbus.fi>

Quote:
For "malloc" in C, we have "new" in c++. For "realloc" in C, what we
have in C++?

new bigger
copy
delete old

OR

write a language proposal what Bjarne Stroustrup will like to get a "renew"
or a new_in_place or something.

Or simply use std::vector; it can expand using resize() or push_back()

- Bjarne Stroustrup; http://www.research.att.com/~bs

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Joshua Lehrer
Guest





PostPosted: Sun Oct 05, 2003 12:10 am    Post subject: Re: realloc in c++ Reply with quote

Aaron Bentley <aaron.bentley (AT) utoronto (DOT) ca> wrote


Quote:
One cute thing he points out is that realloc() is a complete replacement
for both malloc() and free()!


I never understood why this surprised anyone. realloc changes a
pointer size from its original size to a new size. If the source size
is 0, and the new size is non zero, then, clearly, this has to do an
allocation (malloc). If the source size is non-zero, and the target
size is 0, then, clearly, this is a full deallocation (free).

To me, the interface only makes sense this way.

joshua lehrer
factset research systems
NYSE:FDS

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
WW
Guest





PostPosted: Sun Oct 05, 2003 1:16 am    Post subject: Re: realloc in c++ Reply with quote

Bjarne Stroustrup wrote:
Quote:
write a language proposal what Bjarne Stroustrup will like to get
a "renew" > or a new_in_place or something.

Or simply use std::vector; it can expand using resize() or push_back()

Do you also sometimes feel you are being watched? :-)

As I have given the above comment with the above poor attempt of humor as an
*alternative* to:

new bigger
copy
delete old

IMHO the vector is not really an alternative of possible in-place
reallocation of the stuff - since it does exaclty the above - unless it has
some optimization for PODs, and then agaon it will only attempt to "trick"
if it has a POD inside.

That "C++ realloc" would of course need a completely new feature. If we
wanted to base it on realloc we would still need some way to tell to
realloc: do *not* copy the stuff. Because it is unnecessary. In case the
reallocation happens in place we are fine. We just construct the new
elements in the new area.

Yet another attrocity to be committed in the name of optimization. Awaiting
for further correction. ;-)

--
WW aka Attila



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Howard Hinnant
Guest





PostPosted: Sun Oct 05, 2003 9:27 am    Post subject: Re: realloc in c++ Reply with quote

In article <blm8fv$b8s$1 (AT) phys-news1 (DOT) kolumbus.fi>,
"WW" <wolof (AT) freemail (DOT) hu> wrote:

Quote:
Bjarne Stroustrup wrote:
write a language proposal what Bjarne Stroustrup will like to get
a "renew" > or a new_in_place or something.

Or simply use std::vector; it can expand using resize() or push_back()

Do you also sometimes feel you are being watched? :-)

As I have given the above comment with the above poor attempt of humor as an
*alternative* to:

new bigger
copy
delete old

IMHO the vector is not really an alternative of possible in-place
reallocation of the stuff - since it does exaclty the above - unless it has
some optimization for PODs, and then agaon it will only attempt to "trick"
if it has a POD inside.

That "C++ realloc" would of course need a completely new feature. If we
wanted to base it on realloc we would still need some way to tell to
realloc: do *not* copy the stuff. Because it is unnecessary. In case the
reallocation happens in place we are fine. We just construct the new
elements in the new area.

Yet another attrocity to be committed in the name of optimization. Awaiting
for further correction. Wink

We need two things for vector to blow new/copy/delete out of the water:

1. Move semantics:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm

2. Ability to expand in place:

http://www.armdevzone.com/EABI/malloc_helpers.htm

Both are technically feasible today. It just has to be standardized.
If these two proposals were standardized (plus a few other arcane but
fully backwards compatible details) the performance advantages of
vector<T, my_fast_allocator over a built-in array would be
insurmountable. And with the addition of a template alias:

template <class T>
using Vec = std::vector<T, my_fast_allocator;

( http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf )

the use of customized allocators to faciliate expansion in place would
become quite practical. We would be in a position to say:

Quote:
If you do not use Vec<MyClass> instead of new/copy/delete MyClass, you are
going to experience a serious performance hit.

-Howard

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Gabriel Dos Reis
Guest





PostPosted: Sun Oct 05, 2003 1:27 pm    Post subject: Re: realloc in c++ Reply with quote

"WW" <wolof (AT) freemail (DOT) hu> writes:

Quote:
Bjarne Stroustrup wrote:
write a language proposal what Bjarne Stroustrup will like to get
a "renew" > or a new_in_place or something.

Or simply use std::vector; it can expand using resize() or push_back()

Do you also sometimes feel you are being watched? :-)

As I have given the above comment with the above poor attempt of humor as an
*alternative* to:

new bigger
copy
delete old

IMHO the vector is not really an alternative of possible in-place
reallocation of the stuff - since it does exaclty the above - unless it has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


You may be surprised by what your favorite implementation of the
standard library does with vector<T>::resize.

[...]

Quote:
That "C++ realloc" would of course need a completely new feature. If we

No, it would not. vector<T>::resize is sufficient.

Quote:
wanted to base it on realloc we would still need some way to tell to
realloc: do *not* copy the stuff. Because it is unnecessary. In case the
reallocation happens in place we are fine. We just construct the new
elements in the new area.

Did you bother looking at existings implementation of vector<T>::resize?

-- Gaby

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Francis Glassborow
Guest





PostPosted: Sun Oct 05, 2003 2:14 pm    Post subject: Re: realloc in c++ Reply with quote

In article <blm8fv$b8s$1 (AT) phys-news1 (DOT) kolumbus.fi>, WW <wolof (AT) freemail (DOT) hu>
writes
Quote:
Or simply use std::vector; it can expand using resize() or push_back()

Do you also sometimes feel you are being watched? :-)

As I have given the above comment with the above poor attempt of humor as an
*alternative* to:

new bigger
copy
delete old

IMHO the vector is not really an alternative of possible in-place
reallocation of the stuff - since it does exaclty the above - unless it has
some optimization for PODs, and then agaon it will only attempt to "trick"
if it has a POD inside.

But std::vector is a Standard Library template and so it CAN use special
handling. It can even 'know' if it is possible to extend the current
allocation regardless of the PODness of the elements.

What we shied away from (with good reason IMO) was trying to lay down
requirements about when memory should be extended in situ. BTW realloc
makes no such promise, and could always (when required to actually
provide memory rather than by a weird version of free) follow the
strategy:

malloc replacement
copy original
free original

all that vector does is to extend this strategy. Well it would if we
could force shrinkage. But that would be one step further than realloc
which can elect to do nothing if required memory is less than current
memory. I.e. realloc does not actually do the things that many people
seem to think it does.


--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
WW
Guest





PostPosted: Mon Oct 06, 2003 12:01 am    Post subject: Re: realloc in c++ Reply with quote

Gabriel Dos Reis wrote:
Quote:
As I have given the above comment with the above poor attempt of
humor as an *alternative* to:

new bigger
copy
delete old

IMHO the vector is not really an alternative of possible in-place
reallocation of the stuff - since it does exaclty the above - unless
it has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You may be surprised by what your favorite implementation of the
standard library does with vector<T>::resize.

I would be surprised. First of all I have no favoriute one. Second is the
ones I remember does exactly what I have described. Remember: I am not
talking about vectors of PODs!

Quote:
[...]

That "C++ realloc" would of course need a completely new feature.
If we

No, it would not. vector<T>::resize is sufficient.

In your world. In mine doing twice the work just because there is no in
place realloc for non-PODs is not sufficient.

Quote:
wanted to base it on realloc we would still need some way to tell to
realloc: do *not* copy the stuff. Because it is unnecessary. In
case the reallocation happens in place we are fine. We just
construct the new elements in the new area.

Did you bother looking at existings implementation of
vector<T>::resize?

Did you bother to read and try to understand what I wrote? I am getting
really tired of you turning everything back on me. In this thread as well
as in the lvalue thread. If you have something concrete to say: say it so.
If all you have is innuendos then I for one are not interested in them.

BTW just to check how justified are your questions I looked at the STL which
happens to be installed on my PC here. It does:

allocate new
copy old stuff
deallocate old

Just as I wrote. Instead of:

Try to increase in place
if worked use the new space
if not
allocate new
copy old stuff
deallocate old

--
WW aka Attila



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
WW
Guest





PostPosted: Mon Oct 06, 2003 12:01 am    Post subject: Re: realloc in c++ Reply with quote

Francis Glassborow wrote:
[SNIP]
Quote:
But std::vector is a Standard Library template and so it CAN use
special handling. It can even 'know' if it is possible to extend the
current allocation regardless of the PODness of the elements.

Yes. But unless there is C library support for this writers of portable
standard library implementations will be unable to provide this service
without significant effort.

Quote:
What we shied away from (with good reason IMO) was trying to lay down
requirements about when memory should be extended in situ.

And it is not needed either. If it is possible (possible being
implementation defined but without the request of being documented) it will
be done. If not, it will be reported it is not:

void *attempt_extend( void*, size_t);

Returns 0 if it cannot extend, the same pointer if it did. Or it can return
a pointer to a new area, while *not* releasing the old (in case there was no
way to extend in place).

--
WW aka Attila



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Goto page 1, 2, 3 ... 21, 22, 23  Next
Page 1 of 23

 
Jump to:  
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


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.