malloc() and free()

>>4
On most implementations, new/delete are just calls to malloc/free. The only way they're superior is that new is typesafe, in the sense that it returns the asked pointer, and the allocation looks a bit more 'pretty' than the usual type* var = (type*)malloc(sizeof(type),count); (+maybe memset to zero it, if needed) or type* var = (type*)calloc(count,sizeof(type)). I tend to use calloc most of the time, instead of malloc, except when I know for sure that the memory will be fully overwritten/initialized (for example, I would use malloc when reading a whole file from disk, since there's no reason to null everything, just to have it overwritten by the file from disk). Of course, if you're using SEPPLES, you already have more problems, so just switching because you want to use new/delete is silly.

Fragmentation isn't really that big of an issue, in the worst case, it just means you can't alloc big blocks of memory if you've used up a lot of memory and fragmented it badly. It could also be slightly bad for those that still have paging files, but those people have a lot more to worry than malloc/free fragmenting the heap.

If you're that worried about fragmentation, you have a few options:
1) Quick&Dirty, but simple solution used by most people: use the OSes page allocator (on Windows - VirtualAlloc/VirtualFree, on *nix - mmap/munmap). This is useful especially if the memory blocks are very large and short-lived. You can make a compatibility layer if you desire portability (#IFDEF's or whatever your language offers).
2) Proper solution (for low-level languages), but a huge pain to use.
   Make a handle <-> memory area (heap or pages, depending on how you design your system). Before use, call a lock method/function on the handle to acquire its current pointer. Using lock will also set a flag which forbids the memory manager to re-arrange blocks of memory.  When you're done using, you should call an unlock method/function. You can have another thread compact the memory areas/realloc as you need to avoid fragmentation, or have it done on alloc/free operations or only when needed (not enough space). Your memory compactor should avoid any locked blocks. Alloc function should return a handle to the memory adress, free function should receive a handle and free the memory block represented by the handle. Some syntax sugar in the form of macros can be provided (in a Lispy language, it could be with-pinned-memory, altough various managed languages provide similar with* constructs) to make things easier for the user(so he doesn't have to lock/unlock everything by hand - you're now adding even more needed bookkeeping than the usual malloc/free bookkeeping).
It might be worth mentioning that if you're on Windows and the application doesn't have to be portable, GlobalAlloc/GlobalFree/GlobalHandle/GlobalFree/GlobalLock/GlobalReAlloc/GlobalCompact(obsolete)/GlobalSize/GlobalUnlock and a few other functions provide this functionality without you having to implement it from scratch.

It remains without saying that you should not free/unmap memory alloced by such systems in different ways than they were mapped.

I have my doubts if this method is really worth using. The quick&dirty solution is usually enough for most projects and requires little changes to overall code, compared to this.

3) Proper solution (for high-level languages). Very easy to use.
   Just use a compacting gc or whatever the language provides, and forget about memory management, at least unless you really have to do it for some reason (use FFI or specific library functions to do it then).

>>13
In C, casting the return value of malloc is at best pointless, and at worst dangerous.

>>14
Oh right, it's void*. It's just a bad habbit that stayed with me, altough it's usually harmless, as I'm only casting void* to a more specific pointer type. The reason I even developed this bad habbit is probably because the malloc prototype wasn't present once when I forgot to include stdlib.h.

>>14
Except in actual fact, where it's good practice.

>>16
No it's not. What the hell purpose does it serve? None whatsoever.

>>17
It should be completely mandatory in fact. But C is a weakly typed language and we have be forgiving.

>>17
It demonstrates that you know what you're doing, which makes finding bugs later on easier.

>>19
It demonstrates jack and shit, aside from that you can type the same thing twice. IHBT

>>20
aside from that you can type the same thing twice
It's C, what do you expect

>>21
Competent programmers.

There is no need to cast the result of library functions that return void *; it makes your code hard to read, adds no value, and can hide a bug if you don't have a valid prototype in scope. See http://www.cpax.org.uk/prg/writings/casting.php and http://c-faq.com/malloc/mallocnocast.html

>>23
Ｉ ｌｉｋｅ　ｙｏｕ．　Ｙｏｕ　ｃａｎ　ｃｏｍｅ　ｏｖｅｒ　ｔｏ　ｍｙ　ｈｏｕｓｅ　ａｎｄ　ｆｕｃｋ　ｍｙ　ｓｉｓｔｅｒ！

>>23
Most people would include stdlib.h eventually and it would only be a problem if both these conditions are satisfied: 1)No stdlib.h included 2)sizeof(void*)!=sizeof(int) (not the case on x86) 3)ints store the sign in an unusual way.

>>25
no guarantee that sizeof(void*) == sizeof(int) on x86, although that's the case on every 32-bit protected mode x86 system I've ever used, which tend to use ILP32.  x86-64 operating systems seem to use LP64 or LLP64, where sizeof(void*) == 8 and sizeof(int) == 4.  x86 systems could use LP32 too.

>>25
Are you some sort of brain-damaged C++ programmer or something?

>>13
Thank you :)

>>27
No. What made you think that? I haven't said anything about C++ in my post.

>>29
You're still trying to come up with reasons why you should cast malloc, even though there's so many reasons why you should not. Of the programmers I have worked with most of the ones who insist on throwing casts around in ways that could get you shot in the foot, the vast majority also preferred C++ for some reason. (I'm guessing probably because you have to cast it in C++ because it bitches about things that really should work and are perfectly valid C code. Backward compatible my ass.) But, even after acknowledging the ways casting could go wrong, you still don't seem to be against doing so.

Oh, and you can't count to 3.