🚀 go-pugleaf

  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' )