[Thomas Richter]

Originally Posted by meynaf

Then it is irrelevant. I'm speaking about OS includes, not hardware addresses.

Ah, where is your "consistency of unreadability"? Why does it make a difference whether a symbolic name is part of a hardware address, or part of a software structure?

Originally Posted by meynaf

Do it the way you want, the others do it the way they want, it's not my problem. Everyone is free, and hopefully.

That wasn't quite the point, was it? The point is: "Why don't you work on your style and use chances to improve it?". Nobody is perfect, and you learn something new every day.

Originally Posted by meynaf

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.

As in "which mess"?

Originally Posted by meynaf

Try coding with a decent IDE, just as "learning experience".

I'm also using VisualStudio at work, or GoldEd on Amiga... whatever works for the job. However, as soon as the project becomes more complex, a tool to resolve dependencies is needed. IDEs are not as flexible as makefiles. Or cmake, or whatever tool you use for that.

Originally Posted by meynaf

They have function, but a function that can be abused like everything else. As i said, use the right tool for the task. It's not always the right tool.

How a "symbolic name" can be abused is beyond me. And why a symbolic name to a hardware register is something different than a symbolic name for a structure component either.

Originally Posted by meynaf

There is a contradiction here : if that works even better, why did you tell you were doing a lot of asm ?

Whatever does the job, as always. Low level "driver code" or speed critical code is in assembly. High level control functions that are not critical are in C or any other high level language.

Originally Posted by meynaf

According to what you've just written here, you should be doing mostly some compiled stuff, and asm for the few remaining cases.

Yes, that is how it looks today, indeed. Not back then, but this was also a learning experience. It does not pay off to do everything in assembler.

Originally Posted by meynaf

Still not "many others" doing it...

Still enough people with more experience than those of you and me combined.

Originally Posted by meynaf

Library offsets are only a small part of it. And debuggers are not immune to getting them wrong.

That would surprise me - namely how to get them wrong.

Originally Posted by meynaf

Of course, as i already stated, they sometimes just can't do the job. What do you prefer : a solution that always work or one that sometimes fail ?

Why don't symbolic names always work? They do always work. Numbers fail - because they are easy to get wrong, and it is much harder to find out what exactly is wrong if you got it wrong. So what's a jsr -$c6(a6)? You don't know, unless you know what a6 is.

Originally Posted by meynaf

Invalid argument (petitio principii). I have not in any manner agreed that it's harder to read.

Names are telling. Numbers are not. OpenWindowTagList(a6) tells you what is supposed to happen. The TagID "LeftEdge" tells you wha the tag does. The numbers... mean that you have to go searching. Probably not even searching, but computing what the right number is, as the includes do not provide simple equates for them. Do you have all tags in your mind? All Os equates? That's outright silly.

Originally Posted by meynaf

Invalid argument (straw man fallacy). I never told all kinds of symbolic names were useless.

So where's the difference between cl_Super(a0) and ciaapra(a0)?

Originally Posted by meynaf

Remember : if the $18 isn't super obvious then there is a comment next to it.

And where is the difference just putting the symbol right there without the comment?

Originally Posted by meynaf

It can't be the reverse. If a change has to alter the number, then this breaks binary level compatibility. Same number produces same executable and it *has* to work. Same name but different number is however not guaranteed to work.

I beg your pardon? The equates are there to help the programmer, to generate code that is readable and self-documenting. Use the offer. Or just try once and share your experience.

Originally Posted by meynaf

Of course i don't write very complex programs. I keep things simple so that it is easier to debug and maintain, on the contrary to many people doing overcomplicated, bloated, and hard to debug code.

Well, then as I assumed, you lack quite some experience with larger projects. That explains the problem.

Originally Posted by meynaf

I have tried it, and observed how the programs got worse.

In which way?

Originally Posted by meynaf

And again, IT IS ONLY FOR OS INCLUDES.

So what makes Os includes special compared to your includes? What makes hardware structure different to software structure?

Originally Posted by meynaf

Nope. There are dependencies, like different routines using same library or device or whatever, functions calling other api functions for internal purposes, etc.
Initially some modules were in separate files and it didn't work very well.

In which way didn't it work? Maybe you got the concepts wrong? It works nicely here.

Originally Posted by meynaf

And of course end user of the library shouldn't have to care in which module some function is located.

If you develop a library, you would typically have multple includes for them, of course, depending on which feature of the library is used. Just to name some, there is <exec/memory.h>, <exec/ports.h>, <exec/nodes.h>.... all is nicely separated out, so you don't need to include everything. That's modularization.

Originally Posted by meynaf

Frankly, as an example should i separate simple console print from file open in different modules ?

I'm not sure what you are saying. You are talking about a trivial "hello world?" There is no module there, but I'm not talking about such type of toy programs. I'm talking about "real stuff".

Originally Posted by meynaf

And where's the problem in rebuilding everything ? You wrote yourself that building times were pretty much unimportant.

That depends on the size of the program, of course.

Originally Posted by meynaf

Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler.

If the program is "short enough", this might work for you. If it is "long enough", it does not.

Originally Posted by meynaf

And my OS abstraction layer is a single module for me. There is absolutely no problem in that !

There are many problems with that. The Os is not a single layer - there are multiple modules that are build on top of each other, i.e. there is a structure behind this.

Originally Posted by meynaf

What offsets ? There are no offsets visible to the end user.

Then, why dou you write comments? The end user doesn't see comments either?

Originally Posted by meynaf

AGAIN: It's just OS includes i don't use. My own structure members have names.

So what's the difference between your structures and the Os structures? You are not consistent then?

Originally Posted by meynaf

And thus you multiply the complexity (twice as many classes) for little benefit (and a small cost in performance).

Pimples reduce complexity as "compiler firewall".

Originally Posted by meynaf

No it is the exact opposite. With single include you do not need to care where a function is located - you have it readily available. This is a real time gain when developing.

And you polute the name space, and need to rebuild everything once you change something. Apparently, you seem to believe includes only deliver function names - typically, they deliver very little function names in my case. They deliver a lot of the structure.

Originally Posted by meynaf

Did i tell you it was only for OS code that i use numbers and there is no OS code in the program itself because it is hidden away in the include ?

And again, why is there a difference?

Originally Posted by meynaf

My question wasn't precise enough. I thought you understood it was all about asm, but no you didn't.
So let me retry : can you say the same about your asm code ?

Asm code is machine specific, naturally. I cannot write assembler that runs on 68k and x64 simultaneously. Quite apparent.