[meynaf]

Originally Posted by Thomas Richter

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.

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

Originally Posted by Thomas Richter

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?

Do it the way you want, the others do it the way they want, it's not my problem. Everyone is free, and hopefully.
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.

Originally Posted by Thomas Richter

That's what I call "stubborness".

You seem to be quite a specialist in that area.

Originally Posted by Thomas Richter

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

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

Originally Posted by Thomas Richter

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

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.

Originally Posted by Thomas Richter

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.

There is a contradiction here : if that works even better, why did you tell you were doing a lot of asm ? According to what you've just written here, you should be doing mostly some compiled stuff, and asm for the few remaining cases.

Originally Posted by Thomas Richter

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.

Still not "many others" doing it...

Originally Posted by Thomas Richter

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.

Library offsets are only a small part of it. And debuggers are not immune to getting them wrong. 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 ?

Originally Posted by Thomas Richter

FOr consistency, you use the least readable version?

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

Originally Posted by Thomas Richter

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".

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

Originally Posted by Thomas Richter

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?".

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

Originally Posted by Thomas Richter

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

Invalid argument (ad nauseam).

Originally Posted by Thomas Richter

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...

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.

Originally Posted by Thomas Richter

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

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.

Originally Posted by Thomas Richter

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.

I have tried it, and observed how the programs got worse.
And again, IT IS ONLY FOR OS INCLUDES.
So it has nothing "very fundamental" and isn't an error at all.

Originally Posted by Thomas Richter

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.

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.
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 ?

Originally Posted by Thomas Richter

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

Dependency resolution is only needed if there is something to resolve.

Originally Posted by Thomas Richter

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.

And where's the problem in rebuilding everything ? You wrote yourself that building times were pretty much unimportant.
Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler.

Originally Posted by Thomas Richter

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.

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

Originally Posted by Thomas Richter

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

What offsets ? There are no offsets visible to the end user.
AGAIN: It's just OS includes i don't use. My own structure members have names.

Originally Posted by Thomas Richter

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.

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

Originally Posted by Thomas Richter

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.

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.

Originally Posted by Thomas Richter

Exactly not, with numbers in it instead of names.

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 ?

Originally Posted by Thomas Richter

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.

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 ?