Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12911 > unrolled thread

C++ Memory Management Question

Back to article view | Back to comp.lang.c++

Contents

  C++ Memory Management Question Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-12-31 08:56 -0500
    Re: C++ Memory Management Question Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-31 09:44 -0500
      Re: C++ Memory Management Question Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-12-31 10:17 -0500
        Re: C++ Memory Management Question "MikeWhy" <boat042-nospam@yahoo.com> - 2011-12-31 12:56 -0600
        Re: C++ Memory Management Question jt@toerring.de (Jens Thoms Toerring) - 2011-12-31 19:05 +0000
      Re: C++ Memory Management Question Carlo Milanesi <carlo.nospam.milanesi@libero.it> - 2011-12-31 18:18 +0100
        Re: C++ Memory Management Question Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-31 13:04 -0500
          Re: C++ Memory Management Question Carlo Milanesi <carlo.nospam.milanesi@libero.it> - 2011-12-31 19:42 +0100
          Re: C++ Memory Management Question Goran <goran.pusic@gmail.com> - 2011-12-31 23:25 -0800
            Re: C++ Memory Management Question Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-01 09:39 -0500
              Re: C++ Memory Management Question Goran <goran.pusic@gmail.com> - 2012-01-01 08:20 -0800
              Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-01 19:05 +0000
                Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-01 19:36 +0000
                  Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-01 19:49 +0000
                    Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 11:26 +0000
                      Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-02 14:32 +0000
                        Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 15:54 +0000
                          Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-02 16:26 +0000
                            Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 16:58 +0000
                              Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-02 21:14 +0000
                                Re: C++ Memory Management Question Ian Collins <ian-news@hotmail.com> - 2012-01-03 11:11 +1300
                                Re: C++ Memory Management Question scott@slp53.sl.home (Scott Lurndal) - 2012-01-03 20:53 +0000
                                  Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-03 21:21 +0000
                                  Re: C++ Memory Management Question Ian Collins <ian-news@hotmail.com> - 2012-01-04 12:15 +1300
                                Re: C++ Memory Management Question gwowen <gwowen@gmail.com> - 2012-01-04 08:20 -0800
                            Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 22:24 +0000
                              Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-02 22:55 +0000
                                Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 23:27 +0000
                                Re: C++ Memory Management Question Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 01:01 -0800
                        Re: C++ Memory Management Question 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-02 21:45 -0800
                          Re: C++ Memory Management Question Goran <goran.pusic@gmail.com> - 2012-01-03 00:32 -0800
                            Re: C++ Memory Management Question "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-03 17:34 +0000
                        Re: C++ Memory Management Question Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 00:47 -0800
                          Re: C++ Memory Management Question BCFD36 <bcfd36@cruzio.com> - 2012-01-10 22:57 -0800
                Re: C++ Memory Management Question Ian Collins <ian-news@hotmail.com> - 2012-01-03 09:31 +1300
                  Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-02 21:02 +0000
                    Re: C++ Memory Management Question Ian Collins <ian-news@hotmail.com> - 2012-01-03 11:09 +1300
            Re: C++ Memory Management Question Leigh Johnston <leigh@i42.co.uk> - 2012-01-01 18:57 +0000
        Re: C++ Memory Management Question jgk@panix.com (Joe keane) - 2012-01-01 22:04 +0000
          Re: C++ Memory Management Question Carlo Milanesi <carlo.nospam.milanesi@libero.it> - 2012-01-02 00:37 +0100
            Re: C++ Memory Management Question yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-01-09 17:41 +0000
              Re: C++ Memory Management Question Carlo Milanesi <carlo.milanesi@libero.it> - 2012-01-13 08:14 -0800
      Re: C++ Memory Management Question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-01 18:05 +0000
    Re: C++ Memory Management Question Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-31 07:25 -0800
    Re: C++ Memory Management Question Torsten Mueller <dev-null@shared-files.de> - 2011-12-31 16:41 +0100
    Re: C++ Memory Management Question Nobody <nobody@nowhere.com> - 2012-01-01 09:16 +0000
      Re: C++ Memory Management Question Datesfat Chicks <datesfat.chicks@gmail.com> - 2012-01-02 16:48 -0500
        Re: C++ Memory Management Question Goran <goran.pusic@gmail.com> - 2012-01-03 00:02 -0800
          Re: C++ Memory Management Question Datesfat Chicks <datesfat.chicks@gmail.com> - 2012-01-03 12:53 -0500
            Re: C++ Memory Management Question Nobody <nobody@nowhere.com> - 2012-01-03 19:46 +0000
            Re: C++ Memory Management Question Goran <goran.pusic@gmail.com> - 2012-01-04 00:11 -0800
              Re: C++ Memory Management Question Nobody <nobody@nowhere.com> - 2012-01-04 09:30 +0000
      Re: C++ Memory Management Question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-04 19:28 +0000
        Re: C++ Memory Management Question Nobody <nobody@nowhere.com> - 2012-01-04 22:09 +0000
          Re: C++ Memory Management Question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-05 11:43 +0000
    Re: C++ Memory Management Question Christian Gollwitzer <auriocus@gmx.de> - 2012-01-01 18:13 +0100
      Re: C++ Memory Management Question "io_x" <a@b.c.invalid> - 2012-01-01 20:11 +0100
      Re: C++ Memory Management Question Datesfat Chicks <datesfat.chicks@gmail.com> - 2012-01-02 16:51 -0500
    Re: C++ Memory Management Question Simon Quinn <sq@nospam.com> - 2012-01-05 07:54 +0000
    Re: C++ Memory Management Question darylew@gmail.com - 2012-01-10 10:19 -0800

Page 1 of 3  [1] 2 3  Next page →

#12911 — C++ Memory Management Question

I'm just learning C++ (after being a 19-year C veteran), so forgive
any naive questions or concerns.

It seems to me that C++ has more inherent reliance on dynamic memory
allocation than C.  It doesn't have to be that way in all cases (many
classes would be implemented without dynamic allocation), but it seems
more natural in C++ that dynamic allocation would appear in programs.

Here are my questions:

a)I'm assuming that malloc() and free() are still available in C++?

b)Do these draw from the same memory pool as "new" and "delete"?

My reason for asking that question is that I'm looking for a graceful
strategy if dynamic memory gets exhausted.

The obvious strategy that comes to mind is:

a)When the program starts, grab a good chunk of memory using malloc().

b)If the dynamic memory gets exhausted via "new" and friends, handle
the exception.  In the exception handler, free() the memory allocated
by (a) and set a flag to signal the program to gracefully exit as soon
as it can.

c)Hopefully the memory released by free() would be enough to allow the
program to exit gracefully (rather than a sudden less controlled
exit).

Is this sane?  Is there a better way?

Thanks, DFC

[toc] | [next] | [standalone]

#12915

On 12/31/2011 8:56 AM, Datesfat Chicks wrote:
> I'm just learning C++ (after being a 19-year C veteran), so forgive
> any naive questions or concerns.
>
> It seems to me that C++ has more inherent reliance on dynamic memory
> allocation than C.  It doesn't have to be that way in all cases (many
> classes would be implemented without dynamic allocation), but it seems
> more natural in C++ that dynamic allocation would appear in programs.

The reality is simpler: it's easier to do dynamic memory properly in C++ 
(purposefully so, actually), and that's the reason more people resort to 
it.  In fact I've written plenty of code that never allocated anything 
in the free store (except by any library mechanisms that I had no 
control over).  You don't have to use dynamic memory if you don't need it.

> Here are my questions:
>
> a)I'm assuming that malloc() and free() are still available in C++?

That's not a question, you know.  And, they are.

> b)Do these draw from the same memory pool as "new" and "delete"?

Usually.  Unless you've overridden 'new' and 'delete' and made THEM 
"draw" from some other place.

> My reason for asking that question is that I'm looking for a graceful
> strategy if dynamic memory gets exhausted.

Good luck.

> The obvious strategy that comes to mind is:
>
> a)When the program starts, grab a good chunk of memory using malloc().

And do what with it?  Just sit on it?  That's a serious waste of memory.

> b)If the dynamic memory gets exhausted via "new" and friends, handle
> the exception.  In the exception handler, free() the memory allocated
> by (a) and set a flag to signal the program to gracefully exit as soon
> as it can.

Explain "gracefully exit".  I mean, explain it to yourself, keeping in 
mind that your process was *interrupted* by a *failed attempt* to get 
more memory.

> c)Hopefully the memory released by free() would be enough to allow the
> program to exit gracefully (rather than a sudden less controlled
> exit).

So, your strategy is "reserve [a preset amount of] some resource until 
it's desperately needed, then release it and pray that it's enough to 
kill the process", right?

> Is this sane?

How about I don't answer this, and you instead get a second look at it 
at your convenience?

 >  Is there a better way?

This question is asked here countless times every year.  How about *you* 
google for it and try to find out how successful your predecessors were? 
  And if you find something that suits you, by all means use it.  If you 
don't, *and* you have spare time, by all means look for it.  But my 
advice (based on experience trying to handle it and seeing others trying 
to handle it) is, don't waste your time.  If your process has run out of 
memory, the best solution is to restart it with *more memory*.

And, again, good luck!

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#12916

On Sat, 31 Dec 2011 09:44:24 -0500, Victor Bazarov
<v.bazarov@comcast.invalid> wrote:

>So, your strategy is "reserve [a preset amount of] some resource until 
>it's desperately needed, then release it and pray that it's enough to 
>kill the process", right?
>
>> Is this sane?
>
>How about I don't answer this, and you instead get a second look at it 
>at your convenience?
>
> >  Is there a better way?
>
>This question is asked here countless times every year.  How about *you* 
>google for it and try to find out how successful your predecessors were? 
>  And if you find something that suits you, by all means use it.  If you 
>don't, *and* you have spare time, by all means look for it.  But my 
>advice (based on experience trying to handle it and seeing others trying 
>to handle it) is, don't waste your time.  If your process has run out of 
>memory, the best solution is to restart it with *more memory*.
>
>And, again, good luck!

I was thinking primarily about GUI applications that model check and
so on.

A "graceful" exit would be graceful enough to stop current
computations, finish writing log files and so on with the fact that
the computations had to be stopped, then announcing to the user that
computations had to be stopped.

The reason for releasing memory when "new" fails is that without doing
that, the application couldn't even make it to a point where it could
finish writing log files and let the user know they're copulated.

For the type of applications I have in mind, the task would already
have been run with the maximum amount of memory available, and short
of rephrasing the computation or using a different computer, no
options would be available to the user.

Thanks for your input, DFC

[toc] | [prev] | [next] | [standalone]

#12929

"Datesfat Chicks" <datesfat.chicks@gmail.com> wrote in message 
news:tu8uf7lkiqlh6dc759je5vnblkgaufcr5t@4ax.com...
> For the type of applications I have in mind, the task would already
> have been run with the maximum amount of memory available, and short
> of rephrasing the computation or using a different computer, no
> options would be available to the user.

What system? The virtual address space for a 32-bit Windows app is 2 GB; 
much larger on 64-bit. Are you really in danger of running out of heap? What 
is your process doing?

[toc] | [prev] | [next] | [standalone]

#12930

Datesfat Chicks <datesfat.chicks@gmail.com> wrote:
> The reason for releasing memory when "new" fails is that without doing
> that, the application couldn't even make it to a point where it could
> finish writing log files and let the user know they're copulated.

There could be at least two things that might throw a spanner
into the works when you try to "pre-allocate" memory. First,
on multi-tasking systems when you release the pre-allocated
memory you're not always guaranteed that you will get it back
when you then call 'new' - a different process may have been
run in between and just grabbed the memory you released (if
this can happen depends a lot on the system and how it hand-
les memory). And then there's something called "memory over-
commitment", i.e. even though malloc() returns succesfully
you still might have your process killed when you try to use
it. This feature was added on some systems because there are
a lot of programs that do pre-allocation of memory they never
use, so the system signals that memory is available but may
not actually give it to you when you need it and memory has
become exhausted. This can only be avoided by either getting
the administrator of the machine to switch off overcommitment
or by "using" the memory you got (by writing to it). Of cour
se, the details again will be rather system specific.

On the other hand, is a scenario where memory is that exhaus-
ed that you won't get enough even for simple clean-up tasks
really something you have to worry that much about? Normally
you will run out of memory when you need really lots of it
and then there will typically still be enough available for
the clean-up (as long as they don't also need huge amounts).
So, is that a problem you need to solve in a way that there
is not the slightest chance that it can ever occur? As I
read in one of Tanenbaum's books sometimes the best solu-
tion to a rare problem can be to stick your head in the
sand and pretend that it won't happen (see also "ostrich
algorithm";-)
                        Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#12921

Il 31/12/2011 15:44, Victor Bazarov ha scritto:
>  > Is there a better way?
>
> my
> advice (based on experience trying to handle it and seeing others trying
> to handle it) is, don't waste your time. If your process has run out of
> memory, the best solution is to restart it with *more memory*.

So, if your word processor cannot load a huge document, or your video 
editor cannot load a huge piece of footage, you'd like the application 
terminate at once without saving anything :(
I think it would be better to undo the last command, and inform the user 
that the command failed for the memory shortage (compared to the size of 
the document).

To grant a graceful exit, I would ensure that the shutdown routines do 
not allocate any memory, by reserving beforehand all the needed memory 
space.

-- 

Carlo Milanesi
http://carlomilanesi.wordpress.com/

[toc] | [prev] | [next] | [standalone]

#12927

On 12/31/2011 12:18 PM, Carlo Milanesi wrote:
> Il 31/12/2011 15:44, Victor Bazarov ha scritto:
>> > Is there a better way?
>>
>> my
>> advice (based on experience trying to handle it and seeing others trying
>> to handle it) is, don't waste your time. If your process has run out of
>> memory, the best solution is to restart it with *more memory*.
>
> So, if your word processor cannot load a huge document, or your video
> editor cannot load a huge piece of footage, you'd like the application
> terminate at once without saving anything :(

No, not without saying anything.  But saying anything often does NOT 
require memory allocation, nor do I consider "saying anything" a 
graceful exist.

Neither a word processor nor a video editor should even attempt loading 
anything if it determines that the attempt might cause it to run out of 
memory.  If they can't determine that before opening the file, they 
aren't worth our time to discuss them.

Now, the usual way WRT handling memory constraints is *not to let the 
process to run out of memory* in the first place, instead of trying to 
do anything after it has happened.

> I think it would be better to undo the last command, and inform the user
> that the command failed for the memory shortage (compared to the size of
> the document).

Undoing the last command can require allocating of memory...

> To grant a graceful exit, I would ensure that the shutdown routines do
> not allocate any memory, by reserving beforehand all the needed memory
> space.

That's good.  What happens if the process runs out of memory while 
trying to allocate the memory for those shutdown routines?

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#12928

On 31/12/2011 19:04, Victor Bazarov wrote:
>> terminate at once without saving anything :(
>
> No, not without saying anything. But saying anything often does NOT
> require memory allocation, nor do I consider "saying anything" a
> graceful exist.

I wrote "saving" not "saying". I mean, if an application has several 
documents open and one document cannot be loaded, it's better to abort 
only the loading of that document, without closing all the documents, 
and possibly lose changes to them.

> Neither a word processor nor a video editor should even attempt loading
> anything if it determines that the attempt might cause it to run out of
> memory. If they can't determine that before opening the file, they
> aren't worth our time to discuss them.

Is there a way to determine if the next memory allocation will succeed?

To execute Adobe Flash applets, the Firefox Web browser executes a 
process named "plugin-container.exe". I've seen that if there is not not 
enough memory to run one Adobe Flash applet, all Adobe Flash applets 
running in different Firefox windows terminate at once, showing an error 
message in a gray area.
I don't think that is a good behavior, but I think it is rather typical.
It's good that Firefox itself doesn't terminate.

> Now, the usual way WRT handling memory constraints is *not to let the
> process to run out of memory* in the first place, instead of trying to
> do anything after it has happened.

With some programs that is not possible (or it is quite hard to do), as 
it is the user that decides the size of the data to keep in memory.

>> I think it would be better to undo the last command, and inform the user
>> that the command failed for the memory shortage (compared to the size of
>> the document).
>
> Undoing the last command can require allocating of memory...

Undoing a partially performed (uncommitted) document load may mean just 
unrolling the stack and let destructors do their deallocations. And this 
is already done by the exception mechanism. If all has been properly 
loaded, then a pointer to the loaded contents is inserted in the document.

>> To grant a graceful exit, I would ensure that the shutdown routines do
>> not allocate any memory, by reserving beforehand all the needed memory
>> space.
>
> That's good. What happens if the process runs out of memory while trying
> to allocate the memory for those shutdown routines?

That allocation should happens at startup of the application, before 
larger allocations. If that fails, nothing can be done.

-- 

Carlo Milanesi
http://carlomilanesi.wordpress.com/

[toc] | [prev] | [next] | [standalone]

#12935

On Dec 31 2011, 7:04 pm, Victor Bazarov <v.baza...@comcast.invalid>
wrote:
> On 12/31/2011 12:18 PM, Carlo Milanesi wrote:
>
> > Il 31/12/2011 15:44, Victor Bazarov ha scritto:
> >> > Is there a better way?
>
> >> my
> >> advice (based on experience trying to handle it and seeing others trying
> >> to handle it) is, don't waste your time. If your process has run out of
> >> memory, the best solution is to restart it with *more memory*.
>
> > So, if your word processor cannot load a huge document, or your video
> > editor cannot load a huge piece of footage, you'd like the application
> > terminate at once without saving anything :(
>
> No, not without saying anything.  But saying anything often does NOT
> require memory allocation, nor do I consider "saying anything" a
> graceful exist.
>
> Neither a word processor nor a video editor should even attempt loading
> anything if it determines that the attempt might cause it to run out of
> memory.  If they can't determine that before opening the file, they
> aren't worth our time to discuss them.

I disagree. There's no guarantee whatsoever that any allocation will
succeed, so theoretically, your idea is unsound. Practically, it's
difficult to implement more often than not. I was doing it, and
looking back, it was an error. E.g. it's easy only if you merely load
file contents into memory. I don't believe that happens all that
often.

What you're saying is equivalent to going to supermarket to see
whether it has mayonnaise, then going back for money, then coming back
to buy.

Goran.

[toc] | [prev] | [next] | [standalone]

#12940

On 1/1/2012 2:25 AM, Goran wrote:
> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
> wrote:
>> Neither a word processor nor a video editor should even attempt loading
>> anything if it determines that the attempt might cause it to run out of
>> memory.  If they can't determine that before opening the file, they
>> aren't worth our time to discuss them.
>
> I disagree. There's no guarantee whatsoever that any allocation will
> succeed, so theoretically, your idea is unsound. Practically, it's
> difficult to implement more often than not. I was doing it, and
> looking back, it was an error. E.g. it's easy only if you merely load
> file contents into memory. I don't believe that happens all that
> often.
>
> What you're saying is equivalent to going to supermarket to see
> whether it has mayonnaise, then going back for money, then coming back
> to buy.

Not at all.  There is always some reasonable portion that, when 
allocated fresh, is likely to be granted to the process.  And if 
allocating that reasonable portion fails, quit and tell the user he 
can't use that system for that operation without any changes (e.g. 
making some more resources available by either adding spare ones or 
releasing the ones currently used).  I am saying that if you come to the 
store to buy mayonnaise, there is (a) no sense to reach into your pocket 
if the mayo is not on the shelf (file is missing), (b) no need to buy 
the lifetime's worth in advance (even if you know what your lifetime is 
going to be).  We buy mayo in portions, consume, then come to buy some 
more.  Besides, we have replenishment of money, so it's  a bad analogy 
anyway.

In 1960s programmers wrote solving large systems of linear equations 
(hundreds and even thousands) on a system that only had 100 cells of 
memory.  How did they manage?  What is so different about it when it's 
not 100 but 100 billion cells?  There will be problems that aren't going 
to fit in memory whole.  Another example: on MS-DOS there was a text 
editor called MultiEdit that managed to deal with files much larger than 
the available 640KB.  How did they do it?

What I am saying is that there is always a way to deal with large 
amounts of data without having to load it all in memory.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#12942

On Jan 1, 3:39 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 1/1/2012 2:25 AM, Goran wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
> > wrote:
> >> Neither a word processor nor a video editor should even attempt loading
> >> anything if it determines that the attempt might cause it to run out of
> >> memory.  If they can't determine that before opening the file, they
> >> aren't worth our time to discuss them.
>
> > I disagree. There's no guarantee whatsoever that any allocation will
> > succeed, so theoretically, your idea is unsound. Practically, it's
> > difficult to implement more often than not. I was doing it, and
> > looking back, it was an error. E.g. it's easy only if you merely load
> > file contents into memory. I don't believe that happens all that
> > often.
>
> > What you're saying is equivalent to going to supermarket to see
> > whether it has mayonnaise, then going back for money, then coming back
> > to buy.
>
> Not at all.  There is always some reasonable portion that, when
> allocated fresh, is likely to be granted to the process.  And if
> allocating that reasonable portion fails,

But in your previous post you said

>> Neither a word processor nor a video editor should even attempt loading
>> anything if it determines that the attempt might cause it to run out of
>> memory.

... and now you're saying that you will try to allocate memory.

That doesn't make good sense.

> quit and tell the user he
> can't use that system for that operation without any changes (e.g.
> making some more resources available by either adding spare ones or
> releasing the ones currently used).  I am saying that if you come to the
> store to buy mayonnaise, there is (a) no sense to reach into your pocket
> if the mayo is not on the shelf (file is missing), (b) no need to buy
> the lifetime's worth in advance (even if you know what your lifetime is
> going to be).  We buy mayo in portions, consume, then come to buy some
> more.  Besides, we have replenishment of money, so it's  a bad analogy
> anyway.

I disagree. We're possibly lacking mayonnaise, not money. In my
analogy, it is assumed that one does have money, just like it is
assumed that one can _call_ allocation function. You changed my
analogy!

> In 1960s programmers wrote solving large systems of linear equations
> (hundreds and even thousands) on a system that only had 100 cells of
> memory.  How did they manage?  What is so different about it when it's
> not 100 but 100 billion cells?  There will be problems that aren't going
> to fit in memory whole.  Another example: on MS-DOS there was a text
> editor called MultiEdit that managed to deal with files much larger than
> the available 640KB.  How did they do it?
>
> What I am saying is that there is always a way to deal with large
> amounts of data without having to load it all in memory.

I agree with that. But that's another problem, really, one of design.
Question here is clearly how to handle the situation where expected
resource isn't here __without__ changing the design (not right away,
at least).

Goran.

[toc] | [prev] | [next] | [standalone]

#12946

On 01/01/2012 14:39, Victor Bazarov wrote:
> On 1/1/2012 2:25 AM, Goran wrote:
>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>> wrote:
>>> Neither a word processor nor a video editor should even attempt loading
>>> anything if it determines that the attempt might cause it to run out of
>>> memory. If they can't determine that before opening the file, they
>>> aren't worth our time to discuss them.
>>
>> I disagree. There's no guarantee whatsoever that any allocation will
>> succeed, so theoretically, your idea is unsound. Practically, it's
>> difficult to implement more often than not. I was doing it, and
>> looking back, it was an error. E.g. it's easy only if you merely load
>> file contents into memory. I don't believe that happens all that
>> often.
>>
>> What you're saying is equivalent to going to supermarket to see
>> whether it has mayonnaise, then going back for money, then coming back
>> to buy.
>
> Not at all. There is always some reasonable portion that, when allocated
> fresh, is likely to be granted to the process. And if allocating that
> reasonable portion fails, quit and tell the user he can't use that
> system for that operation without any changes (e.g. making some more
> resources available by either adding spare ones or releasing the ones
> currently used). I am saying that if you come to the store to buy
> mayonnaise, there is (a) no sense to reach into your pocket if the mayo
> is not on the shelf (file is missing), (b) no need to buy the lifetime's
> worth in advance (even if you know what your lifetime is going to be).
> We buy mayo in portions, consume, then come to buy some more. Besides,
> we have replenishment of money, so it's a bad analogy anyway.
>
> In 1960s programmers wrote solving large systems of linear equations
> (hundreds and even thousands) on a system that only had 100 cells of
> memory. How did they manage? What is so different about it when it's not
> 100 but 100 billion cells? There will be problems that aren't going to
> fit in memory whole. Another example: on MS-DOS there was a text editor
> called MultiEdit that managed to deal with files much larger than the
> available 640KB. How did they do it?
>
> What I am saying is that there is always a way to deal with large
> amounts of data without having to load it all in memory.

I agree with Goran; you are talking rubbish; there is no standard way to 
determine if an allocation *attempt* will succeed or not; to avoid OOM 
either pre-allocate whatever you need up front if memory requirements 
are bounded otherwise you must handle allocation *failures*.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12948

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews.com...
> On 01/01/2012 14:39, Victor Bazarov wrote:
>> On 1/1/2012 2:25 AM, Goran wrote:
>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>> wrote:
>>>> Neither a word processor nor a video editor should even attempt loading
>>>> anything if it determines that the attempt might cause it to run out of
>>>> memory. If they can't determine that before opening the file, they
>>>> aren't worth our time to discuss them.
>>>
>>> I disagree. There's no guarantee whatsoever that any allocation will
>>> succeed, so theoretically, your idea is unsound. Practically, it's
>>> difficult to implement more often than not. I was doing it, and
>>> looking back, it was an error. E.g. it's easy only if you merely load
>>> file contents into memory. I don't believe that happens all that
>>> often.
>>>
>>> What you're saying is equivalent to going to supermarket to see
>>> whether it has mayonnaise, then going back for money, then coming back
>>> to buy.
>>
>> Not at all. There is always some reasonable portion that, when allocated
>> fresh, is likely to be granted to the process. And if allocating that
>> reasonable portion fails, quit and tell the user he can't use that
>> system for that operation without any changes (e.g. making some more
>> resources available by either adding spare ones or releasing the ones
>> currently used). I am saying that if you come to the store to buy
>> mayonnaise, there is (a) no sense to reach into your pocket if the mayo
>> is not on the shelf (file is missing), (b) no need to buy the lifetime's
>> worth in advance (even if you know what your lifetime is going to be).
>> We buy mayo in portions, consume, then come to buy some more. Besides,
>> we have replenishment of money, so it's a bad analogy anyway.
>>
>> In 1960s programmers wrote solving large systems of linear equations
>> (hundreds and even thousands) on a system that only had 100 cells of
>> memory. How did they manage? What is so different about it when it's not
>> 100 but 100 billion cells? There will be problems that aren't going to
>> fit in memory whole. Another example: on MS-DOS there was a text editor
>> called MultiEdit that managed to deal with files much larger than the
>> available 640KB. How did they do it?
>>
>> What I am saying is that there is always a way to deal with large
>> amounts of data without having to load it all in memory.
>
> I agree with Goran; you are talking rubbish; there is no standard way to 
> determine if an allocation *attempt* will succeed or not; to avoid OOM 
> either pre-allocate whatever you need up front if memory requirements are 
> bounded otherwise you must handle allocation *failures*.
>
The problem with this discussion is that its very OS speific.

To create a robust memory managment system would require good knowledge of 
the underlying OS and an understanding of all possible allocation failures.

I think it is possible that an OS may provide methods for checking available 
memory.

I do agree with Carlo that profession programmes should exit gracefully , if 
possible. True it may not always be possible as there may be times when a 
complete system crash is inevitable , but a program should at least *try* to 
save work or recover under low memory conditions. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#12949

On 01/01/2012 19:36, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews.com...
>> On 01/01/2012 14:39, Victor Bazarov wrote:
>>> On 1/1/2012 2:25 AM, Goran wrote:
>>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>>> wrote:
>>>>> Neither a word processor nor a video editor should even attempt loading
>>>>> anything if it determines that the attempt might cause it to run out of
>>>>> memory. If they can't determine that before opening the file, they
>>>>> aren't worth our time to discuss them.
>>>>
>>>> I disagree. There's no guarantee whatsoever that any allocation will
>>>> succeed, so theoretically, your idea is unsound. Practically, it's
>>>> difficult to implement more often than not. I was doing it, and
>>>> looking back, it was an error. E.g. it's easy only if you merely load
>>>> file contents into memory. I don't believe that happens all that
>>>> often.
>>>>
>>>> What you're saying is equivalent to going to supermarket to see
>>>> whether it has mayonnaise, then going back for money, then coming back
>>>> to buy.
>>>
>>> Not at all. There is always some reasonable portion that, when allocated
>>> fresh, is likely to be granted to the process. And if allocating that
>>> reasonable portion fails, quit and tell the user he can't use that
>>> system for that operation without any changes (e.g. making some more
>>> resources available by either adding spare ones or releasing the ones
>>> currently used). I am saying that if you come to the store to buy
>>> mayonnaise, there is (a) no sense to reach into your pocket if the mayo
>>> is not on the shelf (file is missing), (b) no need to buy the lifetime's
>>> worth in advance (even if you know what your lifetime is going to be).
>>> We buy mayo in portions, consume, then come to buy some more. Besides,
>>> we have replenishment of money, so it's a bad analogy anyway.
>>>
>>> In 1960s programmers wrote solving large systems of linear equations
>>> (hundreds and even thousands) on a system that only had 100 cells of
>>> memory. How did they manage? What is so different about it when it's not
>>> 100 but 100 billion cells? There will be problems that aren't going to
>>> fit in memory whole. Another example: on MS-DOS there was a text editor
>>> called MultiEdit that managed to deal with files much larger than the
>>> available 640KB. How did they do it?
>>>
>>> What I am saying is that there is always a way to deal with large
>>> amounts of data without having to load it all in memory.
>>
>> I agree with Goran; you are talking rubbish; there is no standard way to
>> determine if an allocation *attempt* will succeed or not; to avoid OOM
>> either pre-allocate whatever you need up front if memory requirements are
>> bounded otherwise you must handle allocation *failures*.
>>
> The problem with this discussion is that its very OS speific.
>
> To create a robust memory managment system would require good knowledge of
> the underlying OS and an understanding of all possible allocation failures.
>
> I think it is possible that an OS may provide methods for checking available
> memory.
>
> I do agree with Carlo that profession programmes should exit gracefully , if
> possible. True it may not always be possible as there may be times when a
> complete system crash is inevitable , but a program should at least *try* to
> save work or recover under low memory conditions.

That is fine if "save work" or "recover" do not allocate memory 
otherwise they may also suffer a memory allocation failure.  Aborting 
the program (what you call "crashing") on allocation failure is 
perfectly acceptable for a subset of all possible programs and this is 
what will happen if you don't handle (catch) allocation failure 
exceptions such as std::bad_alloc.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12976

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:EaOdnR_ieaQwJZ3SnZ2dnUVZ8nCdnZ2d@giganews.com...
> On 01/01/2012 19:36, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews.com...
>>> On 01/01/2012 14:39, Victor Bazarov wrote:
>>>> On 1/1/2012 2:25 AM, Goran wrote:
>>>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>>>> wrote:
>>>>>> Neither a word processor nor a video editor should even attempt 
>>>>>> loading
>>>>>> anything if it determines that the attempt might cause it to run out 
>>>>>> of
>>>>>> memory. If they can't determine that before opening the file, they
>>>>>> aren't worth our time to discuss them.
>>>>>
>>>>> I disagree. There's no guarantee whatsoever that any allocation will
>>>>> succeed, so theoretically, your idea is unsound. Practically, it's
>>>>> difficult to implement more often than not. I was doing it, and
>>>>> looking back, it was an error. E.g. it's easy only if you merely load
>>>>> file contents into memory. I don't believe that happens all that
>>>>> often.
>>>>>
>>>>> What you're saying is equivalent to going to supermarket to see
>>>>> whether it has mayonnaise, then going back for money, then coming back
>>>>> to buy.
>>>>
>>>> Not at all. There is always some reasonable portion that, when 
>>>> allocated
>>>> fresh, is likely to be granted to the process. And if allocating that
>>>> reasonable portion fails, quit and tell the user he can't use that
>>>> system for that operation without any changes (e.g. making some more
>>>> resources available by either adding spare ones or releasing the ones
>>>> currently used). I am saying that if you come to the store to buy
>>>> mayonnaise, there is (a) no sense to reach into your pocket if the mayo
>>>> is not on the shelf (file is missing), (b) no need to buy the 
>>>> lifetime's
>>>> worth in advance (even if you know what your lifetime is going to be).
>>>> We buy mayo in portions, consume, then come to buy some more. Besides,
>>>> we have replenishment of money, so it's a bad analogy anyway.
>>>>
>>>> In 1960s programmers wrote solving large systems of linear equations
>>>> (hundreds and even thousands) on a system that only had 100 cells of
>>>> memory. How did they manage? What is so different about it when it's 
>>>> not
>>>> 100 but 100 billion cells? There will be problems that aren't going to
>>>> fit in memory whole. Another example: on MS-DOS there was a text editor
>>>> called MultiEdit that managed to deal with files much larger than the
>>>> available 640KB. How did they do it?
>>>>
>>>> What I am saying is that there is always a way to deal with large
>>>> amounts of data without having to load it all in memory.
>>>
>>> I agree with Goran; you are talking rubbish; there is no standard way to
>>> determine if an allocation *attempt* will succeed or not; to avoid OOM
>>> either pre-allocate whatever you need up front if memory requirements 
>>> are
>>> bounded otherwise you must handle allocation *failures*.
>>>
>> The problem with this discussion is that its very OS speific.
>>
>> To create a robust memory managment system would require good knowledge 
>> of
>> the underlying OS and an understanding of all possible allocation 
>> failures.
>>
>> I think it is possible that an OS may provide methods for checking 
>> available
>> memory.
>>
>> I do agree with Carlo that profession programmes should exit gracefully , 
>> if
>> possible. True it may not always be possible as there may be times when a
>> complete system crash is inevitable , but a program should at least *try* 
>> to
>> save work or recover under low memory conditions.
>
> That is fine if "save work" or "recover" do not allocate memory otherwise 
> they may also suffer a memory allocation failure.  Aborting the program 
> (what you call "crashing") on allocation failure is perfectly acceptable 
> for a subset of all possible programs and this is what will happen if you 
> don't handle (catch) allocation failure exceptions such as std::bad_alloc.
>

This is not what I meant by crashing, I said a system crash , that is the OS 
encountering a unrecoverable and critical error. You are speaking about 
aborting a program , a program just dying whenever it encounters an 
exception.. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#12980

On 02/01/2012 11:26, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:EaOdnR_ieaQwJZ3SnZ2dnUVZ8nCdnZ2d@giganews.com...
>> On 01/01/2012 19:36, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews.com...
>>>> On 01/01/2012 14:39, Victor Bazarov wrote:
>>>>> On 1/1/2012 2:25 AM, Goran wrote:
>>>>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>>>>> wrote:
>>>>>>> Neither a word processor nor a video editor should even attempt
>>>>>>> loading
>>>>>>> anything if it determines that the attempt might cause it to run out
>>>>>>> of
>>>>>>> memory. If they can't determine that before opening the file, they
>>>>>>> aren't worth our time to discuss them.
>>>>>>
>>>>>> I disagree. There's no guarantee whatsoever that any allocation will
>>>>>> succeed, so theoretically, your idea is unsound. Practically, it's
>>>>>> difficult to implement more often than not. I was doing it, and
>>>>>> looking back, it was an error. E.g. it's easy only if you merely load
>>>>>> file contents into memory. I don't believe that happens all that
>>>>>> often.
>>>>>>
>>>>>> What you're saying is equivalent to going to supermarket to see
>>>>>> whether it has mayonnaise, then going back for money, then coming back
>>>>>> to buy.
>>>>>
>>>>> Not at all. There is always some reasonable portion that, when
>>>>> allocated
>>>>> fresh, is likely to be granted to the process. And if allocating that
>>>>> reasonable portion fails, quit and tell the user he can't use that
>>>>> system for that operation without any changes (e.g. making some more
>>>>> resources available by either adding spare ones or releasing the ones
>>>>> currently used). I am saying that if you come to the store to buy
>>>>> mayonnaise, there is (a) no sense to reach into your pocket if the mayo
>>>>> is not on the shelf (file is missing), (b) no need to buy the
>>>>> lifetime's
>>>>> worth in advance (even if you know what your lifetime is going to be).
>>>>> We buy mayo in portions, consume, then come to buy some more. Besides,
>>>>> we have replenishment of money, so it's a bad analogy anyway.
>>>>>
>>>>> In 1960s programmers wrote solving large systems of linear equations
>>>>> (hundreds and even thousands) on a system that only had 100 cells of
>>>>> memory. How did they manage? What is so different about it when it's
>>>>> not
>>>>> 100 but 100 billion cells? There will be problems that aren't going to
>>>>> fit in memory whole. Another example: on MS-DOS there was a text editor
>>>>> called MultiEdit that managed to deal with files much larger than the
>>>>> available 640KB. How did they do it?
>>>>>
>>>>> What I am saying is that there is always a way to deal with large
>>>>> amounts of data without having to load it all in memory.
>>>>
>>>> I agree with Goran; you are talking rubbish; there is no standard way to
>>>> determine if an allocation *attempt* will succeed or not; to avoid OOM
>>>> either pre-allocate whatever you need up front if memory requirements
>>>> are
>>>> bounded otherwise you must handle allocation *failures*.
>>>>
>>> The problem with this discussion is that its very OS speific.
>>>
>>> To create a robust memory managment system would require good knowledge
>>> of
>>> the underlying OS and an understanding of all possible allocation
>>> failures.
>>>
>>> I think it is possible that an OS may provide methods for checking
>>> available
>>> memory.
>>>
>>> I do agree with Carlo that profession programmes should exit gracefully ,
>>> if
>>> possible. True it may not always be possible as there may be times when a
>>> complete system crash is inevitable , but a program should at least *try*
>>> to
>>> save work or recover under low memory conditions.
>>
>> That is fine if "save work" or "recover" do not allocate memory otherwise
>> they may also suffer a memory allocation failure.  Aborting the program
>> (what you call "crashing") on allocation failure is perfectly acceptable
>> for a subset of all possible programs and this is what will happen if you
>> don't handle (catch) allocation failure exceptions such as std::bad_alloc.
>>
>
> This is not what I meant by crashing, I said a system crash , that is the OS
> encountering a unrecoverable and critical error. You are speaking about
> aborting a program , a program just dying whenever it encounters an
> exception..

This thread is not about unrecoverable or critical OS errors; it is 
about memory allocation failures.

Even if an OS provided a mechanism to determine available memory what 
guarantee would there be that the amount of available memory reported by 
such a function would be the same as the amount of available memory when 
the allocation request is actually made?

Are you suggesting that one should check available memory before calling 
any function that may allocate memory?  This is of course absurd.

Are you suggesting that in C++ one should only use the no-throw version 
of 'new' and check every allocation request at the site of the request 
and report an error and "save work" or "recover"?  This is of course absurd.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12981

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews.com...
> On 02/01/2012 11:26, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:EaOdnR_ieaQwJZ3SnZ2dnUVZ8nCdnZ2d@giganews.com...
>>> On 01/01/2012 19:36, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews.com...
>>>>> On 01/01/2012 14:39, Victor Bazarov wrote:
>>>>>> On 1/1/2012 2:25 AM, Goran wrote:
>>>>>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>>>>>> wrote:
>>>>>>>> Neither a word processor nor a video editor should even attempt
>>>>>>>> loading
>>>>>>>> anything if it determines that the attempt might cause it to run 
>>>>>>>> out
>>>>>>>> of
>>>>>>>> memory. If they can't determine that before opening the file, they
>>>>>>>> aren't worth our time to discuss them.
>>>>>>>
>>>>>>> I disagree. There's no guarantee whatsoever that any allocation will
>>>>>>> succeed, so theoretically, your idea is unsound. Practically, it's
>>>>>>> difficult to implement more often than not. I was doing it, and
>>>>>>> looking back, it was an error. E.g. it's easy only if you merely 
>>>>>>> load
>>>>>>> file contents into memory. I don't believe that happens all that
>>>>>>> often.
>>>>>>>
>>>>>>> What you're saying is equivalent to going to supermarket to see
>>>>>>> whether it has mayonnaise, then going back for money, then coming 
>>>>>>> back
>>>>>>> to buy.
>>>>>>
>>>>>> Not at all. There is always some reasonable portion that, when
>>>>>> allocated
>>>>>> fresh, is likely to be granted to the process. And if allocating that
>>>>>> reasonable portion fails, quit and tell the user he can't use that
>>>>>> system for that operation without any changes (e.g. making some more
>>>>>> resources available by either adding spare ones or releasing the ones
>>>>>> currently used). I am saying that if you come to the store to buy
>>>>>> mayonnaise, there is (a) no sense to reach into your pocket if the 
>>>>>> mayo
>>>>>> is not on the shelf (file is missing), (b) no need to buy the
>>>>>> lifetime's
>>>>>> worth in advance (even if you know what your lifetime is going to 
>>>>>> be).
>>>>>> We buy mayo in portions, consume, then come to buy some more. 
>>>>>> Besides,
>>>>>> we have replenishment of money, so it's a bad analogy anyway.
>>>>>>
>>>>>> In 1960s programmers wrote solving large systems of linear equations
>>>>>> (hundreds and even thousands) on a system that only had 100 cells of
>>>>>> memory. How did they manage? What is so different about it when it's
>>>>>> not
>>>>>> 100 but 100 billion cells? There will be problems that aren't going 
>>>>>> to
>>>>>> fit in memory whole. Another example: on MS-DOS there was a text 
>>>>>> editor
>>>>>> called MultiEdit that managed to deal with files much larger than the
>>>>>> available 640KB. How did they do it?
>>>>>>
>>>>>> What I am saying is that there is always a way to deal with large
>>>>>> amounts of data without having to load it all in memory.
>>>>>
>>>>> I agree with Goran; you are talking rubbish; there is no standard way 
>>>>> to
>>>>> determine if an allocation *attempt* will succeed or not; to avoid OOM
>>>>> either pre-allocate whatever you need up front if memory requirements
>>>>> are
>>>>> bounded otherwise you must handle allocation *failures*.
>>>>>
>>>> The problem with this discussion is that its very OS speific.
>>>>
>>>> To create a robust memory managment system would require good knowledge
>>>> of
>>>> the underlying OS and an understanding of all possible allocation
>>>> failures.
>>>>
>>>> I think it is possible that an OS may provide methods for checking
>>>> available
>>>> memory.
>>>>
>>>> I do agree with Carlo that profession programmes should exit gracefully 
>>>> ,
>>>> if
>>>> possible. True it may not always be possible as there may be times when 
>>>> a
>>>> complete system crash is inevitable , but a program should at least 
>>>> *try*
>>>> to
>>>> save work or recover under low memory conditions.
>>>
>>> That is fine if "save work" or "recover" do not allocate memory 
>>> otherwise
>>> they may also suffer a memory allocation failure.  Aborting the program
>>> (what you call "crashing") on allocation failure is perfectly acceptable
>>> for a subset of all possible programs and this is what will happen if 
>>> you
>>> don't handle (catch) allocation failure exceptions such as 
>>> std::bad_alloc.
>>>
>>
>> This is not what I meant by crashing, I said a system crash , that is the 
>> OS
>> encountering a unrecoverable and critical error. You are speaking about
>> aborting a program , a program just dying whenever it encounters an
>> exception..
>
> This thread is not about unrecoverable or critical OS errors; it is about 
> memory allocation failures.
>
> Even if an OS provided a mechanism to determine available memory what 
> guarantee would there be that the amount of available memory reported by 
> such a function would be the same as the amount of available memory when 
> the allocation request is actually made?
>
> Are you suggesting that one should check available memory before calling 
> any function that may allocate memory?  This is of course absurd.
>
No not at all. But such functions may exist.

> Are you suggesting that in C++ one should only use the no-throw version of 
> 'new' and check every allocation request at the site of the request and 
> report an error and "save work" or "recover"?  This is of course absurd.
>
Why is it absurd to check each allocation for a failure?



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#12982

On 02/01/2012 15:54, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews.com...
[snip]
>
>> Are you suggesting that in C++ one should only use the no-throw version of
>> 'new' and check every allocation request at the site of the request and
>> report an error and "save work" or "recover"?  This is of course absurd.
>>
> Why is it absurd to check each allocation for a failure?

If you knew how to properly use C++ exception handling you would not be 
asking that question.  You need to learn about RAII and such; I 
recommend you read a decent C++ book which should cover this (and it is 
not the first time I have made this recommendation to you).

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#12986

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:e8Kdnfm9b7RMR5zSnZ2dnUVZ7vOdnZ2d@giganews.com...
> On 02/01/2012 15:54, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews.com...
> [snip]
>>
>>> Are you suggesting that in C++ one should only use the no-throw version 
>>> of
>>> 'new' and check every allocation request at the site of the request and
>>> report an error and "save work" or "recover"?  This is of course absurd.
>>>
>> Why is it absurd to check each allocation for a failure?
>
> If you knew how to properly use C++ exception handling you would not be 
> asking that question.  You need to learn about RAII and such; I recommend 
> you read a decent C++ book which should cover this (and it is not the 
> first time I have made this recommendation to you).
>

You state something is absurd but when asked for reasoning behind such a 
statement you cannot give a reasonable answer. You are absurd.




--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#12995

On 02/01/2012 16:58, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:e8Kdnfm9b7RMR5zSnZ2dnUVZ7vOdnZ2d@giganews.com...
>> On 02/01/2012 15:54, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews.com...
>> [snip]
>>>
>>>> Are you suggesting that in C++ one should only use the no-throw version
>>>> of
>>>> 'new' and check every allocation request at the site of the request and
>>>> report an error and "save work" or "recover"?  This is of course absurd.
>>>>
>>> Why is it absurd to check each allocation for a failure?
>>
>> If you knew how to properly use C++ exception handling you would not be
>> asking that question.  You need to learn about RAII and such; I recommend
>> you read a decent C++ book which should cover this (and it is not the
>> first time I have made this recommendation to you).
>>
>
> You state something is absurd but when asked for reasoning behind such a
> statement you cannot give a reasonable answer. You are absurd.

Is that your first of many ad hominems of 2012?  In that spirit you are 
a proven homophobic bigoted troll who deserves little respect; why 
should I waste time teaching you how to use C++ properly?  Read a book 
and clean up your act.

/Leigh

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web