Acknowledged

Feature-request: add pre-processor with inline functions to Monkey C

Please consider adding some pre-processor to Monkey C, similar to C.

For example we could have inline functions. It would make developers life much easier: the readability of the code would improve, in many cases the binary size could be decreased  litte-bit.

#inline function myfunc(a) {return App.getApp().getProperty("LeftGoalType") == GOAL_TYPE_FOO || App.getApp().getProperty("RightGoalType") == GOAL_TYPE_FOO;}

or:

#inline myfunc(a) App.getApp().getProperty("LeftGoalType") == GOAL_TYPE_FOO || App.getApp().getProperty("RightGoalType") == GOAL_TYPE_FOO

  • Just to mention it, from what I recall, some kind of optimizations are already there in the current (stock) compiler. At least things like if (xxx) { } where xxx is defined to be literal false makes the code in the body never included in the binary (this helps me a lot with eliminating all but essential code from builds for low-memory devices). Combined with (custom) annotations, this quite often makes it quite on par feature-wise with a preprocessor.

    For boring historical context, that type of optimization did not exist when this feature request was posted (2021).

    It was first available in 2022: https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/optimal-monkey-c

    But yeah, you are correct, the current state of optimization functionality in the Monkey C compiler lessens the need for inline functions.

    I will also reiterate that modern languages do not have a C-style preprocessor because of all the issues stemming from it. e.g.the use of certain preprocessor constructs makes it difficult or impossible for an IDE to properly interpret the code, not to mention the confusion it adds for humans.

  • Yes it's since SDK 7, but this feature request is from 4 years ago

  • Just to mention it, from what I recall, some kind of optimizations are already there in the current (stock) compiler. At least things like if (xxx) { } where xxx is defined to be literal false makes the code in the body never included in the binary (this helps me a lot with eliminating all but essential code from builds for low-memory devices). Combined with (custom) annotations, this quite often makes it quite on par feature-wise with a preprocessor.

  • So far, my biggest limitation is memory limits from code.  About 80% of my memory limit is code, whether from the data engine (that provides all my metrics), the on-device settings, or the licensing system.  Good quality experiences for customers require code - lots of it to handle various cases.  Anything to shrink that footprint and allow more logic will yield better customer experiences.

  • For anyone interested (Gavriel already uses it), I implemented inline functions in my optimizer a while back. It has the bonus of working with normal monkeyc syntax. You just add a (:inline) attribute to the functions, so you can compile with or without the optimizer, and it works either way.