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

[Dave]

----- Original Message ----- 
From: "Brent Fulgham" <bfulg@pacbell.net>
To: "Dave" <davejf@frontiernet.net>; <shootout-list@lists.alioth.debian.org>
Sent: Friday, March 18, 2005 12:41 PM
Subject: Re: [Shootout-list] Re: Shootout-list digest, Vol 1 #208 - 14 msgs


>
> --- Dave <davejf@frontiernet.net> wrote:
>
<snipped for brevity>
>
>> '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.)
>

What I was concerned with is that some languages may provide an inline
assembler interface as a non-implementation specific and spec'ed part of the
language. For example, the D language does. The inline assembler spec. for D
is suppose to facilitate consistent and 'portable' assembly across software
platforms and D compilers [for a given CPU, obviously]. In other words,
inline assembler is officially part of the D language so there may be a grey
line on 'exiting the host language' in that case. That's where that came
from.

>
>> 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.

Agreed.

>
> 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?
>

You're right - those are implemented in the same language so wouldn't be an
issue. I missed that point in the original post.

- Dave

> -Brent