• Replies 16 replies
  • Subscribers 21 subscribers
  • Views 397 views
  • Users 0 members are here
Options
Related

Cannot determine if container access is using container type

mcinner1

I'm getting a warning:

"Cannot determine if container access is using container type"

Using SDK 8.3.0

What can I do to get rid of that warning?
(What is the container type in that case?)

The code works perfectly!

Thanks for helping!

  • in reply to flowstate

    Wow!

    I really had var bikeshifter; without type!

    Changing it to  var bikeShifter as AntPlus.Device or Null;  leads to no warning when I use my former line: var batStatus = bikeShifter.getBatteryStatus(shifterArray[i]);

    Thank you for addressing this topic so in-depth.

  • in reply to mcinner1

    You're welcome!

    I will also point out that this could've been avoided by using strict type checking (aka the highest level / 3), because the type checker would've forced you to declare types for all variables, and you would've gotten a clear error in this case.

    Ofc as you pointed out, your code worked. But as bikeShifter was untyped, you could've easily had certain bugs in any of the accesses to bikeShifter which would not have been caught by the type checker (like calling member functions with wrong number/type of arguments).

    The warning about container access was just a symptom of the problem. Using strict type checking probably avoids a lot of these "mysterious" warnings, but ofc it forces you to do more work when writing your code.

    EDIT to be clear, strict type checking doesn't literally make these "mysterious" warnings go away, but at least in this case, it would add additional warning or errors which point to the root cause of the problem.

  • in reply to flowstate

    Flowstate provides helpful feedback here, good job. But in case some aren't aware, there are several ways to disable type checking. I prefer to add this to my project's monkey.jungle file, rather than a VSC setting or command line parameter. All my projects use these settings.

    -----------

    project.manifest = manifest.xml

    project.typecheck = 0
    project.optimization = 2
  • in reply to DaveBrillhart

    that is the exact "wrong" comment flowstate tried to explain why not to do...

    I use:

    project.typecheck = 3
    project.optimization = 3z
    which at least from the typecheck point of view goes in the spirit of the rest of this thread :) I would also recommend doing this in every new project from the beginning.

    optimization: For datafields that target old devices with less memory I use 3z (though unfortunately exactly the old devices seem to gain less than newer devices)
  • in reply to DaveBrillhart
    DaveBrillhart said:
    But in case some aren't aware, there are several ways to disable type checking

    The purpose of type checking is to make your code better, by catching certain kinds of problems at compile time, rather than run time. Same goes for addressing warnings (in the "right" way).

    Yes, mcinner1 could've disabled type checking, but they also could've just completely ignored the warnings, too, in which case this thread would not exist.

    I'd like to think that people who wish to eliminate warnings typically do so because they want their code to be better. Otherwise it would be trivially easy to simply ignore any warnings that the compiler emits. 

    I think the real question in the OP shouldn't be "how do I get rid of these warnings?", but rather "what's the cause of these warnings and what's the *best* way to address them?"

    Ofc anyone is free to disable type checking, but especially in this case, that solution isn't really any better than simply closing your eyes and pretending you didn't see those warnings. It's actually a lot worse, since it throws away any existing benefit that was gained from using the type checker. For example, at the time OP was posted, at least we know that the project:

    - compiles without type check errors (at whatever level they use, probably the default level)

    - in the future, won't compile if new code is written that contains type check errors

    Now let's say mcinner1 disabled type checking just to get rid of a couple of weird warnings. What was gained and what was lost?

    Gained:

    - They no longer see a couple of warnings that they don't understand

    Lost:

    - They no longer see a couple of warnings that they don't understand. If you take 2 seconds to think about it, this is actually a bad thing. What if those warnings pointed to real bugs?

    - In the future, they won't be informed of any new type check errors, which means they could add new bugs to their code which could've been prevented by the type checker

    It all depends on how you view the task of addressing warnings and errors I guess:

    1) It's just a video game where the goal is to eliminate all warnings and errors by the cheapest and quickest method possible, regardless of the consequences. I think this is the managerial approach to fixing bugs. I've dealt with managers who prefer to just close unaddressed tickets so their numbers look good. I'm sure no Garmin manager ever does this...

    I also see the same kind of thing with some TypeScript devs, where they'll just thoughtlessly add a cast to banish a warning or error, when it's not the right thing to do (and it actually obscures a real bug).

    2) warnings and errors actually tell me something important about my program. I want to understand them and address them the right way so my program will be better.

    --

    So yeah, if you just see software development as some kind of chore or game where the goal is simply to get your app to compile, go ahead and disable type checking completely.

    If you want to write better software, the type checker can help you. 

    Since you are obviously doing this as a hobby (like most people here), you should just do whatever works for you. But I don't think it's great advice to tell *other* people to disable the type checker. Even if others are doing this as a hobby, I don't think it's helpful to suggest worst practices.

    As a matter of fact, it's hobbyists and amateurs who can benefit the most from type checking, since it may catch problems that they didn't necessarily anticipate.

    I mean, ask yourself why Garmin enables type checking by default, or why they added type checking to Monkey C in the first place. Hint: it's not because they hate CIQ devs and want to make our lives harder.

    Even if I have type checking disabled for my old projects (for example), i would never suggest that it's the right thing to do in general, especially for new projects.

    DaveBrillhart said:
    All my projects use these settings

    Yeah that's unsurprising

  • in reply to flowstate

    I will also point out that more than once, I have seen noob devs post about problems with run-time crashes that could've been completely averted by using type checking at the default level. 

    Turning off type checking can lead to more bugs.

    Turning on type checking can prevent bugs. It can rarely lead to more bugs, unless you use it in a way that gives you a false sense of security (by using a casts to banish warnings and errors when it's neither necessary nor the right thing to do).