Re: Scheran & .hxx formatting

[Michael McClary <michael>]

> From: autodesk!unreal!robertj (Young Rob Jellinghaus)
> 
> The single file with which I'm having far and away the most trouble is xcvrx.
> hxx, which needs to be included since some FeBe classes send and return
> Xcvrs.  The formatting of xcvrx.hxx is much messier than any of the others, and
> how's this for a healthy function declaration?
> 
>        virtual SPTR(Heaper)    make(
>                   Xcvr *
>                 , Entry *
>         );
> 
> That one broke the whitespace-tolerance code I added last week to deal with
> the strange declaration layout.

Then it found a bug in your whitespace-tolerance code.  The language spec
didn't limit the amount of whitespace allowed, last I looked.

You'll find a lot of

	function(
		  argType	argName
		, argType	argName
		, argType	argName
		, argType	argName
		, argType	argName
		, argType	argName
		, argType	argName
	)...

-ish declarations in places I've been.

> Anyway, there are only a few lingering problems.  The Recipe class doesn't seem
> to like SPTR at all; SPTR(Recipe) or SPTR(HeaperRecipe) give compile errors.
> Not hard to work around.  

That's because Recipes are not part of the garbage-collection regime, and
thus you can not have SPTRs, CKPTRs, or WPTRs to them.  Use a Recipe *.
The same thing happens with Category.

(There's currently a design issue outstanding:  Should we allow WPTRs to
 non-GCish types?)

> What is the difference between CAST(SomeType, xm->fetch(p_ElkObject)) and
> (SomeType*) (Heaper *) xm->fetch(p_ElkObject)?

It casts it up to "Heaper *", then down to "SomeType *".  I believe that was
necessary at one point because a ?PTR(SomeOtherType) was being returned, and
cfront wasn't able to figure out that it could extract a "SomeOtherType *"
from it.

	michael