Unexpected const behaviour

Former Member
Former Member
Good software engineering practice is to declare any constants (with const) used within a class to be in the class to avoid any potential clashes with constants in other classes. The constants in this case are just numbers and not arrays or other more complicated data types.

While trying to reduce the memory footprint of my app I discovered that all const declared in a class take up memory in *every* instance of that class. It is reasonable that the const data is stored in memory as it may be more than a simple data type (or maybe the VM instruction set doesn't support immediate constants) but should only need to be stored once.

Simply moving the 4 const in a class to be outside of the class saved me about 1KB of memory in my app as this class is heavily instantiated.

On a slightly more academic note, if a class const is an array the array contents can still be changed (as documented in the SDK) but as each instance gets its own const array changes made to the const array contents will be private to that instance making the change and not shared across all instances. It is not a programming style I would every use but I would have expected the changes to be shared given the scope of where the const is declared.

It looks like const just marks the variable as immutable but other than that it is treated as a regular variable and no special use made of its immutable nature in optimising the code.

Dave.
  • I've pointed this out in the past. I think the right thing to do as a developer is to make them static const. The static tells the compiler to make one instance shared between objects of the given type, and the const indicates the data is immutable.

    That said, it seems like it would be an easy optimization to make all class members that are declared const implicitly static.

    Travis
  • Here is the original post I mentioned above. I'll verify I'm still seeing these unusual behaviors and I'll file bugs for them.

    Travis
  • In the thread that Travis linked to, we had looked at the behavior of enums (per the original post in the thread), and determined that it's functioning by design. Enums of a class can only be accessed through an instance variable of said class.

    However, I think it's worth taking another look at this and also worth considering making all constants static, as Travis suggests. Travis, unless you've already gotten started on this, I'll evaluate a few different cases and get some tickets filed for review.
  • However, I think it's worth taking another look at this and also worth considering making all constants static, as Travis suggests. Travis, unless you've already gotten started on this, I'll evaluate a few different cases and get some tickets filed for review.


    I have a test case written up, but I haven't had a chance to submit it. I hesitated because I'm starting to think this is by design. It seems that const in MonkeyC is very much like final in Java. Unless you declare something static in Java, I believe you get a unique variable in each instance. If this is the case, maybe it is just an issue with the terminology.

    I'll file the test case either way, and I'll let you guys figure it out. :)

    Travis
  • Former Member
    Former Member over 8 years ago
    Hi Travis,

    Static is a much better solution than mine.
    Nice test by the way.

    Dave.