Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: bad alloc Date: Tue, 06 Sep 2011 17:00:22 +1200 Lines: 31 Message-ID: <9clnn7F72aU2@mid.individual.net> References: <28a1b207-f29e-4d7d-81ca-490aa64bb808@z18g2000yqb.googlegroups.com> <214b61f9-0a26-446d-9bcf-6da7d70326d9@k15g2000yqd.googlegroups.com> <38b94512-ef13-4168-b057-f095ed7c91b7@c19g2000yqe.googlegroups.com> <9dbad43a-f341-44ac-b3cb-14cb8f3eb909@l2g2000vbn.googlegroups.com> <6bfba27a-a5bd-42df-b3b9-d1d393958665@fd21g2000vbb.googlegroups.com> <9cb8rmFfcoU1@mid.individual.net> <64024153-4384-44d8-aec8-b097c44e848e@t5g2000yqj.googlegroups.com> <9cfti9FsstU5@mid.individual.net> <8c52f625-7360-43c4-aee3-13b9a4484971@h9g2000vbr.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net pHKKDxhAxe8gLMt7mLugtg0xUzn1KaXydv1HkqtVwkrhDOIHWm Cancel-Lock: sha1:LTUjYy0AlP5afoxuRAXZPepP3B4= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: <8c52f625-7360-43c4-aee3-13b9a4484971@h9g2000vbr.googlegroups.com> Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:9775 On 09/ 5/11 05:56 AM, James Kanze wrote: > On Sep 4, 1:03 am, Ian Collins wrote: >> On 09/ 4/11 11:20 AM, James Kanze wrote: > >>> On Sep 2, 6:45 am, Ian Collins wrote: >>>> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > >>> [...] >>>> I agree. On a descent hosted environment, memory exhaustion is usually >>>> down to either a system wide problem, or a programming error. > >>> Or an overly complex client request. > >> Not spotting those is a programming (or specification) error! > > And the way you spot them is by catching bad_alloc:-). > > Seriously, the problem is very much like that of a compiler. > Nest parentheses too deep, and the compiler will run out of > memory. There are two solutions: specify an artificial nesting > limit, which you know you can handle (regardless of how many > connections are active, etc.), or react when you run out of > resources. There are valid arguments for both solutions, and > I've used both, in different applications. I have also seen both in compilers. For example last time I played, g++ didn't have a recursion limit for templates (as used in meta-programming) while Sun CC does. -- Ian Collins