🚀 go-pugleaf

In article <56744@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>
>>Are you suggesting that it may be possible to generate more efficient
>>executable code if arbitrary field re-ordering (by the compiler) is allowed?
>
>Yes.
>
>>If so, are you prepared to give realistic (not contrived) examples of such
>improvements?
>
>Yes and no.  Clearly, I am not free to talk about MS future plans.
>Hopefully, even a few obvious examples should demonstrate the plausability...

OK. I'm willing to admit that it is just barely *plausable* that one of these
fine days I may wakeup and find out that everyone is taking their personal
fusion-powered helicopters to work, that the Jetsons are my next door
neighbors, and that some whiz-bang compiler will be smart enough to reorder
fields for me such that I end up with faster code.  (Note however that,
to the best of my knowledge anyway, no such compilers for *any* language
that provides "record types" now exists.  Still, that's besides the point.
If men can walk on the moon, who knows.)

>Agreed. That's why I suggested that one approach might be that "struct"
>means the same layout as C, as long as you don't derive.  Then all your
>C code continues to work.  One can think up reasons why one might want
>to use inheritence in matching machine registers, but that seems pushing it,
>to my mind.

Now that I've admited that future compilers should not be *unduly* constrained
by my own antiquated way of thinking about them, I'd like to say that it
still seems that user should have an (ANSI standard) way of getting layouts
exactly the way they want them (for all the reasons which have already been
mentioned) when necessary.  If the default is that the compiler has control
of the layout (rather than the programmer) I don't even mind that, so long
as the programmer can get control when necessary (via the proper syntactic
incantations).

I'm not keen on the idea that the use of the word "struct" (as opposed to
"class") should be taken as the indicator of the programmer's desires in
this regard.  Somebody suggested that nesting the class/struct declaration
within an `extern "C" {}' section might be a nice way to indicate that good
old fashioned programmer-controlled layout is being requested.  That sounds
reasonable to me.  Furthermore, it seems to be consistant with the
existing uses for `extern "C" {}' and it also allows for the possibility
of getting an entire set of related classes layed out the way you want/need
them.  Note howver that just using `extern "C"' as a prefix, as in:

	extern "C" struct s { unsigned i:7; unsigned j:9; };

will not work well because there could be some confusion in cases like:

	extern "C" struct s {...} foobar (int i);

In that case people might get confused about whether the `extern "C"' applied
only to the declared function or to both the function and the struct type
definition.

>Ron continues on, arguing strongly for the advantages on manually clustering
>over automatic clustering.  I disagree.  I think performance in other
>OOPLs and OODBs show that manual clustering doesn't work, because patterns
>of usage do not remain constant.  Thus clustering needs to be done 
>automatically, adapting to changing patterns of usage.

I was only arguing that "manual" clustering is simple to implement, simple
to understand, and that it is actually *needed* in some cases.  I stand
be these assertions, however I'm willing now to admidt that Jim A. (and
Microsoft) or some other compiler developer or vendor may be able to
conjure up some magic in the future which will give me faster code if
the compilers is allowed to take control of this "implementation detail"
in most cases.  I just don't want the control to be taken away from the
programmer irrevocably and in all cases.
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.