thoth@springs.cis.ufl.edu (Gilligan) (02/06/90)
Just recently I posted about the addition of consts in appropriate parts of the library. There are a few places where they still seem to be missing, namely member functions. For those of you who might not have heard, a function declared const is saying that it does not modify its *this object. g++ has enforced this in every case I've noticed, not allowing me to call data member's member functions within the const function unless they were also declared const. (yes, that statement confused me too) I was declaring a function that would accept a class containing one of the generic classes (MPlex applied to one of my own) as a const reference parameter. I ran afoul of the fact that the <T>MPlex::operator() was not declared const. This is perfectly rational if you want to modify the reference it returns (and I do that frequently) but is most inconvenient if you only want to examine the data using the const members of the <T> class. I think it is possible to overload functions based on `const'ness. Is anyone looking into this for the Plex classes? Is there a simpler way? I could cast my object to non-const, but is this justified and aesthetically pleasing? Does <T>MPlex::operator() alone really modify the object? Should I start modifying the generic files until they seem to work, or should I typecast my data before passing it in, or should I do something completely different. ** Number two- when I `genclass String ref Vec' the resulting .cc won't compile unless I apply the following sed script. (Please give me a better sed script if you belive this is inefficient. I know little about sed and would like to learn the tricks of the trade.) /else/ N /else.*\n.*goto jump_over;/ d /jump_over:/d That rips out what seems to be an optimization goto in gsort. The compilation output is: springs:13 % g++ -g -v -c String.Vec.cc g++ version 1.36.3 (based on GCC 1.36.92) /local/lib/gnu/gcc-cpp -+ -v -undef -D__GNUC__ -D__GNUG__ -D__cplusplus -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__HAVE_68881__ -Dmc68020 String.Vec.cc /usr/tmp/cca01506.cpp GNU CPP version 1.36 /local/lib/gnu/gcc-cc1plus /usr/tmp/cca01506.cpp -quiet -dumpbase String.Vec.cc -g -version -o /usr/tmp/cca01506.s GNU C++ version 1.36.3 (based on GCC 1.36.92) (68k, MIT syntax) compiled by GNU C version 1.36. default target switches: -m68020 -mc68020 -m68881 -mbitfield String.Vec.cc: In function int gsort (class String *, int, auto int (*)(class String &,class String &)): String.Vec.cc:319: label `jump_over' used before containing binding contour String.Vec.cc:319: label `jump_over' used before containing binding contour I have no idea what this means or how to fix it. An int ref Vec, on the other hand, compiles fine (although why you would want to create a *reference* int Vec is beyond me). Thanks again, Rob. 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: 550 uunet!cs.utexas.edu!oswego.oswego.edu!dl@samsung... Host unknown -- ( My name's not really Gilligan, It's Robert Forsman, without an `e' )
dl@G.OSWEGO.EDU (Doug Lea) (02/06/90)
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