[Interest] memory fragmentation?

[Alex Malyushytskyy]

>>Nonsense. Any application using a gigabyte or more of memory should HAVE
SWITCHED to 64-bit a couple of years ago.

It is not nonsense.
You provide to users version which works on their system (whatever they have).

And even though application may need close to 2GB of data (or more) to
work efficiently,
it does not mean that it can't be run on 32 bit computers to solve
reasonable problems there.
It does not mean that you can't recommend user to use 64 bit version
of the code.
You have to make sure your application either handles all the tasks
correctly, be efficient if possible,
or at least it has to notify user that specific task can't be handled
on this specific system as early as possible.

Crashing or even exiting due to insufficient memory in the middle of
long term task is not a choice.

>> What can be done to combat this in C++/Qt?

As it was said above you can control memory allocation yourself, up to
the point you can write your own garbage collector.
All applications I know which are designed to work with huge amount of
memory (especially large than available RAM) are utilizing its own
memory handling.
System due to generality normally is too inefficient for your specific case.

For example one of our application on Windows ( this is the case when
Windows is more flexible than Linux)

 - reserves  the largest amount of continues memory we could afford
for data (leaving enough for your widgets ) using VirtualAlloc with
MEM_RESERVE flag,
This insures that this address range will not be used when regular
memory allocation occurs.

- When data is loaded VirtualAlloc is called with MEM_COMMIT flag to
allocate as much memory as needed.
This approach works well since reservation takes no time, time
consuming operation is (normally associated with memory allocations)
committing.

Unfortunately it is way too difficult to give good advice without
knowing application details.

Regards,
  Alex