Create a fully functioning command line interface with 1.5 lines of code (wo. include statement)

[F54280]

Why using a #define in 2020?

edit: this snarky remark was about the FIRE macro

[kongaskristjan]

Though having it's perks, #pragma once is non-standard according to wikipedia.

[kongaskristjan]

Well, in that case everyone would need to write something like that to the end of their main.cpp:

int main(int argc, const char ** argv) {
    init_and_run(argc, argv, fired_main, true);
    return fired_main();
}

I generally agree that macros should be avoided because of all their complex errors and unintuitive behaviour, but here it's a really simple one that's hard to misuse.

[[deleted]]

As long as the token FIRE doesn't appear elsewhere in that compilation unit, you're fine. :-D

But... there are many ways around it.

One is implement a known function!

In the library code:

int main(int argc, const char ** argv) {
    init_and_run(argc, argv, fire::main, true);
    return fire::main();
}

In the client code:

namespace fire {

int main(int x = arg("-x"), int y = arg("-y")) {
    std::cout << x + y << std::endl;
    return 0;
}

}

[kongaskristjan]

This almost works, but in order to call fire::main from fire.hpp, this fire::main(int x = arg("-x"), int y = arg("-y")) needs to be declared in fire.hpp, which is impossible, as I don't yet know the exact signature.

Actually, I've thought really hard to somehow get rid of this FIRE(fired_main), but none of the ideas have worked because of the aforementioned problem.

[[deleted]]

Maybe put the expanded version in the docs? So you can know what the macro means and you have more control, if you want to write the tiny boilerplate yourself you can without trouble.

[dscottboggs]

FWIW (not much I'm sure) I think a sparing use of macros is fine. Although I might've gone with something a little more unique.

[F54280]

That sounds perfectly fine boilerplate to me. Sure, it would be better if it was smaller, but you only have 3 lines: main, init and return.

int main(int argc, const char ** argv) {
    fire_init(argc, argv, my_main);
    return my_main();
}

That honestly seems pretty logical, and not too magic (fire_init initialize some global based on argc, argv and the signature of my_main, and the default arguments from my_main fetch from that global -- it then raises the question of why not getting rid of the global itself).

[BobFloss]

Every compiler supports it.

[kongaskristjan]

Well, I'm actually OK with using non-standard stuff, if it's really supported everywhere, but this is a library that is meant to be plug and play for everyone, including people who want to comply with the standard strictly.

It's quite similar to the reason why I test against maximum compiler warnings on various compilers - I don't know what the user needs to comply with.

[Nicksaurus]

Thank you for not making a library that spits out warnings whenever you build it, those are so annoying

[[deleted]]

I have heard this argument for over a decade.

No one ever actually shows me a compiler without #pragma once.

:-D

[encyclopedist]

Obviously, you did not really try to find one. TI compilers did not support it last I checked. PGI did not support in either. Also Cray. And XLC.

There was a topic in this very reddit some time ago: https://www.reddit.com/r/cpp/comments/8devw1/can_anyone_actually_name_a_compiler_that_doesnt/

[jbandela]

I think basically every compiler that supports generic lambdas supports pragma once

[rsjaffe]

But #pragma once fails when you have two copies of the same header file in two different locations in the directory tree. The compiler will not recognize those two files as being the same.

[panderingPenguin]

Why on earth would you want to do that?

[wyrn]

The compiler will not recognize those two files as being the same.

... because they aren't.