Uploaded image for project: 'C++ Standard Library'
  1. C++ Standard Library
  2. STDCXX-209

make std::bad_alloc::what() more informative

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1
    • Fix Version/s: 4.3.0
    • Component/s: 18. Language Support
    • Labels:
      None
    • Environment:

      all

    • Severity:
      Usability

      Description

      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.
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              sebor Martin Sebor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 4h
                4h
                Remaining:
                Remaining Estimate - 4h
                4h
                Logged:
                Time Spent - Not Specified
                Not Specified