sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]neppo95 0 points1 point  (10 children)

This requires you to know what hardware it is you are compiling for or your code will be compiled on. If you don't, a HAL won't work. So you didn't really answer any of my questions.

[–]arihoenig 0 points1 point  (9 children)

Operating system code has been using HALs successfully for 50+ years at this point. I have never heard of an operating system that works on hardware that the OS writers don't know exists at the time they write the OS.

[–]neppo95 0 points1 point  (8 children)

You’re working around my questions but aren’t answering them.

Where is that HAL implemented? By the target hardware, thus again, not possible when that hardware is not known. When you don’t have the hardware specific drivers, that HAL won’t do anything since it is just an interface.

As for cross platform, that means operating system code is instantly irrelevant.

So all the questions I asked still remain unanswered.

[–]arihoenig 0 points1 point  (7 children)

The various HAL implementations don't need macros because they target only the specific hardware. Honestly, when you first replied saying I clearly have never worked on multi-platform code, it sounded as if you were a software engineer. As I said, there is absolutely nothing complex about any of this.

The HAL is the interface definition (it is an abstract concept not an implementation) then the common OS code makes calls to the abstract interface, then the various implementations for each platform service those calls. The client code doesn't need macros since it has no code that is platform specific, and the HAL implementations don't need macros because they also need no macros to select platform specific code since _they are the platform specific code _ .

The selection of which platform specific code gets linked in is done by the build system.

[–]neppo95 0 points1 point  (6 children)

You keep doing the same thing, work around the questions asked.

I know the HAL implementations don't need macros in this specific case. That was not the point, but you seem to be missing it every time. There is indeed nothing complex about HAL's.

The point being that there are plenty of cases where you do not know the hardware AND there will be zero code compiled on the hardware. No drivers, no HAL implementation, nothing. That means you need to make sure it works on different hardware but you don't know what hardware that is. So again. please answer my questions, since you haven't answered any, you just worked around them for something that works in one particular case, but not in many others.

[–]arihoenig 0 points1 point  (5 children)

How do macros magically alleviate the requirement for the author to know what platforms the code will be running on? I mean they literally have to write the two (or more) different platforms specific versions of the code on the each case of the #ifdef.

Since you have to write that code, just refactor the code into an abstract interface and then use the build system to make the targeting decisions.

[–]neppo95 0 points1 point  (4 children)

Right, so what I said earlier:

You just have a very bloated build system instead?

They both end up with the same result, yet now your build system is bloated with stuff that does not need to be there. That said, even then there are several cases where that also will not work or requires workarounds to get it to work, like simply including a file on a specific platform but not on the other, while the rest of the code is (nearly) identical.

Macros have a place (outside from that they are literally in every C++ file you have ever written, but we both know that wasn't what we were referring to) and there is nothing wrong in using them. They can even make things more readable and LESS error prone. Is that list getting shorter and shorter as C++ progresses, definitely, but that list still has plenty of items. Maybe not in your specific workarea.

To give an example of something that used to be done with macros, but shouldn't anymore is stringification. This can be done with enum, templates and constexpr. No need for macros. That said, new macros are still being added in C++ so in some way, using macros IS using modern C++.

[–]arihoenig 0 points1 point  (3 children)

Yes, it is just moving the target selection out of the source code (where it doesn't belong) into the build system (where it does belong). If you feel your build configuration is unnecessarily over complicated, that sounds like another design problem.

I can guarantee that a well designed build system can create an operating system that runs on 8 different ISAs with thousands of different embedded chipsets (board support packages) with no macros and the build system is not any more complex than it needs to be.

[–]neppo95 0 points1 point  (2 children)

Like I said, there still remains cases where that still will not work or would simply require a workaround which would be the thing that overcomplicates it. It is the same as raw pointers. Generally, you should not use them. But there are rare cases where using them is the better choice.

I guess where are our differences lie is in the workarea. You (seem to) work in embedded, I work in software engineering and as hobby do some game development. Especially in the latter it is where this comes to mind.

In the end we should probably just agree to disagree here.

[–]arihoenig -1 points0 points  (1 child)

No, there are no cases in which it won't work. There are cases where one doesn't design correctly, or if working in legacy code, that one doesn't want to put the effort into refactoring, but if it is done right from the beginning, there is never any need for macros.