U++ forum: Welcome to the forum

Re: Very first impressions and.... [FEATURE REQUESTS] [message #11775 is a reply to message #11767]

Tue, 25 September 2007 16:42

mdelfede
Messages: 1307
Registered: September 2007

Ultimate Contributor

luzr wrote on Tue, 25 September 2007 14:22

Actually, maybe my working theory is wrong, but I think you do not have to rescan headers in this case, as long as the change in header does not change the macros...

I don't think you're wrong, I only think all that is VERY complicated ! Razz

Quote:

Therefore this comes to quite simple scheme - each header has set of "input macros" as part of caching keys and produces a set of "output macros". As long as caching key matches, you can just take output macros of header instead of parsing it when you see #include.

Or that is the plan Smile

If you see any flaw, do not stay silent, you would save my time following a wrong approach... Smile

No flaws at all, it seems all ok, but really complicated to code... If I did understand, you do that :
1 - On first scan, completely scan all headers
2 - Starting from first one (no input macros), you get 'output macros' from it and get some sort of hash or magic code from those macros.
3 - You repeat all that for following headers, storing the 'magic' on input and tha cached macros.
4 - On next scans, if first header is changed you rescan it and get again the 'magic code'
5 - if 'magic code' didn't change even if the header changed, you don't need to rescan following headers.

The only (small) flaw I see is that you change a macro on first header you must indeed rescan all following headers, but that's rare.

Quote:

(Well, the one possible flaw is that of course, some program constructs can start in one header and end in another. I decided simply to ignore this possibility for now...)

well, if a programmer does such a construct, he deserves the bad behaviour of parser.... I'd call it "just force things to make them buggy" Razz

What I don't see are 'big' advantages against a simpler (much simpler) background processing. Ok, you're real time each key you press, but your code will become very complicated and, in the (rare) possibility that user change a simple macro on first header, he will notice a long delay on editor.
OTOH, your way is of course more 'technical' and 'funny' to code...

Ciao

Max

p.s. do you think also to make some sort of word completion (besides member function/variables) ? Something like "type-2-chars-press-a-key-and-get-a-list-of-words" ? That would be useful too...

Report message to a moderator