Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!G.OSWEGO.EDU!dl From: dl@G.OSWEGO.EDU (Doug Lea) Newsgroups: gnu.g++.lib.bug Subject: argh, member functions not declared const Message-ID: <9002061207.AA04181@g.oswego.edu> Date: 6 Feb 90 12:07:00 GMT References: Sender: daemon@tut.cis.ohio-state.edu Reply-To: dl@oswego.oswego.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 73 About consts in container classes: Yes, many of the classes have not yet been const-ified, mostly just out of time constraints. Sorry. Also, a bunch of things should ideally be rewritten, rather than patched, to support const for containers. But just patching them in would probably be serviceable. (As with any new C++ feature, an implementation written from scratch given the feature is almost always better than one with the feature patched in, but patching is a lot better than nothing!) If you or anyone else would like to volunteer to place member consts in the Plex and/or other pseudogeneric class files, this would be very helpful. I would happily review your changes and integrate them into a libg++ release. (Another snag about all this is that in gcc and g++, `const' as an ordinary function qualifier is supported to mean that the function is a `pure' function, i.e., that repeated applications of the function with the same arguments always return the same results, with no side effects. Specifying this kind of const allows the backend to perform some powerful optimizations that are not possible with the C++ const construct, since C++ const doesn't promise complete lack of side effects. Ideally, many functions should be revised/relabelled to support this as well, although there are two obstacles: The usage is not C++ 2.0 or ANSI C standard, and the backend does not (yet?) know how to handle gnu-const functions with pointer arguments, which includes all member functions, since `this' is implicitly an argument to member functions.) The Vec.ccP problem you mention appears to be a real g++ limitation: It seems to be complaining because temporary vars are created in the jumped-over part that g++ apparently doesn't see are killable before jump_over: so it thinks that the binding context is different. I'll revise this code a bit to work around this limitation, via: *** Vec.ccP~ Mon Aug 21 07:07:03 1989 --- Vec.ccP Tue Feb 6 06:19:56 1990 *************** *** 312,321 **** SWAP (mid, lo); if ((*cmp) (*hi, *mid) < 0) SWAP (mid, hi); ! else ! goto jump_over; ! if ((*cmp) (*mid, *lo) < 0) ! SWAP (mid, lo); ! jump_over: *pivot = *mid; pivot = &pivot_buffer; --- 312,320 ---- SWAP (mid, lo); if ((*cmp) (*hi, *mid) < 0) + { SWAP (mid, hi); ! if ((*cmp) (*mid, *lo) < 0) ! SWAP (mid, lo); ! } *pivot = *mid; pivot = &pivot_buffer; > Also, Doug, the Reply-To address in the mail you sent me didn't > work. UUCP or whatever-it-was has always been magic to me anyway: If you have uucp connects, you ought to be able to reply via some path like that below if you know how to get to rutgers or cornell. Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2367 email: dl@oswego.edu or dl%oswego.edu@nisc.nyser.net UUCP :...cornell!devvax!oswego!dl or ...rutgers!sunybcs!oswego!dl