<https://github.com/mgood7123/kpp>

# feed

[Smallville7123]

https://github.com/mgood7123/kpp

[altavir]

You really want to bring the worst of C/C++ world to kotlin?

[Smallville7123]

Maybe? XD

[Smallville7123]

At least only #define usage, other stuff is optional

[altavir]

It is really terrible. You'd better spend your time learning the language ant its way to solve those problems.

[Smallville7123]

How is it terrible o.o

[altavir]

The preprocessor breaks all tooling and makes the program behavior unpredictable. You should start by defining what problems do you want to solve with your tool (in #general). I am sure you will be immediately pointed in the right direction about how to solve it in Java/Kotlin world.

[Smallville7123]

Ok

[Smallville7123]

Also how would I detect such unpredictable behavior, and what are some examples of this unpredictable behavior

[altavir]

It seems obvious for me, but there is a lot of discussions about it. Like this question: https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives

[Smallville7123]

Ok, I'll try to see if I can address some of those problems so that hopefully they would not be a problem

[Smallville7123]

For example, I could change how the macro's are detected so that the user can easily tell if x is a macro or not, among other things such as attempting to rewrite the user's code during processing for (x++) cases, so it behaves as expected

[Smallville7123]

Aswell as, possibly replacing macros containing an if ... with a method then replacing the macro with a method call and so on

[Smallville7123]

Though I probably cant do any of that yet untill I figure out how to prevent infinite recursion in macro expansions

[Casey Brooks]

I’m curious why you’d need preprocessor macros when kotlin natively supports inlined functions, which seem to have a similar effect?

[Smallville7123]

dunno, lazy i guess lmao