DoSuperMethodA without amiga.lib side posts
Mod note: problematic posts moved from http://eab.abime.net/showthread.php?t=104863
*********************************************************************** Look, do you think in 5 years from now, you remember what $18 was? For debugging, there is source level debugging, MonAm supports that. |
Quote:
And for source level debugging with MonAm i assume you need to assemble the code with GenAm otherwise it doesn't get the info it needs. And in turn this will fail because GenAm does not have half the features i need/use. |
Quote:
Quote:
Quote:
|
Quote:
If code requiring comments is bad, then all code in the world is bad. If you think some code is obvious and is not worth commenting, think twice. Chances are good you are making a mistake. A comment that is there but not very useful isn't a problem. A comment that's NOT here where there should be one is a lot more problematic. Quote:
Besides, the source could be anywhere, including in an editor that's not even running on the Amiga (i.e. opened in np++ while the code is in debug in winuae - in windowed mode i can see both together). Altering the source as mistakes are found make said source obsolete in regard to any source level debugging. Quote:
I need a debugger that can trace into a function that's in input.device context (like the hook of a class). For obvious reasons Devpac can't do this. And i'm not talking about OS killing programs... Note that even though it's not my case, many coders use winuae's built-in debug facilities, of course without any source level possibilities. Quote:
There is nothing wrong in using the numbers in asm programs, really. It has always worked fine and always will. It's a magnitude more lean and mean. And of course, when it comes to resourcing (= disassemble programs and reassemble them), knowing the (most common) numbers helps a lot. Consider this : as long as you use a good enough assembler, my code can readily assemble on any setup. No path in sources, no incdir mess, no special config required, no version conflicts, no need to have anything particular installed. Btw what is your motivation here ? Warning me is something, insisting is something else. |
Quote:
Comments are good. Programs requiring comments are bad. Code should be to a major degree "self-documenting", so something like Code:
move.l $18(a0),a0 ;cl_Super Code:
move.l cl_Super(a0),a0 There is an even better alternative. Instead of wasting your time with commenting things that could be self-documenting, write *why* your code does something: Code:
; ok, method XYZ is not specific to our class, forward it to the super class So, don't waste comments and typing to "obvious" things the assembler can do for you. Instead, comment motivation, structure and design, i.e. "higher level". In the same vain, Code:
addq.l #1,d0 ;increment d0 Code:
addq.l #1,d0 ;advance to the next index in the list These principles aren't new, aren't mine... Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
It seems, at the start, as if this is more work, but the invested time pays of very soon, you just have to start right from the beginning. Btw what is your motivation here ? Warning me is something, insisting is something else.[/QUOTE] |
Quote:
Quote:
Totally ridiculous. Perhaps i work in the field for as long or even longer than you do. My programs may be short and simple, but they do as much work as bigger programs do, and faster. Quote:
But some bozos think their code is self-documented enough, and then the reader does not understand a thing when reading it. How many times did i find whole sources without even a comment saying what the source itself is for ! Is THAT the way of coding you want ME to use ?? Quote:
Code:
move.l $18(a0),a0 ; access to parent class pointer (cl_Super) Quote:
Of course i document why the code does something. All interfaces are fully documented, all routines tell what they do, etc. Quote:
Quote:
This strategy is called the strawman fallacy. I have never written such bogus comments such as you show above. Quote:
Not that i'm using it myself, i wrote my own many years ago. Quote:
I started 68k asm with devpac2 many years ago and will NEVER return to that. And no, devpac3 isn't better. Quote:
Quote:
Quote:
Quote:
I didn't design my coding style just for this, it's one of the reasons - no more, no less. But even though rarely needed, in our case here it really is ! Quote:
Quote:
Besides, instead of criticizing my way of coding, you could be helpful again and tell me the best way to force the rendering to use coordinates relative to the gadget and not to the window ? The provided RastPort doesn't do that. Quote:
Quote:
Quote:
But resourcing, yes, it's just a different way to go into other people's code. Does maintaining someone else's program count as "development" for you ? If yes, resourcing is the same. Quote:
Quote:
(In many cases i had to use a linker, etc, for other reasons, and it has always been a PITA.) Quote:
I know and have tried both options. Can you say the same ? |
Quote:
Frankly, you have no clue. Quote:
Quote:
Quote:
Code:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
But changing this way of coding would invade the whole program. It's not "anti-style" at all. Just something you can't understand/accept. Quote:
Quote:
Quote:
Be realistic, please. Nice theories don't work in real life. Quote:
Even compilers turn peephole optimisation on. But maybe they're wrong all the way ? Quote:
Fact is my code works and is fast. Quote:
Quote:
Easy to maintain is another illusion. Quote:
The way you started was probably quite different to mine, so it can't be compared. If you attempted that on C code, that's understandable. OTOH, several times i've had some source code from other ppl using the way you so badly want me to use (why ?), and i clearly do not want to produce such horrors myself. |
Quote:
In old ages, "includes" on Amiga were a bit painful, if you only had a single disk drive and little memory. But that doesn't hold anymore, for at least the last 25 years. There is no excuse not using proper tools. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
In C the situation would be very different, as the compiler would check if the field is in the structure or not. Or if the value is in the enum. But in asm this doesn't work this way. Therefore using the name isn't worth its price (except if it's declared in my own source, for my own purpose). Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Should be very easy - something makes me think you're not doing a lot of asm anyway. You can charge me of paying too much attention to micro optimisation, which you regard as a small detail. But i can do the same for you for this whole story : the information is there, and its location (instruction or comment) is totally irrelevant. (It would be important in a strong typed language, but here we're doing asm.) Quote:
Quote:
Quote:
Again it's not "anti-style". In the same way it is better to do : jsr -$228(a6) ; OpenLibrary than : jsr LVOOpenLibrary(a6) And this, because it is more readable. Comments in asm are aligned to the right of instructions. And the eye is there when it looks for infos. Another benefit of using the numbers is that you end up knowing the most common ones. And this is invaluable when debugging code you don't have the sources for. On the Amiga i am able to enter any program and do alterations in it. This counts a lot against the small detail of using the name in the instruction or in the comment. Quote:
There are things you regard as good practices and things you regard as bad practices. But you seem to be overgeneralizing this. Me, i am more pragmatic. When something is the right tool for the current job, i use it. This is what differentiates good programmers from average or bad ones. Quote:
Anyway, 6502 and 68k are different beasts. Quote:
You just don't know how to code and you want to teach lessons to me ? Beat it. You think you know better ? Explain. Why would it be so bad ? The number does not change. So the code will work in the future if it works now. (And it is what will figure in the executable anyway.) The name does not give any info the comment does not give. Someone else reading the code will have all that is relevant. (Actually, the number gives an information the name doesn't, it is the magnitude of the number.) We are not dependent on external includes, which can not have bad consequences. (Actually the opposite, for the reasons i stated.) Frankly, i've just put a number instead of a name and this is gonna have a catastrophic impact ? This is totally irrealistic. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Drop the comment. Put the name right into the call. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
With this kind of point of view, there would never have any innovation. Quote:
And - but perhaps you didn't get it - it's only about OS includes. My own structure fields have names. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
You failed to prove using OS includes improves things in any manner. Quote:
Quote:
Quote:
Frankly, why do you insist so much ? You have absolutely no idea of how my code is overall, you've only seen a single isolated line ! All my OS code is in a single include (MY include, not OS one). And it gets included over and over. Programs using it should not depend on anything but this file, which in turn does not depend on anything at all. This is what is called modularity. Should someone rewrite all the features inside for another OS, all my code would then run on that OS. Often the users of cpp classes on windows depend on windows.h or whatever os includes and this pisses me off. Implementation details should not appear in interfaces. My code is in some way platform independent. Can you say the same about your code ? |
Quote:
Quote:
That's what I call "stubborness". Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
The reason for modularity is to isolate information between modules, thus to decrease the dependencies. If you just put everything into one file, you could also put all sources into one file. Same shit. Quote:
Quote:
Instead, you hide the <windows.h> away, in particular includes, or possibly even in implementation files. In my projects, there is no "global depencency" on windows.h. Quote:
Quote:
Quote:
|
Quote:
Quote:
And as i told you several times, i actually tried the os includes. It ended up in such a mess i will nevermore do that. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
And again, IT IS ONLY FOR OS INCLUDES. So it has nothing "very fundamental" and isn't an error at all. Quote:
Initially some modules were in separate files and it didn't work very well. And of course end user of the library shouldn't have to care in which module some function is located. Frankly, as an example should i separate simple console print from file open in different modules ? Quote:
Quote:
Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler. Quote:
Quote:
AGAIN: It's just OS includes i don't use. My own structure members have names. Quote:
Quote:
Quote:
Quote:
So let me retry : can you say the same about your asm code ? |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
You want a big proof sent to your face, really ? Quote:
Every coder reasonably advanced knows what $dff180 or $dff09a are. Frankly, do you really want me to include hardware/custom.i and hardware/intbits.i and write this horror instead : move.w #INTB_INTEN,intena Quote:
Believe me, my coding style is quite different now than it was many years ago. Quote:
Quote:
Quote:
Quote:
Quote:
Added together we have something like 60-70 years of experience. Really, find someone who has more. Quote:
Quote:
Quote:
Then, it's just a matter of copy-paste. It's not as if there were OS tag values scattered all over the place in my programs. Now consider static initialization of a gadget structure with DC directives. There you can't use your beloved names anymore, you have to know the structure layout - i.e. the numbers. Quote:
Quote:
Quote:
Quote:
Quote:
Anyway, why should i prove anything ? After all, if you advocate a change, it's yours to provide the proof (else it is reversing the charge of the proof). So please speak about in which ways (with concrete and detailed examples) your experience with numbers got wrong. That would be more useful. Quote:
I don't need to include anything else. Always same name. OTOH, OS includes are many files scattered in many dirs. When using a function i like having it readily available and there they aren't. Quote:
Quote:
If not, you can not know why it can't work nicely. Quote:
Quote:
It could have been : should i separate video (frame buffer) handing from GUI parts ? Quote:
Quote:
All that to say that "short enough" is actually the most common case, and i always optimise for the most common case. Treating all programs as it they were very big is a bad idea, really. Back in '98 or so i had to split a big program and use a linker because the A1200's 2mb weren't enough to assemble it. Then i got 030 with 16mb. Then i could merge it again. Phew. But i am able to do that again if needed. It is not a problem. However it is rarely needed, if ever, nowadays. Quote:
These modules will be different if you consider porting the code to another architecture. Same code could run on Atari ST or Mac OS 68k, maybe even Megadrive, with no change at all - only the includes would be different. And by converting the asm code in some automatic way (with a small vm), then it could potentially work on *any* architecture. Quote:
Quote:
In some way, OS structures definitions are "const" where mine aren't. Call it an inconsistency if you like. If using the right tool for the job is being inconsistent. Quote:
And they won't work for function parameters - you still have to abstract handles to void* and lose type checking in the process. Quote:
Quote:
I don't change the OS encapsulation code all the time. Programs using it do not need to be reassembled if new features get added in it. Quote:
Header files are for interfaces, not for structure. Quote:
So even if i admitted it was a messy way of doing, it would only affect a single source, actually, not the whole programs. But you here clearly assume it does. Quote:
The only trick is to group everything OS/hardware specific to a small part that will be rewritten for each. Besides, with a relatively simple cpu translation layer it would also work on x64, aarch64, or whatever. |
While I prefer OS includes too, I absolutely fail to see how this
Code:
move.l cl_Super(a0),a0 ;do whatever Code:
move.l $18(a0),a0 ;do whatever (cl_Super) |
Quote:
Yes, of course there is a difference. The first one is guaranteed to be correct. The second one could be the suorce of a subtile error. Do you actually know whether $18 is the right offset? If so, how? And if not, how would you find out without debugging? |
Quote:
|
Thomas,
Meynaf is wrong. He know's he's wrong. He's just arguing with you for entertainment. While there's nothing wrong with that, you could both choose something more worthwhile to argue about. Regards, The rest of the internet. |
All times are GMT +2. The time now is 20:09. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.