Thread: memory management...

New is good since it is a default way of allocating memory. You can make your own memory management system and then overload a class to use new (or delete) so that anyone else using your class can adapt to the change without learning any new syntax. New and delete are one of the advantages of the C++ langauge, not using them would be omitting part of the language. For example, I wouldn't say "I refuse to use the - sign for subtraction."

You know, and this is just my humble opinion, but I think it's kind of pathetic to want a statement added to a language because a programmer is too lazy to write either a macro or a function to meet their needs.

You only have to write it once because you can create your own libraries and headers, you know.

I just think it's kind of lazy to expect the world to change around a laziness issue... I also think it introduces yet another layer of obfuscation to new programmers about what's actually going on.

New and delete already know the type of the pointer thus eliminating the need or usefulness of typecasting with them. I don't know what new and delete will do if you actually find a way to re-type them via a typecast. Crashing your program is the first thing that comes to mind, especially if you are trying to change the type via a typecast.

If you are returning a pointer to memory then you are using void *. This is what malloc returns, but not new. Even though new does use malloc for allocation it does not return void *. New returns a correctly typed pointer to the newly allocated object. It creates the object or can also instantiate a class. Here it is allocating 4000 signed bytes and returning a correctly typed pointer.

char *Test=new char[4000];
int *Test=new int[4000]

This new returns char * not void *.
Test has been intialized and created. No typecast needed.
In the second one, 4000 integers are allocated - malloc(4000*sizeof(int)); or 8000 bytes.

Invalid:
char *Test=(unsigned int *)new char[4000];

The left side does not match the right side so this will not be accepted by the compiler.
This statement is not valid. You are telling the compiler to assign the character pointer Test to point to a character array (region of memory). However, the typecast is also telling the compiler that Test should be an unsigned int *, but new is saying char. This will flag an error in your compiler.

Here new is instantiating a class which calls MyClass's constructor.
Again, no typecast needed in this use or future uses of Test. It is already known.
MyClass *Test=new MyClass;

Since you use the datatype or class in the new statement, it is not correct to re-typecast the data type to a different type.

If you are wanting a mem management like in Windows then your functions should return void *. Then it is up to the programmer what data type his pointer is and he can do this with typecasting.

Code:

char FAR *Text=0;
HGLOBAL memhandle;
memhandle=GlobalAlloc(GPTR,2048);
Text=(char Far *)GlobalLock(memhandle);

Left side matched right side - char FAR *Text=(char FAR *) - void FAR * has been typecasted to char FAR *. Now Text is a signed character pointer.

GlobalAlloc will allocate the memory and return the handle to that area. To use it you must call GlobalLock to get a pointer to that area of memory. Here I've typecasted it to be a char FAR pointer -GlobalLock returns void FAR * so I can typecast it to whatever data type I want that memory to be.

You could write similar functions - one that allocs the memory and returns a handle - that is tracked by your mem management system. Then you call another function to lock that area and return a pointer to it. In a non-multi-task environment you need not track which process that mem belongs to, just that it has been locked and allocated and cannot be moved or tampered with. Then you can typecast the void far * or in DJGPP just void * to be whatever data type you need. Cleanup is not as clean since the type is really not known by your functions, just by you. They are merely returning a void * pointer which points to an address unknowing of the data type.

New and delete are much better and it might be beneficial for you to just override new and delete to get them to do exactly what you want. As long as you make destructors for each of your derived classes and for the base class, you should not have any problems with new and delete causing memory leaks.

Delete will only fail when the system has been messed up by a wild pointer or it is used with a pointer that has not been allocated with new or when you try to delete a null pointer - not a good idea

New will only fail if the system has been messed up by a wild pointer or if there is not enough memory for the object.

In protected mode a wild pointer should not mess up your system or frag someone else's code. Your code will surely cease functioning, but everything else *should* be fine.

I'm not sure about resizing memory areas with new - never had the need for it so I've never tried it. Pretty sure that since the object has already been created and init that this is not allowed. You must delete the pointer and realloc with the new size of the object.

Give me a better idea of what you want with this mem management thing and I'll help you code it. We've been through this mem thing a lot and perhaps I'm misunderstanding you - would love to help. Promise that I'll think outside of the box - just this once.

Assembly is very easy, especially if you read AoA. You will be amazed at how much power is packed into so few opcodes. And when you learn it well enough you will be able to do super fast graphics and pretty much super fast anything. Make sure you do a thorough read of it - expecially the chapter on Von Neumann arhitecture and CPU architecture. When you know how it all fits together you can create code that is much faster simply because it is working with the machine instead of against it. Excellent resource that AoA.

Now I see what you are doing. It is a simple bi-linear interpolation only you are doing it a bit different. Actually the bi-linear interpolation will be much faster than doing it the way you have been. No for loops, instead you will be calling your bilinear function for x,y,x+1,y+1 for RGB. This does cause 3 new stack frames to be set up in the calls - make sure your bilinear function is inlined and in pure asm (use the FPU). The inline should help a bit.