Coyote on Nostr: nprofile1q…lt054 From what I have read, correct me if I am wrong, it is primarily ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqc2k5qcrmycq3ycdyl0rnlex6ycfgyzsx7cnnzpaj8e6djrhc0tpsxlt054 (nprofile…t054)
From what I have read, correct me if I am wrong, it is primarily an optimization when used on functions.
Not really, at least anymore. At most it hints to the compiler to inline, insert the function's instructions wherever it's used, but the compiler is under no obligation from the language to do so. The inline keyword in C++ has evolved to mean that a function is allowed to have multiple definitions among different translation units (files, basically) as long as those definitions are the same. This allows one to write a function definition in a header file without needing it be static, a unique version in every translation unit.
Say I have a static variable in a namespace:
namespace stuff {
uint8_t x = 69;
}
Careful, static is an overloaded term that has different meanings depending on context. It can refer to the storage duration (stuff::x has static storage duration because it belongs to a namespace scope), or linkage (stuff::x has external linkage because it isn't static or const). Usually when people talk about variables or functions being static, they are talking about the use of the static keyword, so one could say you don't have a static variable.
What are some potential DRAWBACKS, if any, to making this inline?
inline isn't really a case of drawbacks and advantages because of its change to "multiple definitions allowed" meaning. There are cases where inline is required (your example were it to appear in a header file included in multiple translation units would need to be inline), cases where inline doesn't make a difference (static inline on a namespace scope variable or function has the same meaning as static), and cases where inline isn't allowed (any block scope variable).
As an aside, you have to reach for compiler specific stuff if you want the "optimization" version of inline. GCC and Clang can use __attribute__((always_inline)). It's unconditional, so it's easy to find this hurts more than helps.
From what I have read, correct me if I am wrong, it is primarily an optimization when used on functions.
Not really, at least anymore. At most it hints to the compiler to inline, insert the function's instructions wherever it's used, but the compiler is under no obligation from the language to do so. The inline keyword in C++ has evolved to mean that a function is allowed to have multiple definitions among different translation units (files, basically) as long as those definitions are the same. This allows one to write a function definition in a header file without needing it be static, a unique version in every translation unit.
Say I have a static variable in a namespace:
namespace stuff {
uint8_t x = 69;
}
Careful, static is an overloaded term that has different meanings depending on context. It can refer to the storage duration (stuff::x has static storage duration because it belongs to a namespace scope), or linkage (stuff::x has external linkage because it isn't static or const). Usually when people talk about variables or functions being static, they are talking about the use of the static keyword, so one could say you don't have a static variable.
What are some potential DRAWBACKS, if any, to making this inline?
inline isn't really a case of drawbacks and advantages because of its change to "multiple definitions allowed" meaning. There are cases where inline is required (your example were it to appear in a header file included in multiple translation units would need to be inline), cases where inline doesn't make a difference (static inline on a namespace scope variable or function has the same meaning as static), and cases where inline isn't allowed (any block scope variable).
As an aside, you have to reach for compiler specific stuff if you want the "optimization" version of inline. GCC and Clang can use __attribute__((always_inline)). It's unconditional, so it's easy to find this hurts more than helps.