KxSystems / kdb

Companion files to kdb+ and q
https://code.kx.com/q
Apache License 2.0
417 stars 163 forks source link

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

Open EveryNameIsTakenEvenThisOne opened 5 years ago

EveryNameIsTakenEvenThisOne commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 2 years ago

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.