[Thomas Richter]

Originally Posted by meynaf

6502 is mostly very low level code. No OS includes.

Have you actually read the book? There, symbolic names are not used for Os includes, but for hardware addresses, which also makes a lot of sense.

Originally Posted by meynaf

Argumentum ad populum don't work either.

Oh, and you think you are the only one doing it right, and everybody else does it wrong, and you haven't tried to change your style, just as learning experience?


That's what I call "stubborness".

Originally Posted by meynaf

The fun part here is "generate various targets". Again you forget we're talking about amiga asm. And for the rest we have great IDEs today that can hide all these obscure and unwieldy makefiles.

I'm not sure why you want to hide them. Instead "work with them".

Originally Posted by meynaf

Sorry, i supposed you knew that comments don't end up in the executable file...

Symbolic names neither. Yet, they are in the source, and unlike comments, they have function.

Originally Posted by meynaf

Wasn't it you who one day told me to just use a compiler ?

That works even better, yes. At least in most cases. In the remaining cases, you need an assembler, but even that tool need to be used properly.

Originally Posted by meynaf

Wake up, there are not "many others" doing 68k or 6502 asm today.

It does not matter whether that is 6502, 68k, i386, x64 or arm. Don't tell me that these are "different languages". There is a common principle why you use telling names and not numbers.

Originally Posted by meynaf

On the contrary, it's very useful when debugging.

It's the job of the debugger to show symbolic names. It's not hard to do that with library offsets, every debugger I know does that. It's not hard to find and run a source level debugger either.

Originally Posted by meynaf

They can't always do that, and they can't do it for structure fields because they have no way to know. For consistency i use same method for both.

FOr consistency, you use the least readable version?

Originally Posted by meynaf

Again, argumentum ad populum.
With this kind of point of view, there would never have any innovation.

Actually, the innvation was to *have* symbolic names. With your approach, people would still use punch cards. The innovation is "let the computer do the job".

Originally Posted by meynaf

As i told - but you didn't read - i already tried.
And - but perhaps you didn't get it - it's only about OS includes. My own structure fields have names.

So what's so bad about Os includes and what's so great about your includes? Where is your "consistency"? Where is the "Oh, I remember in 5 years what the $18 in my code was good for?".

Originally Posted by meynaf

Apart that it is not in any way harder to read.
You failed to prove using OS includes improves things in any manner.

Yes, they do. They make sources readable and self-documenting. Not that I'm saying that for the first time.

Originally Posted by meynaf

Yes if they change, you indeed reassemble the program - and discover that all of a sudden it stops working because of some incompatible change.

It's actually quite the reverse. If I use symbolic names, the program remains working even after a change. Otherwise, I have to search for numbers, and as I don't know what the number was good for...

Originally Posted by meynaf

If the number is wrong, the program will simply not work and it is very easy to fix. Using the wrong number is the same as using the wrong name.

So, apparently, not very complex programs. Most bugs I fix are not easy to detect.

Originally Posted by meynaf

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 !

Because you are making a very fundamental error here. Yes, I know script kiddies start to write code like this, even more so on a computer system which had only a single disk drive, and 512K in 1988. But those times are long over, and it is time to adapt. It's not me who resists a change - it is you. Just try it once, and observe how the programs get better. It is a well went advice from a transition I myself went through, and I only knew afterwards what exactly I was doing wrong.

Originally Posted by meynaf

All my OS code is in a single include (MY include, not OS one). And it gets included over and over.

That looks like a sign of missing modularization. It's better to write smaller units, each with its own include file, defining only the parts that are relevant for this particular module.

Originally Posted by meynaf

Programs using it should not depend on anything but this file, which in turn does not depend on anything at all.

Dependency resolution is the matter of automatic tools. Makefiles implement them. Tools can create them.

Originally Posted by meynaf

This is what is called modularity.

No, it is the absence of modularity - exactly the opposite. You have now one big dependency, and rebuild everything just if one single detail change. It works the other way around: One include per module, so you only have to rebuild what depends on this module.


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.

Originally Posted by meynaf

Should someone rewrite all the features inside for another OS, all my code would then run on that OS.

Hardly, because none of the offsets would be correct, and there is no abstraction.

Originally Posted by meynaf

Often the users of cpp classes on windows depend on windows.h or whatever os includes and this pisses me off.

In C++, you use "compiler firewalls" for that, hide implementations behind interfaces by a very simple idiom called "pimples". In fact, if you just have a single include file, you would not get around to have a <windows.h> included there, and thus all dependencies dragged into all modules, which is exactly wrong.


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.

Originally Posted by meynaf

Implementation details should not appear in interfaces.

And that is exactly why you separate out different interfaces into different files. windows.h is as much an interface as the modules of your source. Unless you have none, of course, which is lousy structure.

Originally Posted by meynaf

My code is in some way platform independent.

Exactly not, with numbers in it instead of names.

Originally Posted by meynaf

Can you say the same about your code ?

Yes, of course I can say that. Why don't you go to my github page for some of the *public* projects. That is of course not assembly, but C++, but compiles on a varity of platforms due to autoconf. It also builds on windows, of course.