Acknowledged
2 months ago

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

flocsy🤠
  • 1 month ago in reply to FlowState

    Yeah, I used to be in the same boat with C preprocessor. :-) So yeah, I'd say I'm quite impressed with what Monkey C offers as an alternative to it.

  • 1 month ago

    TL;DR macros are bad because they obscure meaning from both the IDE and the developer

  • 1 month ago

    Oh for sure, just providing context and getting on my soapbox to preach about the evils of the C preprocessor.

    Source: guy who abused the preprocessor for *years*

  • 1 month ago in reply to flocsy🤠

    Yeah, no worries - I understand. Just sharing what is the current state of the things/something that may be useful for new developers.

  • 1 month ago

    > not to mention the confusion it adds for humans.

    I've worked with C devs with decades of experience who did not understand why a macro that implement a multi-statement "inline function" should be written as follows:

    [invoked just like a regular function: "fake_inline_fn(x);"]

    They didn't understand the purpose of do...while(0) and why the above construct is superior to the extremely naive alternative of:

    Obviously the problem with the 2nd construct is in some cases it can be invoked with a trailing semicolon:

    All of this is to say nothing about the subtle difference between passing x as an argument to a true function (inline or not), where x is only evaluated once), versus passing x as an argument to a macro, where x is evaluated each time it's referred to in the macro body.

    And also to say nothing about what happens if you forget to surround uses of the macro argument with parens:

    #define bad_square(x) (x * x)
    #define good_square(x) ((x) * (x))

    bad_square(5 + 5); // 35, oops!