[Shootout-list] Re: Shootout-list digest, Vol 1 #208 - 14 msgs

Brent Fulgham bfulg@pacbell.net
Fri, 18 Mar 2005 10:41:43 -0800 (PST)


--- Dave <davejf@frontiernet.net> wrote:

> Just to clarify what my understanding of the
> proposal is:
> a) a 'ban' of external libraries only (as opposed to
> runtime libs. that are included with a base 
> implementation using default link switchology),

Yes -- that's my tentative proposal.

> and b) you're also speaking of including only the
> primary tests (not 'interesting alternatives') in
> the "default CRAPS rating", so the results at 
> a glance reflect the more 'pure' implementations.

Yes.  However, we can discuss this further if people
have opposing views.
 
> 'Ban' inline assembler in any of the actual
> implementation code (not, of 
> course, in the runtime libs.), in case anyone gets
> any ideas <g>

This falls under the overall idea of banning
implementations that exit the host language for
part of the processing.  (So, inline asm is bad,
but so is inline 'C' in a Perl program, etc.)
 
> And - much less importantly - include in the LOC
> count things like non-library headers that are
> really part of the implementation code in 
> disguise :) For example, C/simple_hash.h.

This gets tricky.  For a silly metric like LOC, you
would be surprised how many e-mails I get from
people complaining that it's not fair for one reason
or another.

If I start included #include stuff in the loc count,
I probably have to present the HTML-ized version with
all of the included source (or someone will say
"hey, it's only 15 lines and you claim it's 1200
lines!).

> This could be interesting even wrt. to some of the
> g++ vs. Intel C++ implementations (i.e.: by these 
> rules, someone would have to roll their own 
> hash class, or use std::map or whatever).

I'm not sure I follow this point.  Why would they
have to roll their own hash class?  This would fall
under category (b), wouldn't it?

-Brent