Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

k.h is unusable in C++ programs #12

Open
EveryNameIsTakenEvenThisOne opened this issue Jan 21, 2019 · 3 comments
Open

k.h is unusable in C++ programs #12

EveryNameIsTakenEvenThisOne opened this issue Jan 21, 2019 · 3 comments

Comments

@EveryNameIsTakenEvenThisOne

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++.

@jesseconnell
Copy link

jesseconnell commented Feb 8, 2019

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.h are 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++.

@simon-graham
Copy link

I 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 return in their own code. Perhaps we could have a cut down k.h that just includes the essentials.

@Yuhta
Copy link

Yuhta commented Nov 23, 2021

I think we need a k-core.h which does not include any macro of single character to make it easier to be used in real world projects. The old k.h can still include k-core.h to avoid code duplication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants