> // ParseManual: int yylex(void)
  [...]
       // InlineParse: ON
       int yylex(void) {
       // InlineParse: OFF
       ...

I've been using
  Inline(Parse|Code)(Start|Stop)
  InlineDont(Parse|Code)

The first four control multi-line processing.
The last two control single lines.

Any excised text is replaced by shaped whitespace to preserve line and
character positions (ie, $txt =~ s/[^\n]/ /g;).

Inline(Parse|Code)(Start|Stop) wipe out their entire line.
So commenting "/* InlineParseStop */" works for when you want it.

One can be implicit (beginning-of-code ... start ...),
or explicit    (beginning-of-code stop ... start ...).
The code selection and parse selection are independent.


class illustration {
 InlineParseStop
  void dont_export_me_to_perl () {}
  void inline_doesnt_understand(templates<int> var) {}
 InlineParseStart
  int normal () { return 42; }
  InlineDontParse Frob* get_Frob (); // C++ code given Frob pointers, 
  InlineDontCode  void* get_Frob (); // which I dont want to explain to Inline.
}


   2 lines instead of one, remembering to set something on then off (just for

If one wants one liners, one might use InlineDoParse.
I dropped the InlineDo's at some point, as I was rarely/never using them.

Mitchell Charity


   Date: Tue, 22 Oct 2002 17:54:57 -0700
   To: nadim <nadim[at]khemir.net>
   Cc: Inline Mailing List <inline[at]perl.org>
   Subject: Re: Some Inline Benchmarks
   Message-ID: <[EMAIL PROTECTED]>
   References: <[EMAIL PROTECTED]>
    <[EMAIL PROTECTED]>
   From: ingy[at]ttul.org (Brian Ingerson)


   On 23/10/02 01:05 +0200, nadim wrote:
   > On Saturday 12 October 2002 01:07, Brian Ingerson wrote:
   > > At least on my machine, the parsing isn't the real culprit. I'm eager to
   > > see Nadim's results. ;)
   > 
   > Hi all, I finally got tired of this parsing non sense. Why should I parse 
   > hundreds of KB of code to find the one function I know will be there since 
   > I put it there in the first place.
   > 
   > ParseRecDescent and ParseRegExp are fine as long as the code is unknown or 
   > not too difficult to parse (ParseRegExp fails on flex generated code (you 
   > can't blame it for that ;-))
   > 
   > With ParseManual you must declare the function you want to be exposed, in 
   > my case (works with whatever comment type you have);
   > %{
   > // ParseManual: int yylex(void)
   > %}

   Cool.

   I have been thinking of something a little more flexible:

       // InlineParse: ON
       int yylex(void) {
       // InlineParse: OFF
       ...

   I think having a standard way of telling Inline what to parse, and what not
   to is a fine idea. I'd be glad to start discussing this in the next release.

   In the mean time, I think your hack is a great way to do it.

   Cheers, Brian

Reply via email to