Hacker News Reader

Comment by pineapple_sauce | Hacker News Reader

What should be evaluated is removing indirection and tightly packing your data. I'm sure you'll gain a better performance improvement. virtual calls and shared_ptr are littered in the codebase.

In this way: you can avoid the need for the `final` keyword and do the optimization the keyword enables (de-virtualize calls).

>Yes, it is very hacky and I am disgusted by this myself. I would never do this in an actual product

Why? What's with the C++ community and their disgust for macros without any underlying reasoning? It reminds me of everyone blindly saying "Don't use goto; it creates spaghetti code".

Sure, if macros are overly used: it can be hard to read and maintain. But, for something simple like this, you shouldn't be thinking "I would never do this in an actual product".

View on HN

Macros that are giving you some value can be ok. In this case, once the performance conclusion is reached, the only reason to continue using a macro is if you really need the `final`ity to vary between builds. Otherwise, just delete it or use the actual keyword.

(But I'm worse than the author; if I'm just comparing performance, I'd probably put `final` everywhere applicable and then do separate compiles with `-Dfinal=` and `-Dfinal=final`... I'd be making the assumption that it's something I either always or never want eventually, though.)

In modern C++, macros are a viewed as a code smell because they are strictly worse than alternatives in almost all situations. It is a cultural norm; it is a bit like using "unsafe" in Rust if not strictly required for some trivial case. The C++ language has made a concerted effort to eliminate virtually all use cases for macros since C++11 and replace them with type-safe first-class features in the language. It is a bit of a legacy thing at this point, there are large modern C++ codebases with no macros at all, not even for things like logging. While macros aren't going away, especially in older code, the cultural norm in modern C++ has tended toward macros being a legacy foot-gun and best avoided if at all possible.

The main remaining use case for the old C macro facility I still see in new code is to support conditional compilation of architecture-specific code e.g. ARM vs x86 assembly routines or intrinsics.

But how would one conditionally enable or disable the “final” keyword on class members without a preprocessor macro, even in C++23?

Macros are still useful for conditional compilation, as in this case. They've been sunsetted for anything that looks like code generation, which this isn't. I was more commenting on the reflexive "ick" reaction of the author to the use of macros (even when appropriate) because avoiding them has become so engrained in C++ culture. I'm a macro minimalist but I would use them here.

Many people have a similar reaction to the use of "goto", even though it is absolutely the right choice in some contexts.

Macros in C are a text replace and so it is hard to see from a debugger how th code got like that.

Yes, I'm well aware of the definition of a macro in C and C++. Macros are simpler than templates. You can expand them with a compiler flag.

when things get complex templete error messages are easier to follow. nobody makes complex macros but if you tried. (template error messeges are legendary for a reason. nested macros are worse)

> nobody makes complex macros

http://boost.org/libs/preprocessor

Reply on news.ycombinator.com