[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