"Chris Miller" <chris@dprogramming.com> wrote in message news:op.s1ed6eu6po9bzi@esi...
> On Wed, 07 Dec 2005 00:01:51 -0500, James Dunne <james.jdunne@gmail.com> wrote:
> >>   To parse it, look at std/cover.d. It has a parser for it <g>.
> > As I keep telling others... I really should produce brain-waves before sound-waves.  (Proverbial sound waves in this case, I guess)
> >
> > Also it's not that hard to parse... just find the first | on the line... it could also be as simple as fixed record sizes and an atoi call.
>
> If the number is large it'll push the | over more columns.

Yup. Just scan for the |.

> One thing strange about the .lst file is 0 is the only number padded with 0s. Kind of makes it harder to skim the file looking for bigger numbers, I'll get thrown off seeing a number with many digits yet is 0.

It makes it easy to do a grep for untested lines of code. It'll also correctly parse as the number 0, so no special case code is necessary.

Jarrett Billingsley wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dn0kr7$2rk4$1@digitaldaemon.com...
> 
>>Sounds very cool!  Any kind of code analyzation tools are welcome,
> 
> 
> Heh, I just realized I typed "analyzation."  Where the heck did that come from?
> 
> _analysis_. 
> 
> 
Is "analyzation" not proper english? It shows up here (Websters): http://www.answers.com/analyzation

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

>>> #define REGISTER_AS_REMOTE_PROCEDURE_CALL(Object, functionName)
>>> (Object)->Register((#functionName),(functionName))
>> 
>> If I can't get the symbol name converted to a string at compile
>> time... all is lost and D is still limited.
>> 
>> Oh well... I must be getting spoiled with these new features.  It
>> makes me want more! :-P
> 
> Hey, don't feel bad.  You're just following society's motto: "Gimme,
> gimme, gimme, gimme!" :-)
> 
> Thanks Walter.  This is another great release.  Woowoowoowoooo!


The motto is (C) ABBA of sweden!

Goes like "Gimme gimme gimme, a man at the midnight...."

(And with this single song, they've made more money than the entire D newsgroup combined will, in their entire lifetime. It's so wrong!)

BCS wrote:
> The essence of the problem is that DMD can't tell the argument list of a
> function from just the name.
> 
> example:
> 
> int fn(int);
> int fn(char);
> void fn(void);
> 
> // what type is fn?
> 
> auto fnp = &fn;
> 
> // what type is fnp and what does it point to

(Admittedly, not knowing crap, (since I've been doing Honest Work lately)) I'd assume that this problem would go away about the same time we get implicit template instatiation.

Yeayeayea, they're not related, but getting one of these to work, would at least give a clue to get the other one fixed, too.

Ahhh, IMHO. (Almost forgot!)

No, the point is that the without context there is no way to tell with fn is intended. The solution (for us) is to cast it as one or the other. For D the solution is to make any such ambiguity an error and require that the compiler check to see if any other symbol could also be used and if so throw an error.


In article <439B5685.7030408@nospam.org>, Georg Wrede says...
>
>BCS wrote:
>> The essence of the problem is that DMD can't tell the argument list of a function from just the name.
>> 
>> example:
>> 
>> int fn(int);
>> int fn(char);
>> void fn(void);
>> 
>> // what type is fn?
>> 
>> auto fnp = &fn;
>> 
>> // what type is fnp and what does it point to
>
>(Admittedly, not knowing crap, (since I've been doing Honest Work lately)) I'd assume that this problem would go away about the same time we get implicit template instatiation.
>
>Yeayeayea, they're not related, but getting one of these to work, would at least give a clue to get the other one fixed, too.
>
>Ahhh, IMHO. (Almost forgot!)

BCS wrote:
> No, the point is that the without context there is no way to tell with fn is
> intended. The solution (for us) is to cast it as one or the other. For D the
> solution is to make any such ambiguity an error and require that the compiler
> check to see if any other symbol could also be used and if so throw an error.

In other words, we have to do this sort of thing:
#
# int fn(int);
# int fn(char);
#
# int function(int) fnpi = &fn; // skip use of auto entirely
# auto fnpc = cast(int function(char)) &fn; // use cast, which actually makes it worse
#

Maybe what we need is a syntax like:
# auto fnp = &fn(int);

Where any expression that parses as an address operator followed by a function call where all parameters are typeid's, is an explicit address-of-function expression.  Its not perfectly context free grammar, but should be an easy case to check, since presumably if even the first parameter is a typeid, they would all have to be.  (I don't know of any case where passing types to functions is currently valid syntax.)

This would be nifty in templates:
# template foo (alias T_X) {
#   void foo (...) {
#     auto fnp = &fn(T_X);
#     /* blah blah */
#     somethingElse(fnp, ...);
#   }
# }

-- Chris Sauls