I was just a little too late for D7450 so @jacqueslucke suggested taking it to devtalk.
-----8<------[cut here] -----8<------
! In D7450#179813, @brecht wrote:
I suggest using
#pragma oncewould be good I think, but we can do that globally.
since we were picking on
_t being reserved for posix, i feel i can pick on this a tiny bit
and i’ll start with what the proper solution ought to be edit: new insights after talking on chat
#ifndef bli_float2_hh #define bli_float2_hh ... #endif
well the C standard says
The following identifiers are reserved and may not be declared in a program (doing so invokes undefined behavior):
2) All external identifiers that begin with an underscore.
3) All identifiers that begin with an underscore followed by a capital letter or by another underscore (these reserved identifiers allow the library to use numerous behind-the-scenes non-external macros and functions)
However lets pull up the C++ standard as well here
Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
#pragma once it’s not in any standard, also gcc seems to have some perf issues with it
So we end up in our current situation
#define __BLI_FLOAT2_HH__ clearly goes against 2 sets of standards, but everyone does it anyhow.
#pragma once is not in any standard, but all modern compilers support it anyhow.
which leads me to the solution posted above
On chat we looked at how chrome and llvm handled this they seemingly went with
#ifndef <PROJECT>_<PATH>_<FILE>_H_. for chrome (ie
llvm seems to follow a similar scheme
#ifndef LLVM_MC_MCEXPR_H for
Seems like a good solution, also given the define is depended on the path we could easily script this to do it in bulk.