libstdc++/9073: Can __STL_ASSERTIONS come back, but with more than rope?

libstdc++/9073: Can __STL_ASSERTIONS come back, but with more than rope?

[Matthias Klose]

>Number:         9073
>Category:       libstdc++
>Synopsis:       Can __STL_ASSERTIONS come back, but with more than rope?
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 27 15:36:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Anthony DeRobertis <asd@suespammers.org>
>Release:        3.0.4 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
host: i386-linux
>Description:
[ Reported to the Debian BTS as report #128993.
  Please CC 128993@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/128993 ]
	

It'd be nice to have __STL_ASSERTIONS or equivelant come back to do
things like bounds-check vector accesses (yes, I know about at()) for
debugging purposes.
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: libstdc++/9073: Can __STL_ASSERTIONS come back, but with more than rope?

[neroden]

Synopsis: Can __STL_ASSERTIONS come back, but with more than rope?

State-Changed-From-To: feedback->suspended
State-Changed-By: neroden
State-Changed-When: Thu Apr 10 18:03:00 2003
State-Changed-Why:
    Unlikely to be implemented any time soon.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9073

Re: libstdc++/9073: Can __STL_ASSERTIONS come back, but with more than rope?

[bkoz]

Synopsis: Can __STL_ASSERTIONS come back, but with more than rope?

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Thu Jan  2 15:07:37 2003
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Thu Jan  2 15:07:37 2003
State-Changed-Why:
    __STL_ASSERTIONS making a comeback is extremely unlikely. A better way to do this would be to just encapsulate std::vector and add your own runtime checks. I believe that Cay Horstman has done this with older versions of std::vector: you might check google.
    
    -benjamin

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9073