On Tue, Jun 16, 2015 at 2:25 PM, Roland Bock
On 2015-06-16 16:09, Louis Dionne wrote:
Roland Bock
writes: Roland Bock
writes: [...]
_Compile__time strings:_
[...]
* I do not want to "using namespace ::boost::hana::literals" at top-level or in one of the namespaces in the header. Is it acceptable to only import the `_s` string literal from Hana?
using boost::hana::literals::operator""_s; Not really. This code has to be provided by the user of the library. It
On 2015-06-15 21:08, Louis Dionne wrote: lives outside the sqlpp namespace. I cannot just tell them, to please import some string literal into their namespace.
[...] I must admit I don't have a solution. This is such a pain since it is a __joke__ in terms of implementation difficulty at the compiler/language level, but I think it is not solvable at the library level.
I do hope that libraries like Hana, Metaparse and sqlpp11 help in proving that there is need to add language support for compile time strings.
This. +1. Then, +1 again. There was a cute suggestion at CppNow about performing Great Violence with the preprocessor (and an illustration was shown for how it does actually work): (1) Put your clear-text in a text file. (This isn't a C++ file, it's just arbitrary text.) (2) Use #include"" to pull that text-file into some arbitrary location within your C++ code (perhaps within a "constexpr" function body). (3) Use "constexpr" operations within that "constexpr" function-body to perform arbitrary string-manipulation (at compile-time), thus achieving compile-time arbitrary string manipulation. There is a "suggested-limit" regarding the number of compile-time execution operations a given compiler might implement to support constexpr-function bodies (I think the guidance was something like 500 operations executed at compile-time by the compiler, don't remember), but you could "reset" this limit with each translation unit. So, I was actually thinking about making a library that would perform this string-manipulation at compile-time to assemble massively complex strings. Typical manipulations are (of course) things like embedding version information, embedding resources and paths, and other higher-order-operations like embedding SQL queries. However, even though I think it would really work, I think it's a horrible work-around that becomes completely useless when we, "doing it right" and actually adding language support for compile-time strings. --charley