 |
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
 Posted: Mon Dec 04, 2006 6:45 am Post subject: |
 |
|
| Developer Silver wrote: | ...you can see which includes have 0 calls and are not necessary.  |
Perhaps, but I can also see this causing trouble when people don't realize that just because they aren't using a function/identifier in an include, does not mean the include is not needed, as I suspect you might not realize 
For instance, perhaps an include exists to aggregate other includes which are frequently - but not always - needed together, to avoid the need for excessive include statements in the source. Or perhaps such an include really does have functions in it, but it just so happens none of them are used. Remove that include based on the fact that none of it's functions/identifiers are used, and you may end up having trouble with includes that file itself defined.
While it could be argued that it would be better to simply include all of your individual files themselves (and I would argue that), I've seen all sorts of twisted and confusing stuff with includes, and it would surprise me NOT to see something like the above. The problem? Without needlessly complex issues like that, and with a generally good structure for how includes are used, such a feature really isn't all that important.
So, it's sort of like... the problem for which you think you want the feature may actually make it difficult to even use the feature in the first place. |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
| Posted: Mon Dec 04, 2006 6:02 pm Post subject: |
|
|
| Developer Silver wrote: | | @Marilla: using this feature in ecompile makes impossible to generate false positive, I think... |
This is what I was talking about:
| Code: |
include "inc1";
program DoIt(who)
CallInc2Function();
endprogram
|
inc1:
| Code: |
include "inc2";
....other stuff not used in the .src...
|
inc2:
| Code: |
function CallInc2Function()
...
endfunction
|
In your example, ecompile would report - correctly - that no functions are used from inc1. However, if you remove inc1 from the .src, you will break it. Obviously, no one would ever do what I've done in the above simple example. But also just as obviously, if you look through the actual includes I've often seen, the above effectively happens a whole lot.
========================
I think that a combination of what Tritan and SMJ have mentioned, coupled with re-organizing your include files, will solve the problem much better. I think people create includes very improperly, a lot of the time. For instance, with apologies to any former distro devs (and I don't know - maybe these includes are no longer in the distro?), I think that includes like 'myutil' and 'std' are just completely horrid. Well, beyond the fact that the large majority of functions in them can probably be killed completely due to features the core now has (especially the std.inc I used to have way back from 092! hehe), I also think that 'catch-all' includes like that make for very messy code.
Now, there may be times when you will have some 'master functions' that you just use ALL the time. But includes like myutil and std don't have functions like that in them, to be honest. They have a bunch of often completely unrelated functions that (if core support had not been added) can be useful from time to time in this or that thing.
The problem with includes like this is simple: Changing one function in them for some purpose will end up with you having lots of .src files recompiled needlessly (which is what I know your issue is here - and I agree that it's a good goal, to eliminate needless recompiles due to includes. I just think you are barking up the wrong tree to accomplish it)
So, maybe myutil has a function in it to, say, open the player's web browser. Fine. (though again, it's now a core function, but stay with me here). Then maybe it also has a function to... I dunno... do anything else at all. Think about this a second:
In what logical way is the "DoAnythingElseAtAll()" function related to the "OpenWebBrowser()" function? The answer is 'in no way'. The logical conclusion should then be, "These two functions do not belong, therefore, in the same include".
My solution was very, very simple: I created an include for the web browser function and it's helper functions alone. There were no other functions at all that were 'related' to them, so I put no other functions in that include.
So, if I ever change the web browser include file, I can rest assured that only .src files that actually use the web browser function will be recompiled.
I do this same thing for all includes: I only put functions/identifiers together in an include when those functions/identifiers are logically connected to each other. This means I end up 'splitting up' includes a lot - I have a lot of includes with only a couple functions, and those includes are named such that when I look at the include area of a .src file, it's obvious what includes are there, and why. I never need to ask myself, "does this .src use that include?"
And then something that has been mentioned related to includes elsewhere; includes including other includes; Some people think that's just plain bad, right from the start. I think it *can* be bad, and confusing, but I also think it's absolutely necessary to accomplish the type of organization I do.
For example, take my WebBrowser include. As you may know, that include needed some functions to convert characters into hex and such, to build the packet to send. But what if I also needed those functions elsewhere?
I would put those functions themselves in another include - again, only with related functions. Then, I would include that include from within the web browser include, and whatever other scripts/includes needed those functions would also include it.
What I would NEVER do: Create duplicate copies of those functions and put them in multiple source files. (That's when you start getting the lovely "Expected identifier, got user function instead" error). |
|
|
|
|
|
|
|
|
I'd rather my eCompile did not take the extra time, personally.