Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!rex!uflorida!bikini!thoth From: thoth@springs.cis.ufl.edu (Gilligan) Newsgroups: gnu.g++.lib.bug Subject: argh, member functions not declared const Message-ID: Date: 5 Feb 90 20:20:24 GMT Sender: news@uflorida.cis.ufl.EDU Distribution: gnu Organization: /cis/lightning0/thoth/.organization Lines: 68 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 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 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 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' )