Repository navigation
k.h is unusable in C++ programs #12
Description
Activity
ENITETO is absolutely right. Style is subjective, so name your variables whatever you want. However, while everyone no doubt loves the hyper-terse, nonstandard, language-replacing syntax, preprocessor macros used to the extent seen in
k.hare near-universally seen as bad practice and are thus avoided. In theory, adding#include "k.h"could completely change behavior in completely unrelated code elsewhere. This really, really goes against good practice in C++.Reacted by Alexandre Quach-Tea and Anthony RubickI concur. We have to be extremely careful when using k.h from C++. The way it stomps all over the global namespace is really problematic. In practice what we normally have to do is make is make a wrapper header that #undefs O, R, Z, P, etc and everything else we don't use.
I find it highly doubtful that any end users are going to make any use of things such as
#define R returnin their own code. Perhaps we could have a cut down k.h that just includes the essentials.Reacted by Alexandre Quach-Tea, Ramana Kiran, Will Da Silva, Jimmy Lu and Nguyen Khoi PhanReacted by IstvanI think we need a
k-core.hwhich does not include any macro of single character to make it easier to be used in real world projects. The oldk.hcan still includek-core.hto avoid code duplication.
The deliberate obfuscation of using single uppercase characters as macro names instead of meaningful identifiers makes it impossible to comingle k.h with any reasonable C++ program that uses templates in which template parameters are single letters such as T and U, which are extremely prevalent in the STL and in Boost and is generally accepted good practice for C++.