This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: realloc without moving?



To Chris: What exactly are your requirements?  You are aware that
glibc on Linux also has efficient realloc for very large chunks thanks
to the mremap() system call?



Hmm.. I may have to think about this harder :)

My exact area of interest is std::vector, that is the vector class provided in the C++ standard library (although I may expand my interest later).

When someone tries to add a new element (via .push_back) to an already full vector, then we must allocate a new larger block of memory and copy the existing vector into it.

Now if the class is sufficently simple (and we can check for that) then we can simply copy the old memory bit-for-bit into the new block. In this case a call to realloc is exactly what we want.

If however the elements of the vector are complex classes then this is forbidden, and this is where this reallocing business comes in. If we can expand the current allocation of memory that the vector is in, all is well and good. If however this is not possible, we cannot simply copy the elements of the vector bit-for-bit, we must allocate a new block of memory to put them in and use the class's copy constructors.

Chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]