>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

    Jan> I did apply some patches I got for gcc 2.95, but haven't
    Jan> tested it myself yet. I also cleaned up the forking of new
    Jan> `vprocs'. If the new thread is a derived class, it calls an
    Jan> overloaded memberfunction and not the passed pointer. And
    Jan> even that turned out to be tricky. Overloaded member
    Jan> functions are not yet visible in the class constructors.

Oh, you got that to work?  I am not a C++ programmer (ie, I've skimmed
through the ARM 1st ed once but never hacked on, let alone write
myself, a serious C++ program).  What I did was to use a static
function taking pointer-to-vproc-object and call it from an init()
member.  I only got to the no-parameter types, though, I gave up on
the parametrized ones because I saw the `-fpermissive' kludge on the
list.  Of course this needs to be redone for every derived class, so
it's not a great idea.  What would be nice is if the root vproc class
could have such a static function that only initialized the LWP and
all of the other stuff was done in an overloaded init function.  But
that doesn't seem possible.

    Jan> The -fpermissive flag is detected by the autoconf script and
    Jan> added, I don't know if that helps.

That is probably bad until things get cleaned up ;-)  (No, of course
you want people building the distribution, leave it in.  -fpermissive
does not inhibit generation of warnings, of course.)

    >> How about the other two main issues (prototypes with
    >> missing/wrong return types and the "goto crosses object
    >> initialization" problem, in vproc.cc IIRC)?

    Jan> Prototypes are probably still wrong, the goto might have been
    Jan> fixed by the vproc initialization changes.

I doubt this.  I expect that all the compiler knows is that the goto
crosses the initialization of a class instance, and lexically it knows 
it must clean that up.  But it does not know under what conditions the 
initialization has or has not happened; it would need to generate an
implicit 

    if (/* complement of the union of the error conditions */)
    {
      ~the_offending_object;
    }

and that's hard for a human, let alone a compiler.

I did not understand what the code was doing, so I didn't actually try
it, but it occurred to me that you might be able to make that object
local to a block, and put the error return goto target outside of that
block.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."