>>>>> "Jan" == Jan Harkes <[EMAIL PROTECTED]> 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."
