Thread: Lazy allocation and *alloc()

Really, I don't think you have to worry about that. I don't know, but I'd imagine that if a realloc() call needs to copy its data to another location in memory, the OS would simply reused the old physical address. In other words, it would be moved in virtual memory, but that portion of virtual memory would refer to the same physical memory.

(I really don't know what I'm talking about here, but I could see that happening.) [edit] Regarding bithub's post: Wow, my guess was right! [/edit]

Anyway, you *really* shouldn't allocate 1GB just because you can. Re-think your algorithm, use realloc(), and only if it's too slow go with another solution.

One thing you could do is to simulate lazy allocation in your own program. Let's say you have a data structure like this:

Code:

struct data_t {
    char data[20];
};

Maybe you want a huge, spare array or matrix of that data. You could then use

Code:

struct data_t *lookup(struct index_t where);

which would look into a table of allocated pages to see if "where" exists. If it does, you return the actual pointer to it; otherwise, you return NULL or maybe allocate space for the chunk. Some sort of hash table would probably be a good idea for this.

Of course, that's really just a spare matrix in disguise, so you should read up more on how they can be implemented . . . the only type of sparse matrix implementation I've ever done was in a program of mine called planedist. You can download it here: http://dwks.theprogrammingsite.com/m...anedist.tar.gz

[I believe you need SDL and SDL_gfx to compile it, which you can get here: Simple DirectMedia Layer]

explanation.txt in that archive describes the algorithm. Anyway, you could use something like that for your own code if you wanted to. Keep in mind that I know absolutely nothing about this subject and came up with that algorithm by myself after a few hours of puzzlement. No idea if it's any good . . . .