From issues-return-2053-apmail-stdcxx-issues-archive=stdcxx.apache.org@stdcxx.apache.org Mon Jun 02 18:54:06 2008 Return-Path: Delivered-To: apmail-stdcxx-issues-archive@locus.apache.org Received: (qmail 62156 invoked from network); 2 Jun 2008 18:54:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jun 2008 18:54:06 -0000 Received: (qmail 27203 invoked by uid 500); 2 Jun 2008 18:54:08 -0000 Delivered-To: apmail-stdcxx-issues-archive@stdcxx.apache.org Received: (qmail 27178 invoked by uid 500); 2 Jun 2008 18:54:08 -0000 Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list issues@stdcxx.apache.org Received: (qmail 27167 invoked by uid 99); 2 Jun 2008 18:54:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 11:54:08 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 18:53:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 2DCBF234C126 for ; Mon, 2 Jun 2008 11:53:45 -0700 (PDT) Message-ID: <1308946878.1212432825180.JavaMail.jira@brutus> Date: Mon, 2 Jun 2008 11:53:45 -0700 (PDT) From: "Martin Sebor (JIRA)" To: issues@stdcxx.apache.org Subject: [jira] Updated: (STDCXX-209) make std::bad_alloc::what() more informative MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/STDCXX-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-209: -------------------------------- Severity: Usability Description: Moved from the Rogue Wave bug tracking database: {noformat} ****Created By: hoaglin @ Sep 17, 2004 07:46:13 PM**** **** Entered By: Web @ Thursday, September 09, 2004 8:01:23 AM **** #web Keith, I'm not doing garbage collection and I'm not looking for any change in the memory management. All I want is that when the new operator throws an exception it sticks the # of bytes of memory requested in the exception handler what() message. Surely this information is readily available where the exception is being thrown and I don't see why this should cause any overhead so long as no exception is being thrown, ****Modified By: sebor @ Apr 11, 2005 02:58:41 PM**** This would be useful but std::bad_alloc is thrown by the operator new defined by the runtime library that comes with the compiler. We have little control over what string the what() member function returns. We could wrap calls made by our library in another function, catch the bad_alloc there, and rethrow another exception derived from std::bad_alloc, where we could override what() and format the string so as to include the information the user is asking for but that would only take care of exceptions thrown as a result of running out of memory within the library itself and not user code. A better solution would be to send this request to compiler vendors. Deferred. {noformat} was: Moved from the Rogue Wave bug tracking database: ****Created By: hoaglin @ Sep 17, 2004 07:46:13 PM**** **** Entered By: Web @ Thursday, September 09, 2004 8:01:23 AM **** #web Keith, I'm not doing garbage collection and I'm not looking for any change in the memory management. All I want is that when the new operator throws an exception it sticks the # of bytes of memory requested in the exception handler what() message. Surely this information is readily available where the exception is being thrown and I don't see why this should cause any overhead so long as no exception is being thrown, ****Modified By: sebor @ Apr 11, 2005 02:58:41 PM**** This would be useful but std::bad_alloc is thrown by the operator new defined by the runtime library that comes with the compiler. We have little control over what string the what() member function returns. We could wrap calls made by our library in another function, catch the bad_alloc there, and rethrow another exception derived from std::bad_alloc, where we could override what() and format the string so as to include the information the user is asking for but that would only take care of exceptions thrown as a result of running out of memory within the library itself and not user code. A better solution would be to send this request to compiler vendors. Deferred. Affects Version/s: 4.2.0 4.2.1 Remaining Estimate: 4h Original Estimate: 4h Added 4.2 to the list of affected versions and set initial estimate. > make std::bad_alloc::what() more informative > -------------------------------------------- > > Key: STDCXX-209 > URL: https://issues.apache.org/jira/browse/STDCXX-209 > Project: C++ Standard Library > Issue Type: Improvement > Components: 18. Language Support > Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1 > Environment: all > Reporter: Martin Sebor > Fix For: 4.3 > > Original Estimate: 4h > Remaining Estimate: 4h > > Moved from the Rogue Wave bug tracking database: > {noformat} > ****Created By: hoaglin @ Sep 17, 2004 07:46:13 PM**** > **** Entered By: Web @ Thursday, September 09, 2004 8:01:23 AM **** > #web > Keith, > I'm not doing garbage collection and I'm not looking for any change in the memory management. All I want is that when the new operator throws an exception it sticks the # of bytes of memory requested in the exception handler what() message. Surely this information is readily available where the exception is being thrown and I don't see why this should cause any overhead so long as no exception is being thrown, > ****Modified By: sebor @ Apr 11, 2005 02:58:41 PM**** > This would be useful but std::bad_alloc is thrown by the operator new defined by the runtime library that comes with the compiler. We have little control over what string the what() member function returns. We could wrap calls made by our library in another function, catch the bad_alloc there, and rethrow another exception derived from std::bad_alloc, where we could override what() and format the string so as to include the information the user is asking for but that would only take care of exceptions thrown as a result of running out of memory within the library itself and not user code. A better solution would be to send this request to compiler vendors. > Deferred. > {noformat} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.