macro_rules! cpp_call {
        ($($tt:tt)*) => {
            unsafe { $($tt)* }
        }
    }

Yeah, not pretty, but it works :P

Nature finds its ways.

Seriously though, maybe comment annotation would be better than abusing the macros like that. I though there was a more direct cpp way. (Edit: As in the c preprocessor, not C++.)

> Rust does not have a textual substitution pre-processor

Is that not pretty much what Rust's procedural macros are? [0]

Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways), it can do any arbitrary manipulation of source code, but in a way that is integrated with the compiler and less prone to breaking the program.

[0] https://doc.rust-lang.org/reference/procedural-macros.html

A proc macro would still need to be invoked as either

    cpp_call! { fn foo() { ... } }

or

   #[cpp_call] fn foo() { ... }

The former can be written even with a macro_rules macro. Regardless, both macros have to work by parsing the whole input tokentree `fn foo ( ) { ... }` and emitting it back with an `unsafe` prepended. The macro invocation cannot expand to just `unsafe`.

Yes, this is what I was meaning, thank you.

its splitting hairs but not really. Rust's proc macros need to be explicitly invoked using special syntax at the usage site, either by annotating a statement or enclosing a block of tokens. On top of that, they do token replacement (or addition, with derive macros) which means they can only take valid input tokens as an argument (compared to macro_rules which can take arbitrary strings).

Textual substitution is less rigorous. It tells the compiler to replace a string with another, wherever it is seen. There's no restriction that it must be valid token input to be replaced or that it needs to be an explicit usage of the macro.

> Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways)

Reminds me of some of stringification abused in the Linux kernel. What looks like a function call passing the literal text param1## as an argument, where it would then trigger a different stringification in a subsequent preprocessor pass that prepended ##foo to the passed argument.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety.

I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust.

I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point is a bit skewed.

There seem to be very few GUI libraries which can be used in Rust as well. I'll keep checking https://areweguiyet.com/

If you want to use a tool that pastes code fragments in arbitrary places you can. However, I'm not clear on the benefit over something that's aware of its context, or at the very least AST aware.

Even modern C++ has eschewed macros for virtually every use case, the only reason I've had to use them (legitimately) has been conditional compilation and some compiler/platform specific issues.

Like if you're doing #define PI 3.14159 you're asking to get chirped in code review.

Ye, everyone know it is:

    #define PI 3.1415927410125732421875

that is the float closest to pi or that there is the GNU extension USE_FUNKY_DEFINES-something with M_PI for cmath. (I know you meant constexpr:ions).

Long time ago when computers were 32-bit I used to write something like this in C++:

    inline double pi()
    {
        __asm fldpi;
    }

On old enough compilers, this will get you 80-bit version of pi, more precision than even double. Completely useless now, modern compilers no longer emit x87 code.

math.h has M_PI in posix.

The point is that using macros for constants is frowned upon in modern codebases, just like all other use cases for macros that break type safety and the one definition rule.

Yes, I understand the point. But to your comment in a literal sense, if I were doing code review I would probably suggest using M_PI. Which happens to be a macro.

Which actually highlights that many things you want to use for practical purposes are C rather than C++, predate innovations such as const or namespaces, etc. It's possible and common to understand the downsides and still reach for the macro.

Just because we don't have textual substitution doesn't mean we don't have macros. We have a lot of macros!

(It took me a while to write back to you because I am busy writing bare-metal embedded Rust, btw. Including using some macros!)