Quote:
Originally Posted by Ernst Blofeld
You also pointed it out in that post by calling it a "horror", so it was never hidden from anyone.
|
Yes but considering the point of view i'm supposed to defend here, you could have interpreted this as me just mocking the use of the names.
And yet nobody has spotted the mere fact it was just plain wrong and not working.
Because it was far from being as obvious as with the numbers.
Quote:
Originally Posted by Ernst Blofeld
B for bit, F for field? Easier than numbers.
|
Single letter often escapes the view. Confusion is so easy. But large number vs small number do not escape.
And don't tell me you will always remember that as clearly as it is now.
Quote:
Originally Posted by Thomas Richter
I afraid you do not understand what "modularization" means or is about. Let me explain again: It helps to split a big problem the program is supposed to solve into sub-problems. Each sub-problem gets a module, and a separate source file, plus a separate include file. You keep the interfaces between modules small, so you reduce the dependencies. Thus, if you work on a sub-problem, you do not need to change everything - provided you designed your interfaces well. "Well" as in "small" and "by hiding unnecessary information".
Everything a module needs to know about other modules is in the include files from the other modules.
Thus, if modulea.asm includes moduleb.i and modulec.i, you know what the depencies are.
With one big blob - you do not have that information. You need to search.
Also, the build phase profits from that. If you change moduleb.asm, without changing its interface, only moduleb needs to be rebuild, and nothing else. This is typically much less than the whole program.
If you change the interface, only modules including moduleb.i have to be rebuild, and that is also less than the full program.
|
This is all theory. Thorham has seen the actual code, you haven't.
But now let's imagine i suddenly decide to use names everywhere, as STRONGLY suggested.
What would the consequences be ?
First, if the includes are made directly in the include file, it will result in huge namespace pollution.
F.e. just include definitions for custom chip registers and see all your instances of "color" label fail miserably. Ouch.
To avoid this, i must use a linker and thus put all the code in a separate source - actually several, as also "suggested". And assemble that separately.
That means object code must in some way be available for all programs using the includes. Simple INCPATH in asm's config will no longer be enough.
So either a program is built with several commands, or it uses some script or makefile.
And then a very nice (ahem) absolute path has to be added to the build process or it won't find the lib.
Now if i just want to write some small test program for whatever purpose, new code setup requires creating several files instead of just one.
And it's the end of me being able to create new small program in less than a minute.
The code within the library itself is no longer as lean and mean as before, as linkers can't directly optimise code (contrary to if/endc in the source).
Provided this is even possible : the library does a lot of magic like routine changes depending on cpu type, automatic error handling and resource tracking.
It would require using complicated, unwieldy things such as ctors and dtors, that i suppose not every linker will support.
And all that for the sake of having names in a source file i don't even touch often. It's just plain crazy.