Hello Gert,
I reconsidered this point and found some lively discussions about it,
e.g. http://stackoverflow.com/questions/1674032/static-const-vs-define-in-c
The "const int" way has some advantages (as pointed out in all the
discussions I found) over the #define:
- It is type-safe
- It respects scope
- It eases (in some cases) debugging (entry in symbol table)
It is usually recommended as "static const", what we could also use.
Am 04.06.2014 16:05, schrieb Holger Kummert:
>>+ const unsigned int uni_max_utf16 = 0x0010FFFF,
>>+ uni_half_base = 0x00010000,
>>+ uni_half_mask = 0x000003FF,
>>+ uni_half_shift = 10,
>>+ uni_sur_high_start = 0xD800,
>>+ uni_sur_low_start = 0xDC00,
>>+ uni_sur_low_end = 0xDFFF;
>
>I'm feeling slightly uneasy with these. If these are true constants,
>is there a good reason to use "const int" variables, and not follow
>the usual convention
>
>#define UNI_MAX_UTF16 ...
>#define UNI_HALF_BASE ...
In the original code both variants are used ...
(see http://clang.llvm.org/doxygen/ConvertUTF_8c_source.html)
>
>so it's more obvious to the reader of the code that this is not something
>which can change at run time?
Well, doesn't a "const" definition express this?
Yes, you're right, they are actually constants.
The reason why I defined them as variables is because I wanted to keep
things together that belong together. I'm a bit unhappy with defining a
constant in a separate .h file that is used only once somewhere in the code.
So what about defining them as constants, but at the same location in the
code as the variable definitions are now?
So I'm in favor of the "static const" - definition.
Opinions?
Holger
