4 ms·

Welcome to the future of C++ :) [[clang::musttail]] [[deprecated]] [[nodiscard]] static inline bool& func(...) noexcept {...}

Matheus28 5y ago
You forgot constexpr
- sitkack 5y ago
  CppCon 2017: Ben Deane & Jason Turner “constexpr ALL the Things!” https://www.youtube.com/watch?v=PJwd4JLYJJY https://www.youtube.com/watch?v=PJwd4JLYJJY
ndesaulniers 5y ago
[[always_inline (for real though this time)]]
ufo 5y ago
To be pedantic... the musttail attribute goes in the return statement with the function call, not on the function definition.
vlovich123 5y ago
Attributes don't need to go in separate sections though: [[clang::musttail, deprecated, nodiscard]]. Also unfortunately the inline keyword doesn't really do much except make the author feel happy they thought the compiler they told it to inline that function.
wahern 5y ago
I'm more of a C programmer, not C++, but several years ago I switched to BSD/KNF style for function definitions because it improved consistency and diff-friendliness when managing qualifiers and attributes. BSD/KNF style is, int foo(int a, int b) { ... } This lends itself to prepending and appending qualifiers as separate lines, like __attribute__((unused)) __attribute__((format (printf 1, 2))) static inline char * sformat(const char *fmt, ...) { ... } Often I'll split linkage qualifiers (static inline) from return type (char *), especially when linkage is controlled by a macro. K&R and Linux styles are similar: int foo(int a, int b) { ... } Function prototype styles are the same across BSD/KNF, K&R, and Linux, keeping the return type on the same line as the identifier, but I'll often put linkage qualifiers and sometimes even return types on their own line, especially if there are other attributes as well. Note: All these styles normally place braces on the same line as control flow statements. Function definitions are treated differently for what I understand in hindsight are good (if possibly serendipitous) reasons. C++ complicates things with methods, template, etc, so I'm not sure how well the above styles fit C++. In what little C++ I've written one of my first gripes was with difficulties controlling linkage, period.
pjmlp 5y ago
Just wait for the C++ version from Spring.

Matheus28 5y ago

You forgot constexpr

sitkack 5y ago
CppCon 2017: Ben Deane & Jason Turner “constexpr ALL the Things!” https://www.youtube.com/watch?v=PJwd4JLYJJY https://www.youtube.com/watch?v=PJwd4JLYJJY

ndesaulniers 5y ago

[[always_inline (for real though this time)]]

ufo 5y ago

To be pedantic... the musttail attribute goes in the return statement with the function call, not on the function definition.

vlovich123 5y ago

Attributes don't need to go in separate sections though: [[clang::musttail, deprecated, nodiscard]]. Also unfortunately the inline keyword doesn't really do much except make the author feel happy they thought the compiler they told it to inline that function.

wahern 5y ago

I'm more of a C programmer, not C++, but several years ago I switched to BSD/KNF style for function definitions because it improved consistency and diff-friendliness when managing qualifiers and attributes. BSD/KNF style is, int foo(int a, int b) { ... } This lends itself to prepending and appending qualifiers as separate lines, like __attribute__((unused)) __attribute__((format (printf 1, 2))) static inline char * sformat(const char *fmt, ...) { ... } Often I'll split linkage qualifiers (static inline) from return type (char *), especially when linkage is controlled by a macro. K&R and Linux styles are similar: int foo(int a, int b) { ... } Function prototype styles are the same across BSD/KNF, K&R, and Linux, keeping the return type on the same line as the identifier, but I'll often put linkage qualifiers and sometimes even return types on their own line, especially if there are other attributes as well. Note: All these styles normally place braces on the same line as control flow statements. Function definitions are treated differently for what I understand in hindsight are good (if possibly serendipitous) reasons. C++ complicates things with methods, template, etc, so I'm not sure how well the above styles fit C++. In what little C++ I've written one of my first gripes was with difficulties controlling linkage, period.

pjmlp 5y ago

Just wait for the C++ version from Spring.