Just my few cents:
>> Is your application a 32-bit app? Under Windows, applications are
restricted to 1.5 to 2 GB of memory even though the system has more
available. This even includes running a 32-bit app on a 64-bit system.
That is not exactly right. On Windows 32 , by default 32 bit application is
restricted to max of 2 GB of memory for data. You can adjust system to use
3Gb , but this is unusual.
This includes all memory and typically you can't get a continuous chunk of
memory over 1.8 GB.
At the same time (might depend on compiler options, if not mistaken for MVC
it is /largeaddressaware ) the same 32 bit application running on Windows
64 bit can address up to 4 GB of data.
>>A bit off-topic, but still: it's not a very good idea to make your
application's behavior/logic dependent on amount of free memory reported by
the system.
>>Reasons:
>>1) most, if not all, modern OSes use "delayed allocation" strategy, so a
successful malloc() or its equivalent doesn't guarantee you actually will
be able to use that >>memory;
>>2) multitasking means there's always a chance that during the period
between you request information about available RAM and try to use it
another process will >>allocate some amount of memory for its own needs,
causing your allocation to fail.
>>My suggestion is either to:
>>1) use system's native functions to get total amount of memory and use it
to determine the upper limit for your allication (e.g. never allocate more
than 50% of RAM >>even if it's not used by anything else);
There are cases when you need as much memory as system can provide,
otherwise it is a good suggestion if your upper limit is not more than is
allowed for process (This is really a concern for win32 ) .
I would add that If you need more memory then RAM available it is usually
better to manager swapping yourself, since usually it can be organized much
more efficient for specific cases than general approach used by system.
>>2) enlarge your buffers when necessary until you get an "out of memory"
signal in form of std::bad_alloc, NULL returned by an allocation function,
etc..
I would not advice this.
I see exception as a costly "emergency" feature which should never happen
in normal situation. It is much better to avoid this, especially if you
really need as much memory as you can get, cause looped allocation (until
it fails) is slow. It is much better to test process memory once. Keep in
mind that if you need a large continuous chunk of memory, that might be
far away from "available" memory for process even at startup due to data
from dll loaded, but Windows do provide sufficient information about memory
usage to counter this..
Regards
Alex
On Mon, Jul 8, 2013 at 10:20 AM, Constantin Makshin <cmaks...@gmail.com>wrote:
> A bit off-topic, but still: it's not a very good idea to make your
> application's behavior/logic dependent on amount of free memory reported by
> the system.
> Reasons:
> 1) most, if not all, modern OSes use "delayed allocation" strategy, so a
> successful malloc() or its equivalent doesn't guarantee you actually will
> be able to use that memory;
> 2) multitasking means there's always a chance that during the period
> between you request information about available RAM and try to use it
> another process will allocate some amount of memory for its own needs,
> causing your allocation to fail.
>
> My suggestion is either to:
> 1) use system's native functions to get total amount of memory and use it
> to determine the upper limit for your allication (e.g. never allocate more
> than 50% of RAM even if it's not used by anything else);
> 2) enlarge your buffers when necessary until you get an "out of memory"
> signal in form of std::bad_alloc, NULL returned by an allocation function,
> etc..
> On Jul 8, 2013 4:20 PM, <qt.dan...@free.fr> wrote:
>
>> Using 4.8 under windows / mingw, I catch a std::bad_alloc exception
>> raised somewhere, that I do not seem to have raised. At that point,
>> there is still 66% of system memory available according to windows.
>>
>> 1) Is there a Qt way to programmatically monitor the amount of RAM yet
>> available to the current process ?
>>
>> 2) Is there a standard way to debug this, in order to find where the
>> exception was raised ?
>>
>> Quentin
>> _______________________________________________
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
