Position configuration for UltraTrac

If you're just telling us what you're doing in the last 10 years, then whatever, but if you mean that something in my code is not good, then can you be more specific? Which line? I am doing has check, so I don't understand what is your point.

flocsy🤠 said:

yes, I know it will only work if has check is done at compile time)

jim_m_58 said:

For this, I've always done the has check at runtime,

flocsy🤠 said:

I am doing has check, so I don't understand what is your point.

Sorry to play the "forum whisperer" but I think jim_m_58 saw your literal comment "has check is done at compile time" and responded that he does has checks at runtime for this purpose.

My guess is that you originally meant to write "compile time has checks are disabled" (or something similar), but you accidentally wrote something with the opposite meaning, which is understandable (happens to all of us all the time.)

At the end of the day, I think we're all in violent agreement that these has checks should be done at runtime.

For what it's worth (not much) your code looks good to me.

Related bug I just opened:

fr955: Position.hasConfigurationSupport(CONFIGURATION_SATIQ) returns true in sim, false on real device

Hehe, no actually I do have the checks at compile time. I think there is at least one place in the above code where I use CONFIGURATION_GPS without checking if it exists, but also in a place in the code where it won't exist for old devices. I could also use numbers or add my constants, but I don't see how this could ever change in existing devices (they will not add a GPS chip, nor the constant to any device that doesn't have it now)

flocsy🤠 said:

Hehe, no actually I do have the checks at compile time.

Haha ok my bad - I made a dumb assumption and it blew up in my face as per usuge. Sorry for not taking you at face value. I made that assumption because jim_m_58 responded that he likes run time checks better, and you seemed to think he didn't have a point, so I thought you originally meant to say the same thing as he did. TL;DR I dun goofed by overthinking everything.

Either way, jim_m_58's response absolutely does make sense as he's insisting that, for him, run time has checks would be more appropriate than compile time has checks (in this case).

Having said all of that, I don't agree with the statement that your code only works if has checks are done at compile time though. Why wouldn't it also work if has checks are done at run time? I think your statement only makes sense if you assume that "compile-time has checks <==> replacing enums with their values" [*]. I don't think that's necessarily true.

[* my assumption about your assumption is based on your statement that compile time has checks are necessary and "I think there is at least one place in the above code where I use CONFIGURATION_GPS without checking if it exists, but also in a place in the code where it won't exist for old devices."]

Ofc both of those things (compile time has checks and replacing enums with their values) require optimization to be enabled at a certain level, but I *also* think that if you use the --disable-api-has-check-removal flag (so API has checks are done at run time), that doesn't mean that enums *won't* be replaced with their values.

You can try to verify or disprove what I said by looking at the generated mir files with optimization enabled and --disable-api-has-check-removal specified as a compiler option.

I think the mir files will show that enums are still replaced with their values, although has checks are done at run time.

(I wouldn't mind being proven wrong tho, as I like to know how the compiler actually works.)

In general, is it a good idea to rely on the behaviour of the optimizer? I get that you're trying to save precious bytes on older devices, and I've definitely manually replaced enums with constant integer values by hand in the past. I would be a lot more worried about relying on behaviour that's more or less invisible to me as a dev to avoid crashes [**]. (What if it changes in the future? What if I don't really understand how it works? Even if it won't change and I know how it works, maybe it's better to lighten the cognitive load by writing code that *doesn't* rely on how it works.)

[**] i.e. using an enum that doesn't on an old device will only work (not crash) if optimization is enabled at a certain level, and assuming the optimizer will replace the enum with its value. Whereas manually replacing an enum with its value in the source code might look ugly and be difficult to maintain, but you know it won't cause a crash due to a failed symbol lookup in any case.

(if I'm right about the above, it actually shows that "nit-picking" [*] - as in "good-faith attempt at attention to detail when it matters" as opposed to pointing out unimportant stuff for no reason except to be annoying - can be valuable in some cases. By trying to preempt nitpicking, you did reveal an interesting assumption about your code that may or may not be true)

[* I would call it attention to detail and not nit-picking when it's in good faith but I get how it can be annoying either way]

Yeah, and that lead to the following feature request (I don't understand how nobody opened such yet [or maybe I just couldn't find it]): https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-enable-more-granular-disabling-of-api-has-check-removal