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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#13002

On 01/ 3/12 10:14 AM, Leigh Johnston wrote:
>
> 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.

So why do you keep on giving it the attention it craves?

-- 
Ian Collins

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

#13041

Leigh Johnston <leigh@i42.co.uk> writes:
>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.

A bit harsh, don't you think?

Define "use C++ properly".   Isn't "properly" rather context-dependent?

For example, I've been writing in C++ since 1989.   Almost all of it
(several hundreds of thousands of lines) has been written commercially for
hypervisors (one for 3Leaf, one for SGI) and operating systems for very
large systems (256 processors in 1995) (Burroughs/Unisys).

In such code, one doesn't have an RTL, and the run-time overhead of exceptions
and newer features such as run-time typing is prohibitive.   Would you argue that
such code is not "proper"?   I wouldn't.  So exceptions aren't always the "proper"
answer to "how do I determine if my allocation failed (succeeded)?".

The first OS was written using cfront 2.1[*].   There were no exceptions, templates,
funky casts, etc.    Using classes to encapsulate data and associated methods with
data was of enough value that we felt it was the correct choice of implementation
language.    When 3.0 came out with templates, exceptions etc, we eschewed those
features due to the additional cost at run-time (space bloat in the case of templates).

scott

[*] cfront generated C code that made extensive use of the comma operator.   This caused
a couple of interesting bugs in the PCC (portable C compiler) we were using on
the Motorola 88100 processor systems;  the temporary register allocation code was
failing due to the expression tree being too large - I ended up modifying the temp 
register allocation code in PCC with a variation of sethi-ullman algorithm.

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

#13042

On 03/01/2012 20:53, Scott Lurndal wrote:
> Leigh Johnston<leigh@i42.co.uk>  writes:
>> 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.
>
> A bit harsh, don't you think?
>
> Define "use C++ properly".   Isn't "properly" rather context-dependent?
>
> For example, I've been writing in C++ since 1989.   Almost all of it
> (several hundreds of thousands of lines) has been written commercially for
> hypervisors (one for 3Leaf, one for SGI) and operating systems for very
> large systems (256 processors in 1995) (Burroughs/Unisys).
>
> In such code, one doesn't have an RTL, and the run-time overhead of exceptions
> and newer features such as run-time typing is prohibitive.   Would you argue that
> such code is not "proper"?   I wouldn't.  So exceptions aren't always the "proper"
> answer to "how do I determine if my allocation failed (succeeded)?".

Like it or not this newsgroup is about standard C++ and exceptions are 
part of standard C++.  If you cannot use exceptions then you cannot use 
standard C++ and this newsgroup is not really a suitable forum for any 
queries or solutions you may have.

/Leigh

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

#13049

On 01/ 4/12 09:53 AM, Scott Lurndal wrote:
>
> Define "use C++ properly".   Isn't "properly" rather context-dependent?
>
> For example, I've been writing in C++ since 1989.   Almost all of it
> (several hundreds of thousands of lines) has been written commercially for
> hypervisors (one for 3Leaf, one for SGI) and operating systems for very
> large systems (256 processors in 1995) (Burroughs/Unisys).
>
> In such code, one doesn't have an RTL, and the run-time overhead of exceptions
> and newer features such as run-time typing is prohibitive.

Shouldn't that be in the past tense?  I'm not aware of any contemporary 
compilers were the overhead of using exceptions is any more than C style 
return checking.  In every comparison I've run since the late 90s, 
exceptions have been faster.  Also nothing that calls its self a C++ 
compiler lacks a standard library.

> Would you argue that
> such code is not "proper"?   I wouldn't.  So exceptions aren't always the "proper"
> answer to "how do I determine if my allocation failed (succeeded)?".

Nor would I.  I have also worked in situations where "C with classes" 
(and even "C with function overloading") was a good fit.

> The first OS was written using cfront 2.1[*].   There were no exceptions, templates,
> funky casts, etc.    Using classes to encapsulate data and associated methods with
> data was of enough value that we felt it was the correct choice of implementation
> language.    When 3.0 came out with templates, exceptions etc, we eschewed those
> features due to the additional cost at run-time (space bloat in the case of templates).

Unfortunately memories of those long past runtime performance issues 
have stuck around.

-- 
Ian Collins

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

#13079

On Jan 2, 9:14 pm, Leigh Johnston <le...@i42.co.uk> wrote:

> 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?

And yet I suspect you will *continue* to waste your time on this, as
you have proved yourself utterly incapable of not doing so, despite
the colossal evidence that its a waste of perfectly good IP packets.












/**
 * Space above left for Leigh to call me a troll
 */
--
Killfiles cleared each calender year...

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

#13004

"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).
>
Allowing the program to terminate is not what I would call properly using 
C++ EH.
What is the point in RAII freeing up memory, with stack created object 
destructors, if the program is going to terminate anyway?
Apparently you dont use C++ EH because you simply allow the program to 
terminate and catch no exceptions, so how does this make you such an expert 
on the subject?



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

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

#13008

On 02/01/2012 22:24, 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).
>>
> Allowing the program to terminate is not what I would call properly using
> C++ EH.
> What is the point in RAII freeing up memory, with stack created object
> destructors, if the program is going to terminate anyway?
> Apparently you dont use C++ EH because you simply allow the program to
> terminate and catch no exceptions, so how does this make you such an expert
> on the subject?

So you have just spent half an hour reading up on RAII from the Web and 
of course you now think you are expert enough to make that comment?  Please.

RAII clean up kicks in when any exception is thrown not just 
std::bad_alloc exceptions.

I typically have a top-level try/catch in main() (which ensures RAII 
clean up happens for any exceptions I don't catch elsewhere) which 
displays a nice error message and then re-throws from that to cause 
process termination.

The type of program I am writing will dictate whether or not a 
std::bad_alloc exception raised during a particular type of object 
construction is recoverable or should result in program termination. 
Typically the software I write is layered in such a way that any 
try/catch is several layers removed from the function raising the 
exception; this is key to understanding why you don't want to explicitly 
check all possible memory allocation requests for failure in C++; C++ 
exception handling exists because it replaces the old fashioned checking 
of error codes of functions which sucks.

If you followed my advice months ago and read a decent C++ book you 
probably would not be still posting this usual dross of yours; accusing 
others of the ignorance which you yourself possess (a case of 
psychological projection).

HTH.

/Leigh

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

#13009

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:roSdnVh1J5d6qJ_SnZ2dnUVZ7vednZ2d@giganews.com...
> On 02/01/2012 22:24, 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).
>>>
>> Allowing the program to terminate is not what I would call properly using
>> C++ EH.
>> What is the point in RAII freeing up memory, with stack created object
>> destructors, if the program is going to terminate anyway?
>> Apparently you dont use C++ EH because you simply allow the program to
>> terminate and catch no exceptions, so how does this make you such an 
>> expert
>> on the subject?
>
> So you have just spent half an hour reading up on RAII from the Web and of 
> course you now think you are expert enough to make that comment?  Please.
>
> RAII clean up kicks in when any exception is thrown not just 
> std::bad_alloc exceptions.

RAII just gurantees that stack contructed objects will have thier 
destructors called.


>
> I typically have a top-level try/catch in main() (which ensures RAII clean 
> up happens for any exceptions I don't catch elsewhere) which displays a 
> nice error message and then re-throws from that to cause process 
> termination.

There is no point in RAII if you are simply going to terminate the process 
anyway, the OS will reclaim the resources on termination anyway.


>
> The type of program I am writing will dictate whether or not a 
> std::bad_alloc exception raised during a particular type of object 
> construction is recoverable or should result in program termination. 
> Typically the software I write is layered in such a way that any try/catch 
> is several layers removed from the function raising the exception; this is 
> key to understanding why you don't want to explicitly check all possible 
> memory allocation requests for failure in C++; C++ exception handling 
> exists because it replaces the old fashioned checking of error codes of 
> functions which sucks.

So according to you there is your typical way of doing things and what you 
describe as the old fashioned checking of error codes. No other style of 
programming is worth considering as far as you are concerned, only these two 
ways.

>
> If you followed my advice months ago and read a decent C++ book you 
> probably would not be still posting this usual dross of yours; accusing 
> others of the ignorance which you yourself possess (a case of 
> psychological projection).
>

I've known about C++ EH and RAII for many years , granted I am not recently 
familiar with this as I would be if I used it everyday, but I don't consider 
you to be an expert on this subject and I certainly don't think you are in a 
position to give me advice on it.



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

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

#13208

On Jan 2, 10:55 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 02/01/2012 22:24, Paul <pchrist wrote:
> > "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> >news:e8Kdnfm9b7RMR5zSnZ2dnUVZ7vOdnZ2d@giganews.com...
> >> On 02/01/2012 15:54, Paul<pchrist wrote:
> >>> "Leigh Johnston"<le...@i42.co.uk>   wrote in message
> >>>news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews.com...

> >>>> 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).
>
> > Allowing the program to terminate is not what I would call properly using
> > C++ EH.
> > What is the point in RAII freeing up memory, with stack created object
> > destructors, if the program is going to terminate anyway?
> > Apparently you dont use C++ EH because you simply allow the program to
> > terminate and catch no exceptions [...]

of course DTORs can do other things besides just freeing memory.

<snip>

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

#13017

Leigh Johnston於 2012年1月2日星期一UTC+8下午10時32分44秒寫道：
> On 02/01/2012 11:26, Paul 
>  "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> > news:EaOdnR_ieaQwJZ3SnZ2dnUVZ8nCdnZ2d@giganews.com...
> >> On 01/01/2012 19:36, Paul
> >> "Leigh Johnston"<le...@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

What are you talking about?
If you just play with programs that need small amount of memory from the OS, 
then a lot error checking operations can be omitted. 

But those are low paid programmers' jobs definitely. 

Please don't baby sister too much for those ambitious talented young 
to have the bad habits to avoid  exploring  and experimenting  for further professional tricks. 

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

#13021

On Jan 3, 6:45 am, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> > 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
>
> What are you talking about?
> If you just play with programs that need small amount of memory from the OS,
> then a lot error checking operations can be omitted.

Leigh is pretty much right on the money when calling systematic use of
nothrow absurd.

In normal C++, one uses throwing new and said error-checking is
indeed, well, not omitted, but replaced by exception handling and
RAII. You can't reasonably use new(nothrow) without lulling yourself
in the false sense of security. Or, you can, but you need to renounce
using STL and other parts of standard library, boost and many other
libraries, basically, you need to only use C libraries. That's doable,
but, as he said, absurd.

Goran.

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

#13030

"Goran" <goran.pusic@gmail.com> wrote in message 
news:d6bdd1d2-434e-40af-adfe-c19c10e8f558@k28g2000yqn.googlegroups.com...
On Jan 3, 6:45 am, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> > 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
>
> What are you talking about?
> If you just play with programs that need small amount of memory from the 
> OS,
> then a lot error checking operations can be omitted.

Leigh is pretty much right on the money when calling systematic use of
nothrow absurd.
-----------------------------------------------------------------

This idea whatever shite it is he has thought up about using nothrow 
versions of new, he has thought up himself and nobody else has introduced 
this idea into the discussion. Whether he is spot or not I don't care 
because I don't care about his stupid idea, that he himself has called 
absurd.




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

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

#13207

On Jan 2, 2:32 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 02/01/2012 11:26, Paul <pchrist wrote:
> > "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> >news:EaOdnR_ieaQwJZ3SnZ2dnUVZ8nCdnZ2d@giganews.com...
> >> On 01/01/2012 19:36, Paul<pchrist wrote:
> >>> "Leigh Johnston"<le...@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:


<snip>

> >>> 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.

agreed

> >> 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.

ok

> > This is not what I meant by crashing, I said a system crash ,
> > that is the OS
> > encountering a unrecoverable and critical error.

it's quite clear in context what "program crash" means.

> > 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?

If you have some control over what is running on the machine it makes
sense. I work in "semi-embedded" environments where the program has a
dedicated machine. We know what's runnig on the machine so we're less
likely to be surprised by memory suddenly vanishing. If the machine
runs out of memory it's usually our fault.

In these circumstances it makes sense to keep an eye on available
memory. particularly when doing memory expensive tasks.

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

yes

> 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.

fairly silly, as many news are small and available memory is large

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

#13228

On 1/10/12 12:47 AM, Nick Keighley wrote:
> On Jan 2, 2:32 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
[lots of stuff deleted]


>
>> 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.
>
> fairly silly, as many news are small and available memory is large

I am working on a satellite program. You know, one of those things that 
orbit the earth. It was decreed long ago (decades) that 
malloc/calloc/new/etc. would not be used on these systems. Ever, for any 
reason.

I can see the wisdom in this. It is not like you have easy access to a 
power-on reset button if this thing decides to crash a year or 5 years 
or 10 years after launch, or to some kind of a crash-dump.

And you can't just add new memory, but I'd like to be on the team that 
got the assignment to do it if it had to be done.

-- 
Dave Scruggs

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

#12993

On 01/ 2/12 08:05 AM, Leigh Johnston wrote:
> 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*.

What part of "there is always a way to deal with large amounts of data 
without having to load it all in memory" do you consider to be rubbish? 
  It's one of the oldest problems in computing.

-- 
Ian Collins

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

#12994

On 02/01/2012 20:31, Ian Collins wrote:
> On 01/ 2/12 08:05 AM, Leigh Johnston wrote:
>> 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*.
>
> What part of "there is always a way to deal with large amounts of data
> without having to load it all in memory" do you consider to be rubbish?
> It's one of the oldest problems in computing.

If that is what you thought I was referring to then you obviously are 
unable to follow a conversation; clue: "I agree with Goran".

When one replies to a post one is not necessarily only replying to the 
very last sentence of a post.

/Leigh

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

#13001

On 01/ 3/12 10:02 AM, Leigh Johnston wrote:
>
> When one replies to a post one is not necessarily only replying to the
> very last sentence of a post.

Then snip appropriately.

-- 
Ian Collins

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

#12945

On 01/01/2012 07:25, Goran wrote:
> 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 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]

#12953

In article <4eff43fa$0$16659$5fc30a8@news.tiscali.it>,
Carlo Milanesi  <carlo.nospam.milanesi@libero.it> wrote:
>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 it could produce a useful measage

a) your hard drive is full
b) this can't possibly work on your machine
c) we ran into VM problems, if you close something else, maybe it will work

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

#12957

On 01/01/2012 23:04, Joe keane wrote:
> In article<4eff43fa$0$16659$5fc30a8@news.tiscali.it>,
> Carlo Milanesi<carlo.nospam.milanesi@libero.it>  wrote:
>> 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 it could produce a useful measage
>
> a) your hard drive is full
> b) this can't possibly work on your machine
> c) we ran into VM problems, if you close something else, maybe it will work

I was sarcastic, of course.
However those messages are not really informative.
Microsoft Paint ("prush.exe", the bitmap editing utility included in 
Microsoft Windows) does something better.
I don't have the English version of it, but when I try to create an 
image of 20000 x 20000 pixels on my system (your system may be 
different), it waits a couple of seconds, then displays a message 
similar to "Insufficient memory or resources. Close one or more 
applications and retry", and it does not terminate, keeping open the 
previous bitmap. Obviously it tried to create such a large bitmap and 
failed, because if it had decided that such a bitmap was too large, it 
wouldn't wait that time, and it wouldn't suggest to close other 
applications.

-- 

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web