> if the requested storage that caused the heap to expand gets returned with a
> free() or delete I do not believe the C runtime issues a STORAGE
> RELEASE for the additional increment of heap: it keeps it around in
> anticipation of future malloc() or new requests. It does not RELEASE the
> hea
Does the HGPR compiler option make any difference?
z/OS 2.2.0>z/OS XL C/C++>z/OS XL C/C++ User's Guide>Compiler
options>Description of compiler options>HGPR | NOHGPR
Purpose
Enables the compiler to exploit 64-bit General Purpose Registers (GPRs) in
32-bit programs targeting z/Architecture® hard
On Thu, 19 Feb 2015 08:18:05 -0600, Ze'ev Atlas wrote:
>I still think that the decision, many decades ago, to leave the actual
>definition and implementation of short, int, long, etc. to the implementation
>rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I
>thought so
ursion I might
>be out of stack.
>
>One of the major chores my terminate routine does is lots and lots of
>delete's, so that would presumably free up heap.
>
...
On Fri, 23 Jan 2015 13:11:37 -0600, Carl Kugler
wrote:
>It seems to me that you have to be careful not to do to
On Fri, 23 Jan 2015 10:50:50 -0800, Charles Mills wrote:
>Works like a champ! That is exactly what David Crayford (thank you, David!)
>suggested off-line. I followed the spirit of this, but did things somewhat
>differently. In my new handler, I
>
>- Put out a diagnostic message
>- Call CEE3DMP
How about using set_new_handler() in your main() to register a new_handler()
that does a ctrace() followed by a throw(std::bad_alloc)?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@list
