ROTFLMAO! Louis Armstrong would've laughed too!

I never saw those drives. But I never saw an Apple Lisa either, outside of magazines... I do remember coming across a floppy drive that had two heads on each side of the armature.

I've seen each of those issues, just not all at the same time. :) With the system I was working on, the users were telling me that they wanted the bugs fixed and workflow changed, but my manager didn't hear it, so it didn't happen.

To be fair, 'flippies' were something we actually used for a time....

Reminds me of someone who once told me, "Our users aren't asking us to improve our internal processes, fix bugs or improve our code. When they start asking for that, you can work on it."

Though it annoys me that compilers are smart enough to replace what you tell them to do, with what you meant to tell them to do (even if you didn't know you meant to do it), that is a good safety feature. printf's can be very unsafe....

How about simplifying the effort and use puts()?

If the memory is returned, then it's not leaking. If you had a leak, then then the memory usage would keep growing until your application crashes. If you want your application to use less memory, then you'll have to look at how you use your data and the lifetime in which you keep it.

It looks like someone has given you a solution, so I'll explain a bit why this happens. The resizing of your image using GDI is a simple re-sampling algorithm. When you shrink it, pixels in a horizontal and vertical direction are removed, at a semi regular spacing, to make the image fit the new size. This has the effect of producing a horizontal and vertical waveform in your image. Your parallel lines in the image, also make up a wave pattern. When these two wave patterns interact, you get an interference pattern and see the Moire' effect. http://en.wikipedia.org/wiki/Moire_effect[^]

bool _tagXMLNode::RemoveChild( LPXNode node )
{
XNodes::iterator it = GetChildIterator( node );
if( it != childs.end() ) // Fixed it
{
delete *it;
childs.erase( it );
return true;
}
return false;
}

I'm, just now getting exposure to the Domain Model. From what I'm seeing in action at the moment, is that all hierarchies appear to be flat and relationships between objects are a mess to unravel and understand. It looks like spaghetti glue for OOD. I hope this isn't what the model is about... Gotta order that book today...

Sounds like they are taking the method's responsibility and applying it to the class level....

"Reading through your 3rd and 4th paragraph, it would seem to me that SOLID is not the problem, the developers that built the system do not understand how to apply SOLID." That's the impression I got. I can see how a narrow vision of what 'single use' or 'single responsibility' means, can lead to some bad design work.

If the leak is due to a bug in a third party library then there may be no workaround to your issue. The operating system already caches out memory to a page file on disk. If you're exceeding the 1 or 3gig limit set by the linker, then you're hitting the wall on addressable memory. You can't allocate more memory than you can address. With 32 bit pointers the theoretical limit is 2^32 bytes or 4gig. In practical terms it's less because some of the bits in the upper end of the pointer can have a special meaning. I've seen server side systems live with leaks like this, by periodically restarting. If you can prove that the third party library is leaking the memory with a simple test case, then I would raise this issue with your vendor.

I meant it for the thread anyway...

That's the best place to start. Make sure you have no memory leaks. If there is some reason that you need gigabytes of data in memory to do some heavy complex processing (perhaps DNA analysis, simulations etc...,) then upgrade your hardware and go 64 bit.

If you're dynamically creating the objects in your app, you can overload the 'new' operator. But that's not really going to do the trick. As others have mentioned data has to be in memory to be used.

What is the problem that you are trying to solve?

From this, it looks like something is including it in stdafx.h Comment out includes in this file until you find it. It's likely a third party library header, or a header file that is local to you project.

If you're using MFC, add this snippet above your code:

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Your memory leaks will then appear in the output window. Note that it doesn't work correctly with overloaded new constructors, so for those you may need some $ifdef guards.